Bugs and flaws

[jeff.williams at aspectsecurity.com (Jeff Williams)]

At the risk of piling on here, there's no question that it's critical to
consider security problems across the continuum. While we're at it, the
analysis should start back even further with the requirements or even the
whole system concept.

All of the representations across the continuum (rqmts, arch, design, code)
are just models of the same thing.  They start more abstract and end up as
code.  A *single* problem could exist in all these models at the same time.

Higher-level representations of systems are generally eclipsed by lower
level ones fairly rapidly.  For example, it's a rare group that updates
their design docs as implementation progresses. So once you've got code, the
architecture-flaws don't come from architecture documents (which lie). The
best place to look for them (if you want truth) is to look in the code.

To me, the important thing here is to give software teams good advice about
the level of effort they're going to have to put into fixing a problem. If
it helps to give a security problem a label to let them know they're going
to have to go back to the drawing board, I think saying 'architecture-flaw'
or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone
doesn't help distinguish it from 'bug' in the minds of most developers or
architects.

--Jeff

Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Wednesday, February 01, 2006 5:07 PM
To: John Steven
Cc: Will Kruse; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws

John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but
here
> goes:
>   
We'll let the moderator decide that :)

> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a blurry one, and certainly slippery as you move from 'left' to
'right'.
>   
Cool.

> But, we all should understand that there's commensurate blur in our
analysis
> techniques (aka architecture and code review) to assure that as we sweep
> over software that we uncover both bugs and architectural flaws.
>   
Also agreed.

> 2) Flaws are different in important ways bugs when it comes to
presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
>   
I disagree with the word usage. To me, "bug" and "flaw" are exactly
synonyms. The distinction being drawn here is between "implementation
flaws" vs. "design flaws". You are just creating confusing jargon to
claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
::= bug. A vulnerability is a special subset of flaws/defects/bugs that
has the property of being exploitable.

> I nearly fell through one of my consultant's tables as I leaned on it this
> morning. We explored: "Bug or flaw?".
>   
The wording issue aside, at the implementation level you try to
code/implement to prevent flaws, by doing things such as using higher
quality steel (for bolts) and good coding practices (for software). At
the design level, you try to design so as to *mask* flaws by avoiding
single points of failure, doing things such as using 2 bolts (for
tables) and using access controls to limit privilege escalation (for
software).

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
        Olympic Games: The Bi-Annual Festival of Corruption

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php