目录
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 启示和建议
5 附录
1.关于CVSS和CVSS V4
CVSS(Common Vulnerability Scoring System)中文译为:通用漏洞评分系统,是一个免费、开放的行业事实标准。CVSS提供了一种捕获漏洞主要特征并生成反映其严重性的数字评分的方法,同时将数字评分转换为定性表示(例如低、中、高和严重),以帮助组织正确评估漏洞管理流程并确定响应优先级。
CVSS(Common Vulnerability Scoring System)由美国国家基础设施咨询委员会(National Infrastructure Advisory Council,NIAC)发起,NIAC后来将CVSS评分标准托管给FIRST(Forum of Incident Response and Security Teams)维护(FIRST CVSS SIG)。目前已经发布了5个版本。下图回顾了CVSS标准的发展史。
2.CVSS V4相比V3.1变化点
删除范围变更(Scope)指标
将影响因素(C/I/A)拆分为缺陷系统(Vulnerable System)和后续系统(Subsequent System)两部分的C/I/A
删除时间指标组中的修复水平(RL:Remediation Level)和报告置信度(RC:Report Confidence)2个指标
简化利用代码成熟度(E:Exploit Code Maturity)为利用成熟度(E:Exploit Maturity)
安全性(S:Safety)
自动化(AU:Automatable)
供应商漏洞紧急度(U:Provider Urgency)
恢复性(R:Recovery)
价值密度(V:Value Density)
漏洞响应工作(RE:Vulnerability Response Effort )
在补充指标组中增加安全性(S:Safety)指标
该指标捕获了启用攻击的易受攻击系统的先决部署和执行条件或变量。这些与安全增强技术/技术(参考攻击复杂性)不同,因为这些条件的主要目的不是明确减轻攻击,而是作为易受攻击的系统的部署和执行的结果自然出现。如果攻击者不采取行动克服这些条件,攻击可能只是偶尔成功或根本不成功。
AT(Attack Requirements):外部挑战(EXTERNAL CHALLENGES):必须克服易受攻击系统的部署和执行条件或变量。示例包括:竞争条件或中间人攻击。注意:执行特定于站点的评估时,可以通过修改的攻击要求 (MAT) 环境指标来表示作为补偿控制的外部防火墙过滤器的存在。
用户交互(UI:User Interaction)指标取值由(None, Required)→ (None,Passive,Active),将“需要用户交互”细化为“被动交互”和“主动交互”
·针对反射性XSS,UI为A:反射式XSS要求用户单击特定链接才能触发漏洞利用。用户可以选择或有机会在与链接交互之前查看该链接合法性。其可以有意识地决定是否与攻击者的有效负载进行交互,因此这将被视为主动(Active)。
·针对存储型XSS,UI为P:存储型XSS不需要特制的链接来触发漏洞。用户在正常浏览网站时可能会无意中触发漏洞利用,并且在漏洞利用之前没有意识或没有能力避免与攻击者有效负载的交互。因为没有有意识地决定与有效负载交互,所以这将被视为被动(Passive)。
·针对用户单击链接的行为,UI为A:与反射型XSS类似,在单击链接之前,用户可以选择或有机会查看该链接。由于用户正在有意识地决定通过链接与攻击者的有效负载进行交互,因此这将被视为主动(Active)。
范围(Scope)可能是CVSS V3中最不受欢迎的指标,其在多个场景中均存在较大歧义,这导致不同组织之间、不同漏洞评估人员之间存在的较大的认知差异。因此在CVSS V4.0,Scope指标“光荣退休”了。
取而代之的,是将影响指标(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)。漏洞存在于此类系统的一个或多个组件中。从消费者角度来看,为达成某一目的或功能服务的技术产品或解决方案可被视为系统(例如服务器、工作站、容器化服务等)。
需要注意的是:当一个系统仅向另一个系统提供功能时,或者它被设计为专门由另一个系统使用时,那么它们可被一起视为评分感兴趣的系统。例如,仅由智能扬声器使用的数据库被视为该智能扬声器系统的一部分。如果数据库中的漏洞导致智能扬声器发生故障,则数据库及其服务的智能扬声器都将被视为易受攻击的系统。
确定“缺陷系统”
确定“后续系统”
场景1:攻击者能利用虚拟机中的漏洞读取和/或删除主机操作系统文件
场景2:用户态低权限运行程序,突破边界进入高权限执行任意代码。
场景3:微处理器中的安全飞地(SE:Secure
Enclave )与其他操作系统进程(包括操作系统内核本身)之间的安全边界突破要考虑在后续系统影响中。比如安全边界外的一个漏洞影响到了安全飞地中的数据或者代码的CIA。
场景4:Web应用程序中的漏洞影响用户客户端(例如Web浏览器)
场景5:在分布式环境中,为其他安全域组件提供连接、保护或者认证服务的组件存在漏洞。如路由器、防火墙、或认证管理器中存在漏洞,影响到了下游组件的基本可用性。
场景6:PDF阅读器中存在漏洞,受害者打开恶意PDF文档时破坏同一操作系统上的其他文件
场景7:Web应用存在SQL注入,影响到后台数据库。
场景8:Web服务器或者SSH服务器崩溃。
场景9:攻击者耗尽共享系统资源(如填充文件系统)
场景10:攻击者利用应用中漏洞,突破权限限制,访问本无权限访问的资源(这些资源本来就共享给该应用,但用户被限制无法访问)。
删除原有的修复级别 (RL) 和报告置信度 (RC)指标
利用成熟度指标包含3个指标值:
1. 未报告(U:Unreported ):未感知到POC公开;且未感知到针对此漏洞的利用尝试;且未感知到简化利用该漏洞的尝试的公开可用解决方案。
2. POC概念验证(P:Proof-of-Concept):POC已公开;且未感知到针对此漏洞的利用尝试;且未感知到简化利用该漏洞的尝试的公开可用解决方案。
3. 攻击(A:Attack):已报告针对此漏洞的攻击;简化利用该漏洞的尝试解决方案已公开(或私下可用)。
为保证利用成熟度指标准确取值,CVSS V4明确说明需要利用“威胁情报”来进行决策。并提供了操作建议:
要使用多源威胁情报源(相互补充)
应实时更新;
·安全性(S:Safety)
当系统确实具有与安全相关的预期用途或目的适用性时,利用该系统内的漏洞可能会产生安全影响,这可以在补充指标组中表示。安全补充指标的可能值如下:
Present
(P) | 该漏洞的后果符合 IEC 61508 后果类别“边缘”、“严重”或“灾难性”的定义 |
Negligible
(N) | 该漏洞的后果符合 IEC 61508 后果类别“可忽略”的定义。 |
·供应商漏洞紧急度(U:Provider Urgency)
这个指标用于体现漏洞产品供应商对于该漏洞紧急程度的判别,同样利于企业进行漏洞的评级和管理。该指标值通常由由直接面向消费者的供应商(PPP)提供。
Red | 提供商已评估此漏洞的影响为最高紧急程度 |
Amber | 提供商已评估此漏洞的影响为中等紧急程度 |
Green | 提供商已评估此漏洞的影响,认为其紧迫性有所降低 |
Clear | 提供商已评估此漏洞的影响,认为没有紧迫性 |
·恢复性(R:Recovery)
系统在被攻击后,在性能和可用性方面恢复服务的能力。也可以称为“韧性”。
Automatic (A) | 受到攻击后,系统自动恢复服务。 |
User (U) | 受到攻击后,系统需要用户手动干预来恢复服务 |
Irrecoverable (I) | 遭受攻击后,用户将无法恢复系统服务。 |
·价值密度(V:Value Density)
攻击者通过单个漏洞攻击事件可以获得控制的资源。它有两种可能的值,扩散和集中:
Diffuse (D) | 包含漏洞的系统的资源有限。也就是说,攻击者通过单个利用事件获得控制的资源相对较小。此选项的一个例子是对单个电子邮件客户端漏洞的攻击。 |
Concentrated (C) | 包含漏洞系统的资源丰富。此类系统通常由“系统操作员”而不是用户直接负责。此选项的一个例子是对中央电子邮件服务器的攻击。 |
·漏洞响应工作(RE:Vulnerability
Response Effort )
漏洞响应工作量指标的目的是提供补充信息,说明消费者对其基础设施中已部署产品和服务的漏洞影响提供初步响应的难度。这个指标有助于企业判断某个漏洞的响应难度。
Low (L) | 响应漏洞所需的工作量很小或微不足道。示例包括:更清晰的文档、配置解决方法的沟通,或者来自供应商的指导,不需要消费实体立即更新、升级或更换,例如防火墙过滤器配置。 |
Moderate
(M) | 响应漏洞所需的操作需要付出一些努力,并且可能对实施造成的服务影响最小。示例包括:简单的远程更新、禁用子系统或低接触软件升级(例如驱动程序更新)。 |
High (H) | 响应漏洞所需的操作非常困难,并且可能会导致扩展的、预定的服务影响。示例包括:高特权驱动程序更新、微代码或 UEFI BIOS 更新或软件升级,需要在实施之前仔细分析和了解任何潜在的基础设施影响。不可修复的故障,例如不可启动的闪存子系统、磁盘或固态驱动器 (SSD) 故障、内存模块损坏、网络设备或其他在保修期内不可恢复的硬件。 |
在补充指标组中增加安全(S:Safety)指标,该指标除了作为额外指标使用外,在环境评分中也有使用。
如果利用漏洞(影响易受攻击系统的可用性或完整性)有可能影响人类安全,则应使用修改后的安全性后续系统影响(即 MSI:S/MSA:S)。
安全指标值衡量漏洞利用后对人类参与者的安全性,或可以预见受伤的参与者的影响。与其他影响指标值不同,安全性只能与后续系统影响集关联,除了可用性和完整性指标的 N/L/H 影响值之外,还应考虑安全性。
注意:如果安全性有影响,则应明确分配安全性值。
参考IEC 61508,若导致“边缘”或更严重的伤害时,则应选择“安全性”取值
灾难(Catastrophic) | 多人丧生 |
严重(Critical) | 一人丧生 |
边缘(Marginal) | 造成一人或多人严重受伤 |
可忽略(Negligible) | 最严重的情况是轻伤 |
3.CVSS V4体现的趋势
为强调此观点,重新定义CVSS命名法:
CVSS-B | 基本指标 |
CVSS-BE | 基础和环境指标 |
CVSS-BT | 基础和威胁指标 |
CVSS-BTE | 基础、威胁、环境指标 |
强烈建议使用资产数据丰富漏洞扫描解决方案的结果。通常,资产管理数据保存在数据库中,可以轻松地与漏洞扫描数据集成。此步骤不仅使漏洞管理团队能够利用环境度量组来提高 CVSS 评分结果的质量,而且负责修复已识别漏洞的工程师将拥有更多可用信息。
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
“威胁情报”成为重头戏
漏洞影响的评估更加科学
增加新产业适配(不局限ICT领域)
对供应商多个领域(如威胁情报、产品韧性)提出更高挑战
“威胁情报”在CVSS中的重要作用也对供应商的的威胁能力提出要求。
4.启示和建议
5.附录
附录2:杀伤链
球分享
球点赞
球在看