金融行业开源软件漏洞风险评估框架研究

2018-09-26何东杰匡翔宇刘为怀蒋丹妮

计算机应用与软件 2018年9期

何东杰匡翔宇王琪刘为怀蒋丹妮杨洁

1(中国银联电子商务与电子支付国家工程实验室上海 201201)2(复旦大学计算机科学技术学院上海 200433)

0 引言

随着开源软件的不断发展和完善，其地位日益重要，金融企业在生产环境中不可避免地需要使用开源软件。虽然开源软件的源代码可见，但是由于未参加开发过程，其质量无法评估，这与金融行业对于软件安全性的极高要求相违背。

本文从开源软件导致的安全问题入手，目标在于减少金融公司使用开源软件的风险。开源软件的安全问题中一个重要部分就是漏洞风险。由于无法预测在将来会不会爆发漏洞，在漏洞曝光后及时地分析处理是十分重要的工作。企业用户需要及时获取到漏洞信息，并评判其风险，才能做出正确的对策。

开源软件在开发、维护方式上与闭源(商业)软件有很大的不同，在漏洞风险的评判上要根据其特性捕获更多的信息[1]。首先，开源软件开发速度较快，必须不断追踪和整合包含安全补丁的新版本。其次，开源软件的漏洞常常直接公布而没有提前通知使用方，因此，用户必须时刻保持警惕，做好修复漏洞的准备[2]。最后，开源组件之间具有较强的依赖性，该组件本身可能没有漏洞，但是其依赖的组件有漏洞[3]。

开源软件的漏洞需要考虑漏洞的属性和软件的属性。传统的软件度量模型包括软件成熟度评估模型和开源软件评估模型。目前主流的模型有OpenBrr、QSOS和OSMM等。本文将逐一论述其模型中的安全性部分的特点和缺陷，并借鉴它们的思想构建评估模型。

现有的漏洞发布平台，例如NVD和CNNVD等，发布对漏洞危险的定级时考虑的都是漏洞本身的属性，而没有考虑到用户所在的实际环境。因此，为了准确地反映漏洞对用户所在环境的危害，本文将漏洞本身的因素加入考量，同时也加入了在特定环境中的评估方法。

1 现有技术方案

现有的技术方案主要包括现有的对于软件安全性的评估框架和对于漏洞的评估两种。

1.1 软件度量模型

软件度量模型主要包括OSMM、QSOS、OpenBRR和OMM。它们都是在2000年之后提出的开源软件评估模型。

(1) OpenBRR模型：OpenBRR最初由Intel在2005年提出，目前也是开源社区中较为著名的成熟度评估方案。OpenBRR模型的评估准则主要包括完整性、简单性、可适应性和一致性等。它的评估分为四个阶段，分别为软件初步过滤、增减与确定评估指标模版、搜集评估原始数据并度量和通过加权和计算软件的评估。在安全性的评估方面，主要有三项指标，分别为最近6个月中等到十分危险的安全隐患数量，当前仍存在的安全隐患数量和有没有致力于安全性的信息。每个指标采用1～5的五级度量，采用加权和的方式计算结果。可见，其安全性的评估很薄弱，仅考虑了过去和未来的漏洞数量。

(2) OMM模型：OMM模型是由欧盟和华工大共同提出的成熟度模型。OMM更注重于对开发过程的考察，它的模型定义分为两个阶段，分别为确定评价因子和因子分解为相应的目标。官方提供可信因子有12项，其中安全性相关的只有1项：缺陷数目和错误报告[4]。可见，OMM模型在安全性方面的评估比OpenBRR模型更薄弱，并且它没有给出具体的评价规则。

(3) OSMM模型：OSMM模型分为OSMM-C模型和OSMM-N模型。OSMM-N模型包含了6项一级属性，然而都与安全性无关，只能算在可维护性和支持性方面。OSMM-C模型中包含了15项因素，较OSMM-N扩展了一倍多，其中包括了安全性，含义为必要的安全措施和必要的限制，包括访问控制和用户授权等。

1.2 漏洞评估方法

现有的漏洞评估方法主要有CVSS和OVAL两种，其中CVSS使用最为广泛。

(1) CVSS：CVSS是一种计算漏洞危害的评分方式，主要包括三项分数基础分、临时分和环境分。基础分用于描述漏洞的内在属性；临时分主要是由外部事件导致的影响，是一个随时变动的数值；环境分用于反映漏洞对该组织的影响[5]。CVSS目前最新的版本是3.0，漏洞的得分介于0～10之间，按照分数划为5个等级，9.0分以上为危急漏洞。

