关于CVSS V4.0,你想知道的都在这了!
2023-11-15 18:0:59 Author: 看雪学苑(查看原文) 阅读量:10 收藏

目录

1 关于CVSS和CVSS V4

2 CVSS V4相比V3.1的变化点

       2.1 变更概览

       2.2 变更详解

              2.2.1 细化基础指标粒度

              2.2.2 删除范围(scope)指标

              2.2.3 调整时间指标组(Temporal Metrics)为威胁指标组(Threat Metrics)

              2.2.4 新增补充指标组(Supplemental Metrics)

              2.2.5 增加OT/ICS/IoT行业适配

3 CVSS V4体现的趋势

       3.1 CVSS V4有哪些观点

       3.2 CVSS V4体现的趋势

4 启示和建议

 附录

1.关于CVSS和CVSS V4

CVSSCommon Vulnerability Scoring System)中文译为:通用漏洞评分系统,是一个免费、开放的行业事实标准。CVSS提供了一种捕获漏洞主要特征并生成反映其严重性的数字评分的方法,同时将数字评分转换为定性表示(例如低、中、高和严重),以帮助组织正确评估漏洞管理流程并确定响应优先级。

CVSSCommon Vulnerability Scoring System)由美国国家基础设施咨询委员会(National Infrastructure Advisory CouncilNIAC)发起,NIAC后来将CVSS评分标准托管给FIRSTForum of Incident Response and Security Teams)维护(FIRST CVSS SIG)。目前已经发布了5个版本。下图回顾了CVSS标准的发展史。

由上图可以看出,CVSS V3已经存在8年之久(也是应用最广泛的一个版本),随着行业发展,其在漏洞评估方面也展现出了一些争议,虽然经历过微小版本更新(CVSS V3.1),但仍存在一些批评。在经历多次延期之后,FIRST CVSS SIG终于于2023111日正式发布CVSS V4.0(参考附录1),其较CVSS V3.1变化巨大。

2.CVSS V4相比V3.1变化点

2.1 变更概览

CVSS V4.0较CVSS V3.1最直观的变化点是基本指标由以前的8个变更为11个。这是普通CVSS使用者最大的冲击。
然而从整体来看,CVSS V4.0主要变更点主要有5个:
  1. 细化基础指标粒度

    1. 将攻击复杂度(AC)指标拆分为AC(攻击复杂度)和攻击要求(AT)两个指标
    2. 细化用户交互(UI)指标粒度
  2. 删除范围(Scope)指标

    1. 删除范围变更(Scope)指标

    2. 将影响因素(C/I/A)拆分为缺陷系统(Vulnerable System)和后续系统(Subsequent System)两部分的C/I/A

  3. 调整时间指标组(Temporal Metrics)为威胁指标组(Threat Metrics)

    1. 删除时间指标组中的修复水平(RL:Remediation Level)和报告置信度(RC:Report Confidence)2个指标

    2. 简化利用代码成熟度(E:Exploit Code Maturity)为利用成熟度(E:Exploit Maturity)

  4. 新增补充指标组(Supplemental Metrics),含有6个指标。

    1. 安全性(S:Safety)

    2. 自动化(AU:Automatable)

    3. 供应商漏洞紧急度(U:Provider Urgency)

    4. 恢复性(R:Recovery)

    5. 价值密度(V:Value Density)

    6. 漏洞响应工作(RE:Vulnerability Response Effort )

  5. 增加OT/ICS/IoT行业适配

    1. 在补充指标组中增加安全性(S:Safety)指标

    2. 在环境指标组(Environmental Metrics)后续系统评分中,针对完整性和可用性增加安全性(S:Safety)选项,即MSI:S和MSA:S。
下图勾勒出上述5大变化点。
接下来针对这5大变化点进行详细阐述。

2.2 变更详解

2.2.1. 细化基础指标粒度

1.将攻击复杂度(AC)指标拆分为AC(攻击复杂度)和攻击要求(AT)两个指标

AC → AC + AT:简化AC;增加ATAttack Requirement)

 AC(Attack Complexity):
该指标捕获攻击者为主动规避或规避现有内置安全增强条件而必须采取的可衡量操作,以获得有效的利用。(所克服的)这些条件的主要目的是提高安全性和或增加漏洞利用工程的复杂性。
AT(Attack Requirement)

该指标捕获了启用攻击的易受攻击系统的先决部署和执行条件或变量。这些与安全增强技术/技术(参考攻击复杂性)不同,因为这些条件的主要目的不是明确减轻攻击,而是作为易受攻击的系统的部署和执行的结果自然出现。如果攻击者不采取行动克服这些条件,攻击可能只是偶尔成功或根本不成功。

如何有效区分ACAT?
ACAttack Complexity ):内置挑战(BUILT-IN CHALLENGES);攻击者必须采取行动来主动规避或规避内置的安全增强条件。示例包括:ASLR DEP或者,攻击者必须收集一些与目标强相关的秘密,然后攻击才能成功。秘密是无法通过任何侦察渠道获得的信息。为了获得这些秘密,攻击者必须执行额外的攻击或破坏其他安全措施(例如,可能需要知道密钥才能破坏加密通道)。注意:执行特定站点的评估时,内置防火墙过滤器作为补偿控制的存在可以通过修改后的攻击复杂性 (MAC) 环境指标来表示。

ATAttack Requirements):外部挑战(EXTERNAL CHALLENGES):必须克服易受攻击系统的部署和执行条件或变量。示例包括:竞争条件或中间人攻击。注意执行特定于站点的评估时,可以通过修改的攻击要求 (MAT) 环境指标来表示作为补偿控制的外部防火墙过滤器的存在。

2. 细化用户交互(UI)指标粒度

用户交互(UIUser Interaction)指标取值由(None, RequiredNonePassiveActive),将需要用户交互细化为被动交互主动交互

被动(Passive):成功利用此漏洞需要目标用户与易受攻击的系统和攻击者的有效负载进行有限的交互。这些交互将被视为非自愿的,并且不需要用户主动破坏易受攻击的系统中内置的保护措施。示例:打开Outlook预览页导致攻击。
主动(Active):成功利用此漏洞需要目标用户与易受攻击的系统和攻击者的有效负载执行特定的、有意识的交互,或者用户的交互会主动破坏保护机制,从而导致漏洞被利用。示例:明确忽略 Excel 关于电子表格中可能包含潜在恶意脚本的警告。
注意

    ·针对反射性XSSUIA:反射式XSS要求用户单击特定链接才能触发漏洞利用。用户可以选择或有机会在与链接交互之前查看该链接合法性。其可以有意识地决定是否与攻击者的有效负载进行交互,因此这将被视为主动(Active)。

    ·针对存储型XSSUIP:存储型XSS不需要特制的链接来触发漏洞。用户在正常浏览网站时可能会无意中触发漏洞利用,并且在漏洞利用之前没有意识或没有能力避免与攻击者有效负载的交互。因为没有有意识地决定与有效负载交互,所以这将被视为被动(Passive)。

    ·针对用户单击链接的行为,UIA:与反射型XSS类似,在单击链接之前,用户可以选择或有机会查看该链接。由于用户正在有意识地决定通过链接与攻击者的有效负载进行交互,因此这将被视为主动(Active)。

2.2.2. 删除范围(Scope)指标

