作者：来自 Elastic Smriti
你们的 SIEM 真的准备好了吗？一种新的验证方式
你已经完成了很多工作。日志正在流入，规则已启用，代理已部署，仪表板也已经存在。
但如果你的 CISO、审计人员或红队报告问你：你的 SIEM 是否已经准备好检测并响应那些真正重要的威胁，你能否自信地回答？
大多数团队都无法做到。并不是因为他们没有构建出一个具备能力的环境，而是因为缺少一个能够把所有内容串联起来的统一视图：你拥有的数据、依赖这些数据的检测规则、数据流的健康状态，以及当分析师需要追溯三个月前的事件时，这些数据是否仍然可用。
这个差距在没有出问题之前是不可见的。一条数据管道静默失败，在一次正在进行的入侵中造成了六小时的盲区。一条检测规则在某个从未真正接入数据源的情况下运行了数月。当审计人员要求提供日志保留证明时，答案分散在不同人的记忆和上一季度的电子表格中。
我们构建了 SIEM Readiness 来弥合这一差距。
表格问题
如果你和任何安全运营中心（security operations center - SOC）经理谈论他们如何跟踪运营准备状态，你很可能会听到类似的故事。
覆盖范围跟踪存在于电子表格中，可能每季度才有人更新一次。管道健康状态只有在出问题时才会被检查。保留策略是在初始部署时设置的，之后就再也没有审查过。检测工程师基于规则库中可用的内容启用规则，但并不清楚所需的数据源是否真的已经接入。
每个团队都在用不同工具、不同节奏孤立地回答准备度问题。SOC 经理有覆盖矩阵，平台工程师监控摄取速率，合规经理在每次审计前手动收集保留证据。没有人拥有全局视图，而全局视图才是关键。
从基础开始：可见性健康（Visibility Health）
SIEM Readiness 是 Elastic Security 中的一项新能力（截至 9.4 技术预览版），它提供一个集中、持续更新且可操作的 SIEM 运行健康视图。
我们从可见性健康开始，是因为在评估检测是否有效、响应流程是否可用之前，你必须先确认底层数据是否真实存在、是否正确、是否在流动，以及是否被保留。可见性是一切的前提。
该准备度视图围绕现代 SOC 的五大日志类别组织：
- 终端 / 主机（Endpoint/Host）：进程、文件、注册表和系统级事件
- 身份（Identity）：认证、访问管理和目录服务
- 网络（Network）：防火墙、DNS、代理和流量数据
- 云（Cloud）：云服务商 API、配置和活动日志
- 应用 / SaaS（Application/SaaS）：业务应用和 SaaS 平台事件
在每个类别中，SIEM Readiness 会从四个维度评估健康状态：
- 覆盖率（Coverage）
- 质量（Quality）
- 连续性（Continuity）
- 保留（Retention）
1）覆盖率：你是否拥有检测所需的数据？
这是最基础的问题，并且在两个层面上运作。
- 在规则层面：SIEM Readiness 会检查每一条已启用的检测规则及其所依赖的数据源。如果你启用了一组需要 CloudTrail 的初始访问（Initial Access）规则，但 CloudTrail 并没有流入你的环境，那么这些规则只是 “名义上启用”，实际上永远不会触发。SIEM Readiness 不只是简单提示 “CloudTrail 缺失”，而是会指出：“CloudTrail 缺失，并且你有 23 条已启用规则（覆盖 6 个 MITRE ATT&CK 战术）依赖它。”
这种上下文会改变你的优先级判断。你不再是按字母顺序去接入数据源，而是优先接入那些能最大程度填补检测空白的数据源。
- 在类别层面：SIEM Readiness 会基于五大日志类别，对整体覆盖情况进行评估，并参考 MITRE ATT&CK、NIST CSF 和 CIS 基准。然而它是 “环境感知” 的 —— 如果你没有云基础设施，那么云覆盖不会被计入你的负面评分。你的准备度评分反映的是你的实际环境，而不是一个通用理想模型。
你可以做的事情：查看缺少数据的规则，识别能够填补最多缺口的集成，禁用不适用于你环境的规则，并生成一个案例（case）将接入工作分配给合适的团队。
2）质量：你的数据结构是否正确？
数据 “到达” 并不等于数据 “可用”。如果你的日志不符合 ECS（Elastic Common Schema），那么依赖 process.name 的规则将无法匹配，仪表板面板会显示空白，不同数据源之间的关联分析也会在无声中失败。
这是 SIEM 中最常见但也最隐蔽的一类失败模式之一。数据确实存在，规则也已启用，一切看似正常，直到你发现字段不匹配，检测实际上从未真正生效。
SIEM Readiness 会在类别层面暴露 ECS 不兼容问题，为你提供一个高层信号，指出哪些数据类别存在映射问题。它并不是对字段级别详细分析的替代方案 —— Elastic 已经提供了 ECS Data Quality Dashboard 来完成这部分工作。相反，它更像是一个早期预警系统，告诉你“问题在哪里”，并提供直接链接让你深入排查。
你可以做的事情：查看受影响的数据流，修复字段映射，并优先处理那些质量问题对检测影响最大的类别。
3）连续性：你的数据是否真的在持续流动？
解析器配置错误、上游 schema 变更、凭证轮换后的权限问题——摄取管道都会失败。这些情况确实会发生。问题不在于失败本身，而在于这些失败是 “静默发生” 的。
一个丢失 5% 文档的管道不会触发告警，也不会有空白仪表板提示你问题存在。数据只是悄悄消失，而依赖这些数据的检测也随之静默失效。你往往是在分析人员调查事件时，才发现时间线中存在缺口。
SIEM Readiness 会监控管道失败率，并将超过 1% 阈值的管道标记出来。低于 1% 属于健康状态，高于 1% 则需要采取行动。
你可以做的事情：在 Discover 中查看失败情况，调查根本原因，并生成一个预填充的 case（案例）来分配修复工作，从而确保修复过程被跟踪，而不仅仅是被发现。
4）保留：当你需要数据时，它是否还在？
检测是实时的，但调查不是。
当分析人员在处理一个告警并回溯攻击者过去 90 天的活动时，数据必须仍然存在。当审计人员要求提供日志保留证据时，你需要的是一个不以 “我查一下” 为开头的答案。
SIEM Readiness 会基于来自 FedRAMP、NIST 800-53、SOC 2 和 ISO 27001 等行业标准，对你的保留策略进行评估。每个日志类别都有推荐的保留窗口 —— 终端与网络为 90 天，身份与云为 180 天 —— 而 readiness 视图会显示你在哪些方面未达标。
保留计算覆盖热（hot）、温（warm）和冷（cold）存储层级，因为只要数据被保留，无论存放在哪一层都算有效。真正重要的是：当有人需要时，数据是否仍然可用。
你可以做的事情：调整索引生命周期管理（ILM）或数据生命周期策略，导出用于审计准备的保留报告，并生成一个 case 来跟踪策略变更。
以行动为导向，而不仅仅是认知
这里有一个关于设计方式的说明，因为它很重要。
SIEM Readiness 中的每一个信号都对应一个可执行动作。不会存在让你看着图表然后疑惑 “那我该做什么？” 的情况。每一个指标都会连接到下一步行动——接入数据源、修复管道、调整策略，或创建一个 case 来分配工作。
评分是“环境感知”的。你的 readiness 视图反映的是你的真实环境，例如你使用哪些云服务商、部署了哪些集成、哪些数据流是活跃的。不适用的类别不会被纳入分母，也不会被惩罚。
并且它是基于遥测数据驱动的，而不是基于表单填写。SIEM Readiness 会从你的数据中推断你的环境，而不是让你填写配置表单告诉系统你有什么。它直接观察实际存在的内容。
SIEM Readiness 的发展方向
可见性健康（Visibility Health）是基础，它回答的是：在当前数据条件下，你的 SIEM 是否能够检测威胁？
但 readiness 的问题更广，我们正在构建完整答案。
检测准备度（Detection Readiness）是下一阶段。除了“你是否有数据”，还包括 “你的检测是否真正有效？” 哪些已启用规则从未触发 —— 是配置错误，还是你的环境确实很干净？哪些 MITRE ATT&CK 战术有良好的规则覆盖并由健康数据支撑，哪些存在缺口？在你的环境下，哪些预构建规则应该启用但尚未启用？Detection Readiness 将把规则管理从“浏览规则库”转变为一种以覆盖为驱动的引导式流程。
响应准备度（Response Readiness）将随之而来。你的响应流程是否可运行？告警被分流和案例被处理的速度如何？你与工单系统和 SOAR 平台的连接是否健康？哪些告警类型已经实现自动响应，哪些仍然需要分析人员每次手动介入？Response Readiness 将打通从数据到检测再到行动的完整闭环。
三者合在一起，将回答完整问题：
- 可见性 —— 你能检测到吗？（你是否拥有正确的数据？）
- 检测能力 —— 你会检测到吗？（你的规则是否有效？）
- 响应能力 —— 你能及时行动吗？（你的流程是否可执行？）
我们也在探索 AI 辅助的 readiness 洞察 —— 一种轻量级总结能力，用来突出最高风险并建议优先级行动。例如：“你的 Identity 覆盖较强，但 18% 的已启用规则缺少支持数据。接入 CloudTrail 将恢复 23 条规则的 Initial Access 覆盖。” 它不是自动修复，而是在需要时提供清晰的优先级指引。
帮助我们把它做对
我们发布 SIEM Readiness，是因为我们相信 “我的 SIEM 准备好了吗？” 这个问题，应该有一个清晰、持续、产品原生的答案 —— 而不是电子表格，不是季度审计前的紧急补救，也不是你自己搭建的向量搜索系统。
我们从可见性健康开始，因为它是一切的基础。检测准备度和响应准备度将在后续推出。
但每天使用它的团队最清楚它应该是什么样子。我们希望听到你的反馈：
你现在有哪些需要手动检查的内容，应该变成自动化？
你希望 SIEM 能回答哪些关于自身运行状态的问题？
什么会让这个功能成为你每天早上第一个打开的页面？
参与讨论：
如果你有反馈或希望优先实现的能力，可以通过 Elastic 客户团队提出，并让他们提交 SIEM Readiness 的功能增强请求。
如果你希望进行更深入的设计伙伴讨论，也可以联系你的 Elastic 团队，我们很乐意交流。
最危险的 SIEM，是看起来一切正常的那个。让我们确保你的确实如此。
本文所述任何功能或能力的发布与时间安排均由 Elastic 全权决定，部分功能可能不会按时交付或最终不予提供。
