Root Cause Analysis sau Security Incident: cách xác định nguyên nhân gốc và entry point

Root Cause Analysis (RCA) sau security incident không phải là đặt tên cho artefact đã tìm thấy. “Có malware”, “plugin bị sửa” hoặc “admin account bị dùng” mới chỉ mô tả symptom, mechanism hoặc entry point. RCA cần chứng minh chuỗi nguyên nhân nào cho phép attacker vào, duy trì truy cập, tạo impact và vì sao các control hiện có không ngăn hoặc phát hiện sớm hơn.

Một RCA tốt phải dựa trên Incident Timeline, scope, evidence và confidence. Nếu evidence chưa đủ, kết luận đúng có thể là UNKNOWN hoặc HYPOTHESIS, không phải cố ép thành “root cause confirmed”. Với signal kiểu file PHP thay đổi, xem case File PHP thay đổi bất thường để tránh biến symptom filesystem thành root cause khi chưa có provenance.

Phân biệt Entry Point, Root Cause, Persistence và Contributing Factor

Nếu entry point nghi là plugin vulnerable, đối chiếu case Plugin WordPress có lỗ hổng dẫn tới Website bị xâm nhập. Nếu persistence nằm ở privileged admin/plugin/MU-plugin hoặc scheduled task/database, hai case Admin lạ, Plugin lạ và MU-plugin Persistence và Cron, Database Persistence và Malware tái nhiễm giúp kiểm causal chain thay vì chỉ ghi “malware quay lại”.

Xây dựng RCA từ evidence

Bắt đầu RCA từ Incident Timeline, không từ phỏng đoán

Dùng Incident Timeline để dựng chuỗi tối thiểu:

precondition
  -> initial access
  -> privilege/context obtained
  -> persistence or change
  -> impact
  -> detection signal
  -> containment
  -> recovery

Nếu timeline còn khoảng trống lớn trước initial access hoặc giữa entry point và persistence, RCA chưa nên đóng. Ghi rõ evidence gap và alternate hypothesis thay vì biến giả thuyết thuận tiện nhất thành fact. Một ví dụ về cách correlation access log và timestamp hỗ trợ dựng chuỗi là case phân tích Security Incident từ Access Log và Timeline.

RCA Hypothesis Matrix

Điểm quan trọng là phải ghi cả evidence phản bác. Nếu một hypothesis chỉ có evidence “ủng hộ” nhưng không xem dữ liệu mâu thuẫn, confidence dễ bị thổi phồng.

Confidence Gate cho kết luận RCA

Không có một công thức xác suất cố định cho mọi incident. Confidence là cách ghi mức chắc chắn của kết luận và phải gắn với evidence cụ thể.

RCA Worksheet thực dụng

Không dùng “5 Whys” một cách máy móc

Hỏi “tại sao” nhiều lần có thể hữu ích nhưng incident bảo mật thường có nhiều nhánh nguyên nhân song song. Một vulnerable component, credential reuse và thiếu monitoring có thể cùng góp phần. Cố ép mọi incident về một nguyên nhân duy nhất dễ tạo corrective action thiếu.

Nên dùng causal chain có evidence và cho phép nhiều contributing factor thay vì một chuỗi tuyến tính giả tạo.

Ví dụ RCA cho WordPress compromise

Giả sử attacker dùng credential admin bị lộ để login, cài plugin độc hại và tạo persistence.

• Entry point: admin credential bị sử dụng trái phép.
• Root cause: account đặc quyền không có MFA và credential bị reuse.
• Persistence: plugin/file trái phép và một scheduled task.
• Contributing factor: thiếu alert cho admin login từ nguồn mới.
• Impact amplifier: account có quyền cài plugin trực tiếp production.

Corrective action phải xử lý identity, privilege, deployment và monitoring; chỉ xóa plugin không sửa root cause. Với impact biểu hiện bằng redirect, JavaScript injection hoặc SEO spam, đối chiếu case Redirect, JavaScript Injection và SEO Spam Malware để truy ngược từ symptom tới source owner và persistence.

