[SC-L] Book project needs co-author(s)

2011-03-07 Thread Mark Graff
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.

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

2006-11-05 Thread Mark Graff
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.


Secure Coding mailing list (SC-L)
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

2006-07-21 Thread Mark Graff
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.


- Original Message - 
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

 To subscribe or unsubscribe via the World Wide Web, visit
 or, via email, send a message with subject or body 'help' to

 You can reach the person managing the list at

 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
   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],
 Cc: SC-L@securecoding.org
 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 
 design/requirements bugs persist in n-version programming paradigms. 
 I'll let
 the interested people google that one up for themselves.


 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 
 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



[SC-L] Re: WSJ.com - Tech Companies Check Software

2006-05-06 Thread Mark Graff
Fascinating and heartening development. Raises a couple of questions in my 

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?


p.s. I apologize, btw, if my meanderings above recapitulate annoyingly 
threads here I have missed while attending to Other Concerns.
- Original Message - 

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

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
To: Secure Coding SC-L@securecoding.org
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 



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 

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 

their previous development process was faulty. While banks and other
companies that deal with sensitive customer data began to build security 

software development in the late 1990s, Microsoft Corp. and other software
makers are only now in the middle of revamping their software-writing


Ken van Wyk
KRvW Associates, LLC