如何管理漏洞(漏洞管理新说)

青藤云安全 | 程度,下面我们就来聊聊关于如何管理漏洞?接下来我们就一起去了解一下吧!

如何管理漏洞(漏洞管理新说)

如何管理漏洞

青藤云安全 | 程度

本文概要

漏洞管理(Vulnerability Management)是一个老生常谈的概念,也是信息安全领域最为人熟知的概念。漏洞管理不等于漏洞扫描,漏洞扫描充其量只是过程中的一个步骤。大家经常会把漏洞管理和补丁管理(Patch Management)混为一谈,两者区别也在这里说下,补丁管理是指更新软件、操作系统和应用的一个过程,补丁通常包括功能类、性能类和安全类补丁。把漏洞管理和补丁管理放在一起,基本有一定的衔接关系,在存在漏洞的时候,需要打补丁来进行修复。但是有时候的漏洞短时间内并没有补丁,比如0Day,或者是放弃维护的软件、系统以及应用,比如Windows XP。漏洞有时候就算发现了,也会因为业务问题而无法打补丁,要通过其他的方式降低影响,比如安全流量设备的虚拟补丁。

将企业的漏洞管理计划与安全框架或标准进行对照,如 Center for Internet Security (CIS, 互联网安全中心) Controls,将有助于揭示有差距以及潜在的改进领域。目前CIS Controls的版本是V7.1发布时间是2019年4月。CIS控制是一系列有优先级的纵深防御行为,可以降低大部分常见的攻击方式。CIS控制一共分为三个大的部分,初级、基础级、组织级。每个级别是递进关系,每个级别里面表明了相应的安全手段。如下图所示,这里看到持续的漏洞检测是作为初级能力中的第三项出现,也是在安全能力要求比较低的情况下就需要做出的表现。

关于持续漏洞管理的细分要求

上图中共展示了七个要求:3.1 运行自动化扫描工具主要讲的是非认证式扫描,指外部通过网络指纹方式的扫描;3.2 运行认证的扫描,主要指登录到相应的设备进行扫描;3.3 设定专用账号,这个是扫描的方式要求,这样可以一方面方便扫描,另一方面可以降低误报;3.4部署系统的自动化补丁管理工具,是针对于系统的漏洞进行修复;3.5部署软件的自动化补丁管理工具,这是针对于软件的漏洞进行修复;3.6 进行背靠背的漏洞扫描,是为了验证漏洞是否补丁成功的验证性扫描;3.7 采用风险评级流程,是一种按照风险来对漏洞进行评估的方式。以上七个要求只是说明了应该做到的方面,但并不代表漏洞管理流程,下一章将对漏洞管理流程进行解析。

漏洞管理流程

漏洞管理流程一般情况下分为四个步骤:漏洞识别、漏洞评估、漏洞处理、漏洞报告。

漏洞识别是我们通常意义下的漏洞扫描,也是漏洞管理的第一步。根据现有资产的情况,目前可分为笔记本、PC、服务器、数据库、防火墙、交换机、路由器、打印机等。漏洞扫描进行全部资产的扫描发现已知的漏洞。后面会详细介绍漏洞识别的相关原理。

漏洞评估是在漏洞识别的基础上进行漏洞严重性的评估,这一步非常重要会影响到后面的处理步骤。比较常见的漏洞评估是使用CVSS评分法,根据CVSS的分数可以分为危急、高危、中危和低危。但是这种评估方法被业界诟病太多,需要结合其他的方式来进行评估。做法会更进一步结合资产的重要性来评估漏洞影响,更好的方式是结合风险和威胁评估。后文也会重点说明这种方式。

漏洞处理是在漏洞评估的基础上进行相关的修复、降低影响或者不修复的操作。修复动作不是简单的打补丁,是一个流程上的东西。修复过程通常包括以下几个步骤:

1. 获取厂商的补丁;

2. 分析补丁的依赖和系统的兼容性以及补丁的影响;

