Caring about Security (and Dental Health)

Caring about the security of your site or service is a bit akin to going to the dentist on a regular basis: It’s not pleasant, doesn’t really get you any visible results and costs time and money. Hence the people who care/go regularly are the ones who have had a bad experience by not doing so. In my own case that is now (sadly) true for both my teeth and security.

My exposure to computer security issues started in the fall of 1987 when I was a freshman at Harvard. We had a bunch of VAX machines (remember those?) running BSD Unix. I logged in repeatedly with the default account password that I had been given at the beginning of class. A week or so into classes when I logged in again, a little shell script ran saying something like “You should change your password! RTM" RTM is of course non other than Robert T. Morris (who graduated that year) and the following year created what became known as the first Internet or Morris worm (btw, lest anyone think differently I am an RTM fan). Since then I have encountered enough nefarious activity on the Internet that I take even far-fetched sounding concerns about the security of smart electricity grids seriously.

Most startups have extremely limited resources in terms of time and money and need to worry primarily about delivering a service that people will actually use. Having said that, there are a bunch of basic security items that no startup should ignore:

Guard against SQL injection attacks by using a framework or escaping inputs or using parameterized queries
Limit the potential for XSS attacks (like the one Twitter was hit with) by sanitizing user inputs that get displayed on the site (if you are asking a user for a color code, exclude anything from the input that is not a color code).
Limit access to your machines to traffic that is absolutely required using netfilter/iptables (in most cases that will just be http, https, ssh and maybe smtp, pop).
Don’t just use the default configuration files for Apache, PHP (or whatever you are using) and ssh. The defaults tend to have poor security and even a few minutes of work will make them more secure.
If you have a web based admin console for your service (who doesn’t?) make sure that it requires strong passwords and if it permits delete or modification operations have scripts ready to undo (soft delete is the way to go). Also run the web based admin over https to make password sniffing on wifi connections harder.
Avoid URLs based on auto-increment row ids, which make it easy for an attacker to traverse your entire database (there are also scaling reasons for avoiding these).

I am sure the list could be made longer, but these strike me as must-have items even when you are just getting started. Once your site or service takes off and you have many thousands or even millions of users (or significant ecommerce transactions) there will be lots of other things you have to do (such as external security audits and hiring ”paranoids“), but those are all great problems to be having!