0xBA 漏洞管理从入坑到逃离

0x00 前言:

突然发现已经有N个月没更新自己的专栏了,不是偷懒也不是忘了,是最近真的忙,最近在忙的内容呢看标题也就明白了,自打接手了这部分工作的其中一部分工作之后,发现真的有些想法和思路有点tu样tu simple,尤其是面对数据、系统甚至是人员上面各种各样的问题,简直是无法搞,所以下面算是干这件事儿的一部分总结吧,当然涉及到不能说的各位也就别想打听了。


0x01 入坑前的准备:

首先我们需要阐明一下这里说的漏洞的定义,我们这里的漏洞仅包含来自于软件供应链层面上的安全漏洞,不包括业务系统、从零开始的自研基础组件等来自于业务和基础设施平台层面的漏洞。

在解决这部分漏洞的问题的时候首先应该问自己四个问题(其实在干一件事儿之前都应该问自己这四个问题):

(1)我们在执行漏洞管理这部分的时候针对的目标是什么,需要达到的预期效果是什么

(2)针对这一部分,我们是否有足够的方法去支撑现有的设计思路

(3)产出是什么,收益在哪里,如何评价这件事情干的好坏

(4)如何运营,运营数据如何积累

想清楚以上的问题实际上就可以开干了,但是绝大多数人干活之前都不会想清楚这些问题,不然也不会做着做着就觉得自己入坑了。


0x02 挖坑掘土:

对于漏洞这一部分的生命周期管理,实际上是一个很大的话题,漏洞也分很多种类,所以在划分漏洞的时候我们需要对漏洞分类,在接手的时候,首先需要考虑清楚以下问题:

(1)我们需要管理的漏洞包含存量漏洞和增量漏洞,存量漏洞信息如何收集,增量漏洞信息如何收集?

(2)如何确定这些漏洞是否值得我们修复,ROI是否划得来

(3)漏洞的修复节奏如何确定划分

(4)如何验证漏洞是真的修复完毕了

对于第一个问题而言,存量漏洞往往都是集中在安全体系没有搭建起来之前,如何判断一个安全体系是否达到够用的标准有很多,但是从漏洞管理的角度上出发,核心的数据主要是资产信息以及对应负责人与现有的漏洞存量数据这两部分。具体数据字段的话,各家和各家的都不一样。对于增量漏洞而言,其实就是每天披露的漏洞,当然我们不一定需要这么全的信息(关于存量漏洞这一部分,后面还会有坑),这部分数据,往往依赖于所谓的态势感知和威胁情报团队。

对于第二个问题,这个问题需要涉及到对增量与存量漏洞的评估,评估因素大的方向上说其实就是漏洞的危害和是否有资产受影响,至于如何评估这一部分,相信绝大多数公司都有专业的评估应急团队,让专业的人做专业的事儿是没错的。对于ROI,对于高危漏洞和在野漏洞,ROI绝对是很高的,但是对于一些无关痛痒的漏洞,则见仁见智。

对于第三个问题,虽然所有人都在喊高危漏洞不过夜,但是这部分实际上不过夜的我相信还有很多,而且数量级绝对不低,笔者曾经见过一个very very厉害的漏洞放内网几个月没有修完的。漏洞的修复节奏仍然还是专业的人做专业的事儿,放心的交给评估应急团队。

对于第四个问题,很血腥的例子就是前几天的CVE-2019-0708,微软的补丁打了没有生效的case不仅有,而且还很多,这个时候,蓝军团队就派上了用场。

由于这件事儿各有各的套路,所以今天这篇文章我们不会涉及到漏洞催修和反向验证这一部分,我们会讨论如何尽可能多的为这两个团队提供高可用的数据和信息。


0x03 跳坑:

我们刚刚说过了,对于这一部分工作,核心依赖的两份数据一份是企业的资产相关数据,另一部分是关于漏洞的信息,对于资产相关的数据,EDR、HIDS、ITMS这些系统可以帮我们很好的采集这些软件信息、版本、使用情况、资产负责人、对应的业务系统等相关的信息,只要追求前面这些系统的覆盖度和采集情况,就大概心里有数了。

而对于漏洞这部分信息,主要是依赖于所谓的CVE数据库,这部分就一个字:爬,这部分数据就大概差不多了,当然我说的存量,至于增量的话,只需要每天拖一遍就行了,大概13w条数据,拖完了去更新就OK了,but这里面会有以下几个大坑:

(1)不是所有需要修复的漏洞都有CVE编号(CVE官方拒收或者当feature处理了)

(2)不是所有有CVE编号的漏洞都能在Mitre的数据库里面获取到(如当天发布的微软安全公告在对应的mitre数据库里面是查不到的)

(3)CVE数据库里面的数据不是一成不变的,也是。。。。会更新的(case:思科某漏洞在mitre数据库和官方安全公告的cvss相关分数和数据不一致,一个5.x一个8.x)

(4)永远不要低估乙方大佬及厂商的PR能力(如脏牛、麦哲伦等带名字的漏洞)

(5)关心黑客的心理情况(上周去上海参加Bluehat的时候听小道消息说SandboxEscaper小姐姐就是因为失恋了连发4个0day。。。)

对于这部分,还是一个字,爬,只不过爬的内容增加了很多,但是我们仍然需要对漏洞信息进行梯度和置信度划分,具体划分如下:

MITRE CVE数据库-》安全软件官方安全公告-》安全服务商官方博客和微信-》社交网络

这个时候我们基本上按照梯度就可以基本上覆盖到了,只剩下爬取频率和递送这一部分的数据。当然这些数据也是需要入库的,所以在递送的时候也要注意一下以下的问题:

(1)漏洞影响范围和危害的变化

(2)资产上下线的情况(资产上线但是仍然存在已知漏洞仍属于增量漏洞,虽然说这一部分是安全基线和上线流程的锅)

至于乙方大佬和厂商的PR这种,送大家一句话:应急依靠朋友圈,虽然没技术含量但是真的有点用。至于黑客心情。。。这事儿真没办法。

在漏洞信息收集完毕之后,另一个大坑是漏洞与资产的信息交叉,这一部分,其实MITRE官方还有一个CPE用来枚举各种软件、硬件、系统和版本,能覆盖比较多的场景。


0x04 出坑。。。不好意思出不来了:

这一部分是个长期运营的工作,所以出坑是不可能的,尝试利用自动化工具和平台来解决这一部分工作吧。另外,该人肉还是人肉,别因为面子不好意思说自己不是人肉干的。


0x05 总结

内容不重要,其实角色转换了一年之后,学到的最有用的东西就是如何跟boss交流工作,虽然现在做的还是不够好,但是基本的思路算是学到了,后面的话继续努力吧。

理性打个广告:有想从事甲方威胁情报和态势感知体系建设的请私聊,欢迎来我这里,另外我们也招收其他安全方面的人才,参考:anquanke.com/post/id/15

来这里你将会有机会见到:

(1)百万级IDC入侵检测的大佬及对应的系统

(2)亿级QPS的WAF

(3)PB级流量的NIDS大佬

(4)还有很多。。。。

编辑于 2019-06-08

文章被以下专栏收录