安全自动化在于信任，而非技术

我们可以自动化动作，而不自动化决策……

[[197888]]

一直以来的反馈都表明，至少安全团队是非常渴求自动化的。但这种渴望受制于怀疑和恐惧。怀疑威胁检测的准确性，恐惧威胁控制或缓解响应自动化的后果，以及自动化出错可能造成的不良影响和破坏。

长期工作于网络安全领域的人知道，这种现象并不新鲜。反垃圾邮件和入侵防御系统(IPS)的承诺尚历历在目，对其异常和攻击检测能力的过度自信所造成的混乱，就开始啪啪打脸。

安全自动化

很多公司都有IPS，但却以非阻塞模式运行，直接降级成入侵检测系统(IDS)使用。而且这种趋势至今未减：公司企业引入自动化功能到现有技术中，比如安全信息及事件管理(SIEM)、终端检测与响应(EDR)、安全自动化与编配(SAO)解决方案等，但却不相信它们的自动化能力，仅仅在发送通知或执行威胁情报查询之类基本任务上应用自动化。

这基本上无视了检测功能已大幅改进的事实，尤其是在应用了行为建模和机器学习驱动的方法之后。真是应了那句老话：千万别尝试用技术来解决社会问题。因为问题本身就不是基于技术的，而是基于信任——或者信任的缺失。这里面涉及的3个基本原则是：

安全运营团队可评估风险影响，但评估不出对生产的影响

安全运营团队深居象牙塔内，专注在威胁的风险和影响上，难以建立并维护对生产环节现状的感知。受影响系统是不是任务关键的?系统是否不稳定?是否遗留系统?系统当前是用于处理年度财务报告，还是在被付费客户使用?这些问题，安全运营团队往往难以感知。

禁用无关紧要的用户账户看起来很简单，但该用户账户很可能是用于执行关键过程的。依赖、复杂性和未知因素，都是自动化的痛脚。这些正好是大多数安全运营团队要么缺乏要么信息过时的数据点——但却对事件响应或修复过程的执行方式有影响。这并不是说事件或漏洞根本不用处理，而是强调需要额外的时间或特定的方式进行处理。

可以自动化动作，但不自动化决策

当然，可被自动化的东西，远不止实际控制或修复响应过程。很多工作，比如事件优先级划分、额外所需信息及上下文的获取、利益相关者通知等，都可以被自动化。另外，若动作已经过审查，也是可以自动化的。最简单的场景里，这意味着向IT运营团队发送事件通知——包括问题描述、潜在影响、解决问题所需的动作等，然后请他们确认动作执行，或者拒绝执行自动化动作而手动处理。我们可以自动化动作，而不自动化决策。

可随信任与信心的增加而扩展自动化

IT运营往往过载，于是从安全运营到IT运营的传递，往往在响应上有长长的延迟。在诸如勒索软件之类的事情情况下，这种延迟意味着，是控制住局面还是只能灾难恢复的差别，是单纯的事件还是完完全全的数据泄露的差别。工作过载的一队人会反对能让自己更轻松的办法，这简直是违反人类直觉的事，然而，人性就是这样。不过，即便如此，我们依然可以帮助缓解疑虑和担忧，建立信任和信心。

方法就是：记录哪些动作是手工执行的——同个动作由人代替机器执行的次数，并计算出人和机器做同个动作在所消耗时间与资源上的差异。其思想精髓在于：如果多次接到需要相同手工动作的类似事件通知，那么此类事件便可以很安全地自动化处理。毕竟，我们有审计线索来证明这一点，也有数据来建立业务案例。更重要的是，我们也能收集数据，勾勒出哪些事务或位置不能安全地自动化。

或许在某个业务部门可以安全进行的自动化，在另一个业务部门就是完全不可接受的。自动化过程必须支持粒度，无论是指标收集，还是自动化配置时。理想状态下，不管使用哪种自动化技术，都必须支持该方法，并提供所需的各项指标。技术可以辅助建立信任，但最终，必须让你期望信任你的对象感受到。