Yvan Boily [yboily (at) seccuris (dot) com [email concealed]] wrote:
> on almost every single code audit I have participated in I
> have received hostile responses from the development team.
> ...
> I need to know ... interactive than defensive. Any pointers?
Yvan,
The quality of your audit has a lot to do with how it is received by
everyone involved. If you are able only to pick apart the flaws that
everyone knows are there, then what's the point, really? Why shouldn't
the developers view you as an annoyance if your job is to rake them over
the coals for doing the very thing that management told them to do?
Namely, it was most likely the developers' explicit mission to get the
product feature-complete as quickly as possible because there is a
drop-dead go-live date that is the reason the developers have a job
doing development in the first place.
It does appear ironic and absurd for management to then punish the
developers for meeting the schedule by having a code audit pick apart
all the things the developers were forced to skip over in order to
finish on time.
The developers themselves can show you those things, since they probably
have them all memorized and documented.
Now, if you are able to point out things that the developers truly did
not already know so that they learn something new, if you are able to
document, for the developers' benefit in their relationship with
management, mistakes and skipped steps and lack of understanding or lack
of devotion to security on the part of management at the same time, and
in a balanced manner with a presentation of indisputable facts, then
developers will love you and management will love you and both will gain
new leverage in their ongoing relationship with the other.
If you are being asked to do code audits rather than forensic audits
that examine anything and everything your expertise guides you to
examine, then you are being manipulated by people who think that
security is all about finding the mistakes made by others rather than
perfecting security starting with themselves.
Examine the whole process the way a forensic examiner does during a
forensic audit and you will see, and reveal, a very different picture of
cause-and-effect.
Sincerely,
Jason Coombs
Director of Forensic Services
PivX Solutions, Inc.
http://www.PivX.com/forensics/
-----Original Message-----
From: Yvan Boily [mailto:yboily (at) seccuris (dot) com [email concealed]]
Sent: Monday, August 30, 2004 10:45 AM
To: secprog (at) securityfocus (dot) org [email concealed]
Subject: "Selling" a code-audit.
One of my primary responsibilities with my employer is performing code
audits; so far I have been fairly effective in a technical capacity,
however on almost every single code audit I have participated in I have
received hostile responses from the development team. I have tried a
variety of approaches to develop a stronger rapport with the development
team, however in spite of my best efforts I find that going into a code
audit I am already fighting against preconceptions about why the code
audit is being performed.
I understand that many people feel threatened when work they have done
is criticized; what I need to know is how I can minimize this and coax
the development teams into being more interactive than defensive. Any
pointers?
> on almost every single code audit I have participated in I
> have received hostile responses from the development team.
> ...
> I need to know ... interactive than defensive. Any pointers?
Yvan,
The quality of your audit has a lot to do with how it is received by
everyone involved. If you are able only to pick apart the flaws that
everyone knows are there, then what's the point, really? Why shouldn't
the developers view you as an annoyance if your job is to rake them over
the coals for doing the very thing that management told them to do?
Namely, it was most likely the developers' explicit mission to get the
product feature-complete as quickly as possible because there is a
drop-dead go-live date that is the reason the developers have a job
doing development in the first place.
It does appear ironic and absurd for management to then punish the
developers for meeting the schedule by having a code audit pick apart
all the things the developers were forced to skip over in order to
finish on time.
The developers themselves can show you those things, since they probably
have them all memorized and documented.
Now, if you are able to point out things that the developers truly did
not already know so that they learn something new, if you are able to
document, for the developers' benefit in their relationship with
management, mistakes and skipped steps and lack of understanding or lack
of devotion to security on the part of management at the same time, and
in a balanced manner with a presentation of indisputable facts, then
developers will love you and management will love you and both will gain
new leverage in their ongoing relationship with the other.
If you are being asked to do code audits rather than forensic audits
that examine anything and everything your expertise guides you to
examine, then you are being manipulated by people who think that
security is all about finding the mistakes made by others rather than
perfecting security starting with themselves.
Examine the whole process the way a forensic examiner does during a
forensic audit and you will see, and reveal, a very different picture of
cause-and-effect.
Sincerely,
Jason Coombs
Director of Forensic Services
PivX Solutions, Inc.
http://www.PivX.com/forensics/
-----Original Message-----
From: Yvan Boily [mailto:yboily (at) seccuris (dot) com [email concealed]]
Sent: Monday, August 30, 2004 10:45 AM
To: secprog (at) securityfocus (dot) org [email concealed]
Subject: "Selling" a code-audit.
One of my primary responsibilities with my employer is performing code
audits; so far I have been fairly effective in a technical capacity,
however on almost every single code audit I have participated in I have
received hostile responses from the development team. I have tried a
variety of approaches to develop a stronger rapport with the development
team, however in spite of my best efforts I find that going into a code
audit I am already fighting against preconceptions about why the code
audit is being performed.
I understand that many people feel threatened when work they have done
is criticized; what I need to know is how I can minimize this and coax
the development teams into being more interactive than defensive. Any
pointers?
Yvan Boily
[ reply ]