Security Escalation Matrix: Alert đến Incident

Security Escalation Matrix là cơ chế giúp đội vận hành quyết định một tín hiệu bảo mật cần được xử lý ở mức nào, khi nào một alert trở thành incident, ai phải được thông báo và ai có quyền thực hiện hành động tiếp theo. Nếu không có matrix rõ ràng, cùng một sự kiện có thể bị đánh giá khác nhau giữa các ca trực, ticket bị chuyển vòng quanh hoặc incident nghiêm trọng bị giữ quá lâu ở mức “đang theo dõi”.

Trong Managed Security, escalation không chỉ là gọi thêm người. Nó là một phần của quy trình quản trị rủi ro: thu thập evidence, triage, xác định severity, đánh giá business impact, quyết định có cần incident response hay không, sau đó chuyển đúng technical owner hoặc management owner khi vấn đề vượt thẩm quyền hiện tại.

Từ Signal đến Incident: triage và severity

Các trạng thái Signal, Alert, Finding và Incident

Một sai lầm phổ biến là coi mọi event từ tool bảo mật đều là incident. Thực tế nên tách các trạng thái:

Signal/Event: dữ liệu hoặc thay đổi được ghi nhận, chưa đủ kết luận.
Alert: signal vượt rule/threshold và cần được review.
Finding: vấn đề đã được xác minh nhưng chưa chắc đang gây incident, ví dụ cấu hình yếu hoặc vulnerability.
Incident: sự kiện đã hoặc có khả năng gây ảnh hưởng đến confidentiality, integrity, availability hoặc business operation và cần response có điều phối.

NIST SP 800-61 Rev. 3 xem incident response là một phần của toàn bộ cybersecurity risk management, không phải hoạt động chỉ bắt đầu khi hệ thống đã bị compromise rõ ràng. Việc phân loại đúng giúp dùng nguồn lực phù hợp và tránh cả hai cực: bỏ sót incident hoặc biến mọi alert thành khủng hoảng.

Alert nào cần human triage?

Không phải alert nào cũng cần cùng mức xử lý. Human triage nên ưu tiên những signal có một hoặc nhiều đặc điểm:

Liên quan tài khoản quản trị, credential hoặc privilege change.
Ảnh hưởng login, checkout, payment, API hoặc critical flow.
Có evidence exploitation, malware, unauthorized change hoặc data access.
Xuất hiện trên asset business-critical.
Có nhiều nguồn evidence độc lập cùng chỉ về một hành vi.
Attack đang tiếp diễn hoặc impact có thể tăng nhanh theo thời gian.

Alert volume cao không nên là lý do duy nhất để escalation. Một signal hiếm trên critical asset có thể quan trọng hơn hàng nghìn bot request đã bị WAF block đúng như thiết kế.

Triage cần trả lời những gì trước khi escalation?

Một triage tối thiểu nên cố gắng xác định:

What happened? Signal nào được quan sát và từ nguồn nào?
Where? Asset, account, endpoint hoặc environment nào liên quan?
When? Bắt đầu khi nào, còn tiếp diễn không?
Impact? Có downtime, unauthorized access, data exposure hoặc integrity change không?
Confidence? Evidence đủ mạnh hay có khả năng false positive?
Scope? Một asset hay nhiều hệ thống?
Next action? Theo dõi, remediation backlog, escalation hay incident response?

Nếu thiếu dữ liệu, ticket nên ghi rõ unknown thay vì tự suy đoán. Uncertainty cũng là một phần của triage evidence.

Severity không nên chỉ dựa trên tên alert

Một signature có chữ “Critical” không tự động biến sự kiện thành Critical incident. Severity nên kết hợp technical evidence với business context:

Asset criticality.
Confirmed impact.
Exploit/compromise confidence.
Attack scope.
Time sensitivity.
Existing compensating controls.
Khả năng phục hồi và dependency.

Ví dụ, nhiều lần login thất bại từ bot có thể chỉ là Medium/Low nếu đã bị rate limit và không có account compromise. Ngược lại, một login thành công bất thường vào admin account quan trọng có thể cần ưu tiên cao dù số lượng event rất nhỏ.

Thiết kế Security Escalation Matrix

Một Security Escalation Matrix tham khảo

Không có severity matrix universal cho mọi website. Bảng dưới đây là cấu trúc tham khảo để tùy chỉnh theo business:

Mức	Ví dụ trạng thái	Escalation	Hành động chính
Critical	Confirmed compromise, active data exposure, critical flow unavailable hoặc attacker còn duy trì access	On-call security + technical owner + business owner	Incident response, containment và management communication
High	Strong evidence exploitation, privileged account risk hoặc control failure trên asset quan trọng	Senior security/technical owner; elevate nếu impact tăng	Investigation ưu tiên, mitigation/containment nếu cần
Medium	Verified finding hoặc suspicious behavior chưa có impact trực tiếp	Operational owner	Remediation plan, monitoring tăng cường
Low	Hardening gap, informational event, blocked noise	Backlog/review	Maintenance hoặc tuning định kỳ

Matrix cần được hiệu chỉnh bằng incident history và business criticality, không nên dùng nguyên xi như một “chuẩn ngành”.

Escalation và Elevation khác nhau thế nào?

Hai khái niệm thường bị trộn:

Escalation: chuyển hoặc bổ sung resource/chuyên môn để xử lý kỹ thuật hiệu quả hơn.
Elevation: đưa vấn đề lên cấp quản lý hoặc business authority vì impact, risk acceptance hoặc quyết định vượt thẩm quyền kỹ thuật.

Ví dụ, analyst có thể escalation alert tới incident responder để điều tra sâu hơn. Nếu containment yêu cầu tắt checkout hoặc chấp nhận downtime, incident có thể cần elevation tới business owner.

Khi nào Alert nên được declare thành Incident?

Không nên dùng một trigger duy nhất. Alert có thể được declare thành incident khi evidence cho thấy một hoặc nhiều điều kiện:

Security policy/control đã bị vi phạm với impact thực tế.
Có unauthorized access hoặc privileged account compromise.
Malware, web shell hoặc persistence được xác minh.
Data exposure/exfiltration được quan sát hoặc có evidence đáng tin cậy.
Attack đang làm giảm availability của critical service.
Integrity của code/config/content bị thay đổi trái phép.
Nhiều alert liên quan tạo thành một attack chain có ý nghĩa.

Incident declaration nên có timestamp, người quyết định, severity ban đầu và evidence supporting. Severity có thể được reclassify sau đó.

Ví dụ triage và escalation thực tế

Ví dụ 1: WAF phát hiện lượng lớn request bất thường

WAF block hàng nghìn request không tự động là incident. Triage cần xem request đã bị block hay bypass, endpoint nào bị nhắm tới, origin có chịu tải bất thường không và legitimate traffic có bị ảnh hưởng không.

Nếu WAF hoạt động đúng, đây có thể chỉ là monitored attack activity. Nếu rule bị bypass, origin overload hoặc attacker chạm tới endpoint nhạy cảm, severity cần tăng và có thể chuyển incident response.

Lifecycle rule và exception có thể tham khảo WAF Maintenance Checklist.

Một login lạ là alert cần context. Analyst nên kiểm tra MFA, session, IP reputation, lịch sử user, subsequent action và xem account có thực hiện privilege/config change hay không.

Nếu user xác nhận hoạt động hợp lệ, alert có thể đóng với evidence. Nếu không xác nhận hoặc có hành vi tiếp theo đáng ngờ, cần escalation nhanh để revoke session/credential theo authorization và điều tra phạm vi.

Ví dụ 3: Vulnerability mới trên component public-facing

Finding vulnerability chưa chắc là incident. Nếu chưa có evidence exploitation, issue có thể đi vào remediation workflow với priority dựa trên exposure, asset criticality và exploitability.

Nếu log cho thấy exploitation đang diễn ra hoặc compromise đã xảy ra, finding phải được chuyển sang incident process thay vì chỉ chờ patch SLA.

SLA, authority, handoff và communication

Escalation Matrix phải gắn với SLA

Matrix nói ai và khi nào; SLA định nghĩa mức dịch vụ có thể đo. Hai tài liệu cần khớp nhau. Nếu SLA yêu cầu Critical được human triage ngoài giờ nhưng escalation matrix không có on-call contact, cam kết đó không khả thi.

Chi tiết cách tách acknowledgment, triage, containment và remediation có thể xem trong Managed Security SLA.

Contact Matrix cần nhiều hơn tên và số điện thoại

Mỗi contact nên có vai trò và authority:

Primary security contact.
Backup/on-call security contact.
Application/developer owner.
Hosting/cloud owner.
CDN/WAF/DNS owner.
Business owner/management.
Legal/privacy/comms contact nếu phù hợp.

Matrix cũng cần kênh dự phòng nếu email hoặc hệ thống ticket gặp sự cố.

Emergency Authority phải được định nghĩa trước

Escalation nhanh nhưng không có quyền hành động vẫn có thể khiến incident kéo dài. Cần xác định trước action nào provider hoặc on-call engineer được phép thực hiện mà không chờ approval từng lần.

Ví dụ action hẹp có thể gồm block source cụ thể, revoke session đã xác minh compromise hoặc bật pre-approved WAF rule. Action ảnh hưởng rộng như disable API, block region hoặc shutdown service thường cần business authority cao hơn.

Evidence tối thiểu trong một Escalation Ticket

