RE: Lame studies that people quote as fact that have no basis in reality and still don't prove anything even if they did

["Brass, Phil (ISS Atlanta)" <PBrass () iss net>]

Depends on your industry.  Typical COTS software can defer known
defects, including possible security risks (though typical COTS
developers and QA teams probably don't think much about these), until
after release, so it doesn't matter when you find them, since finding !=
fixing.  Also, building secure software boosts the consumer's
productivity and reduces the consumer's costs, but as you point out I
don't think it does the same for the developer (unless they have
contractual sanctions of some sort for security defects, and that
probably doesn't happen very often - in my experience when, for example,
a consulting shop delivers a banking or mortgage application, which is
then tested and found to be full of holes, the client generally pays the
consultancy some more to fix their problems).

Banks and the like are very interesting, because I imagine they don't
get to make that choice to defer fixing serious security issues.  I
imagine there's some pretty strong due-diligence requirements on that
sort of thing.  So unlike regular software where the cost of defects can
be weighed after they have shipped, and their "real" urgency can be
gauged from consumer reaction, and sort of amortized over multiple
development cycles (i.e. only ever really fixing the bugs your users are
seriously griping about, leading to a steadily growing pile of
continuously deferred medium and low priority bugs that has been known
to drive men insane), serious software security defects in the financial
industry become showstoppers, so every one of them has to get fixed, and
there's no amortization cost benefit.  Furthermore, because the option
of deferring these bugs is not available, it is possible to incur
tremendous opportunity costs while you wait for your software to be
fixed, something other industries can shrug off and say "That's going to
be the cost of being first to market".

Combine this with the frequently endemic nature of security defects -
they are defects in implementation style (not performing safe integer
arithmetic, concatenating parameters to make SQL statements) or design
(not having a reference monitor or row-level access control), and rather
than having a single defect to fix, what you really have with one
"vulnerability" is a problem on multiple lines in every file in the
application.

So it's my opinion that security "bugs" are much much more expensive to
fix during implementation or maintenance than regular bugs.  The numbers
you quote sound much more like the kind of numbers I hear about regular
software in books like "Rapid Development".  For security bugs in
financial software, I believe it is much higher.

This is why education is the key for this kind of software.  If you can
start with educated developers, the risk and cost of security problems
can be significantly reduced.

IMHO.

Phil

> -----Original Message-----
> From: dailydave-bounces () lists immunitysec com 
> [mailto:dailydave-bounces () lists immunitysec com] On Behalf Of 
> Dave Aitel
> Sent: Wednesday, February 04, 2004 9:33 AM
> To: dailydave () lists immunitysec com
> Subject: [Dailydave] Lame studies that people quote as fact 
> that have no basis in reality and still don't prove anything 
> even if they did
http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss306_art550,00.
html

"""
Don't get me wrong. Building secure software is a laudable goal. It 
boosts productivity and reduces costs. According to one study, it's 6.5 
times more expensive to fix a security problem in the implementation 
phase than in the design phase of a software rollout. By the time you 
get to the maintenance phase, it's 100 times more expensive. """

This is crap. If you spend your whole life looking for security bugs in 
your product, then you find them. Continuously. You'll end up finding at

least 100 times more than will ever come out in public. So you really 
save a lot of money by doing everything in the QA phase, where it
belongs.


-dave




_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave