|There's more than one way to do things|
Is it Secure?by cjf (Parson)
|on Apr 09, 2002 at 22:53 UTC||Need Help??|
I'm sure we've all been asked this at some point or another. Perhaps a friend asked you this question about their computer. Maybe your technologically savvy PHB (</sarcasm>) asked it about the program you're currently working on. It's a question that is asked every single day, and there is no correct answer.
The reason that there is no correct answer, is because the question is naive at best. No system can ever be completely secure. Stating that a system is 'secure' provides little information and begs the question 'secure from what.' Even the computer that's unplugged and encased in concrete in your basement is vulnerable to an earthquake.
All a system can be is secure enough that the chance of it being compromised is acceptable. This, of course, dictates that the amount of security required depends on the job you're doing. If you're storing highly sensitive data such as credit card numbers, increasing security should be a very high priority.
Security is, however, only one of many priorities. Increased security will often make your system more intrusive, harder to use, and will cost more in time, talent, and ultimately money. Increasing security is an investment, and it is important to assess how far you're willing to go to reduce your vulnerabilities to a certain level.
So how do you determine how much increased security is worth to your project? Developing a security policy that enforces basic security standards will give you an idea of how far you'll need to go out of your way to increase the security of your system or product. RFC 2196, a 'guide to developing computer security policies and procedures for sites that have systems on the Internet', serves as a good base example. Similar concepts can be applied to many other areas. In order to write an effective security policy you also need to know what your major vulnerabilities are. Attack Trees by Bruce Schneier suggests a method of modeling security threats and discovering what areas you need to focus on most.
Applying these concepts to developing web applications written in Perl is not difficult either. At the lower end of the spectrum you could just say all scripts placed online must use taint checking. Placing a slightly higher value on increased security you could require all scripts follow guidelines similar to those in Essential CGI Security Practices. Even though you can extend your policy and lessen vulnerabilities indefinately along this spectrum, your project will never be 'secure', it will only be more resistant to certain attacks.
Security is not an all or nothing issue.
Update: Added the third sentence in the second paragraph to clarify a point. Thanks for the suggestion podmaster :).