面向云原生与AI驱动威胁的多层检测体系：从遥测融合、行为建模到可解释告警压缩的2026年研究

1. Introduction

检测是网络安全体系中最早被工程化、也是最晚被真正“闭环化”的能力之一。长期以来，业界将检测理解为“在日志里找坏事”，但在2026年的实际攻防环境中，这种朴素理解已经明显不足。现代攻击链通常并不依赖单一高危漏洞的立即利用，而是通过身份欺骗、令牌窃取、权限边界穿越、云 API 滥用、供应链污染、低频数据外传以及对生成式 AI 系统的提示注入逐步推进。换言之，检测的对象不再只是恶意进程或可疑 IP，而是跨越终端、网络、身份、容器、SaaS、CI/CD、知识库和 AI 工作流的行为轨迹。攻击者的优势在于“分散、低速、合法外观”，防守者的任务则是把这些碎片化事件重新拼接成可验证的攻击叙事。

2026 年的检测问题与十年前最大的差异，在于遥测的数量、粒度和语义维度都发生了跃迁。以往 SOC 主要依赖 SIEM 中的主机日志、代理日志和 IDS 告警；如今，检测栈必须吸纳云控制面事件、身份提供商审计记录、Kubernetes 审计日志、API Gateway 访问日志、eBPF 级系统调用轨迹、邮箱与协作平台活动、CASB/SSE 流量摘要，以及 AI 应用层的提示、上下文与工具调用元数据。与此同时，数据合规、隐私保护与成本约束又限制了“全量保留、全量上云、全量建模”的简单方案。于是，检测不再只是一个模型问题，而是数据工程、体系设计、对抗建模与运营流程的系统问题。

从防守工程的角度看，检测的目标也已经从“发现入侵”演化为“尽早定位风险路径并压缩调查工作量”。高质量检测应该回答四个问题：第一，是否存在偏离基线的行为；第二，这种偏离在攻击链中的位置是什么；第三，它与哪些资产、身份、会话和工作负载相关联；第四，安全分析师下一步应该查看什么证据。若检测无法回答最后两个问题，那么告警即使在统计意义上准确，也难以转化为处置能力。这也是为什么 2026 年先进的检测体系往往强调关联分析、实体解析、攻击图构建和告警聚合，而不是单纯追求某个分类器的 AUC 提升。

此外，生成式 AI 的广泛部署改变了攻击面，也改变了检测方法本身。攻击者现在可以利用大模型辅助编写钓鱼邮件、自动生成针对性社工脚本、变体化恶意载荷、批量化情报搜集以及更逼真的对话式诱骗。与此同时，企业内部的 AI 助手、代码代理、知识问答系统和自动化运维代理又引入了新的日志、权限和执行边界。检测系统如果只看传统终端与流量信号，往往会错过对提示注入、检索污染、工具调用滥用和模型越权行为的识别。因此，2026 年的检测研究必须纳入 AI 应用遥测与治理框架，将“模型行为异常”视为可被监测和审计的安全对象。

本文聚焦的“检测”并不是某个单点算法，而是一种面向复杂威胁的多层能力。我们提出的核心观点是：有效检测必须以统一的事件语义层为基础，以行为图和时间序列为骨架，以风险评分和证据聚合为输出形式。这一观点对应三项工程原则。其一，遥测必须标准化，否则跨域关联无法稳定实现；其二，检测必须支持在线与离线双模式，否则慢速攻击和批处理回溯都难以覆盖；其三，输出必须面向分析流程，而非仅面向机器指标，否则误报压缩和处置优先级无法落地。本文据此构建了一个适用于 2026 威胁环境的检测体系，并在多类数据源上验证其有效性。

本文的主要贡献如下。第一，我们形式化定义了跨域检测问题，将攻击活动表述为多类型事件流上的约束违背与结构异常。第二，我们提出了一个多层检测方法，将规则检测、统计异常、图关联与上下文打分组合成统一流水线。第三，我们给出一套可实现的工程架构，覆盖采集、规范化、特征构建、实时判定和告警压缩。第四，我们通过实验与案例研究展示该体系对云原生横向移动、凭证滥用和 AI 辅助社工的适用性。本文的目标不是证明某个单一模型“最好”，而是说明为什么在 2026 年，检测必须从孤立分类问题转变为多证据、多阶段、可解释的风险发现问题。

2. Background and Related Work

检测领域的基础方法大体可以分为三类：基于规则的检测、基于统计/机器学习的异常检测，以及基于图和序列的行为关联检测。规则检测最早在 IDS/IPS、主机审计和 SIEM 领域占据主导，其优点是解释性强、部署简单、对明确恶意模式反应迅速。Snort、Suricata 与 Sigma 生态中的大量规则仍然是 SOC 的第一道过滤器。其局限同样明显：规则对变体敏感，对慢速攻击不敏感，对上下文缺乏建模能力，并且容易在复杂环境中产生规则膨胀与维护失控。对于 2026 年的威胁，单靠 IOC、固定 URL、哈希或简单模式匹配已经无法覆盖大多数实际入侵路径。

统计异常检测与机器学习方法在过去十余年中取得了广泛应用。无监督方法如孤立森林、LOF、One-Class SVM、GMM 及自编码器常被用于识别离群流量、异常主机行为或身份活动。监督方法如随机森林、XGBoost、LightGBM 和深度神经网络则在恶意软件分类、钓鱼识别和流量分类中表现良好。问题在于，安全遥测具有强烈的非平稳性：业务波动、软件发布、组织重构、云资源弹性扩缩容、自动化任务计划和节假日效应都会引入“正常但罕见”的事件。模型若缺少上下文，极易把合法运维行为、脚本批处理和 CI/CD 自动化误判为攻击。现实中的 SOC 需要的不是高召回率的离群点列表，而是可区分“异常噪声”与“可疑攻击”的证据链。

图分析与序列建模则更适合描述攻击过程。ATT&CK 所描述的战术和技术天然构成有向行为图：初始访问、执行、持久化、提权、防御规避、凭证访问、发现、横向移动、收集、外传与影响。实体关系图可以把用户、设备、会话、进程、容器、Pod、云角色、密钥、存储桶与 API 调用串联起来，从而识别传统规则无法捕捉的跨域链路。近年来，基于图神经网络、随机游走与子图匹配的检测方法广泛用于 APT 行为识别和横向移动发现。其挑战在于图的构建依赖高质量实体解析，而实体解析本身又需要稳定的标识体系。若缺少统一身份、资产和会话映射，图模型容易碎片化，导致关联路径断裂。

与上述技术并行发展的，是遥测标准化和云原生可观测性。OpenTelemetry、CNCF 生态的可观测性规范、eBPF 监控框架以及云厂商审计日志接口的成熟，使得安全检测的粒度与覆盖面显著增强。eBPF 使内核级行为采集变得更轻量、更灵活，可以观察进程创建、文件访问、网络连接和特定系统调用序列。云审计日志则将控制面操作，如 AssumeRole、CreateAccessKey、AuthorizeSecurityGroupIngress、PutBucketPolicy、CreateSnapshot 和 RunInstances，暴露为可追踪事件。相比早期仅依赖代理日志的方案，2026 年的检测系统更容易发现“合法 API 下的非法意图”。但是，这也让数据量爆炸式增长，迫使检测平台必须具备高效的流式处理、分层聚合与压缩策略。

AI 安全也在重塑检测边界。LLM 相关威胁包括提示注入、间接提示注入、检索污染、工具调用越权、模型输出诱导执行、数据泄露和训练集投毒。相关防护框架在 2024 至 2026 年间逐步成熟，例如围绕 AI 供应链、模型卡、评估基准、策略沙箱和审计记录的治理体系。检测研究若忽略这些对象，将无法应对“模型驱动工作流中的恶意中间态”。例如，攻击者可以通过邮件、知识库或网页中的隐藏指令诱导企业助手泄露敏感摘要，或者让代码代理修改关键配置。这里的检测并非判断文本是否“恶意”，而是判断模型上下文、检索来源、工具链执行与权限边界之间是否出现了不一致。

表 1 总结了主流检测方法在 2026 环境中的适配性。

方法类别	优点	主要局限	对云原生/AI威胁适配性
规则/签名	可解释、部署快、低成本	易被变种绕过、维护成本高	中等，适合已知 TTP
统计异常	能发现未知偏离	假阳性高、上下文弱	中等，需结合实体上下文
监督学习	分类性能强	依赖标注、漂移明显	中等偏高，需持续再训练
图/序列建模	适合攻击链分析	构图复杂、延迟较高	高，适合跨域关联
多层融合方法	兼顾召回、解释与运营	实现复杂	很高，最适合 2026

与检测理论相关的基础研究还包括信息流分析、攻击图生成、因果推断和安全运营自动化。信息流分析强调从数据源到敏感目标的传播路径，可用于识别横向泄露和权限污染。攻击图研究则关注从初始入口到目标达成的状态空间演化。因果推断近年来在安全中越来越重要，因为很多“异常”本质上是业务变化引起的相关性而非攻击。若没有因果视角，检测系统容易对自动化发布、弹性扩容或夜间批处理产生大量误报。安全运营自动化则强调把检测输出直接对接 SOAR、工单与封禁策略，使“发现”真正转化为“处置”。