表面上看CVSS的三项分数具有相当的普适性，能够覆盖大部分因素，然而现实情况是包括NVD和CNNVD在内的漏洞发布机构都只发布CVSS的基础分，其他两项分数需要用户自己去评估。现实情况下，绝大多数企业都没有能力和精力来进行评估，都采用标准推荐的权重和分数，并且只考虑基础分，这就导致了CVSS的得分有很大的局限性。

(2) OVAL：OVAL是一种用来评估漏洞XML格式的描述语言可以用来分析各种操作系统和嵌入式系统的状态、漏洞补丁等情况，它主要包括定义、测试、对象、变量和状态这五项因素[6]。OVAL只是一种用来描述漏洞语言，本身不能对漏洞进行打分，但可以基于它进行漏洞的评估。

1.3 攻击图技术

攻击图产生于20世纪90年代，最近几年成为了研究热点。攻击图用来模拟潜在攻击者可以用来侵入目标网络的可能路径，以及用于确定相应的主动和被动安全措施。攻击图生成过程包括漏洞信息处理，收集网络拓扑和应用信息，确定网络主机之间的可达性条件以及应用图建立算法[7]。

攻击图可以表示潜在攻击者通过利用主机上的一系列漏洞并在每一步获得某些特权的侵入目标网络的方式。在传统的攻击图中，节点代表攻击者在网络主机上获得的特权，边代表攻击者为获得这些特权而使用的软件漏洞。攻击者需要在某些主机上拥有一组特权才能利用网络主机上的特定漏洞。在成功利用主机上的漏洞后，攻击者会获得其他特权，并继续攻击网络中的其他主机，或尝试使用其他漏洞提升此主机上的特权。本文对传统的攻击图算法进行改进，使其适应于系统中单个漏洞的影响评估。

2 本文研究方法

在研究方法上，本文先提出金融开源软件漏洞风险评估模型，再提出相应的具体评估方法。在评估方法上主要使用了网络信息获取工具和攻击图的手段。

2.1 风险评估模型

本文所设立的模型借鉴了软件成熟度模型的分级打分策略。一级属性设置了漏洞因素、质量因素、影响因素三项。三项因素的表格如表1所示。

表1 金融行业开源软件漏洞风险模型评估条件及子属性

漏洞因素用来衡量该漏洞的威胁，是漏洞本身具有的属性，设计时借鉴了CVSS的思想。主要包括漏洞利用难度、攻击所需资源和对安全三要素(机密性、完整性和可用性)的影响。

质量因素用来衡量开源软件的因素，主要包括四点，即:1) 该软件之前曝光漏洞的次数，即在过去有多少高、中危漏洞被曝光，用来反映该软件的开发质量。2) 该软件在生产环境中的稳定性，即该软件在生产环境中稳定运行的时间占总时间的比例，用来反映该软件的漏洞是不是偶然事件。3) 该软件最近更新的频率，如果开源社区衰落，缺乏开发者维护代码，导致软件缺乏维护，会增加漏洞和故障的可能性[8]。4) 该软件开发者等级，有写代码平台如Openhub对开发者的等级进行了评级，可以借此推断软件质量。

影响因素用来衡量该漏洞被利后对系统造成的影响，主要受两方面的影响。1) 该软件在系统中的层次，通常可以分为应用软件、中间件软件、支持软件、平台软件、底层软件还是操作系统级软件。被攻击时，越低层的软件往往具有越大的权限，也能造成更严重的破坏。2) 该软件被依赖的程度，环境中其他的软件对该软件调用的方式，也包括该软件为其他软件包括上层软件提供服务的方式。如果在系统中较多依赖于该软件提供的特定功能才能正常运行，则其被依赖程度较高，一旦该软件被攻击，会牵扯到与其相关的其他软件。

2.2 风险评估计算方法

本文中每个一级要素的分值，要通过二级要素的分数计算得到，而二级要素则需要按照相应的标准去评判。本文通过对国内外诸多代码托管平台上开源软件特征的调研，确立了评价策略。

漏洞因素可以采用CVSS V3的评分，将其基础分采纳作为漏洞因素的得分VL，这是一个介于0～10之间的整数。

质量因素二级属性评价方式采用权值积分的方式，得分按照三级制给出，分别为1分、3分和5分。具体的评价方式如表2 所示。实际使用中可以根据需求进行属性的增加和删除，也可以对评分细则进行修改。

表2 金融行业开源软件漏洞风险模型质量因素评估细则

