Security Alert Triage là bước đánh giá ban đầu để xác định một cảnh báo có đáng tin, có tác động và có cần kích hoạt Incident Response hay không. Triage tốt giúp tránh hai lỗi đối lập: biến mọi alert thành incident hoặc bỏ qua một chuỗi tín hiệu đang cho thấy compromise thật sự.
NIST CSF 2.0 tách Detect và Respond thành các chức năng liên quan nhưng khác nhau. Trong vận hành, monitoring tạo alert, triage xác minh và ưu tiên, còn Incident Response bắt đầu khi evidence đủ để cần containment, investigation hoặc recovery có tổ chức.
Mục tiêu và nguyên tắc của alert triage
Những câu hỏi phải trả lời trước tiên
- Alert có phải false positive hay không?
- Tài sản, user, endpoint và time window nào bị ảnh hưởng?
- Impact và confidence đang ở mức nào?
- Có cần giữ evidence trước khi hành động không?
- Nên close, monitor, investigate hay escalate?
Khi alert quality kém, cần quay lại False Positive trong Security Monitoring và Security Alerting để tuning rule.
Không coi mọi alert là incident
Alert chỉ là tín hiệu cần đánh giá. Một thay đổi hợp lệ trong maintenance window khác hoàn toàn cùng thay đổi xuất hiện sau login Admin bất thường. Triage phải khóa scope và change context trước khi đánh severity.
Quy trình triage theo từng bước
1. Xác minh alert và telemetry
Kiểm tra log source còn hoạt động, timestamp có đúng, parser có lỗi và rule có vừa thay đổi hay không. Một alert do telemetry hỏng không nên được xử lý như security event thật.
2. Xác định scope và change context
Ghi nhận host, website, account, IP/source, path, process, file hoặc component liên quan. Sau đó đối chiếu deployment, maintenance, backup, campaign hoặc hoạt động quản trị đã biết.
3. Correlation các signal liên quan
Tìm các sự kiện trước và sau alert trong cùng time window: login, account change, file change, cron, WAF event, request spike, process, resource và application error. Correlation giúp tăng hoặc giảm confidence. Có thể dùng Website Security Signals làm checklist nguồn tín hiệu.
4. Đánh giá impact và confidence
Impact trả lời nếu alert là thật thì hậu quả có thể đến đâu. Confidence phản ánh bằng chứng hiện tại đáng tin đến mức nào. Alert high impact nhưng low confidence vẫn có thể cần triage nhanh; high impact + high confidence thường nên escalate sớm.
Mô hình phân loại alert
| Trạng thái | Ý nghĩa | Hành động |
|---|---|---|
| Benign/Expected | Hoạt động hợp lệ đã xác minh | Đóng alert, cập nhật context nếu cần |
| False Positive | Rule tạo cảnh báo sai | Đóng và đưa vào backlog tuning |
| Suspicious | Chưa đủ evidence nhưng có deviation đáng chú ý | Thu thập thêm context, tăng monitoring |
| Likely Incident | Nhiều signal phù hợp với compromise | Escalate theo Incident Response |
| Confirmed Incident | Evidence đủ mạnh về sự cố | Containment, investigation và recovery theo runbook |
Khi nào nên kích hoạt Incident Response?
Không có threshold chung cho mọi tổ chức, nhưng các điều kiện sau thường đáng escalation: account đặc quyền bị compromise, mã/file trái phép được xác minh, persistence signal tái xuất hiện, dữ liệu hoặc service bị ảnh hưởng, attacker activity đang tiếp diễn hoặc blast radius chưa xác định.
Đừng chờ “chắc chắn 100%” nếu impact tiềm năng cao và evidence đang tăng. Incident Response có thể bắt đầu bằng containment có kiểm soát và investigation song song.
Những việc không nên làm trong triage
- Xóa file đáng ngờ trước khi lưu evidence cần thiết.
- Reset mọi credential mà không ghi lại timeline.
- Allowlist rộng chỉ để alert biến mất.
- Đổi threshold ngay khi chưa hiểu nguyên nhân.
- Coi HTTP 200 hoặc website vẫn chạy là bằng chứng không có compromise.
Triage checklist và theo dõi sau quyết định
- Alert ID, timestamp và owner.
- Tài sản bị ảnh hưởng.
- Rule và telemetry source.
- Change/maintenance context.
- Signal liên quan trước/sau alert.
- Impact và confidence.
- Decision: close, monitor, investigate hoặc escalate.
- Evidence và action đã thực hiện.
Các chỉ số backlog, time-to-triage và alert quality nên được theo dõi trong Security Monitoring Dashboard.
Kết luận
Security Alert Triage là cầu nối giữa Detect và Respond. Một quy trình tốt xác minh telemetry, khóa scope, correlation signal, đánh giá impact/confidence và đưa ra quyết định rõ ràng. Nhờ đó đội vận hành không biến mọi alert thành incident nhưng cũng không bỏ lỡ những dấu hiệu cần phản ứng sớm.
Nguồn tham khảo
Operational artifact: runbook và log sample cho alert triage
Lưu ý: mẫu dưới đây dùng dữ liệu giả lập đã khử thông tin để minh họa cách triage; không phải log production hay bằng chứng sự cố của SecureWebOps.
2026-09-08T02:13:14Z auth user=admin-demo action=login result=success source=198.51.100.24
2026-09-08T02:16:03Z audit actor=admin-demo action=plugin_activated plugin=demo-plugin
2026-09-08T02:18:31Z fim path=/wp-content/plugins/demo-plugin/demo.php action=created
Cách đọc sample
- Không kết luận compromise chỉ từ IP mẫu hoặc một login thành công.
- Kiểm tra login có change/travel/VPN context hợp lệ không.
- Đối chiếu activation với deployment/change record.
- Xác minh file creation có thuộc package/plugin hợp lệ không.
- Nếu ba signal không có context hợp lệ và actor có quyền cao, nâng confidence và chuyển Incident Response.
Mẫu triage record
| Trường | Giá trị cần ghi |
|---|---|
| Alert ID | ID duy nhất |
| Telemetry health | PASS/FAIL + last-event age |
| Scope | Asset/account/route/time window |
| Evidence refs | Log/event/file references |
| Impact | Low/Medium/High + lý do |
| Confidence | Low/Medium/High + số signal độc lập |
| Decision | Close / Monitor / Investigate / Escalate |
| Owner / next review | Ai xử lý và thời điểm xem lại |
Runbook exit gate
- PASS: alert có disposition, owner và evidence refs.
- PASS: likely/confirmed incident có handoff rõ sang Incident Response.
- FAIL: đóng alert chỉ vì website vẫn trả 200.
- FAIL: xóa artefact trước khi ghi evidence cần thiết.