He may also mean testing the integrated solution...
In todays world of application integration - your system is only as secure
as all other systems that are being integrated or communicating with it. So
they could potentially design a system that stands alone by itself and in
itself is as secure as possible with todays knowledge - but one plugged in
module or communication point opens up the entire solution for as many holes
as you can think of (again certain precautions can be put in place - but
nothing ever guarantees without testing.. The sp can't be expected to know
of every potential security hole in every system that would ever interact).
Now as a principle to your original statement I would agree to a point. :)
As a sp you need to be very upfront in your contract on what you will and
will not provide. Now certainly your company should not allow obvious and
known security holes to persist in your solution - and should make every
effort to lock down the application as much as possible. However - it's
never going to be 100% clean. So what kind of security consulting would you
provide? Running scripted tests against the app to see if any
'script-kiddie' could take it out? Running break-it testing to see what
kind of 'silly' things you missed. Or slamming the application with every
possible destructive force to see if it lives...
What I have always done in past positions is worked with legal to document
the normative security solution provided in all situations (and build it
into the price). Don't make basic security optional. Say: "We are going to
guarantee that these (list them) types of security flaws will not be present
in the system - and you will pay x dollars for this guarantee" - also make
sure that your company can only be held liable for fixing the flaws if found
(and not held liable for other problems - like lost revenue or lost data).
Also make it clear that these flaws are based on the understanding of
currently known holes at a certain point of time (in otherwords - you are
not required to react to future found holes - unless paid).
If it boils down to it - and the client is not willing to pay for the added
comfort of security - (perhaps its an intranet application - and you have 10
employees all with vested interest in the company (who knows what kind of
reasons they might give)) - perhaps you should also design a default 'you
don't have to pay' level of security. Where they sign documentation stating
that you will not provide any higher level of security other than testing
'xyz' - remember the most important thing is to spell it out in such a way
that a common understanding can be reached - so each knows what the other is
paying for and will be getting - hence why you should use your legal
department. :)
It's a balance between keeping your clients (and keeping them happy and
functioning) - and keeping your company bringing in the revenue it needs to
survive.
Good Luck!
-----Original Message-----
From: wirepair [mailto:wirepair@roguemail.net]
Sent: Sunday, September 26, 2004 6:40 PM
To: secprog@securityfocus.com
Subject: Re: Charging customers on security
Charging for security of your own applications? That seems pretty backwards
to me. Why should the client who buys your software with the expectation
that it works and is secure have to pay for the fact that it isn't? So when
my seat belts are broken, and my tires randomly explode, I have to pay the
car manufacturer more money to get these features fixed?
duh?
-wire
On Thu, 23 Sep 2004 10:16:40 -0700
King Pang <kingpang@gmail.com> wrote:
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.
--
Visit Things From Another World for the best comics, movies, toys,
collectibles and more.
http://www.tfaw.com/?qt=wmf
