Incident Response
Incident Response Starts Before Anyone Types "We Have a Situation"
Nobody wants to discover an incident response plan for the first time during an incident.
Yet that happens.
Someone notices strange authentication activity.
A server starts behaving differently.
An employee reports a suspicious email.
An endpoint begins communicating with an unfamiliar destination.
Suddenly everyone wants to know:
What do we do?
That is the point of incident response.
Incident Response Starts Before the Incident
NIST's current incident response guidance, SP 800-61 Rev. 3, emphasizes incorporating incident response throughout cybersecurity risk management and improving preparation, detection, response, and recovery activities.
That means incident response isn't simply a collection of commands for emergencies.
Preparation matters.
Before something happens, an organization should understand:
Who responds?
Who has authority?
Who gets notified?
What systems are critical?
Where are logs?
How is evidence preserved?
How are systems isolated?
Who communicates externally?
How are recovery decisions made?
Those questions are much easier to answer on a Tuesday afternoon than during a ransomware event.
The Classic Incident Response Lifecycle
NIST's earlier incident handling guidance described four major areas:
Preparation
Detection and analysis
Containment, eradication, and recovery
Post-incident activity
The current guidance aligns incident response more closely with the NIST Cybersecurity Framework 2.0, but the practical ideas remain familiar.
You prepare.
You detect.
You investigate.
You contain.
You remove the threat.
You recover.
Then you learn.
Preparation
Preparation is the part people skip because nothing exciting is happening.
That is exactly why it matters.
You want to know where your important assets are.
You want logging.
You want backups.
You want contact information.
You want procedures.
You want trained people.
You want the authority to make decisions.
And you want to test the plan.
A document sitting untouched in a shared drive is not an incident response capability.
Detection and Analysis
Something happens.
Now you need to determine whether it is actually an incident.
An alert isn't automatically an incident.
A failed login isn't automatically an attack.
A suspicious process isn't automatically malware.
The goal is to collect enough information to understand what is happening.
Questions might include:
What happened?
When did it start?
What systems are affected?
Which accounts are involved?
Is the activity still happening?
Is there evidence of compromise?
How far has it spread?
This is where logs become incredibly valuable.
Without useful telemetry, investigators may be forced to reconstruct events from incomplete evidence.
Containment
Once an incident is understood well enough, you may need to contain it.
Containment is about limiting damage and preventing additional spread.
That could involve actions such as:
Isolating an endpoint
Blocking network traffic
Disabling compromised credentials
Removing a system from service
Restricting access
Blocking malicious infrastructure
Containment can provide time to develop an appropriate remediation strategy.
The important point is that containment is a decision.
Pulling a server offline might stop an attack.
It might also take a critical business service offline.
Incident response requires technical judgment and business awareness.
Eradication
Containment limits the problem.
Eradication removes the underlying cause.
That could involve:
Removing malware
Patching vulnerabilities
Resetting credentials
Removing unauthorized accounts
Rebuilding systems
Correcting configurations
Eliminating persistence mechanisms
You don't want to simply make an attacker disappear for five minutes.
You want to remove their ability to come back.
Recovery
Eventually systems have to return to normal operation.
But recovery shouldn't mean:
"Everything turns back on. Good luck."
You want to validate systems.
Check that security controls are functioning.
Monitor for recurring activity.
Confirm that the root cause was addressed.
And verify that the environment is actually ready to return to normal operations.
Post-Incident Activity
This is the part organizations are often tempted to skip.
The incident is over.
Everyone is tired.
The ticket gets closed.
Everyone moves on.
That's a mistake.
Ask:
Why did this happen?
How was it detected?
What worked?
What failed?
What information did we wish we had?
What should change?
The goal isn't to find someone to blame.
The goal is to make the next incident less damaging.
The Uncomfortable Truth
A good incident response program doesn't guarantee that you won't have incidents.
That's not realistic.
The goal is to improve your ability to:
detect → understand → contain → recover → learn
The organizations that respond well aren't necessarily the ones that never have problems.
They're often the ones that prepared before the problem arrived.
Final Thought
Incident response isn't the emergency binder.
It's the people, processes, technology, authority, and practice behind that binder.
If your first incident response meeting begins with:
"Does anyone know who has access to the logs?"
you're already having a bad day.
Prepare before you need the plan.
Sources
NIST SP 800-61 Rev. 3, Incident Response Recommendations
NIST Computer Security Incident Handling Guide
NIST Cybersecurity Framework 2.0
