Security Incident Report là hồ sơ tổng hợp một security incident theo cách người khác có thể hiểu, kiểm chứng và hành động tiếp. Báo cáo tốt không chỉ kể lại “website đã bị hack như thế nào”; nó nối evidence, timeline, impact, quyết định containment, recovery và corrective action thành một bản ghi có thể dùng cho vận hành, quản trị rủi ro và post-incident review.
Không có một mẫu duy nhất phù hợp cho mọi website. Mức chi tiết phụ thuộc severity, dữ liệu liên quan, nghĩa vụ nội bộ và yêu cầu pháp lý. Tuy nhiên, cấu trúc nên tách rõ fact, assessment, decision và open action để tránh biến giả thuyết thành kết luận.
Security Incident Report khác Incident Timeline như thế nào?
Incident Timeline tập trung vào thứ tự sự kiện theo thời gian. Security Incident Report rộng hơn: nó giải thích phạm vi, impact, root cause, hành động đã thực hiện, residual risk và việc gì còn phải làm.
Timeline thường là một phần của report, không phải toàn bộ report.
Cấu trúc Security Incident Report nên có những phần nào?
1. Executive summary
Tóm tắt ngắn: incident là gì, được phát hiện khi nào, asset nào bị ảnh hưởng, severity cuối cùng, trạng thái hiện tại và business impact chính. Phần này nên đủ cho người không trực tiếp điều tra hiểu tình hình mà không cần đọc toàn bộ log.
2. Detection và activation
Ghi nguồn phát hiện, signal ban đầu, thời điểm alert, cách xác minh và tiêu chí khiến đội mở Incident Response. Nếu activation từng thay đổi severity, cần ghi lý do.
Liên kết với tiêu chí kích hoạt Incident Response và severity P1–P4.
3. Scope và impact
Liệt kê asset, account, credential, dữ liệu và chức năng bị ảnh hưởng; phân biệt confirmed affected, suspected và cleared. Impact nên tách confidentiality, integrity và availability thay vì chỉ ghi “website bị lỗi”.
4. Timeline và evidence
Trình bày các event chính theo timestamp đã chuẩn hóa, kèm evidence ID hoặc nguồn log. Không cần nhúng toàn bộ log vào thân báo cáo; nên tham chiếu tới evidence repository hoặc phụ lục có kiểm soát.
5. Containment, eradication và recovery
Ghi action nào đã thực hiện, owner, thời điểm, lý do, verification và rollback nếu có. Với cleanup malware, cần phân biệt containment tạm thời với remediation lâu dài.
6. Root cause và contributing factors
Nêu root cause với mức confidence, entry point nếu xác định được, persistence và các contributing factor như thiếu patch, quyền quá rộng, logging thiếu hoặc process chưa rõ. Nếu chưa đủ evidence, ghi rõ evidence gap thay vì suy đoán.
7. Residual risk và corrective action
Báo cáo không nên kết thúc ở “đã khôi phục”. Cần ghi rủi ro còn lại, owner chấp nhận rủi ro và danh sách corrective action có priority, owner, due date và verification.
Mẫu cấu trúc báo cáo thực dụng
| Phần | Nội dung tối thiểu | Evidence/owner |
|---|---|---|
| Incident metadata | ID, severity, start/detect/close time | Incident owner |
| Executive summary | What happened, scope, impact, status | Incident commander |
| Detection | Signal, source, confidence, activation | Monitoring/triage |
| Scope | Affected/suspected/cleared assets | Investigation record |
| Timeline | Key events + timestamp + timezone | Log/evidence IDs |
| Response actions | Containment, eradication, recovery | Action records |
| RCA | Root cause, entry point, confidence | RCA evidence |
| Residual risk | Risk left + acceptance | Risk owner |
| Corrective actions | Action, owner, priority, due date | CAP backlog |
Fact, hypothesis và decision phải được tách riêng
Một lỗi phổ biến là biến assessment chưa chắc chắn thành fact trong báo cáo. Ví dụ “IP X xuất hiện trong access log” là fact; “IP X là attacker” có thể chỉ là hypothesis nếu chưa có correlation đủ mạnh.
Mỗi kết luận quan trọng nên có evidence hoặc confidence. Cách này giúp report vẫn hữu ích khi có evidence mới sau closure.
Báo cáo cho lãnh đạo và báo cáo kỹ thuật có thể khác nhau
Cùng một incident có thể có executive report và technical appendix. Executive report tập trung impact, decision, residual risk và corrective action; technical appendix giữ timeline chi tiết, log source, IOC, artefact và phương pháp verification.
Không nên đưa secret, password, token hoặc dữ liệu nhạy cảm trực tiếp vào bản report được chia sẻ rộng. Với incident có nhiều stakeholder, nội dung report nên đồng bộ với quy trình giao tiếp với khách hàng và nội bộ khi website gặp security incident để tránh thông điệp lệch giữa technical team và business owner.
Quality gate trước khi phát hành Incident Report
- Incident ID, severity và thời gian dùng cùng một chuẩn timezone.
- Scope khớp với evidence cuối cùng.
- Fact và hypothesis được phân biệt.
- Root cause có confidence hoặc evidence gap.
- Mọi action quan trọng có owner và timestamp.
- Residual risk có người chấp nhận phù hợp.
- Corrective action có owner, priority, due date và verification.
- Không chứa credential hoặc dữ liệu nhạy cảm ngoài phạm vi cần thiết.
Report nên dẫn sang bước nào tiếp theo?
Sau khi incident ổn định, report là đầu vào trực tiếp cho Post-Incident Review & Lessons Learned và Corrective Action Plan. Nếu incident chưa đủ điều kiện đóng, quay lại Incident Closure Checklist.
Nguồn tham khảo
NIST SP 800-61 Rev. 3 xem Incident Response là một phần của quản trị rủi ro xuyên suốt CSF 2.0; CISA Incident Response Playbook nhấn mạnh quy trình chuẩn hóa để nhận diện, phối hợp, remediation, recovery và theo dõi mitigation. Với website, report nên phản ánh chính các quyết định và evidence trong vòng đời này thay vì chỉ là biên bản kết thúc.