实战攻防演习下的产品安全保障

本章为该系列的第四篇，主要介绍面对国家级的实战攻防演习，产品安全保障工作的目标和方案。在设计保障方案前，将紧绕目标制定设计原则，方案中主要围绕漏洞挖掘方案和应急响应方案展开，最后将介绍在经历多年实战演习后、对产品安全保障的一些新的感触。

产品安全保障专项

01

—

产品安全目标

产品安全的目标其实很明确，就是保障产品的自身安全性，避免在任何时候被任何方式攻破。但在实战演习期间，目标可以具象化为：

• 产品不被攻破：指参加演习客户侧的公司产品，不会因为已知或未知漏洞而攻破。这个目标异常的难，已知漏洞的主要难点在于交付团队的覆盖及加固程度（需要覆盖所有参与演习的客户，包括其子公司、孙子公司...，有的客户比较保守，不一定允许加固）；未知漏洞的难点在于内部团队发现产品漏洞的能力、产品线的配合度（比如忘了提供产品的某一部分代码，黑白盒测试就会漏测，大概率就会把漏洞漏出去）以及外部红队的攻击决心（若是被盯上并死磕，大概率是保不住目标了）。当然了，按照以往的经验也会有一些例外，比如已经退市很久的产品、明确是因为客户不加固等情况就不会计算在内;
• PSIRT高速运转：在值守期间，所有的产品安全事件处置都严格按照PSIRT战时响应流程执行。平、战时的不同点在于事件数陡增和响应、处置SLA极度缩减。事件数变多很好理解，全国这么多攻击队集体开战，客户数也很多且安全水平参差不齐，但此时的安全运营水平很可能是最高的，各个公司都有外包驻场人员二十四小时不间断的盯着告警，最容易发现攻击。正是因为攻防氛围高度紧张，客户侧的每一个安全事件都需要快速响应，所以每个PSIRT流程的响应与处置时限被压缩得非常短，总体来看至少减少为平时的1/3。

02

—

安全保障方案

2.1.方案设计原则

一切围绕目标、结合现状和资源展开，在有限的时间里（一般演习前T-45天是备战阶段），需要集中式的、尽可能的发现公司产品漏洞，快速输出解决方案并同步至客户侧进行修复。面对庞大的产品线，需要抓住重点以保障整体效果，以下为主要考量的因素：

• 产品分类分级：按照产品的部署位置（攻击面，如互联网边界部署暴露面大易被攻击）、产品的类型（如集权类，演习中攻下后得分高的容易被关注）、产品的销量（一般说是产品服务端的实例数，卖的多被攻击的概率就越大）、已暴露出问题的产品（如SRC近期收到漏洞的产品，很可能别人已经拿到源码并存在对外传播的可能性，风险系数高）等四大因素将产品分为重点产品和一般产品，然后分而治之；

• 发挥长板优势：在前面的章节已经提到过调用公司内部的漏洞挖掘资源，但是他们如何开展工作呢？挖洞的手法比较多，比如有的团队擅长做源码分析，那就让他们进行代码审计；有的团队擅长进行渗透，那就组织产线搭环境进行实战攻击；有的团队擅长做二进制漏洞挖掘，那就立一个二进制安全的专项，让他们在各自擅长的领域发挥；

• 全过程的覆盖：在做保障方案时，除了要考虑保障的目标，还应该想到保障的时间周期及对应要做的动作。犹如一个产品上线一样，发布前尽可能的发现其安全问题然后修复，但也不能保证上线后一定不会有安全问题，而是应该事先准备好应急响应措施和流程。面对演习，其实也是一样的，应该要同时制定产品的漏洞挖掘方案和应急响应方案。

2.2.漏洞挖掘方案

在2021年的演习之后，总结并发表了《浅谈安全产品的hvv安全之道》。如今看来，那些安全专项依旧很有效，大多数都还在延用。以下将回顾最近三年的主要安全专项：

• 2020年的专项：从攻击面角度并结合演习得分权重将产品分为A类和B类，外部协调到了安服攻击实验室和代码安全实验室的资源，开展了十项漏洞相关工作，第一项始于某VPN事件之后发起的自身排查，其次是加入了黑盒实战渗透和白盒静态代码扫描（首次大规模推，之前在做小范围试点并尝试通过规则调优减少误报率）。当时的攻击态势还没那么焦灼，所以也完成了既定目标（无产品0day在野传播、无客户因为我司产品漏洞而被攻陷）；
• 2021年的打发：在20年的基础上，强化了产品安全事件应急响应团队和组织的建设，在演习的启动会上一起召开了PSIRT领导小组会议，强调各相关团队的职责、协作机制和演习中的要求，并让所有产品线的一把手签字承诺在规定时间内修复所有漏洞、按照要求响应事件以及在演习期间亲自值班。在漏洞挖掘方面，第一次大规模推开源组件检测（早在18年就开始试用，但由于各种原因没有覆盖所有产线）并趁机提出严苛的漏洞修复要求，没想到也能顺利落地，为此后将开源组件扫描嵌入到安全提测流程中奠定了基础，极大的提高了我们推行这件事的决心；
• 2022年的策略：经过前几年的沉淀，建立了产品安全保障矩阵，参与方包括产品线、安服攻击实验室、代码安全实验室、安全技术研究实验室、外部白帽子和网络安全部，挖洞关注点也从最开始的黑、白盒，增加了灰盒IAST、外部收集、产线自查、交付安全审计等5个方面，如最上方保障矩阵所示。

2.3.应急响应方案

为了保障产品安全事件应急的有序开展，需要提前制定应急响应处置策略，包括应急场景预设、流程及SOP制定、面向全员进行宣贯、组织相关方应急演练。

• 应急响应场景预设：在演习过程中，最常见的是来自一线客户侧的漏洞情报、开源软件漏洞情报、互联网上传播的产品漏洞情报，所以将这些场景前置，在演习前编写剧本、组织相关方进行演练。针对一些细节问题一定要细扣，比如互联网上的舆情处置机制，微信中在传播某产品存在漏洞的情报而产生舆论，会快速扩散到参加演习的客户耳中，然后他们就会不断地来求证事实，给值班团队带来极大的压力，故此类事件应急一定是要放到演练中；
• 应急响应流程制定：在网络安全事件响应中，标准动作分为7个标准：检测、响应、抑制、报告、恢复、补救和总结教训。在产品安全事件处置时，其处置方式、闭环难度陡然而生，不再是针对公司内部，在恢复和补救环节需要面向所有客户，不过总体上依旧可以参照这个思路。平时的事件定级在战时也可以不用考虑，因为战时出了问题就立马需要解决，仅需区分是否产品新漏洞，然后采取相对应的措施即可；
• 组织全员宣贯流程：面向所有的产线进行产品应急响应流程宣贯，一般是要求产线负责人、安全专员及要值班的同事参与，其核心目的就是同步产品在遇到安全问题时，如何有序、快速的跨部门处置。做到值班时，不慌不忙、有头绪的找对应人员；
• 开展应急响应演练：在T-7天的时间段内，组织产线（容易出问题的产品线）、公关、交付等PSIRT相关团队和重保指挥体系下的情报、一线PM等相关团队，针对列出的应急响应场景进行线下演练，在培训后进行实操、正式开始前找找感觉，及时发现流程中的不足并进行优化，做好最后的准备。

2.4.一些新的感触

犹如《浅谈安全产品的hvv安全之道》结尾的预测一样：在未来的几年里，攻击队对安全产品的攻击火力依旧猛烈。这在22年得到了印证，产品遭受高度自动化和破坏力极强的武器化攻击，利用多个漏洞的组合（数据库服务漏洞+应用程序漏洞），并对抗程序保护机制进行底层hook，自动收集产品上的敏感信息并切片外传...这种场景好像在电影里或真实的APT组织案例中才能看到，没想到直接搬到了眼前。

提升产品的实战化对抗能力，已经迫在眉睫。一方面是借助企业蓝军的思路，组建产品安全蓝军，定期逐一攻击公司产品，与常态化安全测试不同的是目标不一样（想方设法拿到产品权限）；另一方面建立产品自我感知风险的能力，当面对不同层面的攻击时，能够立即发现并产生告警，以供运营人员处置。

未完待续，下期再见~

---

原文始发于微信公众号（我的安全视界观）：实战攻防演习下的产品安全保障