作者：来自 Elastic Roberto Arico
团队如何将价值拱手让人，以及这样做需要付出什么代价
凌晨 3 点。值班工程师收到告警：支付处理服务器 payment-processor-01 的中央处理器（CPU）使用率达到 97%。他们打开可观测性平台，查看指标峰值，重启主机，然后关闭工单。
但就在六个小时前，一名攻击者已经在同一台主机上部署了一个加密货币挖矿程序，并将它伪装成内核工作线程，在每隔 15 分钟向 Monero 挖矿池发送信号的同时，悄悄耗尽计算资源。运维工程师完全没有看到这些情况。安全团队也没有看到 CPU 告警。而那个本应该写着 "已确认威胁 ------ 立即隔离主机" 的工单，最终却以 "已解决：重启" 关闭。
这个场景并非假设。它每天都在各个组织中上演，并不是因为人们没有认真关注，而是因为那些本可以揭示威胁的数据，存在于一个完全不同的平台中，没有人想到要去查看。
运行 2 个（或更多）平台的真实成本
当组织为可观测性和安全分别运行不同的工具时，从纸面上看，这种划分似乎很合理。运维团队关心正常运行时间和性能。安全团队关心威胁和合规性。为什么一定要强迫他们共享一个平台？
然而，攻击者并不会各司其职。
现代威胁的设计目标就是让它们看起来像普通的基础设施噪声。加密货币挖矿程序伪装成内核进程。数据外泄任务看起来像正常的出口流量。遭到入侵的 Web 服务器产生的内存模式，与内存泄漏产生的模式完全相同。当可观测性数据和安全数据分别存在于不同系统中时，这些威胁就会保持不可见，因为任何一个团队都无法看到完整的情况，而平台之间的空隙，恰恰就是攻击者藏身的地方。
但平台分离带来的并不仅仅是可见性问题。它还会悄悄造成成本重复。
这种成本重复很容易被忽视，因为两个独立团队正在对同一批底层事件进行两次存储和处理：一次用于可观测性，一次用于安全。被摄取到 SIEM 中的基础设施日志，往往就是为你的 APM 或指标平台提供数据的同一批日志。SOC 分析师查询的网络流数据，就是 SRE 团队用来调试延迟的同一批流数据。当这些平台彼此分离时，你需要为这些数据支付两次摄取费用，并存储两份数据。
而你的团队在任何时刻，都只能看到完整情况的一半。
相同的数据，两个世界
单一平台的意义，并不是强迫运维团队和安全团队共享一个 UI。而是让他们能够访问相同的底层数据，这样当告警触发时，完整上下文已经存在。
假设上面的场景中，可观测性指标和安全事件都存在于同一个 Elasticsearch 集群中，会发生什么变化？
显示 kworker/u8:2 消耗 97% CPU 的进程表旁边，就会存在一条安全事件，显示同一个进程在六小时前从 /tmp/.x11-unix/.kw8 启动，以 www-data 身份运行，而不是以 root 身份运行。针对 d0.pool.minexmr.com 的 DNS 查询，也存在于与 CPU 图表相同的集群中。
每隔 15 分钟发生的出站 TCP 连接，只需要一次查询，就可以与触发值班工程师告警的 Kibana 告警关联起来。
数据从来没有丢失。它只是存在于另一个盒子里。
当这些盒子变成一个盒子之后，AI agent 就可以在一次对话中跨两个领域进行推理，而不需要先查询一个独立的 SIEM，再查询 Elastic，然后手动交叉比对结果。它可以将可观测性索引和安全索引中的搜索统一为一种调查能力。
你可以先询问这台主机的 CPU 历史记录，然后询问它最近创建的进程事件。agent 不需要切换平台；它只需要进行搜索。
这就是一种能够在任何人打开第二个工具之前，自动将可观测性告警转化为安全调查的架构。
安全价值本来就在那里。只是你看不到它
安全团队最难接受的事实之一，是组织的可观测性数据中已经存在大量安全信号。
主机指标包含正在运行的进程列表。APM 跟踪记录服务之间的调用，可以揭示横向移动。基础设施日志包含 DNS 查询、网络连接和身份验证事件，这些数据可以直接映射到 MITRE ATT&CK 技术。
信号就在那里。缺少的是索引。
已经将可观测性数据摄取到 Elastic 的组织，实际上已经拥有了用于安全检测的原材料。Elastic Agent 为基础设施监控收集的进程遥测数据，与驱动 Elastic Security 主机检测规则的数据是相同的遥测数据。为 SRE 工作流程摄取的日志，与用于 SIEM 关联分析的日志也是相同的日志。
问题不是是否需要收集更多数据；问题是，你已经在收集的数据是否同时被用于这两个目的。
这正是通过搜索进行数据摄取成为倍增器的地方。
当来自任何来源的数据 ------ 云基础设施、本地主机、网络设备以及第三方 SaaS ------ 通过统一的摄取层进入 Elastic 后，它一落地就可以被每个团队查询。
寻找慢查询的可观测性工程师，与寻找异常进程行为的 SOC 分析师，查询的都是相同的索引。任何一个团队都不需要再保存一份独立的数据副本。
任何一个团队也不需要为这些数据重复付费。
在这个统一层之上再添加一个 AI agent ------ 一个能够在多个索引上使用工具，并在一次推理链中跨这些索引进行推理的 agent ------ 过去需要人类分析师花费一个小时手动完成的关联分析，现在可以在每次告警触发时自动在几秒钟内完成。
你的流程，而不是互联网上的流程
通用 语言模型 知道什么是加密货币挖矿程序。它可以用合理的方式描述隔离和遏制的最佳实践。
但它不知道你所在组织的 IRP-004 要求 SOC 负责人和支付运营团队在隔离任何支付主机之前进行双重审批。
它不知道你的 PCI-DSS 义务要求在确认事件后的四小时内通知合规团队 ------ 不是 24 小时，不是 "尽快"，而是四小时，并且这个要求已经明确记录在你自己的政策中。
它不知道你的网络隔离流程使用 VLAN PAYMENT-QUARANTINE，也不知道你的取证团队要求在任何修复操作开始之前，先创建一个带有事件引用标识的磁盘快照。
这种具体性，是 "你可以直接采取行动的建议" 和 "你必须重新解释之后才能采取行动的建议" 之间的区别。
在受监管行业中，重新解释会带来风险，例如做出错误决定、错过通知窗口，或者遗漏记录某个步骤。
答案并不是使用你的内部文档训练 模型 ------ 这些文档会发生变化，有版本控制，而且可能受到访问限制。
答案是将你的事件响应手册放入 Elasticsearch，并为你的 AI agent 提供一个针对该索引的搜索工具。
这就是最实用形式的搜索：它不是供人浏览的 UI，而是一种检索机制，让 AI agent 在需要的时候，以你的实际流程作为其推理依据。
当 agent 确认一台受到 PCI-DSS 管辖的主机上存在加密货币挖矿程序时，它不会依赖通用知识。它会搜索流程手册，检索 IRP-001 和 IRP-004，然后直接根据你的安全团队和支付团队编写并批准的步骤得出建议。
"隔离主机" 会变成：
"应用 PAYMENT-QUARANTINE 安全组，只允许来自取证 VLAN 的入站流量，获得 SOC 负责人和支付运营团队的批准，并在四小时内通知合规团队。"
每一条建议都可以追溯到某份具体文档中的具体章节。
这不仅仅与合规有关。它还让 AI 的建议具备可审计性。
当监管机构询问某项决策是如何做出的时，答案不再是"模型建议这样做"。
而是：
"agent 检索了 IRP-004 第 3.2 节，并按照其中的流程执行。"
这就是一条你可以进行辩护的证据链。
同样的原则也适用于安全流程手册之外的内容。
产品运行手册、升级矩阵、供应商 SLA、监管义务以及变更流程，都决定着你的组织如何响应事件。
将这些内容摄取到 Elasticsearch 中，就可以让 agent 将这些指导内容作为有依据、可检索的上下文使用。
你并不是在训练模型；你是在给它一个知识库，并教会它如何搜索。
"更好地协同" 到底意味着什么
对于可观测性和安全来说，跨领域的 AI 调查能力，才是统一平台与两个独立平台之间真正有意义的区别。
一个同时拥有可观测性索引和安全索引搜索工具的 AI agent，可以发现消耗 97% CPU 的内核工作线程其实是一个加密货币挖矿程序，因为它能够在同一条推理链中同时查询指标和安全事件。
如果分别在两个独立平台上运行两个独立的 AI agent，然后希望它们能够互相通信，是无法实现这种能力的。
这要求数据位于同一位置，可以一起查询，并且处于同一个 上下文窗口 中。
凌晨 3 点收到告警的运维工程师，不应该还需要知道应该检查哪个平台。
在他们打开第二个工具之前，结论就应该已经出现。
从 CPU 告警，到确认威胁，再到创建案例的完整审计轨迹，都应该存在于同一个地方，并且已经准备好满足组织需要满足的所有合规要求。
不要为数据支付两次费用；让你的数据发挥双重作用。
如果你的团队正在为可观测性和安全运行不同的平台，那么隐藏在两者之间空隙中的威胁，并不是"会不会发生"的问题；而是"什么时候发生"的问题。
本文中所描述的任何功能或特性的发布及发布时间，均由 Elastic 自行决定。目前尚未提供的任何功能或特性，都可能无法按时交付，也可能根本不会交付。
在这篇博客文章中，我们可能使用或提及了由其各自所有者拥有和运营的第三方生成式 AI 工具。Elastic 无法控制这些第三方工具，也不对其内容、运行或使用承担任何责任或义务，也不对因你使用此类工具而可能产生的任何损失或损害承担责任。在使用 AI 工具处理个人、敏感或机密信息时，请务必谨慎。
你提交的任何数据都可能被用于 AI 训练或其他目的。无法保证你提供的信息会得到安全或保密的处理。在使用任何生成式 AI 工具之前，你应该了解其隐私实践和使用条款。
Elastic、Elasticsearch 及相关标识均为 Elasticsearch B.V. 在美国及其他国家/地区的商标、标识或注册商标。所有其他公司名称和产品名称均为其各自所有者的商标、标识或注册商标。
原文：The security attack hiding in your unified data | Elastic Blog