RE: Charging customers on security

Glenn_Everhart_at_bankone.com
Date: 09/29/04

  • Next message: King Pang: "Re: Charging customers on security"
    Date: Wed, 29 Sep 2004 10:32:42 -0400
    To: <koen.vingerhoets@ubench.be>, <secprog@securityfocus.com>, <kingpang@gmail.com>
    
    

    The key issue would seem to be what the expected environment of a piece
    of software is, and its variation.

    When someone designs a building, its designer is required to consider the
    natural environment so the building will resist earthquake, wind, water,
    heat, cold, or whatever else is normally seen over time where the building
    is. It is also required to be able to support expected loads (and should
    state limits so nobody tries to pile tungsten bricks onto the top floor
    of a building not designed for such, or the like.)

    If someone attaches large boxes of dynamite to the support beams of a
    building and explodes it, though, people do not complain the building
    was engineered wrongly in most cases. It is recognized that human attack
    is a whole different kind of problem.

    The exception is where the building is designed as a fortress. Then some
    art exists around resisting dynamite, artillery, or whatnot.

    Software too can be well designed to resist damage from mistaken use.
    Malicious use is a larger problem. Some will remember when a buffer overflow
    would usually crash a program. Random data overflowing a buffer will generally
    do no worse since statistics strongly favor data patterns that are non-exploits.

    If an occasional crash with mis-specified inputs can be tolerated, and no
    malicious attacks are expected, buffer overflows might be tolerated also.
    Some years ago that was common thinking.

    Software that now must exist in large networked environments generally has
    to presume exploits will be in the environment too, so that we now expect
    that someone assuring us the software works in such an environment means he
    is saying that buffer overflows will not be allowed to just cause random
    crashes, but be caught.

    Unlike natural events, though, malicious attacks are not readily predictable
    and are statistically overwhelmingly improbable as random patterns. Therefore
    I suspect it is never going to be possible to claim software as suited to
    a hostile environment. The best one can do is to point at resistance to past
    malicious attacks (especially new ones) and to have designers whose ability to
    invent defenses against malicious attacks is greater than most attackers'
    ability to invent new attacks.

    None of this rises to the level of a guarantee, which will create problems
    for sellers. Moreover, if your designers are able to invent new defenses quickly and
    accurately, you as a vendor are likely to want them to do that in all their
    designs, rather than sometimes writing vulnerable software and sometimes
    writing less vulnerable software. You do not want a careful designer to deliberately
    write careless software some of the time, lest he mix styles by mistake.

    I fear this makes the idea of selling levels of software not too feasible.
    A vendor can advertise how well his designers do or have done, but against
    unknown malware, a consumer will always have some risk.

    This is not a science, but an art.

    Glenn Everhart


    -----Original Message-----
    From: Koen Vingerhoets [mailto:koen.vingerhoets@ubench.be]
    Sent: Tuesday, September 28, 2004 5:00 AM
    To: Secprog@Securityfocus. Com; King Pang
    Subject: RE: Charging customers on security


    Hi,

    I think your idea of layered security will work quite well.
    As mentioned by others, it must be CLEAR what the customer buys. On the other hand, they must be aware of the risks.

    In your example, you clearly have three levels. Maybe take an example of all? So that they SEE the difference?
    Show a print of webconfig, a print of the registry, and so on.

    I wouldn't introduce a third party that early... makes it look as if you don't know how to make it secure.

    Koen



    -----Original Message-----
    From: King Pang [mailto:kingpang@gmail.com]
    Sent: Monday, September 27, 2004 6:36 PM
    To: Chris Matthews
    Cc: secprog@securityfocus.com
    Subject: Re: Charging customers on security


    Thanks for all inputs. I totally agree with all of you. However, I'm
    afraid the car analogy would not apply (exactly) in this case. When
    we sell a car, the buyer chooses an end product; when we sell
    "solutions", the buyer and we agree on what features to be included in
    the envisioning phase. The car buyer cannot choose to have no seat
    belts, but the solution buyer can choose to run everything as
    administrator.

    I was thinking if it is possible to charge customers in different
    security levels. Using username and password as an example: the basic
    level would come with no encryptions such that username / password are
    stored in plain text in the web.config. An intermediate level would
    store them in the registry using aspnet_setreg. An advanced level
    would blah… (you get the idea). Would this work? And more
    importantly, would the customers buy this idea?

    Or, is it possible to introduce a third party company to do security
    audit on the solution to be delivered, just like a car must pass some
    safety test. In this case, will the customer be willing to pay for
    it? Any experience?

    Thanks for all comments. All of you have been very helpful.



    On Mon, 27 Sep 2004 09:47:38 -0400, Chris Matthews <cmatthews@xn.com> wrote:
    > Hi,
    >
    > I normally lurk, but this reminds me of a situation I was in not too
    > long ago.
    >
    > I was building software for a stock broker (specifically, a
    > money-maker). We had the usual, limited budget and a very tight
    > deadline. We analyized the problem, and realized that there was no way
    > to securely build this software in the time allocated. We then
    > immediately went back to the client and explained the situation, as well
    > as the lack of time to do proper security. He said not to bother and
    > that he just "wanted it to work".
    >
    > In my experience I've found that customers want a lot and there are
    > quite a few that will gladly pay fair for it, but they need to be
    > explained the ramifications of their decisions. In my case, it was
    > simply a matter of reworking the environment that the software would be
    > used in to increase the security to a reasonable level.
    >
    > I would suggest that if you are in the position of a contractor to your
    > client, that your responibility to make them understand their decisions.
    > If you are building software that you sell commercially, then you have
    > to deliver what you sell :)
    >
    > Cheers,
    > Chris
    >
    >
    >
    > -----Original Message-----
    > From: King Pang [mailto:kingpang@gmail.com]
    > Sent: Thursday, September 23, 2004 1:17 PM
    > To: secprog@securityfocus.com
    > Subject: Charging customers on security
    >
    > Hello,
    >
    > Our company developers Microsoft Solutions and I am responsible for
    > leading the security initiative in the corporation. I have spent a
    > lot of time and effort on how we should apply security guidance to our
    > product life cycle, such as adding threat modeling and doing security
    > review. But after I have convinced them that security is important,
    > we brought up a discussion on how we should charge our customers.
    >
    > Many of you have customer experience. They want to pay the minimum
    > and have all the features. If they can choose not to pay, they won't.
    > If we tell them threat modeling will add x human-weeks of development
    > and we have to charge them x thousand dollars more, they won't pay.
    > Moreover, they expect the system to be secure enough and if there is
    > anything wrong, they would think that is our fault.
    >
    > If any of you have any experience on dealing security with customers
    > and how you would deal with this issue, please throw in two cents. Any
    > comments or related articles would help too.
    >
    > Warm Regards.
    >
    >





    **********************************************************************
    This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
    **********************************************************************


  • Next message: King Pang: "Re: Charging customers on security"

    Relevant Pages

    • Re: Security in a hosted facility
      ... I work in that environment. ... We monitor access to the server, ... things that the customers might put on the server. ... The customer is responsible for the security of his ftp password, ...
      (Security-Basics)
    • Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked
      ... Oh, yeah, the answer is probably "The original designers of the ... Internet didn't pay attention to security". ... Which is part of the reason why I stopped paying attention to network ...
      (comp.arch)
    • Re: Visual Studio Sucks
      ... "Data Environment" I am referring to. ... designers at all since they really have no commonalities between them ... I could bring up a new query builder via the keyboard by doing Shift ... When working with SQL Server - why the heck did they remove the ...
      (microsoft.public.vsnet.ide)
    • Re: Java vs JavaScript
      ... that it does not restrict you from doing anything potentially dangerous ... designers were in a tearing hurry at the time this stuff was set in stone). ... Agreed that JS gains some security from the fact that it just doesn't have the ... ability to touch as much as the Java runtime (assuming the application that ...
      (comp.lang.java.programmer)
    • Re: A fossil makes a statement
      ... are not inherently secure just because they are VMs. ... Java designers choose a VM to achieve portability, not security. ...
      (borland.public.delphi.non-technical)