Incident Response and when to consider an incident resolved

Question

I am currently making amendments to an IR process and the topic of incident closure has come up. The organisation follows NIST and therefore their IR process has four phases:

• Preparation
• Detection & Analysis
• Containment, Eradication & Recovery
• Post-Incident activity

My proposal is that an incident can be deemed resolved once a post-mortem meeting or meetings have been conducted and concluded. Any recommendations or activities identified as part of this phase are considered outside the scope of responding to an incident. When considering the phases above, anything that comes out of the Post-Incident activity feeds directly into the Preparation phase.

My thinking here is that in some cases, a post-incident recommendation may be significant and require project management. There seems to be an appetite for an incident to be considered unresolved as long as post-incident recommendations have not yet been implemented. My reluctance here is that this will impact SOC performance metrics.

Interested to get thoughts on this and how the topic of incident closure is handled within other organisations.

Answer 1

My reluctance here is that this will impact SOC performance metrics.

So, your process of resolving an incident has 2 distinct stakeholders:

• the SOC team to measure "Time to Resolution"
• the infosec team to ensure "Lessons Learned" are properly actioned

Those 2 stakeholders are at odds with each other. And you're trying to get clever at satisfying both parties.

I wouldn't take a NIST or even an infosec approach to trying to address this. This is a pure process design issue.

The resolution date belongs to the SOC. The ticket is theirs and their responsibility comes to an end long before the various projects end. The infosec team needs to find another tool to track the projects it wants to generate and stop leveraging the ticketing tools as its project management tool.

If that doesn't work, add a new date to the ticketing system to reflect when the Response phase ends, and use that for your SOC performance metrics.

Answer 2

In classic Agile parlance, I would consider the post-mortem to Close the incident, while the end of the incident would be declared when the DoD CJCSM 6510.1B incident table category for root/user compromise or malicious logic installation/execution has been Resolved.

Resolve incident first; then Close