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. ___
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 IElzc3VpbmcgQ0ECEE3TNKjT6vVPziZ4GZOH6N4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD
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 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. ___
