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. ___
[SC-L] Economics of Software Vulnerabilities
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. Keep in mind that economics does have a tendency to balance out risk and reward, and to fairly allocate liability. But it takes time. We're only about 50 years into the life of the software industry, and we're just starting to see regulatory notice that computers even exist. 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. 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. 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. 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...) But that's not security. It's just reducing irresponsible defects. For computer security to have any meaning, someone, some where, has to say what is supposed to happen and what is not supposed to happen with regard to access to information and resources of the system. In other words, there has to be a security policy. If there's no way to articulate how the security policy can be enforced by a system, i.e., no security model, then there's no real way to even have a discussion about whether a system, much less individual components of the system, contribute to or get in the way of enforcing the security policy. What's most disappointing to me is the near-total lack of discussion about security policies and models in the whole computer security field, today. We're at about the 19th century level of sophistication of the practice of medicine - we have a germ theory (bugs make you sick), but we're still trying to get the doctors and nurses to wash their hands between surgery (Doctor! It HURTS when I do that! Then stop DOING that!). Better languages, better language skills, and better transparency (disclosure) are all areas of important improvement. The question I raise is this - will we return to a serious discussion about whether and how computers can be used to secure the vital information of enterprises before our industry reaches its first century (say, by 2055)? Ought a computer be able to be expected to apply controls adequate to bet your life on, or not? If so, when will that discussion get started again? It seems like the analytical approaches that brought us Bell-LaPadula and similar models are considered off-topic, today, but I haven't seen anything replace them as the basis for a rational computer security discussion. If engineering is the practice of applying the logic and proofs provided by science to real world situations, software engineering and computer science seem simply to have closed their eyes to the question of system security and internal controls. Perhaps economics will reinvigorate the discussion in the coming decades. Ed Reed ___ 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] e: How can we stop the spreading insecure coding examples at, training classes, etc.?
Message: 1 Date: Tue, 29 Aug 2006 15:48:17 -0400 From: [EMAIL PROTECTED] Subject: Re: [SC-L] How can we stop the spreading insecure coding examples at training classes, etc.? To: "Wall, Kevin" [EMAIL PROTECTED] Cc: SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Quoting "Wall, Kevin" [EMAIL PROTECTED]: I think that this practice of leaving out the "security details" to just make the demo code short and sweet has got to stop. Or minimally, we have to make the code that people copy-and-paste from have all the proper security checks even if we don't cover them in training. If we're lucky, maybe they won't delete them when the re-use the code. I agree, and would like to extend it: security should be discussed *at the same time* that a topic is. Teaching security in a separate class, like I have been doing, reaches only a fraction of the audience, and reinforces an attitude of security as an afterthought, or security as an option. Comments in the code should explain (or refer to explanations of) why changing or deleting those lines is a bad idea. However, I'm afraid that it would irritate students, and make security the new "grammar and spelling" for which points are deducted from "perfectly valid write-ups" (i.e., "it's my ideas that count, not how well I spell"). The same used to be said about unstructured programming examples (computed gotos, spaghetti code, multiple entry and exit points from functions, etc). We got past it. We need a similar revolution in thought with regard to security, and some one to take the lead on providing clear, crisp examples of coding style that is more secure by its nature. I don't have one handy - but that's my wish. 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
