Phân tích Security Incident từ Access Log và Timeline

Access log thường là nguồn evidence đầu tiên giúp tái dựng một security incident, nhưng log đơn lẻ hiếm khi đủ để kết luận root cause. Giá trị thực sự xuất hiện khi nhiều nguồn log được chuẩn hóa timestamp, correlation theo IP/user/session/request và xếp lại thành timeline có phân biệt fact, observation và hypothesis.

CISA Incident Response Playbook yêu cầu phân tích log để correlate adversary activity và duy trì incident timeline gồm event, mô tả, timestamp, impact và data source. CISA cũng nhấn mạnh log cần đủ chi tiết cho incident response, được bảo vệ khỏi sửa/xóa và nên tập trung về hệ thống quản lý log. Microsoft Sentinel/Defender sử dụng incident timeline để reconstruct attack story từ alerts, entities và log events. Nguồn: CISA Incident Response Playbook, CISA — Logging and Monitoring và Microsoft Sentinel — Incident Investigation.

Bối cảnh: nhiều log rời rạc nhưng chưa có attack story

Giả sử website ghi nhận một chuỗi sự kiện trong cùng buổi tối: nhiều request bất thường tới một endpoint, sau đó xuất hiện login admin lạ, một file mới được tạo dưới wp-content và vài phút sau có outbound request không quen thuộc. Mỗi signal riêng lẻ chưa đủ chứng minh quan hệ nhân quả, nhưng khi xếp đúng thứ tự có thể hình thành một attack chain hợp lý.

Những nguồn log nên gom trước

• Web server access/error log.
• CDN/WAF log và firewall event.
• WordPress login/activity log.
• System authentication, process và service log.
• File integrity hoặc deployment/change log.
• Database, cloud audit và control-panel log nếu có.

Investigation: chuẩn hóa evidence trước khi dựng timeline

Bước 1: normalize timestamp và timezone

Một trong các lỗi phổ biến nhất khi dựng timeline là so sánh timestamp từ nhiều hệ thống nhưng khác timezone, DST hoặc clock skew. CISA yêu cầu incident timeline phải ghi date-time group rõ ràng; thực tế nên chuẩn hóa về UTC hoặc một timezone duy nhất và giữ nguyên raw timestamp trong evidence record.

Nếu server clock lệch vài phút, cần ghi chú offset thay vì âm thầm chỉnh dữ liệu. Timeline tốt phải cho người khác tái kiểm tra được cách event được sắp thứ tự.

Bước 2: correlation theo entity và request context

Correlation nên dựa trên nhiều trường: source IP, user/account, session/cookie, request path, user-agent, request ID, hostname, process, file path và destination. Một IP giống nhau không tự động chứng minh cùng attacker, đặc biệt với proxy, NAT hoặc shared infrastructure.

Microsoft Sentinel incident timeline cho phép analyst nối alerts và hunting bookmarks theo chronology để reconstruct attack story; nguyên tắc tương tự có thể áp dụng cho website investigation ngay cả khi log stack đơn giản hơn.

Bước 3: phân loại fact, observation và hypothesis

Timeline nên tách ba lớp. Fact là dữ liệu log trực tiếp, ví dụ “request POST tới endpoint X lúc 20:14:02 UTC”. Correlated observation là kết nối có evidence, ví dụ “cùng session tạo admin account 45 giây sau”. Hypothesis là suy luận cần kiểm chứng, ví dụ “endpoint X có thể là initial access”.

Cách tách này ngăn timeline biến thành câu chuyện được kể ngược từ kết luận mong muốn.

Từ chronology tới entry point và scope

Tìm earliest confirmed malicious activity

Điểm quan trọng không phải event được phát hiện đầu tiên mà là malicious activity sớm nhất có evidence. Detection có thể xảy ra muộn hơn initial access nhiều giờ hoặc nhiều ngày. Cần đi ngược timeline từ IOC đã biết, pivot theo IP/user/path/file và kiểm tra dữ liệu trước thời điểm alert.

CISA playbook yêu cầu scope được cập nhật khi investigation có dữ liệu mới; vì vậy earliest known compromise có thể thay đổi trong quá trình phân tích.

Phân biệt initial access với activity sau compromise

Một admin login lạ có thể là entry point, nhưng cũng có thể là hành vi xảy ra sau khi attacker đã lấy credential từ webshell hoặc config file. Tương tự, file PHP đáng ngờ có thể là persistence chứ không phải initial exploit. Timeline giúp tách thứ tự, nhưng root cause vẫn cần evidence riêng.

Tham chiếu Incident Timeline cho website và Root Cause Analysis sau Security Incident để tách chronology khỏi causal conclusion.

Bảo toàn evidence trong khi phân tích

Log chỉ hữu ích nếu integrity đủ tin cậy. CISA khuyến nghị bảo vệ log khỏi unauthorized access hoặc deletion; trong incident response, cần lưu bản sao evidence trước khi cleanup hoặc rotate log.

• Export raw log trước khi filter hoặc normalize.
• Ghi nguồn, thời gian thu thập và checksum nếu phù hợp.
• Không chỉnh sửa trực tiếp file log gốc.
• Lưu query/filter dùng để tạo working timeline.
• Ghi rõ khoảng thời gian bị thiếu log hoặc retention gap.

Nếu cần containment trước khi phân tích xong, xem cách cô lập website mà không phá hủy evidence.

Khi nào timeline đủ mạnh để hỗ trợ RCA?

Timeline không tự động chứng minh root cause. Nó đủ mạnh để hỗ trợ RCA khi chronology nhất quán giữa nhiều nguồn và có evidence cho các bước quan trọng của attack chain.

• Timestamp đã được normalize và clock skew được ghi chú.
• Các event quan trọng có data source rõ ràng.
• Correlation dựa trên nhiều entity chứ không chỉ một IP.
• Initial access hypothesis có evidence trước follow-on activity.
• Khoảng trống log và uncertainty được ghi rõ.
• Scope được cập nhật khi xuất hiện evidence mới.

Validation và bàn giao investigation

Bài học vận hành

• Access log hữu ích nhất khi được correlation với auth, application và system evidence.
• Timeline phải chuẩn hóa timestamp trước khi suy luận chronology.
• Event được phát hiện đầu tiên không nhất thiết là initial access.
• Correlation không đồng nghĩa causation; RCA cần evidence riêng.
• Fact, observation và hypothesis nên được ghi tách biệt.
• Retention và integrity của log quyết định giới hạn investigation.

Nguồn tham khảo

• CISA — Incident and Vulnerability Response Playbooks
• CISA — Use Logging on Business Systems
• Microsoft Sentinel — Investigate Incidents
• Microsoft Defender XDR — Investigate Incidents
• NIST SP 800-171 Rev.3 — Incident Response