12.14 Lessons Learned and Post-Incident Review

Lessons Learned and Post-Incident Review

The incident is closed. The hardening is underway. The detection rules are deployed. The final step: a structured post-incident review (PIR) that extracts maximum value from the experience and prevents the same failures from recurring.

Conduct the PIR within 5 business days of incident closure while the details are fresh.

PIR agenda for INC-2026-0227-001

1. Timeline review. Walk through the chronological timeline from first phishing email (27 Feb 08:45) to final containment (28 Feb 18:30). For each event: was it detected by automated detection, discovered during investigation, or reported by a user? The ratio tells you how much of the attack your detection covered vs how much required human investigation.

For this incident: Wave 1 was detected by an analytics rule (automated). Waves 2-4 were discovered during the investigation (human). Wave 5 was detected by the CFO reporting a suspicious email (user). This means automated detection caught the initial compromise but did not catch the internal phishing or the BEC attempt. The detection engineering work in subsection 12.13 closes these gaps.

2. Detection assessment. How quickly did the first alert fire after the first compromise? The phishing click occurred at 08:52. The sign-in from the attacker IP occurred at 08:54. The analytics rule fired at 09:17 — a 23-minute detection lag. This is the rule’s schedule interval plus Sentinel ingestion latency. An NRT version of the same rule would have fired within 2-3 minutes.

Action item: convert the detection rule from scheduled to NRT for faster detection of AiTM initial access.

3. Response assessment. Containment was executed at 18:30 on 28 February — approximately 34 hours after the first compromise. Why? The first 2 hours were investigation (appropriate). The next 6 hours were after-hours with no SOC coverage. The following morning, the investigation expanded as Waves 2-4 were discovered. Containment was delayed because each new wave required re-scoping before containment could be executed.

Action item: define a containment trigger threshold — “if AiTM is confirmed for any account, revoke tokens and reset password immediately. Do not wait for full scope assessment.” Parallel track: investigate scope WHILE containment is being executed.

4. Prevention assessment. Could this attack have been prevented entirely? Yes — conditional access token protection (token binding) would have prevented every token replay in the campaign. The control was available (E5 licensing) but not deployed. Why? It was not in the security roadmap because the risk was not prioritised.

Action item: deploy token protection (subsection 12.12, Recommendation 1). Conduct a review of available-but-not-deployed controls in the tenant to identify other gaps.

5. Communication assessment. Were stakeholders notified appropriately and on time? The CISO was briefed at 10:00 on 27 February (within 1 hour of detection — good). The affected users were notified after containment (appropriate). The CFO’s report of the BEC attempt was received at 16:15 on 28 February and correlated with the investigation within 30 minutes (good).

No action items on communication for this incident.

6. Data coverage assessment. Were all necessary log sources available? UrlClickEvents was populated (Safe Links enabled). CloudAppEvents was populated (Defender XDR connector active). SigninLogs and AuditLogs were populated. No data gaps that impeded investigation.

Action item: none for this incident. Document the positive finding — data coverage was sufficient.

PIR output document

Compliance mapping: NIST CSF RS.IM-1 (Response plans incorporate lessons learned). ISO 27001 A.5.27 (Learning from information security incidents). SOC 2 CC7.5 (The entity identifies, develops, and implements activities to recover from identified security incidents).

The feedback loop

This PIR connects three operational processes:

Incident response → Detection engineering. The investigation found 4 detection gaps. The detection engineering work in 11.13 produced 8 rules to close them. The monthly detection review (Module 10.11) tracks these rules’ effectiveness.

Incident response → Hardening. The investigation identified 4 preventive control gaps. The hardening recommendations in 11.12 address each one. The quarterly security posture review tracks deployment progress.

Incident response → Hunting. The investigation revealed attacker TTPs (AiTM proxy, token replay, inbox rules, internal phishing, BEC). These TTPs feed the hunting hypothesis backlog (subsection 12.11): “Hunt for AiTM indicators monthly using the queries from this module.”

This is the complete operational cycle: detect → investigate → contain → eradicate → report → harden → engineer detections → hunt. Modules 1-10 taught the individual skills. Module 12 demonstrated the complete cycle on a real incident.

Subsection artifact: The PIR output table and feedback loop documentation. Reusable for any incident — modify the findings and action items for each case.

Knowledge check