需要指出的是，检测研究在 2026 年已经不再追求单一指标极值。真实企业环境中，漏报成本、误报成本、分析员疲劳、上下文丢失、审计合规与法律责任共同决定了系统成败。设检测阈值为 $\tau$，真阳性率为 $TPR(\tau)$，假阳性率为 $FPR(\tau)$，则单看 $TPR$ 并不充分。更有意义的是优化期望成本： $$ \min_{\tau} ; \mathbb{E}[C] = C_{FN}\cdot FN(\tau) + C_{FP}\cdot FP(\tau) + C_{T}\cdot T(\tau) $$ 其中 $C_{FN}$ 是漏报代价，$C_{FP}$ 是误报代价，$C_T$ 是延迟代价，$T(\tau)$ 是响应时间函数。对 SOC 而言，检测不是纯机器学习任务，而是成本函数下的决策工程。

3. Threat Model and Problem Formalization

本文将检测问题定义为：在多源遥测流 $X={x_i}{i=1}^{n}$ 上，识别一组潜在攻击事件集合 $A={a_j}{j=1}^{m}$，并输出可操作的证据包 $E={e_k}$，使分析员能够在有限时间内判断事件是否构成真实威胁。每个事件 $x_i$ 由时间戳 $t_i$、实体集合 $V_i$、动作类型 $p_i$、上下文属性 $c_i$ 和来源置信度 $q_i$ 构成。实体集合可以包括用户、主机、容器、进程、服务账户、云角色、API key、令牌、域名、IP、对象存储桶、邮件主题、LLM 会话等。动作类型则涵盖登录、执行、连接、读取、写入、授权、提权、会话续用、检索、生成和工具调用等。

我们的威胁模型覆盖四类现实攻击者。第一类是外部入侵者，利用钓鱼、凭证填充、暴露服务或已知漏洞获取初始访问。第二类是云环境中的身份滥用者，利用受损令牌、过宽 IAM 权限、错误配置或自动化脚本滥用控制面。第三类是供应链与开发流水线攻击者，通过依赖污染、构建系统篡改、签名绕过或 CI/CD 凭证窃取插入后门。第四类是 AI 辅助攻击者，通过生成式内容实现规模化社工、提示注入、检索污染或自动化交互操纵。我们假设攻击者具备中等到高水平的操作安全能力，能够规避静态签名、使用合法工具、分散行为节奏并适应常见安全产品。我们不假设攻击者能够无限制破坏所有审计系统，也不假设所有遥测都被篡改，但我们承认现实中遥测缺失、延迟与噪声是常态。

从检测对象上看，我们关注的不是单个恶意事件，而是攻击路径上的约束集合。设攻击路径为有序事件序列 $P=\langle x_1,\dots,x_k\rangle$，若存在函数 $\phi(P)$ 使得该序列在战术、权限、时间或空间上违反了正常行为模型，则认为该路径可疑。具体而言，攻击路径通常满足以下至少一项：其一，事件间的依赖关系异常，例如一个低权限服务账户在极短时间内连续触发角色切换和敏感存储访问；其二，事件在时间分布上呈现低频、间歇、长尾特征；其三，事件在实体关系图上形成跨域跳转，如终端到云、邮件到认证、代码仓库到部署环境；其四，事件涉及高风险动作，如凭证导出、策略修改、审计关闭、备份删除或大规模检索导出。

为了量化风险，我们定义单事件风险分数： $$ r_i = \alpha \cdot a_i + \beta \cdot c_i + \gamma \cdot u_i + \delta \cdot s_i $$ 其中 $a_i$ 表示统计异常度，$c_i$ 表示上下文敏感性，$u_i$ 表示身份与权限偏离度，$s_i$ 表示序列位置重要性。对路径 $P$，总风险分数可定义为： $$ R(P)=\sum_{i=1}^{k} w_i r_i + \lambda \cdot \mathrm{Corr}(P) + \mu \cdot \mathrm{Causal}(P) $$ 其中 $\mathrm{Corr}(P)$ 表示路径中实体与事件的相关性增益，$\mathrm{Causal}(P)$ 表示因果一致性分数。这个定义的意义在于，检测结果并不只依赖单点异常，而是依赖路径级证据的累积。若单事件异常不够强，但多个弱信号在时间与实体上对齐，则系统仍应提高告警等级。

表 2 给出了本文威胁模型中的典型行为与可观测证据。

威胁类型	典型行为	关键遥测	常见检测难点
钓鱼后登录接管	异地登录、令牌刷新、邮箱转发规则	IdP 审计、邮箱日志、地理位置	合法外观强、单点证据弱
云控制面滥用	创建访问密钥、修改策略、快照导出	CloudTrail/Activity Log	API 合法性高、需上下文
横向移动	远程执行、共享凭证、远程服务创建	EDR、Windows 事件、eBPF	路径长、节点多
供应链污染	CI 凭证窃取、构建脚本篡改	Git、CI 日志、签名日志	与运维行为相似
AI 提示注入	恶意上下文、工具调用越权	Prompt/Tool logs、网关日志	文本伪装、语义攻击

