Đưa website hoạt động trở lại sau sự cố bảo mật là một risk decision, không phải thao tác kỹ thuật đơn lẻ. Website có thể trả HTTP 200 và trông bình thường nhưng vẫn còn persistence, credential rủi ro, dữ liệu bị sửa hoặc monitoring chưa sẵn sàng.
Vì vậy cần một go-live gate rõ ràng để quyết định khi nào có thể mở lại traffic production.
Điều kiện đầu tiên: attacker không còn hoạt động trong phạm vi đã biết
Containment phải đủ ổn định: không còn session trái phép, command execution, webshell activity, outbound connection hoặc hành vi persistence mới trong telemetry đang quan sát.
Nếu vẫn có tín hiệu mới, quay lại containment và scope thay vì cố mở site sớm.
Root cause và persistence phải được xử lý ở mức chấp nhận được
Không nhất thiết mọi câu hỏi điều tra đều đã có đáp án tuyệt đối, nhưng entry point chính, persistence và control gap có khả năng tái compromise phải được xử lý hoặc có compensating control.
Xem Root Cause Analysis để phân biệt symptom với root cause.
Go-Live Decision Matrix
| Gate | PASS khi | BLOCK khi |
|---|---|---|
| Containment | Không còn activity trái phép trong scope đã biết | IOC/persistence mới vẫn xuất hiện |
| Integrity | File, DB, config đã đối chiếu/trusted | Không biết artefact nào là hợp lệ |
| Credential | Credential rủi ro đã revoke/rotate | Old session/key vẫn dùng được |
| Function | Critical user flow test pass | Login/checkout/form/API lỗi |
| Monitoring | Telemetry và alert đã hoạt động | Không quan sát được signal liên quan incident |
| Rollback | Có snapshot/backup và owner | Không có đường lui an toàn |
Integrity check cần bao phủ gì?
WordPress core, plugin, theme, uploads, MU-plugin, cron và file config phải được review so với trusted source hoặc known-good baseline. Database cần kiểm tra admin account, option, scheduled task, content quan trọng và các thay đổi liên quan timeline. Hosting, DNS, CDN/WAF, SSH/SFTP và integration cũng cần được kiểm tra nếu nằm trong scope.
Functional test trước khi mở traffic
Security recovery không được phá các chức năng quan trọng. Test tối thiểu nên gồm login, logout, form, API/webhook, checkout/payment nếu có, upload, cache/CDN và scheduled task quan trọng. Ghi lại pass/fail thay vì chỉ kiểm tra bằng mắt.
Monitoring phải được bật trước traffic
Post-incident monitoring nên sẵn sàng trước khi user quay lại. Signal ưu tiên phải bám theo RCA: admin login, file changes, cron/MU-plugin, WAF event, outbound request, credential reuse hoặc component thay đổi.
Xem Post-Incident Monitoring để thiết kế cửa sổ quan sát tăng cường.
Có nên mở lại từng phần?
Nếu kiến trúc cho phép, phased recovery giúp giảm blast radius: mở read-only/public content trước, sau đó admin, form, API hoặc transaction function. Mỗi pha có verification riêng.
Mẫu Go-Live Approval Record
| Trường | Nội dung |
|---|---|
| Incident ID | Mã sự cố |
| Decision time | Timestamp + timezone |
| Approver | Owner có quyền quyết định |
| Passed gates | Containment, integrity, credential, function, monitoring |
| Known residual risk | Rủi ro còn lại + owner |
| Rollback trigger | Dấu hiệu buộc rollback/cô lập lại |
| Monitoring window | Thời gian và signal theo dõi tăng cường |
Rollback trigger phải được định nghĩa trước
- IOC cũ xuất hiện lại.
- Admin/session trái phép mới.
- File hoặc persistence mới xuất hiện.
- Outbound traffic đáng ngờ tái diễn.
- Functional corruption hoặc dữ liệu sai lệch.
Nếu trigger xuất hiện, quay lại Incident Response thay vì cố giữ website online.
Go-live chưa phải Incident Closure
Mở lại website chỉ là một milestone của recovery. Incident vẫn cần closure checklist, post-incident review và corrective action.
Tiếp theo dùng Incident Closure Checklist để xác định khi nào sự cố thực sự có thể đóng.