我们可以自动化动作,而不自动化决策……
一直以来的反馈都表明,至少安全团队是非常渴求自动化的。但这种渴望受制于怀疑和恐惧。怀疑威胁检测的准确性,恐惧威胁控制或缓解响应自动化的后果,以及自动化出错可能造成的不良影响和破坏。
长期工作于网络安全领域的人知道,这种现象并不新鲜。反垃圾邮件和入侵防御系统(IPS)的承诺尚历历在目,对其异常和攻击检测能力的过度自信所造成的混乱,就开始啪啪打脸。
安全自动化
很多公司都有IPS,但却以非阻塞模式运行,直接降级成入侵检测系统(IDS)使用。而且这种趋势至今未减:公司企业引入自动化功能到现有技术中,比如安全信息及事件管理(SIEM)、终端检测与响应(EDR)、安全自动化与编配(SAO)解决方案等,但却不相信它们的自动化能力,仅仅在发送通知或执行威胁情报查询之类基本任务上应用自动化。
这基本上无视了检测功能已大幅改进的事实,尤其是在应用了行为建模和机器学习驱动的方法之后。真是应了那句老话:千万别尝试用技术来解决社会问题。因为问题本身就不是基于技术的,而是基于信任——或者信任的缺失。这里面涉及的3个基本原则是:
安全运营团队可评估风险影响,但评估不出对生产的影响
安全运营团队深居象牙塔内,专注在威胁的风险和影响上,难以建立并维护对生产环节现状的感知。受影响系统是不是任务关键的?系统是否不稳定?是否遗留系统?系统当前是用于处理年度财务报告,还是在被付费客户使用?这些问题,安全运营团队往往难以感知。
禁用无关紧要的用户账户看起来很简单,但该用户账户很可能是用于执行关键过程的。依赖、复杂性和未知因素,都是自动化的痛脚。这些正好是大多数安全运营团队要么缺乏要么信息过时的数据点——但却对事件响应或修复过程的执行方式有影响。这并不是说事件或漏洞根本不用处理,而是强调需要额外的时间或特定的方式进行处理。
可以自动化动作,但不自动化决策
当然,可被自动化的东西,远不止实际控制或修复响应过程。很多工作,比如事件优先级划分、额外所需信息及上下文的获取、利益相关者通知等,都可以被自动化。另外,若动作已经过审查,也是可以自动化的。最简单的场景里,这意味着向IT运营团队发送事件通知——包括问题描述、潜在影响、解决问题所需的动作等,然后请他们确认动作执行,或者拒绝执行自动化动作而手动处理。我们可以自动化动作,而不自动化决策。
可随信任与信心的增加而扩展自动化
IT运营往往过载,于是从安全运营到IT运营的传递,往往在响应上有长长的延迟。在诸如勒索软件之类的事情情况下,这种延迟意味着,是控制住局面还是只能灾难恢复的差别,是单纯的事件还是完完全全的数据泄露的差别。工作过载的一队人会反对能让自己更轻松的办法,这简直是违反人类直觉的事,然而,人性就是这样。不过,即便如此,我们依然可以帮助缓解疑虑和担忧,建立信任和信心。
方法就是:记录哪些动作是手工执行的——同个动作由人代替机器执行的次数,并计算出人和机器做同个动作在所消耗时间与资源上的差异。其思想精髓在于:如果多次接到需要相同手工动作的类似事件通知,那么此类事件便可以很安全地自动化处理。毕竟,我们有审计线索来证明这一点,也有数据来建立业务案例。更重要的是,我们也能收集数据,勾勒出哪些事务或位置不能安全地自动化。
或许在某个业务部门可以安全进行的自动化,在另一个业务部门就是完全不可接受的。自动化过程必须支持粒度,无论是指标收集,还是自动化配置时。理想状态下,不管使用哪种自动化技术,都必须支持该方法,并提供所需的各项指标。技术可以辅助建立信任,但最终,必须让你期望信任你的对象感受到。
本文作者:nana
来源:51CTO