提升效率显然可以节省时间和开销。除开这么明显的好处，还有一些其他隐形福利，比如减少人为失误、提升准确率、增加生产力等等。
然而不幸的是，在事件响应领域，缺乏效率却是常态。虽然有些很棒的安全团队想要在事件响应过程中引入效率，我们生活的世界流行的却是“剪贴”式事件管理。即便团队相当有才，想往事件响应过程中引入效率却也是举步维艰。
这并不是说就没多少人想要提升事件响应过程的效率，而是说，某种程度上而言，所有关于提升事件响应效率的讨论都没有产出什么太大的改变。个中原因有很多，比如到底是哪些领域让企业投入大量时间进行人工事件管理，大家的看法可能就存在差异。
或许把企业最需要往事件响应工作流中引入效率的领域列举一下，会对现状有所帮助：
1. 警报/事件和事故单/工作队列之间的智能映射
安全公司每天要处理的事件以十亿计，警报也能有数万到数十万条，但真正开出事故单需要纳入工作队列着手处理的，可能在几百条左右。警报通常是由覆盖一个或多个事件的逻辑自动产生的。虽然质量和精确度有待考证，但至少这个过程是相对自动化的。只是，到底哪些警报需要纳入工作队列呢?很不幸，这个甄别过程就相当不明确，基本上靠人工来做了。
2. 预判优先级
不先定个优先级就干等着众多警报加入到工作队列中，这种事无异于让我们的团队白白浪费大量时间在梳理成千上万个无意义的数据节点上。何不在警报变为工作量之前就先想想我们到底面临的是什么风险和威胁?在警报内容构建过程一开始就定下优先级不是很好吗?
3. 强化前期分析
为什么要对着一大堆上下文和意义都不明确的数据发愁?为什么不战略性地在数据构建过程初期就进行分析而产出高质量的警报和更有意义更富上下文的数据再发到工作队列呢?
4. 用户识别
分析警报的时候必定要识别用户。这一步完全可以自动化，不需要再由人工操作了。
5. 资产识别
理由同上。
6. 警报评估
大多数警报评估涉及的事项都差不多，我们甚至可能遵循定好的流程来筛查某类警报。这种重复性工作何不自动化呢?
7. 理解警报
评估警报的时候，我们至少要对当前发生的事情有个基本了解，而这通常涉及审查警报本身及相关支持性证据。为什么不把这些支持性证据自动加进来呢?
8. 抽取IOC
调查涉恶意代码或恶意链接的事件往往需要抽取攻击指标(IOC)。都2018年了，好歹把抽取工作自动化了吧!
9. 事件描述
决策需要上下文和对事件的理解。如果能把大部分事件描述工作给自动化了，难道不是更能省出时间来进行分析和事件响应了吗?
10. 分析
整个事件响应工作流中最能体现人类智慧的环节。于是，省省那些在Excel表格中剪切粘贴的无脑工作吧，我们可以做得更好的。
11. 识别感染/入侵方法
分析的成果之一，就是找出当前安全状态中的漏洞并补之。然而即便发现了漏洞，我们仍然需要一个系统一个系统地登录进去再执行漏洞修补动作。这么费事的过程，就不能统一执行了吗?
12. 转向
隔离出行为异常的主机后，我们就会转向研究这些主机最近都遭遇了什么。没错，这里面涉及一些剪切粘贴的工作，还有额外的查询之类的。
13. 查找相关行为
深入了解了正在处理的事件后，我们就需要转向可以使我们找出其他地方类似事件的工作了。于是，另一波剪切粘贴和更多查询袭来。
14. 识别/填补警报中的漏洞
如果错过了某些重要事件，我们就需要了解为什么警报机制中会出现漏洞，并将该漏洞堵上。该工作自然落在安全团队身上。但如果将来有工具可以更积极主动地指引我们识别出漏掉的事件，不是更好吗?
15. 识别根源
弄清事件产生根源非常重要，但这基本是个人工过程。如果能有些辅助措施，想必是很好的。
16. 改善安全态势
发现了新的恶意域名，自然就会想要封锁它或者导引到无害的地方挂起。当然，这些操作都是人工的。
17. 事故单里记下一切
没记录就没发生过。但事故单详录过程真的有必要做那么多剪切粘贴吗?
18. 报告
严重事件通常需要做事后报告。如果事故单里已经记录下了一切重要信息，为什么还要重复一遍这个过程来提交一份可以让人骄傲地上呈管理层、高管和其他利益相关者的报告呢?
19. 沟通
简明及时的沟通在事件处理过程中起着非常重要的作用。于是，如果能从事件处理系统自动生成要汇报的各种邮件，不是很美好的事吗?
20. 抽取经验教训
世上没有完美的安全项目。处理过的任何事件都可作为经验教训以供将来参考。但这种经验教训的抽取过程如果能有工具帮忙就更好了。
