个人学习时对安全最原始的近距离接触就是安全漏洞，企业中也不例外。
前段时间就有幸参与并且落地了一些与漏洞管理相关的项目。与个人学习差距较大的地方在于，甲方企业对安全漏洞的最核心最关键需求就是“闭环漏洞”，这里涉及到的不仅是如何发现、如何修复之类技术问题，整体建设的思路、运营的流程、运营与管理流程中业务方与安全方视角的切换，环环相扣，都非常重要。
目前阶段我理解的“安全事件管理与漏洞管理”的终极目标，就是“结果导向，解决问题”。发现问题很重要但不是目的，如何解决问题降低安全风险才是最终目的。忽略对修复结果的追踪、缺少标准化流程来对漏洞状态进行持续管理，会导致修复周期长、漏洞无法闭环等问题。
基础安全建设
公司最初的安全管理形式是“甩文档，甩表格”，原始低效。最大问题是人工成本太高，尤其是公司资产数量不少，扫描出的漏洞数量也不少，拉群与业务方同学逐个沟通，管理起来比较费劲。而且业务同学普遍在漏洞修复这件事上很不积极（这涉及到企业员工安全意识建设，另开一篇博客说）就导致漏洞修复效率奇低。严重漏洞还比较有压力，修复速度很快，从高危往后的漏洞修复，大家的效率会随着漏洞等级的降低逐级递减。
这时候如果有平台、有机制规范修复的整体流程的话，问题想必会得到很大缓解。好的流程可以让人自觉地进入“管束”状态，对解决问题本身是很有益的。
流程依赖两个必要条件：
- 一个好用的漏洞管理平台
- 管理平台可以减少重复的人力劳动，提高安全运营效率。
- 公司资产管理
- 管理公司资产，也可以将发现的安全问题及时给到业务侧修复。
漏洞管理平台
- 报警管理：
漏洞管理平台所汇集的信息来源是多方的，包括外部报告（渗透测试、SRC）、HIDS、威胁情报、扫描器。每个报警源低耦合、可插拔、易扩展。
- 漏洞全生命周期管理
以上告警信息经人工研判后，需要将有效漏洞导入漏洞管理平台，并将安全问题分发至业务线。可以通过安全调度中心或企业工单等自动化流程分发。
流程：漏洞发现 ➡️ 漏洞验证 ➡️ 漏洞分发 ➡️ 业务修复 ➡️ 复测 ➡️ 打回/延期/关闭 ➡️ 结束
全程留痕（日志等）
支持表格/图表导出
模版化
常见/常规的漏洞描述、危险描述、修复方案可以模版化存储到漏洞知识库中。
- 权限控制
漏洞owner只允许访问自己负责修复的漏洞的信息。做好权限的分类分级。（基于功能模块，基于角色）
- 扩展性与易用性
- 与其他平台/流程的打通。（如加入到工单中）
- 开放API
- 支持批量操作
ps：对于安全侧，定期的数据分析和统计是必要的，常见的例如dashbord页面，实时展示不同统计维度、多种漏洞数据情况，同时漏洞运营的监控指标也可以在这个页面实时显示，便于运营同学及时发现问题。
为什么在业务侧也需要做数据分析，一方面是业务真的有这种诉求（安全意识较高的业务），他们希望了解每季度甚至每月对体系内部的安全风险情况；另一方面从安全的角度，让业务侧能看见这些“触目惊心”的漏洞数据，也是警示和提醒。
资产管理
安全问题的处理自然离不开业务部门的参与，安全漏洞更需要细粒度到资产属主、定位到人，因此需要具备公司各类资产的全量接口，如：域名、IP、主机名、容器名、实例名等，以及各类资产之间的映射关系查询，以确保安全问题定位的准确性和实效性。
除了上述提到的常见类型资产，指纹库、第三方组件库的建立也是很必要的，尤其是fastjson、struts 2这类安全漏洞爆发时，如何在快速应急也是对安全的考验。 由于资产的动态性，内部梳理是一部分，也需要外部视角的资产探测来做补充，也正是由于资产动态变化这个特性，这往往也是实际工作中的难点和痛点。
流程
基础安全建设的前提下，将漏洞管理平台的运行与运营流程结合起来，让整个系统进入良好运转状态。
- 关键点：闭环
- 时效性要求：对于高、中、低不同等级的漏洞有不同的修复优先级和时效性要求。
- 通知渠道覆盖：安全平台以工单形式自动化将问题下发至业务，通过邮件、IM、短信等通知渠道将工单状态的变更实时同步至业务和安全。
- 周期提醒、过期升级抄送：对业务进行周期性修复提醒，若在规定时间内未修复将安全问题逐级上升至业务侧管理角色，督促整改，确保安全问题处置的时效性保证闭环率。
- 人工定期review流程：不断优化迭代运营流程。
优化策略：定期的数据统计和分析，可以发现流程和机制上的gap点，及时改进。
- 协同与通知
协同的重要作用之一是促进业务方与安全方效率协同，效率协同就需要彼此理解，需要同步安全与业务的认知。
- 从上至下推进：首先是安全制度层面，明确各类资产、虚拟资源的安全职责，出了安全问题谁来担责（安全制度一定要经过高层review确认和背书，具备权威性）。
- 明确接口人机制：在每个业务体系设立安全负责人、安全接口人角色（也需要在制度层面达成一致），有职责和义务配合安全，牵头推进该业务体系安全问题的处理。
- OKR协同：OKR协同机制，将安全任务拆解至业务的OKR里（前提也是需要沟通达成一致），形成“契约”后让业务能主动推进。
安全review意识
针对外部报告的各种漏洞、情报，甚至是一次突发的应急事件、红蓝对抗等，安全需要对内部各能力线进行审视，内部安全能力是否有覆盖、是否该覆盖、是否能覆盖、资产是否有遗漏、安全能力是否存在gap点、安全流程是否存在改进空间等，需要不断优化迭代内部的安全能力，不断提高纵深防御水平。
风险分析：漏洞管理起源于漏洞，但绝不止于漏洞。从一个安全漏洞可以深挖的东西很多，如：业务逻辑业务形态是怎样的，他们为什么会出现这类问题，在现有安全需求下出现这类问题是否合理，安全能力还能做什么，发生这个问题的根因是什么、以及背后潜在的可能风险面等等，可以更加发散的来看。
基于以上两点，举个简单的例子：
比如业务侧被发现存在一个fastjson某个版本的RCE漏洞并且被getsehll了，从这个问题知道业务侧代码大概率是使用JAVA的，那么现在安全能力是否有定期的在进行扫描，是否有被扫描到，如果有被提前扫描到，那么业务侧为什么当时没有修复，是漏洞信息未触达业务还是业务不会修、不能修；
如果内部没有提前扫描出来，那么安全就需要反思排查了，是组件库/指纹库/POC 没覆盖、不准确还是压根这台机器就不在我们的资产库里；
除了扫描的问题，被反弹shell了，websehll检测、HIDS是否有报警，如果没报警是为什么，机器不覆盖还是规则不覆盖还是什么其他原因，若是有报警，为什么安全侧未提前发现，报警功能是否还正常、报警处理流程是否不够高效导致处理滞后….
从业务侧来说，是测试机还是开发机，测试机严格讲是不允许部署在外网的，这说明业务侧开发部署上线流程不规范，至少是存在安全隐患的；
从发现的这一台机器来看，业务侧是否还有别的部署了该版本fastjson的机器，除了fastjson其他JAVA类的组件是否还应该排查；
从整个公司范围来说，单个业务出现这类case，其他业务是否也会有，是否需要进行针对性的排查………
数据分析：精细化运营少不了对数据的分析解读，对安全来说需要定期查看数据、指标，是否在阈值范围内，近期漏洞数量/类型变化情况，安全是否需要采取新的控制措施；各业务线漏洞的分布情况，哪些业务目前安全风险较大，是否需要进一步了解等；
针对业务方，可以定期给业务线安全接口人/负责人等管理角色推送安全数据以及风险评估报告。
Reference：https://www.cnblogs.com/ffx1/p/15406732.html
在自我梳理过后搜到上面这篇博客。很高兴我的前面的大部分想法与作者不谋而合，这件事本身也是对我自己的一种激励～😆