King Pangs company is designing software which is going to be deployed in a
clients environment. This means that professionally, and as a matter of
integrity, they are responsible for security. You can have
scalable/pluggable security mechanisms, but general application security is
in fact an internal cost of development and should be factored into the
development cost.

If a client requires a higher level of assurance than a vendor can provide
internally, then the vendor has an obligation to either assume the cost or
bill the client for the cost. From my own experience the client has always
required that the vendor assume the cost of assurance because of the fact
that clients stand to gain little from paying enhanced pricing for the
reasons that follow:

Failing a specific level of assurance is usually a deal-breaker; A code
audit I performed through the first quarter of 2004 was a political
nightmare between the client who required the code audit and the vendor who
neither desired, nor cooperated during the code audit process.

Assurance certifications are desirable features; if you get your code audit
analyzed and certified by a respected body then that is a saleable feature.
Most clients will refuse to absorb the one-time cost of a selling point.

The perception of security is a critical competitive advantage; if a vendor
says "we will give you security only if you pay for it" is far less
appealing than a vendor who says "we already have our products tested for
security and we have this design methodology which dictates how we accounted
for security in the design". I was the technical lead on a project which
was initiated by a client who was seeking assurance for a product because
they wanted to use it as a competitive advantage.

Clients have multiple vendors; this is of course, a generalization. There
are very few companies that have a complete lock in on a type of software,
or have such an excessive market share that they can essentially "lock out"
competition. As a result clients will simply select a vendor who has
already implemented the level of security/assurance that is required.

It really is the responsibility of the vendor to provide baseline security
to an application, however, as I said in my previous post the existance of
pluggable security mechanisms (multiple areas: strong encryption,
authentication modules, access control modules, etc) can provide ample
opportunity to benefit financially from multiple tiers of security.

If the product (featuring scalable security) was not the case described
above, but rather a piece of software that had two different versions, a
secure version, and an insecure version, as a client or customer, I would
ask "If the creator of the product cannot assert a basic level of security
across all of the products, why should I trust the security of one of the
products?".

Yvan Boily

> -----Original Message-----
> From: Glynn Clements [mailto:glynn.clements (at) virgin (dot) net [email concealed]]
> Sent: Monday, September 27, 2004 10:13 PM
> To: ovi
> Cc: secprog (at) securityfocus (dot) com [email concealed]
> Subject: Re: Charging customers on security
>
>
> ovi wrote:
>
> > It's ridiculous. What are you saying ?? If I as a client, don't pay
> > you for having a stable and secure program you sell me a
> buggy one????
> > Not even M$ is thinking this way anymore, although they
> continue to sell buggy OS.
>
> 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.
>
> Depending upon the environment in which the software will be
> used, there may or may not be any point in expending that effort.
>
> 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.
>
> [The situation is different if the user may be blindly
> feeding "untrusted" data to the program. In that case, the
> program is "accessible" to the creators of such data.]
>
> If you are developing software for commercial publication
> (the Microsoft model), then it may be used in a large number
> of different environments, and many of those environments
> will require that the software is robust against "unexpected" inputs.
>
> 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.
>
> --
> Glynn Clements <glynn.clements (at) virgin (dot) net [email concealed]>
>

[ reply ]