Re: Charging customers on security

In-Reply-To: <[email protected]>

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


You hit on another good point there. The car buyer can not choose to have no seat belts, if they want their car to pass registration and be legal for highway use. I grew up in a rural area, and trucks didn't necessarily have to have seat belts, but they couldn't be certified as drivable on the highway without them.

I can almost bet that if the government didn't have in place restrictions on things like seat belts, bumper heights, etc that the manufacturers would not put them in *unless the market demanded it.*

Unfortunately, as in with software, people don't always care about safety or security, even when it comes to their own lives. Having been in emergency services I've seen my share of drivers who don't wear their seat belts, even though they are present in the car, and pay dear consequences for it.

As another posted pointed out, the challenge is that there isn't a standards body for something like this. In a car, you pretty much only have to worry about either being hit, catching fire, or rolling over. In a software application, you have to question things like do we need to protect it from local users? Web users? SQL Injection attacks? DB admins? Other software vendors whose software might be running on the machine? Packet sniffers? Etc, etc, etc. 

We are in the midst of finishing up an app where the DB admins are not allowed to see the data stored in the database for pretty much all of the information. This means encryption (among other things). It also means an increased cost in development time and in maintenance time. While the dev time is obvious, the maintenance may not be so. If there is a problem with the application that our logging doesn't catch, only those who have the authorization to know the keys can access the information to see what is going on.

In my opinion, the best thing to do would be to develop internal standards and document it. Things like you'll use stored procedures with parameters to prevent SQL injection attacks. Or things like the app will assume anyone with Administrator access to the local machine can modify it. These are the kinds of things you have to lay out from the very beginning.

Second, have a different set of documents for customer choice. Things like what level of encryption can be used, if you will do a security audit of the user's server before your app is installed on it, etc. This way the user's can choose if they want that extra security or not. If I am storing a username and password for a 30 member club that maybe has their phone number I'm going to use a different level of encryption then if I am storing personal details of foreign nationals.

Although I agree it seems a little silly to charge your customers for basic premise code security, like SQL injection attacks, it isn't at all when you start having to handle data and code in a special way.