Alert ID/source và timestamp.
Asset/account/endpoint liên quan.
Severity hiện tại và rationale.
Observed evidence, không chỉ conclusion.
Impact đã biết và unknown.
Action đã thực hiện.
Next action đề xuất.
Owner hiện tại.
Escalation/elevation contact đã gọi.
Deadline hoặc next review time.

Ở lớp server, việc có log đủ sự kiện là tiền đề để triage và chứng minh timeline. Xem thêm Server Audit Logging.

Handoff giữa các đội phải có acknowledgment

Ticket không nên được coi là đã chuyển trách nhiệm chỉ vì analyst gửi email. Bên nhận cần acknowledgment; cho tới lúc đó original owner vẫn theo dõi.

Handoff tốt gồm evidence package, severity, lý do escalation, next action, deadline và tiêu chí trả ngược lại. Điều này đặc biệt quan trọng khi Managed Security, developer và hosting là ba vendor khác nhau.

Khi nào cần Management Elevation?

Không phải mọi Critical kỹ thuật đều cần CEO, nhưng management cần tham gia khi:

Có khả năng ảnh hưởng đáng kể tới khách hàng hoặc doanh thu.
Containment gây downtime lớn.
Cần chấp nhận risk thay vì remediation ngay.
Có potential data breach hoặc nghĩa vụ notification.
Cần huy động nguồn lực ngoài scope hiện tại.
Incident kéo dài vượt technical authority.

Management elevation nên truyền đạt impact và decision needed, không gửi toàn bộ raw log mà không có context.

Communication trong Incident nên được kiểm soát

Thông tin sự cố có thể nhạy cảm. Escalation plan nên xác định kênh nào dùng cho technical details, ai được thêm vào room/ticket và ai có quyền phát ngôn ra bên ngoài.

NIST SP 800-61r3 nhấn mạnh coordination và communication giữa các bên liên quan trong response/recovery. Communication plan nên được chuẩn bị trước thay vì xây trong lúc incident đang diễn ra.

Kiểm thử và cải tiến Escalation Matrix

Escalation Matrix cần được test

Một matrix chưa từng dùng có thể chứa số điện thoại cũ, account hết quyền hoặc dependency không còn đúng. Nên test bằng tabletop hoặc scenario định kỳ:

Admin account compromise.
WAF bypass trên endpoint quan trọng.
Malware/web shell.
Origin outage hoặc DDoS.
DNS/domain change trái phép.

Test nên đo không chỉ thời gian gọi người mà cả việc owner có hiểu authority và runbook hay không.

Post-Incident Review phải cập nhật Matrix

Mỗi incident là evidence để đánh giá escalation model. Nếu alert bị giữ quá lâu, sai contact hoặc approval làm chậm containment, đó là finding của quy trình chứ không chỉ lỗi cá nhân.

Action sau incident có thể gồm thay severity criteria, bổ sung contact, mở rộng emergency authority, cải thiện logging hoặc thay alert correlation.

Lỗi phổ biến và checklist triển khai

Những lỗi phổ biến của Security Escalation Matrix

Chỉ có contact list mà không có trigger escalation.
Mọi alert đều gửi lên cấp cao nhất.
Severity dựa hoàn toàn vào tool score.
Không phân biệt technical escalation và management elevation.
Không có backup contact.
Không gắn với SLA/coverage hours.
Không định nghĩa emergency authority.
Handoff không có acknowledgment.
Không review sau incident hoặc thay đổi nhân sự.

Checklist xây Security Escalation Matrix

Inventory critical asset và business flow.
Định nghĩa signal, alert, finding và incident.
Xây severity criteria theo risk.
Map technical owner và business owner.
Định nghĩa trigger escalation/elevation.
Gắn coverage và SLA.
Định nghĩa emergency authority.
Chuẩn hóa evidence package.
Thiết kế primary/backup communication channel.
Test bằng tabletop và cập nhật định kỳ.

Kết luận

Security Escalation Matrix giúp biến alert thành quyết định có kiểm soát. Quy trình tốt không escalation theo cảm tính mà dựa trên evidence, asset criticality, impact, confidence và authority. Alert chỉ trở thành incident khi đủ điều kiện, nhưng khi impact/time sensitivity tăng, escalation phải diễn ra nhanh và đúng owner.

Một matrix hiệu quả phải liên kết với SLA, incident runbook, contact list, logging và shared responsibility. Khi những thành phần này khớp nhau, đội vận hành giảm được cả hai rủi ro: phản ứng quá mức với noise và phản ứng quá chậm với incident thật.

Nguồn tham khảo: NIST SP 800-61 Rev. 3; NIST SP 800-184 về recovery planning và playbook; NIST Cybersecurity Framework 2.0.