微慑信息网

漏洞治理平台的设计与实现

几个月前笔者曾经梳理过技术方面的漏洞处理的心得,经过几个月的实践和迭代,我们在公司内推出了漏洞治理的概念,并进行实践中。本文就漏洞治理体系的设计和实现的各个环节做个详细的阐述。

适用场景:

业务系统逻辑复杂,部门间关系较复杂,对网络安全敏感性高的环境。(当然内部环境简单的企业也可以采用,但会感觉方案太重)

整体架构:

整体架构从资产发现开始,第二个阶段是漏洞扫描,第三个阶段是漏洞处理,第四个阶段是数据分析和展示。我们逐个展开一下:

一、资产发现


对于安全和运维工作来讲,资产是一切的基础,其重要性怎么强调都不过分。但大部分企业资产管理工作都不是安全部门的职责,如果运维部门能提供准确、全面的资产信息,那是非常幸福的事,此段可以直接略过。但从笔者了解的情况看,很多企业这方面的工作都或多或少的有所欠缺尤其是经历了快速增长期和漫长建设期的企业更是如此。

1.1 IP&服务资产

为了安全检查的全面性,安全部门的资产发现至少要确认IP、端口和服务,至于业务线和负责人的信息可以交给相关资产管理部门来完善。具体方法如下:

技术选型:经过多方面考虑我们还是选择功能非常成熟的nmap,通过调度程序启动多个nmap进程,并将任务分解后下发给不同nmap;

使用方法:

①第一步还是探活,我们用-sn完成探活,这里需要说明一下,很多文章讲-sn的时候都说仅仅是ICMP探测,但通过抓包我们发现实际策略是ICMP+80+443。

为了增加准确度,我们进一步将nmap源码中探活策略修改为更多常用端口(如:增加22、3389、3306等),具体端口信息可以根据企业实际情况酌情处理,但不要增加太多,以免影响效率。

②探活之后就是全端口和服务发现,这部分就用nmap原生功能就没问题。

IP&服务下线策略,实际扫描中我们发现nmap会由于各种原因导致漏报,所以不能在新一轮扫描没发现某个服务就直接判断该服务失效。我们的策略是连续三次扫描中都没发现该服务才会将该服务判定为下线。

1.2 url资产

相对于IP资产,url资产是比较麻烦的,单独用一种手段很难完全满足需求。我们基本上通过两种手段:爬虫和流量解析,稍稍展开一下。

