First, a summary - secure programming is often
associated with good programming tactics, which is always advised.
Second, Try offering a few architecture designs that have strong
security solutions that are affordable.
Once the design is chosen the security can be implemented in modules and
upgraded at another time.
Although there are exceptions; but consideration of implementing
encryption
(data or tunnel), token authentication, etc... and how the upgrades to
these modules/packages maybe helpful.
Gaining trust and future work is always an advantage.
Good Luck..
On Fri, 1 Oct 2004, Jeremy Epstein wrote:
In your summary of the discussion, I think you left one off:
7) Some people are reasonably knowledgeable, and DELIBERATELY and RATIONALLY
make the decision not to worry about security (e.g., because they know that
it runs in a benign environment disconnected from public networks, or
because the cost of security is greater than the value/risk of the
information on the system).
Just because we as security engineers thing everyone should want what we
offer, doesn't mean they're irrational to reject it.
In some jurisdictions it's now mandatory to put fire suppression sprinklers
in all houses. The fire suppression companies probably think all of us
should want their technology, because they know it's good for us, even if
it's not mandatory. And they can tell home builders not to quote a separate
price for the sprinklers, so customers don't choose to "save money" by
leaving it out, just as this discussion has suggested that people shouldn't
make it an "option".
But it's not an irrational decision to leave them out. They're imperfect:
heads sometimes fail and spray water over everything causing damage even
when there's no fire [*] (as a result, I don't know if they actually reduce
or increase insurance premiums). They're expensive, which might be money
better spent on other fire suppression or safety measures. They're not that
attractive, which might give a competitive advantage to another home builder
who chooses not to offer them (or make them optional).
So if I, as a rational home builder, am trying to decide whether to package
in this technology which I *know* is good for my customers.... I may well
say "no" or make it optional... Just like this discussion of security.
--Jeremy
[*] If you've ever seen the damage a burst pipe in a house can do, it's MUCH
worse when a sprinkler head fails and sprays water everywhere.
-----Original Message-----
From: Brandon Niemczyk [mailto:bniemczyk@gmail.com]
Sent: Thursday, September 30, 2004 7:59 PM
To: Michael Wojcik
Cc: secprog@securityfocus.com; Jeroen van Drie
Subject: Re: Charging customers on security
I think the entire discussion so far can be summed up into a
few points
1) some people are gullable and will pay "extra" for security
2) some aren't :)
3) you're probably better off not mentioning it at all and
just assessing the needs then building those costs from the get-go
4) while a 'tiered' pricing setup for security may be
completely feasible, it's not very ethical
5) ethics don't matter to everyone
6) it's very easy to exploit the lack of software/security
knowledge of the general public, but you have to realize you
will lose some of the market (the knowledgable part) when you do
