[SC-L] Darkreading: compliance
hi sc-l, this month's darkreading column is about compliance. my own belief is that compliance has really helped move software security forward. in particular, sox and pci have been a boon: http://www.darkreading.com/document.asp?doc_id=119163 what do you think? have compliance efforts you know about helped to forward software security? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.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
Maybe it depends on the vertical? What vertical(s) did you find it a distraction in? gem -Original Message- From: Michael Silk [mailto:[EMAIL PROTECTED] Sent: Mon Mar 12 17:34:56 2007 To: Gary McGraw Cc: SC-L@securecoding.org Subject:Re: [SC-L] Darkreading: compliance On 3/13/07, Gary McGraw [EMAIL PROTECTED] wrote: hi sc-l, this month's darkreading column is about compliance. my own belief is that compliance has really helped move software security forward. in particular, sox and pci have been a boon: http://www.darkreading.com/document.asp?doc_id=119163 what do you think? have compliance efforts you know about helped to forward software security? no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.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. ___ -- mike 00110001 3 00110111 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/13/07, Gary McGraw [EMAIL PROTECTED] wrote: hi sc-l, this month's darkreading column is about compliance. my own belief is that compliance has really helped move software security forward. in particular, sox and pci have been a boon: http://www.darkreading.com/document.asp?doc_id=119163 what do you think? have compliance efforts you know about helped to forward software security? no. my feeling is that it focuses management on unimportant things like meeting checkpoints rather then actually doing useful things. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.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. ___ -- 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. ___
Re: [SC-L] Darkreading: compliance
what do you think? have compliance efforts you know about helped to forward software security? Compliance brings accountability. Without accountability or financial impact people have little incentive for putting security on the priority list. I for one welcome our compliance overlords. Regards, - Robert Auger http://www.cgisecurity.com Application Security news and more http://www.webappsec.org/ company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.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. ___ ___ 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
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 of shame for the shoddy quality of their output. Feed the beast, and support rampant featurism - its what's made so many people rich, after all. The consumers who chose feature-rich over high-quality did that, not the software industry. In the long run, though, featurism without quality is not sustainable. That is certainly true, and I applaud efforts to encourage developers to rise up from their primordial ooze and embrace the next steps in sane programming (we HAVE largely stamped out self-modifying code, but strcpy() is still a problem...) I beg to differ. There is no evidence at all that the good enough modality is
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. ___
