演习后对工作技能的复盘总结

专业技能

• 攻击痕迹少：安全产品若是硬件盒子交付，其硬件性能设计可能仅为供产品正常运行，期间产生的应用日志、操作日志都不能长时间存储在本地，但也会提供了syslog/rsyslog等日志外发功能。不过从目前来看，未开启的客户还是占据了大多数。此外面临的是武器化装备的攻击队，即使本地会留存一些日志，大概率也会被想办法清除。有人可能会说从流量层面做分析，但实际情况很可能是NTA检测未覆盖，即使覆盖了基本上也都是未解密。在诸如此类的因素下，就导致了产品被攻击时，很难直接找到日志判断出被利用的漏洞。此时不起眼的程序debug等其他底层打印的日志，起到了关键作用，在以往的案例中均是通过分析这些日志，找到蛛丝马迹从而取得突破。
• 日志分析有门槛：主要是指获取日志有权限、查看日志有难度，得让产线和安全部门齐上阵才能解题。前者是安全设备的一个常见现象，硬件形式交付时不会提供系统的root及相关权限账密，在产品遭受攻击时，客户一般都是要找原厂支持，即使到了原厂的前场交付，他们也很有可能不知道账密，必须联系产线开发操作；后者是有的产品日志先加密再打印，也是需要原厂工程师解密后才能看懂，这类情况一般发生在底层C/C++实现、客户端和服务端通信的部分；
• 攻击复现还原链路：在安全产品的应急事件处置过程中，绝大多数都是证据链不足，所以大多数时候都是一边看少得可怜的日志，一边review代码，根据日志中发现的线头，到代码中去挖洞验证。团队经常是大半夜、后半夜都在指挥中心值班挖漏洞，或是写漏洞利用工具，通过攻击复现的方式去验证产品被攻击场景或外部传播的舆情。根据攻击视角的路径还原情况，决策产品是否出补丁、是否按照PSIRT战时流程和要求到客户侧做修复。

职业嗅觉

• 感知潜在风险：先拿零日漏洞处置事件来说，要求盖公司章印和领导签字须在48h内反馈，但持续不断地还有漏洞发过来，且正值周末不好盖章。初步评估按照要求完成不了，故为了避免处理不好带来的影响，主动找某所接口人沟通反馈事宜。再看某邮箱被攻击的自我检查事件，更好的说明了安全人员不要站在旁边看其他家的热闹，而要反思自己并自检。
• 细扣关键过程：在处置产品安全事件的过程中，不时发现对研判后的安全事件处置流程不通畅，以及各小组存在的各种问题，都及时找到对应组长指出并在群里同步，让其他组引以为鉴。尤其是在产品漏洞的研判、定级环节，是整个处置流程的关键节点，作为产品安全负责人一定要清楚演习期间的每个事件甚至细节，及时纠偏以免造成更大的不良影响。
• 推动问题闭环：还是在实战演习保障期间，产品应急组是四个班次，每个班在交接班时都需要review交接报告，多次强调当班事儿当班闭，但不同组别的执行情况却相差较大。平时主动、负责的组长在这时表现得更好，太技术的组长相对做的差，这大概率是认知问题，但这其实又是做好事情的基本准则。

内部资源

原文始发于微信公众号（我的安全视界观）：演习后对工作技能的复盘总结