The uprising from customers may already be starting. It is called open source. The real question is what is the duty of others on this forum to make sure that newly created software doesn't suffer from the same problems as the commercial closed source stuff...
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ed Reed Sent: Monday, March 19, 2007 4:27 PM To: Crispin Cowan Cc: sc-l@securecoding.org Subject: Re: [SC-L] Economics of Software Vulnerabilities Crispin Cowan wrote: > Crispin, now believes that users are fundamentally what holds back security > > I was once berated on stage by Jamie Lewis for sounding like I was placing the blame for poor security on customers themselves. I have moved on, and believe, instead, that it is the economic inequities - the mis-allocation of true costs - that is really to blame. Vendors are getting better, because they're being shamed by publicity - not because they're bearing more of the costs that users incur due to shoddy software. But as bad as the costs are that are born by users of shoddy software (patch costs, loss of utility, denial of service, licenses for anti-virus software to make up for the egregiously bad code that leaves buffer overflow exploits available that anyone can leverage to take over a system) - as bad as those costs are they're still swapped by the value - increased productivity and adrenalin rush - that commercial feature-ism delivers. Add the slowly-warmed pot phenomenon (apocryphal as it may be) - customers don't jump out of the boiling pot because they're too invested to walk away. Eventually I think they'll get fed up and there'll be a consumer uprising. Until then let's encourage better coding practices and secure designs and deep thought about "what policy do I want enforced". (obligatory plug for high assurance) But, let's not confuse code quality with code security, either. It isn't secure (against hostile code) until you can verify that it (a) does what the policy says it should do (functional testing) and (b) doesn't do what the security policy says it shouldn't do (fuzzing is just a way of performing boundary tests on inputs - it tells you nothing about hidden behaviors of the system, and you can't tell anything about those without formal analysis and good life cycle configuration management). Ed _______________________________________________ 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* _______________________________________________ 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. _______________________________________________