没几个网络安全技术人员会声称自己的工作很轻松。总是工作比人多，总是干不完的活。但你有没有想过，这种现象背后都有些什么原因呢？
总有各种各样的因素让安全运营和事件响应工作不得不随时待命，7乘24小时全天候开工。但这种工作强度主要是由两大基本原因造成的：
警报疲劳：大多数公司仅仅是警报太多，误报太多，噪音太多。这让公司几乎不可能识别出真正的攻击信号，也没办法有效划分工作优先级。
缺乏上下文：即使是最佳警报系统也缺乏必要的上下文以支持有效决策，我们无法获悉正在处理的威胁性质是什么，又该进行怎样的响应。
虽然安全社区里不是每个人都对这些基本问题有所察觉，但确实很多人已经意识到了这些问题。警报疲劳和上下文缺乏问题由来已久，但该怎样改善呢？毕竟，仅仅是找出为什么很多公司觉得安全运营这么困难是不足够的。运营界或多或少知道这些问题的存在，但他们真正追求的，是建设性意见、技术、方法，以及，最重要的——解决方案。
可以通过叙事驱动的安全运营模型，来改善上下文缺乏问题。但即使是最高品质、最高精确性、最低噪音、最合理容量的警报系统，要打造合适的上下文环境，也是需要相当多元的数据集才能够提供所需的支持证据的。
叙事驱动或者是普通安全运营的最终目标，都是辅助产生明智的决策，并针对给定的事件警报，知道需要进行哪种类型的响应。下面三个因素是阻碍打造叙事驱动安全运营的三大基本挑战：
数据的多样性和现代安全环境的复杂性构建出了一个混乱的环境，身处其中的分析师们不确定该上哪儿去获得必要的丰富上下文信息；
很多安全系统的分析限制阻碍了分析师对数据进行精确的、有针对性的、深入的查询；
很多安全系统的性能限制意味着，最精确、最有针对性、最深入的查询往往比公司通常能接受的耗时要长上许多。
这糟糕的情况令手动打造叙事驱动的安全运营几乎是不可能完成的任务。那我们还有哪条路可以走呢？以前曾有人尝试过用脚本语言进行多种形式的增强。虽然不是完全版叙事驱动安全运营模型，也算是朝着最终目标迈出了第一步吧。不过，尽管用脚本进行自动化可以免去大量的重复分析劳动，还是有一些问题尚未解决：
脚本需要经常性维护和协调才能保持有效性，常常把分析师们的精力从数据分析和事件响应中抽离；
脚本功能难以建档，使运营持续性难以保证，尤其是在脚本作者离开公司的情况下；
同时具备写脚本能力的分析师比我们所认为的要少，公司想招聘到合适的技能配给就更难上加难了。
这并不是说脚本就不是安全公司的有效工具，事实上，某些情况下，它还真是。安全公司的工作效果和效率与其任务队列质量紧密相关，因为这是公司工作流的主要驱动力。任务队列的效果可以被警报疲劳和上下文缺乏给高度稀释掉。对于像任务队列这种安全公司工作效果的主要影响因素，难道我们不去寻求更好的东西吗？
最近出现的安全业务流程和自动化空间，给安全运营界带来了我们一直以来寻求的新的可能性。该空间给公司带来的几点好处包括：
通过关联，合并和连接多种警报的能力。这种能力，结合上改善信噪比的警报，可以将警报量大幅减少到可以管理的水平。
以自动化方式打造叙事驱动或部分叙事驱动安全运营的能力。这将解放分析师，将他们之前花在耗时耗力的重复性查询上的时间和精力投入到更高层次的活动中去，比如分析、事件响应和捕获。
更好的上下文提供的更及时明智的决策。
由于信噪比提升而带来的更短入侵停驻时间和更少的“漏报”入侵。
例行常见警报类别的自记录处理过程。
调查、记录和报告中的人为失误减少。
虽然安全运营和事件响应界当前正被警报疲劳和上下文缺乏压到不堪重负，未来还是可以期待一下的。的确，厂商满足我们期待的程度，以及公司将这些能力成功应用到运营上的程度，都还有待观察。但即便有这些考虑，安全业务流程和自动化解决方案还是具备很大潜力。
有一件事是确定的——现状不会一成不变。警报驱动的安全运营该淘汰了。
本文转自d1net（转载）
