甲方企业安全痛点之漏洞管理

2019-01-03 110773人围观 ,发现 12 个不明物体 企业安全

一、前言

在大企业中,安全漏洞的全生命周期管理是难以落地实施的一项工作。然而,这项工作的重要性毋庸置疑。

我们在漏洞管理上尝试过使用一些优秀的开源的漏洞管理平台,如[洞察](https://github.com/creditease-sec/insight)、[SeMF](https://gitee.com/gy071089/SecurityManageFramwork)等。当漏洞碰上企业文化,开源平台就显得有些各种水土不服。就个人看法,用开源平台管理漏洞必须二次开发,要么安全从0开始,自己开发。我们选择了后者。以下内容主要是介绍漏洞管理平台的设计思路及实现,希望能帮助到漏洞管理平台研发或者二次开发的朋友,少走弯路。

二、漏洞生命周期

漏洞的生命周期概括为3个环节,每个环节完成一定的动作后,转换到下一个环节或者结束:

漏洞发现

漏洞跟踪

漏洞暂缓

漏洞发现

漏洞发现这个环节,主要的内容是自动化导入漏洞扫描工具的结果。

漏洞发现.png

导入结果时要主要几个点:

1.  选择扫描工具时,必须确定扫描工具接口是否满足漏洞扫描、漏洞结果导入的需求。

2. 自定义漏洞的5元组,如漏洞名称、漏洞目标、漏洞类型(划重点)、漏洞状态、漏洞来源等。

3. 漏洞类型的维度要根据企业内部情况而定,这个字段很可能影响后续通知谁去修复。

4. 对扫描目标要做区分,如扫描的IP是属于生产还是测试,或者是终端(可以添加相应的字段去记录,这将影响漏洞的修复及时率和重要程度)。

当完成漏洞工具扫描结果导入后,我们要制定规则,什么样的漏洞是需要我们跟进处理的,什么样的漏洞是可以忽略的。将需要跟进处理的漏洞丢入下一个环节:漏洞跟踪。

漏洞跟踪

漏洞跟踪这个环节包括:漏洞跟进、漏洞回归测试、漏洞修复。

这个环节往往是企业落地漏洞管理最难之处。影响的因素有很多,比如我们遇到的:

领导赋能不足,导致研发人员不积极影响;

企业资产信息不全,很多漏洞并不知道是谁负责。

我觉得既然要建漏洞管理平台,一定要提前思考如何推行,如何让参与人员更方便的使用,减小可预见的阻力。

最终我们借助了企业项目三剑客之Jira以及企业的CMDB,完成了漏洞跟踪这个环节的任务。

漏洞跟踪.png

当漏洞修复,该漏洞的生命周期就结束了,当然这个美好的愿景往往不会出现。

漏洞生命周期中出现最多的是无法彻底修复,这个情况的原因会有很多很多,如供应商不见了、该系统准备下线了、该系统很重要框架不敢动、该系统过xx月会升级等等。出现这种情况该怎么办?不管了吗?于是我们设计多了一个环节漏洞暂缓,这个环节专门处理这种无法根治的情况。

漏洞暂缓

漏洞暂缓这个环节,将各种情况的漏洞及漏洞处理措施记录在案,后续若有相应漏洞的勒索或者挖矿等病毒,可“借力”推动修复。

漏洞暂缓.png

目前对于暂缓漏洞的处理措施主要是通过安全设备做策略限制,将风险降低。对于计划升级或计划下线的漏洞除了策略限制外,添加通知提醒,若在计划时间未升级或下线,漏洞需要跟进处理最终到修复阶段。

三、过程坑点

整个漏洞管理平台搭建的过程中,有不少坑(来自于需求跟不上变化,需求不满足企业实际情况),往往牵一发而动全身,重写平台好几次。

讲讲坑点:

1. 确定应用系统或主机的安全负责人的责任范围。如负责人是负责应用系统的所有组件,还是仅仅是某个模块,是否包括中间件、数据库、操作系统等;

2. 选择适合的企业内部的工单系统,如OA、Jira或者其他。只有保证参与人员都拥有账号才能最大的减小阻力。(如果你的设计是参与人员登录你研发的漏洞平台处理漏洞,开账号是个难题,要考虑的情况会复杂非常多,如供应商、外包人员怎么处理。)

3. 建议使用ELK存储吧,可以少做很多报表的工作。

四、结束语

安全不是让业务更高效的事情,而是让业务更复杂的一个事情。

最后想说全篇没code,上个Kibana测试环境效果图。

结束.png

*本文作者:bigface,本文属 FreeBuf原创奖励计划,未经许可禁止转载。

发表评论

已有 12 条评论

取消
Loading...
css.php