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:
Thanks to recent work, particularly by the Dutch National Cyber Security Centre, the processes that result in successful discovery and reporting of software vulnerabilities are reasonably well understood.
At the FIRST conference this week I presented ideas on how effective incident response protects privacy. Indeed, since most common malware infects end user devices and hides itself, an external response team may be the only way the owner can learn that their private information is being read and copied by others. The information sources used by incident responders – logfiles, network flows, etc.
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.
Domain Name Service resolvers are an important source of information about incidents, but using their logs is challenging. A talk at the FIRST conference discussed how one large organisation is trying to achieve this.