hi steve, The bugs/flaw continuum is, in fact, a continuum. It's great that you guys have begun to collect and publish information about flaws in the CWE. I agree completely with your statement "I suspect that design/architecture level taxonomies will be very challenging to build."
Part of what Fred is trying to spark with his work is some research funding for that area. gem On 8/25/09 6:36 PM, "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. _______________________________________________