Principle
There are well-defined and tested incident management processes in place, that aim to ensure continuity of essential services in the event of system or service failure. Mitigation activities designed to contain or limit the impact of compromise are also in place.
Description
Incidents will invariably happen. When they do organisations should be prepared to deal with them, and as far as possible, have mechanisms in place that minimise the impact on the essential service.
The particular mechanisms required should be determined as part of the organisation’s overall risk management approach. Examples might include things such as DDoS protection, protected power supply, critical system redundancy, rate-limiting access to data or service commands, critical data backup or manual fail-over processes.
Guidance
NCSC’s 10 Steps: Incident Management is the most concise guidance here, but organisations should use other more detailed guidance as and when appropriate. Other authoritative guidance pieces are referenced below.
Preparation – An Incident Response Plan
In addition to meeting the expectations of 10 Steps: Incident Management, you should ensure that your organisation’s incident response plans are grounded in thorough and comprehensive risk assessments. Response plans should prioritise essential services along with the assets and systems that underpin them, such as operational technologies, or key datasets.
The business continuity implications of any compromise should also be taken into account and your cyber incident response plans should link to other business response functions. You should form a response team that is capable of implementing the plan, with the appropriate skills, tools and reach into other parts of your organisation, such as security monitoring and business response.
In practice, the Incident Response function could be co-joined with the security monitoring function. This needn’t be a dedicated team and some members may have non-response related roles. Collectively, the team should have knowledge of IT security, IT infrastructure and Business Management, any specialist technologies (e.g. Operational Technologies or datacentres), incident reporting requirements and communications.
Your plan should cover all relevant potential incidents. It should be auditable and testable (via exercises) across a range of incident scenarios and should encompass all realistic descriptions of what might constitute an incident and its severity. Your test scenarios should draw on threat intelligence, past incidents, exercises and the ways in which security capabilities (e.g. security monitoring and alerting) would feature in your response options. Your scenarios should also consider incidents that involve suppliers and your wider supply chain (e.g. incidents arising through supplier relations, or relying on suppliers as part of your response).
These scenarios could include:
- malware infection
- denial of service
- hacker infiltration
- an Insider Incident
- an inability to view status of the network or operational system
- emergency patching or anti-virus signature roll-out
- system backup and restore
- confirmation of normal operations
Your plan should work seamlessly with other system management and security functions, such as security monitoring. Changes and improvements to response plans should reflect changes to these functions and vice versa, where appropriate.
Plans should articulate clear governance frameworks and roles with procedures for reporting to relevant internal or external stakeholders, such as regulators and competent authorities.
Your plan should also set out a comprehensive range of containment, eradication and recovery strategies, specifying how and when they should be used.
Your organisation should be able to describe its own state of readiness, using any criteria or expected standards from regulators or competent authorities, or from your internal governance arrangements, where appropriate.
You should run exercises to test your ability to respond to incidents that could affect the delivery of essential services. These exercises should reflect past experience, red-teaming/scenario planning, or threat intelligence and should draw heavily on your risk assessment, considering all relevant assets and vulnerabilities, especially where they relate to essential services. Exercises could be designed to test communication channels, technical capabilities, or table-top decision-making tests.
The exercise should record lessons learned, covering governance, roles and internal communication, quality of network and security monitoring data, containment and recovery strategies, or any other factors relevant to their effectiveness. This should integrate with lessons learned activities (see D2 Lessons Learned).
In order to report coherently on incidents when required, your plan should set out reporting thresholds (i.e. what does and does not need to be reported) and standards (i.e. the level of detail that should be reported) and should set out how and when to report on incidents and to whom.
More detailed guidance on developing an incident response plan, and the underlying capability to implement it, can be found in Section 2 of the NIST Computer Security Incident Handling Guide, Part 4 of CREST Cyber Security Incident Response Guide or the Prepare section of ISO 27035.
Response and Containment
Your organisation’s security monitoring function should be capable of alerting with enough detail for a response team to triage and determine the most appropriate response, which might be to investigate further, to take predetermined action, or to take no action. Eventualities not covered in the plan should be dealt with by risk-based decisions, taking account of factors like potential disruption, cost-effectiveness of response and the need for evidence preservation.
The resilience measures your organisation has in place should support incident response (see B5 Resilient Networks and Systems).
Incidents should be reported to the appropriate internal and external authorities, in line with the relevant reporting thresholds and standards. The response team should be capable of prioritising incidents, according to the potential consequences and disruption to essential services, using risk-based methods. These events should be documented, including alerts provided, information passed and decisions taken.
In addition to adhering to mandatory reporting requirements, organisations should seriously consider voluntarily reporting cyber security incidents to the NCSC, who may be able to provide situational awareness, drawing on incident reporting from other victims, as well as response and protective security advice. Assistance may also be sought from Cyber Incident Response (CIR) companies – see CIR scheme.
Further guidance is found in Section 3 of NIST Computer Security Incident Handling Guide, Part 5 of CREST Computer Security Incident Response Guide or Part 4 of ISO 27035.
References
NIST Computer Security Incident Handling Guide
CREST Cyber Security Incident Response Guide
Prepare section of ISO 27035
< Back to Principle C2 Forward to Principle D2 >
Source: NCSC