①爬虫:我们是通过改造幽灵蛛(https://github.com/henrylee2cn/pholcus)实现的,目前效率还可以接受,一台sever限制一个主域爬15层,2个小时内完成140万个链接的任务。

②流量解析:爬虫的诸多局限性不用多说,所以我们将访问流量解析出的url与url资产列表比对,有新增的加入到资产表中。另一个角度说,如果没有请求,就算这个url存在我们也不必要去检查漏洞,因为根本没人访问(包括黑客)。但流量解析涉及到每秒几十万用户请求的情况下如何快速去重,我们还在实验中。

二、漏洞发现


有了资产信息,下一步就是漏洞发现了,漏洞发现我们通过三类逻辑实现:资产信息匹配,商业扫描器,自主开发扫描器。

2.1 资产信息匹配

这类方法主要适用于0day漏洞爆发,在没有验证脚本的情况下,通过版本信息来判断漏洞影响范围。这个比较好理解,就是前端页面设计的时候注意搜索条件的填写就好。这类方法检查漏洞是有一定缺陷的,所以我们还要用扫描器完成外部扫描工作。

2.2 商业扫描器

商业扫描器大家都比较熟悉,优势是技术成熟、漏洞信息全面、部署简单;但缺点也很明显:

  • 扫描速度很慢,我们的经验是约6000台sever需要三周
  • 大量漏洞信息需要忽略,导致整理报告时间很长
  • 漏洞更新需要依赖厂商,无法自定义

2.3 自主开发扫描器

为了解决商业扫描器的上述问题,我们设计并开发了自己的扫描工具,这里简述一下实际运行逻辑,具体的实现方法暂不过多展开,我会用单独一篇文章阐述。

核心扫描组件:我们分别用java、python和Go做了分布式框架,目前看Go的效果最佳,但Python的适配性最好。基本方法是将资产信息拆分成以服务为单位的条目(如:一个IP开了三个服务,就是三条资产信息),存在Redis中,扫描进程启动时会先加载POC库,在逐条获取Redis中的资产信息,完成匹配后开始扫描工作。需要注意的是这类高并发扫描逻辑要考虑被扫描资产的承载能力,尽量把压力分散到不同被扫描设备上,分散方法有很多,比如将POC和资产一一对应后随机进入扫描任务,或者以POC为核心逻辑,POC1下所有IP扫描完成后再扫描POC2等等,总之不要盯着一个IP玩命扫就是了。

这里可以优化的点是:由于我们的扫描节点和控制节点是分开的,所以获取资产信息的时候可以同时获取一组,避免网络延时对效率的影响,这还要看具体数据。

漏洞扫描组件与资产发现组件的配合:我们打破了传统扫描器中资产扫描和漏扫串行的方式,将资产扫描和漏扫异步进行,可以随意调整,基于此我们设计了如下逻辑:

① 资产扫描后针对新增资产进行漏洞扫描,比较特殊的情况是:系统第一次运行所有资产都是新增的,所以第一次漏扫是全网扫描。之后每次资产扫描后,只针对新增资产进行漏扫。重点来了,这个逻辑将循环执行,我们起名叫“永不停歇模式”。

② 根据资产列表中的资产信息,做定期的全资产扫描。这个扫描周期我们设定的是三天。

基本逻辑说完了,解释一下这么做的理由:按经验来说漏洞的高发区域就是新增的资产和服务,所以我们将资产发现和新增资产漏扫的工作执行了“永不停歇模式”。资产信息不变不代表漏洞情况不变,但属于较低概率事件,所以进行周期扫描。这么做的另外一个好处是,执行POC会产生很多系统日志,虽然我们写了一些过滤脚本,但也有很多过滤不完全的系统还是会产生大量垃圾日志。但资产扫描的情况就会好很多,所以周期执行资产扫描,定期执行全网漏洞扫描可以有效减少垃圾日志的产生。

三、漏洞处理


我们日常安全管理的一个很重要的工作就是督促整改,但从笔者了解的情况看,很多企业都遇到过修复漏洞工作推进十分困难的情况,这也直接导致了安全团队与运维和开发团队的对抗情绪。

笔者团队一直致力于让非安全部门更主动的修改漏洞,我们在去年(2017)根据实际情况建设了“漏洞管理平台”,主要实现如下三个层面的能力:

① 便捷:任何产品级系统便捷性都是最基础、最重要的事。所以,驱动业务使用安全部门“平台”的最低要求就是–不能比处理邮件麻烦。这个要点就是前端页面设计和通知手段的多样化。

② 驱动:比便捷更稳妥的方式是让系统有驱动力,驱动力的来源是领导们的关注,这个层面我们是通过数据分析和展示系统给领导看来解决驱动力的问题。

③ 主动:驱动毕竟有一定强制的成分在,所以比驱动更高的一个层次是让运维和开发主动来看,这要求“平台”的内容对运维和开发有吸引力。这个层面的问题我们也在实验中,比如积分制,配合一些精神和物质的奖励等。

具体实现逻辑如下:

上面的逻辑图看起来复杂,简化来说有如下三个阶段,就可以实现基础能力:

① 漏洞入库

商业扫描器扫描结果有人工筛选后分别进入两个库:一是流转库,走漏洞修复流程,下面会说;二是“低危库”,我们私下也叫垃圾库。商业扫描器的扫描结果会有大量这类的信息,是我们认为不需要修复的漏洞信息。那为什么我们还要存呢?这是个很实际的问题,很多企业应该都会遇到过上级检查单位下发的漏洞整改通知,这些漏洞很多都是不必要整改的,但报告发到领导手上就会比较紧张。所以“低危库”就是告诉领导:我们发现过,但是经过判断不用整改。

自研扫描器的结果由于是自己写(或搜集)的POC的检测结果,这里没有低危数据,所以自研扫描器的结果直接入流转库。

② 漏洞流转

漏洞流转的方式和目前大部分开源的漏洞管理系统流程非常相似,都是对漏洞做全生命周期管理,基本设计到5个关键点的把控:发现、通知、整改、复查、复发。前面四个阶段都好理解,这里面最难定位的就是复发,我们也一直在研究复发的定义、定位和处理方式。目前比较容易的是弱密码和一些系统漏洞,web漏洞复发定位相对难一些。另外一个小亮点是“自动复查”,一旦漏洞状态变成“已整改待复查”后,会出发扫描器自动复查。除非恰巧碰到扫描队列里有任务,正常情况下单IP、单服务、单POC的执行速度是非常快的。

③ 流程数据存储

这些数据主要用于后面的分析及展示,建议能想到的数据都留存下来,数据量不会很大。数据应用主要通过下一部分来介绍。

四、数据分析及展示


我们做数据分析的最初诉求是基于业务做狭义的风险评估,以此督促业务整改漏洞。但现在看来,这部分的工作至少还有两方面的用途:一是体现安全部门工作量;二是积累相关数据为必将到来的机器学习做数据积累。数据展示方面的内容不太具备通用性,我们基本通过如下三个维度做数据分析:

① 漏洞概况分析,包括一些比较通用的统计,如:各类漏洞的占比,高危漏洞的业务分布,新增漏洞趋势等;

② 督促性分析,以业务为单位的未修复漏洞超时时间总和排名,最近一个月新增漏洞整改率排名,漏洞高危漏洞平均修复时间排名等;

③ 内部(外包)团队工作效果评估,因为所有漏洞信息(包括无需整改的漏洞)都在系统中存在,所以一旦有外部(包括上级单位,兄弟单位,SRC等)提交的漏洞信息,可以马上有针对性的对团队能力进行评估。

因为笔者的开发团队没有UI设计能力,所以上述的可视化呈现都是以饼图和柱状图的形势呈现,比较丑,就不截图了

五、展望未来


目前笔者团队已经基本完成上述平台的设计的所有功能,但我们认为这仅仅是个开始,漏洞治理工作还有很多事情要做,未来我们希望在下面几个层面进一步深入:

  • 特殊系统漏洞目前还无法扫描:一些专业设备不能识别,尤其是一些阉割版的Linux系统。笔者遇到过不止一次遇到接收畸形包就自杀的设备。针对这类设备我们需要进一步的识别,识别出来之后只能先忽略,专用设备的漏洞实在无力去跟踪,只能寄希望于厂商。
  • 自研扫描器的POC跟踪:自主研发这件事说起来跟牛X,但具体落地会面临很多问题。POC实时跟踪对我们来说就是一个难点,我们目前只能实现对开放POC的改写和嵌入,目前还没有根据利用代码形成POC的能力。我们希望日后一方面加强团队能力,另一方面可以通过一些商业合作补充这方面的不足。
  • 从机器漏扫到机器渗透:提到机器渗透目前我们要做的并不是要替代所有渗透测试工作,只是能说清楚逻辑,能通过简单代码实现的渗透工作一点一点的积累,从而替代一些比较初级的渗透工作,笔者认为迈出这一步跟重要。
  • 从机器渗透到机器学习渗透:这里没有用“智能渗透”或“AI渗透”的名字,但意思是一样的。这是从量变到质变的过程,现在已经有商业公司实现了产品化(但不太了解效果)。这个升华的门槛在于现在是AI大火的时代,人才紧缺。另外就是如何将渗透逻辑模型化在不同决策点做积累不同数据进行不同训练,这也要很专业的人才才能搞定。所以目前笔者团队对此暂时只能想象,期待有大神级的技术或产品出现。
  • 自动修复漏洞:这也是我们想象的一部分,虽然大量漏洞都有修复建议,但自动修复这件事还是有太多问题存在,但如果我们把一些能工具化的操作都固化下来,配合一些自动化运维的手段是否可以实现一些这方面的能力呢?我们还在思考。不过最简单的情况,发现弱密码后自动改成强壮的密码,再发给业务,应该是可行的,不过我们没做过。

写在最后

这篇文章准备的时间确实长了点,但没想到会写这么长。能看到这里的小伙伴们辛苦了!!对漏洞做这么多工作主要是日常痛点太多,才不得不花费精力搞一套系统,希望能一劳永逸。这套系统设计的根本理念,就是想把比较复杂和繁杂的工作放到后台,能工具化的全面工具化。让不懂安全,甚至不懂技术的人能方便的处理漏洞。我们会朝着这个方向继续努力,希望得到更多大神支持,对这方面工作有兴趣的小伙伴欢迎关注我的公众号或加我微信(微信号:huangle0914)深入探讨。

本文标题:漏洞治理平台的设计与实现
本文链接:
(转载请附上本文链接)
http://vulsee.com/archives/vulsee_2018/0911_6693.html
转载请附本站链接,未经允许不得转载,,谢谢:微慑信息网-VulSee.com » 漏洞治理平台的设计与实现
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

微慑信息网 专注工匠精神

访问我们联系我们