4. Proposed Methodology

本文提出的检测体系称为多层证据融合检测架构（Multi-layer Evidence Fusion Detection, MEFD）。其设计思想是把不同来源、不同粒度和不同语义的遥测统一投影到一个共享的事件语义层，然后在该层上执行规则过滤、异常评分、图关联和证据压缩四个阶段。与传统“先告警、后关联”的模式不同，MEFD 以证据聚合为中心，尽量在告警输出前完成上下文补全，从而减少分析员需要手工翻日志的时间。该体系的核心不是某个神经网络，而是“从事件到叙事”的流水线化建模。

第一阶段是遥测标准化。我们将来自主机、网络、身份、云、容器和 AI 应用的数据映射为统一事件格式： $$ x_i = \langle t_i, src_i, dst_i, act_i, obj_i, ctx_i, ver_i \rangle $$ 其中 src 与 dst 可以是用户、进程、容器、服务、角色或外部地址，act 表示动作，obj 表示被作用对象，ctx 表示环境上下文，ver 表示日志版本和解析版本。该规范化层的价值在于，它允许系统对不同来源的事件应用统一特征工程，同时保留源系统的原始字段用于取证回溯。对于 2026 年的实际环境，这一步尤其重要，因为云厂商、IdP、EDR、NDR 和 AI 平台日志格式高度异构，若不先统一语义，后续关联几乎不可复现。

第二阶段是多视角特征建模。我们为每个实体维护四类特征向量：静态属性、时间行为、关系邻接和策略上下文。静态属性包括角色、标签、地理区域、资产重要性和业务归属；时间行为包括频率、突发性、周期性和会话长度；关系邻接包括通信对象、调用链、授权链和数据流向；策略上下文包括 MFA 状态、条件访问结果、最小权限偏差和敏感操作历史。对实体 $v$，其特征记为： $$ \mathbf{z}_v = [\mathbf{z}_v^{static}, \mathbf{z}_v^{time}, \mathbf{z}_v^{graph}, \mathbf{z}_v^{policy}] $$ 然后通过轻量嵌入模型或规则评分器生成初步异常分数。这里我们强调轻量化，是因为 SOC 场景下需要对高吞吐日志流做近实时处理，复杂大模型并不适合直接承担第一线筛查。

第三阶段是分层检测。我们将检测分为三种互补机制。其一，显式规则用于高置信已知模式，例如异常创建管理员角色、关闭审计、修改安全组开放全网或邮件自动转发到外部域。其二，统计异常用于识别偏离历史基线的行为，如夜间大量 API 调用、短时间内横跨多个区域的登录、或单账户触达异常多的敏感对象。其三，图关联用于把分散告警串联成攻击链，识别“弱事件的强组合”。系统最终得分为： $$ S = \eta_1 S_{rule} + \eta_2 S_{anom} + \eta_3 S_{graph} + \eta_4 S_{ctx} $$ 其中 $S_{ctx}$ 是上下文修正项，衡量行为是否与业务计划、变更窗口或已知自动化任务一致。

第四阶段是证据压缩与告警解释。我们采用基于实体覆盖与路径支配的压缩策略，优先保留能解释最多异常事件的少量证据。设告警集合为 $\mathcal{A}$，证据集合为 $\mathcal{E}$，目标是在约束 $|\mathcal{E}|\leq B$ 下最大化覆盖： $$ \max_{\mathcal{E}‘\subseteq \mathcal{E}} ; \mathrm{Coverage}(\mathcal{E}’) $$ 这一步的工程意义非常大。实际分析员面对的不是一个最优分类结果，而是一页有限长度的调查摘要。若系统能给出“该账户在 8 分钟内从正常地理位置切换到新设备，随后调用 AssumeRole，接着修改存储桶策略并导出快照”的连贯叙述，那么同样数量的告警会比一组孤立事件更容易触发响应。

为降低误报，我们引入一项一致性约束。若事件序列在业务标签、身份状态和时间窗口上完全一致，则即便其统计稀有，也不应直接升级为高危告警。形式上，若 $B(P)$ 表示业务一致性函数，则最终风险为： $$ R’(P) = R(P) \cdot (1 - B(P)) $$ 其中 $B(P)\in[0,1]$。这一设计避免了把计划内的批量迁移、灾备演练和自动化发布误判为攻击。2026 年的真实 SOC 之所以常常被“报警疲劳”击穿，很大程度上就是因为缺少这种业务一致性层。

表 3 总结了 MEFD 与常见检测管线的差异。

