个人学习时对安全最原始的近距离接触就是安全漏洞,企业中也不例外。
前段时间就有幸参与并且落地了一些与漏洞管理相关的项目。与个人学习差距较大的地方在于,甲方企业对安全漏洞的最核心最关键需求就是“闭环漏洞”,这里涉及到的不仅是如何发现、如何修复之类技术问题,整体建设的思路、运营的流程、运营与管理流程中业务方与安全方视角的切换,环环相扣,都非常重要。
目前阶段我理解的“安全事件管理与漏洞管理”的终极目标,就是“结果导向,解决问题”。发现问题很重要但不是目的,如何解决问题降低安全风险才是最终目的。忽略对修复结果的追踪、缺少标准化流程来对漏洞状态进行持续管理,会导致修复周期长、漏洞无法闭环等问题。
基础安全建设
公司最初的安全管理形式是“甩文档,甩表格”,原始低效。最大问题是人工成本太高,尤其是公司资产数量不少,扫描出的漏洞数量也不少,拉群与业务方同学逐个沟通,管理起来比较费劲。而且业务同学普遍在漏洞修复这件事上很不积极(这涉及到企业员工安全意识建设,另开一篇博客说)就导致漏洞修复效率奇低。严重漏洞还比较有压力,修复速度很快,从高危往后的漏洞修复,大家的效率会随着漏洞等级的降低逐级递减。
这时候如果有平台、有机制规范修复的整体流程的话,问题想必会得到很大缓解。好的流程可以让人自觉地进入“管束”状态,对解决问题本身是很有益的。
流程依赖两个必要条件:
- 一个好用的漏洞管理平台
- 管理平台可以减少重复的人力劳动,提高安全运营效率。
- 公司资产管理
- 管理公司资产,也可以将发现的安全问题及时给到业务侧修复。
漏洞管理平台
- 报警管理:
漏洞管理平台所汇集的信息来源是多方的,包括外部报告(渗透测试、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
在自我梳理过后搜到上面这篇博客。很高兴我的前面的大部分想法与作者不谋而合,这件事本身也是对我自己的一种激励~😆