面向互联网侧舆情信息的应急

在每一年的演习中，我们都会处置好几十起产品安全事件，虽然绝大多数都是已知的漏洞，但仍然有记录和总结的价值。另外身处应急响应大厅，还会得到来自几千同事传来的一手情报，他们犹如探针一样驻扎在客户侧进行防守，又或是攻击队员，在演习期间不间断的上报情报，可以帮助提升公司网络安全（安全部做出相应排查、加固和检测动作）和产品安全能力（产品线依据情报详情编写检测规则）。回顾历年写下的笔记，提炼出八个典型场景进行分享：

1、面向情报公司付费信息的应急2、面向互联网侧舆情信息的应急3、客户侧产品推送样本事件处置4、某邮箱被攻击情报的自我检查5、办公网出口地址攻击客户蜜罐6、SRC白帽子突破边界进业务网7、某部门下发零日漏洞确认函处置8、公司溯源团队查到团队内部成员

本章为该系列的第八篇，亦是进入白热化战时状态的第2篇。面对互联网上传播的产品漏洞信息，要想方设法的去挖掘细节，做到知己知彼灵活应对。期间，丰富的白帽子人脉资源和SRC门户起到了至关重要的作用，帮助我们快速定位白帽子，引导其提交SRC换赏金，实现漏洞信息的收敛及推动事件快速闭环。

—

事件描述

某日，情报团队监测到多个微信群在传播：我司产品，存在后台文件上传漏洞。将该情报上报至产品应急组，值班组长随即在团队内部群和现场的溯源团队发出号召，尝试去联系发信息的师傅，试图获取情报来源和详情。

—

响应动作

漏洞情报源溯源：团队内部有几个同学常年活跃在白帽子群体中，这时候凭借平时的积累，辗转反侧联系了三四个人之后，最终找到了一个红队师傅，他声称手里有细节，可以和他进行漏洞情报交换。
引导至SRC提交：但这毕竟是不合规的，于是就引导他提交到SRC换取奖金。此处会涉及到一些谈判技巧，比如现在提交是值钱的，再晚点提交估计就要撞洞而一文不值。因为漏洞肯定会在攻击队之间传播，他不提交、别人不一定不会交；全国演习客户都投入了大量人力进行监测，只要攻击队使用就不难被发现。
漏洞信息分析研判：从SRC收到漏洞信息后，值班同学立即组织产线对漏洞进行验证，发现找不到环境，原来是已经退市多年的产品存在漏洞，现在产线没有人维护，只能是告知客户进行升级或替换新设备。
输出漏洞止血方案：与此同时，准备了更细致的方案。针对因此被攻击的客户或防止客户因为该漏洞被攻击，也输出了临时的止血方案，通过配置nginx摘除相关API映射的方式防止被攻击。
对外公告编写发布：由于在微信群中出现了大范围的传播，产线也准备了公告，对此事件进行公开说明并提供了解决方案。

—

处置结果

已对外发布公告，后续基本无新生事项。

即使有人还是会来询问，同步了公告后，基本都没问题了。

—

经验总结

所有的产品安全事件，都能涵盖到事件响应流程中，看似都是相同的操作：收集情报 --> 上报情报 --> 分析研判 --> 输出方案 --> 对外公告。但其环节中涉及到的关键资源和能力却有所差异。在这类事件中，展现出来的是：

情报在演习场景中可化被动为主动：无论是产品的漏洞情报，还是被攻击后的事件情报，几乎全都是无风不起浪。但凡是互联网上传的产品漏洞，基本上都或大或小的存在一些安全问题。若提前得到情报，则可以提早部署工作，从容应对可能产生的外界舆论和客户侧诉求带来的压力；
安全圈子在演习场景中也同样重要：混圈子，仿佛一直都是安全圈的贬义词，会认为是没真本事、只会动嘴皮子的人。但是安全圈也有不同的局，高端局或内部圈子，没特长的人可能也进去不了。所以圈内的资源是十分重要的，个人不能闭门造车，轻视了这层关系，比如在定位白帽子就动用了圈内资源，这极大的提高了事件的处置效率；
已退市产品安全性成为演习中的软肋：无论是在演习前做集中式的漏洞挖掘和修复，还是产线在人力资源上的投入，都不会去考虑一个不再维护的产品。但是，在演习期间遇到事件又必须去处理，这也是近几年头疼的事情。依稀记得有一年凌晨，一群人还在找产品归属哪个产线、是哪位负责人，确定之后才能继续执行后续应急。就攻击队而言，这样的产品漏洞更好挖，要知道老产品最初都只考虑安全功能，而非自身安全性。