RE: Charging customers on security
From: Koen Vingerhoets (koen.vingerhoets_at_ubench.be)
To: "Secprog@Securityfocus. Com" <firstname.lastname@example.org>, "King Pang" <email@example.com> Date: Tue, 28 Sep 2004 11:00:15 +0200
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.
From: King Pang [mailto:firstname.lastname@example.org]
Sent: Monday, September 27, 2004 6:36 PM
To: Chris Matthews
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
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 <email@example.com> wrote:
> 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 :)
> -----Original Message-----
> From: King Pang [mailto:firstname.lastname@example.org]
> Sent: Thursday, September 23, 2004 1:17 PM
> To: email@example.com
> Subject: Charging customers on security
> 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.