Sau khi một finding đã được xác minh, câu hỏi tiếp theo thường là: “Mức độ nghiêm trọng của finding này là bao nhiêu và nên xử lý trước hay sau finding khác?”
Đây là điểm dễ bị đơn giản hóa quá mức. Một scanner gắn nhãn “Critical” không tự động có nghĩa finding đó là ưu tiên số 1 của doanh nghiệp. Ngược lại, một vấn đề kỹ thuật chỉ ở mức “Medium” có thể trở thành ưu tiên cao nếu nó nằm trên asset rất quan trọng, đang public và có ảnh hưởng trực tiếp tới dữ liệu hoặc quyền quản trị.
Bài này tập trung vào Security Finding Severity, risk, impact và likelihood, đồng thời phân biệt chúng với remediation priority. Nội dung chỉ áp dụng cho finding đã qua Security Finding Validation.
Security Finding Severity là gì?
Severity mô tả mức độ nghiêm trọng của một weakness hoặc vulnerability trong bối cảnh kỹ thuật đã được xác định.
Tùy framework, severity có thể dựa trên điều kiện khai thác, quyền hoặc tương tác cần thiết, phạm vi tác động, ảnh hưởng tới confidentiality/integrity/availability và các yếu tố threat/environment bổ sung.
Severity hữu ích để chuẩn hóa cách nói về finding, nhưng severity không đồng nghĩa hoàn toàn với business risk hoặc remediation priority.
Phân biệt Severity, Risk, Impact, Likelihood và Priority
| Khái niệm | Câu hỏi chính |
|---|---|
| Technical Severity | Weakness nghiêm trọng về mặt kỹ thuật đến đâu? |
| Impact | Nếu condition bị abuse hoặc control thất bại, hậu quả là gì? |
| Likelihood | Trong context hiện tại, khả năng dẫn tới sự kiện không mong muốn ra sao? |
| Risk | Finding nguy hiểm thế nào với asset và doanh nghiệp cụ thể? |
| Remediation Priority | Nên xử lý finding này khi nào so với các việc khác? |
Một mô hình tốt có thể dùng severity làm đầu vào cho risk, rồi dùng risk cùng operational context để quyết định priority.
Đánh giá Impact và Likelihood đúng cách
Confidentiality Impact
Dữ liệu nào có thể bị đọc ngoài quyền: public content, thông tin tài khoản, dữ liệu khách hàng, credential/secret, business data, backup hoặc log nhạy cảm.
Integrity Impact
Attacker có thể thay đổi gì: nội dung website, user role, configuration, đơn hàng, DNS, code/file hoặc log/evidence.
Availability Impact
Finding có thể làm gián đoạn một chức năng, một user, toàn website, origin/backend hoặc khả năng recovery.
Business Impact
Đây là lớp mà technical score thường không thể tự biết: mất doanh thu, gián đoạn vận hành, ảnh hưởng hợp đồng/khách hàng, chi phí incident response, mất quyền quản trị hoặc rủi ro dữ liệu.
Không nên bịa con số tài chính nếu không có first-party data. Có thể mô tả loại impact và để business owner định lượng khi cần.
Likelihood
Likelihood không nên chỉ dựa trên câu hỏi “có exploit public hay không”. Nó có thể bị ảnh hưởng bởi asset public/internal, authentication hoặc privilege requirement, user interaction, độ phức tạp khai thác, feature vulnerable có bật không, attack path có reachable không, evidence về exploitation, compensating control và mức độ phổ biến của asset/component.
Likelihood là estimate dựa trên evidence và context, không phải xác suất toán học chính xác nếu tổ chức không có dữ liệu để tính.
Risk Model và CVSS nên dùng thế nào?
Có nên dùng Risk = Likelihood × Impact?
Công thức này hữu ích như một mô hình tư duy đơn giản, nhưng không phải chân lý phổ quát. Nếu tổ chức dùng ma trận Low/Medium/High, có thể kết hợp likelihood và impact để tạo risk band nhất quán, miễn là định nghĩa từng mức rõ ràng.
| Likelihood \ Impact | Low | Medium | High |
|---|---|---|---|
| Low | Low | Low/Medium | Medium |
| Medium | Low/Medium | Medium | High |
| High | Medium | High | High/Critical theo policy |
Đây chỉ là ví dụ governance. Tổ chức có thể dùng scale khác nếu phù hợp risk model của mình.
CVSS là gì và dùng ở đâu?
CVSS – Common Vulnerability Scoring System là framework do FIRST duy trì để mô tả các đặc tính chính của vulnerability và tạo numerical score cho technical severity.
CVSS v4.0 là phiên bản chính thức hiện hành của FIRST. Nó hữu ích khi cần chuẩn hóa technical severity, so sánh vulnerability theo cùng framework, ghi vector để người khác hiểu assumptions và kết hợp advisory data trong vulnerability management.
Nhưng CVSS không tự biết website kiếm bao nhiêu doanh thu, dữ liệu nào quan trọng nhất hoặc finding nào phải xử lý trước vì business deadline. Do đó:
CVSS score ≠ business risk ≠ remediation priority.
Context nào làm Risk hoặc Priority thay đổi?
Asset Criticality
Cùng một finding trên hai asset có thể tạo risk khác nhau. Staging demo không dữ liệu thật khác production customer portal; DNS/registrar account có thể có blast radius toàn domain; corporate blog có integrity/reputation risk riêng.
Exposure và Reachability
Cần xem asset Internet-facing hay internal, có cần VPN/account/privilege không, endpoint có discoverable không, origin có bypass edge control không và có IP allowlist/WAF/network segmentation không.
Exposure không làm weakness biến mất, nhưng ảnh hưởng likelihood và urgency.
Exploitability
Không nên dùng “dễ khai thác” nếu không có cơ sở. Nên mô tả attack vector, authentication/privilege requirement, user interaction, complexity, precondition, public exploit evidence nếu đã xác minh và khả năng tái hiện trong scope.
Với finding không được phép exploit, report nên nói rõ potential exploitability và limitation thay vì giả vờ đã chứng minh impact.
Compensating Control
Nên tách intrinsic/technical severity, environmental risk và remediation priority. MFA, network restriction hoặc WAF có thể giảm likelihood nhưng không nhất thiết làm underlying weakness biến mất.
Finding Chain
Nhiều finding riêng lẻ có thể tạo attack path nguy hiểm hơn tổng từng phần, ví dụ:
Username enumeration → weak password policy → thiếu MFA → admin access
Security Audit Report nên có khả năng ghi nhận finding relationship hoặc risk theme thay vì chỉ sắp danh sách theo điểm.
Severity và Priority có thể lệch nhau như thế nào?
CVSS cao nhưng Priority thấp hơn
Có thể xảy ra khi component chỉ nằm trên staging biệt lập, feature vulnerable bị tắt, asset không reachable, compensating control giảm exposure đáng kể hoặc component sắp decommission theo change window đã xác nhận.
Có thể giữ technical severity nhưng ghi environmental/business priority khác.
Severity thấp nhưng Priority cao hơn
Cũng có thể xảy ra khi finding nằm trên login của toàn bộ khách hàng, là mắt xích trong attack chain, ảnh hưởng DNS/domain control, đang chặn assurance requirement hoặc có threat evidence làm urgency tăng.
Priority là quyết định vận hành, không chỉ là phép sắp xếp điểm scanner.
Đừng dùng Severity để che Confidence thấp
Thứ tự đúng nên là:
Validation → Evidence/Confidence → Severity → Risk → Priority
Nếu confidence thấp, finding cần thêm validation hoặc limitation trước khi đưa vào executive risk summary.
Mô hình thực dụng để chấm và quản trị Finding
5 bước đánh giá
- Xác nhận finding: candidate đã qua validation.
- Chấm technical severity: dùng CVSS hoặc framework nội bộ khi phù hợp.
- Đánh giá asset/context: criticality, exposure, data, control.
- Đánh giá likelihood/impact: dựa trên evidence, không dựa trên fear.
- Gán remediation priority: xét risk, exploitation evidence, dependency và operational window.
Severity band nên được định nghĩa bằng Policy
Nếu dùng Informational/Low/Medium/High/Critical, tổ chức nên định nghĩa điều kiện vào từng band, ai được override, override cần evidence gì, cách xử lý exception/acceptance và target remediation nếu có policy.
Không nên lấy một bảng màu từ tool rồi coi đó là risk policy của doanh nghiệp.
Severity và Remediation SLA
Nhiều tổ chức gắn severity với target remediation time. Cách này hữu ích để vận hành nhưng không nên biến thành con số cứng áp dụng mọi hệ thống. SLA cần xét business criticality, active exploitation evidence, availability requirement, change window, fix complexity, temporary mitigation và risk acceptance.
Checklist đánh giá Severity và Risk
- Finding đã được validate chưa?
- Asset nào bị ảnh hưởng và criticality là gì?
- Attack path có reachable không?
- Có cần authentication/privilege/user interaction không?
- Impact kỹ thuật đã chứng minh tới đâu?
- Business impact nào hợp lý, cái nào chưa có evidence?
- Có compensating control không?
- Có evidence về exploitation hoặc threat context không?
- Technical severity framework nào đang dùng?
- Remediation priority có khác technical severity không, và tại sao?
Ví dụ: cùng Vulnerability, hai Priority khác nhau
Asset A
- staging;
- IP allowlist;
- không dữ liệu thật;
- scheduled decommission trong 7 ngày.
Technical severity vẫn cao, nhưng remediation priority có thể được quản lý theo decommission plan nếu risk owner đồng ý.
Asset B
- production;
- Internet-facing;
- chứa customer data;
- feature vulnerable đang bật;
- không có compensating control đáng kể.
Finding tương tự có thể trở thành ưu tiên khẩn cấp hơn nhiều.
Kết luận
Security Finding Severity là một phần của risk analysis, không phải toàn bộ quyết định remediation. Technical severity giúp chuẩn hóa đặc tính vulnerability; risk bổ sung asset, exposure, impact, likelihood và control; priority chuyển risk thành thứ tự hành động.
CVSS v4.0 là framework kỹ thuật hữu ích, nhưng không nên được dùng như business risk score tự động.
Sau khi finding đã được validate và đánh giá severity/risk, kết quả cần được trình bày theo cách người quản lý và đội kỹ thuật đều hành động được tại Security Audit Report. Khi cần chuyển risk thành thứ tự xử lý thực tế, xem cách ưu tiên Security Finding theo Risk, Impact và Effort.
Để xem toàn bộ chuỗi từ scope, validation và risk analysis đến remediation và retest, xem hub Website Security Audit.