Gary, Great article and since you used attacks and categories in the same :) sentence I am tempted to ask if you looked at WASC Threat Classification project?
On Tuesday, August 25, 2009, Steven M. Christey <co...@linus.mitre.org> wrote: > > Gary, > > You said in the article: > >>The next category of attacks to expect are attacks that target defects in >>design and architecture - which I call flaws. > > I think it's already happening. I fully expect to see this reflected in > the updated CVE vulnerability trends for 2007/2008, which (fingers > crossed) will be released in the next month or so (OK, most of the flaws > will be in web apps, but still...) > >>we lack a taxonomy of flaws such as the ones we have for bugs (see the >>Seven pernicious kingdoms and the CWE). > > CWE is not just a bug parade, it's also a flaw parade ;-) Although the > parts related to flaws don't > have the depth or specificity that exists for bugs/faults. The > "weaknesses introduced during design" view CWE-701 actually lists 353 > entries. > > http://cwe.mitre.org/data/lists/701.html > > ... although there are a lot of weaknesses that you could argue are bugs. > For example, is path traversal a bug or a flaw? It probably depends on > how file handling is performed within a specific application. Actually, I > think the lines between flaws and bugs/faults can get pretty fuzzy. > > We do want to address CWE's relative lack of depth for flaws, however. > The hierarchy in the research view (CWE-1000) may be the best way to > peruse where CWE stands. I'd love to hear from others who are working in > classification at the flaw level. > > Current areas of promise under CWE are CWE-227 ("API Abuse" which has been > borrowed from Seven Pernicious Kingdoms and given a little more > structure), resource lifecycle issues and control spheres (CWE-664), > external control of critical data/variables/systems/clients (CWE-642), > protection mechanism failures (CWE-693), and even many of the classic > Saltzer-and-Schroeder design principles (CWE-657). It is not coincidental > that these areas still need some work, and any/all input is welcome. Use > the "graph" tab on the individual CWE pages to see the sub-hierarchies. > > Interestingly (or perhaps not), implementation bugs and > design/architecture flaws may share some of the same underlying > fundamental properties. For example, a bug-level action of setting a > variable declaration to "public" instead of "private" has some of the same > properties as a flaw-level action of creating an open socket that anybody > can connect to - you're unintentionally exposing a resource to somebody > who shouldn't have any access to that resource at all. Or, as an example > of a resource lifecycle problem, a use-after-free implementation bug isn't > so different than the flaw in which you continue to use a certificate > after it has expired. > > I suspect that design/architecture level taxonomies will be very > challenging to build. For one part, there's a lot less research in the > area than implementation bugs (at least the research that I'm aware of), > and certainly a lot less public vuln data to draw from (e.g. CVE). There's > a lot of stuff on design but not in any easily-packaged form to build a > taxonomy, and it's often tied to specific technologies. For another, you > have a lot more different perspectives at play. We can look at an > unbounded strcpy and say "well that's clearly a bug" but at the design > level, is the problem "use of a language that supports arbitrary indexing > of arbitrary pointers" or "use of a risky API function that doesn't > perform its own bounds-checking" or "use of a data structure [string] that > does not have expliticly-stated length as a separate field from the > buffer" or "failure to validate input"? (The answer may be "all of the > above" or "it depends on your perspective," but that's where taxonomy > construction gets really hard.) > > I, for one, can't wait. > > - Steve > _______________________________________________ > 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 > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Thanks & Regards, Prasad N. Shenoy _______________________________________________ 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 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