质量因素主要考虑了最近一年内中高危漏洞数量、开发者等级、最近一年内软件更新周期和可靠运行时间占比这四项所有开源软件都具备的属性，保证评估方式可实施。

在得到质量因素各二级要素分值之后，通过表2中所给出的权值，加权求和。表2中的权值是本文分析得出的经验值，在实际使用时可根据企业运维人员对软件质量的理解调整权值。其中，质量因素有n项指标，分别为Q1～Qn，他们的权重分别为WQ1～WQn则，质量因素为：

(1)

影响因素的分值通过2.3节所描述的攻击图算法得到，先生成SVRA攻击图，再执行评估算法，得到风险值AF。总的漏洞风险为：

(2)

2.3 风险评估数值获取

本文针对模型中的评估属性都给出了切实可行的操作方案。包括了整体方案、信息获取方案和漏洞影响评估方案。

2.3.1 整体方案

整体方案包括漏洞因素获取、质量因素获取和影响因素获取三部分，流程如图1所示。

图1 风险评估工作流程

漏洞因素采用NVD给出该漏洞CVSS V3基础分。为此需要维护一个信息获取工具，用来获取漏洞因素得分。质量因素前三项也需要该工具获取信息。可靠运行时间占比通过分析日志内容获得，这方面有许多现有的工具[9]，使用人工方式分析也可以。影响因素通过使用扫描工具分析开源软件所属环境，并使用SVRA算法，计算出该漏洞在特定系统中的影响大小。

2.3.2 信息获取方案

信息获取工具需要爬虫工具的支持。与一般的网页爬虫相比，漏洞信息已知要获取信息的页面和需要的内容，可以放弃通用爬虫的普适性，但是需要有较强的鲁棒性，能够应对常见的异常情况。

本文所提信息获取方案采用了两种手段增强鲁棒性：(1)从多个数据源获取数据，例如代码托管平台可以选择多个，包括国外的Github、Gitlab、BitBucket、SourceForge、Google Open Source以及国内的码云、码市、CSDN Code、百度效率云等。漏洞公布平台则包括了NVD和CNNVD等。(2)独立维护元素路径。将单独维度将爬虫的获取元素路径单独提炼出来，生成一个表格，如表3所示，使得它更容易维护，当页面布局发生变化时，修改较为方便。

表3 信息获取路径表

通常情况下页面信息的变更主要是错位和丢失两种情况，如表4所示。丢失，即某项信息无法获取，但其他内容没有异常；错位是由于页面信息的增加或减少导致获取到的信息名称和内容不匹配。此外，也要考虑到错位和丢失同时存在的情况。

表4 发生错误的情况

区分了错误类型后，异常情况的监测就可以实施了。丢失情况比较容易发现，当发现存在无法获取的值时，即发生了丢失。错位情况比较难以发现，本文采取的方式是将获取的数据与之前的结果进行对比，如表5所示。当发现数据的长度或格式无法匹配之前内容时，进行异常报警。异常监测可以设置成定时任务，定期提醒运维人员介入核查错误内容。

表5 正常信息与异常信息对比

对于质量因素中的开发者等级和软件更新周期这两项属性可以采用和漏洞信息相同的获取方法，只要对获取路径表中的内容进行修改为相应的开源软件门户和代码托管平台。

2.3.3 漏洞影响评估方案

为了评估漏洞影响因素，本文借鉴了攻击图的思想，提出了一种对系统中单个漏洞进行评估的算法：SVRA(Single vulnerability risk assessment)算法。

SVRA图生成算法:SVRAconstruct输入:软件集S,关系集R和漏洞集Vul输出:攻击图AGBegin:bool visited[S.length]queue Qforeach m_Vul: Vul: if visited[m_Vul.s]: continue Q.push(m_Vul.s) visited[m_Vul.s] = true S[m_Vul.s].vul = m_Vul.score while !Q.empty(): node = Q.front V.push(node) foreach r: R: fro = r.f, end = r.e if end=node: swap(fro, end) if fro=node&&!visited[end]: E.push(r) Q.push(fro) visited[end] = true Q.pop()return (E,V)End

SVRA漏洞风险及其影响因素评估算法:SVRAevaluate输入:攻击图AG输出:漏洞及其影响因素的集合Begin:foreach v: AG.V: if v.ris <= 0: continue AG.initRis() queue.clear() queue.push(v) m_ris = 0 while !queue.empty: m_v = queue.front m_ris+= m_v.ris * m_v.srv.num foreach e: AG.E: if e.second != m_v: continue if m_v.ris > e.front.sec: t_ris = m_v.ris - e.front.sec t_ris+= e.front.aut - m_v.aute.ris = t_ris queue.push(e.front) queue.pop endwhile; result.push_back(v, m_ris) sort(result.begin,result.end,comp_ris)return resultEnd

