On Tue, 12 Apr 2011, Gary McGraw wrote:
Here is an article about Vendor Control and the BSIMM that introduces a very simple attestation-based scheme Sammy and I have developed called vBSIMM. Jim has been in the loop throughout ideation and writing and endorses the approach: http://www.informit.com/articles/article.aspx?p=1703668
I'm really glad to see this. It's a great start. BSIMM is important, but it's huge, and I've strongly suspected that some activities aren't as influential as others for directly improving software security (e.g. the activity related to the vendor's "marketing" their own expertise). Starting with just a subset of these activities should make BSIMM accessible to more vendors and consumers.
One big question is whether any vendors will self-attest, and if so, who would maintain a repository of these self-attestations. I would love to see that happen.
Don't forget to compare this in your mind to the alternative which seems to be looking for certain bugs in a particular app, one app at a time.
There is a continued disconnect between BSIMM, which lists proactive activities that vendors have adopted without explicit proof of the efficacy of those practices, and top-N lists, which admittedly set a low bar (which many developers still fail to meet regularly). If a vendor's "halo" activity of a custom top-N list in vBSIMM does not account for CSRF or XSS, say, and the software consumer is a web shop, then this is most likely a problem for the consumer. (After all, there's no real guarantee that a vendor's SSG has sufficient skill or experience).
To use the nutrition-labeling analogy, if I'm buying a snack from a producer that follows strict protocols that minimize the environmental impact and have almost-zero amounts of rat droppings, that might give me a warm fuzzy feeling, but I'd also want to know if the snack contains 3 days' worth of saturated fat and cholesterol in one serving.
We are still a while away from quantifying the "inherent security" of a deployed software application, then tying this "security" back to developer activities to determine which activities are the most effective.
In this context, general-purpose Top-N lists still have a role as one part of a larger system of checks and balances. Certain development practices are believed (rightly or wrongly) to lead to more secure software; general-purpose Top-N lists become one mechanism for verifying whether those claims hold water, at least in terms of the *absence* of common vulnerabilities.
By the way, CWE and SANS will be doing a 2011 Top 25, which is expected to support a variety of customized Top-N sublists. This will be informed by our active development of the customization features of the Common Weakness Scoring System (CWSS), which allows users to modify scores based on business-value concerns.
- 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
