政府将SIEM定义为“用于改进安全问题检测和修复的单一系统”，但如果有多个SIEM会发生什么情况？
随着安全数据的爆炸式增长，以及大型SOC分析要求的日益复杂化，SIEM作为安全事件集中地的作用已被削弱。现在，新出现的趋势正在将问题从“孤岛过多”转变为“SIEM过多”。
这给安全运营带来了麻烦，因为两头在外并不比一头在外强。
Imperator Mar"gok, sorcerer king of the Gorian Empire
终端厂商备货SIEM
让我们来解读推动SOC依赖多个SIEM的趋势。我们将看到，这些强大的潮流可能会在未来数年内影响安全运营。
首先，所有Gartner EDR MQ领导者的共同点是什么？他们都打着XDR的旗号，开始销售SIEM。
CrowdStrike称我们已拥有下一代SIEM和日志管理工具
微软将向您销售简单而强大的SIEM解决方案
Palo Alto不喜欢其他人抄袭"XDR"，因此他们给SIEM起了个不同的名字，并写道SIEM解决方案将不断适应和发展
其他厂商也是如此。这些厂商都不满足于仅仅销售可对接Splunk或其他专用SIEM平台的终端Agent。
Splunk所面临的挑战很可能在这一行业趋势中扮演了重要角色。这家最近被思科收购的公司在安全事件管理领域的控制力超过了所有终端厂商的总和。但是，在许多人看来，Splunk每年约20亿美元的安全收入还有待争夺，有待成为厂商账单中的一个细项，而这个厂商正在你成千上万的终端上运行着。
技术进步也起到了一定作用，因为之前吸引SOC团队使用Splunk和Elastic的突破性搜索性能已经老化。CrowdStrike为Humio支付了4亿美元，而SentinelOne则以不到2亿美元的价格收购了Scalyr。PaloAlto从谷歌租用了大数据技术，而Trellix则选择了Snowflake。因此，这些跨界挑战者能够宣称拥有与纯粹的现有企业相当的能力。
我之所以说“声称”，是因为我们有理由对其康健状态持有一定的怀疑态度。在CrowdStrike贴上自己的商标之前，Humio还没有被企业广泛采用。Splunk在狩猎和威胁检测方面的大规模分析能力更胜一筹。终端厂商希望他们的搜索平台“足够好”，能够取代中小企业市场以外的SIEM。鉴于EDR厂商在每个企业都部署了成千上万的代理，他们很可能有机会证明这一点。
您的云随附SIEM
由于每家大型企业和政府机构现在都有公共云的足迹，因此采用多种SIEM的另一个重要原因是，每个主要的CSP都有自己的SIEM产品。AWS的安全湖产品仍处于早期阶段，但Azure和Google都在认真对待自己的产品。
两家公司都在相关的收购和开发上投入了数十亿美元。微软报告称，有数千家客户使用Sentinel，并为在该平台上保留Azure和Office365事件日志提供大量补贴。因此，许多企业选择使用CSP的内置SIEM，至少作为分析该平台日志的权宜之计。
Azure 数据收集为 Microsoft Sentinel 客户提供补贴
当SIEM只是个辅助时
有几个因素会阻碍这些新型SIEM在大型企业中取代Splunk。如果存在其中几个因素，XDR或云SIEM将作为辅助SIEM处于补充地位。
其他团队也使用数据：网络安全以外的团队也经常使用Splunk，包括IT和DevOps。收集到Splunk中的大部分数据也可能被这些团队使用，而这些团队在支持可观察性用例方面有自己的要求。
其他活跃的安全用例：Splunk可用于安全操作以外的安全用例，如漏洞管理、欺诈检测和法规遵从。
分析要求：企业检测团队需要进行大量的分析工作，包括关联、异常检测和行为建模。连接能力有限且没有数据科学支持的底层搜索技术无法提供完全替代所需的同等能力。
报告要求：Splunk仪表板可以非常壮观......许多安全领导者都依赖它们提供指标和趋势图。
云出口：只在一种云中提供的SIEM可能会带来过高的出口成本，并对企业使用的其他云中运出的数据造成合规性问题。
集成要求：混合环境和基础架构已部署数十年的企业有"长尾"集成要求。从Splunk转换过来需要大量的日志收集和规范化开发工作。
内容要求：作为意见很大的套件（如Palo Alto Networks）的一部分提供的解决方案往往会针对其产品进行优化。第三方EDR或CNAPP可能很少或根本没有预建内容。建立和维护有效规则和关联所涉及的工作将由各个安全团队承担。
除了这些Splunk可能会继续存在的原因外，还有网络的软肋。许多安全分析师在Splunk专业知识和认证方面投入很大，如果他们的Splunk退役，这些专业知识和认证就会过时。
对安全运营的影响
在多个SIEM（安全信息和事件管理）解决方案上工作所引发的问题并没有得到足够的关注。网络安全提供商Corelight，作为大量数据的生成者并且深知这一问题，在一篇名为《一个SIEM不够吗？》的文章中提到“防御者已经在部署一个次级SIEM”。
Anton Chuvakin在《与多个SIEM共存》一文中警告说，多系统设置的“复杂性及其脆弱性（由于数据流集成需求和检测内容组织）是致命的。复杂性会破坏安全。”但是，上述趋势需要我们更深入地分析这些危险。
首先，跨多个SIEM检测威胁更加困难。攻击者不会局限于环境的某一部分；他们会通过电子邮件攻击终端，然后转向云控制平面，从那里通过网络提取数据。仅限于其中一个区域的传感器无法可靠地识别正在发生的攻击。
防御者还必须应对在不同资源库中管理的数百个检测。大规模的检测工程需要一个包含版本控制、测试和可重复流程的生命周期，以确保检测按预期运行。这在单个平台上已经很难实现，而在多套检测规则中则不太可能成功。
想想当一个新的零日漏洞成为头条新闻时会发生什么。检测工程师会争分夺秒地确保立即识别、控制和缓解利用企图。比较不同SIEM提供商的覆盖范围（例如，一个在Azure，一个在AWS）需要团队手动确认两者都覆盖了相关服务和TTP。
考虑到每种检测和响应解决方案可能使用不同的语言及其专有的规则语法和格式。团队可能会倾向于在分析师之间划分责任，一些分析师专门负责SIEMA，另一些则负责SIEMB。在大规模应用中，编写出色的查询对于优化性能至关重要，而这种专业技能很难在多个解决方案中进行开发。
确保数据质量也是一项挑战。如果没有一个中央SIEM，安全操作就会变得非常复杂，难以确保预期的数据集始终如一地到达。维护数据模型也是如此，因为对上游数据的更改必须在不同位置进行。统一的流水线（不局限于某个SIEM）在这方面有所帮助，但数据质量仍会受到不同系统中不同的保留策略和修改的影响。
在旋转的转椅上，事件响应速度较慢，效率较低，调查需要在不同的搜索控制台中进行。每一组结果都可能代表攻击的一部分，必须手动调节成统一的时间线。当攻击跨越大量时间和资产时，这就变得异常困难。
最后，最重要的自动化目标也受到了巨大冲击。每个SIEM都需要通过一套针对独特数据模型运行的不同API进行单独集成。针对一组警报开发的Playbook需要针对另一个SIEM监控的并行环境从头开始构建。试图利用数据科学和机器学习来自动执行使SOC疲于奔命的常规任务，可能会在一个SIEM或另一个SIEM中得到支持，但无法在不同系统间移植。
总结
安全运营领导者应注意使用多个SIEM的弊端。虽然急于求成的厂商可能会轻描淡写地描述使用辅助SIEM带来的困难，但买家在计划期间应花时间与部署了同一套多SIEM的类似组织进行沟通。讨论的关键问题应包括检测保真度、规则管理复杂性、确保数据质量、调查工作量和自动化成功率。虽然行业趋势使采用多个检测和响应平台变得越来越有诱惑力，但必须权衡潜在的成本节约与“双头”方法固有的风险和复杂性。
原文链接：
https://www.omeronsecurity.com/p/the-two-headed-siem-monster
往期回顾
网络安全搞平台化，可能吗？
ToC的安全赛道，活得下去吗？
炒作？警钟？警惕网安营销中的FUD宣传套路
关注「安全喵喵站」，后台回复关键词【报告】，即可获取网安行业研究报告精彩内容合集：
《网安供应链厂商成分分析及国产化替代指南》，《网安新兴赛道厂商速查指南》，《网安初创天使投资态势报告》，《全球网络安全创业加速器调研报告》，《网安创业生态图》，《網安新興賽道廠商速查指南·港澳版》，《台湾资安市场地图》，《全球网络安全全景图》，《全球独角兽俱乐部行业全景图》，《全球网络安全创业生态图》
话题讨论，内容投稿，报告沟通，商务合作等，请联系喵喵mew@z1-sec.com。
声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
