Incident Triage là bước đánh giá nhanh để quyết định một sự cố website đang nghiêm trọng đến đâu, cần điều tra gì trước và có phải escalation ngay hay không. Triage tốt không cố “giải quyết toàn bộ incident” trong vài phút; nó tập trung vào việc tạo đủ context để hành động an toàn.
Đầu vào có thể là alert từ WAF, login bất thường, file integrity, malware scanner, phản ánh của người dùng hoặc dấu hiệu vận hành khác. Đầu ra nên là một đánh giá có owner, confidence, severity sơ bộ, phạm vi ban đầu và next action.
Incident Triage khác Security Alert Triage thế nào?
Security Alert Triage đánh giá một alert có đáng tin và có cần mở Incident Response hay không. Incident Triage diễn ra sau khi sự cố đã được mở hoặc đang có đủ lý do mạnh để xử lý như incident.
5 câu hỏi triage cần trả lời đầu tiên
1. Chuyện gì đã xảy ra?
Ghi lại signal ban đầu, nguồn phát hiện, timestamp, asset liên quan và hành vi quan sát được. Tránh mô tả kết luận khi evidence mới chỉ là giả thuyết.
2. Asset nào đang bị ảnh hưởng?
Không chỉ nhìn vào URL. Kiểm tra WordPress instance, hosting account, database, CDN/WAF, DNS, email, admin account, SSH/SFTP và integration liên quan.
3. Attacker có quyền gì?
Khác biệt giữa scan thất bại và admin compromise là rất lớn. Triage cần xác định khả năng attacker đã có session, credential, write access, shell hoặc persistence.
4. Impact hiện tại và tiềm năng là gì?
Đánh giá tính bí mật, toàn vẹn và khả dụng: dữ liệu bị đọc hay chưa, nội dung bị sửa không, chức năng quan trọng có bị gián đoạn không và sự cố có thể lan rộng không.
5. Cần làm gì ngay để giảm thiệt hại?
Nếu attacker đang hoạt động, containment có thể cần ưu tiên. Nhưng mọi hành động phải cân bằng với việc bảo toàn evidence. Không nên “dọn sạch” chỉ để website trông bình thường trở lại.
Quy trình Incident Triage thực dụng
- Ghi nhận incident ID, thời điểm và owner.
- Thu evidence ban đầu từ alert, log và trạng thái hệ thống.
- Xác minh confidence của tín hiệu.
- Gán severity sơ bộ theo P1–P4.
- Xác định phạm vi ban đầu và asset cần kiểm tra tiếp.
- Quyết định containment tạm thời nếu cần.
- Mở danh sách câu hỏi chưa trả lời để điều tra tiếp.
Mẫu output của một phiên Incident Triage
| Trường | Nội dung cần ghi |
|---|---|
| Incident ID | Mã sự cố duy nhất và thời điểm mở incident |
| Signal ban đầu | Nguồn alert, timestamp, asset, hành vi quan sát được |
| Confidence | Low / Medium / High kèm evidence hỗ trợ |
| Severity sơ bộ | P1–P4 và lý do |
| Scope ban đầu | Confirmed affected / Suspected / Chưa kiểm tra |
| Containment cần ngay? | Có/không, action cụ thể và evidence có nguy cơ mất |
| Open questions | Các giả thuyết hoặc khoảng trống cần xác minh |
| Next owner / next action | Ai làm gì tiếp theo và thời điểm review lại |
Output này giúp triage có thể handoff giữa ca trực hoặc giữa monitoring và Incident Response mà không mất context.
Exit criteria: khi nào triage được coi là hoàn tất?
Triage có thể đóng khi đã có đủ thông tin để chuyển sang một nhánh hành động rõ ràng. Không cần biết toàn bộ root cause ở bước này.
- Incident có owner và severity sơ bộ.
- Scope ban đầu đã phân biệt confirmed và suspected.
- Evidence dễ mất đã được nhận diện.
- Containment khẩn đã được quyết định hoặc loại trừ có lý do.
- Open questions có owner và next action.
- Thời điểm review severity/scope tiếp theo đã được xác định.
Evidence nào hữu ích trong triage?
Triage không cần thu toàn bộ dữ liệu ngay lập tức, nhưng nên ưu tiên evidence có khả năng thay đổi nhanh: active session, process, connection, WAF/CDN event, access log gần thời điểm incident, audit log WordPress, account changes và file modifications.
Sau triage, chuyển sang thu thập log phục vụ investigation và bảo toàn evidence trước các thay đổi lớn.
Triage phải phân biệt fact và hypothesis
Một kỹ thuật đơn giản là ghi từng phát hiện theo ba cột: Fact, Hypothesis, Need to verify. Ví dụ “admin user X đăng nhập lúc 02:13 từ IP lạ” là fact; “attacker đã lấy được mật khẩu admin” là hypothesis cho tới khi có thêm evidence.
Cách này giúp tránh tunnel vision và giảm nguy cơ containment sai đối tượng.
Khi nào cần escalation ngay?
- Compromise tài khoản đặc quyền hoặc hosting control plane.
- Active malware/webshell hoặc persistence được xác nhận.
- Data exposure hoặc payment/content tampering.
- Attack đang tiếp diễn và phạm vi chưa kiểm soát.
- Nhiều website hoặc nhiều account dùng chung hạ tầng có dấu hiệu liên quan.
Nếu chưa rõ có nên mở incident hay không, quay lại tiêu chí kích hoạt Incident Response.
Sau triage cần xác định phạm vi ngay
Triage chỉ tạo “ảnh chụp ban đầu”. Bước tiếp theo là mở rộng điều tra để biết blast radius thực sự. Một website bị compromise có thể chỉ là điểm hiển thị đầu tiên của sự cố lớn hơn ở hosting, credential hoặc dependency.
Xem tiếp cách xác định phạm vi ảnh hưởng của website security incident.
Baseline tham khảo
NIST SP 800-61 Rev. 3 đặt detection, response và recovery trong một hệ thống quản trị rủi ro liên tục. CISA Incident Response Playbook cung cấp một quy trình vận hành tham khảo cho việc xác định, phối hợp, remediation và recovery. Với website, triage nên kết hợp telemetry hạ tầng và application context thay vì chỉ dựa vào một loại log.