There is a great quote from the talmud that embodies this, one that is used in the book Firewalls and Internet Security by Bill Cheswick and Jim Bellovin (I am referring tothe first edition, ca. 1994, but the second edition, to which the link points was published in 2003 and added Aviel Rubin as co-author) to introduce one of the chapters (if memory serves):
Low Alecha HamLachah Ligmor, v'Low Atah Ben Chorin l'He Batail me menah - Loosely translated, this means It is not your duty to complete the work, but you are not free to let it lie fallow. The notion here is that it is very impossible to completely secure anything, but don't use that as an excuse to not even try.
Some people take a very negative approach to security. Let's do the bare-bones, and that's it. They wait until a breach happens before they start patching things. In the real-world, this approach is what I call a negative approach - i.e. Let's only prevent the things we find to be harmful, and allow everything else until it is used against us. In the real-world, this is the equivalent of saying, let's not put a lock on our door until we get robbed. Granted, I am over simplifying. Many people have the equivalent of a front-door lock in the form of a corporate firewall, but completely ignore that they left the side window wide-open.
While I am nowhere near perfect myself (read: please don't hack my site :) ), I am an advocate for something that I like to call Positive Security - i.e. only open up the services that you need to offer and nothing more and then monitor them dilligently.
Here are five basic points towards thinking positively about security:
- Remember to close everything down on your servers that doesn't need to be used publicly. It is more difficult figuring this out at first, but it is better to have to figure out which service needs to be turned on, then to browse through a list of services after a breach and figure out who is the weakest link.
- Don't worry as much about the ports you close than the ones you open. You need to open port 80 (and/or 443) to allow access to your site, and it makes sense that attackers will try to find ways to exploit these to ports before trying more difficult means.
- Despite what you and your development team think, your code has bugs. Whether you're vulnerable to SQL injection, buffer overflows, or privacy issues, don't be so naive to think that your code and security are flawless. Test it for common vulnaerabilities (like the aforementioned SQL injection).
- Don't worry about inconveniencing users. Which conversation would you rather have with a user - explaining to them that they can't do something because of security concerns, or explaining to them that 5,000 customer credit cards or social security numbers were stolen.
- Minimize your liability by minimizing the sensitive data you store. Since no security measures are strong enough to prevent every breach, why not limit the amount of sensitive data you store to mitigate risk. For example, if the credit card is processed by a third party, why store them on your site altogether? There is also no need to store passwords in plain text. A one-way hashing function is almost always available with most APIs, and that's all you need for passwords. In addition, if you are worried about your code, why not obfuscate it, or only install executables on your servers when possible. While these methods are not completely foolproof, they will repel the casual attackers and make things more difficult for the more experienced ones.
Again, the minute you connect something to a public network it ceases to become completely secure, but the more steps you take to secure it, the better your chances are of keeping it safe.