Next year Janet will be celebrating its thirtieth anniversary. This made me realise that it’ll also be twenty years since I was first involved in incident response, dealing with attacks against “my” web and email servers at Cardiff University. Over that time the purposes of incident response have stayed pretty much the same: to reduce the number of security breaches where possible and to reduce the severity of those that do still occur. But the range of services and people that need to be involved in doing that has grown far beyond what I could have imagined.
For a recent talk at ENISA I sketched out my personal six ages of incident response or, if you prefer, a six layer model. The latter is actually a better way to think about it: these aren’t stages that incident response has passed through, they are nearly all still going on in parallel. And I’m sure there will be more to add in future.
- The host layer. When I first worked on security, it felt like a one-to-one contest between the attacker and the system administrator. As sysadmin, I controlled all the systems I cared about so they should all have been equally well defended. When a vendor or the CERT Coordination Centre announced a software patch it was my job to edit and recompile the relevant programs or operating system! My aim was simply to make the attacker go away. Groups of sysadmins informally shared information about defensive and attacking techniques.
- The network layer. After a while it became apparent that attacks were no longer coming directly from the attackers’ machines. Instead they were ‘hopping’ from one compromised machine to the next, presumably to hide their traces. That meant that the systems attacking mine were themselves be victims of a previous attack; they might still have genuine customers on them who needed to know they had a problem. Some IP address ranges did advertise abuse or CERT contacts to whom reports could be made but many didn’t. CERTs and incident responders built their own address books for hard-to-reach networks. If you needed to contact someone then you might be told how or a message might be passed on – a lot of people were doing incident response without it being formally part of their jobs so were cautious about disclosing the fact too widely.
- The operational layer. To this point attacks had been done by individuals typing commands into their computer: if they were hopping through your computer you could often see traces of them doing it, including typos! But when someone came up with the idea of automating attacks, defenders needed to communicate a lot more quickly. Unlike telling someone that they have a problem with their computer, reporting that you are experiencing a worm or DDoS attack means sharing information about your own current vulnerability. So you don’t just have to find and communicate quickly with the people who can make your problem go away, you also need to trust them not to misuse the information you reveal in ways that will increase rather than decrease the damage.
- The law enforcement layer. Incident responders have talked with the police for as long as there have been computer crime laws. But formal involvement came more recently, with the realisation that dealing with attacks purely as a technical matter was just teaching attackers how to do it better. Only the possibility of sanctions against individuals seemed likely to make them stop. But the police and CERT worlds are very different: police and their communication channels are generally organised in national hierarchies whereas CERTs talk much more directly, often directly across borders; the objectives of prosecuting an attacker versus getting a service quickly back into operation may conflict; even the way we describe an event may be different, creating plenty of opportunities for mis-communication.
- The legislative layer. And then we discovered that laws are different and that attacks that are crimes in one country may not be in others. Even in some European countries, unauthorised access may only be a crime if it involved circumventing a protection mechanism such as a password or firewall – not true in the UK, by the way. And laws must allow incident responders to do their work. As a principle that seems to be understood by law-makers – it’s even in a recital to the draft Data Protection Regulation – but explaining how details of proposed changes in data protection, interception and computer misuse laws could unintentionally make lawful incident response impossible is now taking up quite a bit of my time.
- The cloud layer. With the most recent community to join the incident response world, we’re back at a technology layer. But it’s a different layer. Whereas most incidents follow the topology of networks so the existing contacts between network operators are often useful, with clouds and other types of overlays that’s no longer true. Incidents can, and do, propagate in ways that don’t reflect the underlying network topology. It may also be hard for one layer to interpret an incident without help from the other – even whether a large traffic flow is an incident or a successful experiment – which increases the risk that actions taken by incident responders at one layer may interfere with those taking place at another. Understanding the communications we need to deal with incidents in overlays is still a work in progress.
- The next layer … may be industrial control systems, or internet of things, or…
With each new layer a similar process of enlarging the community has taken place. Initial contacts have been made with individuals; discussions have taken place to understand their field’s interests and language. As it became clear how to incorporate the field into incident response, work has been needed to increase trust – often helped by actually working on incidents – and to expand awareness and coverage within the new field. Eventually this knowledge may be formalised into working procedures, training and benchmarks: a stage that ENISA is now reaching with law enforcement.
I don’t see any sign of these developments stopping any time soon. We’re still working to understand the interactions with clouds and lawyers and I’m sure that other fields will be identified before long. Incident response is never routine: it’s a challenging and increasingly important area.