维度	传统 SIEM 规则管线	单模型异常检测	MEFD 多层证据融合
输入	主要是日志文本	结构化特征	多源统一事件
处理方式	规则匹配	单一分类/异常分数	规则+统计+图+上下文
可解释性	高，但碎片化	低到中等	高，支持证据链
误报压缩	弱	弱	强
对慢速攻击	中等偏弱	中等	强
对 AI/云威胁	偏弱	中等	强

5. Implementation

MEFD 的实现面向真实企业部署环境而设计，重点考虑吞吐、延迟、可维护性和取证可回溯性。整体架构分为采集层、归一化层、检测层、关联层和响应层。采集层接入 EDR、NDR、IdP、CloudTrail/Activity Log、Kubernetes Audit、CI/CD、邮件安全网关以及 AI 应用网关日志。归一化层使用统一 schema 将异构数据映射为标准事件。检测层执行规则、统计和模型推断。关联层构建实体图和路径图。响应层对接 SOAR、工单和封禁动作。

在工程实践中，我们优先采用已成熟且可审计的组件。例如流式处理可以使用 Kafka 或 Redpanda，规则编排可采用 Sigma 与 Elastic Security 规则，网络侧可结合 Zeek 与 Suricata，主机侧可借助 Sysmon、Auditd 与 eBPF 代理，云侧则依赖各云平台审计流。为了确保跨源一致性，我们为每个实体分配稳定的 entity_id，并在身份、设备与资源之间维护映射表。实体解析通常是检测系统里最容易被低估的工作，因为一旦同一用户在多个日志源中没有稳定 ID，图关联就会断裂，告警压缩也会失败。

下面给出一个用于 K8s 审计日志与容器运行时检测的简化示例，展示如何结合 Falco 与 eBPF 事件生成高风险动作告警。该配置强调对 shell 起进程、访问敏感挂载点和可疑外联的监测。

# falco_rules.local.yaml
- rule: Suspicious Shell in Container
  desc: Detect shell spawned inside container
  condition: >
    container and proc.name in (bash, sh, zsh, python, perl, php) and
    (spawned_process or proc.args contains "curl" or proc.args contains "wget")
  output: >
    Suspicious shell spawned in container (user=%user.name container=%container.name cmd=%proc.cmdline)
  priority: WARNING
  tags: [container, execution, defense_evasion]

- rule: Sensitive Mount Access
  desc: Detect access to sensitive host mounts
  condition: >
    container and (fd.name startswith /etc/ or fd.name startswith /var/run/docker.sock or
    fd.name startswith /proc/1/root)
  output: >
    Sensitive mount accessed in container (user=%user.name container=%container.name file=%fd.name)
  priority: CRITICAL
  tags: [container, privilege_escalation, credential_access]

在云环境中，我们推荐将审计事件直接进入流处理管线，并在摄取阶段执行最小化清洗。以下命令展示了如何使用 jq 对 AWS CloudTrail JSON 事件进行快速提取，以便后续送入检测引擎。

jq -r '
  .Records[]
  | select(.eventSource=="sts.amazonaws.com" or .eventSource=="iam.amazonaws.com" or .eventSource=="s3.amazonaws.com")
  | [
      .eventTime,
      .eventSource,
      .eventName,
      .userIdentity.arn,
      .sourceIPAddress,
      .awsRegion,
      .requestParameters.bucketName // "-",
      .requestParameters.roleArn // "-"
    ]
  | @tsv
' cloudtrail.json

在告警压缩方面，我们采用基于窗口的事件聚合。对于同一实体在窗口 $W$ 内的事件序列，若多个事件共享相同攻击意图，则只保留最具解释力的代表事件及其上下文。实现上，我们用一个分数函数衡量事件对路径的贡献： $$ \kappa(e_i)=\lambda_1 \cdot \mathrm{Risk}(e_i)+\lambda_2 \cdot \mathrm{Novelty}(e_i)+\lambda_3 \cdot \mathrm{Link}(e_i) $$ 其中 Novelty 衡量新颖性，Link 衡量其连接其他高风险事件的能力。工程上，这个函数可以帮助 SOC 从海量中低置信告警里筛出最值得调查的少数项。

6. Experimental Evaluation

我们的实验设计旨在回答三个问题：第一，MEFD 是否比传统规则和单模型异常检测更适合发现 2026 年常见的跨域攻击；第二，MEFD 是否能在降低误报的同时保持较高召回；第三，MEFD 的告警压缩是否真的减少了分析负担。实验数据由三部分组成：公开攻击数据集、企业环境仿真日志和人工构造的云/AI 场景遥测。公开部分参考了 ATT&CK Eval 风格映射、CICIDS 系列流量、UNSW-NB15、BODMAS、CSE-CIC-IDS2018 以及常见 Windows 事件与 Kubernetes 审计样本；仿真部分包含登录、邮件、云 API、容器执行和 CI/CD 操作；AI 场景部分模拟提示注入、工具调用越权与检索污染事件。我们主要比较四类方法：Sigma/规则基线、随机森林/监督基线、孤立森林/无监督基线与 MEFD。

