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 20:45:23 -0700
I want to concur with Peter - you should do a code <insert noun> after
you've given the devs a tutorial, otherwise they'll find nothing.

And teach them tricks, like evaluating the data source - it's all about
the data in many cases; and untrusted data from mostly anonymous users
is what causes real issues. Code on an anonymous data path should be
reviewed the most.

[Writing Secure Code] http://www.microsoft.com/mspress/books/5957.asp
[Protect Your PC] http://www.microsoft.com/protect
[Blog] http://blogs.msdn.com/michael_howard

[On-line Security Training]
http://mste/training/offerings.asp?TrainingID=53074


-----Original Message-----
From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] 
Sent: Monday, September 20, 2004 10:14 AM
To: secprog@securityfocus.org
Subject: Re: "Selling" a code-audit.

Adam Shostack <adam@homeport.org> writes:

Don't call it an audit.  Call it a review, a walk-through, or something
less
agressive.

Right.  It's going to be tricky to avoid the perception by developers
that
auditors aren't just externally-appointed code nazis come to criticise
their
work.  One possible approach here is to treat it as a lead-in to the
developers themselves doing the reviews/walk-throughs.  So you start out
with
(say) a half-day tutorial on security reviews/walkthroughs, and then
spend the
second half of the day going through code with the in-house developers,
as an
extension of the initial tutorial.  Although this may quack like a code
review/audit, all it's doing is using actual code to point out a few
examples
for tutorial purposes (no, really!).  The actual code reviewing is then
done
by in-house developers, possibly with a little further assistance
(purely to
provide guidance and training, no more) by the external
auditors/reviewers.

(Something to watch out for is that although everyone will be
enthusiastic
 about code reviews initially, eventually some ship deadline will come
up
 faster than expected and the reviews will be dropped to save time, and
then
 another urgent deadline will appear, and pretty soon it'll all be going
out
 unchecked again).

Peter.


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