Incident Response
Containment – Technical Containment for Security Incidents
Containment is the most critical phase of any incident response. The goal is to rapidly stop an ongoing compromise, prevent further spread, and stabilize your systems — without destroying forensic evidence.
🛑 Stop the attack
Interrupt lateral movement
Preserve evidence
Retain forensic artifacts
Stabilize
Restore controlled operational security
Why containment is critical
In real-world incidents we typically see:
- lateral movement across the network
- active compromised accounts
- persistence mechanisms
- undetected data exfiltration
Every hour of delay increases:
- overall damage
- regulatory pressure
- recovery costs
Containment shortens this window.
Containment objectives
🎯 Primary
- stop attacker movement
- interrupt command & control
- isolate compromised assets
Secondary
- preserve evidence
- gain situational awareness
- maintain operational capability
⛔ Not part of containment
- system rebuilds
- cleanup activities
- hardening
Typical technical scope
Network & Infrastructure
- segmentation / isolation of affected hosts
- blocking known IOC IPs & domains
- restricting east–west traffic
- disabling compromised VPN access
Identity & Access
- disabling compromised accounts
- token invalidation
- emergency MFA activation
- analysis of privileged access paths
Endpoints & Servers
- EDR containment (Defender / CrowdStrike / SentinelOne)
- live response sessions
- acquisition of volatile artifacts
- identification of active processes
Cloud / M365 / Entra ID
- review of suspicious sign-ins
- conditional access hardening
- review of service principals
- API token rotation
When is containment required?
Typical triggers
- malware / ransomware
- admin anomalies
- cloud account takeover
- data exfiltration
- SIEM / MDR escalation
Real-world situations
- unclear root cause
- partial visibility
- operational pressure
- management escalations
Our containment process
1) Triage
Assess situation
2) Isolation
Stop spread
3) Preservation
Preserve evidence
4) Stabilization
Secure operations
Common mistakes
- immediate system rebuilds
- uncoordinated password resets
- power-off instead of isolation
- no clear incident ownership
- missing evidence preservation
What you should prepare
- alerts / screenshots
- affected systems
- short timeline
- actions already taken
- decision maker
Outcomes (Deliverables)
Management situation brief
compromised assets
attack hypothesis
next steps
GDPR / NIS2 context
Technical foundation for:
- data exfiltration assessment
- notification decisions
- proof of due diligence
FAQ
Reset passwords immediately?
Yes — but coordinated.
Power off systems?
No. Isolate instead.
Start time?
1–2 business days, faster for active incidents.