Incident management
Page 2 of 7
Introduction: Incident Response overview
Cyber incident response (IR) is complicated by two factors. Firstly, no two incidents are ever the same. Secondly, all responses require people, process and technical elements to work together in order to be successful.
Planning your incident response ahead of time is essential. This will be a major determining factor in the final outcome of any real world incident.
You should produce IR plans and guidance, exercise your response and review your capabilities (including those of any 3rd party service providers). This will give you the best chance of minimising the impact of any attack and recovering quickly.
Note: GDPR
It's worth noting that preparation and mitigation for data breaches are both explicitly required by the ICO, as part of your GDPR-related measures.
They state that you should, "Have well-defined and tested incident management processes in place in case of personal data breaches."
Structure of the incident response process
Although the details of any given incident will vary, the primary stages of response to a cyber incident can be described in broad terms. These are laid out in Figure 1 below.
Contain, Analyse (and often Remediate) frequently form a cycle, which can repeat several times. As more is uncovered about the nature of the attack or incident, it is possible to determine more actions that can be taken to contain it.
In many cases, you may need to perform further analysis before containment actions can be taken. However, you should look to Contain (or mitigate) as an early step, since this may be critical when faced with a live incident where damage or loss is occurring.
Incident Response vs Incident Management
In this guidance both incident management and incident response are referred to.
The two terms are very often used interchangeably. However, there are some differences:
Incident Management (IM) sits within and across any response process, ensuring all stages are handled. IM deals with any communications, media handling, escalations and any reporting issues, pulling the whole response together, coherently and holistically. Blue channel in Fig 1.
Incident Response (IR) This includes triage, in-depth analysis, technical recovery actions and more. Green channel in Fig 1.
Incident detection and notification
Incidents can be detected and reported through a wide variety of routes. Typical detection and notification or reporting routes include:
- Technical: Alerts from various monitoring tools such as SIEM solutions, SOC teams, AV / IDS alerts. Ideally, alerts from different sources will be correlated and presented in the same timezone.
- Staff: Users may report incidents and can be a great strength if they are trained and encouraged to report suspicious activity - whether it be an unusual email or a colleague acting strangely. Customer services and PR teams may also report unusual calls or evidence of a successful compromise found online, such as stolen customer details.
- Third parties: Reports may come from companies which perform incident investigations and threat research. It could also come from partners, suppliers or the public. In some cases it may come from government.
You should seek out additional guidance on monitoring and provide appropriate staff training to ensure that your monitoring is efficient and effective.
An incident may be reported in different ways and to different teams - IT security, helpdesk, legal, PR. Each of these teams should have guidance on how to identify something they should report and who they should report it to.
Ultimately, all alerts of possible incidents should come through to the team responsible for managing them. They can then assess and triage the incident, but also correlate with other alerts.