- A+
一、前言
在大企业中，安全漏洞的全生命周期管理是难以落地实施的一项工作。然而，这项工作的重要性毋庸置疑。
我们在漏洞管理上尝试过使用一些优秀的开源的漏洞管理平台，如[洞察](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原创奖励计划，未经许可禁止转载。
