Defining your objectives
You have an incident. You know you need to handle it. You’re under pressure, and your team is stressed.
This is often the most dangerous point in an incident response operation. Stressed people under pressure to respond quickly tend to make one of two mistakes:
- Delaying too long in making critical response decisions and exacerbating incident impact
- Conversely, making knee-jerk decisions in responding to the incident which cause further damage to the business, or hinder a complete response
To help guide your internal teams, and manage your response effectively, you need to take time out from stressful immediate response activities to review the incident, prioritise your response and decide, definitively, what the business objectives are in your response.
Triage, within an incident, generally consists of:
- Classifying the incident in terms of impact and urgency
- Prioritising the incident
- Defining objectives for the handling of the incident
- Assigning actions or further investigation of the incident to relevant teams or personnel for further investigation or remedial actions
As part of your preparation stages, you should have a set of criteria that you can use for classifying the impact and urgency of an incident, and hence determining its priority.
The impact classifications below, defined by CESG’s GovCertUK and adopted by CREST, may provide a useful point of reference for initial classification of the incident, based upon the perceived or established impact. This will ultimately be guided by your Business Impact Analysis.
| Classification | Description | Example |
|---|---|---|
| Critical | These incidents will usually cause the degradation of vital service(s) for a large number of users, involve a serious breach of network security, affect mission-critical equipment or services or damage public confidence in the organisation. | Targeted cyber security attacks or loss of publicly available online service. |
| Significant | Less serious events are likely to impact a smaller group of users, disrupt non-essential services and breaches of network security policy. | Website defacement or damaging unauthorised changes to a system. |
| Minor | Many minor types of incident can be capably handled by internal IT support and security. All events should be reported back to the information security team who will track occurrences of similar events. This will improve understanding of the IT security challenges and may raise awareness of new attacks. | Unsuccessful denial-of-service attack or the majority of network monitoring alerts. |
| Negligible | It is not necessary to report on incidents with little or no impact or those affecting only a few users, such as isolated spam or antivirus alerts; minor computer hardware failure; and loss of network connectivity to a peripheral device, such as a printer. | Isolated anti-virus alert or spam email. |
Not every incident is critically urgent. In some cases, speed of response may be sacrificed for completeness of the response. Again, your business should define its urgency criteria for responding to incidents. If you do not have these guidelines in place, the following may aid responders in assigning an initial priority to incidents as they occur:
| Priority | Description | Example |
|---|---|---|
|
High |
The damage caused by the incident increases rapidly. Operation of the systems affected may be impaired, where these systems support or enable critical business processes. A minor incident may be prevented from escalating to a Significant or Critical incident by timely action. |
A single workstation affected with Ransomware, which is encrypting files within a network share. A critical data silo is thought to be under current, active attack. |
|
Medium |
The damage caused by the incident increases over time, but this is not thought to be a rapid escalation. Systems affected are not immediately critical, but they may provide access to critical systems over time. A small group of users and their business operations may be affected, but business as usual can still operate for the majority of the organisation. |
Generic banking malware detected on a workstation belonging to a VIP user. A denial of service attack in progress against a non-critical branch office network. |
|
Low |
The damage caused by the incident only marginally increases over time. Affected business processes are not key to the organisation and are not time-sensitive. Evidence suggests that the compromise is historic, or not currently being exploited. Affected systems are isolated from sensitive areas of the organisation. |
Compromise of a system on a segregated guest wireless network. Detection of historic brute force attack against website accounts which has since ceased. |
Cross-referencing impact and urgency can create a priority which can be used to determine the frame of reference for the response. Pre-prepared incident response plans may state what priority of incident may be handled by BAU operational teams as a matter of course, and which priority incidents should be declared major incidents, and result in the instigation of emergency incident response plans internally. An incident with high urgency may allow first responders greater freedom in making independent and isolated decisions, compared with a low urgency incident. An incident with negligible impact may warrant no formal response at all.
These decisions should be pre-determined and contained within your incident response plan; first responders should be able to consult this documentation and understand their focus.
Mobilising full emergency incident response capabilities may not be applicable or appropriate in every situation; the aim of the triage process is to determine how important the incident is, and how it should be handled.
Information about the incident to date, the impact and urgency of the situation and the Business Impact Analysis for the affected data or systems must be used to determine the objectives of the incident response operation. If possible, the business’ priorities should be pre-determined and documented within incident response plans. Different incident response objectives could conflict with one another, so it is important that incident responders have a frame of reference for what they are trying to achieve.
Objectives for the incident response operation could include:
- Resumption of service as quickly as possible, where the affected system is critical in terms of availability for the business
- Rapid ringfencing and protection of confidential information, where the affected system or network is critical in terms of confidentiality for the business
- Integrity checking of the affected systems, where integrity of data is critical for the business
- Preservation of evidential integrity, where criminal activity is suspected and prosecution is likely to be an outcome of the incident, or where culpability must be definitively established
- Identification of the origination of the threat and gathering of intelligence about the activities being conducted during the incident
Particularly for organisations with known advanced threat actors, continued covert observation of an attacker to determine their goals and modus operandi may be an objective of the incident response operation (for intelligence gathering purposes), even if the urgency of containment is high. Experienced incident handlers should be used to inform these decisions.
Once the priority of the incident, and the objectives of the response have been defined, the next step is to allocate activities to members of the incident response teams
Tuesday: Identifying The Incident
Wednesday: Defining Your Objectives
Improve your security
Our experienced team will identify and address your most critical information security concerns.