Halhebshi/AI-SOC-Triage-Automation

# AI-SOC-Triage-Automation# 这是一个旨在回答一个实际问题的自主实验：Security Copilot 的定价对许多组织来说难以承受，那么能否使用 Azure OpenAI 和 Microsoft Sentinel 基于按需付费模式构建出类似的东西？ 这是一个概念验证。它远未达到企业级标准，也不能直接原样投入生产环境，但它展示了仅使用 Microsoft 技术栈中已有工具可以实现的功能。初衷是跳出标准工具提供的功能进行思考，探索在承诺全面部署 Security Copilot 之前，租户内部托管且经济实惠的 AI 分诊是否现实。 运行正常时，该流水线会自动分诊 Sentinel 事件。当分析师打开工单时，它已经包含了一份结构化的三级（Tier 3）报告：确凿的日志条目、MITRE ATT&CK 映射、可直接运行的 hunting 查询以及缓解步骤。误报会在无需人工干预的情况下自动关闭。所有事件数据都保留在 Microsoft 租户内部，且每个事件的成本以美分为单位计算。 ## 架构 当 Sentinel 事件触发时，Logic App 会提取实体（账户、设备、IP、文件名），并跨可用的遥测表运行 KQL union 查询以获取原始证据。这些证据将与事件详情打包在一起，并伴随三级 SOC 分析师 prompt 发送给 Azure OpenAI。模型会返回结构化的 JSON，Decision Matrix 随后将事件路由到四种结果之一：自动关闭、升级、排队审查或默认评论。 基于 Azure Logic Apps、Microsoft Sentinel 和 Azure OpenAI 构建。没有使用第三方工具，数据也不会离开租户。 ## 工作原理 **1. 事件触发。** Sentinel 事件触发 Logic App。实体被提取到一个目标列表中，用于界定证据查询的范围。 **2. 收集证据。** 跨可用遥测表运行 KQL union 查询： ``` union isfuzzy=true DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceLogonEvents, EmailEvents, SecurityAlert | where TimeGenerated > ago(14d) | where AccountName has_any (targetedEntities) or DeviceName has_any (targetedEntities) or RemoteIP has_any (targetedEntities) or FileName has_any (targetedEntities) or InitiatingProcessAccountName has_any (targetedEntities) | project TimeGenerated, Type, ActionType, AccountName, DeviceName, RemoteIP, FileName, TableName=Type | sort by TimeGenerated desc | take 50 ``` **3. AI 深度分析。** 事件详情和 KQL 证据被发送给 Azure OpenAI，并附带三级 SOC 分析师 system prompt。模型输出包含六个字段的结构化 JSON： | 字段 | 用途 | |---|---| | ActionableRecommendation | 自动关闭、排队或升级 | | PrimaryIndicator | 具体的确凿日志条目及其确认威胁的原因 | | ExecutiveSummary | 简明的非技术性摘要 | | TechnicalAnalysis | 包含 MITRE ATT&CK 映射的详细报告 | | InvestigationKQL | 用于深度 hunting 的可直接运行的 KQL 查询 | | NextSteps | 手动缓解步骤 | **4. Decision Matrix 路由。** switch 操作根据模型自身的建议执行，而不是依赖硬编码的规则： - **自动关闭**：事件作为误报关闭，并带有解释性评论 - **升级**：分配事件，提高严重性，将完整分析报告作为事件评论发布 - **排队**：发布三级分析，保留事件供分析师审查 - **默认**：为任何无法顺利解析的内容发布评论 升级逻辑信任模型的建议字段。prompt 负责推理；flow 负责路由。 ## 实际结果 来自实验室的一个真实事件：在混合加入的 endpoint 上发生了带有编码命令执行的可疑 PowerShell 下载。 在无需分析师干预工单的情况下，系统将创建多个具有 GUID 类似名称的 `.key` 文件标记为勒索软件活动的主要指标 (T1486)，识别出指向多个外部 IP 的出站连接为潜在的 C2，生成了跨 `DeviceFileEvents`、`DeviceProcessEvents` 和 `DeviceNetworkEvents` 的特定设备 hunting 查询，建议立即隔离主机，升级了事件，并将严重性从中级提高到高级。完整的报告已自动作为事件评论发布。 (screenshots/logic-app-flow.png) (screenshots/decision-matrix.png) (screenshots/incident-report.png) ## 设计决策 **Prompt enrichment，而非 RAG。** 会针对每个事件收集实时的 KQL 证据，并在 runtime 注入到 prompt 中。没有向量存储，没有检索步骤。值得一提的正确命名。 **成本。** Security Copilot 需要专用的 SCU 配额。本项目基于 Azure OpenAI 的按需付费定价运行，这对于规模较小的安全团队来说是完全不同的考量。 **数据边界。** Azure OpenAI 在 Azure 订阅中运行。事件数据不会离开租户，这对于对合规性敏感的环境至关重要。 ## 已知局限性 跨六个表的 union 查询对于真实的生产环境来说范围太广。它在实验室中可行，但面对每日大量数据摄入的企业级 Sentinel 工作区时将无法支撑。 下一次迭代将首先根据告警产品名称进行路由，并按来源运行定向查询：MDE 告警仅查询设备表，身份告警仅查询 sign-in 和 MDI 表。更窄的查询，在 prompt 中产生的噪音更少，token 成本更低。

标签：AI, Azure OpenAI, Microsoft Sentinel, 大语言模型蜜罐, 安全运营, 扫描框架, 自动化代码审查, 自动化分类