浅谈甲方漏洞管理实践

0x00 概述

如今年（2021）七月Gartner 发布《Hype Cycle for Security Operations, 2021》（2021安全运营技术成熟度曲线），漏洞管理已经成为安全运营中较为成熟的子领域，可以说一切安全运营活动的开始几乎都是从漏洞管理开始的，是安全工作中的基础也是重要组成部分。

从合规方面，今年工业和信息化部、国家互联网信息办公室、公安部发布的《网络产品安全漏洞管理规定》也对网络产品提供者和网络运营者提出了明确的要求，企业需要扩充原有合规清单来满足监管要求。（附：官方解读）

0x01 漏洞管理的三层架构

1、底层安全基建

工欲善其事必先利其器，漏洞管理也不例外，一个好用的安全管理平台，能减少不少重复人力劳动，提高安全运营效率；另一方面，要想将发现的安全问题及时给到业务侧修复满足安全SLA，资产管理也必不可少。以上两个主要部分就像是漏洞管理的基座。

1.1 安全管理平台

为什么不称漏洞管理平台而是安全管理平台，因为漏洞管理是安全运营工作的一部分，一个整合了安全运营各工作环节的集中处置平台更利于提高工作效率。
安全管理平台通常具备如下功能模块：

• 全量报警管理
  来自外部报告（例如SRC、CNNVD等其他外部平台报送）、内部安全能力发现，如扫描器、HIDS、流量监测、蜜罐等产生的报警。每个报警源模块低耦合、可插拔，易于扩展。

• 支持漏洞全生命周期管理
  来自众多渠道的安全报警在经过自动/人工研判分析后，需要对真正需要关注的漏洞进行管理，通常是以工单等自动化流程形式，将安全问题分发至业务线，包含了漏洞分发、业务侧修复、修复后安全侧确认、直至关闭/打回工单等一系列操作。

• 漏洞知识库
  包含常规漏洞的漏洞描述、风险/危害描述、修复方案等，一方面是减少安全侧重复填写这些信息、另一方面是赋能业务侧。

• 权限管理
  安全管理平台通常具有诸多功能模块，因此做好权限的分类分级是十分必要的，可以是基于功能模块的、或是基于角色的，可以参考RBAC模型。

• 和其他平台/流程的打通
  主要用于安全卡位和数据同步需求的场景，例如研发需求管理、域名/服务上线、上线前提测等。

• 支持开放API
  基于提高安全效率考虑，可以开放第三方API给安全内部甚至业务侧，例如批量处理场景、以及和其他（安全）平台联动场景等。

• 数据分析和展示功能
  不管是安全侧还是业务侧都有数据分析的诉求。

对于安全侧，定期的数据分析和统计是必要的，常见的例如dashbord页面，实时展示不同统计维度、多种漏洞数据情况，同时漏洞运营的监控指标也可以在这个页面实时显示，便于运营同学及时发现问题。

为什么在业务侧也需要做数据分析，一方面是业务真的有这种诉求（这是安全意识较高的业务），他们希望了解每季度甚至每月对体系内部的安全风险情况；另一方面从安全的角度，让业务侧能看见这些“触目惊心”的漏洞数据，也是警示和提醒。

1.2 资产管理

安全问题的处理自然离不开业务部门的参与，安全漏洞更需要细粒度到资产属主、定位到人，因此需要具备公司各类资产的全量接口，如：域名、IP、主机名、容器名、实例名等，以及各类资产之间的映射关系查询，以确保安全问题定位的准确性和实效性。除了上述提到的常见类型资产，指纹库、第三方组件库的建立也是很必要的，尤其是当fastjson、struts 2这类安全漏洞爆发时，如何在快速应急也是对安全的考验。
由于资产的动态性，内部梳理是一部分，也需要外部视角的资产探测来做补充，也正是由于资产动态变化这个特性，这往往也是实际工作中的难点和痛点。

2、流程&机制

在平台建设的基础上，如何让整个系统良好的运转起来，是第二个部分——安全流程与协同机制需要关注的。

2.1 确保闭环

