The aims of incident response have stayed pretty constant - to reduce the number and severity of security breaches that occur. But nowadays far more services and people need to be involved.
Recently I had the privilege of being awarded a medal of honour by the Vietsch foundation for my role in advancing trust and security within the European research and education sector. This was a great honour, which reminded me that it’s 20 years since I was first involved in incident response, dealing with attacks against web and email servers at Cardiff University.
Since then I’ve been head of the Janet network’s incident response team and am now Jisc’s chief regulatory adviser.
Universities, colleges and research networks have always been a good place to see incident response develop. When I started, our need to run networks that were both open and secure meant we learned effective incident response techniques very early; we’re still among the first to experience new challenges such as clouds and overlay networks.
My own experience covers six 'ages' of incident response, though a six-layer model is a better way to think about it:
The host layer
When I started, security felt like a direct contest between the attacker and the system administrator. As sysadmin, I controlled all the systems that mattered to me.
When a security weakness in a program or operating system was announced it was my job to modify and recompile the relevant code to prevent attackers using the weakness to gain access to my systems. The aim was simply to make attackers go elsewhere.
There was no formal procedure in place for dealing with attacks, so groups of sysadmins shared information informally about defences and attacks.
The network layer
After a while we noticed that attacks no longer came directly from attackers’ own computers. Instead attackers ‘hopped’ from one compromised system to the next to hide their traces. Now the systems attacking me were themselves victims of earlier attack.
This meant I had to get messages to other operators and users to tell them they that they had a problem with their systems. At the time many people were doing incident response alongside their paid jobs so were concerned about being overloaded if they became too visible.
As a result, many networks didn’t advertise where to send incident reports so messages were often passed along a chain of responders, each one with a contact a bit closer to the problem.
The operational layer
Early attackers typed commands manually; evidence often included their typos! But when someone invented automated attacks, defenders needed to communicate much more quickly. Informal, ad hoc, relationships weren’t enough; contact and trust needed to be established in advance.
Telling someone you are suffering from a worm or denial of service attack reveals your own vulnerability, so you needed to know they wouldn’t misuse information and increase, rather than decrease, the damage. Regular meetings with peers became an essential part of incident response work.
The law enforcement layer
Incident responders have talked with police ever since crime appeared online. Formal involvement developed as we realised that treating attacks as a purely technical matter just teaches attackers how to do it better.
Only possible fines or imprisonment seem likely to dissuade them but linking the two communities is tricky. Police organisation uses national hierarchies whereas computer security incident response teams (CSIRTs) talk directly across borders.
Prosecuting an attacker may conflict with restoring a working service and even our descriptions of an event may differ.
The legislative layer
We then discovered that laws vary; attacks that are crimes in my country may not be in yours. Laws need to permit incident detection and response.
Law makers understand that in principle - it’s stated in the draft Data Protection Regulation - but I still have to explain how detailed changes in data protection, interception and computer misuse laws could unintentionally make lawful incident response impossible.
For example every few years there’s a proposal to ban programs that find security weaknesses, even though those are at least as important to security teams as they are to attackers.
The cloud layer
The latest community joining the incident response world takes us back to a technology layer but one with a different structure. Traditional incidents follow network connections so are often traced and resolved through existing relationships between operators.
With clouds, grids and similar systems that’s no longer true. Incidents can and do spread in ways that don’t reflect the underlying network topology. Data can be hard to interpret - is that massive traffic flow an incident or a successful experiment?
We’re still working to understand the communications needed to deal effectively with incidents in these systems.
The next layer
We don’t yet know what this will be. It may be industrial control systems, or the internet of things, or something completely different, but I’m sure there will be more in future.
Effective incident response
We haven’t finished any of these layers, they’re all still going on in parallel. Incident response will continue to develop, alongside the ways we use networks. With those uses becoming ever more critical to individuals and organisations, effective incident detection and response are vital.
Keeping the impact of incidents at an acceptably low level requires a partnership. Incident response teams in organisations deal with individual users and machines. Janet network computer security response incident team (CSIRT), shares good practice and advice, coordinates the response to large-scale incidents, and provides trusted links to the worldwide incident response community.
Incident response is seldom routine, it’s a challenging and increasingly important area.