在日常的漏洞研究和管理中，通常会发现，不同漏洞平台、不同团队对于漏洞的编号、严重程度的定义通常会出现差异化。

比如以下为漏洞常见的6个要素：

漏洞六要素

我们以心脏出血漏洞为例：

心脏出血

这些内容都是描述心脏出血的，可以看到不同的平台有不同的编号，类别也不同，影响组件的、等级、标题都是存在差异的，那么对于安全研究人员或者漏洞管理，就不可避免的需要去识别是不是同一个漏洞，然后需要自己去判定漏洞等级和类型等，不同的人或者团队，常常就会存在如以下的矛盾点：

矛盾点

这缘于不同的知识面、对漏洞的认知、标准，所以才导致的这些问题。那么有没有一个统一的标准来处理这个问题？有，SCAP！

SCAP

今天主要介绍SCAP1.0版本。

scap 1.0

SCAP包含了Protocol(协议)与Content(内容)，协议是指SCAP由一系列现有的公开标准构成，这些公开标准被称为SCAP Element(SCAP元素)，Protocol规范了这些Element之间如何协同工作。Content指按照Protocol的约定，利用Element描述 的生成应用于实际检查工作的数据。

SCAP六大元素：

scap 六要素

这其中可能大家对CVE、CVSS相对会比较熟悉，接下来就一一讲解下：

CVE

cve

CVE相对好理解，通俗的讲就对漏洞的统一收录和编号，当然，这里是针对通用组件漏洞的，这也就是大家经常会看到会有安全人员在自己的简历写自己活得了多少个CVE编号，那意味着对应编号的通用组件漏洞是当时由他发现的0DAY，是他拥有独立的0DAY发现能力的象征；当然，CVE并没有体现漏洞的影响和严重程度等情况，所以单从CVE编号看不出什么，一个很水的漏洞也是可以申请个CVE编号的。

CVSS

cvss

CVSS是个评分系统，基本的表达方式比如右侧图的那种5.0直接分数的形式，还有就是类似于

1
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/RL:O/CR:L

这种向量的表达方式，至于这里面的AV、AC等都代表什么意思，我们可以继续往下看就大概清楚了。

cvss组成

CVSS的评分是有三个指标组，一般我们看漏洞本身的严重程度主要就看基础指标，这个指标就更多的是从漏洞本身的一些点去计算的，而时间指标组有时也会进行考虑，比如说随着时间的变化，原来没有利用方式，后面出现了，漏洞的利用情况就完全不是一回事了，危害指数可能就应该是直线上升，比如永恒之蓝，一开始漏洞爆发，虽然伴随Exp，但只有少数人会用，但是随着网上各种利用文章、MSF的插件有了之后，瞬间满世界都是利用这个漏洞攻击的；再者环境指标，主要就是漏洞在不同环境上的影响可能会有所差别。

那刚才讲到，上面的AV那些是什么？其实就是这些指标项，具体可以见下图，在PPT里被翻译成了中文是为了方便大家理解，这里面的H、L可能就代表高、低，具体可见官网说明https://www.first.org/cvss/specification-document。

cvss指标项

回到分数计算，要怎么计算分数呢？其实是有公式的，我们以基础指标组为例。

cvss基础指项

cvss基础指标公式

针对漏洞的每个指标判定是属于什么情况，比如说攻击向量，有网络、相邻网络、本地、物理，指的是发起漏洞攻击的几种方式，对应用作计算的因素分数分别是0.85、0.62、0.55、0.2，一般来说，能够直接通过网络发起攻击的漏洞是最方便利用的，所以分值也最高；其他几个指标项也是一样的。

我们以漏洞《phpMyAdmin 反射型 XSS 漏洞 (CVE-2013-1937)》为例：

指标 值 说明
攻击向量 网络 N, 0.85 该漏洞产生于 Web 应用，明确需要与服务器进行网络交 互。
攻击复杂度 低 L, 0.77 虽然攻击者需要对目标系统侦查，但是一个有效 session token 可以很容易的获得，并且许多系统可能使用众所 周知的或者默认的数据库名称。
权限要求 无 N, 0.85 攻击不需要任何的权限要求。
用户交互 需要 R, 0.62 一个成功的攻击需要受害者访问存在漏洞的组件，比如 点击一个有害的链接。
范围 改变的 C 漏洞组件是 Web 服务器运行的 phpMyAdmin。受影响 的组件是受害者的浏览器。
保密性影响 低 L, 0.22 存在于受害者浏览器的信息可以被读取并且发送给攻击者。
完整性影响 低 L, 0.22 网站运行 phpMyadmin 的相关信息是被约束的， Coookie 数据是被排除在外的，因为 phpMyadmin 默 认情况下 HttpOnly 是启用的。
可用性影响 无 N, 0 恶意代码可以使受害者系统变慢，但效果比较差，受害 者可以很容易的关闭浏览器标签来终止。

