RE: Charging customers on security

This sounds far too ivory tower for me.  "no excuse for not expending that
effort...personally, I'd rather pay..." That says enough right there. The
question is rarely what we, as programmers and admins, feel is  the
necessary level of security.  The question is what level is appropriate
given sensitivity, time, budget, and customer requirements.  Would you give
a five year old fine drafting instruments to take to kindergarten to draw
circles? I hope not.  On the same token, how could you justify the testing,
planning, and overall time investment it takes to write solid code and
design secure systems when your customer simply asks for a simple command
line program?  I doubt the answer is <because> "I'd rather pay."


Brad Horton


-----Original Message-----
From: Wesley Shields [mailto:[email protected]] 
Sent: Tuesday, September 28, 2004 3:29 PM
To: Glynn Clements
Cc: ovi; [email protected]
Subject: Re: Charging customers on security


On Tue, Sep 28, 2004 at 04:12:54AM +0100, Glynn Clements wrote:

> There's nothing ridiculous about the cost to the client reflecting the 
> development costs. Implementing security features takes time and 
> therefore costs money.
> 
> Validating inputs requires effort. Testing for and handling errors 
> requires effort. Authentication, encryption and lots of other things 
> which may improve security all require effort.

Yes, and there is no excuse for not expending that effort.  Keeping the cost
to a customer low is a sound business decision, but it quickly becomes
outweighed by the number of bugs left open when not expending the effort to
fix them because it will cost more money.

Personally, I'd rather pay more to know that the code was developed as best
as it can possibly be developed than to pay less knowing there are some
bugs.

> Depending upon the environment in which the software will be used, 
> there may or may not be any point in expending that effort.

The environment you plan for the software to be used in is not always the
one it is ultimately used in.  Many times software is deployed outside of
what the developer was initially told.

> E.g. a command-line utility which isn't setuid and which is only 
> accessible by users with shell access may not need to be concerned 
> with buffer overruns. There's nothing which I can achieve by injecting 
> shellcode into one of my own processes which I can't achieve by just 
> compiling/installing and running an equivalent program.

This argument is insane.  You should always write software to be secure,
regardless of how it is being executed.  A bug is a bug, and while it may
not be exploitable under certain conditions those very conditions are
subject to change and the bug suddenly goes from harmless to a security
problem.

[snip]

> But not all software fits this model. A lot of software is bespoke, 
> i.e. it is developed for a specific client for a specific purpose, and 
> will only be used in a specific context. It's entirely possible that 
> it doesn't need to deal with unexpected cases, because you are sure 
> that the only people who will ever use it won't be deliberately trying 
> to break it. In that situation, expending additional effort on 
> security issues is unjustified.

I'm reminded of the old saying: "The only two things that are certain in
life are death and taxes."  The environment the software is intended to
operate in can very well change - either intentionally or not.  Using the
"the software was never intended to run in a hostile environment" argument
is worthless in my book.

The bottom line is you either develop secure code or you don't.  Where the
software will be used should not enter into this argument at all, as the
environment is _ALWAYS_ subject to change.

> --
> Glynn Clements <[email protected]>

-- WXS
Wesley Shields