RE: Charging customers on security

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:[email protected]] 
> > Sent: Thursday, September 30, 2004 7:59 PM
> > To: Michael Wojcik
> > Cc: [email protected]; 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
> > 
>