Post-Incident Review là buổi review có cấu trúc sau khi security incident đã ổn định để xác định điều gì đã xảy ra, điều gì xử lý tốt, điểm nào thất bại và thay đổi nào cần được thực hiện tiếp. Mục tiêu của Lessons Learned không phải tìm người để đổ lỗi mà là biến evidence của incident thành cải tiến có owner và verification.
Review nên dựa trên timeline, report, RCA và quyết định thực tế trong incident. Nếu buổi họp chỉ dựa vào trí nhớ hoặc ý kiến mạnh nhất trong phòng, kết luận dễ lệch khỏi evidence.
Khi nào nên tổ chức Post-Incident Review?
Review nên diễn ra sau khi incident đã qua trạng thái khẩn và đủ evidence chính đã được bảo toàn, nhưng không nên chờ quá lâu đến mức context bị mất. Không có một mốc ngày cố định cho mọi tổ chức; severity và độ phức tạp quyết định thời điểm phù hợp.
Trước review, kiểm tra Incident Closure Checklist và bảo đảm các open issue quan trọng đã được ghi nhận.
Ai nên tham gia?
Incident owner và technical responders
Những người trực tiếp triage, containment, investigation và recovery cung cấp context về quyết định kỹ thuật, evidence gap và giới hạn trong quá trình xử lý.
System hoặc business owner
Owner giúp đánh giá impact thực tế, residual risk và mức ưu tiên của corrective action.
Monitoring, development và infrastructure
Nếu incident liên quan alert, code, plugin/theme, server, CDN/WAF hoặc DNS thì các owner tương ứng nên tham gia để action sau review có thể thực thi.
Input cần chuẩn bị trước buổi Lessons Learned
- Security Incident Report bản hiện hành.
- Incident Timeline và key evidence.
- Severity changes và decision log.
- Root Cause Analysis cùng confidence/evidence gap.
- Containment, recovery và rollback records.
- Danh sách alert/detection đã hoạt động hoặc đã bỏ sót.
- Open corrective action hiện có.
Các câu hỏi Lessons Learned nên trả lời
Detection
Signal nào phát hiện incident? Phát hiện sớm hay muộn? Alert nào có noise? Có telemetry nào thiếu khiến investigation chậm?
Triage và scope
Activation có đúng lúc không? Severity ban đầu có hợp lý không? Scope có bị đánh giá quá hẹp hoặc quá rộng? Những evidence gap nào làm chậm quyết định?
Containment và recovery
Biện pháp containment nào hiệu quả? Action nào gây side effect? Recovery gate có đủ rõ? Rollback có khả dụng không?
Communication và coordination
Ai cần thông tin nhưng nhận quá muộn? Handoff có mất context? Có quyết định nào bị chậm vì không rõ owner hoặc authority?
Prevention và resilience
Control nào thất bại hoặc không tồn tại? Điều gì cần hardening? Backup, logging, credential, deployment hoặc monitoring cần thay đổi gì để giảm likelihood hoặc impact nếu sự cố tương tự lặp lại?
Blameless không có nghĩa là bỏ qua trách nhiệm
Blameless review tập trung vào system, process, information và decision context thay vì quy kết cá nhân. Tuy nhiên action vẫn cần owner cụ thể. “Không đổ lỗi” không đồng nghĩa “không ai chịu trách nhiệm sửa”.
Mẫu Lessons Learned Record
| Trường | Nội dung |
|---|---|
| What worked | Control, alert hoặc process giúp giảm impact |
| What failed | Control/process không hoạt động như kỳ vọng |
| What was missing | Telemetry, owner, access, runbook, backup… |
| Decision friction | Nơi thiếu dữ liệu hoặc authority làm chậm xử lý |
| Evidence gap | Điều chưa thể kết luận và lý do |
| Lesson | Bài học có thể tái sử dụng cho incident sau |
| Action | Thay đổi cụ thể cần thực hiện |
| Owner / due date | Người chịu trách nhiệm và thời hạn |
| Verification | Cách chứng minh action đã có hiệu lực |
Từ lesson sang corrective action
Một lesson chỉ có giá trị khi được chuyển thành thay đổi có thể kiểm chứng. “Cần monitoring tốt hơn” quá mơ hồ; “thêm alert cho admin creation ngoài change window, owner Security Ops, test bằng event mô phỏng” là action có thể đóng.
Đưa các action sang Corrective Action Plan sau sự cố để ưu tiên theo risk và theo dõi đến khi verification PASS.
Quality gate cho Post-Incident Review
- Kết luận dựa trên evidence chứ không chỉ memory.
- Fact, hypothesis và opinion được phân biệt.
- Root cause và contributing factor không bị trộn lẫn.
- Mỗi lesson quan trọng có action hoặc lý do không action.
- Mỗi action có owner, priority, due date và verification.
- Open evidence gap được giữ lại nếu vẫn có ảnh hưởng tới risk.
- Detection/monitoring rule được cập nhật khi incident tạo signal mới.
Lessons Learned phải quay trở lại readiness
Post-Incident Review không phải bước cuối tách biệt. NIST SP 800-61 Rev. 3 đặt Incident Response trong quản trị rủi ro liên tục; bài học sau incident cần quay trở lại preparation, detection, response và recovery để hệ thống tốt hơn trước lần sau.
Sau khi action đã được tạo, dùng Incident Response Readiness Checklist để xác minh những cải tiến quan trọng đã thực sự đi vào readiness.