Re: [SC-L] bumper sticker slogan for secure software
There's another point to consider, when talking about whether True Security is Possible. And I have to say I've never been happy with the forms I've found so far to express it... Security, in many cases, decays. It's like what we used to call, in the Old Days, bit rot. Software that has worked perfectly well for years (that is, failures and mistakes have fallen under the threshold of detection) suddenly stop working. Often, it's because some element of the environment in which the system runs has changed around it. It could be a library that the program uses, for instance. I suppose it could be a change in the way the software is used, or applied. So while most software decays in some way while it ages, I seem to observe that the security aspect of a program decays faster than the rest of it. (This has some analogies in the real world. Some parts of a car, for example, wear out faster than the rest. Tires and Brake pads. It's an interesting feature of good design, of course, to isolate the effects of wear and tear into parts intended to be disposable. But I digress.) I have therefore often wondered if we should be talking, not about how secure a system is, in a static sense, but rather what its security half-life is. This is the point of my hoary thought experiment (sorry if you've heard this one) in which we prepare a desktop with the latest and greatest in the way of anti-virus stuff, firewalls, OS patches, and so forth, then spin it down, shrink-wrap it, and put it in a closet. If we take it out a year later and spin it up, that system will be less sure--more likely to successfully be compromised--than it was when it was spun down. How fast security decays will vary, depending mostly on which OS and app software it runs and how corrosive, if you will, that part of the overall operating landscape (the Internet, say) is. This reasoning leads me to the thought that Mac OS X, for example, is more secure than Windows XP for reasons having nothing directly to do with design or implementation, but rather pertaining to its very ubiquity. XP, in this sense, is the center of the bullseye. Gee, maybe software systems emanate a modicum of unsecurity gravity, so that if you get a great many of them together (that is, if millions and millions of people buy the product), security plummets, and declines as the square of the distance to True Dead Center of the day's commonplace platform. Or, to put it another way, this is why XP sucks. Well, I said I've never been happy with the way I've expressed this. -mg- - Original Message - From: [EMAIL PROTECTED] To: sc-l@securecoding.org Sent: Friday, July 21, 2006 5:05 AM Subject: SC-L Digest, Vol 2, Issue 124 Send SC-L mailing list submissions to sc-l@securecoding.org To subscribe or unsubscribe via the World Wide Web, visit http://krvw.com/mailman/listinfo/sc-l or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of SC-L digest... Today's Topics: 1. Re: bumper sticker slogan for secure software (Pascal Meunier) 2. Re: bumper sticker slogan for secure software ([EMAIL PROTECTED]) 3. Re: bumper sticker slogan for secure software (Florian Weimer) 4. Re: bumper sticker slogan for secure software (Pascal Meunier) 5. Re: bumper sticker slogan for secure software (ljknews) 6. Re: bumper sticker slogan for secure software (Pascal Meunier) 7. Re: bumper sticker slogan for secure software (ljknews) 8. Re: bumper sticker slogan for secure software (Dana Epp) 9. Re: bumper sticker slogan for secure software (John Wilander) -- Message: 1 Date: Thu, 20 Jul 2006 15:11:06 -0400 From: Pascal Meunier [EMAIL PROTECTED] Subject: Re: [SC-L] bumper sticker slogan for secure software To: Gary McGraw [EMAIL PROTECTED], Florian Weimer [EMAIL PROTECTED], der Mouse [EMAIL PROTECTED] Cc: SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On 7/20/06 1:57 PM, Gary McGraw [EMAIL PROTECTED] wrote: I'm afraid that's not true. John Knight has a famous paper that shows that design/requirements bugs persist in n-version programming paradigms. I'll let the interested people google that one up for themselves. gem But it's true for stupid bugs like buffer overflows and format string vulnerabilities, in which we're still swimming, and the proof is the fact that those aren't possible in some languages. For design/requirements bugs, I'm reading: Why Are Formal Methods Not Used More Widely? John C. Knight Colleen L. DeJong Matthew S. Gibble Lu?s G. Nakano Department of Computer Science University of Virginia Charlottesville, VA 22903 http://www.cs.virginia.edu/~jck/publications/lfm.97.pdf
Re: [SC-L] SC-L Digest, Vol 2, Issue 183
Gary McGraw said: Ed Felten and I found out early on (back in 1996) that you can use the press as a lever to get companies to do the right thing. We learned this when releasing the very first Java Security hole. We found out that Sun paid much more attention once USA Today picked up the story from comp.risks. Later, we could disclose the problems responsibly... I told my part of this tale in Secure Coding (O'Reiily, 2003--with KRvw, of course). I was Sun's corporate-wide Security Coordinator, responsible for fixing, or getting fixed, all security bugs or flaws in our products. I had analyzed, without source code, the Java jail approach and had identified what I thought was a potential problem. I reached out internally and had a series of meetings with the main designer, the main architect, and the person who was in charge of security for Java. I told them each that my experience and intuition indicated that there would be a serious security bug, right there, and volunteered to round up a group of volunteer external experts (I was well plugged into FIRST at the time) to help analyze potential problems. All this was before any security bugs had been found in Java. And as busy as I was keeping up with bugs fixes, disclosures, and exploits inh UIX/Solaris, I was determined to act proactively and help perfect what I saw as a great step forward in security. The three Java experts gave me the cold shoulder. I persisted. They told me to go away, and expressed with force and conviction that there were not--could not be--any security bugs in Java. About 10 weeks later, I was at a national-security conference in Houston. While I was walking up to give my address on the Java Security Model--literally, while I was taking to the stage--an acquaintance there said, Hard day for Sun security types, I guess He then showed me the USA Today headline Gary referred to in his post. It turned out that Gary and Ed had independently discovered and (unsuccessfully) reported the self-same bug I had hypothesized about. It was fixed a few short weeks later. Hubris is not endemic to a single company, or individual. And the inability to see our own mistakes (sometimes, even when they are pointed out to us) is something I don't believe we software types can even claim as particular to our occupation. It is, as luminaries like Peter Neumann and James Reason have amply demonstrated, a failure common to that combination of orderly and creative thinking we call engineering. Similarly, for reasons Ken and I discuss in Chapter 1 of Secure Coding, the corporate animal really will, all too often, turn the Reality Distortion Field on full-force rather than deal with a pre-headline problem. I often ask myself which set of dangerous behavior--corporate blindness, or preemptive disclosure--is more likely to trigger the first security-bug-caused death. I don't know. Can we turn the ship of software development before we hit that rock? I doubt it. One hopes. -mg- ___ 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] Book project needs co-author(s)
Hi SC-L folks, Ken van Wyk and I (we wrote “Secure Coding”, in 2003) are working on a new book. It’s about how software developers and enterprise security specialists can work together to help make a business safer. The project is not moving fast enough for us, so we’d like to take on one or two co-authors. If you would like to be considered, please email me at “coding-authors at vanwyk dot org”. (A one-sentence expression of interest would be fine.) I will reply promptly with more information about the project and a list of things about you we will want to know. Our deadline for these inquiries is Sunday, March 13th. We would prefer co-authors with a successful track record, but previously published books or papers are not a prerequisite. We do require substantial experience in at least one of the two disciplines—software development or enterprise security—and the ability to express oneself clearly in business English. Oh, and you will need lots of time, this year. 1. We are looking for full co-authors, so please don’t offer to write or code for a fee. 2. Feel free to forward this announcement to any individual (not a list). 3. Our publisher would need to approve your participation. Serious inquiries only, please. -mg-___ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
