Security breaches and compromises are no longer just a possibility but a simple matter of fact. The arduous (and arguably pointless) discussions on how to prevent organisations from ever being hacked is steadily moving on to a more productive approach, based on clearly identifying those resources that make or break the company and, regulatory obligations aside, decide on the financial attractiveness of protective measures in comparison to other investment options available to the organisation.
This is exactly what we have been asking for - a seat at the big boys' table as partners in business. As such we have to accept and trust the economic decisions made by the leadership team, even if the resulting risk is uncomfortable at times and breaches become a certainty. Our task today is to manage not just the security but the impact of the breach as well. Being in the media following a breach is challenging for any organisation, but as illustrated by Apache Foundation and others, it needn't be a PR disaster if you can avoid fumbling the incident response process.
While I'm not in a position to oracle the decisions leading up to some of the high-profile compromises we've seen this year, it doesn't change the fact that our colleagues in the IT or security departments at Sony, RSA, Epsilon and others are expected to deal with these situations professionally, responsibly, decisively and swiftly, no matter what security controls they were able to afford or implement beforehand.
Being the victim of a security breach has, rightfully or not, the latent stench of incompetence to it, so any attempt to limit the damage to the organisation's brand will be an uphill battle from the start. And while effective incident management does require considerable skills and experience, even the most basic incident response plan will be an invaluable guide in the stressful times when the crisis hits. There are numerous free resources available e.g. by NIST providing guidance on incident response handling to everyone who is willing to invest the time to investigate how the typical building blocks could be formulated in an efficient response plan for his/her organisation.
The effectiveness of the incident response plan is dependent on how well it is aligned with the corporate reality and the skill level of the personnel expected to carry it out. Blindly applying an incident response template that does not fit the environment could in the worst case cause confusion and hamper response processes. To ensure your plan will work as expected when you actually need it the organisation should schedule regular test runs, similar to what you might already do for your BCP/DR plans.
Most IT professionals will admit that they are well aware that they really should have a proper plan and, that ideally, it should be tested every couple months, but in reality there seems never enough time to sit down and work on the incident response plans. If this sounds familiar I recommend to start at least with a very simple interim plan - get in contact with a professional incident response service (SecureWorks, Verizon, Mandiant, etc), discuss the 'what if' and make sure you have their number written down somewhere readily available.
Daniel Schatz, CISSP, is a principal security analyst for Thomson Reuters based in London/UK. He is a member of the International Systems Security Association (ISSA-UK) and holds several qualifications including CISSP, CCSK, CVSE, CEH, MCITP: Enterprise Administrator and MSc Information Security & Computer Forensics (University of East London).
This was first published in July 2011