[SC-L] Bugs and flaws

[Evans, Arian]

Original message bounced due to address; I chopped to remove WMF and rambling
to focus on the subject of language standardization:

[...wmf...]
fyi// on attack surface: http://www-2.cs.cmu.edu/~wing/

Attack surface concepts fit hand-in-glove with threat modeling concepts,
which fit hand in glove with this equivocal design/implementation dialogue.

[...]
Q. What does the bug/flaw dialogue demonstrate the need for?

There's plenty of folks on this list smarter than I am, so it is
nice to see a majority agree on what I think the key issues are:
communicating (a) accurate and (b) actionable data; expanded:

1. Defect Definition
2. Defect Classification
3. Defect Identification
4. Defect Implication (effectively communicating defect implication)

By example I mean (number corresponds to above):

1. Format String, weak crypto use, define what & why are these security defects?
2. Implementation Defect, Design Defect, bug, flaw
3. How do we identify these defects in software?
4. Implication: RTAWV (Risk, Threat, Attack, Weakness, Vuln) & communication
to both technical and non-technical audience is the goal.

I added Weakness at the TRIKE group's suggestion, and it has significantly
helped in classification instead of using two confusing vuln categories.

There is obviously a many-to-one mapping between threat->attack<-weakness
and even from vuln to weakness, depending on how we define vuln. (I have
defined vuln as "a particular instance or attackable instance of a weakness").

This is *valuable* information to the person trying to solve issues in this
problem domain, but I rarely find it well understood by *non-appsec* folks.

(Valuable in the sense that it is easier for non-appsec folks to act on a weakness,
like insufficient output encoding standards/implementation, than a list of 10,000
exploitable URLs in a large templated site representing 4 XSS variants.)

[...]

I continue to encounter equivocal uses of the words Threat, Attack, Vulnerability,
Flaw, Defect, Artifact (and associated phrases like "security-artifact"), Fault,
Bug, Error, Failure, Mistake, MFV (multi-factor vulnerability) in our collective
software security dialogue and literature.

What is the best way to work on establishing a common language? Is it reasonable
or realistic to expect such standardization?

OWASP and WASC have made strides in the webified space on defining attack classes,
and some weak patterns; Mitre has worked terminology in the unmanaged code space.

Where to go from here?

Arian J. Evans
FishNet Security

816.421.6611 [fns office]
816.701.2045 [direct] <--limited access
888.732.9406 [fns toll-free]
816.421.6677 [fns general fax]
913.710.7045 [mobile] <--best bet
aevans at fishnetsecurity.com [email]

http://www.fishnetsecurity.com





> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan
> Sent: Friday, February 03, 2006 2:12 PM
> To: Gary McGraw
> Cc: Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: Re: [SC-L] Bugs and flaws
> 
> 
> Gary McGraw wrote:
> > To cycle this all back around to the original posting, lets 
> talk about
> > the WMF flaw in particular.  Do we believe that the best way for
> > Microsoft to find similar design problems is to do code review?  Or
> > should they use a higher level approach?
> >
> > Were they correct in saying (officially) that flaws such as 
> WMF are hard
> > to anticipate? 
> >   
> I have heard some very insightful security researchers from Microsoft
> pushing an abstract notion of "attack surface", which is the amount of
> code/data/API/whatever that is exposed to the attacker. To design for
> security, among other things, reduce your attack surface.
> 
> The WMF design defect seems to be that IE has too large of an attack
> surface. There are way too many ways for unauthenticated remote web
> servers to induce the client to run way too much code with parameters
> provided by the attacker. The implementation flaw is that the 
> WMF API in
> particular is vulnerable to malicious content.
> 
> None of which strikes me as surprising, but maybe that's just me :)
> 
> 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
>