Re: Charging customers on security [repost]

Unfortunately, Michael is quite right. One could wish it were
not so, but that won't change the fact.

> 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.

Sun Microsystems have practiced this for years. Compare Solaris with
Trusted Solaris.  Which one is sold most? The standard one. 
Many people doesn't even _know_ Trusted Solaris exist, 
less even consider bying it. Why?

Well. If you ask me, many organisations does not want security. 
It's expensive. Not only to purchase, but also to maintain. 
Oh, they'll say "we want our systems to be secure", but they
certainly does not want to pay for it.

Pardon my generalisations below, there are of course exceptions,
but I have found the following to be only too common:

* Management does not want to pay for security. 
  It costs a lot of money (purchase, implementation, maintenance, 
  and they need some security analysts, too)

* System administrators does not want security.
  "What do you mean, rsh with trust relationships is insecure?"
  Lets face it. Their job is much easier without security
  (until compromise, of course).

Until the above changes, we will continue to see lot of
lousy code, buffer overflows, and worms exploiting them.

And yes, Standard Solaris is still better security-wise than
some other OS:es out there, and it is definitely not a
"lousy", nor "early" product (and cheap can be argued too :-)), 
but it is not very secure in its default configuration.

Best regards,
Patrik Sternudd