Incident Response Readiness là mức độ website và đội vận hành đã chuẩn bị trước để có thể phát hiện, triage, containment, điều tra và recovery khi security incident xảy ra. Readiness tốt không làm incident biến mất, nhưng giúp giảm thời gian ra quyết định, hạn chế mất evidence và tránh việc xử lý trong trạng thái thiếu owner, thiếu access hoặc thiếu backup.
Checklist này nên được dùng trước incident và review lại sau mỗi Lessons Learned. Mục tiêu không phải đạt “100% checkbox”, mà là biết gap nào đang tồn tại, risk nào được chấp nhận và owner nào phải xử lý.
Nền tảng readiness: asset, identity, logging và escalation
1. Asset và ownership readiness
- Domain/registrar, DNS, CDN/WAF.
- Hosting/VPS/server và control panel.
- WordPress core, plugin, theme, MU-plugin.
- Database, object storage, email/SMTP.
- Backup, monitoring và third-party integration.
Mỗi asset quan trọng cần owner và contact path. Nếu incident xảy ra ngoài giờ mà không biết ai có quyền thay DNS, revoke API key hoặc restore backup thì readiness chưa đạt.
2. Identity và emergency access
Inventory admin WordPress, hosting, SSH/SFTP, CDN/WAF, DNS/registrar và cloud account. Xác nhận MFA, least privilege, session review và quy trình revoke khi compromise.
Break-glass access phải được kiểm thử. Emergency access chỉ hữu ích nếu credential còn dùng được, được bảo vệ đúng và owner biết cách truy cập. Không nên đợi tới incident mới phát hiện tài khoản recovery đã hết quyền hoặc email khôi phục không còn kiểm soát.
3. Logging và evidence readiness
Đội phản ứng phải biết log nào tồn tại, retention bao lâu, timezone gì và ai có quyền export. Ít nhất nên xem xét web server, WAF/CDN, WordPress audit, authentication, hosting/system, file integrity và DNS/registrar history.
Dùng danh sách log cần thu thập khi điều tra sự cố làm baseline.
Evidence storage cần tách khỏi hệ thống đang bị điều tra để attacker trên host bị compromise không thể sửa hoặc xóa evidence đã collection.
4. Detection và escalation readiness
Monitoring cần biết signal nào đủ để alert, alert nào cần triage và khi nào phải kích hoạt Incident Response. Severity model, on-call contact và escalation path nên được định nghĩa trước.
Đối chiếu Security Alert Triage, activation criteria và Severity P1–P4.
Containment, recovery và communication readiness
5. Containment readiness
- Revoke admin session hoặc disable account.
- Disable plugin/route có bằng chứng bị khai thác.
- Thêm WAF rule hoặc giới hạn access tạm thời.
- Đưa website vào maintenance có kiểm soát.
- Cô lập host khỏi Internet nếu severity yêu cầu.
Mỗi containment action nên biết trước impact, owner, evidence có thể mất và rollback.
6. Backup và recovery readiness
Có backup không đồng nghĩa recovery-ready. Cần biết backup bao gồm gì, retention, vị trí lưu, quyền truy cập và lần restore test gần nhất.
Recovery gate phải được định nghĩa trước. Trước khi đưa website trở lại production, cần kiểm tra integrity, credential, critical function, monitoring và rollback. Xem Incident Recovery Plan.
7. Communication readiness
Chuẩn bị contact list cho website owner, developer, hosting/CDN, security, business owner và các bên liên quan. Xác định ai được phép gửi customer update, ai approve message và cadence nào áp dụng theo severity.
Dùng Incident Communication để xây status template trước khi cần dùng.
Readiness scoring matrix
| Lĩnh vực | PASS | PARTIAL | FAIL |
|---|---|---|---|
| Asset/owner | Inventory + owner hiện hành | Còn asset chưa rõ owner | Không có inventory đáng tin |
| Emergency access | Đã test và bảo vệ | Có nhưng chưa test gần đây | Không có hoặc mất quyền |
| Logging | Biết source, retention, export | Thiếu một số lớp telemetry | Không thể lấy log cần thiết |
| Containment | Runbook + owner + rollback | Action biết nhưng chưa exercise | Không rõ ai làm gì |
| Backup/recovery | Restore test PASS | Có backup nhưng test cũ | Không chứng minh restore được |
| Communication | Contact + authority + template | Contact có nhưng authority mơ hồ | Không có plan |
| Exercise | Đã diễn tập và action gap | Chỉ review trên giấy | Chưa từng test |
Tabletop exercise: kiểm tra readiness thực tế
Checklist chỉ cho biết control “có vẻ tồn tại”. Tabletop exercise kiểm tra đội có thực sự ra quyết định được hay không. Một scenario đơn giản có thể bắt đầu bằng alert admin login bất thường, sau đó inject thêm file change, persistence và customer report.
Trong exercise cần quan sát
- Mất bao lâu để chỉ định incident owner.
- Đội có xác định đúng severity và scope ban đầu không.
- Có lấy được log/evidence cần thiết không.
- Containment action có owner và rollback không.
- Ai quyết định go-live/recovery.
- Communication path có hoạt động không.
Mẫu Readiness Action Register
| Gap | Risk | Owner | Priority | Due date | Verification |
|---|---|---|---|---|---|
| Không export được WAF log quá 7 ngày | Mất evidence khi phát hiện muộn | Security Ops | P2 | Theo plan nội bộ | Export test PASS |
| Backup chưa restore test | Recovery không chắc chắn | Platform owner | P1/P2 theo criticality | Theo plan nội bộ | Restore + integrity PASS |
| Không rõ ai approve customer update | Communication delay | Business owner | P3 | Theo plan nội bộ | Tabletop handoff PASS |
Quality gate: website đã đủ sẵn sàng chưa?
- Critical asset và owner đã biết.
- Emergency access đã được kiểm thử.
- Log source, retention và export path đã xác minh.
- Severity, activation và escalation path đã định nghĩa.
- Containment action có owner và rollback.
- Backup đã restore test, không chỉ “có file backup”.
- Communication contact và authority đã rõ.
- Tabletop exercise tạo được action gap có owner.
Nếu một mục quan trọng FAIL, đưa gap sang Corrective Action Plan. Sau incident, dùng Lessons Learned để cập nhật lại checklist.
Nguồn tham khảo
NIST SP 800-61 Rev. 3 nhấn mạnh preparation, detection, response và recovery là các phần liên kết trong quản trị rủi ro theo CSF 2.0. CISA cũng khuyến nghị có incident response plan, contact list, role/responsibility và thực hành quy trình trước sự cố. Readiness vì vậy cần được kiểm thử, không chỉ được viết thành tài liệu.