Re: [SC-L] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
On Nov 29, 2007 6:07 PM, Blue Boar <[EMAIL PROTECTED]> wrote: > Andy Steingruebl wrote: > > I like contractual approaches to this problem myself. People buying > > large quantities of software (large enterprises, governments) should > > get contracts with vendors that specify money-back for each patch they > > have to apply where the root cause is of a given type. For example, I > > get money back every time the vendor has a vulnerability and patch > > related to a buffer overflow. > > That changes the incentive to hide security bugs and not patch them or > to slipstream them. Any regulatory regime that deals with security issues is subject to the same thing. Whether its PCI and eluding Auditors or SOX-404 and documenting controls, you'll always have people that want to try to game the system. I'm not suggesting that this is the only solution, but from an economics and motivation perspective SLAs related to software and security features are more likely to work and incur lower overhead than a regulatory regime that is centrally administered. Sure, there are going to be pieces of software that this scheme won't work for or where there aren't very many bulk purchasers, only 1-off purchasers. Things like video games for example where there aren't large institutional purchases. That said, I think contracts between large consumers and software producers would be a good start to the problem. -- Andy Steingruebl [EMAIL PROTECTED] ___ 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] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
Andy Steingruebl wrote: > I like contractual approaches to this problem myself. People buying > large quantities of software (large enterprises, governments) should > get contracts with vendors that specify money-back for each patch they > have to apply where the root cause is of a given type. For example, I > get money back every time the vendor has a vulnerability and patch > related to a buffer overflow. That changes the incentive to hide security bugs and not patch them or to slipstream them. BB ___ 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] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
> Just as a traditional manufacturer would pay less tax by > becoming "greener," the software manufacturer would pay less > tax for producing "cleaner" code, [...] > One could, I suppose, give rebates based on actual field experience: > Look at the number of security problems reported per year over a > two-year period and give rebates to sellers who have low rates. And all of this completely ignores the $0 software "market". (I'm carefully not saying "free", since that has too many other meanings, some of which have been perverted in recent years to mean just about the opposite of what they should.) Who gets hit with tax when a bug is found in, say, the Linux kernel? Why? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
On Nov 29, 2007 2:47 PM, Kenneth Van Wyk <[EMAIL PROTECTED]> wrote: > > The article quotes David Rice, who has a book out called > "Geekconomics: The Real Cost of Insecure Software". In it, he tried > to quantify how much insecure software costs the public and, more > controversially, proposes a "vulnerability tax" on software > developers. He believes such a tax would result in more secure > software. I like contractual approaches to this problem myself. People buying large quantities of software (large enterprises, governments) should get contracts with vendors that specify money-back for each patch they have to apply where the root cause is of a given type. For example, I get money back every time the vendor has a vulnerability and patch related to a buffer overflow. I wrote a small piece about this: http://securityretentive.blogspot.com/2007/09/buffer-overflows-are-like-hospital.html Turns out that the federal government isn't paying for avoidable outcomes anymore. Certain things fall into the rough category of "negligence" and so aren't covered. We ought to just do this for software via a contracts mechanism. I'm not sure we want to start out with a big-bang public-policy approach on this issue. We'd want to know a lot more about how the economics work out on a small scale before applying it to all software. -- Andy Steingruebl [EMAIL PROTECTED] ___ 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] Insecure Software Costs US $180B per Year - Application and
I think many companies are working on making their code more secure however without some sort of penality to the business the others aren't going to invest in security. This in particular is why I like what PCI has done (as an example) enforcing 'some' bare requirements/penalties for not doing While it isn't perfect it's something. I've spoken with a few organizations debating penalizing a developer financially if they have vulnerabilities in their code. It is actually pretty difficult to enforce without the proper training/policies/procedures in place. I think if a tax existed this would force companies to develop these sorts of programs since it will most likely be less expensive than paying the fine. My $1.50 Regards, - Robert Auger http://www.webappsec.org/ http://www.cgisecurity.com/ > > > --===1159861409== > Content-Type: multipart/signed; boundary=Apple-Mail-774--974102641; > micalg=sha1; > protocol="application/pkcs7-signature" > > > --Apple-Mail-774--974102641 > Content-Type: text/plain; > charset=US-ASCII; > format=flowed; > delsp=yes > Content-Transfer-Encoding: 7bit > > FYI, there's a provocative article over on Dark Reading today. > > http://www.darkreading.com/document.asp?doc_id=140184 > > The article quotes David Rice, who has a book out called > "Geekconomics: The Real Cost of Insecure Software". In it, he tried > to quantify how much insecure software costs the public and, more > controversially, proposes a "vulnerability tax" on software > developers. He believes such a tax would result in more secure > software. > > IMHO, if all developers paid the tax, then I can't see it resulting in > anything other than more expensive software... Perhaps I'm just > missing something, though. > > Cheers, > > Ken > > - > Kenneth R. van Wyk > SC-L Moderator > KRvW Associates, LLC > http://www.KRvW.com > > > > > > --Apple-Mail-774--974102641 > Content-Disposition: attachment; > filename=smime.p7s > Content-Type: application/pkcs7-signature; > name=smime.p7s > Content-Transfer-Encoding: base64 > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGdjCCAy8w > ggKYoAMCAQICEE3TNKjT6vVPziZ4GZOH6N4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx > JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ > ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkxNTEzMzAxM1oXDTA4MDkxNDEzMzAx > M1owgYoxEDAOBgNVBAQTB1ZhbiBXeWsxGDAWBgNVBCoTD0tlbm5ldGggUmljaGFyZDEgMB4GA1UE > AxMXS2VubmV0aCBSaWNoYXJkIFZhbiBXeWsxGzAZBgkqhkiG9w0BCQEWDGtlbkBLUnZXLmNvbTEd > MBsGCSqGSIb3DQEJARYOa2VuQHZhbnd5ay5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK > AoIBAQCqSxE6IaWzPYQK1MHK/5vFDNb7GmfI/WVjnBVDvyg2wC0EI1zhMGCRJtE78wPRshTg7kC5 > B8W2qNBIxRO8bkU3+Qw8ZRFjPz8EKDoxJuK6byfip64h5Q/HcL6JWNPRrHZQXwpEisehEgytMOJs > JAoLzHUqi2zVz6Wq+NDhtmOIlegvnlcLiHY+IxZaK4bLe/p3717OtswZtJ+xQUS5J9DUf99PIR8q > DWqt/fFBqhQ9a2zewPH/+Jrwnhl/2WdkCWBEn0kkz9J77hNVe7O0NAKGTirWkU3JKY39wCjb7pf2 > 0TNtoFvfj6oTTOwEdvIZkm6C/HMCf4Cwpc+zlLG6VhzlAgMBAAGjOTA3MCcGA1UdEQQgMB6BDGtl > bkBLUnZXLmNvbYEOa2VuQHZhbnd5ay5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB > gQC7cfuLAK0R/H9LyvtBl4+8wt64B7eyTdQDQTyRUyH1IfJAPgXcG8edBPV/3ff6LOIf5bI0MBjF > HjyavBM8532SVgzs+aadJ3gA8OFDnAAcA8lL0vgx1UJATWLneTxNDz5cauUdTpUAckw1V6tQ/erB > a2BBcLPSdoT9P2B90LMPQDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV > BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE > ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 > aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ > ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy > MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM > dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq > hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6 > YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ > B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E > CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ > ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE > AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s > vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx > VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQ > MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 > KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQTdM0 > qNPq9U/OJngZk4fo3jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG > CSqGSIb3DQEJBTEPFw0wNzExMjkyMjQ3MDlaMCMGCSqGSIb3DQEJBDEWBBSyteyFAANif1U5spNG > +rNDEWeLejCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl > IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls > IElzc3VpbmcgQ0E
Re: [SC-L] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
| FYI, there's a provocative article over on Dark Reading today. | http://www.darkreading.com/document.asp?doc_id=140184 | | The article quotes David Rice, who has a book out called | "Geekconomics: The Real Cost of Insecure Software". In it, he tried | to quantify how much insecure software costs the public and, more | controversially, proposes a "vulnerability tax" on software | developers. He believes such a tax would result in more secure | software. | | IMHO, if all developers paid the tax, then I can't see it resulting in | anything other than more expensive software... Perhaps I'm just | missing something, though. The answer to this is right in the article: Just as a traditional manufacturer would pay less tax by becoming "greener," the software manufacturer would pay less tax for producing "cleaner" code, he says. "Those software manufacturers would pay less tax pass on less expense to the consumer, just as a regular manufacturing company would pass on less carbon tax to their customers," he says. He does go on to say: It's not clear how the software quality would be measured ... but the idea would be for a software maker to get tax breaks for writing code with fewer security vulnerabilities. And the consumer ideally would pay less for more secure software because tax penalties wouldn't get passed on, he says. Rice says this taxation model is just one of many possible solutions, and would likely work in concert with torte law or tighter governmental regulations So he's not completely naive, though the history of security metrics and standards - which tend to produce code that satisfies the standards without being any more secure - should certainly give on pause. One could, I suppose, give rebates based on actual field experience: Look at the number of security problems reported per year over a two- year period and give rebates to sellers who have low rates. There are many problems with this, of course - not the least that it puts new developers in a tough position, since they effectively have to lend the money for the tax for a couple of years in the hopes that they'll get rebates later when their code is proven to be good. -- Jerry ___ 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. ___
[SC-L] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading
FYI, there's a provocative article over on Dark Reading today. http://www.darkreading.com/document.asp?doc_id=140184 The article quotes David Rice, who has a book out called "Geekconomics: The Real Cost of Insecure Software". In it, he tried to quantify how much insecure software costs the public and, more controversially, proposes a "vulnerability tax" on software developers. He believes such a tax would result in more secure software. IMHO, if all developers paid the tax, then I can't see it resulting in anything other than more expensive software... Perhaps I'm just missing something, though. 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. ___
