Phân loại severity giúp đội Incident Response biết sự cố nào cần xử lý ngay, sự cố nào có thể theo dõi thêm và mức escalation phù hợp. Mô hình P1–P4 không phải chuẩn bắt buộc chung cho mọi tổ chức; đây là cách vận hành nội bộ cần được hiệu chỉnh theo mức độ quan trọng của website, dữ liệu và nghĩa vụ kinh doanh.
Điều quan trọng nhất là tiêu chí phải nhất quán. Nếu cùng một tình huống hôm nay là P1 nhưng ngày mai lại bị coi là P3 chỉ vì người trực khác nhau, hệ thống phân loại chưa đủ rõ.
Severity khác Priority như thế nào?
Severity mô tả mức độ nghiêm trọng dựa trên impact, scope, confidence và khả năng tiếp tục gây hại. Priority là thứ tự đội vận hành quyết định xử lý trong bối cảnh nguồn lực thực tế.
Một incident severity cao thường có priority cao, nhưng hai khái niệm không hoàn toàn giống nhau. Ví dụ hai incident đều P1 nhưng incident đang gây data exposure có thể được ưu tiên trước incident đã containment ổn định.
Mô hình P1–P4 thực dụng cho website
P1 — Critical
P1 dành cho tình huống có impact rất lớn hoặc attacker đang giữ quyền kiểm soát đáng kể: admin/hosting compromise có bằng chứng, active data exfiltration, webshell đang hoạt động, redirect/payment tampering, ransomware/destructive action hoặc sự cố ảnh hưởng diện rộng.
P1 thường cần incident owner ngay, containment ưu tiên, escalation tới owner kinh doanh và phối hợp với hosting/CDN hoặc bên thứ ba liên quan.
P2 — High
P2 thường áp dụng khi compromise được xác nhận nhưng phạm vi còn giới hạn, hoặc nguy cơ lan rộng đáng kể nhưng chưa gây impact tối đa. Ví dụ một admin account bị chiếm nhưng đã tạm khóa, plugin bị cài trái phép, malware được xác nhận nhưng chưa thấy dấu hiệu exfiltration.
P3 — Medium
P3 phù hợp với incident có phạm vi nhỏ, đã containment hoặc impact thấp hơn: một account ít quyền bị truy cập, một artefact đáng ngờ nhưng chưa thấy persistence, hoặc sự kiện cần điều tra thêm nhưng chưa có bằng chứng về thiệt hại lớn.
P4 — Low
P4 dành cho sự cố nhỏ đã xác minh, có impact hạn chế và không có dấu hiệu lan rộng. Alert chưa đủ confidence thường nên ở hàng đợi monitoring/triage chứ chưa nhất thiết mở incident P4.
4 yếu tố nên dùng để chấm severity
1. Impact
Đánh giá ảnh hưởng đến confidentiality, integrity và availability: dữ liệu nào có thể bị truy cập, nội dung nào bị sửa, website có bị gián đoạn hay không, và chức năng quan trọng như checkout/login có bị tác động.
2. Scope
Một file đơn lẻ khác hoàn toàn với nhiều website, nhiều account hoặc nhiều hệ thống dùng chung hosting. Vì vậy severity phải được cập nhật sau khi xác định phạm vi ảnh hưởng.
3. Confidence
Confidence mô tả mức chắc chắn rằng sự kiện là malicious. Một indicator đơn lẻ có thể yếu, nhưng nhiều tín hiệu độc lập cùng xác nhận sẽ làm confidence tăng.
4. Attacker control và persistence
Nếu attacker có quyền admin, shell access, persistence qua cron/MU-plugin hoặc credential còn hiệu lực, severity cần phản ánh khả năng họ tiếp tục gây hại ngay cả khi website hiện chưa có biểu hiện rõ.
Severity nên thay đổi trong quá trình điều tra
Severity ban đầu chỉ là đánh giá tại thời điểm triage. Khi có evidence mới, incident phải được nâng hoặc hạ mức.
Ví dụ một sự cố bắt đầu P3 vì chỉ thấy một file lạ. Sau khi phát hiện file đó là webshell và có access log cho thấy sử dụng thành công, incident có thể nâng lên P1/P2 tùy scope và impact.
Do đó hãy ghi lại lý do mỗi lần thay đổi severity trong incident timeline.
P1–P4 không nên chỉ dựa vào số lượng alert
Nhiều alert không đồng nghĩa incident nghiêm trọng hơn. Một WAF rule có thể tạo hàng nghìn hit từ bot nhưng không có exploitation thành công; ngược lại một login thành công vào account đặc quyền có thể chỉ tạo vài log nhưng impact rất lớn.
Để tránh nhầm alert volume với incident impact, xem Security Alert Triage và Incident Triage.
Ví dụ severity matrix cho website
| Mức | Ví dụ | Hành động chính |
|---|---|---|
| P1 | Active compromise, data exposure, payment tampering | Escalate ngay, containment khẩn, bảo toàn evidence |
| P2 | Compromise xác nhận nhưng scope giới hạn hoặc đã containment | Incident owner, điều tra nhanh, kiểm soát credential |
| P3 | Incident nhỏ, impact thấp hơn, cần investigation | Điều tra có lịch, theo dõi scope và evidence |
| P4 | Incident xác minh nhưng tác động rất thấp | Xử lý theo runbook, ghi nhận và review |
Liên kết severity với quy trình Incident Response
Trước hết xác định khi nào cần kích hoạt Incident Response. Sau đó severity quyết định escalation và nhịp xử lý. Từ đây đội phản ứng đi tiếp sang triage, scope, containment, evidence collection và recovery.
NIST SP 800-61 Rev. 3 không bắt buộc mô hình P1–P4 cụ thể; tài liệu nhấn mạnh việc Incident Response phải được tích hợp vào quản trị rủi ro và được điều chỉnh theo bối cảnh tổ chức. Vì vậy P1–P4 trên SecureWebOps nên được coi là operational model, không phải “chuẩn quốc tế cố định”.
Checklist để severity model dùng được thật
- Định nghĩa rõ impact và scope cho từng mức.
- Đưa ví dụ thực tế vào runbook.
- Xác định ai có quyền nâng/hạ severity.
- Gắn từng mức với escalation path và communication cadence.
- Review sau incident để hiệu chỉnh tiêu chí.
Khi severity đã được gán, bước tiếp theo là đánh giá nhanh sự cố bằng Incident Triage và xây dựng phạm vi điều tra dựa trên evidence thay vì cảm tính.