基于社区发现算法对CWE的划分实践

1.前言

如何对漏洞的脆弱性进行分类，在漏洞情报分析过程中一直都是个头疼的问题。分类太细，可读性差；分类太泛，则分析结果准确率和召回率都会随之下降。

就目前来看，对于漏洞分类的解决方案，绝大多数是以CWE标准为基础，在此之上通过人工筛选的方式，选择一些典型CWE作为自己标准的分类类别，如CNNVD是选取了26个CWE作为漏洞脆弱性分类类别，并以“树”的形式将其分为五个层次。

图 1 CNNVD漏洞分类层次树

然而这样的分类方式，虽然大幅提高了人类的可读性，却牺牲了漏洞脆弱性分类给漏洞情报分析带来的分析收益，换句话就是，牺牲了机器的可读性。比如在做某一组件的历史漏洞原因分析时，使用CWE的分类方式进行分析，可以清晰准确的看到组件的脆弱性分布图，并能够以“未知漏洞预测”、“漏洞成因趋势发展”等项目研究。当然，使用CWE进行这类研究时，也会有需要大量数据支撑（历史漏洞脆弱性分布越广，漏洞数据量需求就越大），分析结果召回率低等问题。但使用简化版的漏洞脆弱性分类标准，则无法构建清晰的脆弱性分布图，主要原因是因为脆弱性划分太粗导致的数据密度过大，无法进行有效识别和判断。

综上，我们尝试使用知识图谱构建CWE实体及内部关系，并基于该图谱对CWE的划分进行实践与应用。以求能够找到一种“划分”而不是“简化”CWE标准的方法。

2.CWE图谱构建

CWE™（Common Weakness Enumeration）是一种软件和硬件漏洞脆弱性描述标准，由MITRE负责运营。CWE对于脆弱性的观察角度分为三个：“Software Development” - 软件开发、“Hardware Design”- 硬件设计、“Research Concepts”- 研究概念。在漏洞研究领域，我们通常更关注的是从第三个观察角度“Research Concepts”所构建的CWE描述体系。因此本文便不再赘述前两个角度的相关信息。

“Research Concepts”视角下，CWE描述体系的构建不再关心脆弱点如何被检测到、它们出现在代码中的什么位置、或者它们何时在开发生命周期中被引入，而是重点研究抽象的脆弱性概念的区别以及之间的相互关联关系，并且该视角下会包含所有的CWE。

CWE的描述文件采用的是XML格式，在“Related_Weaknesses”字段中描述了该CWE与其他CWE之间的关系。

     <Weakness ID="1007" Name="Insufficient Visual Distinction of Homoglyphs Presented to User" Abstraction="Base" Structure="Simple" Status="Incomplete">               ... ...               <Related_Weaknesses>                  <Related_Weakness Nature="ChildOf" CWE_ID="451" View_ID="1000" Ordinal="Primary"/>             </Related_Weaknesses>

基于官方的数据文件，可以直接进行实体和关系的抽取。只不过在构建实体属性的时候，我们只采用了CWE_ID 和它的标题，其余部分在尚未进行深入分析和可信度调研之前，并没有被放入知识图谱。

构建好的部分图谱如下：

图 2 部分CWE实体关系图

3.CWE划分实践

细心的读者可能已经发现，在CWE官方描述文件中构建的关系里已经存在有“ChildOf”来对细分类的CWE进行合并，如图三所示“CWE-20”（输入验证不当）下涵盖了“CWE-179”、“CWE-1284”等细分类。那我们为什么还要对CWE进行划分呢？

图 3 CWE-20以及子类的ChildOf关系示例

事实上，CWE标准中的上下级关系（ChildOf）中，上级与下级之间的关联是可以视为强关联关系的，但同属一个上级的下属之间绝大多数是没有关联关系的，而如表一所示，CWE标准中关联关系占比最大的恰恰是上下级关系。但在漏洞脆弱性概念研究中，如果想对CWE进行划分，则必须就要保证划分到同一类的CWE在某一场景中如攻击、溯源、告警分类等，不同的CWE之间具有漏洞脆弱类型相似性和连通性，只有这样才能保证在后续的研究过程中，具有应用意义。

name	num
ChildOf	1121
Requires	12
PeerOf	96
CanPrecede	134
CanAlsoBe	27
StartsWith	3

表 1 CWE标准定义的各种关系数量统计

