UscTrojansDodgers56/ai-assisted-soc-triage-lab

GitHub: UscTrojansDodgers56/ai-assisted-soc-triage-lab

该项目通过本地 LLM 对真实 SOC 告警进行分析,并诚实审计模型在 MITRE ATT&CK 映射和 IOC 提取方面的可靠性与幻觉问题。

Stars: 0 | Forks: 0

# AI 辅助 SOC 分诊实验室 SOC 检测系列的一部分。本实验室将一个本地托管的大型语言模型(运行 llama3.1:8b 的 Ollama)接入 SOC 分析师分诊工作流,然后客观审计了模型在哪些方面提供了帮助,又在哪些方面产生了幻觉。 **这是一个个人自主完成的实验室。并非专业的 SOC 实战经验。** ## 本实验室的目的 提取在之前实验室中已生成的真实告警,将其交给本地 AI 模型,让其总结告警、映射到 MITRE ATT&CK、建议分诊步骤,并起草事件报告。然后由人工验证并纠正输出。目标不是证明 AI 有效。而是精准衡量它在哪些方面可靠,哪些方面不可靠。 **定义本实验室的硬性限制:**模型必须在本地运行。任何告警数据、日志、IOC 或凭据(即使是模拟的)都不能离开当前环境。云聊天机器人总结安全日志是一种新奇事物,但存在数据处理风险。在本地执行相同工作的模型才是真正的 SOC 管控手段。 这是路径 A:使用 AI 完成分析师的工作。它刻意排除了路径 B(保护像 Azure OpenAI 或 Purview 等 AI 系统),该部分将留作以后的综合毕业实验室。 ## 环境 | 组件 | 详情 | |---|---| | 本地工作站 | Lenovo ThinkPad P14s Gen 6, Windows 11, PowerShell | | 本地虚拟机 | VMware Workstation, Ubuntu Linux, 托管 Splunk 和 Ollama | | 云端 | 3 台 Azure 虚拟机,每次会话后释放 | | SIEM | Microsoft Sentinel (KQL) + Splunk (SPL) | | 模型 | llama3.1:8b 通过 Ollama 运行,仅使用 CPU 推理 | ## 方法论 五个阶段,在 SOC 检测系列中保持一致地应用: 1. **检测** —— 发现或注意到恶意事物 2. **分析** —— 深入研究它是什么以及它的作用 3. **关联** —— 将发现连成一个故事 4. **加固** —— 决定阻止或预防什么 5. **验证** —— 证明检测或防御有效 对于本实验室,加固意味着针对 AI 的失败模式强化*工作流*,而不是防火墙。 ## 检测:两个真实告警,复用自之前的实验室 **告警 1 —— GoPhish 凭据捕获**(完全在本地,零云端成本)。一次钓鱼模拟活动("Cali Test"),目标在活动启动后 60 秒内点击了链接并提交了凭据。从 Splunk(`sourcetype=gophish_access`)中提取,并与 GoPhish 管理面板自身的活动结果进行了交叉核对。 这两个告警都被导出为结构化的 JSON(见 `/alerts`),作为干净、明确的模型输入。 ## 分析:提示词 对这两个告警都使用了相同的四部分提示词结构(见 `/prompts/analyze_prompt.txt`): 1. 对所发生事件的通俗英语总结 2. 可能的 MITRE ATT&CK 技术,附带技术 ID 3. 推荐的分诊步骤 4. 起草的事件报告段落 ## 关联:根据真实情况对模型进行评分 模型做出的每一个 MITRE ATT&CK 声明都针对官方框架进行了独立验证。 ### 告警 1 —— 钓鱼(正确答案:T1566.002, Spearphishing Link) | 模型说法 | 模型声称的名称 | 实际 MITRE 名称 | |---|---|---| | T1534 | Leverage Alternate Authentication Mechanisms | Internal Spearphishing | | T1210 | Exploit Public-Facing Application | Exploitation of Remote Services | ### IOC 提取 —— 可靠的对应项 当被要求严格从提供的告警数据中提取妥协指标时(见 `/prompts/ioc_extraction_prompt.txt`),模型在告警 1 上表现得非常干净:它列出的每个 IP、URL、用户名和密码都可以在源文件中验证,零捏造。当不存在任何内容时,它也正确地拒绝编造域名或文件哈希。 **核心发现:**模型在字面提取(阅读直接摆在它面前的内容)方面是可靠的,而在针对外部框架进行分类(从训练中回忆 MITRE ID)方面是不可靠的。失败模式不是广泛的幻觉,而是特定于需要回忆外部参考数据的任务。 ## 加固:这些证据支持的护栏 **护栏 1 —— MITRE 映射仅为草稿,需强制人工验证。**在两个告警和一次直接的自我纠正尝试中,模型从未得出正确的 MITRE 映射,也从未在出错时表达过不确定性。具体且可操作的检查:在将任何技术 ID 和名称对写入报告之前,将其与 attack.mitre.org 进行交叉核对。一个五秒钟的查询就能发现这个实验室中的每一个错误。 **护栏 2 —— IOC 提取相对可靠,但范围很重要。**对提供的数据进行字面提取/总结作为初稿是值得信赖的。区别在于:需要回忆外部技术参考数据的任务比仅需阅读所提供内容的任务具有高得多的幻觉风险。 **流程变更:**这两种任务类型不应捆绑在单个提示词中,使得可靠的答案与不可靠的答案以同等表观的自信度并列出现。此工作流的提示词模板应将 MITRE 映射(标记为需要强制验证)与 IOC 提取和总结(风险较低)分离开来。 **数据本地化管控:**所有告警数据、提示词和模型响应始终保留在本地 Ubuntu 虚拟机上。任何告警数据、IOC 或凭据在任何时候都没有离开过环境。这是此处展示的与 SOC 真正相关的管控手段,它与 AI 的输出质量相分离,且更有意义。 ## 验证:可重复性,经双向证明 **诚实的成本说明:**告警 1 完全在本地完成,零云端成本。告警 2 需要短暂启动两台 Azure 虚拟机来提取 Sentinel 数据;两台机器在导出后立即被释放。 ## 仓库内容 | 路径 | 内容 | |---|---| | `/prompts` | 所有三种测试类型逐字使用的确切提示词 | | `/alerts` | 两个结构化的 JSON 告警输入 | | `/screenshots` | 本 README 中引用的带编号的验证点截图 | ## 相关实验室 ## 使用的工具 Ollama · llama3.1:8b · Microsoft Sentinel (KQL) · Splunk (SPL) · GoPhish · Azure · PowerShell · Python (JSON 验证) *Sean White #ERSec
标签:AI合规, AI风险缓解, DLL 劫持, SOC自动化分诊, 大模型幻觉分析, 大语言模型, 安全运营中心, 本地AI部署, 网络映射, 逆向工具