在开篇《安全事件运营SOP【1】安全事件概述》中,介绍了安全事件的定义、分级、处置原则及处置流程。当发生某类安全事件时,该如何快速处置?以及如何保证不同人员处置的效果都达标?安全事件的种类虽然繁多,但是处理起来并非无据可循。为了解决上述两个问题,同时提升工作效率和降低安全风险。经过大量的运营处置实践,总结出以下常见的处置标准操作程序(SOP)。
本文将从基础概念、运营处置、内部响应实现和事件处置策略四个维度,对接收漏洞事件运营SOP进行阐述。由于作者所处平台及个人视野有限,总结出的SOP虽然经过大量重复的操作、总结及提炼,但仍会存在错误或不足,请读者同行们不吝赐教,这也是分享该系列实践的初衷。
01
—
基础概念
在企业网络安全运营中,有一类事情可能不太被重视,但却常会遇到,如果处置不当可能会给公司带来比较大的麻烦 - - 接收漏洞事件。之所以称之为安全事件,是因为存在不可控因素,处置时需要考虑的范围已经超过漏洞原理本身,被人利用可能给社会或公司带来负面的影响。
漏洞接收事件的渠道可以分为内部和外部两类,可能会有疑问:内部渠道为什么会算进来,以及内部渠道是指SDLC中发现的漏洞吗?从安全事件的定义来看,内部发现的漏洞也有可能导致负面影响,不过概率会比外部的低。内部的漏洞事件是指:非安全部门直接发现的漏洞。比如安全部门发起的SRC奖金悬赏活动收到的漏洞、安全公司有非常多懂攻防的员工、开发也可能对安全比较感兴趣从而提交漏洞…这并非他们的本职工作,所以也可以算作内部的“外部人员”,漏洞在他们手里就有可能导致事件。
内部渠道相对可控,外部就比较被动了。不仅不能清楚何时会以何种方式被通知有漏洞,还可能会被各种要求,比如有反馈要求、时限要求、处置动作说明、责令整改等。在外部的漏洞接收渠道中,包括国家级的漏洞库或平台、行业监管单位下发漏洞、民间漏洞收集相关平台,前两者会得到明确的漏洞通知,最后一种却比较艰难,因为民间平台不会通知企业、可能得通过白帽关系等才能弄清楚漏洞。以下为漏洞接收事件的常见渠道:
02
—
安全运营SOP
面对“在野”的漏洞细节,无论是何种渠道的漏洞事件,都需要快速响应与处置,通常可以参照以下流程:
在对应的环境进行漏洞信息验证,测试漏洞是否真实存在、以及判断被利用带来的影响。针对监管单位下发的漏洞,即使不存在也会被要求按照既定格式、时间进行正式回复。
除了漏洞的利用难度、被利用带来的直接影响,还应该从外部舆论、产品在客户侧的覆盖面等方面,全面对漏洞事件进行评估,从而采取不同的应对措施。
安全人员组织对应的产品线进行漏洞修复,在修复之后进行验证,验证漏洞是否被彻底修复、漏洞修复方法是否可能被bypass、漏洞修复是否带来新的安全问题。在确认无误的情况下,将验证结果告知产线,产线输出修复方案和经过验证的补丁。
漏洞修复后,对各来源渠道需要有明确、及时的答复,如在SRC上确认漏洞并定级给奖金、回复修复计划给监管单位/国家级漏洞库、记录并给与内部提交人一定奖励、对反馈漏洞的客户进行修复与致谢。
针对漏洞接收、处置、修复、验证、回复等整个环节进行总结,反向来优化现有标准与现有流程;对漏洞产生的原因进行分析,反向加强安全测试和内部安全管控。
2.1 – 2.5描述的内容,如下图所示:
注:图中的监管单位,默认包括国家级漏洞库、平台和相关行业的监管单位。对于民间的漏洞库或平台,由于没有固定的方式暂不纳入SOP。
03
—
内部响应实现
漏洞事件的处置其实是一件比较复杂的工作,仅凭安全部门是做不好的。比如漏洞事件需要与GA对接,事件在外部已经产生舆论,事件涉及到侵权,事件处置措施出现分歧无人拍板…
不少公司已经建立了SRC/安全运营团队,对于安全技术运营方面没问题,但当遇到“漏洞”升级为“事件”时,则需要将团队扩大化。比如在成立公司级PSIRT(Product Security Incident Response Team,产品安全应急响应小组-更适合于非SaaS化的产品及服务),由研发、安全、技术服务、客户经理、法务、公关等各岗位专家组成,覆盖供应链、研发、工程交付及技术服务等各环节。
同时设置领导小组和工作小组,领导小组负责产品安全事件的议事与决策,工作小组依据领导小组决策及职责分工进行工作落地。
在2.2中,简要介绍了影响定级的要素,但对于每个因素的占比、事件的分级未提及。此处将针对这部分内容进一步说明:
在日常运营中,按照以上规则,对每个接收漏洞事件进行评分,就可以得到事件等级。附:某次接收漏洞事件的定级示例
04
—
处置漏洞事件策略
被动就是处理起来比较难受,与其被动的等待不如主动接收。当安全建设到一定程度(如主要安全基础设施已建设,进入运营阶段),可以从以下方面着手:
在处置外部接收的漏洞事件时,经常会碰到一些特殊的场景:
曾尝试过与漏洞库沟通,此类漏洞是否出具证明就直接在系统上关闭?但得到了否定的答案,须按照时限和格式进行邮件反馈。自此以后,内部建立SOP和SLA标准化处置每一次漏洞事件。
除了上面撞洞的情况,还经常会有另一种情况:SRC前不久刚收到漏洞,怎么没过多长时间漏洞库就来通报了?仔细查看内容,所有的描述甚至连截图、涉及到的IP都一样。这很难不让人联想到一洞多投,价值最大化。
虽然SRC声明:要求白帽子对提交的信息进行保密、禁止传播,但还是很难去约束。我们曾经也是一名白帽子,很理解白帽子挖洞付出的辛劳,故在漏洞审核时间响应速度、漏洞现金奖励、季度奖励、年度奖励方面投入很多。但换来的却还是多平台刷洞,这难免有点让人心寒。不过好在绝大多数白帽子能坚守住,高质量的漏洞也基本没出现过此类情况。在此,还是想趁机呼吁所有的白帽师傅:遵守SRC或平台的规则,做个正直诚信的人。