Incident readiness cho WordPress là khả năng chuẩn bị trước để khi website bị compromise, redirect lạ, tài khoản Admin bị chiếm, plugin critical vulnerability hoặc outage nghiêm trọng xảy ra, đội vận hành không phải bắt đầu bằng việc đi tìm credential, backup, log và người có quyền quyết định. Readiness tốt giúp rút ngắn thời gian xác minh, containment và recovery, đồng thời giảm nguy cơ phá hủy evidence trong lúc xử lý.
Bài này không thay thế một Incident Response Plan đầy đủ. Nó tập trung vào câu hỏi thực tế hơn: “Nếu sự cố xảy ra ngay hôm nay, WordPress của tôi đã có đủ người, quyền truy cập, dữ liệu, backup, log và runbook để phản ứng có kiểm soát chưa?”
Readiness matrix cho WordPress
| Hạng mục | PASS khi | FAIL khi | Evidence nên giữ |
|---|---|---|---|
| Asset inventory | Biết domain, host, DNS, CDN/WAF, repo, database, backup, integration và owner | Không biết hệ thống nào đang phục vụ production | Inventory có owner và ngày review |
| Contacts & authority | Có người quyết định containment, recovery và communication | Không ai biết ai được quyền tắt site, revoke account hoặc restore | Contact tree + authority matrix |
| Privileged access | Có account riêng, MFA/recovery và break-glass được kiểm soát | Shared Admin hoặc credential không rõ owner | Privileged account inventory |
| Backups | Có bản sao phù hợp và restore test gần đây | Chỉ biết “backup job success” nhưng chưa test restore | Restore test result, RPO/RTO expectation |
| Logs & telemetry | Có access/error, WordPress audit, WAF/CDN, auth và deployment history cần thiết | Thiếu log hoặc timezone không rõ | Log source map + retention |
| Containment | Biết cách giảm blast radius mà vẫn giữ evidence | Phản xạ đầu tiên là xóa file/account hoặc reinstall | Containment runbook |
| Recovery | Có go-live gate, smoke test và rollback | Restore xong là mở traffic ngay | Recovery checklist + validation |
| Tabletop | Runbook đã được diễn tập và cập nhật | Tài liệu tồn tại nhưng chưa ai thử dùng | Scenario, findings, corrective actions |
1. Khóa asset inventory trước khi xảy ra sự cố
Inventory phải đủ để một người không tham gia triển khai ban đầu vẫn hiểu production đang phụ thuộc vào gì. Tối thiểu nên có:
- Domain, registrar, DNS provider và nameserver.
- Hosting, server hoặc managed platform.
- CDN/WAF/reverse proxy nếu có.
- Repository, deployment path và người có quyền deploy.
- Database, object storage và backup location.
- Email/SMTP, payment, webhook, analytics hoặc integration có quyền ghi dữ liệu.
- WordPress Administrator, service account và credential kỹ thuật quan trọng.
- Owner kỹ thuật và owner business cho từng dependency.
Không ghi secret thật vào inventory chia sẻ rộng. Tài liệu readiness chỉ cần chỉ ra secret nằm ở đâu, ai được phép truy cập và recovery path là gì.
2. Xây contact tree và authority matrix
Trong incident, biết “gọi ai” chưa đủ; cần biết ai có quyền quyết định việc gì. Một contact tree tối thiểu nên phân biệt:
| Vai trò | Quyền quyết định | Ví dụ hành động |
|---|---|---|
| Incident lead | Điều phối và chốt trạng thái incident | Escalation, severity, handoff |
| WordPress/Dev owner | Thay đổi ứng dụng trong scope được duyệt | Disable component, collect artifact |
| Infrastructure owner | Network/server/CDN/WAF | Rate limit, isolate, block, snapshot |
| Business owner | Chấp nhận downtime/residual risk | Go/no-go, communication priority |
| Communication owner | Thông tin nội bộ/khách hàng | Status update, incident notice |
Nếu một vai trò không tồn tại trong tổ chức nhỏ, có thể một người kiêm nhiều vai trò, nhưng quyền quyết định vẫn phải được ghi rõ.
3. Chuẩn bị privileged access và break-glass
Readiness thất bại nếu lúc khẩn cấp đội vận hành không vào được hosting, DNS, CDN hoặc WordPress. Ngược lại, một break-glass account không kiểm soát cũng tạo thêm rủi ro. Kiểm tra:
- Privileged account có owner và MFA/recovery phù hợp.
- Không phụ thuộc duy nhất vào account của một nhân sự.
- Recovery code hoặc secret khẩn cấp được lưu trong cơ chế bảo vệ phù hợp.
- Việc dùng break-glass có logging/alert nếu hệ thống hỗ trợ.
- Sau khi dùng break-glass có bước rotate/review.
Với WordPress, tham khảo quản trị tài khoản Admin WordPress.
4. Backup phải được chứng minh bằng restore test
“Backup thành công” không chứng minh website có thể phục hồi. Readiness cần evidence về:
- Backup chứa database, uploads, code/config cần thiết theo recovery model.
- Bản sao không nằm duy nhất trong cùng failure domain với production.
- Biết restore vào môi trường nào và ai có quyền thực hiện.
- Restore test đã kiểm tra cả dữ liệu lẫn chức năng chính.
- RPO/RTO là kỳ vọng vận hành đã được thống nhất, không phải con số suy đoán.
Xem bảo mật backup WordPress và restore integrity.
Restore proof tối thiểu
Một restore test nên để lại ngày test, backup source, môi trường restore, người thực hiện, thời gian hoàn tất, route/business flow đã kiểm tra, lỗi còn lại và decision PASS/FAIL. Không đưa credential thật vào report.
5. Lập bản đồ log và evidence source
Để dựng timeline, đội xử lý cần biết trước log ở đâu, timezone nào và retention bao lâu. Tối thiểu nên map:
- Web server access/error log.
- CDN/WAF event nếu có.
- WordPress audit/admin activity nếu có.
- Authentication/session signal.
- Deployment/change history.
- File integrity hoặc malware telemetry.
- DNS/registrar change history khi liên quan.
Không cần thu thập mọi loại log chỉ để “cho đủ”. Ưu tiên nguồn có khả năng hỗ trợ các quyết định triage, scope, containment và recovery. Xem những log cần thu thập khi điều tra sự cố website.
6. Chuẩn bị containment runbook trước khi cần dùng
Runbook cần mô tả hành động theo điều kiện thay vì câu lệnh phá hủy ngay. Ví dụ:
- Xác minh signal và lock incident window.
- Ghi lại trạng thái account, file, log và service trước thay đổi.
- Xác định blast radius ban đầu.
- Chọn containment nhỏ nhất đủ giảm rủi ro: revoke session, hạn chế account, WAF rule, maintenance mode hoặc isolation theo kiến trúc.
- Ghi action, owner, timestamp và rollback.
- Đánh giá lại sau containment.
Nếu cần cô lập website mà vẫn giữ evidence, dùng workflow containment không phá evidence.
7. Recovery readiness phải có go-live gate
Readiness không kết thúc khi có backup. Trước khi mở traffic sau incident, đội vận hành phải biết tiêu chí nào cho phép return-to-service. Gate nên bao gồm:
- Containment đã hoàn thành theo scope hiện tại.
- Root cause/entry point đã đủ rõ để không đưa nguyên nhân cũ trở lại production.
- Credential/session quan trọng đã xử lý khi cần.
- Integrity và business flow chính PASS.
- Monitoring tăng cường đã sẵn sàng.
- Residual risk có owner và được chấp nhận.
- Có rollback nếu validation sau go-live thất bại.
Xem go-live gate sau security incident.
8. Tabletop exercise: kiểm tra tài liệu bằng tình huống giả lập
Tabletop không cần mô phỏng tấn công thật. Mục tiêu là kiểm tra xem con người và runbook có dùng được không. Có thể chọn một trong các scenario:
- Administrator lạ xuất hiện.
- Website redirect sang domain ngoài.
- Critical plugin vulnerability đang bị khai thác.
- WAF báo spike nhưng chưa biết có compromise hay không.
- Backup gần nhất không restore được.
Trong tabletop, ghi lại điểm nào khiến đội bị chậm: thiếu access, contact không phản hồi, log không tìm thấy, authority không rõ, backup không dùng được hoặc runbook mâu thuẫn thực tế.
Cadence nên dựa trên thay đổi và rủi ro
Không có một tần suất cố định phù hợp cho mọi website. Nên chạy lại tabletop sau thay đổi kiến trúc lớn, đổi hosting/CDN, thay owner chính, thêm integration quan trọng hoặc khi incident trước đó cho thấy runbook không còn phù hợp. Với hệ thống ổn định, tổ chức vẫn nên đặt lịch review định kỳ theo mức rủi ro của mình thay vì để tài liệu hết hạn vô thời hạn.
9. Exit criteria: khi nào được gọi là “ready”?
Readiness chỉ PASS khi bằng chứng thực tế cho thấy đội có thể thực hiện quy trình. Có thể dùng gate sau:
| Điều kiện | Trạng thái |
|---|---|
| Asset inventory có owner và còn hiện hành | PASS/FAIL |
| Contact tree và authority matrix đã xác minh | PASS/FAIL |
| Privileged access/recovery hoạt động | PASS/FAIL |
| Restore test gần nhất thành công theo scope yêu cầu | PASS/FAIL |
| Log/evidence source truy cập được | PASS/FAIL |
| Containment runbook có rollback | PASS/FAIL |
| Recovery/go-live gate đã định nghĩa | PASS/FAIL |
| Tabletop đã tạo corrective actions và owner | PASS/FAIL |
Nếu một mục critical FAIL, trạng thái phù hợp là NOT READY hoặc PARTIAL, không nên tự nâng thành PASS chỉ vì đã có tài liệu.
10. Readiness evidence pack
Một evidence pack có thể gồm:
- Asset/dependency inventory.
- Contact tree và authority matrix.
- Privileged access/recovery test record.
- Backup/restore test report.
- Log source map và retention.
- Containment/recovery runbook version.
- Tabletop scenario, finding và corrective action.
- Ngày review tiếp theo.
Không đưa password, private key, recovery code hoặc secret thật vào evidence pack.
Nguồn kỹ thuật
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations
- CISA — standardized incident and vulnerability response playbooks
- WordPress — Hardening WordPress
Kết luận
Incident readiness cho WordPress là khả năng chứng minh rằng khi sự cố xảy ra, đội vận hành biết tài sản nào bị ảnh hưởng, ai có quyền quyết định, evidence ở đâu, backup có restore được không, containment nào an toàn và điều kiện nào cho phép đưa website trở lại. Readiness tốt không phải một checklist đẹp; nó là một tập control đã được test, có owner, evidence, rollback và corrective action sau mỗi lần review.