发现问题不是目的，如何解决问题降低安全风险才是最终目的。忽略漏洞修复结果的追踪，缺少标准化的流程来对漏洞的修复状态进行持续的追踪管理，将导致修复周期长、无法进行闭环跟踪。

对于高、中、低不同等级的漏洞有不同的修复优先级和时效性要求，安全平台以工单形式自动化将问题下发至业务，通过邮件、IM、短信等通知渠道将工单状态的变更实时同步至业务和安全，若在规定时间内未修复还会将安全问题逐级上升至业务侧管理角色，督促整改，确保安全问题处置的时效性保证闭环率。此外，定期的数据统计和分析也是必不可少的，可以发现流程和机制上的gap点，及时改进。

2.2 协同机制

由于双方视角和安全认知不同，如何让业务方重视安全问题、配合安全及时修复也是一个难题，“从上至下”的推进思路一般来讲会比“至下而上”更加事半功倍。

首先是安全制度层面，明确各类资产、虚拟资源的安全职责，出了安全问题谁来担责（安全制度一定要经过高层review确认和背书，具备权威性）。

明确接口人机制，在每个业务体系设立安全负责人、安全接口人角色（也需要在制度层面达成一致），有职责和义务配合安全，牵头推进该业务体系安全问题的处理。

OKR协同机制，将安全任务拆解至业务的OKR里（前提也是需要沟通达成一致），形成“契约”后让业务能主动推进。

对于频繁出现问题的业务线，可以建立安全协作专项，专注于某类风险集中治理和收敛。

3、精细化运营

3.1 安全review

针对外部报告的各种漏洞、情报，甚至是一次突发的应急事件、红蓝对抗等，安全需要对内部各能力线进行审视，内部安全能力是否有覆盖、是否该覆盖、是否能覆盖、资产是否有遗漏、安全能力是否存在gap点、安全流程是否存在改进空间等，需要不断优化迭代内部的安全能力，不断提高纵深防御水平。

3.2 风险分析

漏洞管理起源于漏洞，但绝不止于漏洞。从一个安全漏洞可以深挖的东西很多，如：业务逻辑业务形态是怎样的，他们为什么会出现这类问题，在现有安全需求下出现这类问题是否合理，安全能力还能做什么，发生这个问题的根因是什么、以及背后潜在的可能风险面等等，可以更加发散的来看。

基于以上两点，举个简单的例子：
比如业务侧被发现存在一个fastjson某个版本的RCE漏洞并且被getsehll了，从这个问题知道业务侧代码大概率是使用JAVA的，那么现在安全能力是否有定期的在进行扫描，是否有被扫描到，如果有被提前扫描到，那么业务侧为什么当时没有修复，是漏洞信息未触达业务还是业务不会修、不能修；

如果内部没有提前扫描出来，那么安全就需要反思排查了，是组件库/指纹库/POC 没覆盖、不准确还是压根这台机器就不在我们的资产库里；

除了扫描的问题，被反弹shell了，websehll检测、HIDS是否有报警，如果没报警是为什么，机器不覆盖还是规则不覆盖还是什么其他原因，若是有报警，为什么安全侧未提前发现，报警功能是否还正常、报警处理流程是否不够高效导致处理滞后....

从业务侧来说，是测试机还是开发机，测试机严格讲是不允许部署在外网的，这说明业务侧开发部署上线流程不规范，至少是存在安全隐患的；

从发现的这一台机器来看，业务侧是否还有别的部署了该版本fastjson的机器，除了fastjson其他JAVA类的组件是否还应该排查；

从整个公司范围来说，单个业务出现这类case，其他业务是否也会有，是否需要进行针对性的排查.........

3.3 数据分析

精细化运营少不了对数据的分析解读，对安全来说需要定期查看数据、指标，是否在阈值范围内，近期漏洞数量/类型变化情况，安全是否需要采取新的控制措施；各业务线漏洞的分布情况，哪些业务目前安全风险较大，是否需要进一步了解等；

另一方针对业务方，可以定期给业务线安全接口人/负责人等管理角色推送安全数据以及风险评估报告。