I have been doing this computer thing for a dozen years
now. I started out as a developer and
migrated over to the dark side, aka application security. I have read lots of blogs and books on
various security and software topics. I
have attended a number of conferences including Black Hat, BSides and
OWASP. I always come away with really
awesome ideas on new processes and technologies. I am always excited to get back to work and
implement these ideas to help my organization.
I put in all of that hard work and finally unveil the final product and…
nothing. Well shit, none of the speakers
at the conference or authors of the blogs or books I read talked about how to
actually communicate these new ideas to the people who have to use the new
process or technology. Think about all
of the conferences you have attended and all of the blogs you have read. How many times have you read about how to
effectively communicate these ideas to the developers who have to implement
them?
Communication is a key area that I’m actively working to
improve, both personally and professionally.
I realized a long time ago that I have a slight temper and this affects
my ability to communicate effectively. There
are times when it takes every bit of patience I have not to tell a developer
their code is complete horse crap. This
isn’t effective and won’t help get vulnerabilities fixed. The approach that should be taken is that of
a teacher, but not a teacher that gives you detention for not turning in your
homework. As security professionals we
should take this approach more often rather than scolding users, developers,
operations, etc. Instead of scolding a
developer for not using parameterized queries to prevent SQL injection the
better approach is to educate them. Sit
down and fix a couple of the vulnerabilities together while teaching the
developer how to use parameterized queries.
Avoid confrontation whenever possible. Getting into a debate about whether a piece
of code is vulnerable is not effective.
Instead, emphasize that while there might be no clear way to exploit the
vulnerability, the code does not meet secure coding standards and that is the
ultimate goal. If developers follow
secure coding standards, then there will never be a debate about whether or not
code is vulnerable. My organization
conducts annual security training which stresses secure coding standards and we
also have a policy that codifies the use of secure coding standards. Because the organization has bought into
using secure coding standards it is easy to leverage this mandate while in
discussions with developers.
Keep your ears open and your mouth shut. Sometimes the best communication is not to
say anything at all and just listen.
Seek out those in more senior positions and observe how they communicate
with people. Pay attention to how they
respond in tense situations when another person is losing their temper. I can remember observing a mentor of mine
when he was being confronted with people looking for a confrontation. My mentor stayed calm and collected. He stayed on topic and would continue to
offer different solutions looking for a compromise. The person who is losing their cool might
have a point so pay attention to what they are saying. This will help diffuse the situation.
As for those cool ideas you got from the conference you just
attended, make sure to have a plan for implementation. Don’t just go to the developers, hand them a
spec and say they have 3 months to implement this. Explain your vision and why this idea is
critical to achieving the organization’s goals.
Come up with short term goals so you can get some quick wins and explain
the long term goals of the project. Most
importantly, don’t let the developers think you’re not invested in this project
as much as they are. If the developers
see you working hard towards the end goal they won’t have an issue working with
you.
