[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 ___
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
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
[SC-L] Re: WSJ.com - Tech Companies Check Software
Fascinating and heartening development. Raises a couple of questions in my mind. 1. Why now? Many worthies, myself included during my years at Sun, have been crying for years/decades *from within the software industry* for just such a shift. So what has changed? Ken and I outlined in Secure Coding the economic forces that have militated against security quality. These forces still operate, I feel sure. The Tragedy of the Commons, for example, is never going to be repealed. So what accounts for this shift, which I agree is happening, without (as I have so often predicted) the dramatic airliner-trapped-in-the-sky/girl-trapped-in-the-well TV moment catalyzing Congress critters into knee-jerk legislation? The significant enabling event coming over the horizon seems to be the development of commerical quality and well-marketed tools. Can it be that capitalism, which (more or less) created the problem, will also lead to its resolution? Perhaps. I have argued elsewhere that unsecure behavior like writing bad code is analogous to polluting the Internet. (I have proposed that unsecurity credits, operating like pollution credits, be used by enterprises to cause departments to budget risk as they today budget other resources.) So maybe we are seeing the birth of entrepeneurial cyber-environmentalism. Has it passed through a stage of being the concern of cranks (us, I mean, esteeemed fellow travelers), to a niche concern, to be followed by being trendy, then mainstream, and so on? Can we hope to live long enough to be condescended to as being passionate about only something everybody knows is dangerous? 2. What is the proper role of government to encourage/foster/exploit such a development? I take it for granted that, as the world's largest (I think) software customer, the U.S. federal government ought to show preference for products built using such tools, and that as the primary overseer of publicy traded North American companies, ought to require, via SEC rules, their internal use by such companies. I (with others) testified in this sense years ago. But let's take another look now at the question of security quality *metrics* and *standards*. As this group have often discussed, it's tough to envision. No more than 1 bug per thousand lines? Must withstand attacks from four high school students for three hours? Able to protect for 24 hours an encrypted Swiss Bank Account worth a million dollars on a site accessible from the World Wide Web? Beats the heck out of me. But my question: what can and should government do, now that tools are emerging, to help us move toward measurement and standards? It happens that NIST (that's the U.S. National Institute of Standards and Technology) has a modest effort starting up to look into the state of the art of static checkers and so forth. I'm not competent to state here what the goals are, or should be, of NIST's current and future efforts should be. So I ask the group: does the advent (as it appears) of effective and easy-to-use tools mean that Now is The Time to push for Standards? If so, who but we cyber-environmentalists can lead the effort? And what's the next step? -mg- p.s. I apologize, btw, if my meanderings above recapitulate annoyingly threads here I have missed while attending to Other Concerns. - Original Message - From: [EMAIL PROTECTED] To: sc-l@securecoding.org Sent: Saturday, May 06, 2006 9:00 AM Subject: SC-L Digest, Vol 2, Issue 69 Send SC-L mailing list submissions to sc-l@securecoding.org To subscribe or unsubscribe via the World Wide Web, visit Message: 1 Date: Fri, 5 May 2006 13:15:52 -0400 From: Kenneth R. van Wyk [EMAIL PROTECTED] Subject: [SC-L] WSJ.com - Tech Companies Check Software Earlier for Flaws To: Secure Coding SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii I saw an interesting Wall Street Journal article today that talks about companies adopting software security practices. Complete story can be found at: http://online.wsj.com/public/article/SB114670277515443282-B59kll7qXrkxOXId1uF0txp8NFs_20070504.html? The article cites a couple of companies that are starting to seriously use some static code analysis tools (Coverity and Fortify) to scan their src trees for security defects. Although it doesn't address much in the way of design-time security activities, it's a good start and it's encouraging to see this sort of coverage in mainstream media. I really liked this quote - In effect, software makers are now admitting that their previous development process was faulty. While banks and other companies that deal with sensitive customer data began to build security into software development in the late 1990s, Microsoft Corp. and other software makers are only now in the middle of revamping their software-writing processes. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com
