如何提升威胁检测能力?——specterops漏斗模型介绍

up:: [[ Blue Team能力建设 ]]-检测工程方法论 Detection Engineering Methodology

  • 背景

    • SpecterOps在与客户合作构建威胁检测和响应能力的过程中,发现两个痛点问题:1、人力有限,无法响应每一个安全事件;2、检测响应流程中理想与现实的脱节。因此发明了漏斗模型(Funnel of Fidelity),量化了在不同阶段,不同角色所担任的职责是什么。随着模型从左到右层层过滤,安全事件分析的深度和真实度会逐步增加。
  • 漏斗模型

    • 在威胁检测和响应中,我们的目标是如何高效利用有限的资源来达成目的,因此需要过滤掉无用的信息,把注意力集中的大概率为真的安全事件上。漏斗模型包含了数据收集、威胁检测、安全分析、事件调查和修复,每个阶段都是检测和响应程序的关键组成部分,如果只重点关注/忽视某些阶段,则会导致漏斗的流动出现问题,如:
      • 没有收集管控遥测数据的SIEM/SOC平台,或收集不全、覆盖不足、解析不够
      • 威胁检测能力不足,无法有效产生可以用来调查的安全告警
      • 没有足够的安全事件响应计划和演习,虽然可以检测到攻击,但无法以可靠的方式对其进行补救
    • 下面是漏斗模型的可视化表示,将箭头的大小想象为每个阶段必须处理的输入数量。过滤发生在每个彩色环上,以减少传递到流程下一步的通用事件的量级。
      • 漏斗模型由五个阶段组成:数据收集、威胁检测、安全分析、事件调查和修复。每个阶段采用前一阶段生成的输入,执行某种过滤或降噪,并为下一个阶段生成输出。理想情况下,每个阶段都允许对相关事件进行更深入或更多的手动分析,因为不相关的事件都会被过滤掉。下面会深入讲一讲各个阶段,包括了负责的角色、输入和输出。
    • 阶段一:日志收集
      • 角色:数据工程师
      • 输入:探针/Agent等Sensor
      • 输出:事件
      • 日志收集是威胁检测和响应过程中最基础的部分,提供了有关整个环境中发生的活动的上下文信息。如果没有数据,几乎不可能检测到恶意活动。成熟的安全团队应该应努力集中尽可能多的遥测数据,以支持后续的检测和响应。例如,Windows 事件日志在本地生成和存储,但必须进行转发收集才能发挥价值。
    • 阶段二:威胁检测
      • 角色:检测工程师
      • 输入:事件
      • 输出:安全告警
      • 通过集中相关事件,检测工程师定义检测逻辑来识别与安全威胁相关的事件。检测阶段的目标是将日志收集阶段的数百万乃至数亿的事件减少到数百甚至数千个安全告警,这些告警将在分析阶段进行分析。这些检测方法通常是工程师在和安全事件/漏洞的交互过程中产生的,并通过程序自动化的方式部署,以生成安全告警。
    • 阶段三:安全分析
      • 角色:安全分析师
      • 输入:安全告警
      • 输出:安全事件或者线索
      • 安全告警是检测逻辑的产出物,有一定数量的误报是合理的。在安全分析阶段,安全分析师将告警分类为恶意、正常和未知;恶意告警会被标识为安全事件,并发送到阶段四进行响应处置,而未知告警则被标识为线索,并发送到事件调查阶段,因为它需要额外的审查。
      • 这一阶段通常能难实现自动化识别,需要人工介入分析,但这就意味着能力、经验、上下文信息的不足会导致分析过程难以标准化。能力和经验需要招聘优秀的人才,并持续学习培养;而上下文信息不足会使分析师很难理解攻击的背景信息、产生告警的检测逻辑、完整的攻击链条以及应该如何识别恶意和正常。我们可以通过使用有完备信息的威胁检测框架(如 如何提升威胁检测能力?——Palantir威胁检测框架介绍 )来缓解这些问题。
    • 阶段四:事件调查
      • 角色:安全分析师
      • 输入:线索
      • 输出:安全事件
      • 安全分析阶段用于消除误报,并产生可控数量的未知事件(可能为个位数或两位数)。调查阶段用于收集在检测或分析阶段可能不可用的其他上下文。这可能涉及更多手动和可扩展性较低的分析,例如文件系统分析、内存取证、二进制分析等,以帮助识别安全事件的真正目的。由于前几个阶段发生的噪音减少,因此可以有足够的人力进行这种额外的审查。
    • 阶段五:修复
      • 角色:应急响应工程师
      • 输入:安全事件
      • 输出:N/A
      • 一旦确认发生安全事件,就必须开展补救活动。在此阶段,应急响应工程师会确定安全事件的范围并从系统和网络中消除影响。许多组织会与第三方合作完成补救活动并确保它们及时完成。
  • 什么是威胁检测?

    • 在许多组织中,检测的概念往往非常微妙。出于这个原因,我们必须区分微观的检测(编写检测逻辑以发现潜在恶意事件的过程)和宏观的检测(从告警到补救的过程)。从宏观意义上讲,攻击必须导致某种补救活动,否则都被认为是被动检测而已。下面,我们将探讨两个关于检测概念混淆的案例。
    • case 1
      • 在攻防对抗演练过程中,防守方在SIEM/SOC发现了攻击方的相关事件,然后就宣布:“我们成功抓到了攻击方!”。但其实他们虽然收集了与该攻击相关的信息,但尚未创建检测逻辑来检测该活动。这不能算是有效的威胁检测。
    • case 2
      • 在攻防对抗演练过程中,防守方已经对特定的攻击技术构建了检测逻辑,如Kerberoasting,虽然触发了安全告警,但安全分析师对 Kerberoasting 的了解不够,无法区分中正常请求和恶意攻击。虽然在微观上确实检测到了攻击,但在宏观上,这并不是有效的威胁检测。
    • 总结
      • 漏斗模型的一个巨大好处是我们可以诊断故障发生在哪个阶段,在case 1中,似乎有足够的日志收集,但缺少威胁检测能力,我们可以通过使用在当前环境中收集的数据,来设计对应的威胁检测的策略。 在case 2中,我们看到系统生成了安全告警,但在分析阶段失败了,为了解决这个问题,我们可以专注于构建告警文档和培训帮助分析师完成工作。这两个例子都不应被视为威胁检测和响应的失败。相反,它们应该被视为改进整个过程的机会。
  • 参考

    • https://posts.specterops.io/introducing-the-funnel-of-fidelity-b1bb59b04036

Notes mentioning this note