Chuyển RCA thành corrective action

Entry Point Evidence Gate

• Timeline phù hợp với first known malicious action.
• Evidence chỉ ra component/account/path cụ thể, không chỉ “có lỗ hổng”.
• Hypothesis giải thích được persistence hoặc follow-on activity.
• Đã xem evidence phản bác và alternate hypothesis.
• Nếu vulnerability được nêu là entry point, phải có evidence site/component thực sự exposed và exploitation path phù hợp.
• Không ghi “confirmed entry point” nếu chỉ biết một component có CVE nhưng không có evidence bị exploit.

Corrective Action Matrix

Corrective action phải sửa hệ thống, không chỉ sửa incident hiện tại

Nếu RCA chỉ tạo task “xóa file”, “đổi password” hoặc “update plugin” mà không sửa process/control gap, cùng loại incident có thể tái diễn. Corrective action nên có owner, priority, deadline, verification và exception/rollback path.

Nếu root cause liên quan credential exposure, dùng Credential Rotation. Nếu liên quan component/config, corrective action cần gắn với hardening, deployment và retest.

RCA Record mẫu

incident_id: INC-YYYY-NNN
rca_version: v1
owner: ...
timeline_ref: ...
scope_ref: ...
entry_point:
  hypothesis: ...
  confidence: low|medium|high|unknown
  supporting_evidence: [...]
  contradicting_evidence: [...]
root_causes:
  - cause: ...
    confidence: ...
    evidence_refs: [...]
persistence:
  - mechanism: ...
    evidence_refs: [...]
contributing_factors:
  - ...
impact_amplifiers:
  - ...
open_evidence_gaps:
  - ...
corrective_actions:
  - action: ...
    owner: ...
    due: ...
    verification: ...
    rollback_or_exception: ...
closure_status: open|conditional|closed

Đóng RCA và chuyển sang recovery

Quality Gate trước khi đóng RCA

• Root cause khác symptom.
• Entry point có evidence và confidence.
• Persistence đã được kiểm tra.
• Evidence phản bác/alternate hypothesis đã được xem.
• Contributing factor và impact amplifier được ghi riêng.
• Khoảng trống evidence được công khai.
• Mỗi root cause/control gap có corrective action.
• Mỗi corrective action có owner + verification.
• Recovery không dựa vào việc “artefact đã bị xóa” đơn thuần.

PASS/FAIL/HOLD cho RCA

• PASS: causal chain đủ nhất quán; entry point/root cause/persistence có evidence; confidence rõ; corrective action có verification; open gap không làm thay đổi recovery decision.
• FAIL: root cause chỉ là symptom; kết luận vulnerability không có exploitation evidence; bỏ qua persistence; hoặc corrective action không kiểm chứng được.
• HOLD: evidence gap còn đủ lớn để có thể thay đổi entry point/root cause hoặc recovery plan. HOLD phải tiếp tục investigation.

Sau RCA, chuyển kết quả sang Incident Recovery Plan và corrective-action backlog để tránh tái diễn. Thực tế recovery cần gate rõ để tránh đưa hệ thống nhiễm trở lại production; xem case khôi phục Website sau Security Incident mà không tái nhiễm.

Kết luận RCA, confidence, evidence gap và corrective action cũng nên được phản ánh trong Security Incident Report để giữ traceability từ điều tra tới closure.

Nguồn kỹ thuật

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations
• CISA — Cybersecurity Incident & Vulnerability Response Playbooks

Kết luận

RCA có giá trị khi biến incident thành một causal model có evidence: precondition → entry point → privilege/context → persistence → impact → detection gap → corrective action → verification. Khi evidence chưa đủ, ghi confidence thấp hoặc UNKNOWN tốt hơn một kết luận chắc chắn nhưng sai.

Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem Incident Response.