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