RE: Charging customers on security

From: Michael Wojcik (Michael.Wojcik_at_microfocus.com)
Date: 09/28/04

  • Next message: Wesley Shields: "Re: Charging customers on security" 
    To: secprog@securityfocus.com
Date: Tue, 28 Sep 2004 07:58:28 -0700

    > From: Brandon Niemczyk [mailto:bniemczyk@gmail.com]
    > Sent: Tuesday, 28 September, 2004 09:47
    >
    > On Mon, 27 Sep 2004 11:24:04 -0700, Michael Wojcik
    > <michael.wojcik@microfocus.com> 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
  • Next message: Wesley Shields: "Re: Charging customers on security"

    Relevant Pages

    • Re: [fw-wiz] Security dumming down - the kings clothes
      ... these networks we have: "it's a trifle chaotic out there". ... responsible for the security portion of this overall process our ... me that our greatest weakness as an industry is not that our customers are ... >>marketing or rhetoric PhD. ...
      (Firewall-Wizards)
    • Re: How do you monetize your skills?
      ... organizations that were dedicate on only the Information Security ... In sales you'll learn that customers that "want" your product/service ... market customer to reach in all of marketing/advertising. ...
      (Pen-Test)
    • Re: Data Center Theft
      ... went wrong, change security and procedures. ... NOT lie to your customers, and put them in the positions that CI Host ... So how is it possible that the facility has been robbed ...
      (bit.listserv.ibm-main)
    • Re: Security and Contingency Planning
      ... Subject: Security and Contingency Planning ... > Hypothetical Situation: ... scenarios should a healthcare provider actually loose data to data theft, ... angles (current customers, former customers, medical staff, union ...
      (Security-Basics)
    • RE: Linux on military aircraft
      ... Internet so that ... threading security can review it to see if there are any holes. ... And customers want to head from their vendor when they ... Banks had 0 experience in modern technology, ...
      (comp.os.vms)