Re: [SC-L] Economics of Software Vulnerabilities

2007-03-19 Thread Ed Reed
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).

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

[SC-L] Economics of Software Vulnerabilities

2007-03-06 Thread Ed Reed
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,

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)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
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.?

2006-08-30 Thread Ed Reed (Aesec)

Message: 1
Date: Tue, 29 Aug 2006 15:48:17 -0400
Subject: Re: [SC-L] How can we stop the spreading insecure coding
	examples	at training classes, etc.?
To: "Wall, Kevin" [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.


Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -