ASPIRE

通用漏洞评分系统(CVSS)

=Start=

缘由：

了解CVE漏洞的评分机制，好在以后出现了漏洞的时候利用CVSS标准对该漏洞的实际影响进行评估，从而指导进行下一步操作。

正文：

参考解答：
CVSS的度量指标

CVSS由三个度量组：「基础-Base」，「时间-Temporal」和「环境-Environmental」组成，每一组又由一些度量指标组成，如下所示：

下面分别来解析各个度量指标的含义和意义：

基础度量组反映了一个漏洞的固有特征——它不随着时间和用户环境的变化而变化。它由两组指标组成：可利用指标和影响指标。

可利用指标反映了漏洞可以被利用的简单程度和技术手段。也就是说，它们代表了漏洞易受利用的特征，我们把它称为脆弱的部分。另一方面，影响指标反映了成功利用该漏洞可以导致的直接结果，以及受该影响产生的后续结果，我们将其正式称为受影响的组件。

虽然脆弱的组件通常是一个软件应用程序、模块、驱动程序等等(甚至可能是一个硬件设备)，但受影响的组件可能是一个软件应用程序、一个硬件设备或一个网络资源。衡量一个脆弱组件之外的弱点的潜在影响，是CVSS v3.0的一个关键特性。

基础分数（必须）
可利用性指标(Exploitability Metrics)
攻击向量(AV) 网络(N) 相邻(A) 本地(L) 物理(P)
攻击的复杂性(AC) 低(L) 高(H)
所需的特权(PR) 没有(N) 低(L) 高(H)
用户交互(UI) 没有(N) 要求(R)
范围(Scope)
范围(S) 不变(U) 改变(C)
影响指标(Impact Metrics)
机密性(C) 没有(N) 低(L) 高(H)
完整性(I) 没有(N) 低(L) 高(H)
可用性(A) 没有(N) 低(L) 高(H)

时间度量组反映了一个可能随时间而变化的漏洞的特征，但是不跨用户环境。例如，一个易于使用的漏洞利用工具包的出现会增加CVSS分数，而一个官方补丁的创建将会减少它。

时间分数（可选）
利用代码的成熟度(E) 未定义(X) 未经验证(U) PoC(P) 函数(F) 高(H)
修复级别(RL) 未定义(X) 官方修复(O) 临时修复(T) 工作区(W) 不可用(U)
报告的可信度(RC) 未定义(X) 未知(U) 合理(R) 确认(C)

环境度量组代表了一个与某个特定用户环境相关且独特的漏洞的特征。这些度量标准允许分析人员合并安全控制，这些控制可以减轻任何后果，也可以根据她的业务风险促进或降低一个脆弱系统的重要性。

环境分数（可选）
机密性要求(CR) 未定义(X) 低(L) 中(M) 高(H)
完整性要求(IR) 未定义(X) 低(L) 中(M) 高(H)
可用性要求(AR) 未定义(X) 低(L) 中(M) 高(H)
修改基础度量指标

(Modified Base Metrics)

 Modified Attack Vector (MAV)
Modified Attack Complexity (MAC)
Modified Privileges Required (MPR)
Modified User Interaction (MUI)
Modified Scope (MS)
Modified Confidentiality (MC)
Modified Integrity (MI)
Modified Availability (MA)
CVSS的打分方程

 

CVSS的打分范围
RATING CVSS SCORE
None 0.0
Low 0.1 – 3.9
Medium 4.0 – 6.9
High 7.0 – 8.9
Critical 9.0 – 10.0
CVSS的各指标的权重
METRIC METRIC VALUE NUMERICAL VALUE
Attack Vector / Modified Attack Vector Network
Adjacent
Local
Physical		 0.85
0.62
0.55
0.2
Attack Complexity / Modified Attack Complexity Low
High		 0.77
0.44
Privilege Required / Modified Privilege Required None
Low
High		 0.85
0.62 (0.68 if Scope / Modified Scope is Changed)
0.27 (0.50 if Scope / Modified Scope is Changed)
User Interaction / Modified User Interaction None
Required		 0.85
0.62
C,I,A Impact / Modified C,I,A Impact High
Low
None		 0.56
0.22
0
Exploit Code Maturity Not Defined 1 High
Functional
Proof of Concept
Unproven		 1
0.97
0.94
0.91
Remediation Level Not Defined
Unavailable
Workaround
Temporary Fix
Official Fix		 1
1
0.97
0.96
0.95
Report Confidence Not Defined
Confirmed
Reasonable
Unknown		 1
1
0.96
0.92
Security Requirements – C,I,A Requirements (CR) Not Defined
High
Medium
Low		 1
1.5
1
0.5
参考链接：

=END=

Docker

, ,
, , ,

《 “通用漏洞评分系统(CVSS)” 》 有 14 条评论

  3. 如何正确对待CVSS
    https://mp.weixin.qq.com/s/ZtlMCz7tz28bATdi9QwxMw
    `
    通用漏洞评分系统（CVSS）诞生于2007年，是用于评估系统安全漏洞严重程度的一个行业公开标准。CVSS现在已经进入第二个版本，第三版正在开发中。它的主要目的是帮助人们建立衡量漏洞严重程度的标准，使得人们可以比较漏洞的严重程度，从而确定处理它们的优先级。CVSS得分基于一系列维度上的测量结果，这些测量维度被称为量度（Metrics）。漏洞的最终得分最大为10，最小为0。得分7~10的漏洞通常被认为比较严重，得分在4~6.9之间的是中级漏洞，0~3.9的则是低级漏洞。

    采取以下措施来让CVSS更有效：
    · 理解公司暴露在风险中的方式。只有这样才能理解CVSS，并将其和漏洞管理项目绑定在一起。
    · 确定公司的损失暴露情况。最终，修补漏洞缺陷这类努力的效果还是要反映到减少公司损失上。应当将注意力集中在漏洞对业务的影响上。举例而言，在面向Web的系统上找的敏感信息泄露漏洞的优先级应当大于那些并不面向外界的漏洞。
    · 需要保证公司的漏洞评分并不基于CVSS默认设置。应当改变CVSS的环境和时间变量，以获得完整的分数。
    · 如果公司同时遇到了两个漏洞：一个CVSS得分很高，但还没有被入侵；另一个CVSS得分很低，但已经被入侵。公司应当如何抉择呢？
    `

    回复

  7. 绿盟安全风险评估算法体系
    http://blog.nsfocus.net/nsfocus-security-risk-assessment-algorithms-system/
    `
    无危则安，无损则全。安全意识就在中国古代人文精神中得到了充分体现。在《申鉴》曾有记载：进忠有三术：一曰防，二曰救，三曰戒，先其未然谓之防，发而止之谓之救，行而则之谓之戒。

    防为上，救次之，戒为下。

    其认为谋事之道的最高境界是防患未然,在事情没有发生之前就预设警戒;其次是在祸患刚开始显露之际及时采取措施中止其发生,至于事后的惩处训诫是最末等措施。这应是现代安全风险管理预防为先的思想雏形。
    `

    回复

  8. CVE漏洞信息爬取
    https://github.com/hungryfoolou/Vulnerability_Mining/tree/master/craw
    `
    1、cveid_craw：先获取所有的CVEID，并按照漏洞类别分别保存（共计13类）。
    2、CVE_craw：再通过程序cveid_craw获取所有的CVEID之后，本程序获取所有的CVEID的主流的参考链接的报告内容，并按照漏洞类别分别保存（共计13类）。

    DoS
    Code Execution
    Overflow
    Memory Corruption
    Sql Injection
    XSS
    Directory Traversal
    Http Response Splitting
    Bypass something
    Gain Information
    Gain Privileges
    CSRF
    File Inclusion
    `

    回复

  9. 监控github上CVE增量，并发送微信通知
    https://github.com/grayddq/ScanCVE
    `
    1、定时通过github的api搜索关键字
    2、增量监控cve特征
    3、提取cve编号，进行mitre查询，并翻译为汉语说明
    4、动态配置需要推送的微信公众号CORPID、CORPSECRET等
    `

    回复

  10. 攻防未动，漏洞先行：标准化漏洞建模与生命周期管理
    https://mp.weixin.qq.com/s/1qzNsahFMEIxCP6dYb4H7Q
    `
    漏洞管理生态系统近年来开始逐渐成熟起来，安全从业者投入大量时间来发现、管理、分类和交流漏洞。漏洞描述的标准化不仅有助于威胁情报共享，而且还有助于有效管理潜在的威胁，帮助组织、供应商和安全研究人员积极寻求发现漏洞并及时作出响应。

    # 标准化的漏洞建模

    当下，漏洞分类标准和漏洞模型都有一定成熟度，有不少标准化模型，包括CWE、CVE、CVSS、CPE、CAN、CAPEC、CKC等。在漏洞管理中，它们各自扮演什么角色，都作用在哪个阶段，拥有什么特点，是安全人员需要提前了解。

    CWE（CommonWeaknessEnumeration）：是开发的常见软件和硬件安全弱点列表。基本上可以认为CWE是所有漏洞的原理基础性总结分析，CVE中相当数量的漏洞的成因在CWE中都可以找到相应的条目。如在代码层、应用层等多个方面的缺陷，从CWE角度看，正是由于CWE的一个或多个缺陷，从而形成了CVE的漏洞。

    CVE（Common Vulnerabilities & Exposures）：公开的漏洞都拥有唯一标识，漏洞编号就好比是出版物的ISBN号。目前最常见的漏洞编号，是引用MITRE组织推出的CVE编号系统，编号由（CVE Numbering Authorities）CNAs分配。漏洞信息通常包括简要描述、告警、缓解措施和报告。CVE就好像是一个字典表，为广泛认同的信息安全漏洞或者已经暴露出来的弱点给出一个公共的名称。但并不是有公开披露的漏洞都有一个相关的CVE- ID。保密的和未公开披露的漏洞通常被称为零日漏洞。

    CVSS（Common Vulnerability Scoring System）：CVSS建立于1990年，目前由FIRST负责运营。它通常是基于对每个漏洞特征进行定量计算一个大致的评分（0-10分），然后输出一个定性值（低、中或高）。当前的CVSS最新版本是2019年6月发布实施v3.1。

    CPE（Common Platform Enumeration）：通用平台枚举项，为IT产品和平台提供了统一的名称，原来属于MITRE运营，2014年交由NIST，作为NVD基础资源的一部分。它是对IT产品的统一命名规范，包括系统、平台和软件包等，CPE在信息安全风险评估中对应资产识别。

    CAPEC(Common Attack Pattern Enumeration and Classification）：是攻击模式枚举分类，是美国国土安全部建立于2007年，现在主要是由MITRE在运营，提供了公开的可用攻击模式，在信息安全风险评估中应对威胁。

    OVAL（Open Vulnerability and Assessment Language）,用于表达系统安全状态，是可以用于检测的技术细节指导，包括获取系统配置信息、分析状态、输出报告三个步骤。OVAL建立于2010年，2016年从MITRE转交给CIS组织。

    CKC（cyber-attacks and the Cyber Kill Chain）：CKC的全面理解是建立在对漏洞生命周期的认识，包括漏洞出现和利用。CKC还通过分配特定事件的攻击行为来提供威胁情报，并使用模型描述来理解这些行为。这种知识有助于目标系统的操作员确定一个成功的防御策略和解决某些网络攻击问题。

    # 全生命周期的漏洞管理

    当今的漏洞管理生命周期理论是由Arbaugh等人在2000年左右定义概念。通过漏洞生命周期映射，可定义过渡边界的事件。由于漏洞会触发相关的漏洞利用事件，风险程度也在提高，有了补丁可用之后，风险程度则会降低。

    漏洞产生阶段（Creation）：漏洞尚未被发现或者利用, 因此, 该阶段安全漏洞无风险。

    漏洞发现阶段（Discovery）：当漏洞刚被发现时, 对漏洞的挖掘和利用处于探索阶段, 并且掌握漏洞信息的人员数量少, 因此, 该阶段漏洞风险较低。

    漏洞公开阶段（Disclosure）：由于漏洞处于公开但未提供补丁的状态,越来越多的潜在攻击者开始关注此安全漏洞。攻击方式也会发生改变, 例如攻击由简单的代码供给转变为自动攻击工具, 使低技能攻击者开始尝试漏洞利用, 随时间推移，漏洞风险持续升高。

    漏洞评估阶段（Assess）：随着攻击脚本的传播, 更多的攻击者掌握了漏洞的利用方法, 从整体上看, 漏洞风险不断增长，达到高峰期。

    漏洞修复阶段（Patched）：随着补丁释放, 安装用户增多, 安全风险不断降低。由于不同漏洞的复杂度差别较大, 对于未能提供补丁的漏洞，相关组织机构也会采取一些手段切断黑客漏洞利用的攻击链路。
    `

    回复

  11. CVSS评分策略分析及近年来满分漏洞盘点
    https://mp.weixin.qq.com/s/OVFsUZkjaK8TgothZjBd5A
    `
    # 引言

    近两年正如许多安全公司的研究员亲身经历的那样，网络攻击量显著增加，重大漏洞被相继爆出并伴随着在野利用。如去年年底的log4shell（CVE-2021-44228）和今年爆出的spring4shell（CVE-2022-22965）在安全圈里都掀起了不小的风浪。由于在分析spring漏洞时cve编号还没有出来，自评影响力也没那么“核弹级”，后续就没怎么关注这个漏洞的。最近突然想看看这个漏洞的CVSS评分，看看官方是怎么给这漏洞做影响力定义的。查看后发现该漏洞CVSSV2.0评分为7.5，CVSS3.1的评分为9.8。那么CVSS的评分依据究竟是什么？2.x和3.x的评分标准区别在哪？是否分数越高就表示漏洞危害越大？近年来又有哪些CVSS评分为满分的漏洞？本篇文章想就这些问题跟大家简单聊一聊。

    # CVSS评分依据

    2.1 CVSS评分指标
    CVSS的评分指标由三部分组成：
    1、基础评价（Base Metric Group）：
    评估漏洞本身固有的一些特点及这些特点可能造成的影响。基础评价指的是一个漏洞的内在特征，该特征随时间和用户环境保持不变，基础评价是CVSS评分里最重要的一个指标，我们一般说的CVSS评分都是指漏洞的基础评价得分。

    2、生命周期评价(Temporal Metric Group)：
    此指标衡量当前利用技术或代码可用性的状态，是否存在任何补丁或解决方法或者漏洞报告的可信度等。生命周期评价几乎肯定会随着时间的推移而改变。

    3、环境评价（Environmental Metric Group）：
    这些指标使分析师能够根据受影响的IT资产对用户组织的重要性定制CVSS评分，并根据组织基础结构中组件的情况的分配分值。

    2.2 基础评价对比
    2.3 生命周期评价对比
    2.4 环境评价对比
    2.5 漏洞等级

    # 评分案例分析

    那么是否CVSS评分越高的漏洞就真的越严重呢？我们可以先来看看CVSS对历史经典漏洞永恒之蓝（CVE-2017-0143）的评分结果：
    永恒之蓝漏洞的严重性和影响力自然不必多说，但CVSS3.X的最终评分仅为8.1分，甚至都没有进入严重级别（Critical）这一档。由于永恒之蓝爆发时还没有3.1的标准，我们可以先通过3.0的标准（与3.1基本一致）来分析下该漏洞为什么在CVSS的评分不高。
    CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
    失分项主要有两个地方，一是攻击复杂度评价给的高，通俗点讲就是该漏洞的利用难度较高。因为永恒之蓝是一个远程溢出漏洞，poc和exp调试比较困难。
    另外该漏洞的作用域评价为固定，因为该漏洞只影响SMB协议，不涉及其他组件、服务或协议。从2.2小节里可以看出，作用域一是会影响“权限要求”项的评分，二是会影响基础评价里“影响度”的评分公式。由于永恒之蓝漏洞由于权限要求评价项为“无”，因此这里只会对“影响度”的评分造成影响，以上两个原因造成了永恒之蓝漏洞的CVSS评分并没有大家想的那么高。

    另外一些看上去不怎么起眼的漏洞CVSS却会给出较高的评分，例如Samba远程代码执行漏洞（CVE-2021-44142），这个漏洞在Samba默认配置下并不会触发，同时利用稳定性也不高，暴露面中规中矩，但CVSS却给了8.8分，比永恒之蓝评分还要高，评分详情为：
    CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
    可以看出仅因该漏洞的利用复杂度比永恒之蓝低，总体评分就比永恒之蓝高了，这从漏洞影响面来看显然是不太科学的。

    此外篇头提到的两个漏洞log4shell（CVE-2021-44228）和spring4shell（CVE-2022-22965）的评分分别为10分和9.8分，事实上这两个漏洞在评分上所有选项都是最高分，唯一区别是一个作用域可变，一个作用域固定，最终影响了计算公式：
    Log4j2：
    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
    Spring：
    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

    这里CVSS对作用域的定义还是比较客观的，因为log4j2是一个组件，只要调用了log4j2相应版本这个系统就会受到威胁，因此作用域为可变；而Spring4Shell只是一个框架，作用域为固定。事实上如果一个漏洞作用域为固定，换言之该漏洞只影响某个独立的组件，那么该漏洞注定得不到10分，最高分也只有9.8分，这也是为什么我们能看到那么多9.8分的经典漏洞的原因。

    # CVSS满分漏洞盘点
    以CVSS3.1为参考标准，从2021年以来至今，9-10分的漏洞共有1586个，其中满分的漏洞共有69个。

    事实上并不是所有的漏洞都能配得上满分。这些漏洞被评为满分的原因主要还是因为漏洞复杂度低、利用条件低且能影响多个组件，对漏洞实际影响范围、危害程度和利用稳定性等因素在基础评分里并未体现。
    `

    回复

  12. 通用漏洞评分系统CVSS v4.0标准浅析
    https://mp.weixin.qq.com/s/D_aAnQkvZe1ky5jzQ5pVVg
    `
    CVSS（Common Vulnerability Scoring System）是一种用于衡量软件漏洞严重性的标准化方法，它通过多个维度（如攻击复杂度、影响范围等）对漏洞进行评分，从而为企业和组织提供了一个量化的风险评估工具。当前主要使用的CVSS为3.1版本，CVSS 3.1是CVSS的第三个版本，于2019年发布。它引入了一些新的评分因素，如机密性影响、完整性影响等，以更准确地评估漏洞对系统的威胁程度。然而，随着时间的推移，CVSS 3.1在某些方面暴露出了一些不足之处，例如评分系统的复杂性和部分评分因素的不明确性。为了解决这些问题，NIST在2023年7月发布了CVSS 4.0。CVSS 4.0在很多方面都进行了改进和优化，例如简化了评分体系、提高了评分准确性等。

    本文将重点介绍CVSS 4.0与CVSS 3.1之间的主要区别，以及这些区别对企业和组织在网络安全管理方面的实际意义。

    由于网络安全形势的快速变化，CVSS标准从2004年问世到现在经过多次修订，已经更新了多个版本：
    2005 CVSS v1
    2007 CVSS v2
    2015 CVSS v3.0
    2019 CVSS v3.1

    当前较为广泛应用的是CVSS V3.1版本，各大厂商的漏洞公告和NVD漏洞数据库都采用该版本。

    5. CVSS v4.0标准

    5.1 新标准的变化

    针对上述问题，CVSS 4.0标准主要进行了如下优化：

    * 新标准强调了CVSS不仅仅只是基础评分
    为了强调CVSS评分系统不仅仅只是基本评分，新标准提出了基础 (CVSS-B)、基础 + 威胁 (CVSS-BT)、基础 + 环境 (CVSS-BE) 和基础 + 威胁 + 环境 (CVSS-BTE) 的组合来评价一个漏洞。

    * 添加了新的基本评分指标（Base Score Metric）
    在基本评分中增加了Attack Requirements指标，同时细化了User Interaction指标

    * 细化了基本评分中的影响指标（Impact Metric）
    对于基本评分中的Impact metric，删除了具有歧义的“Scope”指标，并对机密性、完整性和可用性的影响拓展为两组（Vulnerable System 和Subsequent System的影响），分别代表漏洞对目标系统的影响和利用后对后续系统的影响。以对Subsequent System的影响替代原有的“Scope”属性。

    * 将时间指标组（Temporal metric group）重命名为威胁指标组（Threat metric group）
    __* 进一步简化和明确的威胁指标
    __* 停用原有的修复级别 (RL) 和报告置信度 (RC)
    __* 将利用“代码”成熟度（Exploit “Code” Maturity）重命名为利用成熟度 (Exploit Maturity (E) )，并具有更明确指标值

    * 增加了新的补充指标组，以表现漏洞的其他属性，但是这些新增加的属性不会影响最终的CVSS-BTE分数，具体包括如下指标
    __* Safety (S) 安全
    __* Automatable (A) 自动化
    __* Recovery (R) 恢复
    __* Value Density (V) 价值密度
    __* Vulnerability Response Effort (RE)漏洞响应工作
    __* Provider Urgency (U) 提供商紧急度

    * 增加了对OT、ICS、安全性的考量
    __* 例如添加了影响用户评估安全性指标（Subsequent System Impact Metrics中的MSI:S和MSA:S）
    __* 供应商通过Supplemental Metrics的Safety指标来评估漏洞的安全性影响

    5.2 CVSS v4.0标准说明
    CVSS v4.0评分标准主要包括四个指标组组成：基础、威胁、环境和补充指标组，每个指标组由一组指标构成。

    5.2.1基本指标组（Base Metric Group）
    5.2.2 威胁指标组(Threat Metric Group)
    5.2.3环境指标组（Environment Metric Group）

    5.2.4补充指标组（Supplemental Metrics）
    这是CVSS v4.0增加的一个全新的可选指标组，提供了描述和定量表示漏洞的其他外部属性的新指标。补充指标组中每个指标的使用由 CVSS 使用者确定。并且在不同的用户环境可能使用方式不一样，在该指标组内的任何指标都不会对最终计算的 CVSS 分数（例如 CVSS-BTE）产生影响。然后，组织可以分配每个指标或指标集合的重要性影响，从而对最终的风险分析的结果产生影响。

    具体来说，该指标组包含如下指标：

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

    * Automatable (A) 自动化
    “自动化”指标表示了攻击者是否能够自动化的完成跨目标的漏洞利用。判别标准是能否自动完成Hutchins 等提出杀伤链的步骤1-4（侦察、武器化、投送和利用）。指标可以采用值 no 或 yes。

    * Recovery (R) 恢复
    恢复指标描述了系统在遭受攻击后恢复服务的能力，包括性能和可用性。

    * Value Density (V) 价值密度
    价值密度描述了攻击者通过单个漏洞利用可以获得控制的资源。它有两个可能的值：Diffuse (D)和Concentrated (C)

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

    * Provider Urgency (U) 供应商漏洞紧急度
    这个指标用于体现漏洞产品供应商对于该漏洞紧急程度的判别，同样利于企业进行漏洞的评级和管理。

    6. 结语
    CVSS4.0相对于CVSS3.1在安全漏洞管理方面进行了多项改进，包括引入新的评分机制、考虑依赖项、提供详细的漏洞描述和修复建议以及引入可利用性评分等。这些改进使得安全团队能够更准确地评估和处理漏洞，提高整体系统的安全性和可靠性。
    `

    回复

  14. 关于CVSS V4.0，你想知道的都在这了！
    https://mp.weixin.qq.com/s/Ypep8KPE8fWp_cOrpcA8xA
    `
    1 关于CVSS和CVSS V4

    由上图可以看出，CVSS V3已经存在8年之久（也是应用最广泛的一个版本），随着行业发展，其在漏洞评估方面也展现出了一些争议，虽然经历过微小版本更新（CVSS V3.1），但仍存在一些批评。在经历多次延期之后，FIRST CVSS SIG终于于2023年11月1日正式发布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个：

    2.2 变更详解

    1. 细化基础指标粒度
    * 将攻击复杂度（AC）指标拆分为AC（攻击复杂度）和攻击要求（AT）两个指标
    * 细化用户交互（UI）指标粒度

    2. 删除范围（Scope）指标
    * 删除范围变更（Scope）指标
    * 将影响因素（C/I/A）拆分为缺陷系统（Vulnerable System）和后续系统（Subsequent System）两部分的C/I/A

    3. 调整时间指标组（Temporal Metrics）为威胁指标组（Threat Metrics）
    * 删除时间指标组中的修复水平（RL：Remediation Level）和报告置信度（RC：Report Confidence）2个指标
    * 简化利用代码成熟度（E：Exploit Code Maturity）为利用成熟度（E：Exploit Maturity）

    4. 新增补充指标组（Supplemental Metrics），含有6个指标。
    * 安全性（S：Safety）
    * 自动化（AU：Automatable）
    * 供应商漏洞紧急度（U：Provider Urgency）
    * 恢复性（R：Recovery）
    * 价值密度（V：Value Density）
    * 漏洞响应工作（RE：Vulnerability Response Effort ）

    5. 增加OT/ICS/IoT行业适配
    * 在补充指标组中增加安全性（S：Safety）指标
    * 在环境指标组（Environmental Metrics）后续系统评分中，针对完整性和可用性增加安全性（S：Safety）选项，即MSI：S和MSA：S。

    3 CVSS V4体现的趋势

    3.1 CVSS V4有哪些观点

    3.2 CVSS V4体现的趋势

    * 切近实战，评估粒度细化
    AC拆分为AC和AT,AC针对内在挑战克服，AT针对外在挑战克服；同时UI区分主动和被动。更加切近实际攻击，评估结果更加准确。

    * “威胁情报”成为重头戏
    时间指标组调整为“威胁指标组”，且强调“威胁情报”重要性，并提供威胁情报使用建议。“威胁情报”对利用成熟度指标，以及附加指标组中的“自动化”指标的取值都具有决定作用。

    * 漏洞影响的评估更加科学
    将影响因素（C/I/A）拆分为缺陷系统（Vulnerable System）和后续系统（Subsequent System）两部分的C/I/A。并提供多个场景解释二者边界。解决了CVSS V3.x Scope的部分分歧问题。

    * 增加新产业适配（不局限ICT领域）
    在环境评分中新增了MSI和MSA的Safety选项；同时可以配合附件指标组的Safety选项增加对OT/ICS/IoT行业适配。

    * 对供应商多个领域（如威胁情报、产品韧性）提出更高挑战
    附加指标中的Provider Urgency、Recovery、Value Density、Vulnerability Response Effort 指标对供应商的产品设计能力、产品韧性、漏洞评估能力、修补易部署提出更高要求。
    “威胁情报”在CVSS中的重要作用也对供应商的的威胁能力提出要求。

    4 启示和建议

    * 供应商须加强威胁情报建设，以求准确、及时识别高风险漏洞并快速消减
    * 新型产业（如车领域）可快速制定基于补充指标的CVSS适配方案，并评估其有效性
    * 厂商可通过灵活运用补充指标，展示安全软实力

    CVSS V4中的威胁指标组和补充指标组是展示厂商软实力的有效平台：
    * 威胁指标组-利用成熟度：漏洞威胁情报收集、分析能力
    * 补充指标组-自动化（AU：Automatable）：漏洞威胁情报收集、分析能力；漏洞分析、复现能力
    * 补充指标组-供应商漏洞紧急度（U：Provider Urgency）：漏洞评估技术权威性和专业性
    * 补充指标组-恢复性（R：Recovery）：产品韧性架构设计
    * 补充指标组-（V：Value Density）：产品韧性架构设计
    * 补充指标组-（RE：Vulnerability Response Effort）：修补易部署。

    5 附录
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注