I think that you are spot on, and people are sooner than later going to be demanding that, as a by-product of our shrinking economic reality.
Take this example (not to stir up a semantic pissing match): "Insufficient Input Validation" I get it. I understand the importance of it. But it is not clear to a business owner or C level what that means to execute on. It is fairly ambiguous, especially in Web 2.0 world, what that really means. And often you find in the slippery slope between design and pattern issues, and implementation-level defects, that your fundamental data/function boundary problem is *not* best solved/enforced via input validation. In the case where the ideal solution to enforce a data/function boundary is parameterized sql, or encoded output (or a separate data/control channel), IV in this case simply functions as an attack surface reduction mechanism and the costs associated in defining and enforcing what may be loosely typed data by requirement, can be negligible at best. Obviously this is highly contextual and YMMV on that slippery slope between changing a fundamental design to fixing singular implementation errors. Architecture will play a huge key in figuring cost. But if I have to "pick one" in a "weak data access" scenario: 1) Stronger IV/data typing (before queries are built) 2) Parameterized SQL or abstracted data access layer 3) Principle of least privilege definition and strict CRUD enforcement (by objects accessing data) We would all like to know which has the most return. I think that will be tough though. I've found cases where some simple CRUD tweaking mitigated all negative impact to successful syntax attacks. And I've found cases where it did not help at all, or due to design, simply was not possible to make meaningful priv separations. How's that for a verbose "Yes"? Good questions. ciao -- Arian Evans "I ask, sir, what is the militia? It is the whole people. To disarm the people is the best and most effectual way to enslave them." -- Patrick Henry On Wed, Jan 28, 2009 at 3:20 PM, Steven M. Christey <co...@linus.mitre.org> wrote: > > In the past year or so, I've been of a growing mindset that one of the > hidden powers of CWE and other weakness/bug/vulnerability/attack > taxonomies would be in evaluating secure coding practices: if you do X and > Y, then what does that actually buy you, in terms of which vulnerabilities > are fixed or mitigated? We capture some of that in CWE with CAPEC > mappings for attacks. > > We've also mapped to the CERT C Secure Coding standard, as reflected in > this CWE view: http://cwe.mitre.org/data/graphs/734.html (for the > complete/detailed listing, click the "Slice" button on the upper right and > sift through the Taxonomy Mappings). Or, check out the coverage graphs > that show where the coding standard fits within the two main CWE > hierarchical views: http://cwe.mitre.org/data/pdfs.html > > Now Microsoft has released a paper that shows how their SDL practices > address the Top 25, like they did when the OWASP Top Ten came out. To me, > this seems like a productive practice and a potential boon to consumers, > *if* other vendors adopt similar practices. Are there ways that the > software security community can further encourage this type of thing from > vendors? Should we? > > Gary, do your worst ;-) > > http://blogs.msdn.com/sdl/archive/2009/01/27/sdl-and-the-cwe-sans-top-25.aspx > > - 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. > _______________________________________________ > _______________________________________________ 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. _______________________________________________