Incident Closure là quyết định chính thức rằng một website security incident đã được xử lý đến mức có thể chuyển từ phản ứng khẩn sang theo dõi và cải tiến bình thường. Website online trở lại chưa đủ để đóng incident.
Closure cần evidence rằng containment ổn định, recovery đã kiểm chứng, residual risk được hiểu và chấp nhận bởi đúng owner, còn các corrective action dài hạn đã có người chịu trách nhiệm. Nếu một khoảng trống quan trọng vẫn chưa có owner hoặc chưa có cách theo dõi, incident chưa nên đóng chỉ để giảm số ticket.
Điều kiện nền trước khi xem xét đóng incident
Containment ổn định và scope đủ rõ
Không còn activity trái phép mới trong phạm vi đã biết, không có bằng chứng persistence tiếp tục hoạt động và các asset liên quan đã được phân loại confirmed affected, suspected hoặc cleared theo tiêu chí xác định.
Recovery đã hoàn tất ở mức chấp nhận được
Critical function đã test, credential rủi ro đã xử lý, integrity của file/database/config đã được xác minh và monitoring hoạt động. Xem Incident Recovery Plan để kiểm tra recovery gate trước closure. Một case thực tế về việc recovery phải đi qua eradication, credential rotation và post-recovery monitoring trước khi closure là khôi phục Website sau Security Incident mà không tái nhiễm.
Root cause hoặc evidence gap đã được ghi nhận
Không phải incident nào cũng tìm được root cause với confidence tuyệt đối. Tuy nhiên cần tách rõ điều gì đã xác nhận, điều gì còn là hypothesis và evidence gap nào vẫn tồn tại. Nếu khoảng trống có thể làm thay đổi đáng kể phạm vi hoặc mức rủi ro, chưa nên đóng.
Incident Closure Checklist
| Nhóm | Tiêu chí closure | Evidence |
|---|---|---|
| Containment | Attack/persistence không còn active trong scope đã biết | Monitoring + timeline |
| Eradication | Artefact độc hại và cơ chế persistence đã xử lý | Review/retest |
| Credential | Session, token và key rủi ro đã revoke/rotate | Rotation record |
| Integrity | File, database và config đã xác minh | Baseline/known-good review |
| Recovery | Critical function hoạt động bình thường | Functional test |
| Monitoring | Post-incident monitoring đang chạy | Telemetry + alert test |
| RCA | Root cause hoặc evidence gap được ghi rõ | RCA record |
| Actions | Open corrective action có owner, priority và due date | Action backlog |
Closure không yêu cầu residual risk bằng 0
Incident có thể đóng khi rủi ro còn lại đã được hiểu, có owner chấp nhận và có kế hoạch xử lý. Không nên giữ incident mở vô thời hạn chỉ vì còn backlog hardening dài hạn.
Ngược lại, residual risk chưa được định danh, chưa có người chấp nhận hoặc có thể dẫn tới compromise lặp lại thì chưa đủ điều kiện closure.
Mẫu Closure Decision Record
| Trường | Nội dung |
|---|---|
| Incident ID | Mã sự cố |
| Closure time | Timestamp + timezone |
| Approver | Owner có quyền đóng incident |
| Scope summary | Asset/account/data bị ảnh hưởng |
| Root cause | Kết luận + confidence/evidence gap |
| Residual risk | Rủi ro còn lại + người chấp nhận |
| Open actions | Owner + priority + due date |
| Monitoring period | Signal và thời gian theo dõi tiếp |
| Reopen trigger | Dấu hiệu buộc mở lại Incident Response |
Closure record nên nối được với Security Incident Report để giữ cùng một nguồn sự thật về scope, impact, timeline, RCA, residual risk và corrective action.
Reopen trigger phải được định nghĩa trước
Closure không phải điểm không thể quay lại. Nếu IOC cũ tái xuất hiện, credential cũ tiếp tục được sử dụng, persistence mới xuất hiện, scope mở rộng hoặc hypothesis về root cause bị evidence mới phủ định, incident cần được mở lại và quay về triage.
Khi nào tuyệt đối chưa nên đóng incident?
- Attacker activity hoặc command execution vẫn xuất hiện.
- Chưa biết persistence đã được loại bỏ hay chưa.
- Credential hoặc session cũ vẫn truy cập được ngoài kế hoạch.
- Website online nhưng critical function chưa test.
- Monitoring không quan sát được signal liên quan sự cố.
- Scope còn asset nghi ngờ nhưng chưa có owner xử lý.
- Residual risk quan trọng chưa được chấp nhận bởi người có thẩm quyền.
Sau closure: monitoring, lessons learned và corrective action
Tiếp tục Post-Incident Monitoring
Closure không đồng nghĩa dừng theo dõi. Sau incident nên có cửa sổ monitoring tăng cường để phát hiện reuse credential, IOC cũ, file change hoặc behavior bất thường. Xem Post-Incident Monitoring.
Chuyển phát hiện thành Lessons Learned
Sau khi trạng thái khẩn kết thúc, review cần trả lời điều gì đã xảy ra, control nào thất bại, detection nào chậm và process nào cần cải tiến. Mục tiêu là cải thiện hệ thống chứ không phải tìm người để đổ lỗi. Tiếp tục với Post-Incident Review & Lessons Learned.
Nếu incident có ảnh hưởng tới người dùng, khách hàng hoặc nhiều team nội bộ, closure cũng nên kiểm tra rằng incident communication với khách hàng và nội bộ đã phản ánh đúng fact, trạng thái recovery và residual risk cần công bố.
Quality gate cuối cùng
- Closure decision có approver.
- Evidence chính được lưu và liên kết incident record.
- Residual risk được ghi rõ và có owner.
- Open action có priority và due date.
- Monitoring tiếp tục theo kế hoạch.
- Reopen trigger đã xác định.
- Post-incident review đã được lên lịch.
Khi các điều kiện trên có evidence tương ứng, incident có thể chuyển sang trạng thái closed/monitoring mà không đánh mất trách nhiệm đối với corrective action còn lại.
Nguồn kỹ thuật
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations
- CISA — Cybersecurity Incident & Vulnerability Response Playbooks
Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem dịch vụ ứng cứu sự cố.