What’s your plan on how to handle a security breach? How will you react when you’re hacked? Yes, that’s a “when” and not an “if”. Eventually it will happen. You’d better be prepared.

If you ask a number of organizations on the risk of their computer security being compromised, I doubt that you’ll find a single one saying that there is a risk. Everyone will be fairly comfortable that there is no risk for them to be hacked. Some of them think that they are not an interesting target, so there should be no risk. They’re of course wrong. Any computer attached to the Internet is an interesting target. If not for anything else, it can be used for sending spam.

Most people however will be confident that their security measures are strong enough for their threat level. For some, the confidence will be correct, but for most it’s wrong and they lack an understanding of the actual threat level. Even for those that are correct in that they have a robust security, their is always a risk for something being overlooked.

Remember that to win, you have to find and fix every security issue in your environment. The hacker only has to find and exploit one to get in.

There is only one conclusion to be made of this: Eventually everyone will be hacked. You’d better have a plan. No, you’d better have two plans: A technical plan and a plan for communication.

Technical Plan

Make sure that you have defence in depth. Don’t just rely on perimeter (firewall) security. Optimally your network should be secure enough that you can give anyone access to the inside without fear.

For applications, you should make sure that the implications of a breach of the application or web server security are minimized. Don’t run the application under a privileged account; use an account with minimal rights. Don’t connect to the database with an account that can modify the schema. Such an account should only be used during installations.

Most importantly you should make sure that no passwords are compromised even if the entire database is leaked. That means salted hashes for password storage. Use a standard component, don’t invent anything clever yourself. True secure systems are thoroughly reviewed by several security professionals.

Communication Plan

Being a programmer, I tend to think of the technical plan first, but the communication plan is equally important. Make sure that you know who will face media and that the person doing that is properly trained in both communication and security. The Tesco story (by Troy Hunt) shows how not to do it. Those handling their twitter account have no idea of security and no idea of how stupid they look.

To avoid being targeted by Troy Hunt as the next Tesco, make sure that you take any privately reported security issues seriously. Make sure that everyone that are in a position where they might be contacted about security issues know where to report them (this includes the office receptionist).

Also make sure that the public communications around a security breach are handled by a few chosen people that both understand the political implications and know enough technical details. A security breach is bad. Proper communication can avoid turning “bad” into “disastrous”.

Security is hard. Eventually everyone will get something wrong. You have to find and address every single security issue. The hacker only needs to find and exploit one. You really can’t win. You’d better be prepared when you’re hacked.

• ← Using a Bit of Luck to Track Down CSS Parse Errors in IE7
• Make the DbContext Ambient with UnitOfWorkScope →