漏洞管理已经成为安全运营中较为成熟的子领域，可以说一切安全运营活动的开始几乎都是从漏洞管理开始的，是安全工作中的基础也是重要组成部分
0x01 背景：漏洞归一、闭环运行
1.1 安全背景
如今年（2021）七月 Gartner 发布《Hype Cycle for Security Operations, 2021》（2021 安全运营技术成熟度曲线），漏洞管理已经成为安全运营中较为成熟的子领域，可以说一切安全运营活动的开始几乎都是从漏洞管理开始的，是安全工作中的基础也是重要组成部分。
从合规方面，今年工业和信息化部、国家互联网信息办公室、公安部发布的《网络产品安全漏洞管理规定》也对网络产品提供者和网络运营者提出了明确的要求，企业需要扩充原有合规清单来满足监管要求。（附：官方解读）
1.2 项目需求
事项：漏洞生命周期管理平台
内容：
- 对比开源漏洞系统关注漏洞录入、统计、流转、复测、关闭等状态
- 完成搭建漏洞生命周期管理平台
0x02 漏洞管理实践
2.1 漏洞管理的三层架构
2.2 底层安全基建
工欲善其事必先利其器，漏洞管理也不例外，一个好用的安全管理平台，能减少不少重复人力劳动，提高安全运营效率；另一方面，要想将发现的安全问题及时给到业务侧修复满足安全 SLA，资产管理也必不可少。
以上两个主要部分就像是漏洞管理的基座。
2.2.1 安全管理平台
为什么不称漏洞管理平台而是安全管理平台，因为漏洞管理是安全运营工作的一部分，一个整合了安全运营各工作环节的集中处置平台更利于提高工作效率。
安全管理平台通常具备如下功能模块：
全量报警管理：来自外部报告（例如 SRC、CNNVD 等其他外部平台报送）、内部安全能力发现，如扫描器、HIDS、流量监测、蜜罐等产生的报警。每个报警源模块低耦合、可插拔，易于扩展。
支持漏洞全生命周期管理：来自众多渠道的安全报警在经过自动/人工研判分析后，需要对真正需要关注的漏洞进行管理，通常是以工单等自动化流程形式，将安全问题分发至业务线，包含了漏洞分发、业务侧修复、修复后安全侧确认、直至关闭/打回工单等一系列操作。
漏洞知识库：包含常规漏洞的漏洞描述、风险/危害描述、修复方案等，一方面是减少安全侧重复填写这些信息、另一方面是赋能业务侧。
权限管理：安全管理平台通常具有诸多功能模块，因此做好权限的分类分级是十分必要的，可以是基于功能模块的、或是基于角色的，可以参考 RBAC 模型。
和其他平台/流程的打通：主要用于安全卡位和数据同步需求的场景，例如研发需求管理、域名/服务上线、上线前提测等。
支持开放 API：基于提高安全效率考虑，可以开放第三方 API 给安全内部甚至业务侧，例如批量处理场景、以及和其他（安全）平台联动场景等。
数据分析和展示功能：不管是安全侧还是业务侧都有数据分析的诉求。
对于安全侧，定期的数据分析和统计是必要的，常见的例如 dashbord 页面，实时展示不同统计维度、多种漏洞数据情况，同时漏洞运营的监控指标也可以在这个页面实时显示，便于运营同学及时发现问题。
为什么在业务侧也需要做数据分析，一方面是业务真的有这种诉求（这是安全意识较高的业务），他们希望了解每季度甚至每月对体系内部的安全风险情况；另一方面从安全的角度，让业务侧能看见这些“触目惊心”的漏洞数据，也是警示和提醒。
2.2.2 资产管理
安全问题的处理自然离不开业务部门的参与，安全漏洞更需要细粒度到资产属主、定位到人，因此需要具备公司各类资产的全量接口，如：域名、IP、主机名、容器名、实例名等，以及各类资产之间的映射关系查询，以确保安全问题定位的准确性和实效性。
除了上述提到的常见类型资产，指纹库、第三方组件库的建立也是很必要的，尤其是当 fastjson、struts 2 这类安全漏洞爆发时，如何在快速应急也是对安全的考验。
由于资产的动态性，内部梳理是一部分，也需要外部视角的资产探测来做补充，也正是由于资产动态变化这个特性，这往往也是实际工作中的难点和痛点。
2.3 流程&机制
在平台建设的基础上，如何让整个系统良好的运转起来，是第二个部分——安全流程与协同机制需要关注的。
2.3.1 确保闭环
发现问题不是目的，如何解决问题降低安全风险才是最终目的。忽略漏洞修复结果的追踪，缺少标准化的流程来对漏洞的修复状态进行持续的追踪管理，将导致修复周期长、无法进行闭环跟踪。
对于高、中、低不同等级的漏洞有不同的修复优先级和时效性要求，安全平台以工单形式自动化将问题下发至业务，通过邮件、IM、短信等通知渠道将工单状态的变更实时同步至业务和安全，若在规定时间内未修复还会将安全问题逐级上升至业务侧管理角色，督促整改，确保安全问题处置的时效性保证闭环率。此外，定期的数据统计和分析也是必不可少的，可以发现流程和机制上的 gap 点，及时改进。
2.3.2 协同机制
由于双方视角和安全认知不同，如何让业务方重视安全问题、配合安全及时修复也是一个难题，“从上至下”的推进思路一般来讲会比“至下而上”更加事半功倍。
首先是安全制度层面，明确各类资产、虚拟资源的安全职责，出了安全问题谁来担责（安全制度一定要经过高层 review 确认和背书，具备权威性）。
明确接口人机制，在每个业务体系设立安全负责人、安全接口人角色（也需要在制度层面达成一致），有职责和义务配合安全，牵头推进该业务体系安全问题的处理。
OKR 协同机制，将安全任务拆解至业务的 OKR 里（前提也是需要沟通达成一致），形成“契约”后让业务能主动推进。
对于频繁出现问题的业务线，可以建立安全协作专项，专注于某类风险集中治理和收敛。
2.4 精细化运营
2.4.1 安全 review
针对外部报告的各种漏洞、情报，甚至是一次突发的应急事件、红蓝对抗等，安全需要对内部各能力线进行审视，内部安全能力是否有覆盖、是否该覆盖、是否能覆盖、资产是否有遗漏、安全能力是否存在 gap 点、安全流程是否存在改进空间等，需要不断优化迭代内部的安全能力，不断提高纵深防御水平。
2.4.2 风险分析
漏洞管理起源于漏洞，但绝不止于漏洞。从一个安全漏洞可以深挖的东西很多，如：业务逻辑业务形态是怎样的，他们为什么会出现这类问题，在现有安全需求下出现这类问题是否合理，安全能力还能做什么，发生这个问题的根因是什么、以及背后潜在的可能风险面等等，可以更加发散的来看。
基于以上两点，举个简单的例子：
比如业务侧被发现存在一个 fastjson 某个版本的 RCE 漏洞并且被 getsehll 了，从这个问题知道业务侧代码大概率是使用 JAVA 的，那么现在安全能力是否有定期的在进行扫描，是否有被扫描到，如果有被提前扫描到，那么业务侧为什么当时没有修复，是漏洞信息未触达业务还是业务不会修、不能修；
如果内部没有提前扫描出来，那么安全就需要反思排查了，是组件库/指纹库/POC 没覆盖、不准确还是压根这台机器就不在我们的资产库里；
除了扫描的问题，被反弹 shell 了，websehll 检测、HIDS 是否有报警，如果没报警是为什么，机器不覆盖还是规则不覆盖还是什么其他原因，若是有报警，为什么安全侧未提前发现，报警功能是否还正常、报警处理流程是否不够高效导致处理滞后….
从业务侧来说，是测试机还是开发机，测试机严格讲是不允许部署在外网的，这说明业务侧开发部署上线流程不规范，至少是存在安全隐患的；
从发现的这一台机器来看，业务侧是否还有别的部署了该版本 fastjson 的机器，除了 fastjson 其他 JAVA 类的组件是否还应该排查；
从整个公司范围来说，单个业务出现这类 case，其他业务是否也会有，是否需要进行针对性的排查………
2.4.3 数据分析
精细化运营少不了对数据的分析解读，对安全来说需要定期查看数据、指标，是否在阈值范围内，近期漏洞数量/类型变化情况，安全是否需要采取新的控制措施；各业务线漏洞的分布情况，哪些业务目前安全风险较大，是否需要进一步了解等；
另一方针对业务方，可以定期给业务线安全接口人/负责人等管理角色推送安全数据以及风险评估报告。
0x03 开源漏洞管理调研
3.1 漏洞处理流程设计
3.1.1 漏洞修复过程责任分配
明确的责任分配是漏洞响应能力的基础，首先需要分析组织中涉及漏洞修复的部门和第三方有哪些，各个业务的主管是谁，谁在开发，谁在运维。
由组织的漏洞修复策略来说明各个责任部门的相关责任和漏洞修复的时间要求等。其次需要统一漏洞定义语言，所有漏洞生命周期涉及到的人员对漏洞相关的概念理解一致。
各部门的主要责任：
安全部门
- 提供漏洞管理相关培训；
- 收集、发现和验证漏洞；
- 漏洞风险和影响性评估；
- 与外部漏洞发现者沟通；
- 提供漏洞修复建议；
- 提供漏洞修复补偿措施；
- 跟踪漏洞修复结果。
开发/供应商
- 提供漏洞修复方案或修复补丁；
- 漏洞总结。
运维部门
- 测试漏洞修复方案；
- 开发漏洞修复（变更）计划（业务、运维、安全）；
- 实施漏洞修复；
漏洞的修复可能涉及第三方开发和运维，需要在合同中或补充条款中明确定义安全相关的责任，包括漏洞修复要求、保密要求等。
3.1.2 漏洞修复流程
可能漏洞的修复部署要走组织变更流程，组织可以根据自己的实际情况调整
3.1.3 漏洞管理支持系统
主要是支持漏洞发现和导入汇总、展示、告警和跟踪漏洞修复记录的系统，可以结合资产管理一起来做，另外常见漏洞的修复建议和修复步骤可以做成知识库共享给所有相关部门。最好结合自己组织的工单系统实现漏洞的自动化跟踪。
一些开源的漏洞管理系统：
- insight：洞察-宜信集应用系统资产管理、漏洞全生命周期管理、安全知识库管理三位一体的平台。
- xunfeng：一款适用于企业内网的漏洞快速应急，巡航扫描系统。
- SRCMS:企业应急响应与缺陷管理系统 。
- laravel-src:基于 Laravel 的开源安全应急响应中心平台。
- DefectDojo:一个安全程序和漏洞管理工具。
- Fuxi-Scanner：一款开源的网络安全检测工具，适用于中小型企业对企业信息系统进行安全巡航检测。
- SeMF：企业内网安全管理平台，包含资产管理，漏洞管理，账号管理，知识库管、安全扫描自动化功能模块，可用于企业内部的安全管理。
- DgM：dragonM 漏洞管理和资产管理系统
3.2 开源漏洞管理支持系统分析
3.2.1 初步调研分析
从项目的功能完整性、可维护性与最近更新时间等维度分析，选出三个待测试系统。
3.2.2 SeMF
功能说明
- 业务线管理： 对资产进行分组或根据企业业务线进行拆分，便于进行资产标记和责任人定位
- 资产管理： 该模块主要用于企业内部资产的管理，可根据需要进行资产类型自定义，无需动态组合资产属性和前端展示
- 漏洞管理： 该模块用于集中管理企业内部资产的安全风险，与资产强关联
- 任务管理： 该模块支持周期、延时、人工三种模式创建任务，分别调用不同的任务逻辑，可根据样例进行少量编码集成其他安全扫描器或数据集成
- 流程管理： 该模块为隐性模块，漏洞、任务的的执行步骤均由此进行自定义，流程变更仅需进行 init 设置，如需流程联动其他操作，可编写相应模块进行处理
- 日志管理： 该模块为隐性模块，默认情况下仅显示前 N 条登录日志，其他日志输出需手动操作，后续可能完善
- 安全工具： 该模块可集成一些有意思的安全工具，当前保留回显管理，用法同类似 dnslog，但是对一些盲攻击会有奇效
- POC 管理： 该模块因 POC 动态加载问题，进行了隐藏，但是保留了代码，希望进行 poc 管理共享的同学可以进进行改善
- 系统设置： 该模块可进行一些企业基础信息设置，如人员，部门，终端，扫描器设置等基础数据管理
界面说明
资产列表
漏洞管理
3.2.3 洞察
功能说明
- 应用系统资产管理：对公司应用系统资产进行管理，包括系统名称、域名、重要级别、部门、负责人等。
- 漏洞生命周期管理：对公司应用系统产生的安全漏洞进行线上提交、通告、知悉、复测、分类、风险计算、修复期限计算、邮件提醒、漏洞数据分析统计等。
- 安全知识库管理：对安全知识、管理制度进行集中存放、线上学习、安全培训、知识传承等。
界面说明
漏洞处理流程
3.2.4 dragonM
功能说明
- 漏洞管理
- 资产管理系统
界面说明