然后套进公式计算：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ISCBase = 1 - [(1−ImpactConf) × (1−ImpactInteg) × (1−ImpactAvail)] = 1 - [(1−0.22) × (1−0.22) × (1−0)] = 0.3916

ISC =
Scope Unchanged 6.42 × ISCBase
Scope Changed 7.52 × [ISCBase−0.029] − 3.25 × [ISCBase−0.02]15
=7.52 × [0.3916−0.029] − 3.25 × [0.3916−0.02]15 = 2.72675084384

Exploitability
= 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
= 8.22 × 0.85 × 0.77 × 0.85 × 0.62 = 2.8352547300000004

If (ISC <= 0) 0 else,
Scope Unchanged Round up (Minimum [(Impact + Exploitability), 10])
Scope Changed Round up (Minimum [1.08 × (Impact + Exploitability), 10])
= Round up (Minimum [1.08 × (2.72675084384 + 2.8352547300000004), 10])
= Round up (Minimum [6.006966019747201, 10])
= 6.1

最终这个漏洞的基础分数就是6.1分。

大家会不会觉得这个计算很麻烦？其实不用这么复杂，官网提供了在线计算器，直接选择然后就能自动计算出来了：

cvss计算器

这就是CVSS了。

CPE

cpe

CPE是通用平台枚举，经常描述一个漏洞的时候需要描述漏洞影响了什么组件的什么版本，那么就可以使用CPE。

cpe命名

CPE有三种格式，分别是WFN、URI、FS，对应的一个格式是

1
CPE:2.3:类型:厂商:产品:版本:更新版本:发行版本:界面语言:软件发行版本:目标软件:目标硬件:其他

前面2.3指的是使用的CPE的版本，因为CPE也有多个版本，在2.2版本里是不存在sw_edition、target_sw、target_hw、other这几个字段的，具体的表示方式大家可以参考上图左侧的样例。
cpe匹配

当然，CPE的除了可以用来描述漏洞影响的组件及对应版本情况，还有一个重要的场景就是直接用来匹配是否存在漏洞；针对某个环境进行探测组件版本，使用CPE进行描述，然后与漏洞影响的CPE版本进行匹配，就能直接描述是否该环境受这个漏洞影响；这种场景，CPE是用对应的匹配方式，具体可以参考上图；如果需要在代码中实现，也很简单，一般都有现成的模块，比如Python有现成的第三方包也叫CPE，就包含有相关匹配、格式化的方法可以很方便的使用。

CCE

cce
再来说说CCE，其实CCE也好理解，可以理解为针对基线配置的CVE编号，CVE是针对通用组件漏洞，而CCE是针对基线配置。

比如说图中示例的：

CCE-27868-9

Definition: The maximum password age setting for Apache’s service account should be configured appropriately.
Parameter: number of days.
Technical Mechanisms: defined by Local or Group Policy

CCE-27868-9描述的是针对Apache服务的账号最大过期时间的要求，要求使用一个合适的值。

OVAL

oval

继续说说OVAL，他是一种用来定义检查项、脆弱点等技术细节的描述语言。这么说好像不好理解，通俗的你可以理解为他就是告诉你怎么在一个对应的环境下一步步检测某个漏洞是否存在，他也是有一个库的，可以通过上图oval:org.mitre.oval:def:24241这样的编号去检索，是XML格式；我们还是以心脏出血为例：

心脏出血oval

这是其中一部分，描述了在Ubuntu12.04的版本下，如果系统中存在libssl 1.0.0这样的dpkg包，版本小于0:1.0.1-4ubuntu5.12那么就意味着存在心脏出血漏洞。

OVAL以一种统一的标准来描述某个漏洞的检测细节，而OVAL也是可以通过社区贡献的，这样的话，安全人员、安全工具其实就可以基于OVAL实现对相关漏洞的检测。

XCCDF

xccdf

最后需要讲到的就是XCCDF了。

XCCDF看起来跟OVAL有点类似，但XCCDF被设计为支持信息交换、文档生成、组织化和情境化调整、自动一致性测试以及符合性评分，能够支持与多种基础配置检查技术交互。其中推荐的、默认的检查技术是MITRE公司的OVAL。在实际的SCAP应用中，XCCDF和OVAL往往是成对出现。可以理解OVAL可以作为一个XCCDF的子集。