范围(Scope可能是CVSS V3中最不受欢迎的指标,其在多个场景中均存在较大歧义,这导致不同组织之间、不同漏洞评估人员之间存在的较大的认知差异。因此在CVSS V4.0Scope指标光荣退休了。

取而代之的,是将影响指标(C/I/A拓展针对缺陷系统(Vulnerable System)和后续系统(Subsequent System)两部分的C/I/A即:C/I/A → VC/VI/VA + SC/SI/SA针对C/I/A指标的取值没有本质变化,大家可以参考历史版本打分即可。接下来将针对如何区分缺陷系统(Vulnerable System)和后续系统(Subsequent System)进行详细阐述。

CVSS V4中提出,为进行度量,漏洞评估者应该使用感兴趣的系统概念模型the conceptual model of a system of interest)。

通常来讲,在评分时感兴趣系统可以定义为:在具有连贯功能和安全策略集的环境中执行的一组计算逻辑(set of computing logic)。漏洞存在于此类系统的一个或多个组件中。从消费者角度来看,为达成某一目的或功能服务的技术产品或解决方案可被视为系统(例如服务器、工作站、容器化服务等)。

需要注意的是:当一个系统仅向另一个系统提供功能时,或者它被设计为专门由另一个系统使用时,那么它们可被一起视为评分感兴趣的系统。例如,仅由智能扬声器使用的数据库被视为该智能扬声器系统的一部分。如果数据库中的漏洞导致智能扬声器发生故障,则数据库及其服务的智能扬声器都将被视为易受攻击的系统。

那么如何有效区分缺陷系统和后续系统的边界呢,可以记住如下几个原则:
  • 确定缺陷系统

对于缺陷系统的确定,可以考虑漏洞存在或者漏洞被利用的范围。AVACATPRUI都是基于此进行决策打分。比如,漏洞存在的的模块或者服务属于一个更大的单元的一部分,其本身是无法独立存在的,那么缺陷系统可以几乎肯定就是整个单元。
举例:供应商提供的应用程序中包含多个服务,其中一个服务存在漏洞。如果这个服务无法单独存在,或者换一句话,这个服务对于整个大的服务集来说是不可缺少的,那么缺陷系统就是这个大的应用程序。
  • 确定后续系统

后续系统包括所有不是缺陷系统的东西,并且以某种方式被缺陷系统中的漏洞影响。
举例:同样是上述用例,若存在缺陷的服务可以与该应用程序的其他组件分开(比如供应商可以提供2个组件,并且一个组件不是另一个的组成部分),那么漏洞就是存在于被应用程序消费的这个服务中。在本例中,缺陷系统是这个服务(而非应用程序);如果应用程序安全性被这个服务中的漏洞影响,那么应用程序的影响可以在后续系统CIA中体现。
针对缺陷系统后续系统CVSS同样提供了一些典型场景,便于理解:

场景1攻击者能利用虚拟机中的漏洞读取和/或删除主机操作系统文件

缺陷系统是虚拟机;后续系统是主机。

场景2用户态低权限运行程序,突破边界进入高权限执行任意代码。

只有缺陷系统(微处理器)

场景3微处理器中的安全飞地SESecure Enclave 与其他操作系统进程(包括操作系统内核本身)之间的安全边界突破要考虑在后续系统影响中。比如安全边界外的一个漏洞影响到了安全飞地中的数据或者代码的CIA

缺陷系统是代码发生的安全飞地;后续系统是被影响到的安全飞地。

场景4Web应用程序中的漏洞影响用户客户端(例如Web浏览器)

缺陷系统是Web应用程序;后续系统是用户客户端。(如跨站脚本、URL重定向

场景5在分布式环境中,为其他安全域组件提供连接、保护或者认证服务的组件存在漏洞。如路由器、防火墙、或认证管理器中存在漏洞,影响到了下游组件的基本可用性。

缺陷系统是该组件(如路由器、防火墙、或认证管理器);后续系统是下游组件(若产生影响的话)

场景6PDF阅读器中存在漏洞,受害者打开恶意PDF文档时破坏同一操作系统上的其他文件

只有缺陷系统(OS),不存在后续系统影响。

场景7Web应用存在SQL注入,影响到后台数据库。

只有缺陷系统,不存在后续系统影响。数据库仅向web应用提供服务,共享统一凭据,可认为是一个整体。

场景8Web服务器或者SSH服务器崩溃。

只有缺陷系统(Web服务器或者SSH服务器);对用户的影响是次要的,不被视为对后续系统的影响,因为用户不被视为后续系统的组成要素。

场景9攻击者耗尽共享系统资源(如填充文件系统)

只有缺陷系统,不存在后续系统影响。

场景10攻击者利用应用中漏洞,突破权限限制,访问本无权限访问的资源(这些资源本来就共享给该应用,但用户被限制无法访问)

只有缺陷系统,不存在后续系统影响
场景11应用程序中具有自己的安全域,应用存在漏洞允许攻击者影响其安全范围以外的资源,应评估为具有后续系统影响。   如,一个Web应用程序,它允许用户仅在Web应用程序的安装路径下读取和修改网页和文件,并且不提供用户在这些路径之外进行交互的功能。此应用程序中允许恶意用户访问与此应用程序无关的操作系统文件。
缺陷系统是应用程序;后续系统是操作系统。(若应用本身提供了路径之外的交互功能,但受限被突破,则不视为对后续系统有影响)

2.2.3. 调整时间指标组(Temporal Metrics)为威胁指标组(Threat Metrics

  • 删除原有的修复级别 (RL) 和报告置信度 (RC)指标

  • 将利用代码成熟度(Exploit Code Maturity)重命名为利用成熟度 (EExploit Maturity ),并具有更明确指标值

利用成熟度指标包含3个指标值:

1. 未报告(UUnreported ):未感知到POC公开;且未感知到针对此漏洞的利用尝试;且未感知到简化利用该漏洞的尝试的公开可用解决方案。

2. POC概念验证(PProof-of-Concept):POC已公开;且未感知到针对此漏洞的利用尝试;且未感知到简化利用该漏洞的尝试的公开可用解决方案。

3. 攻击(AAttack):已报告针对此漏洞的攻击;简化利用该漏洞的尝试解决方案已公开(或私下可用)。

为保证利用成熟度指标准确取值,CVSS V4明确说明需要利用“威胁情报”来进行决策。并提供了操作建议:

  • 要使用多源威胁情报源(相互补充)

  • 应实时更新;

  • CVSS中该向量评估应自动化

2.2.4. 新增补充指标组(Supplemental Metrics

·安全性(SSafety

当系统确实具有与安全相关的预期用途或目的适用性时,利用该系统内的漏洞可能会产生安全影响,这可以在补充指标组中表示。安全补充指标的可能值如下:

Present  (P)

该漏洞的后果符合 IEC 61508 后果类别“边缘”、“严重”或“灾难性”的定义

Negligible  (N)

该漏洞的后果符合 IEC 61508 后果类别“可忽略”的定义。

·自动化(AUAutomatable
“自动化”指标表示了攻击者是否能够自动化的完成跨目标的漏洞利用。判别标准是能否自动完成Hutchins等人提出杀伤链的步骤1-4(侦察、武器化、投送和利用)(请参考附录2)。指标可以采用值 noyes

·供应商漏洞紧急度(UProvider Urgency

这个指标用于体现漏洞产品供应商对于该漏洞紧急程度的判别,同样利于企业进行漏洞的评级和管理。该指标值通常由由直接面向消费者的供应商(PPP)提供。

Library Maintainer → OS/Distro Maintainer → Provider 1 … Provider n (PPP) → Consumer
取值有red/Amber/Amber/Clear

Red

提供商已评估此漏洞的影响为最高紧急程度

Amber

提供商已评估此漏洞的影响为中等紧急程度

Green

提供商已评估此漏洞的影响,认为其紧迫性有所降低

Clear

提供商已评估此漏洞的影响,认为没有紧迫性

·恢复性(RRecovery

系统在被攻击后,在性能和可用性方面恢复服务的能力。也可以称为韧性

Automatic (A)

受到攻击后,系统自动恢复服务。

User (U)

受到攻击后,系统需要用户手动干预来恢复服务

Irrecoverable (I)

遭受攻击后,用户将无法恢复系统服务。

·价值密度(VValue Density

攻击者通过单个漏洞攻击事件可以获得控制的资源。它有两种可能的值,扩散和集中:

Diffuse (D)

包含漏洞的系统的资源有限。也就是说,攻击者通过单个利用事件获得控制的资源相对较小。此选项的一个例子是对单个电子邮件客户端漏洞的攻击。

Concentrated (C)

包含漏洞系统的资源丰富。此类系统通常由“系统操作员”而不是用户直接负责。此选项的一个例子是对中央电子邮件服务器的攻击。

·漏洞响应工作(REVulnerability Response Effort

漏洞响应工作量指标的目的是提供补充信息,说明消费者对其基础设施中已部署产品和服务的漏洞影响提供初步响应的难度。这个指标有助于企业判断某个漏洞的响应难度。

Low (L)

响应漏洞所需的工作量很小或微不足道。示例包括:更清晰的文档、配置解决方法的沟通,或者来自供应商的指导,不需要消费实体立即更新、升级或更换,例如防火墙过滤器配置。

Moderate  (M)

响应漏洞所需的操作需要付出一些努力,并且可能对实施造成的服务影响最小。示例包括:简单的远程更新、禁用子系统或低接触软件升级(例如驱动程序更新)。

High (H)

响应漏洞所需的操作非常困难,并且可能会导致扩展的、预定的服务影响。示例包括:高特权驱动程序更新、微代码或 UEFI BIOS 更新或软件升级,需要在实施之前仔细分析和了解任何潜在的基础设施影响。不可修复的故障,例如不可启动的闪存子系统、磁盘或固态驱动器 (SSD) 故障、内存模块损坏、网络设备或其他在保修期内不可恢复的硬件。

2.2.4. 增加OT/ICS/IoT行业适配

在补充指标组中增加安全(SSafety)指标,该指标除了作为额外指标使用外,在环境评分中也有使用。

如果利用漏洞(影响易受攻击系统的可用性或完整性)有可能影响人类安全,则应使用修改后的安全性后续系统影响(即 MSIS/MSAS)。

安全指标值衡量漏洞利用后对人类参与者的安全性,或可以预见受伤的参与者的影响。与其他影响指标值不同,安全性只能与后续系统影响集关联,除了可用性完整性指标的 N/L/H 影响值之外,还应考虑安全性。

注意:如果安全性有影响,则应明确分配安全性值。

参考IEC 61508,若导致边缘或更严重的伤害时,则应选择安全性取值

灾难(Catastrophic多人丧生
严重(Critical一人丧生
边缘(Marginal造成一人或多人严重受伤
可忽略(Negligible最严重的情况是轻伤

3.CVSS V4体现的趋势

3.1 CVSS V4有哪些观点

      · 强调CVSS不仅仅只是基础评分

为强调此观点,重新定义CVSS命名法:

CVSS-B

基本指标

CVSS-BE

基础和环境指标

CVSS-BT

基础和威胁指标

CVSS-BTE

基础、威胁、环境指标

     · 再次强调:CVSS 基本评分(CVSS-B) 只衡量严重性,而不是风险

  •     CVSS基础(CVSS-B) 分数旨在衡量漏洞的严重性,不应单独用于评估风险

  •     CVSS基本分数仅代表漏洞的内在特征,独立于与威胁或漏洞系统所在的计算环境相关的任何因素

  • CVSS基本分数应辅以环境分析(环境指标)以及可能随时间变化的属性(威胁指标)综合使用
  • CVSS-BTE 分数更能评估漏洞实际风险

      · 建议将漏洞扫描结果与资产管理集成

强烈建议使用资产数据丰富漏洞扫描解决方案的结果。通常,资产管理数据保存在数据库中,可以轻松地与漏洞扫描数据集成。此步骤不仅使漏洞管理团队能够利用环境度量组来提高 CVSS 评分结果的质量,而且负责修复已识别漏洞的工程师将拥有更多可用信息。

     · 建议将漏洞扫描结果与威胁情报集成

改善 CVSS 评估结果的最重要方面之一是威胁数据的应用和利用成熟度 (E) 指标的使用。

     · 再次强调:机密性和完整性指标是指影响服务所使用的数据的影响;可用性影响指标是指服务的运行情况

     · 再次强调:可以针对漏洞链(漏洞组合)进行综合评分

     · 建议补充指标使用规范

CVSS:4.0/AV:x/AC:x/AT:x/PR:x/UI:x/VC:x/VI:x/VA:x/SC:x/SI:x/SA:x

EXT:1.0/NEW1:VAL1/NEW2:VAL2

3.2 CVSS V4体现的趋势

  • 切近实战,评估粒度细化

AC拆分为ACAT,AC针对内在挑战克服,AT针对外在挑战克服;同时UI区分主动和被动。更加切近实际攻击,评估结果更加准确。
  • “威胁情报”成为重头戏

时间指标组调整为威胁指标组,且强调威胁情报重要性,并提供威胁情报使用建议。威胁情报对利用成熟度指标,以及附加指标组中的自动化指标的取值都具有决定作用。
  • 漏洞影响的评估更加科学

将影响因素(C/I/A)拆分为缺陷系统(Vulnerable System)和后续系统(Subsequent System)两部分的C/I/A。并提供多个场景解释二者边界。解决了CVSS V3.x Scope的部分分歧问题。
  • 增加新产业适配(不局限ICT领域)

在环境评分中新增了MSIMSASafety选项;同时可以配合附件指标组的Safety选项增加对OT/ICS/IoT行业适配。
  • 对供应商多个领域(如威胁情报、产品韧性)提出更高挑战

附加指标中的Provider UrgencyRecoveryValue DensityVulnerability Response Effort 指标对供应商的产品设计能力、产品韧性、漏洞评估能力、修补易部署提出更高要求。

威胁情报CVSS中的重要作用也对供应商的的威胁能力提出要求。

4.启示和建议

  •     供应商须加强威胁情报建设,以求准确、及时识别高风险漏洞并快速消减

  •      新型产业(如车领域)可快速制定基于补充指标的CVSS适配方案,并评估其有效性

  •      厂商可通过灵活运用补充指标,展示安全软实力

      CVSS V4中的威胁指标组和补充指标组是展示厂商软实力的有效平台:
  • 威胁指标组-利用成熟度:漏洞威胁情报收集、分析能力
  • 补充指标组-自动化(AUAutomatable漏洞威胁情报收集、分析能力;漏洞分析、复现能力
  • 补充指标组-供应商漏洞紧急度(UProvider Urgency漏洞评估技术权威性和专业性
  • 补充指标组-恢复性(RRecovery):产品韧性架构设计
  • 补充指标组-VValue Density产品韧性架构设计
  • 补充指标组-REVulnerability Response Effort 修补易部署。

5.附录

附录1CVSS 相关文档
CVSS V4.0 标准:https://www.first.org/cvss/v4.0/specification-document
CVSS V4.0 用户指南:https://www.first.org/cvss/v4.0/user-guide
CVSS V4.0 示例文档:https://www.first.org/cvss/v4.0/examples
CVSS V4.0 FAQhttps://www.first.org/cvss/v4.0/faq
CVSS V4.0 计算器:https://www.first.org/cvss/calculator/4.0

附录2:杀伤链

https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf

球分享

球点赞

球在看


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458528591&idx=2&sn=42f393155b7d9f5c94c65e6c3f93a219&chksm=b18d1bc586fa92d36ad75c4f5195e1618644fb112ffd235bfda27a83ea4995feaa0957cfc463&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh