Post-Incident Monitoring là giai đoạn theo dõi tăng cường sau khi website đã recovery để phát hiện dấu hiệu tái xâm nhập, persistence còn sót, reuse credential hoặc hành vi tương tự incident cũ. Đây không phải “theo dõi chung chung”; signal cần bám sát Root Cause Analysis và IOC đã biết.
Nếu monitoring sau incident không thay đổi so với trước incident, đội vận hành có thể bỏ lỡ chính pattern đã từng gây compromise.
Monitoring phải bắt đầu trước khi mở traffic hoàn toàn
Telemetry và alert cần hoạt động trước go-live để có baseline mới và phát hiện vấn đề ngay khi website trở lại production.
Xem go-live gate sau sự cố để biết các điều kiện cần pass.
Signal ưu tiên nên bám theo incident cũ
Identity và credential
Theo dõi admin login, failed login bất thường, session mới, password reset, role change, application password và credential cũ bị reuse.
File và persistence
Giám sát file change, cron, MU-plugin, plugin/theme install, wp-config và các path từng liên quan incident.
Network, WAF và outbound behavior
Theo dõi request pattern, WAF rule hit, unusual source, outbound connection, webhook/API behavior và traffic anomaly.
Business function
Quan sát redirect, form, checkout, login, API response và content integrity để phát hiện impact mà security log có thể không phản ánh đầy đủ.
Post-Incident Monitoring Matrix
| Signal | Baseline | Alert trigger | Response |
|---|---|---|---|
| Admin login | Known user/IP/time pattern | Account mới, source lạ, impossible behavior | Triage + session review |
| File change | Known-good checksum/change window | PHP/config thay đổi ngoài deploy | Preserve evidence + isolate |
| Cron/MU-plugin | Approved list | Task/plugin mới không có change record | Investigate persistence |
| WAF/request | Post-recovery traffic baseline | IOC/pattern cũ tái xuất hiện | Block/tune + incident triage |
| Credential use | New active credentials | Old token/key được dùng | Revoke + expand scope |
Thiết kế monitoring window theo phase
Không có con số ngày chung cho mọi website. Thời gian tăng cường nên dựa trên severity, dwell time, persistence, retention log, business criticality và mức confidence của RCA.
Một incident có persistence sâu hoặc credential compromise thường cần cửa sổ theo dõi dài và signal rộng hơn incident nhỏ đã containment sớm.
Phase 1 — ngay sau recovery
Alert sensitivity cao hơn, review thường xuyên, tập trung IOC cũ và signal persistence.
Phase 2 — ổn định
Giảm noise nhưng vẫn giữ detection cho behavior liên quan root cause và credential.
Phase 3 — chuyển về steady state
Chỉ khi baseline mới ổn định và không còn dấu hiệu tái xâm nhập mới chuyển rule/threshold về chế độ vận hành bình thường.
Mẫu Monitoring Review Record
| Trường | Nội dung |
|---|---|
| Review time | Timestamp + timezone |
| Signals reviewed | Identity, file, WAF, persistence, network… |
| Alerts | Số alert + severity + disposition |
| New IOC | Có/không + evidence |
| Baseline drift | Thay đổi hợp lệ cần cập nhật baseline |
| Decision | Continue / tune / reopen incident |
| Owner | Người chịu trách nhiệm |
Khi nào phải mở lại Incident Response?
- IOC cũ tái xuất hiện.
- Persistence mới hoặc artefact tương tự được phát hiện.
- Credential cũ vẫn bị sử dụng.
- Admin/session trái phép xuất hiện.
- Root cause giả định bị evidence mới phủ định.
Nếu trigger xảy ra, không chỉ “tune alert”; cần quay lại triage, scope và containment.
Monitoring phải cập nhật sau Lessons Learned
Sau Post-Incident Review, các detection gap phải được chuyển thành rule, telemetry hoặc review process cụ thể.
Tham khảo Security Monitoring Maintenance Checklist để đưa detection mới vào vận hành dài hạn.
Exit criteria khỏi monitoring tăng cường
- Không có IOC/persistence mới trong cửa sổ đã định nghĩa.
- Baseline mới ổn định.
- Alert liên quan incident đã được tune và test.
- Credential cũ không còn được sử dụng.
- Open detection gap đã có owner/action.
- Incident Closure hoặc steady-state handoff đã được ghi nhận.
Monitoring tốt biến incident đã xảy ra thành khả năng phát hiện tốt hơn cho lần sau, thay vì chỉ chờ hệ thống “im lặng”.