AI 摘要 · 由英文经 AI 翻译
CORTEX: Collaborative LLM Agents for High-Stakes Alert Triage
Bowen Wei, Yuan Shen Tay, Howard Liu, Jinhao Pan, Kun Luo, Ziwei Zhu, Chris Jordan
TL;DR
SOC 面临大量告警和较高的误报率；单智能体 LLM 分诊则难以应对耗时较长的调查，且可审计性有限。CORTEX 将专用智能体与细粒度调查轨迹相结合；在其评测套件上，相较于单智能体基线，该方法提升了 actionable F1，并降低了误报率。
问题
单智能体 LLM 方法将日志解读、上下文检索和告警裁定整合在一起，但在持续时间较长的调查中可能表现不佳，且可审计性有限。
出处：§1 · pp. 1–2方法
CORTEX 使用专用智能体识别工作流、收集外部证据并综合证据，同时提供包含细粒度 SOC 调查轨迹的数据集。
出处：§1 · p. 2结果
在评测套件上，相较于单智能体基线，actionable F1 从 0.66 提升至 0.78，误报率从 24.9% 降至 14.2%。
出处：§5 · p. 7要点与局限
包含明确证据链接的结构化报告有助于后续审查、合规工作和事后学习。
出处：§5 · p. 7评测受限于仅覆盖十余种场景，以及上游遥测数据的可用性和质量；CORTEX 也可能对分布偏移、提示注入或不完整的工具上下文较为敏感。
出处：§5 · p. 7
Abstract
from arXiv · showhide
Security Operations Centers (SOCs) are overwhelmed by tens of thousands of daily alerts, with only a small fraction corresponding to genuine attacks. This overload creates alert fatigue, leading to overlooked threats and analyst burnout. Classical detection pipelines are brittle and context-poor, while recent LLM-based approaches typically rely on a single model to interpret logs, retrieve context, and adjudicate alerts end-to-end -- an approach that struggles with noisy enterprise data and offers limited transparency. We propose CORTEX, a multi-agent LLM architecture for high-stakes alert triage in which specialized agents collaborate over real evidence: a behavior-analysis agent inspects activity sequences, evidence-gathering agents query external systems, and a reasoning agent synthesizes findings into an auditable decision. To support training and evaluation, we release a dataset of fine-grained SOC investigations from production environments, capturing step-by-step analyst actions and linked tool outputs. Across diverse enterprise scenarios, CORTEX substantially reduces false positives and improves investigation quality over state-of-the-art single-agent LLMs.
1 引言
SOCs 面临海量告警，而单智能体 LLM 分诊需要解读日志、检索上下文并判定告警，可审计性有限。CORTEX 提出由专业化、以证据为依据的智能体协作，并构建流程级数据集；实验显示，其分诊效果优于单智能体 LLM。
- SOCs 每天面临数万条告警，其中只有少数是真实威胁，同时误报率高，告警疲劳严重。文中引用的实证误报率接近 99%。出处：§1 · p. 1
- 单智能体 LLM 方法将日志解读、上下文检索和告警判定合并处理，但在长时程调查中可能表现不佳，且可审计性有限。出处：§1 · pp. 1–2
- CORTEX 将工作流识别、外部证据收集和证据综合分配给专业化智能体，并通过结构化消息进行通信。出处：§1 · p. 2
- 发布的数据集记录了十多个生产环境场景中的分析师逐步操作、工具查询与输出，以及中间观察结果。这些过程轨迹支持流程级推理的训练与评估。出处：§1 · p. 2
- 在多种企业场景中，与单智能体 LLM 相比，CORTEX 大幅减少误报并提升调查质量。出处：§1 · p. 2
2 相关工作
已有研究涉及网络安全领域的 LLM 应用、SOC 自动分诊和协作式智能体框架。本文的贡献位于三者交汇处：面向 SOC、以工具证据为基础的多智能体调查。
2.1 网络安全中的 LLM
- 网络安全领域的 LLM 研究涵盖威胁情报提取、知识图谱推理、漏洞分析和攻击自动化，但将端到端 SOC 调查建模为基于工具证据、按角色分工的流程的研究较少。文中还指出，将这一流程蒸馏为可部署的单一模型，仍鲜有研究探索。出处：§2.1 · p. 2
2.2 SOC 中的告警疲劳与自动分诊
- 自动分诊包括有监督的优先级排序和学习排序；新兴的智能体式 SOC 平台则宣称可实现端到端覆盖并提升速度，但可能带来显著的计算成本。出处：§2.2 · pp. 2–3
2.3 协作式多智能体 LLM 系统
- 协作式智能体研究为任务分解和交叉核验提供了依据，同时也记录了规范错误、智能体间不一致，以及终止机制或验证能力不足等问题。本文将规范的消息传递和基于外部证据的验证视为重要的设计需求。出处：§2.3 · p. 3
3 方法
这些方法将按角色专门化的多智能体分诊架构与细粒度 SOC 工作流数据集结合起来，用于过程级监督。
3 方法
- 这些方法将分而治之的多智能体分诊架构与细粒度 SOC 工作流数据集结合起来。出处：§3 · p. 3
3.1 CORTEX 架构
- CORTEX 将告警路由到相关工作流，使用针对特定工作流的智能体查询类型化企业工具，并将证据综合为结构化、可审计的报告。其四个阶段分别为编排、工作流路由、以证据为依据的分析和综合；任何工作流升级都会产生可采取行动的判定。出处：§3.1 · pp. 3–4, Figure 1 · p. 4
3.2 细粒度 SOC 工作流数据集
- 该数据集记录了十种场景中的生产环境调查，包括原始遥测数据、分析师操作、工具查询、中间推理和最终裁定。敏感字段经过假名化处理，调查轨迹以 JSON 序列化，用于监督训练和结构化评估。出处：§3.2 · p. 4
- 每条调查轨迹都包含行为规则证据字段；调查结果标记为可采取行动或不可采取行动，其中不可采取行动的调查分为四个子类。记录涵盖身份、网络、系统、运营、工件和安全注释属性。出处：§3.2 · p. 5
- 数据集样例涵盖异构的云、SaaS 和端点数据源，并将其规范化为统一模式，同时保留领域特定细节。出处：§3.2 · p. 5
4 实验
实验在受模式约束的告警分诊任务中，将 CORTEX 与单智能体基线进行比较，衡量决策质量和效率。CORTEX 提升了分诊指标，但也增加了协同耗时和 token 使用量。
4.1 实验设置
- 测试数据集为细粒度 SOC 工作流数据集，所有 PII 均已在上游完成假名化处理。系统必须返回符合模式的报告，其中包含 Actionable/Non-actionable 判定、适用的子类、以证据为依据的理由，以及可观测指标。出处：§4.1 · p. 5
- 单智能体基线包括仅使用提示词的模型，或采用 ReAct 风格的工具调用模型；对于后者，工具预算和轮次上限与 CORTEX 保持一致。两种基线都必须以工具输出为依据支撑论断，并生成符合模式的报告。出处：§4.1 · p. 5
- CORTEX 将告警路由至相应工作流，使用证据代理执行校准检查，并采用保守的“任一项触发即升级”综合判定策略。评估指标包括决策和子类 macro-F1、假阳性率、可行动告警召回率、输出 token 数、工具调用次数和延迟。出处：§4.1 · pp. 5–6
4.2 分诊性能
- 相较于表现最佳的单智能体基线，可行动告警 F1 从 0.66→0.78；假阳性率则从 24.9% 降至 14.2%。Macro-F1 达到 0.82，子类 F1 提升 +0.15。出处：§4.2 · p. 6, Table 4 · p. 6
4.3 效率
- 每张工单端到端耗时中位数为 152.4 s，仍在约 3 分钟的 SLO 范围内；相比之下，ReAct 耗时 44.6 s，仅使用提示词的模型耗时 28 s。CORTEX 处理 23,600 个 token，而使用工具的基线处理 4,152 个 token；平均工具调用次数从 1.3 增至 3.1。出处：§4.3 · p. 6, Table 5 · p. 6
5 结论
结论将 CORTEX 概括为一种以工具证据为基础、按角色分工的架构；与单智能体基线相比，它提升了决策质量和透明度，并配套提供了流程级 SOC 工作流数据集。附录详述工作流的证据收集与决策策略，同时指出场景覆盖范围和遥测方面的局限。
5 结论
A 工作流提示词
- 工作流提示词将证据检索分配给类型化工具，将决策策略交由 Reasoning & Coordination Agent 执行。CORTEX 的角色包括编排、工作流路由、证据获取，以及综合形成可审计报告。出处：Table 6 · p. 9
A.1 添加用户工作流；A.2 身份验证变更工作流
- 在用户添加和身份验证变更工作流中，智能体会检索目录记录；随后根据管理员状态或账户年龄判断是否可处置。添加管理员属于可处置事项；移除身份验证方式属于可处置事项，而仅当用户是新用户时，添加身份验证方式才属于不可处置事项。出处：§A.1 · p. 9, §A.2 · p. 10
A.3 关联（Coro）工作流；A.4 通用工作流
- Coro 事件按策略升级处理；通用工作流仅在直接证据不足时才检索原始行为事件。通用工作流会关闭无效工单、升级有效且可处置的工单，或在证据不足或相互矛盾时请求补充信息。出处：§A.3 · p. 10, §A.4 · p. 11
A.5 多 ISP（不可能旅行）工作流；A.6 Office 365 访客工作流
- 不可能旅行分析会结合近期登录活动、距离和时间、ISP 多样性，以及合理的 VPN 或移动设备使用解释；若访客具有管理员身份，其活动即属于可处置事项。不可能旅行工作流会评估八小时窗口内的登录。出处：§A.5 · pp. 11–12, §A.6 · p. 12
A.7 Office 365 登录工作流；A.8 PowerShell 工作流；A.9 Salesforce 异常登录工作流；A.10 SharePoint 文件工作流
- 这些策略规定，只有当 O365 登录风险超过 1000 且近期存在高风险活动时，该登录才属于可处置事项；PowerShell 需同时满足恶意代码和管理员身份条件，Salesforce 则要求近期至少出现三次规则事件。出处：§A.7 · p. 13, §A.8 · p. 13, §A.9 · p. 14
B 案例研究
论文展示了 CORTEX 处理告警的五个案例研究，每个案例都包含智能体推理轨迹和最终 JSON 报告。
B 案例研究
- 案例研究涵盖五个告警处理示例。每个示例都展示了 CORTEX 如何处理告警。出处：B Case Studies · p. 15
- 每个示例都包含智能体推理轨迹。出处：B Case Studies · p. 15
- 每个示例还提供最终 JSON 报告。出处：B Case Studies · p. 15
B.1 案例研究 1：添加用户工作流
第一个案例研究跟踪一条新用户告警：检索目标的目录记录、判定其管理员角色，并依据策略给出可执行的结论。
B.1 案例研究 1：添加用户工作流
- 该告警涉及向租户添加一名拥有高权限的新用户。出处：§B.1 · p. 15
- 检索到目标用户记录，确认其为管理员；GlobalAdmin 被列为角色证据。出处：§B.1 · p. 15
- 报告认为，根据策略，授予管理员权限需要采取行动，并建议升级处理。出处：§B.1 · p. 15
B.2 案例研究 2：身份验证变更流程
即使账户并非新建，该流程仍将已有用户移除 MFA 视为需要采取行动的情况。
B.2 案例研究 2：身份验证变更流程
- 该事件是一名已有用户从 MFA 切换为密码登录。已找到该账户，记录显示其创建于 2019 年，创建时间已超过 30 天。出处：§B.2 · pp. 15–16
- 按照给定的推理，移除身份验证方式始终需要采取行动。摘要将已有用户移除 MFA 标记为可能的账户失陷。出处：§B.2 · p. 16
B.3 案例研究 3：多个 ISP / 地理位置不可能性
该工作流将相隔 30 分钟的伦敦和纽约登录判定为不可能旅行，并认为应采取行动。
B.3 案例研究 3：多个 ISP / 地理位置不可能性
- 行为分析智能体将该警报匹配到“多个 ISP”工作流。证据获取智能体从外部系统检索近期登录活动。出处：§B.3 · p. 16
- 推理将该模式判定为不可能旅行，并认为应采取行动。追踪记录将 impossible_travel 标记为 true，并将伦敦至纽约的活动概括为不可能旅行。出处：§B.3 · p. 16
- 伦敦和纽约之间相距约 5,500 km，在 30 分钟内登录超出了可行的旅行时限。查询到的活动显示，伦敦登录时间为 10:15 UTC，纽约登录时间为 10:45 UTC。出处：§B.3 · p. 16
B.4 案例研究 4：Office 365 来宾工作流
该来宾工作流识别出一条面向 Finance 组的邀请，但由于来宾没有管理员权限，判定其无需采取行动。
B.4 案例研究 4：Office 365 来宾工作流
- 行为分析 Agent 将该警报与来宾用户模式相匹配。该事件涉及一名受邀加入 Finance 组的来宾用户。出处：§B.4 · p. 16
- 系统找到了该来宾记录，其管理员角色列为 User。轨迹将该来宾的角色描述为标准用户权限，且不包含管理员角色。出处：§B.4 · p. 16
- 推理结果称，根据策略，该来宾没有管理员权限，因此该邀请无需采取行动。摘要描述该来宾已被添加到 Finance 组，但没有管理员权限。出处：§B.4 · pp. 16–17
B.5 案例研究 5：PowerShell 工作流
该工作流识别带有注册表持久化行为的恶意 PowerShell，并在清除后仍将管理员的执行行为升级处理以便跟进。
B.5 PowerShell 工作流
- 编码后的 PowerShell 和基于注册表的持久化被判定为恶意行为。该工作流检查命令属性和注册表持久化行为。出处：§B.5 · p. 17
- 端点遥测表明，该检测已完成清除。记录的清除状态为 Disinfect。出处：§B.5 · p. 17
- 管理员的恶意 PowerShell 执行行为符合升级策略，因此被升级处理以便跟进。尽管状态为已清除，摘要仍保留持久化行为这一发现。出处：§B.5 · p. 17