3 February 2012


So, the National Institute of Standards and Technology (NIST) announced a couple of days ago the release for comments of draft Special Publication (SP) 800-61 Revision 2, Computer Security Incident Handling Guide. How very timely that was! With 2011 dubbed the year of the data breach, and the fact that it takes 3 to 8 months on average for an organisation to discover they have been breached, what better New Year’s resolution than to have an effective Incident Response Plan?...

Infosec incident response has undeniably become a prominent part of any of our endeavours as the focus is now increasingly moving from “How do I prevent a breach?”  to “What do I do when I get breached?” I know of very few organisations that have successful, exhaustive and maintained incident response plans... When I think of the PCI DSS, it is surprising to see that requirements 12.5.3 and 12.9 (notably) do not appear until milestone 4 of the prioritised approach. I commend Visa Europe for realising this and making it a prerequisite qualifier for their Technology Innovation Programme (TIP) and we certainly advise all our customers to think about incident response very early on. Interestingly, the NIST document suggests that it is vital to build relationships and establish suitable means of communication with other internal groups (e.g., human resources, legal) and with external groups (e.g. other incident response teams, law enforcement). I am still surprised therefore that very few organisations have contacted their acquiring bank as part of an incident response plan scheduled test... For some stats on data breaches, see this post...
So, if we all accept that we should always aim to reduce the frequency of security incidents by effectively securing networks, systems, applications and have the appropriate policies and processes in place (prevention is always better than cure and scope reduction is always paramount...), the NIST report is a great help in providing guidelines on responding to incidents effectively and efficiently. They include the following steps:
  • Creating an incident response policy and plan
  • Developing procedures for performing incident handling and reporting
  • Selecting a team, staffing model and training of the incident response team and other stakeholders.
  • Determining what services the incident response team should provide
  • Setting guidelines for communicating with all parties regarding incidents and establishing relationships between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies): businesses should document their guidelines for interactions with other organizations regarding incidents.
It is not surprising given that the substantial brand and reputational damage that ensues after a data breach that a whole section of the report is dedicated to responding to outside parties and the following diagram explains it well:
They place particular emphasis on responding to the media and suggest the following activities:
  • Conduct training sessions on interacting with the media regarding incidents, which should include the importance of not revealing sensitive information, such as technical details of countermeasures that could assist other attackers, and the positive aspects of communicating important information to the public fully and effectively.
  • Establish procedures to brief media contacts on the issues and sensitivities regarding a particular incident before discussing it with the media.
  • Hold mock interviews and press conferences during incident handling exercises. The following are examples of questions to ask the media contact:
    • Who attacked you? Why?
    • When did it happen? How did it happen? Did this happen because you have poor security practices?
    • How widespread is this incident? What steps are you taking to determine what happened and to prevent future occurrences?
    • What is the impact of this incident? Was any personally identifiable information exposed? What is the estimated cost of this incident?
The full report can be found at http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-61-Rev.%202 and comments can be submitted to 800-61rev2-comments@nist.gov by 16th March 2012 with "Comments SP 800-61" in the subject line.
Finally, don’t forget to include your acquiring bank or processor in your security incident response plan.

If you liked this post, see the next one in this series, entitled “Incident Response and Risk Management go Hand in Hand...”
If you still would like to hear more about incident response, and particularly how to use social media, see this post... 

Until next time...