incident response

Scott Roberts of Github gave an excellent talk on Crisis Communications for Incident Response. If you only follow up one talk from the FIRST conference, make it this one: the slides and blog post are both well worth the time. So this post is just the personal five point plan that I hope I'll remember to re-read whenever I’m involved in communicating around an incident:

An interesting theme developing at this week’s FIRST conference is how we can make incident detection and response more efficient, making the best use of scarce human analysts. With lots of technologies able to generate alerts it's tempting to turn on all the options, thereby drowning analysts in false positives and alerts of minor incidents: "drinking from your own firehose". It was suggested that many analysts actually spend 80% of their time collecting contextual information just to determine which of the alerts are worth further investigation.

Recently we had one of our regular reviews of security incidents that have affected the company in the past few months. All three – one social engineering attack, one technical one, and one equipment loss – were minor, in that only limited information or systems were put at risk; all were detected and fixed, to the best of our knowledge, before anything was accessed that shouldn't have been. If we had only been looking at data breaches they probably wouldn't even have made it to the agenda.

Earlier this week Parliament passed the Data Retention and Investigatory Powers Act 2014 (DRIP), in response to the European Court of Justice's April 2014 declaration of the invalidity of the 2006 European Data Retention Directive on which the UK data retention law depended.