31. SOC, SIEM and Incident Response
31.6 The Incident Response Lifecycle
The widely used NIST incident response lifecycle (NIST SP 800-61) has four phases:
- Preparation – plans, contacts, tools, logging, backups and training before anything happens.
- Detection and Analysis – spot the incident (SIEM alert, user report, GuardDuty), confirm it and understand its scope.
- Containment, Eradication and Recovery – stop the spread, remove the attacker, restore systems safely.
- Post-Incident Activity – lessons learned, fix root causes, improve detection.
Many trainings also use the six-step PICERL model: Preparation, Identification, Containment, Eradication, Recovery, Lessons learned. Same idea, more steps.
Worked example (fictional): "Shivneri Traders" web server compromise
| Phase | What the team did |
|---|---|
| Detection | Wazuh alert: many failed SSH logins, then Accepted password for user deploy from an unknown IP at 02:10. Then a new user support2 was created. |
| Analysis | L2 checked /var/log/secure, last, /etc/passwd, crontab and running processes; found a crypto-miner in /tmp and a cron job restarting it. |
| Containment | Security group changed to allow only the office IP; attacker IP blocked; EBS snapshot taken before changes to preserve evidence (Chapter 28). |
| Eradication | Removed support2, the cron job and the miner; changed all passwords; disabled SSH password login, keys only (Chapter 32). |
| Recovery | Rebuilt the server from a clean AMI, restored the site from backup, monitored closely for two weeks. |
| Lessons learned | Root cause was a weak password on deploy with SSH open to the world. Actions: key-only SSH, fail2ban, MFA on the AWS console, a Wazuh rule for "new user created". |
In India, certain cyber security incidents must be reported to CERT-In within a short time limit under its 2022 directions (details in Chapter 34), so the IR plan must include who reports and how.
Ravindra Bagale's Tip
After a hack, students immediately delete or reboot the server – and then the evidence is gone! First isolate it and take a snapshot/image, then clean it. And if you just rebuild without knowing "how they got in" (the root cause), the attacker will come back the same way.
Ravindra Bagale's Tip – मराठी
Hack झाल्यावर students लगेच server delete करतात किंवा reboot करतात – मग evidence गेला! आधी isolate करा आणि snapshot/image घ्या, मग clean करा. आणि "कसा आत आला" (root cause) हे कळल्याशिवाय फक्त rebuild केले तर attacker त्याच मार्गाने पुन्हा येईल.
Ravindra Bagale's Tip – हिंदी
Hack के बाद students तुरंत server delete या reboot कर देते हैं – फिर evidence गया! पहले isolate करो और snapshot/image लो, फिर clean करो. और "अंदर कैसे आया" (root cause) जाने बिना सिर्फ़ rebuild किया तो attacker उसी रास्ते से फिर आएगा.
Lab
Write a one-page incident report for the Shivneri Traders example using the headings: Summary, Timeline, Impact, Root cause, Actions taken, Lessons learned. Then simulate the start of it in your lab: create a user support2 on the agent VM and confirm Wazuh raises an alert for the new user.
SOC quick reference
| Need | Where / what |
|---|---|
| Linux SSH/sudo logs | /var/log/secure (RHEL/Amazon Linux), /var/log/auth.log (Ubuntu/Kali) |
| Web logs | /var/log/httpd/, /var/log/nginx/ |
| Windows logons | Event IDs 4624 success, 4625 failure, 4720 user created |
| AWS | CloudTrail, GuardDuty, VPC Flow Logs |
| Free lab SIEM | Wazuh (manager + agents) |
| IR phases (NIST) | Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-incident |