Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

Re: "Selling" a code-audit.

Subject: Re: "Selling" a code-audit.
Date: Mon, 20 Sep 2004 07:39:54 -1000
Yvan Boily [yboily@seccuris.com] 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@seccuris.com] Sent: Monday, August 30, 2004 10:45 AM To: secprog@securityfocus.org 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

<Prev in Thread] Current Thread [Next in Thread>