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:
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
Category | Definition |
None | No effect to the organization's ability to provide all services to all users |
Low | Minimal effect; the organization can still provide all critical services to all users but has lost efficiency |
Medium | Organization has lost the ability to provide a critical service to a subset of system users |
High | Organization is no longer able to provide some critical services to any users |
Table 3-3. Information Impact Categories
Category | Definition |
None | No information was exfiltrated, changed, deleted, or otherwise compromised |
Privacy Breach | Sensitive personally identifiable information (PII) of taxpayers, employees, beneficiaries, etc. was accessed or exfiltrated |
Proprietary Breach | Unclassified proprietary information, such as protected critical infrastructure information (PCII), was accessed or exfiltrated |
Integrity Loss | Sensitive or proprietary information was changed or deleted |
Table 3-4. Recoverability Effort Categories
Category | Definition |
Regular | Time to recovery is predictable with existing resources |
Supplemented | Time to recovery is predictable with additional resources |
Extended | Time to recovery is unpredictable; additional resources and outside help are needed |
Not Recoverable | Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted publicly); launch investigation |