hi kevin, I completely agree that bugs and flaws exist as two categories (with a slippery slope between them) outside of security. It is important that we focus on both kinds of defect since the narrative in software security has mostly been about the bug parade. (See Getting Past the Bug Parade <http://www.informit.com/articles/article.aspx?p=1248057> (September 17, 2008)).
In my experience, there seem to be three kinds of categories that flaws tend to clump into: * flaws on "the list" (see STRIDE...or your own list of historical flaws) ex. attacker-in-the-middle attacks * ambiguities in the specs (here I agree with your assessment of #2)...I think that errors of omission go here FWIW * problems with dependencies (lots more of these in Framework-land than there used to be) Requirements would be nice. Sadly, not enough software products actually use requirements even though the people in Pittsburgh would like us to pretend that they do. (Your mileage may vary, etc.) gem On 7/21/11 10:40 AM, "Wall, Kevin" <kevin.w...@qwest.com> wrote: >Gary McCraw wrote: >> This month's informIT article covers the zombies: >[snip] >> * Software security defects come in two main flavors‹bugs at the >>implementation level (code) and flaws at the architectural level (design) > >So, two questions: >1) How is this (software *security* defects) different than any other >software defect? > It seems to me that these are also 2 main categories of software >defects in general. > >2) In terms of "flavors", where do you see software security defects >arising from either incorrect > requirements or simply lack of specifications? > >My experience with #2 is that poor specifications are a major contributor >to software >security defects, more so even than with software defects in general. >That's because generally >these specs are usually considered "non-functional requirements" and they >get missed >more by systems analysts simply because they are not something that the >business >wants and therefore they aren't put into the reqts and thus never get >built. > >I'm not talking about the pseudo-PCI-like requirements that says things >like making >sure that you have no OWASP Top Ten vulnerabilities, but rather actual >omission >of requirements such as failure to specify that data must be kept >confidential, >or to access this data requires authorization by a certain role, or that >an audit >trail must be required for certain actions, etc. > >I don't see how you can chalk these sorts of defects up to flaws at the >architecture level (unless you and I have drastically different views of >system architecture). The are outright omissions in the specifications >and because they are not there, the application team never even thinks >about building in that functionality. Bottom line: I think you are >missing >a "flavor". > >Thanks, >-kevin >-- >Kevin W. Wall 614.215.4788 Qwest Risk Management / Information >Security Team >Blog: http://off-the-wall-security.blogspot.com/ >"The most likely way for the world to be destroyed, most experts agree, >is by accident. That's where we come in; we're computer professionals. >We *cause* accidents." -- Nathaniel Borenstein, co-creator of MIME > > >This communication is the property of Qwest and may contain confidential >or >privileged information. Unauthorized use of this communication is strictly >prohibited and may be unlawful. If you have received this communication >in error, please immediately notify the sender by reply e-mail and destroy >all copies of the communication and any attachments. _______________________________________________ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
