Economics of Software Vulnerabilities

[ed.reed at aesec.com (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).

Ed