Hi James,You're absolutely correct - trying to come up with countermeasures for 730+ issues is crazy. It's much better to have valid controls for the minimum number of things that must be done right, and if they are, then hey presto, attacks using one or more of those 730+ vulnerability classifications either do not work, do no to little damage, and may be even trigger an intrusion escalation procedure.
I have never seen the point of most of the security attack "research" going on up to this point: knowing about attacks in software ("hey ISV, you've got a security 0 day here! Look at me! Look at me! I'm more important than the guys who write this stuff! No look at me, I'm so cool!"). Such venal self promotion does not protect that software. Secure apps can only come about about the other way around, and only if the architects and devs know what they have to do. That's why I've been on the front end of the development process for a long time.
To that end, I've been working on the OWASP Secure Coding Standard for a little while now. It'll be the 16 or so categories of things you MUST, SHOULD and MAY do well to write secure software depending on a risk assessment of your apps data asset classification and processes. I'm designing it to be scalable from single developer self assessed open source projects through to major project teams, and plus, I'm making very few things "MUST" and ensuring the outcome can be detected in multiple ways. The end result should a technically more secure system that avoids most of the 730+ CWE issues by doing as little work as possible, but what work is done is effective.
The Coding Standard will be the Standards portion of the piece ("thou shalt..."), whereas the Developer Guide will be more "This is how you do X well". Both will reflect the forthcoming OWASP Application Security Verification Standard (ASVS), which links into Dana's post about auditing code for evidence of security.
So essentially:1. Coding Standard -> Things you have to do, should be an annex to the contract 2. Developer Guide -> How to do the things noted in the Coding Standard, which the architects and developers can refer to over the sprints and milestones. Not enforceable per se - it's more of a dictionary of "the right way to do it" 3. ASVS -> How to verify that the code or app you've received is compliant with #1, and should be an annex to the contract as well, so it can be formally verified using automated and manual testing techniques both by the developer and the receiver of the software.
thanks, Andrew On Nov 30, 2008, at 12:44 PM, McGovern, James F (HTSC, IT) wrote:
Enumerating all of the potential weaknesses in software as a requirement to be put into a contract is somewhat problematic on several levels. I guess you can take something like CWE as a starting point and filter down the headers to thinks that only apply to your particular implementation. A better approach would be to filter providers based on security before you even get to the contract stage. For example, ask if they would be willing to procure a copy of a static analysis tool from a vendor such as Ounce Labs, Coverity, etc and then check on the backside to see how many seats they have purchased (e.g. reference check).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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. _______________________________________________
