Kushan-Rathnayake/Vanguard-SIEM-SOAR-AI-Architecture

GitHub: Kushan-Rathnayake/Vanguard-SIEM-SOAR-AI-Architecture

一个供应商无关的闭环 SOC/SOAR/AI 架构,用于将终端遥测转化为经人机协同验证的自动化响应能力。

Stars: 0 | Forks: 0

# 🛡️ Vanguard: SIEM、SOAR 与 AI-SOC 架构 一个供应商无关的闭环 SOC 与 SOAR 架构。具备对手模拟(Atomic Red Team)、SIEM 检测工程(Wazuh/Sysmon)、无服务器自动化(Tines)以及 AI 驱动的事件分诊(Groq/Llama-3),并采用人机协同(HITL)主动响应工作流。

Project Vanguard Architecture Diagram
Figure 1: High-level closed-loop architecture mapping the full lifecycle from emulation to AI-triaged HITL remediation.

## 🎯 项目目标 **Project Vanguard** 是一个供应商无关、开源的 SOC 家庭实验室。本项目的目标是超越理论,构建一个功能完备的闭环检测与响应管道。通过结合对手模拟、自定义检测工程、无服务器自动化以及大语言模型驱动的分诊,该项目展示了如何摄取原始端点遥测数据,并将其转化为可供人类分析师操作的、增强的情报。 ## 🛠️ 基础设施与技术栈 * **云 IaaS:** 微软 Azure(Ubuntu Server 22.04 LTS / `Standard_D4s_v3`) * **端点与遥测:** Windows 11,Sysmon(SwiftOnSecurity 配置) * **对手模拟(BAS):** Atomic Red Team(ART) * **SIEM / XDR:** Wazuh 4.x * **SOAR(自动化):** Tines(无服务器企业级管道) * **AI 与威胁情报:** Groq API(Llama-3.1-8b-instant 大语言模型) * **案例管理与 ChatOps:** Jira Cloud、Slack ## 🏗️ 阶段一:基础设施与加固 为了在不推高云成本的前提下复现生产环境,整个后端均运行在单个加固型的 Azure 虚拟机上。 为避免云实例直接暴露于互联网,我配置了严格的网络安全组(NSG)规则。环境仅允许通过明确需要的端口进行入站流量:22 端口(SSH - 限制管理员 IP)、443 端口(Wazuh UI)、1514/1515 端口(代理通信)以及 55000 端口(Wazuh API)。
📸 View Infrastructure Setup Proofs
## 📡 阶段二:端点遥测与日志摄取 可见性是任何 SOC 的基础。我部署了一台本地 Windows 11 端点,并安装了 Wazuh 代理以及 **Sysmon**。通过应用 SwiftOnSecurity 的 Sysmon 配置,端点能够捕获细粒度的遥测数据(进程创建、网络连接等),并通过安全方式将其流式传输到 Azure 托管的 Wazuh 管理器。
📸 View Telemetry Pipeline Proofs
## ⚔️ 阶段三:对手模拟与检测工程 为验证 SIEM 管道,我使用 **Atomic Red Team** 模拟了 **MITRE T1059.001(PowerShell)**。我通过命令行执行了一次模拟的恶意下载启动。 没有依赖默认告警,而是我设计了一个 **Custom Level 15 Critical Wazuh 规则**。该规则使用正则表达式解析 Sysmon 事件 ID 1(进程创建),并特别将恶意命令行参数(如 `-ExecutionPolicy Bypass`)映射到相应的 MITRE ATT&CK ID。
📸 View Attack & Custom Detection Proofs
## 🧠 阶段四:SOAR 集成与告警聚合 生成告警很容易,防止告警疲劳才是真正的挑战。我配置了 Wazuh 的 `ossec.conf`,将自定义 JSON Webhook 推送到 **Tines(SOAR 平台)**。 **聚合引擎:** 为应对多阶段攻击导致的告警风暴,我在 Tines 中设计了一个 90 秒的数据批处理窗口。该机制会按端点主机名聚合传入事件,等待攻击链完成后,再将其编译为单个干净的 JSON 数组以供分析。

Tines SOAR Pipeline

📸 View Data Correlation Proof
## 🤖 阶段五:AI 驱动的分析与工单处理 一旦聚合后的遥测数据完成批处理,Tines 会触发一个指向 **Groq API** 的 Webhook,将原始 JSON 数据输入给 **Llama-3.1-8b-instant** 模型。 通过严格的系统提示工程,大语言模型充当一级(Tier 1)SOC 分析师。它解析 base64 编码的字符串与命令行参数,评估威胁,并输出结构化的摘要。随后,Tines 利用该 AI 输出,通过 **Jira Cloud** 的 Wiki 标记法生成详细、带颜色编码的事件工单。

Jira Incident Ticket

📸 View Prompt Engineering Proof
## 🚨 阶段六:人机协同(HITL)主动响应 该架构中的一个关键工程决策是避免“盲目”的自动化熔断。无认证的 API 隔离请求常常会导致自我引发的网络中断(误报)。 因此,我构建了一个 **人机协同(HITL)** 工作流。SOAR 管道会将一个交互式页面推送到 SOC 的 Slack 频道。“隔离主机”按钮提供一个安全的 **经过身份验证的深层链接**,分析师点击后会直接进入该特定端点的 Wazuh 仪表板。分析师必须登录、审查 AI 分级结果,并手动执行隔离命令。

Slack Active Response Workflow

## 🗺️ 阶段七:威胁覆盖与缺口分析 安全是一个持续的可见性映射过程。我遵循 MITRE ATT&CK 框架,将原子红队模拟的结果映射到我的管道中,以验证防御并识别盲点。

MITRE ATT&CK Heatmap
Figure 2: Custom MITRE Navigator Heatmap.

* 🟢 **已缓解(绿色):** 遥测被捕获,由 SOAR/AI 进行分析,并成功路由至 Slack 以进行 HITL 隔离(例如 T1059.001 - PowerShell、T1105 - Ingress Tool Transfer)。 * 🟡 **已检测(黄色):** 遥测已被摄取并被 Wazuh 标记,但目前需要大量调优以防止因合法管理员活动导致的告警疲劳(例如 T1027 - Obfuscated Files)。 * 🔴 **可见性缺口(红色):** 模拟的 HTTPS C2 流量因缺乏 SSL/TLS 解密而成功绕过检测。将网络 IDS(如 Suricata)集成是当前该实验室的下一个首要目标。
标签:AI驱动, AMSI绕过, Atomic Red Team, Azure, DLL 劫持, DNS 反向解析, DNS 解析, EDR, HITL, Llama 3, LLM, Modbus, SOAR, Sysmon, Tines, Unmanaged PE, Wazuh, 主动响应, 事件分类, 云端安全, 人机协作, 供应商无关, 原子红队, 大语言模型, 威胁情报, 威胁检测, 安全工具集合, 安全演练, 安全运营中心, 对手模拟, 开发者工具, 搜索语句(dork), 数据泄露检测, 无服务器自动化, 日志采集, 智能告警, 服务器less, 生成式AI安全, 端点检测, 网络信息收集, 网络安全, 网络映射, 脆弱性评估, 自动化编排, 虚拟机, 闭环, 隐私保护