在XCCDF文档中除了OVAL，你其实也能看到如CPE。它也是一种XML格式文件。

回过头去六个元素，借用网上的一张图来表示，其实他们之间的关系和作用大概是这样的：

六元素关系和作用

SCAP工具

讲完了这些，有没有相关工具可以帮助我们使用SCAP这一套东西呢？比如说基于XCCDF进行检测输出检查结果？比较出名的比如有OpenSCAP：

这大概就是关于SCAP的一些简单介绍，更多的内容大家可以参考官网文档以及一些应用案例。

其实SCAP的主要作用还是统一标准，这样的话，不用安全研究人员、安全工具就可以直接应用这些标准进行相关的漏洞研究、学习、使用、检测等，一般来说，而不会出现因为不同理解而出现的描述和定义不同等问题。一般做的比较好的安全产品，即使有自己的一套标准，一般也会兼容部分SCAP，而其中CVE应用最为广泛。当然，如果在使用SCAP的过程中，对于标准的理解不同，还是可能导致一些差异，比如咱们计算CVSS过程中，对于漏洞不同指标项的判定，虽然官方有解释和说明，但也有可能不同人对漏洞理解不同而设定的结果不同，最终计算的值也会存在差异，这又是不可避免的了，但SCAP是尽可能的提供统一的标准。

注：SCAP 1.2版本新增

CCSS 通用配置评分系统，类似CVSS，只是CVSS是针对漏洞，与CVE关联；而CCSS是针对配置，与CCE关联
OCIL 开放检查表交互式语言，类似XCDDF

扩展阅读

漏洞命名

关于漏洞命名问题，之前也设计过一套命名规范，不属于SCAP规范的内容，整体的目的是通过漏洞命名就能大概清楚是什么样的漏洞，大家也可以参考下：

语法

漏洞库中的漏洞命名主要包含有产生漏洞的组件名称(即漏洞影响的组件):漏洞影响的版本、漏洞产生位置、漏洞类型以及可选的向量组成，命名规则如下:

1
漏洞影响组件名称+漏洞影响版本+漏洞产生位置+(向量)+漏洞类型
  • 漏洞影响组件名称: 漏洞影响组件名称主要指的是产生漏洞的具体组 件的名称，组件包含比如各种 Web 应用、某个插件、某个系统、某 个通用模块等，均可称为是组件。
  • 漏洞影响版本: 漏洞影响版本指的是对应该组件受到该漏洞影响的版 本号，这里的版本号可以是单个版本(如 V1.0)或者是区间 (如>V1.0&<2.0)，也可以设定是最小值(如>V1.0)或者最大值 (如<V2.0).
  • 漏洞产生位置: 漏洞产生位置指的因为具体的问题导致漏洞产生，该 问题所处于的文件位置(如/admin/admin.php)或者具体通用函数 名或者类名(如_LoadBMP 函数)或者是两者的组合情况。
  • 向量: 向量指 vector，可选，指的是漏洞的输入点(比如说某个 SQL 注入漏洞的向量是参数 id)
  • 漏洞类型: 漏洞类型指的通用漏洞类型，即该漏洞对应的通用分类情况下的漏洞分类名称。
原则
  • 通过漏洞名称即可初步的了解漏洞的基本信息
  • 尽可能避免漏洞名称的重复
  • 避免冗长无意义的漏洞名称
示例
  • ThinkSAAS 2.0.1 thinksaas.php 本地文件包含漏洞
  • ImLib BMP Image _LoadBMP 函数拒绝服务漏洞
  • 用友优普 U8 系统 /Server/CmxGetLoginType.php 文件 appid 参 数 SQL 注入漏洞

漏洞评级

关于漏洞评级问题，很多人习惯性用高中低，或者1-10来描述漏洞等级，之前借鉴微软的DREAD风险模型也设计了一套，同样不属于SCAP内容，大家也可以参考下：
总的漏洞风险等级分为 1-10，10 个级别，其中 1-4 为低危，5-7 为中 危，8-10 为高危。

计算公式
1
危险=发生的概率×潜在损失
评分项定义
  • 潜在损失: 如果缺陷被利用，损失由多大?
  • 重现性: 重复产生攻击的难度有多大?
  • 可利用性: 发起攻击的难度有多大?
  • 受影响的用户: 用粗略的百分数表示，有多少用户收到影响?
  • 可发现性: 缺陷容易发现吗?
高中低定义

高中低定义

评分示例

高中低定义

参考链接