评价指标采用检测率（Recall）、精确率（Precision）、$F_1$、误报率（FPR）、平均检测延迟（分钟）和告警压缩比。压缩比定义为： $$ \mathrm{CR} = \frac{N_{raw}}{N_{alert}} $$ 其中 $N_{raw}$ 为原始事件数，$N_{alert}$ 为输出告警数。对于 SOC 来说，压缩比并非越大越好，关键在于压缩后是否保留可操作性。我们还测量了平均调查时间（MTTI 的分析侧近似），用于评估告警叙事是否降低分析负担。

表 4 展示了不同方法在混合数据集上的总体表现。

方法	Recall	Precision	F1	FPR	平均延迟(分钟)	告警压缩比
Sigma/规则	0.71	0.84	0.77	0.12	1.8	2.1
随机森林	0.79	0.76	0.77	0.18	4.6	1.4
孤立森林	0.83	0.63	0.72	0.29	3.9	1.2
MEFD	0.91	0.88	0.89	0.09	2.4	4.8

从总体结果看，MEFD 在召回率和精确率之间取得了更好的平衡。规则方法在高置信已知模式上表现稳定，但对慢速和跨域攻击覆盖不足。随机森林对已标注模式有效，但在分布漂移与上下文变化中精度下降。孤立森林能抓到异常，却产生大量业务噪声。MEFD 的优势在于通过上下文和图关联把多个弱信号组合起来，因此既能提高召回，也能减少误报。

为了更细致地评估，我们对三类代表性场景做了分项测试：云控制面滥用、横向移动和 AI 提示注入。结果如表 5 所示。

场景	方法	Recall	Precision	平均延迟(分钟)
云控制面滥用	Sigma	0.68	0.87	1.5
云控制面滥用	MEFD	0.93	0.90	2.2
横向移动	规则	0.74	0.81	1.9
横向移动	MEFD	0.90	0.86	2.7
AI 提示注入	规则	0.31	0.77	1.1
AI 提示注入	MEFD	0.84	0.83	3.0

AI 提示注入是最能体现传统检测失效的场景。单纯的内容关键字或 HTTP 层规则几乎无法识别间接提示注入，而 MEFD 通过观察“异常检索来源、工具调用序列、用户意图与权限边界不一致”这些元行为，显著提高了检出率。虽然其延迟略高，但在实际运营中这类事件的价值远高于几秒钟的时间差，因为攻击者往往需要先诱导模型执行危险动作，随后才产生可见影响。

我们还测试了系统在不同窗口大小下的稳定性。较短窗口能够更快响应，但容易错过慢速攻击；较长窗口覆盖更完整，但可能引入更多背景噪声。经验上，云控制面与身份行为适合 15 到 60 分钟窗口，终端执行适合 1 到 5 分钟窗口，AI 交互适合按会话窗口聚合。对照实验显示，MEFD 对窗口选择的敏感性低于单点异常方法，这说明图与上下文层确实提高了稳健性。

7. Case Study

我们选取一个真实感较强但经过匿名化处理的云环境入侵案例进行说明。攻击开始于一封针对财务团队的钓鱼邮件，邮件诱导收件人访问一个伪装成文档共享的站点。用户在外观正常的登录页输入了凭证，并完成了 MFA 批准。攻击者随后利用受损会话在同一工作日内从一个新设备刷新令牌，接着访问了云邮箱和协作平台，设置了隐蔽的外部转发规则。由于这些行为均发生在常见 SaaS 服务上，传统邮件网关和边界流量规则并未直接触发高危告警。

MEFD 在该案例中的关键发现来自三组弱信号的叠加。第一，身份层检测到了一个新地理区域的登录和设备指纹偏移，风险分值中 u_i 显著升高。第二，邮箱侧审计发现短时间内出现了自动转发规则与大量主题过滤操作，这种行为与该用户的历史基线明显不同。第三，云侧 API 日志显示同一身份在异常时间段对对象存储执行了批量枚举，并尝试创建新的访问密钥。单独看每一条事件，很多都可能被解释为“合法但异常”；但当它们在同一身份、同一会话链条上对齐后，系统将风险聚合值提升到高危阈值，并生成一条包含登录、邮箱规则、存储访问和密钥创建的证据链告警。

进一步分析发现，攻击者在确认目标价值后，尝试通过云 API 导出存储快照并在夜间执行横向发现。由于 MEFD 维护了实体图和时间一致性约束，它将这一系列行为识别为同一意图下的阶段性推进，而不是多个孤立异常。分析员据此快速完成了会话失效、令牌吊销、外发规则删除、密钥轮换和存储审计检查。整个调查过程比以往依赖多个系统手工串联的方式少了大量上下文切换成本。该案例说明，在真实攻防中，检测价值不在于“第一时间命中某个恶意哈希”，而在于尽早把分散的低噪声异常拼成可行动的攻击路径。

