Corrective Action Plan (CAP) là danh sách thay đổi được ưu tiên sau security incident để giảm khả năng sự cố lặp lại hoặc giảm impact nếu nó tái diễn. CAP không nên là “wishlist hardening” chung chung; mỗi action cần nối được với evidence, root cause, contributing factor hoặc control gap đã quan sát trong incident.
Một CAP tốt giúp đội vận hành trả lời bốn câu hỏi: sửa gì trước, ai chịu trách nhiệm, khi nào xong và bằng cách nào chứng minh thay đổi có hiệu lực.
Corrective Action khác remediation trong incident như thế nào?
Remediation trong incident tập trung đưa hệ thống về trạng thái an toàn và hoạt động được: loại bỏ persistence, revoke credential, patch lỗ hổng, restore hoặc repair. Corrective action đi xa hơn: sửa control, process và monitoring để giảm risk dài hạn.
Ví dụ vá plugin bị khai thác là remediation; bổ sung vulnerability review, change control và alert khi plugin thay đổi bất thường là corrective action.
Nguồn đầu vào cho Corrective Action Plan
- Root Cause Analysis.
- Post-Incident Review & Lessons Learned.
- Security Incident Report và residual risk.
- Detection gap, false negative hoặc alert noise đã quan sát.
- Recovery/backup gap và credential issue.
- Open evidence gap có thể ảnh hưởng risk.
Phân loại corrective action theo lớp kiểm soát
Identity và access
MFA, least privilege, session lifecycle, account review, credential rotation, break-glass access và thu hồi quyền sau bàn giao.
Application và supply chain
Patch/update policy, plugin/theme governance, dependency inventory, deployment control, code review và giảm attack surface.
Infrastructure và configuration
File permission, server hardening, secret handling, backup isolation, WAF/CDN/DNS control và configuration baseline.
Detection và response
Logging, alert rule, baseline, runbook, incident contact, evidence collection, recovery test và post-incident monitoring.
Ưu tiên action theo risk, không theo độ dễ làm
Action dễ làm không nhất thiết quan trọng nhất. Một phương pháp thực dụng là chấm theo bốn yếu tố: risk reduction, likelihood of recurrence, blast radius và implementation dependency.
| Priority | Đặc điểm | Ví dụ |
|---|---|---|
| P1 | Control gap có thể dẫn tới compromise lặp lại ngay hoặc impact lớn | Credential vẫn còn hiệu lực, persistence path chưa chặn, vulnerable component vẫn public |
| P2 | Giảm đáng kể likelihood/impact nhưng có mitigation tạm thời | MFA rollout, backup isolation, alert cho admin creation |
| P3 | Cải thiện resilience hoặc giảm thời gian phát hiện/xử lý | Runbook refinement, dashboard, change documentation |
| P4 | Nice-to-have hoặc optimization ít ảnh hưởng tới risk hiện tại | Automation tiện ích, reporting polish |
Mẫu Corrective Action Record
| Trường | Nội dung cần ghi |
|---|---|
| Action ID | Mã duy nhất |
| Source | RCA finding, lesson hoặc control gap |
| Risk addressed | Risk cụ thể action cần giảm |
| Action | Thay đổi cụ thể, tránh mô tả mơ hồ |
| Priority | P1–P4 hoặc hệ thống nội bộ tương đương |
| Owner | Người/đội chịu trách nhiệm |
| Due date | Thời hạn có lý do |
| Dependency | Hệ thống, vendor hoặc change cần trước |
| Rollback | Cách khôi phục nếu triển khai gây lỗi |
| Verification | Test/evidence chứng minh action có hiệu lực |
Action phải có verification chứ không chỉ trạng thái “done”
Đánh dấu ticket hoàn thành không chứng minh risk đã giảm. Verification nên bám vào mục tiêu control.
Ví dụ verification tốt
- MFA: thử account đặc quyền mới và xác nhận không thể đăng nhập chỉ bằng password.
- Alert rule: tạo event test và xác nhận alert tới đúng owner trong pipeline thực.
- Backup: restore test sang môi trường kiểm soát và xác minh integrity.
- WAF rule: replay request test an toàn và xác nhận malicious pattern bị chặn nhưng traffic hợp lệ không lỗi.
- Credential rotation: xác nhận credential cũ không còn hoạt động và app vẫn dùng secret mới.
Tránh 5 lỗi khi lập Corrective Action Plan
- Biến CAP thành danh sách hardening không liên quan incident.
- Ghi action kiểu “cải thiện bảo mật” không có scope.
- Không có owner hoặc due date.
- Ưu tiên theo độ dễ làm thay vì risk.
- Đóng action khi deploy xong nhưng chưa verification.
Khi nào có thể đóng một corrective action?
Một action chỉ nên đóng khi thay đổi đã triển khai, verification PASS, side effect chính đã được kiểm tra và evidence được lưu. Nếu risk được chấp nhận thay vì sửa, cần ghi risk owner và lý do acceptance.
Action chưa xong không nhất thiết giữ Incident Response mở nếu closure criteria đã đạt và residual risk có owner. Nhưng CAP phải tiếp tục được theo dõi như backlog quản trị rủi ro.
CAP phải quay lại monitoring và readiness
Corrective action liên quan detection cần được đưa vào monitoring maintenance; action liên quan process phải cập nhật runbook/readiness. Sau khi đóng nhóm action quan trọng, dùng Incident Response Readiness Checklist để xác nhận khả năng phản ứng đã thực sự tốt hơn.
Baseline tham khảo
NIST SP 800-61 Rev. 3 nhấn mạnh Incident Response là một phần của cybersecurity risk management liên tục. CISA playbook cũng coi tracking successful mitigations là một phần của quy trình phản ứng chuẩn hóa. Vì vậy CAP nên được quản lý như risk-reduction work có evidence chứ không phải phụ lục mang tính hình thức.