3. 建立回滚计划,防止补丁对业务造成未知影响;

4. 在测试环境测试补丁修复情况;

5. 在部分生产环境测试补丁修复情况;

6. 进行灰度上线补丁计划,乃至全量补丁修复;

7. 分析补丁修复后的系统稳定并监控;

8. 进行验证补丁是否修复成功,漏洞是否依然存在。

对于很多无法直接根除漏洞进行补丁修复的情况,比如0Day,不在支持范围的系统或者软件,业务需求无法中断,补丁速度滞后等情况。我们要采取降低漏洞影响的操作,如下图所示:

通常关于漏洞减轻的措施三个大的方面:网络、终端、应用和数据,细分可包括:

1. 隔离系统网络,包括防火墙规则和网络区域划分;

2. 网络访问控制;

3. NIPS、WAF、SW、DAP、RASP等软件或者设备签名规则更新;

4. HIPS终端类安全产品进行阻断;

5. EPP类安全产品类似白名单机制、系统加固等;

6. 阻断有漏洞软件的网络连接;

7. 主机防火墙进行端口阻断。

漏洞报告是漏洞管理的最后一个步骤,也是最终的一个产出物。这个报告的目的是为了总结每一次漏洞管理的成果以及记述过程,存档后也可以对下一次的漏洞管理行为做参考。依照报告的涉及深度可以由浅至深分为:合规报告、修复过程报告、基于风险报告、重点漏洞分析报告、趋势和指标报告、持续改进报告。合规的报告比如PCI-DSS类型的报告,仅仅为了合规的需求。报告本身其实能够说明每一次管理过程的成果,以及每次评估方法的多样性以及合理性。

综上所诉,漏洞管理的成熟度,可以参看下表:

漏洞识别原理

漏洞识别一般是通过漏洞扫描器实现的,识别漏洞的形式无外乎有四种:非认证式扫描、认证式扫描、API扫描、被动流量扫描。前两种是最普遍的方式。非认证方式扫描,也叫网络扫描方式(Network Scanning),基本原理就是发送Request包,根据Response包的banner或者回复的报文来判断是否有漏洞,这种分析Response包内容的主要逻辑是版本比对或者根据PoC验证漏洞的一些详情来判断。认证式扫描也叫主机扫描方式(Agent Based Scanning),这种方式可以弥补网络方式的很多误报或者漏报的情况,扫描结果更准,但是会要求开发登录接口,需要在主机进行扫描。拿Nessus举例,基本就是下发一个脚本执行引擎和NASL脚本进行执行,在主机保存相关数据然后上报服务端,最后清理工作现场。API扫描与接近于应用扫描方式,这里不做深入分析,跟之前写的一篇文章中DAST相关。被动式流量扫描比主动式的流量扫描从带宽IO上没有任何影响,但是需要对所有请求和返回包进行分析,效果来说最差,因为某些应用如果没有请求过就无法被动地获取相关流量数据进行分析。

说完这些模式,漏洞识别的核心原理是什么呢?漏洞识别本身并不是很复杂的事情,因为NVD的数据全部是公开,数据来源来看除非有大量的0Day,否则漏洞数量上每个厂商的区别并不大。笔者曾研究过Nessus的实现原理,毕竟在3.0之前还是开源的。80%以上的漏洞识别都是通过版本比对实现的,但是不是CVE漏洞能够体现的,而是每个厂商的安全公告(Security Announcement)获取的。比如RedHat的Security Announcement( http://www.redhat.com/mailman/listinfo/rhsa-announce),可以通过邮件订阅,这里才是真正的可用数据。这里附带一句,任何成熟的软件厂商都应该维护这样的一个安全公告,要不然客户遇到漏洞无法修复。主流的Linux系统都有这种公告我就不一一列举了,还有一些核心的软件也有这种安全公告内容。有这个的好处是让漏洞扫描工具可以迅速的定位漏洞问题所在。除了版本比对,各个扫描器的区别就在PoC的验证脚本数量,老牌的漏扫三大厂Rapid7、Tenable、Qualys积累的都不少,这个就是个日积月累的活了,这种通过PoC的方式更准。因为有些情况运维图省事,直接替换二进制,其实漏洞已经修复了,但是版本没有变化,这时候PoC就起作用了,还有在版本无法获取的情况下也可以发挥作用。PoC可以分为两种形式,一种是本地类的验证,比如bash的Ghost漏洞这种情况就是本地执行PoC方式;另一种网络类的验证,比如OpenSSL的HeartBleed漏洞,就需要向其网站能够发送触发漏洞情况的Payload。其实无论是网络类的扫描方式还是主机类的扫描方式都是这两种原理。

这里可以贴个Kenna和Cyentia联合报告的图,记录了每个厂商的修复漏洞时间:

微软对待漏洞的态度还是挺坚决,75%的漏洞都会在134天内能够修复,反观IBM就会慢很多,也是对于厂商选型来看有参考价值。

其实漏洞扫描厂商的最大区别并不是部署模式,或者是发现方式,最核心的问题是对漏洞的评估。举个例子,如果有1000个漏洞被识别了,要如何回答客户哪100个漏洞是最值得修复的,这才是核心区别,下面着重讨论。

漏洞管理遇到新的问题

一、漏洞评估方式的改进

漏洞的评估模型目前有三种:基于漏洞本身的评价;基于资产的评价;基于风险和威胁的评价。

Model

Focus

Approach

漏洞为中心

漏洞的严重性,依赖CVSS评分包括:可利用性、利用影响、是否公开了利用方式等几个维度,具体可参看CVSS评分标准。

逐渐降低风险

资产为中心

资产对应的商业价值,资产的暴露面。(是否含有敏感数据,是否面向互联网)

逐渐降低风险

威胁为中心

是否在恶意软件中或者勒索软件中,是不是在黑客常用工具集中或者在外界已经有明确的利用脚本等。

威胁立即修复

一般客户能做到以漏洞为中心的第一点也不容易,基本都是对于所有漏洞无差别修复,这样工作量很大,且没有抓住重点。加入资产的重要性进了一步,根据实际资产的价值进行结合这样更有针对性。以威胁为中心的评价方式是近几年提出的,并不是取代上面两者,而是这个基础上综合考虑加入威胁的因素。合起来的模型叫做逐渐降低风险和立即处理威胁(Gradual Risk reduction & Imminent Threat Elimination (GRIT))。如下图所示:

越靠下的部分证明修复窗口越大,越不需要紧急修复,越靠上修复窗口越小,需要紧急修复。最下面的逐渐降低风险是对待风险以漏洞为中心或者是以资产为中心的传统方式。中间的普通紧急威胁是指在渗透的数据库里比如exploitDB或者在渗透测试的工具集里,或是在恶意软件或者勒索软件利用里面,这些数据的来源于威胁情报,需要做一些紧急的应对。最上面的紧急威胁是指针对性的攻击,主要指从威胁情报获取TTPs的攻击,这个针对性很强的攻击必须在很短的时间内处理。

下图是2019年十大安全项目之持续适应风险与信任评估的漏洞管理项目,其基本思路也是基于风险和危险的漏洞管理方式。

二、资产类型的扩展

信息化领域目前的两大趋势变化:传统数据中心上云;IT和OT的结合。两种趋势导致被评估的资产类型发生了很大的变化且导致问题关注点的转移。在上云的趋势下,传统的部署模式会有很大的挑战,尤其是容器技术的大规模使用,之前漏洞扫描的方式基本失效。云计算在使用上方的便性有很大的提升空间,但是通过本地部署的方式去进行漏洞并不是最合适的解决方案,基于云的扫描器可能更适用于这种情况。基于云计算的漏洞扫描方式可以跟云管平台联动,更好的管理云上资产,且毫不遗漏地进行所有云上资产的漏洞管理。由于容器技术的特点,之前网络类的还是基于agent的方式都很难对容器进行有效的漏洞扫描,都需要对容器的文件系统进行理解,对每个layer分析来进行漏洞的分析和扫描。因为容器的网络组织形式以及在运行时状态,会让传统的漏洞扫描失效,基本原理发生了根本的变化。所以在各个大的传统厂商,需要针对容器要做新的技术演进,同时留出了市场空间可以让专门做容器安全的公司有时间切入这个市场。

关于IT和OT的结合,这个场景会更多,漏洞作为安全领域的皇冠,OT安全首当其冲的就是考虑这个问题。OT包含的五大场景:智慧城市、智慧家庭、智慧医疗、智慧交通和智慧工业。智慧城市可以以摄像头举例,现在国内的雪亮工程都是当地极大的工程,但是很少考虑摄像头终端设备的漏洞情况和安全性问题。智慧医疗很多专业的医疗设备都会联网,同时安全性问题也就暴漏出来,国外有些安全厂商已经在关注这个特定的行业。智慧交通在车联网上在车内以及TBOX都有一些厂商切人,漏洞这块还是以挖掘为主,漏洞管理这块还没有成型。智慧工业的场景是常提到的工控安全,这个领域已经有相关的国内厂商在做,但是大部分都还是传统的IT思路。OT领域的漏洞管理还是比较初级的市场,需要更多的市场培育和关注。

三、新的产品类型

这里不提及Web漏洞扫描和配置安全扫描的产品类型,重点提到威胁漏洞管理(TVM)和泄漏攻击模拟(BAS)两种产品。TVM是指威胁和漏洞管理,这种产品本身可以不用做相关的漏洞扫描,这是将漏洞和威胁信息结合归并,可以理解为漏洞领域的SoC。TVM可以使用漏洞扫描数据并利用威胁情报(TI)、攻击的漏洞以及内部资产的重要性,实现让组织更好地理解漏洞风险,防止泄漏产生。同时也可以跟IPDS和WAF类产品对接可以作为漏洞处理的方式可以迅速响应。代表厂商有Kenna Security 和NopSec,同时这两家厂商对于漏洞的评估也比传统的漏洞扫描厂商更有针对性,更基于威胁和风险本身。

BAS是以攻击者视角来看待漏洞。会自动化模拟攻击行为来利用漏洞,更真实,也更具实际意义。BAS会将漏洞识别和漏洞利用合二为一,让客户感觉更真实有效。代表厂商有AttackIQ和Core Security。AttackIQ基于MITRE的ATT&CK的矩阵模型进行的攻击模型来设计的产品更切实落地,基本实现方式是安装agent、运行测试脚本和场景模拟,最后查看结果。形式上看起来跟传统的漏洞扫描没有区别,就是角度上区别比较大,更贴近于实际的攻击场景。

总结

本文主要针对于目前漏洞管理的一些新要求提出了一些见解。首先是介绍了漏洞管理的流程以及成熟度;其次,详细介绍了漏洞扫描的相关原理,对于大部分产品都适用;最后重点引出了漏洞管理遇到的新的问题,包括:漏洞评估方式改进、资产类型的扩展以及新的产品类型的提及。漏洞评估方式的改进是最重要需要注意的地方,也是目前漏洞管理里面的痛点所在,如果没有基于风险和威胁的角度,修复漏洞的优先级就无法做判断,漏洞管理就会走入程式化,效果可能很难得到最好的体现。资产类型的扩充对于目前的漏洞管理方式提出了新的挑战尤其是在云计算、容器技术和IoT相关的场景下,需要思考资产的特殊性来进行漏洞管理的适配。新的产品类型其实也是基于上述提到的产品变化衍生出来的产品,包括TVM和BAS类型的产品,漏洞扫描并不是没有变化,只不过向着更有安全价值的方向在演进。

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页