Re: [SC-L] informIT: attack categories
hi sc-l, Fred sent me some email today and reminded me that he has written about this idea himself in IEEE Security Privacy magazine. We already had a link to his article on the Silver Bullet website, but here's a direct link: The Monoculture Risk Put in Context IEEE Security and Privacy 7, 1 (January/February 2009), 14-17. Fred Schneider and Ken Birman. http://www.cs.cornell.edu/fbs/publications/IEEEspMonoculture.pdf gem On 8/25/09 1:35 PM, gem g...@cigital.com wrote: hi sc-l, If you listened recently to the latest episode of Silver Bullet with Fred Schneider from Cornell http://www.cigital.com/silverbullet/show-041/, one of the ideas Fred and I discussed was the notion of attack categories and anticipating large scale trends in attack space. Hopefully you guys all recall that I am a strong proponent of understanding the attacker's perspective (see, for example Exploiting Software from way back in 2004 where Hoglund and I coined the term attack pattern http://exploitingsoftware.com/). This month's informIT article is about the notion of long term attack categories and is meant to inform software security research: Software [In]security: Attack Categories and History Prediction http://www.informit.com/articles/article.aspx?p=1393066 BTW, shout outs for the OWASP top 10 and CWE in the article may surprise the usual nay sayers. Feedback is most welcome. (Thanks to Ken and Sammy for helping me make this article slightly more coherent.) gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/justiceleague book www.swsec.com ___ 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. ___ ___ 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. ___
Re: [SC-L] informIT: attack categories
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. ___
Re: [SC-L] informIT: attack categories
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. ___
Re: [SC-L] informIT: attack categories
At 6:36 PM -0400 8/25/09, Steven M. Christey 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 think it has been happening for years. I use Microsoft Word V5.1a from 1992, because Microsoft followed that with Word 6.0 which introduced the design defect allowing Macro Viruses. Of course this was not actually an innovation, as IBM had previously introduced _and_withdrawn_ a similar vulnerability in their CMS operating environment (the mail program would automatically call a text formatter which could call the operating system under the direction of the sender. Those who do not study history are condemned to repeat it. -- Larry Kilgallen ___ 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. ___
