Incident Recovery Plan là kế hoạch đưa website trở lại vận hành sau khi containment và eradication đã đạt mức an toàn chấp nhận được. Recovery không đồng nghĩa với “website mở lại được”; nó phải chứng minh rằng hệ thống, credential, dữ liệu và monitoring đã sẵn sàng để quay lại production.
Một recovery tốt có tiêu chí trước–sau rõ ràng, owner cho từng action, rollback plan và verification thay vì chỉ restore backup rồi hy vọng mọi thứ ổn.
Recovery chỉ bắt đầu khi containment đủ ổn định
Nếu attacker vẫn còn active, persistence chưa được xử lý hoặc scope còn mở rộng nhanh, đưa website trở lại production có thể tái tạo compromise.
Trước recovery nên hoàn tất hoặc đủ confidence ở Root Cause Analysis, credential exposure và containment.
Recovery Plan cần bao phủ những lớp nào?
Application và file system
WordPress core, plugin, theme, uploads, MU-plugin, cron và config cần được khôi phục từ nguồn tin cậy hoặc sửa có kiểm chứng.
Database và content integrity
Kiểm tra user, option, scheduled task, content và dữ liệu quan trọng. Nếu restore database, xác minh snapshot không chứa persistence hoặc artefact đã có từ trước.
Identity và credential
Privileged account, session, SSH key, database secret và API key cần được review/rotate theo scope. Xem Credential Rotation sau compromise.
Edge, DNS và integration
WAF/CDN, DNS, webhook, SMTP, payment và service bên thứ ba cần được test để tránh recovery ở origin nhưng vẫn còn config độc hại ở lớp khác.
Recovery Gate: điều kiện trước khi đưa hệ thống vào production
| Gate | Tiêu chí | Evidence |
|---|---|---|
| Root cause | Entry point/persistence đã xử lý ở mức chấp nhận được | RCA + retest |
| Integrity | File/database/config khớp trạng thái tin cậy | Baseline, hash, review |
| Credential | Credential rủi ro đã revoke/rotate | Rotation record |
| Function | Login, form, checkout/API và chức năng chính test pass | Functional test |
| Monitoring | Alert/log/file integrity hoạt động | Test event + telemetry |
| Rollback | Có đường lui nếu recovery thất bại | Backup/snapshot + owner |
Một case thực tế cho thấy vì sao recovery gate phải kiểm cả eradication, credential và post-recovery monitoring là khôi phục Website sau Security Incident mà không tái nhiễm.
Recovery nên theo từng bước thay vì bật toàn bộ cùng lúc
- Khôi phục trusted infrastructure/config.
- Khôi phục application và database.
- Rotate/revoke credential liên quan.
- Test chức năng nội bộ hoặc ở chế độ hạn chế.
- Bật monitoring tăng cường.
- Mở traffic theo từng lớp nếu kiến trúc cho phép.
- Theo dõi error, security event và business function.
Mẫu Recovery Action Record
| Trường | Nội dung |
|---|---|
| Action | Restore, replace, rotate, reconfigure… |
| Owner | Người chịu trách nhiệm |
| Start/finish | Timestamp + timezone |
| Precondition | Gate phải pass trước action |
| Verification | Test chứng minh action thành công |
| Rollback | Cách quay lại trạng thái trước |
Restore backup không tự động chứng minh hệ thống sạch
Backup có thể đã được tạo sau initial compromise. Vì vậy cần xác định known-good point, đối chiếu timeline và test lại sau restore.
Nếu còn nghi ngờ malware/persistence, kiểm tra lại bằng các bước trong cluster cleanup malware WordPress trước khi public traffic trở lại.
Sau recovery phải có monitoring tăng cường
Thiết lập cửa sổ post-incident monitoring với signal liên quan RCA: login, file change, cron/MU-plugin, outbound request, WAF event và credential usage.
Xem tiếp cách theo dõi website sau incident. Sau khi trạng thái đã ổn định, đưa các control đã harden vào checklist rà soát và duy trì Website Hardening định kỳ để phát hiện drift sau recovery.
Khi nào Recovery Plan được coi là hoàn tất?
- Các recovery gate đã pass và có evidence.
- Business function quan trọng hoạt động bình thường.
- Không có IOC/persistence mới trong monitoring window ban đầu.
- Rollback path vẫn khả dụng.
- Open risk còn lại có owner và mức chấp nhận rõ.
- Timeline và incident record đã được cập nhật.
Sau đó mới chuyển sang Incident Closure Checklist, không đóng incident chỉ vì website đã online. Kết quả recovery, residual risk và action còn mở nên được phản ánh trong Security Incident Report để giữ traceability cho lần review sau.
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 xử lý sự cố bảo mật.