OpenKG地址：http://openkg.cn/dataset/vuln-sprocket
开放许可协议：CC BY-SA 4.0 （署名相似共享）
贡献者：四维创智（李德斌，孙基栩，鲍晨阳）
1. 前言
随着时间的推移，攻防技术的不断提升，组件的漏洞与日俱增，随之出现的各类漏洞情报也如雨后春笋一般疯狂涌现，使技术人员在想快速、全面地搜集漏洞情报时，会应接不暇，无法把握情报中心。
虽然，市面上已经出现许多漏洞情报平台来帮助大家去搜集情报，管理情报。但不同厂家的漏洞情报平台的内容侧重点也都有倾侧。
注重漏洞全面，而忽视了漏洞情报的垂直性，往往只有漏洞的基本信息，类似CVE、CNVD等官方漏洞情报平台。
具备一定的垂直漏洞情报搜集能力，能采集到漏洞的中文简介、漏洞POC等信息，但由于该类信息往往由平台运营人员手动采集或编写，在漏洞覆盖面上就会出现纰漏，存在一定的漏报和误报，比如seebug、exploit-db等厂商。
某个工具或框架自主研发或编写的漏洞POC、EXP及自主构建的漏洞情报信息，类似MSF、Nessus、xray等，这类EXP、POC情报价值非常高，是研究人员所重点关注的，但往往这类情报与其他漏洞的情报关联度不高，容易出现孤岛节点。（与CVE/CPE/CWE等标准脱节）
基于上述调研结果，我们不难发现，漏洞情报平台目前主要问题便是：
1. 站在不同角度的厂商对漏洞情报搜集的侧重点不同，导致技术人员想要全面了解某一漏洞的相关情报，就需要跳转多个厂商进行情报查阅；
2. 不同厂商之间的漏洞情报相对孤立，每个厂商都有自己的一套情报标注标准，关联不同厂商情报时，会出现情报重复的现象；
3. 当前各类漏洞情报平台所包含的漏洞情报限制性相对较大，对互联网上散落的弱关联情报并没有很好的采集和分析能力；
根据上述问题，我们尝试采用知识图谱技术对互联网上的开源漏洞情报进行整合和分析，并构建了以CVE漏洞管理方法为标准的漏洞情报平台。我们将它命名为”vuln_sprocket”，下面我们将介绍该图谱的构建方案。
在进行知识抽取前，我们首先要明确，什么是漏洞情报。我们的理解是：针对某一漏洞，所有对了解该漏洞有帮助的信息，都可以称之为该漏洞的漏洞情报。在这里，需要明确的是，漏洞需要了解哪些信息，以及怎样的信息才算是对了解该漏洞有帮助。
通过实战经验以及与一线人员交流得到的反馈，我们总结以下几点比较受到关注的漏洞情报信息：漏洞基础信息、漏洞编号 （包括但不限于CVE、CNVD、EDB-ID）、漏洞危害类型（命令执行、注入、溢出等）、漏洞利用方式(远程、本地)、是否存在利用风险（宕机、数据删除）、漏洞危害等级 （低、中、高）、漏洞简介 （英文、中文）、漏洞作用组件 （厂商、组件、版本）、漏洞分析、漏洞原理机制、漏洞复现过程、漏洞复现靶场、漏洞利用工具、漏洞检测、利用过程分析、漏洞检测代码、漏洞利用代码、漏洞权限提升代码、防御措施、漏洞补丁信息、漏洞白盒检测方式、漏洞具体解决方案、漏洞流行度、热度等趋势分析。针对漏洞之间的关系比较感兴趣的几个点是：
1. 漏洞之间的是否存在组合利用的可能性
2. 漏洞作用的组件是否存在供应链
3. 能否根据某组件已知漏洞情报去推断可能存在的新漏洞
4. 能否对漏洞情报进行分析，能够合并内容相同但发布平台不同的漏洞情报
2.2 实体及关系概念构建
根据以上调研，我们不难发现，在这其中，“漏洞”这个实体概念，是作为情报关联的关键。用户关心“漏洞”的攻击收益，关心“漏洞”的作用对象，关心“漏洞”的原理、防守方案等等。因此，在参考stix 2.1 当中对实体和关系的描述后，我们确定以“漏洞”为核心的原始实体及概念关系，如下图。
并且，我们以漏洞为中心点，根据其他实体与漏洞关系位置的不同对其进行如下的逻辑分层。
1. 组件层(漏洞作用的目标)
A. 软件、操作系统
B. 组件分类信息
2. 漏洞层（中心点）
A. 漏洞基础信息
3. 情报层 （对了解漏洞有帮助的信息）
A. 漏洞情报（对漏洞基础信息进行补充，包括中文翻译、参考链接、漏洞类型等其他属性的补充）
B. 漏洞分析文章（完善漏洞分析情报，包括漏洞分析、复现过程、POC/EXP利用分析、防御措施分析等内容 ）
C. 漏洞检测/利用工具情报（ 完善漏洞工具的情报，包括发布时间、编写语言、POC/EXP来源等信息）
4. 实例层 （情报的详细说明或对情报的补充拓展信息）
A. 工具源码（包含工具源代码信息）
B. 工具脚本 （包含工具脚本的基础信息以及工具调用/触发所需的场景信息）
2.3 实体及关系提取
图谱中绝大多数的知识都是通过对半结构化数据转换得来。需要注意的是，在CWE（软件脆弱性类型数据集）和CAPEC（攻击类型枚举和分类数据集）的官方定义中便包含有两者之间及各个数据集内部的关系，可以进行直接的引用。
CAPEC和CWE的关系是“战术与执行者”的关系，意为“某个攻击类型所表示的攻击行为其作用对象是一个组件的某个脆弱点”。CAPEC标准的数据结构包含的“Related_Weaknesses”字段表述该攻击类型所利用的脆弱点列表。
无论是CAPEC还是CWE，在其标准内部也存在不同实体的关系，CAPEC对于攻击类型之间关系的描述保存在该标准中“Related_Attack_Patterns”字段，CWE对于脆弱性之间关系的描述保存在该标准中“Related_Weaknesses”字段。
在信息搜集过程中，单一的搜集方式会导致信息搜集不全面，或信息误报。通过构建组件、服务、系统等实体之间的关系，并推理之间的间接关系，可完善并发现隐性的资产信息。
确定好原始实体后，我们尝试对实体之间的关系进行分析，除了常规的包含或归属关系外，我们针对组件层，添加了 “depend_on” 这样的一个关系，用来表示组件供应链关系中的依赖关系。这是因为，依赖关系是作用在组件之间的强关联关系（当a依赖b时，若a存在则b一定存在），在进行推理时可以通过该关系进行信息拓展。
CPE（Common Platform Enumeration的缩写）是一个以标准化方式为软件应用程序、操作系统及硬件命名的方法。最大的漏洞库CVE中对软件的描述便是使用了CPE标准。基于统一资源标识符 (URI) 的通用语法，CPE 包括正式名称格式、用于根据系统检查名称的方法以及用于将文本和测试绑定到名称的描述格式。在CPE的字段中，常常包含一定的软件依赖信息，如“cpe:2.3:a:10web:10websocial:-:*:*:*:*:wordpress:*:*”中描述了10websocial 和 WordPress的依赖关系。
同时，在维基百科上，对软件的描述中，也会包含一些依赖关系。当然这类数据，由于软件名并不是使用的CPE标准格式，因此，首先需要进行非标准描述映射标准描述的工作。在这里，我们主要使用的方法有相似度匹配、人工筛选以及基于CVE漏洞描述的关联推理。
2. 软件依赖关系存在“继承”属性，即当a软件所依赖的b软件存在c软件的依赖关系，则a软件与c软件也存在依赖关系
3. 软件依赖关系，若a依赖b组件，则b为a的必要条件。即，当a存在时，b必然存在。
基于以上规则，在信息搜集时，便可以通过推理进行信息补全。
“(n:Software{name:”NextGEN_Gallery”})-[:plugin_for]->(ma:Software{name:”WordPress”})”
这里需要注意的是，“plugin_for”与“depend_on”具备同等效果，不同的是，“plugin_for”具备标注依赖关系中，其中一方是另一方的“插件”的作用
当我们在初步信息搜集时，发现了该目标使用了“NextGEN Gallery”组件（“WordPress”组件的一个插件），但由于该目标修改了有关“WordPress”的相关特征，并使用了伪静态。使我们只获取到了“NextGEN Gallery”信息，届时便可以基于上述知识进行关联，确定组件 “WordPress”的存在，并可以根据规则2，推理出其他组件，如图（红线为规则3推理所得）
知识图谱作为“认知智能”技术典型代表，在网络安全领域中的应用具备天然优势。尤其是在情报组织、分析，辅助决策任务，路径规划等方面，随着知识图谱技术的不断发展其应用空间会非常广泛。
本文所构建的情报虽说均来自于互联网开源漏洞情报信息，但其丰富程度已然超过许多商业情报平台，这不难发现，在如今的互联网时代下，公开情报通过精细的采集、分析后其丰富程度仍是商业情报平台无法比拟的，且情报获取速度较商业情报，在大规模应用中也将快于商业情报许多，于精耕细作某一细分方向的商业情报源比较来说，自然是无法达到它所拥有的速度和准确度，但仍不妨开源漏洞情报在诸多领域的广泛应用。
相信在可见的未来，知识图谱相关技术在开源漏洞情报分析领域，会有它无法替代的作用和意义。
OpenKG
OpenKG（中文开放知识图谱）旨在推动以中文为核心的知识图谱数据的开放、互联及众包，并促进知识图谱算法、工具及平台的开源开放。
点击阅读原文，进入 OpenKG 网站。
原文始发于微信公众号（开放知识图谱）：开源开放 | 开源立体化漏洞情报知识图谱（四维创智）
