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 [EMAIL PROTECTED] [email] http://www.fishnetsecurity.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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@securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