例如攻击场景中，研究同一类漏洞的利用代码相似性时，无论是从代码逻辑结构还是从NLP领域研究同一类漏洞的利用代码的相似性时，首先就是要判定这一类漏洞的划分界限，通常来讲是基于CWE标准去划分，界限设置的过小，比如一个CWE作为一类漏洞的话，则样本数量过少，不足以支撑研究需要。而界限设置过大（将同属一个上级节点下的所有CWE分类都划分为同一类漏洞甚至上上级下的所有CWE划为同一类漏洞），则会引入大量在利用方式上不同的漏洞，对研究产生干扰。比如XSS和代码注入漏洞，二者同属 CWE-74（“注入”）概念下，但其利用方式、漏洞攻击收益、修复方式、作用场景都存在差异，若将所属二者的漏洞利用代码放在一起进行相似度分析时，则结果往往不会很理想。由此可见，在漏洞研究、网络安全情报分析等领域，更关心的是漏洞在“利用方式”、“攻击收益”等与实战贴近的属性的相似度。

3.1 基于特征的聚类算法划分实践

在互联网范围内存在大量社区、论坛发布的漏洞分析文章，其中就包含有利用方式、攻击收益等信息。我们筛选了7000+相关文章，并对每一篇文章中提到的漏洞脆弱类型进行统计，然后以CAPEC标准中表述的攻击收益为基础样本，对文章中包含的攻击收益数据进行实体识别。集合CWE与CAPEC的原有关联关系，与文章中识别出的CWE对应的攻击收益，就可以计算出某个CWE与某个攻击收益的置信度，鉴于一个CWE会对应多个攻击收益，此时便可以以CWE为中心，构建一个基础距离为1，置信度为x的有向图，f（x*1）则作为某个攻击收益与CWE的实际距离。

图 4 CWE-N 与对应攻击收益的实际距离示例

通过对所有CWE的攻击收益有向图使提取特征（密度、分布状态、距离参数等），进行聚类，可以从“攻击收益”相似性这个角度对CWE进行划分。但划分结果，也仅仅只能在研究漏洞攻击收益、攻击效果等领域进行应用，并由于CAPEC标准中定义的攻击收益种类过于单调（过滤重复后，攻击收益仅有34种），且大量CAPEC没有标注攻击收益，从而导致使用该方法划分的CWE簇，若数量保持在10-20个，则导致簇中会出现在图谱中无连通性的节点，大量存在于同一簇中的现象，若数量增加，则又会导致簇与簇之间，重叠度过高。究其原因，是CWE划分颗粒度粗细与CAPEC攻击收益描述颗粒度粗细不匹配所导致的。

3.2 基于模块度的社区发现算法划分实践

通过对CWE使用特征聚类的方式进行划分，我们发现，事实上，将细粒度的CWE分类划分为粗粒度的CWE簇或社区，最难的一点在于，如何保证划分到一个CWE簇或社区中的CWE保持概念上的一致性，并且簇与簇、社区与社区之间还要保持差异性。

CWE构建的图谱中，“ChildOf”关系占CWE之间的关联关系的绝大多数（参考表 2），而在CWE的官方定义中，“ChildOf”关系表示了两个CWE之间的上下级包含关系，也就是说，“ChildOf”关系两端的CWE在概念上具有单向一致性即子单位CWE与父单位CWE概念保持一致。

基于模块度的社区发现算法。基本思想是图谱中的节点会生成一个自己的社区标签，然后遍历所有距离为1的节点的社区标签，并选择最大化模块度增量（贪婪思想）的社区标签更新为自己的社区标签。在达到最大化模块度之后，每个社区看成一个新的节点，重复直到模块度不再增大。

图 5 基于模块度的社区发现

我们使用“攻击收益”、“利用方式”、“概念相似性”三个角度去验证社区发现算法对于CWE划分的有效性。

对于攻击收益的定义，我们沿用CAPEC以及CVSS的描述。将其分为两大类：风险收益和数据收益。风险收益是指CVSS评分区间的分布，CVSS官方在3.0版本中定义，将0-3.9得分区间内的漏洞标注为低危漏洞；4-6.9得分区间内的漏洞标注为中危漏洞；7-8.9为高危漏洞;9-10为严重漏洞，在漏洞概念研究过程中，由于高危及以上漏洞已然对业务造成严重影响，所以通常将高危及以上漏洞作为同一类风险等级进行研究。数据收益，是指漏洞利用成功后具体会造成哪一种影响，如窃取用户名密码、远程执行操作系统命令、提权等。这些概念，我们使用CAPEC中的定义，具体可参考附表。我们期望，同一社区内的CWE所触发的攻击收益，是一致的，即同一社区内的CWE有一致的风险收益和数据收益，当然这仅仅是理想情况，实际情况一定会存在差异，届时我们可以通过调整关系权重、补充CWE节点等方式进行优化。

