Phạm vi ảnh hưởng của một website security incident phải được xác định bằng evidence, không bằng cảm giác. Scope tốt cần trả lời bốn câu hỏi: asset nào bị ảnh hưởng, identity/credential nào liên quan, dữ liệu/chức năng nào có thể bị tác động, và bằng chứng nào đủ để xếp từng đối tượng vào Confirmed, Suspected hoặc Cleared. Nếu scope quá hẹp, bạn có thể cleanup website nhưng bỏ sót account, credential hoặc hệ thống vẫn bị compromise. Nếu scope quá rộng, containment dễ gây downtime không cần thiết và làm loãng nguồn lực điều tra.
Vì vậy scope không phải một kết luận cố định ở đầu incident. Nó là một working record phải được cập nhật khi evidence mới xuất hiện. Mỗi lần scope thay đổi, severity, containment và recovery plan cũng phải được xem lại.
Scope một website incident gồm những lớp nào?
| Lớp | Đối tượng cần inventory | Câu hỏi chính |
|---|---|---|
| Application | WordPress core, plugin, theme, uploads, MU-plugin, cron, database, users, sessions | Thành phần nào có evidence bị thay đổi hoặc bị sử dụng trái phép? |
| Infrastructure | Hosting panel, VPS/server, SSH/SFTP, CDN/WAF, DNS, object storage | Compromise có vượt khỏi WordPress không? |
| Identity | Admin, hosting account, SSH key, API key, SMTP, database credential, cloud token | Credential nào có thể đã bị lộ, reuse hoặc dùng để pivot? |
| Data | User data, orders, form leads, content, secrets, backups | Dữ liệu nào có thể đã bị đọc, sửa, xóa hoặc exfiltrate? |
| Business function | Login, checkout, forms, publishing, email, recovery | Chức năng nào bị gián đoạn hoặc mất tính toàn vẹn? |
| Dependency | Shared hosting account, shared plugin/theme, shared credential, CI/CD, backup repository | Asset khác nào dùng chung thành phần hoặc trust boundary? |
Bắt đầu từ evidence đã biết, rồi pivot có mục tiêu
Sau Incident Triage, lập danh sách indicator đã biết: IP, user, session, file path, hash, timestamp, URL, request pattern, plugin/theme, process, DNS change hoặc hành vi account. Sau đó pivot theo bốn hướng:
- Time: mở rộng trước và sau event đã biết để tìm initial access, persistence và follow-on activity.
- Identity: tìm cùng username, email, session, key hoặc account trên hệ thống liên quan.
- Artefact: tìm cùng file/hash/domain/IP/request pattern trên site khác, backup, CDN/WAF và server log.
- Dependency: kiểm tra các asset dùng chung plugin/theme, hosting account, credential, database hoặc control plane.
Ví dụ: nếu phát hiện một admin login bất thường lúc 02:00, đừng dừng ở login log. Hãy kiểm tra plugin/theme change, file modification, database change, cron, outbound request và control-plane event trong cùng time window.
Incident Scope Matrix: record trung tâm của bước scoping
Mỗi asset/identity quan trọng nên có một dòng với trạng thái, evidence và next action. Không nên dùng một danh sách “site A/site B” không có căn cứ.
| Asset / Identity | Quan hệ với IOC | Evidence đã kiểm | Trạng thái | Next action |
|---|---|---|---|---|
| WordPress production | Direct | Access + audit + file | Confirmed / Suspected / Cleared | Contain / investigate / monitor |
| Hosting / SSH | Credential dependency | Auth + session + control panel | … | … |
| Database | Shared credential / data | Account + relevant change evidence | … | … |
| CDN / WAF / DNS | Control plane | Login + change history | … | … |
| Backup repository | Recovery dependency | Access + integrity + restore point | … | … |
| Related website | Shared component / account | Component version + IOC search | … | … |
Confirmed, Suspected và Cleared phải có tiêu chí
- Confirmed affected: có evidence trực tiếp hoặc correlation đủ mạnh cho thấy asset/identity đã bị compromise hoặc tác động.
- Suspected: có quan hệ hợp lý với incident nhưng evidence chưa đủ để xác nhận hay loại trừ.
- Cleared: đã kiểm theo tiêu chí xác định trước và chưa thấy evidence liên quan trong observation window phù hợp.
Không nên dùng nhãn “clean” chỉ vì malware scanner không báo gì. Scanner là một nguồn evidence; nó không chứng minh account, session, control plane hoặc persistence khác đã sạch.
Evidence checklist trước khi thu hẹp scope
- Initial access hypothesis có timeline phù hợp với evidence hiện có.
- Identity hoặc credential liên quan đã được pivot sang các hệ thống dùng chung.
- Asset trực tiếp và dependency quan trọng đã được kiểm tra.
- Persistence hypothesis đã được kiểm tra, không chỉ malware scan.
- Không còn activity mới chưa giải thích trong observation window đã chọn.
- Mỗi đối tượng được gắn Cleared đều có tiêu chí và evidence reference.
- Nguồn log có retention ngắn đã được thu trước khi hết dữ liệu.
Danh sách nguồn log thực hành nằm tại những log cần thu thập khi điều tra sự cố bảo mật website.
Scope thay đổi thì severity và containment cũng phải thay đổi
Một incident có thể bắt đầu ở P3 nhưng tăng lên P1/P2 nếu phát hiện nhiều site, account đặc quyền hoặc dữ liệu nhạy cảm bị ảnh hưởng. Khi scope đổi, cập nhật lại severity P1–P4.
Containment cũng phải bám theo scope. Cô lập sai asset có thể không chặn attacker; ngược lại, tắt toàn bộ hạ tầng khi chỉ một component bị ảnh hưởng có thể gây downtime không cần thiết. Nếu cần containment nhưng vẫn phải giữ evidence, xem cách cô lập website bị xâm nhập mà không phá hủy evidence.
Scope Record mẫu
Đây là worksheet để đội phản ứng điền bằng evidence thật; không phải kết quả incident đã có sẵn.
incident_id: INC-YYYY-NNN
scope_version: v1
updated_at_utc: ...
owner: ...
initial_indicator: ...
observation_window:
start_utc: ...
end_utc: ...
assets:
- id: wp-prod
relation_to_ioc: direct
status: confirmed|suspected|cleared
evidence_refs: [...]
next_action: ...
identities:
- id: admin@example
status: ...
shared_dependencies: [...]
data_impact:
confidentiality: unknown|none|suspected|confirmed
integrity: unknown|none|suspected|confirmed
availability: unknown|none|suspected|confirmed
open_gaps:
- ...
severity_current: P1|P2|P3|P4
containment_decision: ...
Khi nào có thể đóng bước scoping?
Không có một khoảng thời gian cố định cho mọi incident. Có thể coi bước scoping là đủ để chuyển tiếp khi các điều kiện sau cùng lúc đạt:
- IOC và hypothesis chính đã được pivot qua các asset/dependency quan trọng.
- Không còn asset quan trọng ở trạng thái “chưa biết vì chưa kiểm”.
- Mỗi asset/identity đều có owner + status + evidence reference + next action.
- Observation window không còn activity mới chưa giải thích.
- Entry point/persistence hypothesis đủ nhất quán để không làm recovery bỏ sót đường quay lại.
- Severity và containment đã được cập nhật theo scope mới nhất.
Nếu còn gap lớn, scope vẫn là OPEN. Đừng chuyển thẳng sang cleanup chỉ vì “đã tìm thấy malware”. Trước recovery, cần bảo toàn evidence và dựng Incident Timeline.
PASS/FAIL cho bước xác định phạm vi
- PASS: mọi asset/identity quan trọng có trạng thái và evidence reference; blast radius đủ rõ để quyết định severity, containment và recovery.
- FAIL: scope chỉ dựa trên một scanner/IOC; chưa pivot credential/dependency; nhiều asset quan trọng chưa kiểm; hoặc “Cleared” không có tiêu chí.
- HOLD: evidence chưa đủ để xác nhận hay loại trừ một dependency có khả năng làm thay đổi containment/recovery. HOLD phải mở investigation, không được ép thành Cleared.
Nguyên tắc vận hành
NIST SP 800-61 Rev. 3 đặt incident response trong một chu trình liên tục giữa detection, response và recovery. Trong thực tế website, điều này có nghĩa scope phải được cập nhật khi evidence thay đổi; phát hiện mới có thể buộc đội phản ứng quay lại triage, đổi severity và đổi containment strategy.
Nguồn kỹ thuật
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations
- NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response
Kết luận
Xác định phạm vi ảnh hưởng không phải là liệt kê vài asset “có vẻ liên quan”. Một scope có thể dùng để ra quyết định phải gắn asset/identity → evidence → trạng thái → next action, đồng thời chỉ rõ open gap. Khi scope đủ chặt, severity, containment và recovery mới có nền tảng đáng tin để tiếp tục.