Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors
Hi Chris, You certainly have a point. There are occasional stories on software security that are not disaster coverage or top ten's, but not enough (sample from this set: http://www.cigital.com/~gem/press/). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 1/13/09 11:08 PM, Chris Wysopal cwyso...@veracode.com wrote: The only attention software security seems to get in the mainstream press beyond the bug or attack of the day is from top X lists. That alone makes them worthwhile. They definitely steer the conversation in the right direction. I think everyone involved in creating and promoting top X lists believes they are a conversation starter and not an end game for software security. We just have to make sure the rest of software security follows. -Chris -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Gary McGraw Sent: Tuesday, January 13, 2009 4:50 PM To: Secure Code Mailing List Subject: Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors hi sc-l, There are some important good things about top ten lists that are worthy of mention. The notion of knowing your enemy is essential in security (as it is in warfare), and top ten lists can help get software people started thinking about attacks, attackers, and the vulnerabilities they go after. These days almost any attention paid to the problem is good attention, and the fact that the the tech press is paying attention to software security at all is a good thing. Top ten lists help in that respect. But, I am really worried about these kinds of lists and I wrote up my worries in an article that was just posted: Top Eleven Reasons Why Top 10 (or Top 25) Lists Don't Work http://www.informit.com/articles/article.aspx?p=1322398 I thought you might get a kick out of it. gem http://www.cigital.com/~gem ___ 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] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors
hi sc-l, There are some important good things about top ten lists that are worthy of mention. The notion of knowing your enemy is essential in security (as it is in warfare), and top ten lists can help get software people started thinking about attacks, attackers, and the vulnerabilities they go after. These days almost any attention paid to the problem is good attention, and the fact that the the tech press is paying attention to software security at all is a good thing. Top ten lists help in that respect. But, I am really worried about these kinds of lists and I wrote up my worries in an article that was just posted: Top Eleven Reasons Why Top 10 (or Top 25) Lists Don't Work http://www.informit.com/articles/article.aspx?p=1322398 I thought you might get a kick out of it. gem http://www.cigital.com/~gem ___ 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] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors
On Tue, 13 Jan 2009, Gary McGraw wrote: I thought you might get a kick out of it. I did! :-) Always good to have debates. Executives don't care about technical bugs No, but they do what PCI says they have to (i.e. listen to the OWASP Top Ten). They do care about the bottom line. They hate buying software and finding out how crappy it is afterward. The Siemens example comes to mind. It was mind-boggling to me to hear that they were forced to pay 150% of the original cost just to get the software they bought in a secure form. http://www.networkworld.com/news/2009/011209-software-security-effort.html?page=2 Too much focus on bugs. The Top 25 has 4 or 5 items that are clearly design-related, maybe more if you think that improper input validation is related to design, and still more if you count all the external control items which may be implementation or design depending on who's talking and what the programmer's responsibilities are. The Top 25 even has a couple classic Saltzer-and-Schroeder examples in there (rephrased to avoid the incredible confusion and misinterpretation that has gone on with the original SS). Vulnerability lists help auditors more than developers. Agree - except the Top 25 has anywhere from 3 to 10 specific mitigations/preventions for each CWE. And whether we like it or not, auditors help to drive change. Maybe not the optimal change, but they drive change. Also - when the developers' software managers are told by their marketers that they could lose many, then the managers will figure out how to get the developers to improve. Long-term thinking here - I know, that's not allowed for this industry. One person's top bug is another person's yawner. Absolutely, a point I brought up in the other post I made to SC-L on some interesting challenges. Using bug parade lists for training leads to awareness but does not educate. Yep - which is why we want universities to get cracking, and if the Top 25 helps to prod them on, then so be it. Bug lists change with the prevailing technology winds. Yep - which is why the official name of the Top Ten begins with 2009. We'll do this again next year. Top ten lists mix levels. Also brought up in my last email as a problem for the industry in general. Regarding Seven Pernicious Kingdoms - how does the Top 25 map to them? I could classify most of the Top 25 in multiple categories. Should poor output encoding be put under the Input validation kingdom? Sounds kind of like using the Start button in Windows to shut down ;-) Should cleartext transmission be put under Environment? or Security Features? Again, we *all* have this problem. Automated tools can find bugs . let them. Yes, and a lesson of the Top 25 (that we all already know) is that when people start to apply it, they'll see how a tool won't be a silver bullet. Also covered in my last email... When it comes to testing, security requirements are more important than vulnerability lists. Which is cover a teeny bit in the other email I sent. Also, New York State has put up draft text that mentions the Top 25 as part of a condition for acquisition. Is that enough? Hardly. But things like the Black/Williams software facts label aren't mature either, and Dept. of Homeland Security probably has a couple years to go before their work on assurance cases begins to take shape. Ten is not enough. Neither is 25. Number 26 (another design issue) is also mentioned in the other email I posted. I'm of the mindset that the Top 25 is, short-term, an awareness tool for developers and for customers. In the longer term, maybe it will be a little blip on the road to actionable software assurance. Given that approximately 1000 people have created delicious bookmarks for it, and I've alread seen comments from a couple developers hey, we should go check this out - then we are already seeing some success. Gary, it might seem ironic since I am leading the most comprehensive bug parade out there in CWE, but I agree with you that just following the bug parade is not enough. The Top 25 is a means to an end, and not the end itself. Only time will tell, though. - 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] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors
CVE - http://cve.mitre.org/ known problems known systems CWE - http://cwe.mitre.org/ classes of problems unknown systems http://cwe.mitre.org/top25/ Will business start to talk CWE as they already talk CVE? Discussion/Debate/Thoughts Tom Brennan -Original Message- From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On Behalf Of Kenneth Van Wyk Sent: Monday, January 12, 2009 2:30 PM To: Secure Coding Subject: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors FYI, a top 25 programming errors list from the folks at SANS has been released. See the following for details: http://www.sans.org/top25errors/ Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.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. ___
Re: [SC-L] SANS Institute - CWE/SANS TOP 25 Most Dangerous ProgrammingErrors
Tom, From the business' point of view, they really don't care if widget X has weaknesses, they want to know how to make money by buying and using widget X. They assume X is safe by default, even though it's not. They've been doing fast and crappy for so long, and made heaps of money from it, that it's a hard sell in many places to do the safer thing until the horse has bolted. The only examples where folks buy widget X over widget Y is those folks in operational risk who have to make a financial allowance for a probable risk difference between X and Y. For example, if one satellite launch system blows up one time every four launches, and another blows up one time every eight launches, you'd go with the second or you'd have to budget for the likelihood of having to replace your satellite a bit more with the first one. In our industry, we have still yet to make a compelling, measurable and thus believable case that there's a TCO benefit from buying more expensive, but safer software. Most folks believe all software is safe, despite the fact that it is not. Until that time, CWE and similar *weakness* patterns are a derivative of the actual cost of ownership, and not the actual benefits. That's why I've gone gung ho into build it right the first time mode. I doubt we'll get the accurate metrics required for proof that safer software is cheaper (over time), so it's best that we simply get safer software - period. That's why I will be working with the frameworks and code repositories rather than the 0day crowd. In my view, there is zero value in vulnerability disclosure, discussion, or discovery. It's like shooting fish in a barrel. thanks, Andrew Will business start to talk CWE as they already talk CVE? Discussion/Debate/Thoughts Tom Brennan ___ 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. ___