对于利用方式的定义，主要从三方面去考虑，首先是CVSS中定义的“Attack Vector (AV)” -攻击向量，其次是漏洞作用的组件类型和攻击载荷发送方式。而这其中，同一社区的CWE，在攻击向量的选择上，应保持一定的一致性，对于作用组件类型和攻击载荷发送方式，则会存在差异。

而“概念相似性”，鉴于CWE官方定义的关联关系中“ChildOf”关系占较大的比例，所以同一社区的CWE之间，也应该具备很高的相似性。

首先，我们为保证划分的社区中，同一社区的漏洞具备高度的概念相似性，所以仅使用“ChildOf”关系作为连接边，但发现，会有孤岛节点的存在，且召回率和精确率都并不算高。随后，我们选择使用所有CWE定义的所有关系作为连接边，并加入Q-learning 算法对关系权重进行不断优化，最终得到了一个将所有CWE划分为19类的CWE划分模型。划分出的社区，在各项测试中均表现良好。

划分方法	召回率	精确率	F1
仅使用“CHILDOF”作为边	88.6%	67%	0.763
使用全部关系作为边且权重都为1	89.2%	84%	0.865
使用全部关系作为边并使用Q-L优化边的权重	94.3%	90.2%	0.922

如何描述划分出来的CWE社区、在“攻击收益”、“利用方式”、“概念相似性”等维度上，社区内的CWE是否保持一个良好的一致性。划分出的CWE社区还有什么其他的应用场景。由于篇幅原因，以上问题将会在接下来的系列文章，一一进行解答和实践。

目前已将CWE分类数据集上传，可在公众号后台回复“知识图谱”获取下载链接。使用过程遇到问题，可直接留言或私信，将安排作者在线解答。

基于社区发现算法对CWE的划分实践相关推荐

Network of Thrones --基于社区发现算法和图分析Neo4j解读《权力的游戏》（详细！）
一.概要数学家 Andrew Beveridge 和Jie Shan在数学杂志上发表过一篇名叫<权力的网络>的论文,主要分析畅销小说<冰与火之歌>第三部<冰雨的风暴&g ...
文献记录(part66)--一种基于交叉熵的社区发现算法
学习笔记,仅供参考,有错必纠关键词:复杂网络:社区发现:交叉熵: 一种基于交叉熵的社区发现算法摘要作为复杂网络中的一个极其重要的研究领域,社区结构的搜寻和发现研究具有重要的应用价值．该文将信 ...
基于链接密度聚类的重叠社区发现算法
基于链接密度聚类的重叠社区发现算法文章发表时间:2013年12月 1. 传统社区算法的局限性传统社区算法是将网络划分为若干各互不相连的社区,每个节点都必须隶属与唯一的社区,然而,在实际的社交网络中 ...
图算法（十三）：Louvain算法【适用场景：用于社团发掘、层次化聚类等场景】【基于模块度的社区发现算法，其优化目标是最大化整个社区网络的模块度】
一.概述 Louvain算法是基于模块度的社区发现算法,该算法在效率和效果上都表现较好,并且能够发现层次性的社区结构,其优化目标是最大化整个社区网络的模块度. 适用场景:Louvain算法适用于社团发 ...
社区发现算法 - Fast Unfolding（Louvian）算法初探
1. 社团划分 0x1:社区是什么在社交网络中,用户相当于每一个点,用户之间通过互相的关注关系构成了整个网络的结构,在这样的网络中,有的用户之间的连接较为紧密,有的用户之间的连接关系较为稀疏,在这样 ...
fastunfolding算法_社区发现算法综述—part1
目前我能在arxiv上找到的最新的关于社区发现算法系列的综述文了. 正文从这里开始: 2.2 社区发现现代网络在规模.多样性和复杂性上呈指数增长. 由于网络的变化,各种各样呈现出网络结构的不同类型的 ...
社区发现算法原理与louvain源码解析
前言社区发现(community detection),或者社区切分,是一类图聚类算法,它主要作用是将图数据划分为不同的社区,社区内的节点都是连接紧密或者相似的,而社区与社区之间的节点连接则是稀疏的 ...
社区发现算法-Community Detection-NormalizeCut/Louvain/NMF/LPA
本文结构安排图聚类简介正则化割 Louvain 非负矩阵分解(NMF) 其他常见方法图(graph):是一种由点和边集构成的结构 G = ( V , E ) G=(V,E) G=(V,E) 图聚 ...
社区发现算法——LPA与SLPA算法
LPA(Label Propagation Algorithm) LPA算法是2002年由zhu等提出的,在2007年被Usha.Nandini.Raghavan应用到了社区发现领域,提出了RAK算法 ...

基于社区发现算法对CWE的划分实践

基于社区发现算法对CWE的划分实践相关推荐

最新文章

热门文章