Silver Bullet turns 2: Mary Ann Davidson

[arian.evans at anachronic.com (Arian J. Evans)]

I'll second this Gary. You've done nice work here.

I think Mary Ann's comments are some of the most
interesting concerning what our industry needs to
focus on in the near future. (and I'd love to see you
focus on this with your series)

Her comments reminded me of a discussion on this
list with Wysopal a year or so ago.

Wysopal described defect detection in manufacturing,
and gave software security analogues. This resonates
with me as I'm fond of using analogues to airplane
manufacturing, construction, and testing to explain
what a software SDL should look like, and where/why
whitebox, blackbox, and static analysis could and
should fit in a mature SDL model. And how you
evaluate/prioritize assets and costs.

Important to this discussion is the vastly different
degrees of defect detection we perform on human
transport planes versus, say model airplanes,
where the threat profile is (obviously) reduced.

Yet in software, security folks at many organizations
have a very hard time deciding which planes have
more valuable payloads. What defect to address?

The buffer overflow on the Tandems (that no one
knows how to write shellcode for)? The SQL injection
on the public content DB? The non-persistent XSS
buried deep in the application? HTTP control-character
injection in the caching proxy? Prioritization difficulty...

Mary Ann is asking for metrics, including cost, and
some measure of threat profiles from which to
calculate or estimate the risk presented by defects.

Ultimately I think we all want some sort of priority
weighting by which to make better decisions about
which defects are important, what our executive
next-actions are, what to filter, etc.

But this can't come from software analysis. This
must come from organizational measurement data.

The problem is, nobody in our industry has good
data on what those metrics are. Many of us have
little slices, but there is no universal repository
for sharing all of that information (which is needed).

The software-security marketing industry has relied
as a crutch on software-defect cost-analysis studies
done by large accounting consulting firms that have
a vested interest in puffing up the "discovered" costs,
so that they can sell multi-million-dollar, multi-year,
software defect-reduction projects to their clients
that are reading those reports.

I don't think those reports have much to do with
our industry. (We're all aware of the "we reduced
1 bug per 10 lines of code saving the customer
millions" games those consultancies play, right?)

We really need to know:

Threat:
+ What are the attackers going after?
+ What is being attacked and how often?
+ What is being lost?


Attack Surface:
+ What attacks are successful and how often?
+ What are the most common attacks?
+ What are the most common/successful targets?

Then we need to map this back into software
design patterns and implementation practices,
and generate some metrics around costs to:

+ hotfix & support
+ release-fix and regression test
+ redesign and re-implement

In the manufacturing world, the people who
analyze this data are the actuaries or the
government regulatory agencies. We have
neither insurance or regulation to drive this.

We also need to see if it really costs more
to fix code after-the-fact, versus avoidance
up front. I suspect this up-front avoidance is
still cheaper with unmanaged code products,
and maybe with all design issues.

In the web software world, though, I think this
is not always the case.

(I suspect in the web world, especially with
modern frameworks, it is just as cheap
and easy to refactor/hotifx post-production
software as it is to catch defects before final
implementation or shipping code)

Anyway -- there's a lot that has to happen
to provide Mary with the data she wants
(and indeed any smart CSO in an ISV
should be asking for).

In fact -- it's amazing we've improved so
far, so fast, without even knowing what
the tensile strength of our materials is,
or having a concrete notion of what the
cost of  failure is in a final product.

So where will this come from?

Insurance?

Regulation?

Industry self-policing project?

Is someone here working on this today?

Cheers. Ciao

-- 
-- 
Arian Evans, software security stuff



On Thu, Apr 3, 2008 at 10:19 PM, Stephen Craig Evans
<stephencraig.evans at gmail.com> wrote:
> Gary,
>
> Great interview. You've had some powerhouse interviews recently, for example
> with Chris Wysopal ("my dream is that a static tool can fix business logic
> flaws") and Ed Amoroso ("security researchers are the bomb defusers of the
> Internet").
>
> I laughed at your blunt comment: "that would be great (everybody doing
> software assurance in 5 years) but also impossible".
>
> Andrew, in addition to your points:
>
> - I liked her self-deprecating humor when she talked about her coding skills
>
> - I think she made a justified, underhanded jab at the appsec community to
> make our stuff easier to use when she said:
> (At 4m 55sec) "There are a lot of people who are very well-intended and very
> sharp who come up with laundry lists of 8000 good things that we should do
> in security and all these things we should be doing and all these metrics ?
> and that's all great, but then ... what is the benefit for the cost of
> getting that information?" and "the do-gooders, and in this case I mean it
> in a good sense, need to do is to help people figure out what are the most
> important things to do first so that they'll get the biggest bang for the
> buck".
>
> - I liked her point, using a military analogy, is that products should be
> self-defended.
>
> Cheers,
> Stephen
>
> ---------------------------------------------------
>  From: Andrew van der Stock <vanderaj at owasp.org>
>  Date: Thu, Mar 27, 2008 at 7:32 AM
>  Subject: Re: [SC-L] Silver Bullet turns 2: Mary Ann Davidson
>  To: Gary McGraw <gem at cigital.com>
>  Cc: Kathy Clark-Fisher <KClark-Fisher at computer.org>, Mary Ann Davidson
>  <mary.ann.davidson at oracle.com>, Secure Mailing List
>  <SC-L at securecoding.org>
>
>
>
>
>  Gary,
>
>   Good interview.
>
>   The discussion on being unable to develop trust relationships with
>   contractors who release exploits was interesting, and I wished that
>   there was more discussion on that point. I would have thought signing
>   a contract made it easier to sue for breach of contract than untested
>   laws (or bad laws like the UK's RIPA), so much so you'd really think
>   twice as well as the negative downside of being considered
>   untrustworthy with confidential data - which is like a plague to any
>   consultancy business.
>
>   I really wish Ms Davidson had gone into detail on their SDL, as to
>   what is really in there, and where we could read it and review it.
>
>   Oracle's is an interesting turn around considering back in 2005 /
>   2006, the research community and Oracle's relationship was at an all
>   time low, essentially begging Oracle to put in an SDL and address the
>   security defects properly without outside folks finding them first.
>
>   I have since read that fences have been somewhat mended between
>   researchers, such as David Litchfield, and Oracle. I still wince at
>   that episode - it was entirely unprofessional of Oracle to attack
>   Litchfield, who was practicing responsible disclosure for up to
>   600-800 days, when 30 is the norm. I personally was extremely
>   unimpressed with Oracle's approach of shooting the messenger rather
>   than fixing the product.
>
>   I must admit that episode led me to dismiss Oracle as the walking dead
>   as they obviously couldn't be trusted with data of value, and so
>   didn't follow news about Oracle ... until this interview.
>
>   I'm glad they're now using automated SCA tools and fuzzers, they're
>   now finding most of the security issues themselves, have an internal
>   review team, and my personal favorite - developer awareness /
>   education. This is a 180 degree turnaround from the prior to 2005/2006
>   era. I particularly like that she's going to the universities and ask
>   them to teach coding security. This is what they SHOULD have been
>   doing rather than attacking the research community.
>
>   I'm glad that Oracle is now drinking the kool aid and treating
>   security as a fundamental software engineering requirement. It's about
>   time.
>
>   thanks,
>   Andrew van der Stock
>   Lead Author, OWASP Guide to Writing Secure Applications and OWASP Top 10