CVSS (Hệ thống chấm điểm lỗ hổng chung)

1. Tổng quan

Định nghĩa: CVSS (Common Vulnerability Scoring System) là một khung đánh giá mức độ nghiêm trọng của lỗ hổng, mang tính mở và chuẩn hóa, do FIRST (Forum of Incident Response and Security Teams) — diễn đàn ứng phó sự cố quốc tế — quản lý. Nó đo lường các đặc tính kỹ thuật của một lỗ hổng phần mềm thông qua các chỉ số (metric) được định nghĩa và quy đổi thành một điểm số định lượng từ 0.0 đến 10.0 cùng một cấp độ (None, Low, Medium, High, Critical), để các tổ chức, sản phẩm và quốc gia khác nhau có thể so sánh và trao đổi rủi ro tương đối của một lỗ hổng trên cùng một thang đo.

Bối cảnh ra đời của CVSS nằm ở sự thiếu vắng một ngôn ngữ chung cho thông tin lỗ hổng. Khi việc công bố lỗ hổng tăng vọt vào đầu những năm 2000, mỗi nhà cung cấp gắn các cấp độ riêng của mình như "khẩn cấp", "quan trọng", "trung bình", và vì phán đoán mức độ nghiêm trọng khác nhau giữa các nhà cung cấp cho cùng một khiếm khuyết, phía người dùng (nhân viên an ninh, người quản lý) khó có thể thiết lập thứ tự ưu tiên vá lỗi một cách hợp lý. Để giải quyết sự hỗn loạn này, CVSS v1 được công bố năm 2005 theo đề xuất của NIAC Hoa Kỳ, và FIRST tiếp quản việc vận hành, trải qua v2 (2007), v3.0 (2015), v3.1 (2019) đến khi phát hành v4.0 vào tháng 11 năm 2023.

Bối cảnh thứ hai là thực tế rằng quản lý lỗ hổng đang chuyển sang hướng dựa trên rủi ro (risk-based). Số lượng CVE (Mã định danh lỗ hổng chung) được công bố mỗi năm lên đến hàng chục nghìn, và năng lực vá lỗi của một tổ chức không thể xử lý tất cả cùng lúc. Do đó cần một tiêu chí khách quan, có thể lặp lại để quyết định "vá gì trước", và CVSS đóng vai trò là điểm khởi đầu bằng cách lượng hóa mức độ nghiêm trọng của lỗ hổng để cung cấp cơ sở sơ cấp cho việc xếp thứ tự ưu tiên.

Bối cảnh thứ ba là sự liên kết với các quy định và tiêu chuẩn. Khi NVD Hoa Kỳ (National Vulnerability Database) gán điểm CVSS cho mọi CVE, và khi các quy định ngành như PCI-DSS yêu cầu "xử lý các lỗ hổng được đánh giá CVSS 4.0 trở lên", CVSS đã trở thành thang đo chung trên thực tế cho quản lý lỗ hổng trên toàn thế giới. Tại Hàn Quốc cũng vậy, các giải pháp bảo mật và báo cáo kiểm tra lỗ hổng áp dụng CVSS làm chỉ số cơ bản, khiến nó trở thành một tiêu chuẩn phải nắm vững dưới góc nhìn của Kỹ sư chuyên nghiệp.

2. Cấu trúc CVSS — Các nhóm chỉ số và tính điểm

Cốt lõi của CVSS là nó đánh giá các đặc tính của lỗ hổng theo các nhóm chỉ số có bản chất khác nhau. Lý do tách các nhóm là vì nếu trộn lẫn "tính chất bản chất" của lỗ hổng với "tính chất thay đổi theo thời gian" và "tính chất chỉ có hiệu lực trong tổ chức của ta" thì ý nghĩa của điểm số sẽ bị mờ nhòe. Sơ đồ khái niệm dưới đây cho thấy cấu trúc chỉ số tổng thể của CVSS (bộ khung chung của v3.1 và v4.0).

flowchart TB
    CVSS["Hệ thống điểm CVSS(0.0~10.0)"]
    BASE["Chỉ số cơ sở(Base) - đặc tính cố hữu, bất biến"]
    TEMP["Chỉ số mối đe dọa/thời gian(Threat·Temporal) - thay đổi theo thời gian"]
    ENV["Chỉ số môi trường(Environmental) - phản ánh bối cảnh tổ chức"]
    SUPP["Chỉ số bổ trợ(Supplemental, v4.0) - tham khảo(không ảnh hưởng điểm)"]
    CVSS --> BASE
    CVSS --> TEMP
    CVSS --> ENV
    CVSS --> SUPP
    BASE --> EXP["Khả năng khai thác(AV·AC·PR·UI, v.v.)"]
    BASE --> IMP["Mức tác động(bảo mật·toàn vẹn·sẵn sàng)"]

Chỉ số cơ sở (Base) đánh giá các đặc tính bản chất không đổi của chính lỗ hổng và tạo thành bộ xương của điểm CVSS. Chúng lại được chia thành "Khả năng khai thác (Exploitability)" và "Mức tác động (Impact)". Khả năng khai thác là trục đo kẻ tấn công có thể chạm tới lỗ hổng dễ dàng đến mức nào, gồm Vector tấn công (AV: Network, Adjacent, Local, Physical), Độ phức tạp tấn công (AC: Low, High), Quyền yêu cầu (PR: None, Low, High) và Tương tác người dùng (UI: None, Required). Ví dụ, một lỗ hổng bị khai thác từ xa qua mạng (AV:N), không cần điều kiện đặc biệt (AC:L), không cần xác thực (PR:N), không cần người dùng can thiệp (UI:N) sẽ đạt điểm khả năng khai thác tối đa, làm tăng nguy cơ tự lan truyền kiểu sâu máy tính (worm).

Mức tác động đánh giá mức độ bảo mật (C), toàn vẹn (I) và sẵn sàng (A) bị tổn hại ra sao (None, Low, High) khi lỗ hổng bị khai thác thành công. Lý do đánh giá tách biệt ba yếu tố là vì rò rỉ thông tin (bảo mật), sửa đổi dữ liệu (toàn vẹn) và gián đoạn dịch vụ (sẵn sàng) gây ra thiệt hại có bản chất hoàn toàn khác nhau cho tổ chức. Ở v3.1, khái niệm Phạm vi (Scope) được thêm vào đây để phản ánh liệu thiệt hại từ thành phần dễ bị tổn thương có vượt qua ranh giới quyền hạn bảo mật để ảnh hưởng đến các thành phần khác hay không (Changed/Unchanged). Ví dụ, nếu một lỗ hổng hypervisor cho phép VM khách chiếm quyền máy chủ, Scope trở thành Changed và điểm số tăng mạnh.

Chỉ số mối đe dọa/thời gian hiệu chỉnh cho các đặc tính thay đổi theo thời gian. Nhóm Temporal của v3.1 gồm Độ trưởng thành của mã khai thác (E), Mức độ khắc phục (RL) và Độ tin cậy báo cáo (RC), thể hiện rủi ro thay đổi tùy theo chỉ có PoC hay đã công bố mã khai thác thực sự. v4.0 đơn giản hóa nó thành nhóm chỉ số Mối đe dọa (Threat) chỉ giữ lại "Độ trưởng thành khai thác (E)", vì đánh giá rằng vai trò này chồng lấn với thông tin mối đe dọa bên ngoài như EPSS sẽ đề cập sau.

Chỉ số môi trường (Environmental) phản ánh rằng ngay cả với cùng một lỗ hổng, rủi ro thực tế trong môi trường của tổ chức ta vẫn khác nhau. Chúng gia trọng mức độ quan trọng về bảo mật, toàn vẹn, sẵn sàng của tài sản (Yêu cầu bảo mật CR, IR, AR) và cho phép sửa đổi chỉ số cơ sở (Modified Base) theo các biện pháp giảm thiểu mà tổ chức đã áp dụng. Ví dụ, với lỗ hổng DB trên mạng kín không lộ ra internet, vector tấn công bị hạn chế trên thực tế, nên việc điều chỉnh điểm môi trường xuống thấp là hợp lý.

Điểm số được tính bằng cách cộng gộp các điểm con khả năng khai thác và mức tác động qua một công thức định sẵn để ra 0.0 đến 10.0, rồi ánh xạ sang cấp độ. Bảng dưới đây là các dải cấp độ nghiêm trọng chung cho v3.1/v4.0.

3. Xếp ưu tiên dựa trên rủi ro và liên kết EPSS/KEV

Việc xác định thứ tự vá chỉ bằng điểm CVSS có một hạn chế mang tính cấu trúc. Điểm cơ sở CVSS đo "nó có thể nghiêm trọng đến đâu (severity)", nhưng không nói gì về "khả năng thực sự bị tấn công là bao nhiêu (likelihood)". Thống kê của NVD cho thấy một phần lớn CVE được công bố tập trung ở High và Critical, nên nếu chỉ lấy điểm cơ sở làm tiêu chí thì mọi thứ đều "đầy rẫy nguy hiểm", khiến chức năng xếp ưu tiên tê liệt trên thực tế. Thực tế, nhiều nghiên cứu liên tục báo cáo rằng chỉ một tỷ lệ phần trăm một chữ số trong toàn bộ lỗ hổng được công bố thực sự bị dùng trong tấn công.

Để lấp đầy khoảng trống này, quản lý lỗ hổng hiện đại kết hợp CVSS với EPSS, KEV và bối cảnh tài sản. EPSS (Exploit Prediction Scoring System) cũng do FIRST vận hành, dùng mô hình học máy để dự đoán xác suất (0 đến 1) rằng một lỗ hổng nhất định sẽ thực sự bị khai thác trong 30 ngày tới. Nếu CVSS là "độ lớn của thiệt hại" thì EPSS là trục bổ sung về "khả năng bị khai thác". KEV (Known Exploited Vulnerabilities) là danh sách các lỗ hổng được xác nhận là đã bị khai thác thực sự, do CISA Hoa Kỳ vận hành; việc có tên trong danh sách nghĩa là nó không phải "rủi ro lý thuyết" mà là "mối đe dọa đang diễn ra".

Sơ đồ luồng dưới đây cho thấy quy trình xếp ưu tiên dựa trên rủi ro, bắt đầu từ CVSS và kết hợp EPSS, KEV cùng bối cảnh tài sản.

flowchart LR
    A["Xác định lỗ hổng(CVE·máy quét)"] --> B["Tính điểm cơ sở CVSS(mức nghiêm trọng)"]
    B --> C["Áp dụng EPSS(dự đoán xác suất khai thác)"]
    C --> D["Tra cứu KEV(có bị khai thác thực tế)"]
    D --> E["Phản ánh mức quan trọng tài sản·chỉ số môi trường"]
    E --> F{"Quyết định ưu tiên rủi ro"}
    F -->|"Cao"| G["Vá·giảm thiểu ngay"]
    F -->|"Thấp"| H["Đưa vào chu kỳ vá định kỳ"]

Trong thực tế, các chính sách phân loại, ví dụ, lỗ hổng "có CVSS 9.0 trở lên VÀ nằm trong KEV, hoặc có EPSS 0.5 trở lên" là đối tượng xử lý ngay, trong khi các Critical/High khác được xử lý bằng vá định kỳ theo SLA. Nhờ vậy, ngay cả giữa hàng nghìn Critical, có thể tập trung nguồn lực vào vài chục lỗ hổng "đang nguy hiểm ngay lúc này", cải thiện đáng kể hiệu suất của nhân sự an ninh hạn chế.

Như một trường hợp cụ thể, Log4Shell (CVE-2021-44228) năm 2021 đạt 10.0 (Critical) theo CVSS v3.1 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H); nó cho phép thực thi mã tùy ý từ xa mà không cần xác thực và tác động lan sang các hệ thống khác (S:C), đạt điểm tối đa, và được đưa ngay vào KEV ngay sau khi công bố, kích hoạt ứng phó khẩn cấp trên toàn thế giới. Ngược lại, có nhiều lỗ hổng CVSS cao nhưng EPSS/KEV thấp, nên nhìn ba chỉ số cùng nhau là cách tránh cả phản ứng thái quá lẫn thiếu.

4. So sánh phiên bản — v3.1 và v4.0, các hệ thống tương tự

CVSS v4.0 được cải tổ bằng cách tiếp nhận thẳng thắn các chỉ trích nhắm vào v3.1. Thay đổi lớn nhất là việc bãi bỏ chỉ số Phạm vi (Scope); thay cho Scope vốn thường bị chê là mơ hồ, nó tách rõ ràng tác động Hệ thống dễ bị tổn thương (VC·VI·VA) và tác động Hệ thống kế tiếp (SC·SI·SA) để biểu đạt sự lan truyền thiệt hại chính xác hơn. Nó cũng bổ sung chỉ số Yêu cầu tấn công (AT) xét xem có cần điều kiện cụ thể để tấn công thành công hay không, và chia nhỏ Tương tác người dùng (UI) thành None, Passive, Active.

Thay đổi thứ hai là bổ sung nhóm chỉ số Bổ trợ (Supplemental). Nó chứa thông tin hữu ích cho phán đoán vận hành như An toàn (Safety), Khả năng tự động hóa (Automatable), Phục hồi (Recovery), Mật độ giá trị (Value Density), nhưng là các chỉ số tham khảo không ảnh hưởng đến điểm số. Thứ ba, v4.0 giới thiệu một quy ước đặt tên để minh bạch chỉ ra một điểm số phản ánh tới chỉ số nào, như CVSS-B (chỉ Base), CVSS-BT (Base+Threat), CVSS-BE (Base+Environmental), CVSS-BTE (toàn bộ). Điều này đáp lại chỉ trích lâu nay rằng "hầu hết tổ chức chỉ dùng điểm cơ sở và không tận dụng chỉ số thời gian/môi trường nên điểm bị phóng đại".

CVSS có vai trò khác biệt với các tiêu chuẩn bảo mật khác như CVE, CWE và EPSS. Nếu CVE xử lý "đó là lỗ hổng nào (định danh)" và CWE "đó là loại khiếm khuyết gì (phân loại)", thì CVSS đảm nhận "nó nghiêm trọng đến đâu (đánh giá)". Ngoài ra, trong bảo mật chuỗi cung ứng, nhiều tiêu chuẩn liên kết với nhau như một mắt xích: thành phần được nhận diện bằng [[sbom]], [[vex-vulnerability-exploitability-exchange]] xác định "lỗ hổng đó có thực sự ảnh hưởng đến sản phẩm của ta hay không", rồi CVSS gán mức nghiêm trọng.

5. Chuyên sâu: Xu hướng mới nhất và áp dụng thực tiễn

Gần đây, mô thức quản lý lỗ hổng đã chuyển từ "lấy mức nghiêm trọng làm trung tâm" sang "lấy khả năng khai thác và mức độ phơi nhiễm làm trung tâm". Điều này là kết quả của việc hạn chế khi dùng CVSS đơn lẻ được nhận thức rộng rãi; Gartner và các bên khác đã khuyến nghị tổ chức chuyển sang quản lý lỗ hổng dựa trên rủi ro (RBVM) và quản lý phơi nhiễm mối đe dọa liên tục (CTEM), tích hợp CVSS, EPSS, tình báo mối đe dọa và mức quan trọng tài sản (các con số và thời điểm chi tiết khác nhau tùy phiên bản báo cáo, nên cần hiểu một cách khái quát). Thực vậy, các mô hình ra quyết định phân loại thành hành động/theo dõi/quan sát qua phán đoán hỏi-đáp về "tình trạng khai thác, khả năng tự động hóa và tác động nhiệm vụ" — thay vì xếp hàng theo một điểm duy nhất — đang lan rộng, như SSVC (Stakeholder-Specific Vulnerability Categorization) của chính phủ Hoa Kỳ.

Như một trường hợp áp dụng thực tiễn, các công ty tài chính lớn và nhà cung cấp đám mây áp điểm cơ sở CVSS làm bộ lọc cơ bản trên kết quả máy quét với hàng chục nghìn tài sản, và trên đó tự tính một điểm rủi ro có trọng số kết hợp xác suất EPSS và tình trạng nằm trong KEV, vận hành SLA vá lỗi (ví dụ: 24 giờ cho mục trong KEV, 7 ngày cho Critical, 30 ngày cho High). Nhờ vậy thoát khỏi đống hàng nghìn Critical mà CVSS tạo ra và cho phép tổ chức tập trung vào số ít thực sự gây đe dọa. Ngoài ra, trong đường ống [[devsecops]], một cổng ngưỡng CVSS (ví dụ: chặn bản dựng khi phát hiện 7.0 trở lên) được áp lên kết quả quét phụ thuộc ở giai đoạn dựng, sàng lọc các lỗ hổng trước khi chúng vào môi trường vận hành.

Dưới góc nhìn ra đề, CVSS liên kết chặt với các câu hỏi như "Giải thích hệ thống đánh giá/quản lý lỗ hổng", "Phương pháp quản lý lỗ hổng dựa trên rủi ro", "Hạn chế của CVSS và biện pháp bổ sung (liên kết EPSS/KEV)". Khi soạn bài trả lời, một mạch hiệu quả là (A) định nghĩa khái niệm bằng cấu trúc chỉ số CVSS (Cơ sở, Mối đe dọa, Môi trường), (B) thể hiện tính cập nhật bằng các cải tiến của v4.0, (C) chỉ ra hạn chế khi dùng CVSS đơn lẻ, và (D) đưa ra giải pháp thực tiễn bằng xếp ưu tiên dựa trên rủi ro kết hợp EPSS, KEV và bối cảnh tài sản.

6. Cân nhắc và hàm ý

Dưới góc nhìn của Kỹ sư chuyên nghiệp, CVSS nên được xử lý không phải như "bản thân điểm số" mà như một đầu vào cho việc ra quyết định dựa trên rủi ro, cân nhắc toàn diện những điều sau.

• Chiến lược áp dụng (không dùng đơn lẻ): Đặt ưu tiên chỉ bằng điểm cơ sở CVSS khiến ta bị ngợp bởi đống Critical quá lớn, nên hãy thiết lập chính sách quản lý lỗ hổng dựa trên rủi ro (RBVM) kết hợp EPSS (xác suất khai thác), KEV (khai thác thực tế) và mức quan trọng tài sản, và nhất thiết phản ánh các chỉ số môi trường phù hợp với đặc tính tổ chức.
• Đánh đổi (độ chính xác vs chi phí vận hành): Đánh giá chính xác tới cả chỉ số thời gian/môi trường làm tăng tính hiện thực của điểm nhưng tăng gánh nặng thủ công cho từng tài sản. Đánh giá chính xác toàn công ty là phi thực tế, nên một cách tiếp cận phân tầng — đánh giá sâu các tài sản cốt lõi và vùng phơi nhiễm bên ngoài trước, còn lại quản lý bằng điểm cơ sở tự động hóa — là thực tế hơn.
• Cảnh giác lạm phát điểm/lạm dụng: CVSS được thiết kế giả định "kịch bản xấu nhất" nên điểm có xu hướng cao, và méo mó xảy ra khi nhà cung cấp cố ý thổi phồng hoặc hạ điểm để né tránh trách nhiệm. Do đó đừng tin mù quáng điểm NVD/nhà cung cấp mà hãy đánh giá lại bằng chỉ số môi trường của riêng mình, và xác nhận một điểm số phản ánh tới chỉ số nào, như ký hiệu CVSS-BTE ở v4.0.
• Tính nhất quán quản trị/quy định: Thiết kế các ngưỡng CVSS mà các quy định như PCI-DSS yêu cầu sao cho nhất quán với SLA vá lỗi và các hạng mục kiểm soát [[isms-p]], đồng thời ghi lại lịch sử xử lý lỗ hổng và căn cứ (điểm, EPSS, KEV) để bảo đảm khả năng truy vết kiểm toán.
• Triển vọng/công nghệ liên kết: CVSS có thể xử lý rủi ro toàn chuỗi cung ứng một cách hệ thống khi kết hợp với [[sbom]], [[vex-vulnerability-exploitability-exchange]], [[mitre-attack]] và [[threat-modeling]], và trong tương lai, các mô hình lấy ra quyết định làm trung tâm như SSVC, CTEM kết hợp với dự đoán khai thác dựa trên AI được kỳ vọng sẽ tiến hóa vượt khỏi "xếp hạng theo điểm" thành quản lý rủi ro nhận thức bối cảnh.

Tài liệu tham khảo

• FIRST, "CVSS v4.0 Specification Document". https://www.first.org/cvss/v4-0/specification-document
• FIRST, "Common Vulnerability Scoring System SIG". https://www.first.org/cvss/
• FIRST, "EPSS — Exploit Prediction Scoring System". https://www.first.org/epss/
• CISA, "Known Exploited Vulnerabilities Catalog". https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NIST NVD, "Vulnerability Metrics". https://nvd.nist.gov/vuln-metrics/cvss

Tóm tắt một câu: CVSS là hệ thống đánh giá mức độ nghiêm trọng lỗ hổng tiêu chuẩn do FIRST quản lý, tính điểm 0.0–10.0 từ các chỉ số Cơ sở, Mối đe dọa và Môi trường; hạn chế chỉ đo mức nghiêm trọng của nó phải được bổ sung bằng xếp ưu tiên dựa trên rủi ro kết hợp EPSS (xác suất khai thác), KEV (khai thác thực tế) và bối cảnh tài sản thì mới có giá trị thực tiễn.