NIST SP 800-61
Handling an Incident
2.6. Incident Prioritization
Prioritizing the handling of the incident is perhaps the most critical decision point in the incident handling process. Incidents should not be handled on a first-come, first-served basis as a result of resource limitations. Instead, handling should be
prioritized based on the relevant factors, such as the following:
- Functional Impact of the Incident. Incidents targeting IT systems typically impact the business functionality that those systems provide, resulting in some type of negative impact to the users of those systems. Incident handlers should
consider how the incident will impact the existing functionality of the affected systems. Incident handlers should consider not only the current functional impact of the incident, but also the likely future functional impact of the incident if
it is not immediately contained.
- Information Impact of the Incident. Incidents may affect the confidentiality, integrity, and availability of the organization's information. For example, a malicious agent may exfiltrate sensitive information. Incident handlers should
consider how this information exfiltration will impact the organization's overall mission. An incident that results in the exfiltration of sensitive information may also affect other organizations if any of the data pertained to a partner organization.
- Recoverability from the Incident. The size of the incident and the type of resources it affects will determine the amount of time and resources that must be spent on recovering from that incident. In some instances it is not possible to recover from an incident (e.g., if the confidentiality of sensitive information has been compromised) and it would not make sense to spend limited resources on an elongated incident handling cycle, unless that effort was directed at ensuring that a similar incident did not occur in the future. In other cases, an incident may require far more resources to handle than what an organization has available. Incident handlers should consider the effort necessary to actually recover from an incident and carefully weigh that against the value the recovery effort will create and any requirements related to incident handling.
Combining the functional impact to the organization's systems and the impact to the organization's information determines the business impact of the incident – for example, a distributed denial of service attack against a public web server may temporarily
reduce the functionality for users attempting to access the server, whereas unauthorized root-level access to a public web server may result in the exfiltration of personally identifiable information (PII), which could have a long-lasting impact on
the organization's reputation.
The recoverability from the incident determines the possible responses that the team may take when handling the incident. An incident with a high functional impact and low effort to recover from is an ideal candidate for immediate action from the team.
However, some incidents may not have smooth recovery paths and may need to be queued for a more strategic-level response – for example, an incident that results in an attacker exfiltrating and publicly posting gigabytes of sensitive data has no easy
recovery path since the data is already exposed; in this case the team may transfer part of the responsibility for handling the data exfiltration incident to a more strategic-level team that develops strategy for preventing future breaches and creates
an outreach plan for alerting those individuals or organizations whose data was exfiltrated. The team should prioritize the response to each incident based on its estimate of the business impact caused by the incident and the estimated efforts required
to recover from the incident.
An organization can best quantify the effect of its own incidents because of its situational awareness. Table 3-2 provides examples of functional impact categories that an organization might use for rating its own incidents. Rating incidents can be helpful
in prioritizing limited resources.
Table 3-2. Functional Impact Categories
|No effect to the organization's ability to provide all services to all users
|Minimal effect; the organization can still provide all critical services to all users but has lost efficiency
|Organization has lost the ability to provide a critical service to a subset of system users
|Organization is no longer able to provide some critical services to any users
Table 3-3. Information Impact Categories
|No information was exfiltrated, changed, deleted, or otherwise compromised
|Sensitive personally identifiable information (PII) of taxpayers, employees, beneficiaries, etc. was accessed or exfiltrated
|Unclassified proprietary information, such as protected critical infrastructure information (PCII), was accessed or exfiltrated
|Sensitive or proprietary information was changed or deleted
Table 3-4. Recoverability Effort Categories
|Time to recovery is predictable with existing resources
|Time to recovery is predictable with additional resources
|Time to recovery is unpredictable; additional resources and outside help are needed
|Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted publicly); launch investigation