*本文中涉及到的相关漏洞已报送厂商并得到修复,本文仅限技术研究与讨论,严禁用于非法用途,否则产生的一切后果自行承担。
一、前言
在大企业中,安全漏洞的全生命周期管理是难以落地实施的一项工作。然而,这项工作的重要性毋庸置疑。
我们在漏洞管理上尝试过使用一些优秀的开源的漏洞管理平台,如[洞察](https://github.com/creditease-sec/insight)、[SeMF](https://gitee.com/gy071089/SecurityManageFramwork)等。当漏洞碰上企业文化,开源平台就显得有些各种水土不服。就个人看法,用开源平台管理漏洞必须二次开发,要么安全从0开始,自己开发。我们选择了后者。以下内容主要是介绍漏洞管理平台的设计思路及实现,希望能帮助到漏洞管理平台研发或者二次开发的朋友,少走弯路。
二、漏洞生命周期
漏洞的生命周期概括为3个环节,每个环节完成一定的动作后,转换到下一个环节或者结束:
漏洞发现
漏洞跟踪
漏洞暂缓
漏洞发现
漏洞发现这个环节,主要的内容是自动化导入漏洞扫描工具的结果。
导入结果时要主要几个点:
1. 选择扫描工具时,必须确定扫描工具接口是否满足漏洞扫描、漏洞结果导入的需求。
2. 自定义漏洞的5元组,如漏洞名称、漏洞目标、漏洞类型(划重点)、漏洞状态、漏洞来源等。
3. 漏洞类型的维度要根据企业内部情况而定,这个字段很可能影响后续通知谁去修复。
4. 对扫描目标要做区分,如扫描的IP是属于生产还是测试,或者是终端(可以添加相应的字段去记录,这将影响漏洞的修复及时率和重要程度)。
当完成漏洞工具扫描结果导入后,我们要制定规则,什么样的漏洞是需要我们跟进处理的,什么样的漏洞是可以忽略的。将需要跟进处理的漏洞丢入下一个环节:漏洞跟踪。
漏洞跟踪
漏洞跟踪这个环节包括:漏洞跟进、漏洞回归测试、漏洞修复。
这个环节往往是企业落地漏洞管理最难之处。影响的因素有很多,比如我们遇到的:
领导赋能不足,导致研发人员不积极影响;
企业资产信息不全,很多漏洞并不知道是谁负责。
我觉得既然要建漏洞管理平台,一定要提前思考如何推行,如何让参与人员更方便的使用,减小可预见的阻力。
最终我们借助了企业项目三剑客之Jira以及企业的CMDB,完成了漏洞跟踪这个环节的任务。
当漏洞修复,该漏洞的生命周期就结束了,当然这个美好的愿景往往不会出现。
漏洞生命周期中出现最多的是无法彻底修复,这个情况的原因会有很多很多,如供应商不见了、该系统准备下线了、该系统很重要框架不敢动、该系统过xx月会升级等等。出现这种情况该怎么办?不管了吗?于是我们设计多了一个环节漏洞暂缓,这个环节专门处理这种无法根治的情况。
漏洞暂缓
漏洞暂缓这个环节,将各种情况的漏洞及漏洞处理措施记录在案,后续若有相应漏洞的勒索或者挖矿等病毒,可“借力”推动修复。
目前对于暂缓漏洞的处理措施主要是通过安全设备做策略限制,将风险降低。对于计划升级或计划下线的漏洞除了策略限制外,添加通知提醒,若在计划时间未升级或下线,漏洞需要跟进处理最终到修复阶段。
三、过程坑点
整个漏洞管理平台搭建的过程中,有不少坑(来自于需求跟不上变化,需求不满足企业实际情况),往往牵一发而动全身,重写平台好几次。
讲讲坑点:
1. 确定应用系统或主机的安全负责人的责任范围。如负责人是负责应用系统的所有组件,还是仅仅是某个模块,是否包括中间件、数据库、操作系统等;
2. 选择适合的企业内部的工单系统,如OA、Jira或者其他。只有保证参与人员都拥有账号才能最大的减小阻力。(如果你的设计是参与人员登录你研发的漏洞平台处理漏洞,开账号是个难题,要考虑的情况会复杂非常多,如供应商、外包人员怎么处理。)
3. 建议使用ELK存储吧,可以少做很多报表的工作。
四、结束语
安全不是让业务更高效的事情,而是让业务更复杂的一个事情。
最后想说全篇没code,上个Kibana测试环境效果图。
*本文作者:bigface,本文属 FreeBuf原创奖励计划,未经许可禁止转载。
来源:freebuf.com 2019-01-03 08:30:28 by: bigface
请登录后发表评论
注册