RE: Charging customers on security

> From: Brandon Niemczyk [mailto:[email protected]] 
> Sent: Tuesday, 28 September, 2004 09:47
> 
> On Mon, 27 Sep 2004 11:24:04 -0700, Michael Wojcik
> <[email protected]> wrote:
> > Customers get what they're willing to pay for.  If I charge for the
> > additional cost of producing a secure and working product, and my
> > competitor sells an insecure and buggy product, and does so for less
than
> > what I charge because they have lower development costs, then a customer
> > can purchase whichever product they like.  Grandstanding about which is
> > the proper or ethical strategy does not alter the economics a whit.
> 
> Maybe it's just me, but I don't think most customers would want to do
> buisness with or trust a company that charges extra just to make it's
> program not buggy.

It's just you.  Customers consistently choose to do business with companies
that produce inferior products but sell them more cheaply than superior
ones.

I don't understand why this is such a difficult concept for people to grasp.
Security costs money.  Customers are not always willing to pay more for a
better product.  This isn't an issue of ethics or best practices.  It's a
matter of economics.  The market will decide which companies survive and
which practices are profitable.  Whining on the secprog list will not change
that.

Go ahead and declare that you will never release an insecure or buggy
product.  Charge enough to cover your costs and make a modest profit.  Watch
your market share dwindle to nothing as you go out of business.

That leaves the typical commercial software developer with three choices:

1. Produce cheap, insecure products.  History has shown that they'll sell
(if there's demand for them, regardless of security issues).

2. Produce only high-quality, secure products.  Good luck getting anything
to market in the same timeframe or price range as your competitors, or
convincing many of your potential customers that they should pay more and
wait longer for your product.

3. Provide both less-secure and more-secure versions of your product.  That
might mean "demo" and "retail" versions, or "development" and "production"
versions, or simply some versions with added security features, more
extensive testing, and more aggressive support.

If you don't choose #3, chances are your competitors will choose it for you.
If you don't provide the cheap, early, lousy version of your product,
someone else will.  Either you can collect the money and try to sell the
customer on upgrading to the better version, or you can lose that
opportunity.

Now, certainly some customers are security-conscious.  I happen to be in the
fortunate position of having a number of large customers who are demanding
some security features, and that's enough of a mandate to gradually push
more and more security into the products I work on.  That situation does not
generally apply, however.

> That's kinda like a construction company to charge
> to 'not forget to put the 2x4's in the walls'

Bogus analogy.  There are standards in place for construction (building
codes) and an enforcement apparatus (permits, inspections, civil and
criminal penalties).  It's not a perfect system, but it's much, much, much
better than anything we have for software.  That means that in practice
nearly all construction companies are forced to build to at least the same
quality baseline.

Furthermore, customers of construction companies have thousands of years of
experience with buildings.  It's not particularly difficult to explain to
them the advantages of additional quality over that baseline.  That's just
not the case with software security.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus