某部门下发零日漏洞确认函处置

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

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

 

本章为该系列的第十三篇，亦是进入白热化战时状态的第7篇。主要介绍在实战演习结束后，组织方会向安全公司下发产品漏洞确认函，要求在24小时内向指挥部反馈是否为零日漏洞？该类事件意味着实战的收尾，同时也是产品安全团队接收大考成绩单的重要时刻，因为非自主发现漏洞数是团队的一个反向绩效指标，用于评估日常安全测试做的好坏。

 

01

—

事件描述

某日中午，执行总指挥联系我到某所取零日漏洞核查工作的承诺函。后来又被告知不用去了，直接通过线上发，按照时间和内容要求进行反馈。从拿到漏洞信息开始，就需要快速组织相关产品线一起研判，补全以下表格的信息：

 

02

—

响应动作

产品应急组当班同事正好去年处理过，故由他负责跟进。由于X系统一直没找到归属，一直到晚上七点也没有完成。于是我做了判断，反正都是已下市的产品，所以归属是谁不那么重要，目前最像是X子公司的，所以让他们按照下市的情况来反馈。

写完之后，到了第二个环节 - - 领导审核（所有外发文件需要审核，很重要，做技术的同学不能轻视，否则可能会给个人和公司带来麻烦）。报告的审核比较难受，领导时间不合适、领导各抒己见...恰逢领导Z在出差回京路上，一直拖到21点后才开始审核，看了反馈文件提出几点疑问：

• 0 day怎么定义？退市产品存在未知漏洞，算是0day？
• 退市产品有新版本替换，就算升级方案修复漏洞了吗？

 

经过几轮沟通，最终输出了报告，并在24点前发给某所的对接人。

 

03

—

处置结果

次日中午，接到某所对接人语音（感觉他们比较喜欢语音或电话，不留痕or高效便捷），有个漏洞编号写错了。经过核对，确实是在整理和下发时出了点问题。其实，我们昨晚在分析时就发现了，不过自此没有再继续追问反馈函，反馈工作基本告一段落。

 

04

—

经验总结

该类事件的处置相对简单，主要工作量在漏洞判断及补齐信息、领导审核和修改上。假设非要说难点的话，就在于有反馈时限（收到报告24h内）。因为在这段时间里，除了做上述事情外，还涉及到盖公司章、主要负责人签字，如果漏洞多的话，很难按照要求完成，不过好在这些都可以和对接人沟通。通过这件事，发现自己各有一件事做的好和不好：

 

• 拆解做事步骤灵活处置：主要是盖章的两个环节，第一个是承诺函，第一次到新楼盖章，一进门问了下保安盖章地方，确保没有走错方向，其次是多打印了一张备用，恰好由于自助盖章失败可以派上用场；第二是漏洞反馈函，被要求24h内完成纸质版盖章和法人签字反馈，但又临近周五下班，周末法务不上班，故把盖章的第一页单独打印，先盖章做好准备；

   

• 对零日漏洞的理解偏颇：最开始回答领导Z的提问时，仅关注报告上的计算方式（因为之前已经问过对接人，仅按照时间来判断零日漏洞，与产品下市与否无关），没有充分、灵活地将零日漏洞的概念拿过来用，导致回答很笨拙，显得自己不专业很是懊恼。

 

 

原文始发于微信公众号（我的安全视界观）：某部门下发零日漏洞确认函处置