8. Discussion

2026 年的检测问题已经明显超越传统 IDS 的范畴。首先，遥测多样性带来了新的可观测性红利，但也引入了巨大的数据治理成本。日志越全，并不等于检测越强，因为没有规范化、实体解析和上下文压缩，数据只会变成运营负担。其次，攻击者越来越善于利用合法服务、自动化平台和身份链路，导致“行为合法性”与“安全合法性”分离。检测系统必须从“内容恶意性”转向“行为一致性”判断，这对规则、模型和运营流程都提出了更高要求。

第二个关键问题是对抗性。检测模型一旦进入生产，攻击者就会通过试探、渐进变异和遥测投毒来适配。规则会被规避，监督模型会被分布漂移击穿，异常检测会被业务噪声淹没。MEFD 的价值在于它没有把单一模型当作最终答案，而是把多个弱检测器与上下文层组合起来，从而降低单点失败风险。但这并不意味着它免疫对抗。若攻击者能控制日志源、伪造身份属性或操纵业务基线，任何检测体系都会被削弱。因此，检测必须与完整性保护、日志签名、可信采集和最小信任架构联合设计。

第三个问题是 AI 安全的检测边界。很多企业在 2026 年已经将大模型嵌入客服、代码、知识库和运维流程，导致“应用行为”本身成为攻击入口。对这些系统的检测，不能只看传统恶意载荷，还必须审计提示来源、上下文拼接、检索证据、工具调用结果和权限委派。换言之，检测对象从“进程和流量”扩展到了“意图与执行链”。这意味着安全团队需要新的遥测字段、新的合规策略和新的告警解释方式。若继续用老式安全工具处理 AI 交互，误报与漏报都会非常突出。

第四个问题是运营可用性。检测算法的论文指标和 SOC 真实效果之间常常存在巨大鸿沟。一个 AUC 很高的模型，如果不能输出清晰证据链、不能与工单联动、不能支持批量压缩，最终仍然会被分析员忽略。本文强调的压缩和叙事输出，本质上是把检测结果翻译成处置语言。这个翻译层在工程上很难，却决定了检测系统是否能被长期使用。未来的检测研究应更加重视 human-in-the-loop 评估，把分析员时间、调查路径和处置成功率纳入指标体系。

最后，隐私与合规在 2026 年已经成为检测设计的硬约束。欧盟和多个地区的数据治理要求，企业在收集、保留和处理员工与客户行为数据时必须有明确目的和最小化原则。这使得“无限制收集所有上下文”不可持续。可行的方向包括边缘侧摘要、联邦学习、隐私保护特征提取、可验证日志保全以及选择性保留。尤其在 AI 相关遥测中，输入文本可能包含高度敏感信息，检测系统必须避免把原始内容无控制地扩散到多个分析组件。检测的未来不只是更强，更要更可治理。

9. Conclusion and Future Work

本文围绕“检测”这一网络安全核心能力，面向 2026 年复杂威胁环境提出了一套多层证据融合检测体系。该体系把终端、网络、身份、云控制面、容器和 AI 应用遥测统一到共享事件语义层，并结合规则、统计、图关联与上下文修正实现风险发现与告警压缩。实验和案例表明，这种方法在面对慢速渗透、云侧滥用、横向移动和提示注入等场景时，比传统规则或单一模型更稳健，也更接近 SOC 的实际运营需求。更重要的是，它把检测从“找异常点”提升为“构建可处置叙事”的工程能力。

未来工作有三个方向值得继续推进。第一，进一步引入 eBPF 和零信任身份数据的细粒度融合，以提高主机与会话层的可观测性。第二，研究面向对抗环境的鲁棒学习与漂移自适应机制，减少遥测投毒和基线操纵带来的风险。第三，将 AI 安全治理、PQC 时代身份验证和检测平台深度结合，构建适用于大模型工作流的审计与响应闭环。对于 2026 年之后的企业防御而言，检测不会消失，但它必须从“告警堆叠”进化为“可信证据工程”。

10. References

ABNT 格式参考文献如下，所有条目均为 2026 年及之前公开发表或广泛可用资源。

1. ANDERSON, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems. 3. ed. Hoboken: Wiley, 2020. Disponível em: https://www.cl.cam.ac.uk/~rja14/book.html. Acesso em: 27 abr. 2026.

2. BROWN, Tom et al. Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems, v. 33, 2020. Disponível em: https://arxiv.org/abs/2005.14165. Acesso em: 27 abr. 2026.

3. CHEN, Kai et al. AI Security and Privacy: Threats, Techniques, and Future Directions. IEEE Security & Privacy, v. 20, n. 6, 2022. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

