Incidents are a part of life, but so is understanding the scope and bounds of an incident. One subject that comes up form time to time is how to define what is and is not ‘part of the incident’. Not everyone uses the same terms, language or definitions (which is true of many things in life). But when it comes to cyber incidents on the ground, details matter, but so do decisions!

Is the role of incident response to solve all security challenges and gaps in an enterprise? Should the recovery phase mitigate all threats? should the entire business be changed due to an incident and is that the role of the response team? When do you define what is and what is not part of the response vs what is a business change project?

These are important questions. So let’s take a look:

What is the goal of incident response?

According to NIST SP 800-61 Rev. 2

“Incident handling is the process of detecting and analyzing incidents and limiting the incident’s effect. For example, if an attacker breaks into a system through the Internet, the incident handling process should detect the security breach. Incident handlers will then analyze the data and determine how serious the attack is. The incident will be prioritized, and the incident handlers will take action to ensure that the progress of the incident is halted and that the affected systems return to normal operation as soon as possible.”

What are the key elements here?

• Detection & Analysis
• Containment & Eradication
• Return to normal operation as soon as possible.

I’ll give an example here. During a response process you will conduct an impact assessment (this will typically be iterative as new intelligence comes in) however it’s probable that at some point in the incident you will have a reasonable level of intelligence to suggest the threat is contained and eradicated. You will then need to consider service restoration options. These may include:

• Removal of malicious processes
• Disabling/resetting compromised user accounts
• Revoking compromised sessions
• Key ‘rotation’ (changing passwords etc.)

However, it may also include:

• Restoring from a ‘known good’ backup
• Re-creating a system and restoring ‘clean’ data (from backups or a replica) into the system
• It can require a level or re-architecture, however that is not the goal, that might become a critical dependency based on the specifics on an incident scenario when other options are not available.

So, in short:

1. Clean the live system
2. Restore from a known good state (typically from backups/archives or replicas)
3. Re-create the system (and restore data if possible)

This is in line with the goal to ‘restore normal operations as soon as possible’ (to prevent further disruption and negative business impact).

The goal of incident response (handling) is NOT to:

• Re-architect the entire business or service (this is a programme or project)
• Conduct security assurance of the entire service/enterprise (this is a programme or project)
• Act as security assurance for an enterprise (this is a business capability)

If an organisation chooses NOT to restore service to a known good state, they can of course take that decision, however that is not a task for a response team (they might be transferred to a recover team though!)

So key points:

• Identify the threat
• Contain/Isolate and Eradicate the Threat
• Return to ‘normal operations’ (a previously known good state) as soon as reasonably possible (ensuring the exploited vulnerability is mitigated)

A good friend of mine, Phat Hobbit (Ian Thornton-Trump) said this and I was like, amazingly cool description:

‘Incident Response is first aid not surgery!’

Summary

Incident response is not a process to fix all security flaws or gaps in an enterprise, it does however have findings and lessons learnt that may act as inputs for project activities. If you can restore with reasonable confidence that the incident initiating threat has been eradicated and compromise from the same vector is unlikely, then the goal is to restore service, there is however like all things, the ability for an organisation to choose to NOT do this, but that’s not a goal of incident response, that is something else!

References

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf