From tool procurement to platform architecture: Rethinking the SOC for machine-speed threats
TL;DR · AI 摘要
传统SOC架构无法应对AI加速攻击,需转向统一平台架构以提升响应速度和自动化能力。
核心要点
- 攻击者可在1分钟内通过AI实现域控制,传统SOC工具碎片化导致响应效率低下。
- AI模型依赖统一数据,碎片化数据使AI推理错误率提升4.5倍。
- Elastic提出统一数据平台,结合AI实现自动化攻击面分析。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- SOC架构转型
- 碎片化问题
- 工具间数据摩擦
- 手动数据聚合
- AI局限性
- 依赖统一数据
- 错误推理
- Elastic方案
- 统一数据平台
- AI实时分析
金句 / Highlights
值得收藏与分享的关键句。
攻击者使用AI可在1分钟内实现从初始访问到域控制,传统SOC工具无法应对。
91%的安全团队将严重事故归因于工具间的数据摩擦。
碎片化数据使AI模型推理错误率提升4.5倍,相当于传统钓鱼攻击的点击率。
重新思考SOC:从工具采购到平台架构 | Elastic Blog
从工具采购到平台架构:为机器速度威胁重新思考SOC
作者
Joe DeFever
2026年7月27日
- 在Twitter上分享 在Twitter上分享
- 在LinkedIn上分享 在LinkedIn上分享
- 在Facebook上分享 在Facebook上分享
- 通过电子邮件分享 通过电子邮件分享
- 打印本页 打印
攻击者速度与防御者准备度之间的差距正在扩大。借助AI,攻击者现在可以在不到一分钟的时间内从初始访问扩展到对整个域的控制。1 由大型语言模型生成的网络钓鱼活动的点击率是传统方法的4.5倍。2
大多数企业的SOC并非为此节奏和精度而构建。它们是通过十年来逐个工具采购点解决方案拼凑而成的:这里部署一个SIEM,那里部署一个XDR,在此基础上附加一个SOAR,同时积累着越来越多的仪表板,而分析师根本没有时间进行整合。其结果是一种在对手甚至到达之前就已给防御者带来负担的安全架构。
对于安全团队而言,2026年值得思考的问题不是下一步该购买什么产品,而是底层架构是否能够支持AI时代防御所需的敏捷性、透明度和经济性。
安全运营的碎片化税负
数据碎片化不是一个审美问题,而是一个影响运营和财务的实质性问题,这在每起事件的时间线中都会体现。
在主动调查期间,分析师平均需要操作11个安全控制台,91%的安全团队会将严重事件直接追溯到不连贯工具之间的摩擦。3 SOC团队成员每周花费大量时间手动在这些工具之间汇总数据。这固然是一个效率问题,但更重要的是,这是由架构选择直接导致的风险暴露。
财务层面的负担更甚。按终端设备计费的模式迫使覆盖范围决策变成预算决策。历史数据的重新水化费用会在关键时刻(需要完整上下文时)制造盲区。独立的SOAR授权将自动化变成了一项单独的条目,而非原生能力。所有这些都是供应商强加的税费,悄无声息地将风险从供应商的资产负债表转移到了您的身上。
为什么AI无法修复碎片化的基础
行业对碎片化的应对方式是将AI叠加在现有架构之上。但这种方法已经显示出其局限性。
无论是分类系统、机器学习检测器还是智能代理推理框架,AI模型都依赖于对历史上下文的统一访问。当遥测数据分散在数十个系统中且格式不一致时,模型会继承与人类相同的盲点。这与其说是为自主推理打下坚实基础,不如说是在为昂贵的幻觉构建基础。
对于安全团队而言,在碎片化数据基础设施上进行的AI投资将无法达到预期的商业价值。检索增强生成(RAG)、智能代理工作流和行为分析都假设模型能够实时跨整个攻击面进行推理。如果底层数据无法就地查询,AI层将成为另一个孤岛,而非解决方案。
架构的转折点
两个信号表明架构问题正在从理论讨论转向采购实践。
- 采用压力:近三分之二的组织正在安全运营中尝试使用AI代理,但不到四分之一的组织已将其部署到生产环境。这一差距反映了在非原生设计的基础设施上运行自主代理系统的困难。治理模型、透明度要求和成本控制正在迅速成熟,但它们需要原生支持这些功能的架构。
- 高管期望:80%的首席信息安全官(CISO)在其2026年预算中将AI驱动的安全作为优先事项。但董事会并未批准用于渐进式改进的预算,他们期望在检测平均时间(MTTD)、响应平均时间(MTTR)和分析师留存率方面实现可衡量的改进。使用为预AI威胁模型设计的架构来满足这一期望的可能性极低。
开放统一安全架构的实际要求
为AI时代构建的平台与在SIEM上附加AI功能的系统有本质区别。评估架构方向的安全团队应要求供应商满足以下具体标准:
- 跨域统一遥测:终端、身份、网络和云信号统一流入单一检测层,而非在查询时拼接的多个独立检测层。
- 开放标准作为核心要素:原生支持OpenTelemetry(OTel)和Elastic Common Schema等开放架构和框架,使一次编写的安全检测规则可跨环境通用。
- 原地查询而非持续ETL:分析师无需重新水合或迁移项目,即可直接跨热数据、温数据和归档数据层级运行单一查询。
- 与模型无关的透明AI:每个自主决策都会生成可审计的工具调用记录、证据获取过程和推理逻辑。
- 原生自动化而非附加的SOAR:响应动作内置于平台中,因此隔离措施不依赖在活跃事件中可能失效的脆弱集成。
- 跨监管边界部署灵活性:提供本地部署、云部署、混合部署和物理隔离选项,满足GDPR、HIPAA、DORA或PCI DSS等监管要求组织的需求。
每个标准都修正了工具采购方法的特定结构性缺陷。综合来看,它们定义了"统一"在营销类别之外的实际含义。
自主运营:从警报管理到攻击中和
当架构正确时,运营模式终于可以发生根本性改变。这正是自主AI从概念走向生产的关键转折点。
自主安全运营平台并非完全自主的SOC。这一区别至关重要。自主系统会将人类排除在流程之外,在安全领域这既不负责也难以审计。自主代理系统则将人类置于流程核心:平台负责调查、关联并制定响应方案,而分析师则审查证据、做出判断并批准行动。
这种实际差异体现在事件时间线中。在传统SOC中,三个相关警报(例如可疑登录、异常进程执行和异常外发连接)可能在几秒钟内分别出现在三个不同工具中,需要数小时才能关联。而在自主模型中,它们会以单一高优先级攻击链的形式出现,且推理轨迹已预先构建。从首个警报到获得批准的响应的总时间可大幅缩短。
对安全团队而言,这将运营指标从"已处理警报数"转变为"已中和攻击数"。
为未来构建SOC
在接下来的24个月内能够成功前进的安全团队,不会是那些拥有最大、最昂贵工具库的团队。而是那些架构本身就能原生支持速度、透明度和智能操作的团队,而不是将这些作为后期添加的功能。
这种转变始于对当前技术栈的坦诚评估,明确识别出哪些环节给防御者带来了负担:因定价导致的覆盖范围缺口、因集成摩擦导致的响应延迟、因数据碎片化而受限的AI计划。每个问题都是可解决的架构难题。解决这些问题,正是区分能够跟上AI驱动威胁的SOC,与持续落后的SOC的关键。
若想深入了解开放统一架构如何重塑检测与响应能力,请阅读我们关于如何构建统一开放安全平台的文章。
来源:1 TechRadar,《以机器速度实现安全:为何SOC必须为AI时代重建》,2026年6月。2 The Register,《微软称AI使网络钓鱼效果提升4.5倍》,2025年10月。3 Microsoft,《SOC现状报告》,2025年。4 Ctech,《CISOs将2026预算投入AI,随着网络安全优先级的转变》,2026年2月。
本文中描述的任何功能或功能的发布和发布时间表均由Elastic单独决定。任何当前不可用的功能可能无法按时或根本不会交付。
在本文中,我们可能使用或引用了第三方生成式AI工具,这些工具由其各自所有者拥有和运营。Elastic对第三方工具没有任何控制权,也不对这些工具的内容、操作或使用承担任何责任或义务,也不对因使用这些工具而可能产生的任何损失或损害负责。在使用AI工具处理个人、敏感或机密信息时,请务必谨慎。您提交的任何数据可能用于AI训练或其他目的。无法保证您提供的信息将被安全或保密保存。在使用任何生成式AI工具之前,请务必了解其隐私政策和使用条款。
Elastic、Elasticsearch及相关标识是elasticsearch B.V.在美国和其他国家/地区的商标、标志或注册商标。所有其他公司和产品名称均为其各自所有者的商标、标志或注册商标。