在每一年的演习中,我们都会处置好几十起产品安全事件,虽然绝大多数都是已知的漏洞,但仍然有记录和总结的价值。另外身处应急响应大厅,还会得到来自几千同事传来的一手情报,他们犹如探针一样驻扎在客户侧进行防守,又或是攻击队员,在演习期间不间断的上报情报,可以帮助提升公司网络安全(安全部做出相应排查、加固和检测动作)和产品安全能力(产品线依据情报详情编写检测规则)。回顾历年写下的笔记,提炼出八个典型场景进行分享:
1、面向情报公司付费信息的应急2、面向互联网侧舆情信息的应急3、客户侧产品推送样本事件处置4、某邮箱被攻击情报的自我检查5、办公网出口地址攻击客户蜜罐6、SRC白帽子突破边界进业务网7、某部门下发零日漏洞确认函处置8、公司溯源团队查到团队内部成员 |
---|
本章为该系列的第十三篇,亦是进入白热化战时状态的第7篇。主要介绍在实战演习结束后,组织方会向安全公司下发产品漏洞确认函,要求在24小时内向指挥部反馈是否为零日漏洞?该类事件意味着实战的收尾,同时也是产品安全团队接收大考成绩单的重要时刻,因为非自主发现漏洞数是团队的一个反向绩效指标,用于评估日常安全测试做的好坏。
01
—
事件描述
某日中午,执行总指挥联系我到某所取零日漏洞核查工作的承诺函。后来又被告知不用去了,直接通过线上发,按照时间和内容要求进行反馈。从拿到漏洞信息开始,就需要快速组织相关产品线一起研判,补全以下表格的信息:
02
—
响应动作
产品应急组当班同事正好去年处理过,故由他负责跟进。由于X系统一直没找到归属,一直到晚上七点也没有完成。于是我做了判断,反正都是已下市的产品,所以归属是谁不那么重要,目前最像是X子公司的,所以让他们按照下市的情况来反馈。
写完之后,到了第二个环节 - - 领导审核(所有外发文件需要审核,很重要,做技术的同学不能轻视,否则可能会给个人和公司带来麻烦)。报告的审核比较难受,领导时间不合适、领导各抒己见...恰逢领导Z在出差回京路上,一直拖到21点后才开始审核,看了反馈文件提出几点疑问:
经过几轮沟通,最终输出了报告,并在24点前发给某所的对接人。
03
—
处置结果
次日中午,接到某所对接人语音(感觉他们比较喜欢语音或电话,不留痕or高效便捷),有个漏洞编号写错了。经过核对,确实是在整理和下发时出了点问题。其实,我们昨晚在分析时就发现了,不过自此没有再继续追问反馈函,反馈工作基本告一段落。
04
—
经验总结
该类事件的处置相对简单,主要工作量在漏洞判断及补齐信息、领导审核和修改上。假设非要说难点的话,就在于有反馈时限(收到报告24h内)。因为在这段时间里,除了做上述事情外,还涉及到盖公司章、主要负责人签字,如果漏洞多的话,很难按照要求完成,不过好在这些都可以和对接人沟通。通过这件事,发现自己各有一件事做的好和不好: