Re: [SC-L] Economics of Software Vulnerabilities
In my opinion, though fuzz testing is certainly a useful technique (we've used it in hardware verification for years), any certification based solely on fuzz testing for security would be ludicrous. Fuzz testing is not a silver bullet. The biggest stumbling block for software certification is variability in final environment. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -Original Message- From: Gadi Evron [mailto:[EMAIL PROTECTED] Sent: Mon Mar 12 21:48:25 2007 To: Crispin Cowan Cc: [EMAIL PROTECTED]; Ed Reed; sc-l@securecoding.org Subject:Re: [SC-L] Economics of Software Vulnerabilities On Mon, 12 Mar 2007, Crispin Cowan wrote: Ed Reed wrote: For a long time I thought that software product liability would eventually be forced onto developers in response to their long-term failure to take responsibility for their shoddy code. I was mistaken. The pool of producers (i.e., the software industry) is probably too small for such blunt economic policy to work. I'm not sure about the size of the pool. I think it is more about the amount of leverage that can be put on software: * It is trivial for some guy in a basement to produce a popular piece of open source software, which ends up being used as a controlling piece of a nuclear reactor, jet airplane, or automobile, and when it fails, $millions or $billions of damages result. The software author has no where near the resources to pay the damage, or even the insurance premiums on the potential damage. * In contrast, with physical stuff it is usually the case that the ability to cause huge damage requires huge capital in the first place, such as building nuclear reactors, jet planes, and cars. With this kind of leverage, the software producers don't have the resources to take responsibility, and so strict liability applied to authors reduces to don't produce software unless, possibly, you work for a very large corporation with deep pockets. Even then, corporate bean counters would likely prevent you from writing any software because the potential liability is so large. It appears, now, that producers will not be regulated, but rather users and consumers. SOX, HIPAA, BASEL II, etc. are all about regulating already well-established business practices that just happen to be incorporating more software into their operations. Much like the gun industry. Powerful, deadly tools that, if used inappropriately, can cause huge damage. Indeed, and I found your posts enlightening. Still, today an alternative presentsitself in the now more likely realm of software security certification and testing. It has become more easier and potentially regulated now that fuzzers have become: 1. Good enough. 2. Measurable. 3. Widely accessible. Gadi. ___ 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. ___ This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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] Economics of Software Vulnerabilities
Hi crispy, I'm not sure vista is bombing because of good quality. That certainly would be ironic. Word on the way down in the guts street is that vista is too many things cobbled together into one big kinda functioning mess. My bet is that Vista SP2 will be a completely different beast. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -Original Message- From: Crispin Cowan [mailto:[EMAIL PROTECTED] Sent: Mon Mar 12 20:45:43 2007 To: Ed Reed Cc: sc-l@securecoding.org Subject:Re: [SC-L] Economics of Software Vulnerabilities Ed Reed wrote: For a long time I thought that software product liability would eventually be forced onto developers in response to their long-term failure to take responsibility for their shoddy code. I was mistaken. The pool of producers (i.e., the software industry) is probably too small for such blunt economic policy to work. I'm not sure about the size of the pool. I think it is more about the amount of leverage that can be put on software: * It is trivial for some guy in a basement to produce a popular piece of open source software, which ends up being used as a controlling piece of a nuclear reactor, jet airplane, or automobile, and when it fails, $millions or $billions of damages result. The software author has no where near the resources to pay the damage, or even the insurance premiums on the potential damage. * In contrast, with physical stuff it is usually the case that the ability to cause huge damage requires huge capital in the first place, such as building nuclear reactors, jet planes, and cars. With this kind of leverage, the software producers don't have the resources to take responsibility, and so strict liability applied to authors reduces to don't produce software unless, possibly, you work for a very large corporation with deep pockets. Even then, corporate bean counters would likely prevent you from writing any software because the potential liability is so large. It appears, now, that producers will not be regulated, but rather users and consumers. SOX, HIPAA, BASEL II, etc. are all about regulating already well-established business practices that just happen to be incorporating more software into their operations. Much like the gun industry. Powerful, deadly tools that, if used inappropriately, can cause huge damage. Use appropriately may be part of the key here. If you use your car improperly and kill people as a result of e.g. your drunk driving, then the car maker is not responsible. OTOH, if the design of your top-heavy SUV combined with crappy tires results in rollovers, then courts do hold the vendors responsible. The problem with software: what is appropriate? Conceptually, that the software in question has been sufficiently vetted for quality to justify the risk involved. Efforts to do that kind of thing are used in select industries (nukes and planes) but not widely, because the cost of vetting is huge, so it only is used when the liabilities are huge. Why? Because software metrics suck. 30 years of software engineering research, and LOC is still arguably one of the best metrics of software complexity, and there is almost nothing usable as a metric for software quality. It is not that no one has tried; lots of RD goes into software engineering. Its not that there are no new ideas; lots of those abound. Its not that there has been no advances in understanding; we know a lot more about the problem than we used to. I think it is just that it is a hard problem. Software, by its nature, is vastly more complex per pound :) ^W^W per unit person effort than any other artifact mankind has ever produced. One developer in one month can produce a functional software artifact that it would take a hundred people 10 years to verify as safe. With those ratios, this problem will not fall easily. But as with other serious security policy formulations - the technology is irrelevant. The policies, whether SOX or Multi-level Security, are intended to protect information of vital importance to the organization. If technical controls are adequate to enforce them - fine. If not, that in no way absolves the enterprise of the need to provide adequate controls. Sure it does :) Just show that your organization performed due diligence that is up to industry standards and the fact that you failed pretty much does absolve you, in the eyes of the likes of SOX and Basil. It is a very interesting transition from trying to hold software vendors liable to trying to hold deploying organizations liable, but this first round of regulation looks like a sinecure for compliance consultants and a few specialty vendors,and not much else. The computer software industry has lost its way. It appears to be satisfied with prodding and encouraging software developers to develop some modicum
Re: [SC-L] Economics of Software Vulnerabilities
On Tue, 13 Mar 2007, Gary McGraw wrote: In my opinion, though fuzz testing is certainly a useful technique (we've used it in hardware verification for years), any certification based solely on fuzz testing for security would be ludicrous. Fuzz testing is not a silver bullet. Fuzzing is indeed, most definitely, not a or the silver bullet, nor should testing be based on itsolely. What it does provide us with is a measurable fashion by which we can reliably test the: 1. Stability 2. Programming quality 3. Robustness Of software, to a level which is much higher than employing several reverse engineers and test engineers (not to say just examining vulnerability history on the bugtraq archive). Further, if not by certification, fuzzing has already shown it can pressure companies to use software development lifecycle methodologies and that way enforcing (encouraging?) better security with partners (read Microsoft). Fuzzing has also shown that it can be used to force vendors who sell to you to indeed be tested by certain products (read large Telcos). Although I am unsure if this approach holds water. The re-emergence of this field beyond rubber stamp certifications or very costly certifications, is something I see as very positive. That, of course, if not a or the sulver bullet in any way, either, but maybe we will see less input validation bugs around and will start facing logical flaws that will boggle our minds. Personal opinion: enough with buffer overflows already, no? :) The biggest stumbling block for software certification is variability in final environment. That makes sense, but I figure if we can eliminate some more by a factor in our testing environment(s), all the better. gem Gadi. -- beepbeep it, i leave work, stop reading sec lists and im still hearing gadi - HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March 2007. ___ 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] Darkreading: compliance
On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me): no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. I heartily agree. Compliance almost always becomes (in the worst sense of the word) a mantra to chant down all disagreement. Compliance becomes the *administrative* stick-and-carrot, rather like a driver's license in the US. That is, every US citizen has this set of nominal rights that nobody can take away. On the other hand, a driver's license is a privilege, so you have to jump through some hoops to get it, and it comes with mandatory behaviors, not all of them legal, most of them administrative. Life in the US without a driver's license is marginal. So, administrators use driver's licenses to punish and guide behavior in ways nominally, or legally, forbidden. Wink wink, nudge nudge. I'm most familiar with PCI, and some of the things that people put in it are just downright stupid. If you run your credit card processing on Solaris, why should you put in a virus scanner? Seriously, folks... Since compliance becomes an administrative tool, the weapons against actually paying for compliance become administrative, hence the focus on meeting checklist items. A checklist can't really contain all the capability of a general purpose computing system, as checklists do not have looping or decision making in them. So, they'll always have weird limits, and people will try to overcome those limitations by adding to the checklists. Compliance becomes a rallying point for the professional meeting attenders, parasites and hangers on, hierarchy jockeys. ___ 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] Information Protection Policies
On Mar 9, 2007, at 5:27 PM, McGovern, James F ((HTSC, IT)) wrote: Ken, in terms of a previous response to your posting in terms of getting customers to ask for secure coding practices from vendors, wouldn't it start with figuring out how they could simply cut-and- paste InfoSec policies into their own? Using someone's boilerplate policies as a starting point is great, as long as they go beyond just infosec policies and include examples/ guidelines for writing contracts for outsourcing software development and acquisition. Steve Christey pointed to OWASP's example at http://www.owasp.org/ index.php/OWASP_Secure_Software_Contract_Annex. While I haven't (yet) looked at this AND while I'm certainly no authority on contract writing, I'd bet that this OWASP example will at least provide some pretty good food for thought for anyone who is contracting software development. I firmly believe that we as consumers and as a whole, are not doing an adequate job at demanding more in the way of software security from the software we purchase and outsource. IMHO, that shouldn't be horribly difficult to change in the short- to medium-term. Better contracts and contractor oversight (e.g., independent architectural risk analysis, static code analysis, and rigorous security testing) should go a long way. I know I'm over-simplifying things here, but still... Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com 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. ___
Re: [SC-L] Darkreading: compliance
Once again i'll ask. Which vertical is the kind of company where you're seeing this awful behavior in? BTW, sammy migues agrees with you in a thread we're having on the justice league blog www.cigital.com/justiceleague (look under SOX). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com. -Original Message- From: Bruce Ediger [mailto:[EMAIL PROTECTED] Sent: Tue Mar 13 12:10:42 2007 To: Cc: SC-L@securecoding.org Subject:Re: [SC-L] Darkreading: compliance On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me): no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. I heartily agree. Compliance almost always becomes (in the worst sense of the word) a mantra to chant down all disagreement. Compliance becomes the *administrative* stick-and-carrot, rather like a driver's license in the US. That is, every US citizen has this set of nominal rights that nobody can take away. On the other hand, a driver's license is a privilege, so you have to jump through some hoops to get it, and it comes with mandatory behaviors, not all of them legal, most of them administrative. Life in the US without a driver's license is marginal. So, administrators use driver's licenses to punish and guide behavior in ways nominally, or legally, forbidden. Wink wink, nudge nudge. I'm most familiar with PCI, and some of the things that people put in it are just downright stupid. If you run your credit card processing on Solaris, why should you put in a virus scanner? Seriously, folks... Since compliance becomes an administrative tool, the weapons against actually paying for compliance become administrative, hence the focus on meeting checklist items. A checklist can't really contain all the capability of a general purpose computing system, as checklists do not have looping or decision making in them. So, they'll always have weird limits, and people will try to overcome those limitations by adding to the checklists. Compliance becomes a rallying point for the professional meeting attenders, parasites and hangers on, hierarchy jockeys. ___ 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. ___ This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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] Information Protection Policies
There is a text box in Software Security about this with some language I copied (with permission) from jack danahy of ounce labs. www.swsec.com gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -Original Message- From: Kenneth Van Wyk [mailto:[EMAIL PROTECTED] Sent: Tue Mar 13 12:23:16 2007 To: Secure Coding Subject:Re: [SC-L] Information Protection Policies On Mar 9, 2007, at 5:27 PM, McGovern, James F ((HTSC, IT)) wrote: Ken, in terms of a previous response to your posting in terms of getting customers to ask for secure coding practices from vendors, wouldn't it start with figuring out how they could simply cut-and- paste InfoSec policies into their own? Using someone's boilerplate policies as a starting point is great, as long as they go beyond just infosec policies and include examples/ guidelines for writing contracts for outsourcing software development and acquisition. Steve Christey pointed to OWASP's example at http://www.owasp.org/ index.php/OWASP_Secure_Software_Contract_Annex. While I haven't (yet) looked at this AND while I'm certainly no authority on contract writing, I'd bet that this OWASP example will at least provide some pretty good food for thought for anyone who is contracting software development. I firmly believe that we as consumers and as a whole, are not doing an adequate job at demanding more in the way of software security from the software we purchase and outsource. IMHO, that shouldn't be horribly difficult to change in the short- to medium-term. Better contracts and contractor oversight (e.g., independent architectural risk analysis, static code analysis, and rigorous security testing) should go a long way. I know I'm over-simplifying things here, but still... Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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] Darkreading: compliance
On 3/14/07, Gary McGraw [EMAIL PROTECTED] wrote: Once again i'll ask. Which vertical is the kind of company where you're seeing this awful behavior in? well, fwiw, i've noticed it in finance/investment, and the entertainment industries. but i honestly don't think the industry type makes a whole lot of difference. it's a corporate management thing. BTW, sammy migues agrees with you in a thread we're having on the justice league blog www.cigital.com/justiceleague (look under SOX). gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com. -Original Message- From: Bruce Ediger [mailto:[EMAIL PROTECTED] Sent: Tue Mar 13 12:10:42 2007 To: Cc: SC-L@securecoding.org Subject:Re: [SC-L] Darkreading: compliance On Tue, 13 Mar 2007, somebody wrote (attribution isn't clear to me): no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. I heartily agree. Compliance almost always becomes (in the worst sense of the word) a mantra to chant down all disagreement. Compliance becomes the *administrative* stick-and-carrot, rather like a driver's license in the US. That is, every US citizen has this set of nominal rights that nobody can take away. On the other hand, a driver's license is a privilege, so you have to jump through some hoops to get it, and it comes with mandatory behaviors, not all of them legal, most of them administrative. Life in the US without a driver's license is marginal. So, administrators use driver's licenses to punish and guide behavior in ways nominally, or legally, forbidden. Wink wink, nudge nudge. I'm most familiar with PCI, and some of the things that people put in it are just downright stupid. If you run your credit card processing on Solaris, why should you put in a virus scanner? Seriously, folks... Since compliance becomes an administrative tool, the weapons against actually paying for compliance become administrative, hence the focus on meeting checklist items. A checklist can't really contain all the capability of a general purpose computing system, as checklists do not have looping or decision making in them. So, they'll always have weird limits, and people will try to overcome those limitations by adding to the checklists. Compliance becomes a rallying point for the professional meeting attenders, parasites and hangers on, hierarchy jockeys. ___ 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. ___ This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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. ___ -- mike 00110001 3 00110111 ___ 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. ___
