In-Reply-To: <72d7fc320409270936383e8f03@mail.gmail.com>
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.
