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 <glynn.clements@virgin.net>
-- WXS
Wesley Shields
