Incident management
Page 3 of 7
Plan: Your cyber incident response processes
This section outlines the ingredients of a basic response plan, breaking down how an incident should be managed in practice. This will enable you to develop your own tailor-made plan.
Whether your organisation is 10 people or 10,000, putting guidance in place on how to handle incidents will help you make good decisions under the pressure of a real incident.
Taking the time to create a plan will help you identify gaps in your incident handling capabilities.
Developing an incident response plan is a critical step towards a robust and effective incident management and technical response capability.
Incident Response (IR) - developing your plan
-
Key contacts
IR team/provider, IT, Senior Management, Legal, PR, HR, Insurance. Always consider the risk of people being unavailable - ideally include at least 2 contact methods and 2 or more people (or group) details.
-
Escalation criteria
-
Basic flowchart or process
This should cover the full incident life-cycle
-
At least one conference number
This should be always available for urgent incident calls
-
Basic guidance on legal or regulatory requirements
When to engage legal support, HR, or follow careful evidence capture guidelines
This is a basic plan. Most of the topics and information discussed in this guidance should be documented in (or alongside) your IR plan.
To enhance your IR plan, look to include:
- Simple checklists which can be used easily during an emergency
- Forms for documenting and tracking the incident and for post-incident review, to ensure all key elements are captured
- Include additional detail on the IR stages and more technical guidance on containing, analysing, remediating and recovering from the incident
- Playbooks / guidance on specific types of incidents
In addition to an IR plan, you should also have inter-linked business continuity, disaster recovery and communications plans (covering internal and external communications).
Incident management - Comms, overseeing, tracking and documenting
Incident management collects together the co-ordinating functions which guide, inform and support the wholeresponse process. It encompasses a number of aspects, including:
- Tracking, documenting, assigning and correlating all findings, tasks and communications. Note that keeping careful track of the whole response is very important in cases which may later be reviewed by regulators or courts. This includes real or potential data breaches and criminal activity.
- Arranging of regular update meetings or calls, and involvement of relevant teams
- Escalating serious incidents to senior management
- Ensuring the incident is communicated appropriately (to team, wider business, other stakeholders)
- Ensuring that the full incident lifecycle is covered from initial discovery through to close down.
*Consider options for secure or alternative communications in event of a sensitive incident, or where normal channels are unavailable due to network/email/phone system outage.
Clarity is critical
Understanding everyone's roles and responsibilities is central to ensuring an incident is managed, and therefore handled, successfully.
There must be a central point of co-ordination, no matter who is involved, to ensure all findings are correlated and actions are planned.
An example set of incident response team roles is shown in "Creating your Cyber Security Incident Response Team".
Keeping a careful record of the incident response, decisions made, actions taken, data captured (or missing) is incredibly useful for post-incident reviews. This is especially true if you will need to present evidence of your response to a regulatory body.
Triage - Understanding the type and severity of an incident
Understanding the type and severity of an incident allows you to determine how urgent your response is. It also enables you ensure that the correct people are involved from the outset.
There are two aspects to look at when assessing an incident: Severity and category, or type.
Severity is typically considered against the following:
- 1
Availability
Is the availability of data or systems impacted? (i.e. what is the impact on business output?)
- 2
Confidentiality
Has sensitive data been accessed, leaked or stolen?
- 3
Integrity
Could data or systems have been altered such that they cannot be trusted?
With all of the above, consideration should be given to the scale of the problem, to what type of system or data is involved, and the practical consequences of the incident.
When quantifying impact, it can help to have full documentation detailing all critical assets and data.
Severity matrix
To aid your evaluation of incident severity, create a matrix of example outcomes, rated for severity. These will help inform how serious the response to the incident should be, who needs to be involved and whether the response needs to take priority over other activities.
Below is an example severity matrix. You should think carefully about what matters most to your business and tailor the Examples column to fit your organisation:
| Severity | Examples |
|---|---|
| Critical |
|
| High |
|
| Medium |
|
| Low |
|
Categorisation of an incident
You should also determine what type of incident you are facing. Some examples include:
- Malicious code: Malware infection on the network, including ransomware
- Denial of Service: Typically a flood of traffic taking down a website, can apply to phone lines, other web facing systems, and in some cases internal systems.
- Phishing: Emails attempting to convince someone to trust a link/attachment.
- Unauthorised Access: Access to systems, accounts, data by an unauthorised person (internal or external) – for example access to someone's emails or account.
- Insider: Malicious or accidental action by an employee causing a security incident.
- Data breach: Lost/stolen devices or hard copy documents, unauthorised access or extraction of data from the network (usually linked with some of the above).
- Targeted attack: An attack specifically targeted at the business - usually by a sophisticated attacker (often encompassing several of the above categories).
Category matrix
As with severity, it is very useful to create a matrix of the different categories.
You can enhance this by adding examples of different severity incidents alongside each category. This will help guide and inform your response.
Escalation - decision making and authorities
Escalation
Typically, matrices are used to determine the severity or priority of an incident. The severity level will inform how quickly the incident needs to be handled and who it might need to be escalated to.
For example, a high or critical severity incident is likely to always need to go up to CIO or board level. A low priority incident could most likely be handled by the IT security team alone. You should document who the escalation points of contact are, along with their contact details (including out of hours) and how quickly the escalation needs to occur.
Authorities
The people escalated to must have the authority to make critical decisions. For example, when a decision may result in major business impact, such as taking a critical service or system offline.
Identify the people who are empowered (or who hold delegated authority) to make such decisions and ensure the escalation process includes these key personnel, as appropriate. It is also important to consider deputies and a process to enable others to make decisions, should the primary contact not be available.
In addition to generic guidance, it may be useful to identify specific situations where the technical team should act autonomously, based on the highest business risks and where taking early containment action is likely to reduce the impact of particular incidents.
Core response - The incident response cycle
The four core response stages of analyse, contain, remediate and recover are considered in detail in Technical response capabilities.
However, a brief description of each stage is provided here.
Throughout the response, all tasks and findings should be tracked. Findings and analyses should be correlated, response actions re-prioritised.
In some cases, the response will need to be escalated or de-escalated.
Post incident review and close down - Learning from the incident
A post incident review should cover:
Lessons from the incident itself
- Are there security improvements which could have prevented the incident, or enabled earlier detection?
- Consider both the tactical fixes that would have prevented or detected this incident as well as strategic solutions that may only be identifiable across multiple incidents. For example, ineffective governance processes leading to multiple intrusions through previously un-recorded, internet-facing, assets.
- In particular, was there any information which would have significantly helped your response but which was difficult or impossible to obtain? Make a plan to gather this data ahead of any future attacks.
Lessons from the response
- Was the response successful and effective?
- Were there elements which could have been handled better?
- Was there data which could have been useful but wasn't available (For example, the right logs, or something that was overwritten early in the response?). Keeping a record of activities during the response will assist with this review.
Asking questions
You should consider these issues across people, process and technical capabilities.
For example:
- Were the relevant data and tools available to enable the analysis?
- Did the processes and communications work well?
- Were the right people involved and empowered to make the necessary decisions?
Playbooks
A playbook (or runbook) is a detailed response plan, usually focused on a specific incident type.
Typical playbook examples include 'malware infection', 'phishing emails', 'data breach' and so on.
We recommend you start with the top 3-5 most likely and high risk incident types for your business. To determine what these are, review previous incidents affecting your organisation as well as drawing on threat intelligence and general cyber security news, relevant to your sector and the countries in which you operate.
You should also consider those threats which apply globally, such as major ransomware attacks.
As a minimum, you should document a set of simple instructions which will cover at least the first few hours of each incident, as these can be the most critical and time pressured.
Playbook instructions should include:
- Who to contact - technical teams, suppliers, senior management, and when to engage Legal, HR, PR if required
- How to understand / triage the incident (specifics relating to this type of incident)
- Guidance on reducing the impact / preventing further impact - specific types of containment or mitigation actions
- Steps on retaining evidence or data if required
Enhanced playbooks
Further incident types and additional stages of guidance can also be included. For example, guidance on analysis, how to fully remediate and recover from the incident, how and when to close down, and how to perform a post incident review.
You should consider legal, media and regulatory aspects. Alternatively, the IR team's playbooks could just include guidance on when to engage these teams, who may have their own detailed guidance in this area.
Playbooks can also be implemented and embedded within incident management and orchestration systems, if appropriate.
Legal and Regulatory Requirements
No matter the type of business, assuming the organisation is based in, or does business within the UK or EU, GDPR and DPA regulations will need to be adhered to.
Nearly all organisations will hold personal data for employees and for their customers. There may also be specific regulatory requirements for the sector, and potentially, specific customer reporting requirements based on any contractual agreements.
Minimum preparations in this area should include engaging legal advice and documenting:
- What constitutes a reportable incident, based on the types and volumes of data your business holds (including any data held by suppliers)
- When and how to engage legal support
- Extra steps required. For example, preservation of evidence or recording of actions taken
To further improve this, the following should also be considered:
- Create forms ready for any regulatory reporting
- Run workshops focused on scenarios which invoke legal / regulatory requirements and rehearse the appropriate steps
Law enforcement and evidential handling
If the decision is made to undertake any legal proceedings (e.g. prosecute a criminal) then there will also be a requirement to engage relevant law enforcement agencies. This (along with any civil cases) may require careful handling of evidence. ACPO has advice on this process.