“双SIEM”是个好主意吗？

点击蓝字 关注我们            ///

@GoUpSec

如今，越来越多的企业开始部署“双SIEM”，其中一个SIEM专门支持威胁搜寻/狩猎任务，这种“双SIEM”方案是否具有普适性呢？近日Corelight首席执行官布莱恩·戴尔撰文指出，并非所有企业都能实现/适用这种方法。戴尔就如下几个常见问题进行了分析解读：

很多公司部署单独的SIEM来搜寻威胁，为什么？

我们看到组织，尤其是金融服务、医疗保健、电信和政府等垂直行业的组织，热衷于部署单独的SIEM来搜寻威胁。其投资目的是减少总体响应时间。他们通过计划来完善其威胁追踪功能并启用内部分析计划。在这两种情况下，两者都依赖数据作为其环境基线的基础。威胁猎手使用该基线来发现异常，然后将它们归类为操作问题或威胁活动，并做出相应的反应。

分析程序基于数据来构建检测模块，通常是为了增加MITRE ATT&CK TTP的覆盖范围。在绝大多数情况下，这些程序都会产生一个良性循环：正确的数据可以实现更广泛的分析覆盖范围和更快的分析速度，从而缩短整体响应时间。

满足上述需求的数据需要能超出其检测技术生成的警报和IOC的深度和上下文。此类数据的数量总是比警报本身大得多。在当今的许多SIEM中，这种数据规模的增加推高了成本，无论是直接许可成本还是运营成本。因此，防御者正在转向辅助SIEM平台或数据湖来处理这些更高容量的应用程序。

为什么“双SIEM”并不适用于所有组织？

成本和复杂性！较大的组织有安全工程团队将安全数据湖连接到他们的主SIEM，这是一个两全其美的方法：警报的集中聚合；工作流、报告和培训也可围绕SIEM构建，同时又能使用安全数据湖中的专用分析或威胁搜寻“扩展”。这种集成方案的成本较高，小型组织往往无法负担，而且它们通常没有专门的工程团队，更不用说部署和维护安全数据湖的能力了。

有没有办法只部署一个SIEM，兼顾威胁搜寻？

绝对可以。虽然工作是相同的（启用威胁搜寻并通过分析扩大MITRE TTP覆盖范围），但较小的组织可以通过确定优先级来取得进展。首先，严格界定项目范围：定义需要更好覆盖的特定应用程序或在您的行业中最活跃的特定TTP。其次，使用开箱即用或免费提供的东西——像SIGMA这样的项目为各种TTP提供威胁追踪和SIEM查询。第三，使用行业标准数据和工具，这是您获得人才和培训的最佳途径。

较小规模的组织在这方面也有优势：他们通常会使用相同的分析师来执行事件响应和威胁搜寻。这些创造了一个良性循环，因为威胁搜寻有助于分析师更好地了解他们的环境，这也增加了他们在事件响应中的信心和执行力。较大的组织由于其规模，通常需要为两者创建专门的角色。

为什么区分威胁搜寻和事件响应很重要，最好的方法是什么？

事件响应和威胁追踪是密切合作的活动；唯一的问题是，需要根据组织自身的规模，确定如何使这种伙伴关系发挥作用。在一个或几个人的小团队中，每个分析师都将同时执行两种功能（事件响应和威胁追踪）。这是非常有效的，因为它有助于培养技能和加深对环境的洞察力——只要每周都确保足够时间来寻找威胁（否则救火任务会压倒重要的事情！）。

随着团队的发展，事件响应和威胁搜寻往往拆分成团队中的独立角色。随着这种增长，轮换角色以培养技能并分享对正在进行的工作的见解仍然很重要。在非常大的组织中，两者可以是独立的专业团队，这对于带宽和工具集优化非常有用，但我们需要在这些环境中努力工作以保持事件响应和威胁搜寻功能之间的高通信。

如何加强威胁搜寻和事件响应之间的沟通和反馈？

有三个主要的沟通信息流很重要，无论团队规模大小，都应该绘制出这些沟通模式和所有技术堆栈：

首先，事件响应团队需要对威胁猎手进行有关当前攻击模式的培训。这有助于威胁搜寻团队专注于与日常事件响应相关的问题。

其次，威胁搜寻团队需要分享他们在环境中看到的异常情况的见解，以便事件响应团队能够快速分辨什么是正常的，什么是异常的。

最后，威胁搜寻的输出需要在搜索或分析模型（SIEM查询、Spark notebook等）中进行编码，以服务于事件响应团队。

上述三个信息流有助于无缝对接事件响应和威胁搜寻功能的学习周期。

END

相关阅读