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