incident response

If you've been watching movies and TV series, it may come as a surprise that most computer security incident response actually involves a lot of command line interfaces and perl scripts, and rather few graphical interfaces. That was the first disappointment that greeted a team of computer scientists from Honeywell and Kansas State University who tried to help their local security team with some new tools. The second was that those analysing incidents seemed to rely much more on experience and intuition than on rules or algorithms that might be encoded into software or training manuals.

A panel session at the FIRST conference on comparable security metrics made me wonder why this seems to be so hard. My first visit to another CSIRT, fifteen years ago, was to work out how to compare our Janet CSIRT statistics with those from SURFnet. And yet the tricky question still seems to be working out what it is you are actually measuring. Most incident statistics actually give you a reasonable idea of how busy the CSIRT is: as with most metrics the absolute values don't mean much but the trend – whether more or less busy – probably does.

One of the challenges in finding an appropriate legal framework for incident response is that for many types of incident you don’t know in advance what information you are likely to receive. Rogier Spoor of SURFnet discussed one of the most common situations – cleaning up after a botnet infection - at the TERENA Networking Conference last month. Although SURFnet’s approach is designed to comply with Dutch, rather than UK, law, it seems a reasonable fit for our legislation too.

The various committees of the European Parliament have now published their response to the Commission’s draft Network and Information Security Directive.