SVRA算法包含两部分:SVRA图生成算法和SVRA漏洞风险及其影响因素评估算法。

传统的攻击图构建了一个以属性、攻击方式、漏洞与权限为属性的图，并且利用贝叶斯网[10]或Petri网[11]进行攻击可达性的判断。本文所提出的SVRA算法与传统攻击图算法有两方面的区别：(1)传统攻击图考虑的是网络环境中主机之间的关系，构图的粒度在主机层面，入侵途径是从整个系统的最外层开始，而SVRA算法的粒度在主机上的软件层面，入侵途径从已知软件漏洞开始。(2)SVRA攻击图的评估方法不一样，传统攻击图主要考虑从一个漏洞到另一个漏洞，从一种权限到更高权限的跃迁，而SVRA的评估计算的是对其他节点而非漏洞的影响，考虑的是节点间的关系而不是漏洞间的关系。

本文中攻击图可以表示为AG=(E,V),其中E为边集，即软件之间存在的调用关系，是一条有向边；V表示节点集，是系统的软件集合，对于任意的软件v，可以用五元组表示。其中：nam表示该软件的名称或编号；srv表示该软件涉及的服务，多个软件可能涉及同一服务，sec表示该软件本身的安全性，如访问控制、日志记录等；ris表示该软件当前所受风险；aut表示该软件运行所需的权限。

SVRA图生成算法在构建时可以将多个漏洞考虑在内，加快构图速度，方便漏洞间的对比。算法的输入为初始软件集S、初始关系集R和初始漏洞集Vul。软件集S标识了系统中的所有软件，关系集R标识了系统中软件之间的调用关系，用有向图表示，如果是一个双向的关系，则需要再加入一条反向的边，漏洞集Vul是信息获取工具得到的漏洞信息。SVRA图生成算法返回的结果是攻击图AG。在生成算法中，删除了不相关的软件和关系，也删除了图中的环路，并将初始漏洞集的信息和附着到得到的节点集，方便后续分析算法的实施。

在得到了攻击图之后，利用影响因素评估算法更新攻击图中的每一个节点的ris风险值。SVRA评估算法，综合考虑了软件的服务、安全性和权限，计算出攻击路径可达的节点上所受的影响，最终将整个网络的节点影响因素求和，按照递增的顺序给出漏洞及其影响因素的集合。

3 实验

本文选取了目前金融行业常用的开源消息中间件rabbitMQ和开源分布式数据库Hbase漏洞进行评估。具体的漏洞选择了rabbitMQ的跨站脚本漏洞，CVE编号为CVE-2017-4967，以及Hbase的权限许可和范文控制漏洞，CVE编号为CVE-2015-1836。采用本文所述方法测评并对比二者的漏洞风险差异。

首先获取漏洞信息，利用本文所述信息获取方案采集到漏洞详细信息，可知CVE-2017-4967漏洞对的CVSS V2基础分为4.3，V3基础分为6.1；CVE-2015-1836漏洞对的CVSS V2基础分为7.5，V3基础分为7.3。为方便计算，统一采用V3基础分。

然后计算质量因素，利用本文所述的信息获取方法，得到原始数据，再利用评估模型的得分评判标准，可以得到表 6中所示的数据，其中对比展示了Hbase和rabbitMQ的质量因素子属性差异。

表6 质量因素子属性初始值得分对比

对于表6中的内容，利用式(1)求得Hbase对的质量因素得分为2.5分，rabbitMQ的质量因素得分为3.7分。

最后对影响因素进行计算。先获取系统拓扑结构信息，实践中有三种方式：(1)使用扫描工具如MulVAL、NetSPA和TVA等[12]，再转化为SVRA攻击图；(2)用人工采集的方法，找出系统中正在运行的进程和各个端口所对应的状态和程序，然后根据已知的程序之间关系扩展得到软件拓扑结构；(3)利用开源软件的特性，扫描源代码，获取程序之间的调用关系。

利用系统拓扑信息以及获取到的漏洞信息，采用SVRA算法绘制出攻击图，如图2所示。图中显示了节点和节点间的调用关系，节点后的两个数字分别是五元组中的序号和风险值。初始状态下只有漏洞的两个节点有影响值，分别标记为x和y。