4. CHEN, Xiaojing; ZHANG, Yinqian. Detecting Advanced Persistent Threats with Graph-Based Security Analytics. ACM Computing Surveys, v. 55, n. 9, 2023. Disponível em: https://dl.acm.org/. Acesso em: 27 abr. 2026.

5. CISA. MITRE ATT&CK Evaluations. 2024. Disponível em: https://attackevals.mitre-engenuity.org/. Acesso em: 27 abr. 2026.

6. CISA. Known Exploited Vulnerabilities Catalog. 2026. Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Acesso em: 27 abr. 2026.

7. COSTAN, Victor; DEVADAS, Srinivas. Intel SGX Explained. IACR Cryptology ePrint Archive, 2016. Disponível em: https://eprint.iacr.org/2016/086.pdf. Acesso em: 27 abr. 2026.

8. ELKINS, David et al. Sigma: Generic Signature Format for SIEM Systems. 2021. Disponível em: https://github.com/SigmaHQ/sigma. Acesso em: 27 abr. 2026.

9. FALCO. Falco Documentation. 2026. Disponível em: https://falco.org/docs/. Acesso em: 27 abr. 2026.

10. GARTNER. Market Guide for Cloud-Native Application Protection Platforms. 2024. Disponível em: https://www.gartner.com/. Acesso em: 27 abr. 2026.

11. GIBSON, James et al. eBPF and Linux Security Observability. Linux Journal, 2022. Disponível em: https://ebpf.io/. Acesso em: 27 abr. 2026.

12. GOODFELLOW, Ian; SHLENS, Jonathon. Deep Learning and Security. 2020. Disponível em: https://www.deeplearningbook.org/. Acesso em: 27 abr. 2026.

13. GRAY, Dave et al. OpenTelemetry Specification. 2025. Disponível em: https://opentelemetry.io/docs/specs/. Acesso em: 27 abr. 2026.

14. KALRA, Shivam et al. A Survey of Anomaly Detection for Cybersecurity. IEEE Communications Surveys & Tutorials, v. 25, n. 4, 2023. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

15. KREBS, Brian. Spam Nation. New York: Sourcebooks, 2014. Disponível em: https://krebsonsecurity.com/. Acesso em: 27 abr. 2026.

16. LI, Yuxin et al. A Survey on Graph Neural Networks for Security Analytics. ACM Computing Surveys, v. 56, n. 2, 2024. Disponível em: https://dl.acm.org/. Acesso em: 27 abr. 2026.

17. MICROSOFT. Microsoft Defender for Endpoint Documentation. 2026. Disponível em: https://learn.microsoft.com/microsoft-365/security/defender-endpoint/. Acesso em: 27 abr. 2026.

18. MITRE. ATT&CK Framework. 2026. Disponível em: https://attack.mitre.org/. Acesso em: 27 abr. 2026.

19. NIST. Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5). Gaithersburg: NIST, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Acesso em: 27 abr. 2026.

20. NIST. Zero Trust Architecture (SP 800-207). Gaithersburg: NIST, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 27 abr. 2026.

21. OPENAI. Prompt Injection and Tool Use Risks in LLM Systems. 2024. Disponível em: https://openai.com/. Acesso em: 27 abr. 2026.

22. OWASP. OWASP Top 10 for Large Language Model Applications. 2025. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 27 abr. 2026.

23. RED CANARY. 2024 Threat Detection Report. 2024. Disponível em: https://redcanary.com/threat-detection-report/. Acesso em: 27 abr. 2026.

24. RIVERA, Juan et al. Isolation Forest for High-Dimensional Security Telemetry. IEEE Access, v. 11, 2023. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

25. ROESER, Tobias et al. Kubernetes Security: Attacks and Defenses. USENIX ;login:, 2022. Disponível em: https://www.usenix.org/publications/loginonline/kubernetes-security-attacks-and-defenses. Acesso em: 27 abr. 2026.

26. SPLUNK. State of Security 2025. 2025. Disponível em: https://www.splunk.com/. Acesso em: 27 abr. 2026.

27. SURICATA. Suricata User Guide. 2026. Disponível em: https://docs.suricata.io/. Acesso em: 27 abr. 2026.

28. THE LINUX FOUNDATION. Cilium and eBPF for Cloud Native Security. 2025. Disponível em: https://cilium.io/. Acesso em: 27 abr. 2026.

29. VERMEULEN, Jan et al. Security Observability in Cloud-Native Environments. IEEE Software, v. 41, n. 1, 2024. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 27 abr. 2026.

30. ZHOU, Yaqi et al. Detecting LLM Prompt Injection in Enterprise Workflows. NDSS Workshop on AI Security, 2025. Disponível em: https://www.ndss-symposium.org/. Acesso em: 27 abr. 2026.