uuluul/AI-autonomous-SOC

[]() []() []() []() []() []() NeoVigil 是一个下一代 AI 驱动的安全运营中心 (SOC)，它超越了被动检测。它实施了一个 **5 阶段主动防御生命周期** —— 在攻击路径显现之前进行预测，部署自我演进的欺骗机制来捕获攻击者的技术手段，动态地变异实时攻击面，利用 SOAR Playbook 和防火墙阻断自主遏制威胁，并通过强化学习反馈持续调整其自身的 AI 大脑。 🔗 [架构实时演示](https://uuluul.github.io/AI-autonomous-SOC/) ## 📋 目录 - [执行摘要](#-executive-summary) - [5 阶段防御生命周期](#-the-5-phase-defense-lifecycle) - [阶段 1 — 预测 (Predict)](#-phase-1--predict-topology-aware-attack-path-prediction) - [阶段 2 — 欺骗 (Deceive)](#-phase-2--deceive-self-evolving-dynamic-honeypots) - [阶段 3 — 变异 (Mutate)](#-phase-3--mutate-moving-target-defense) - [阶段 4 — 遏制 (Contain)](#-phase-4--contain-automated-containment--isolation) - [阶段 5 — 适应 (Adapt)](#-phase-5--adapt-brain-self-evolution) - [系统架构](#-system-architecture) - [核心平台能力](#-core-platform-capabilities) - [快速开始](#-quick-start) - [使用与运维](#-usage--operations) - [APT 杀伤链演示](#-the-apt-kill-chain-demo) - [配置参考](#-configuration-reference) - [技术栈](#-tech-stack) - [测试与 CI/CD](#-testing--cicd) - [许可证与致谢](#-license--acknowledgments) ## 🎯 执行摘要 传统的 SOC 平台是 **根本上反应式的**。它们等待攻击者突破边界，然后手忙脚乱地进行检测、分类和遏制。当分析师审查警报时，对手已经完成了横向移动、数据窃取并掩盖了踪迹。 **NeoVigil 颠覆了这一范式。** 与其等待违规行为，NeoVigil 构建了一个 **主动对抗架构**，迫使攻击者在杀伤链的每个阶段都处于劣势： | 传统 SOC | NeoVigil 主动防御 | |:---|:---| | 在攻击发生 **之后** 进行检测 | 在发生前 **预测** 接下来的 3 个步骤 | | 静态、可预测的基础设施 | 实时 **变异** 攻击面 | | 依赖于已知签名 | 从实时攻击者那里 **捕获** 新颖的零日技术手段 | | 人工分类，警报疲劳 | 具有 RBAC 护栏的 **自主** 响应 | | 情报是外部的、过时的 | **自我演进** —— 每次捕获都让系统更智能 | 结果是一个 **闭环防御系统**，其中： 1. **阶段 1 (PREDICT)** 预测攻击者的下一步行动， 2. **阶段 2 (DECEIVE)** 在攻击者即将到达的地方精确放置陷阱并毒化其 AI 工具， 3. **阶段 3 (MUTATE)** 变异真实基础设施，使攻击者的侦察变得毫无价值， 4. **阶段 4 (CONTAIN)** 自主阻断攻击者 IP，生成 SOAR Playbook，并自愈易受攻击的基础设施， 5. **阶段 5 (ADAPT)** 将攻击者的 TTP 存储到知识库中，并通过 RLHF 调整 AI 权重 —— **每一次事件都使系统永久变得更聪明**。 ## 🔺 5 阶段防御生命周期 ### ⚡ 阶段 1 — PREDICT：感知拓扑的攻击路径预测 阶段 1 将 NeoVigil 从检测引擎转变为 **预测引擎**。使用一个名为 **REDSPEC** (用于网络攻击的红队推测预测引擎) 的红队 LLM 角色，系统分析每个高严重性警报，并预测攻击者接下来的 3 个杀伤链步骤。 #### 工作原理 ``` High-Severity Alert → RAG Context Retrieval → Network Topology Graph ↓ ↓ ↓ REDSPEC LLM ← combines all three signals → Predicted Kill Chain ↓ 3-Step Attack Path with per-step confidence scores ↓ Risk ≥ 70 → Deploy Honeypot (Phase 2) Risk ≥ 85 → Trigger MTD (Phase 3) ``` #### 关键能力 | 能力 | 详情 | |:---|:---| | **REDSPEC 角色** | GPT-4 作为红队操作员，预测横向移动、权限提升和数据窃取路径 | | **感知拓扑** | 摄取网络图（子网、ACL、信任区域），以便预测遵循真实的网络路径 | | **CMDB 丰富** | 关联资产关键性，以确定预测的优先级 | | **RAG 增强** | 从向量知识库中检索历史攻击模式，进行基于事实的预测 | | **多租户** | 预测按 `tenant_id` 分区，以实现完全的数据隔离 | | **零日志预测** | 新颖能力：即使新租户没有 prior 警报，也能预测攻击路径 | #### 输出：预测性威胁地图 Streamlit 仪表板将预测渲染为交互式的 **🎯 预测性威胁地图**，显示： - 源主机（已失陷） - 带有每步置信度的预测杀伤链箭头 - 带有关键性光环的目标主机 - 风险评分热力着色 ### 🍯 阶段 2 — DECEIVE：自我演进的动态蜜罐 阶段 2 闭环。当阶段 1 预测攻击路径时，阶段 2 自动在预测路径上部署一个 **蜜罐** —— 一个看起来像真实目标但实际上是仪器化陷阱的真实诱饵服务。 #### 工作原理 ``` Phase 1 Prediction (risk ≥ 70) ↓ Decoy Manager → Selects template matching predicted service ↓ Docker API → Deploys honeypot container on isolated network ↓ Fluent Bit Sidecar → Streams all interaction telemetry ↓ Validation Engine → Compares actual attacker behavior vs. prediction ↓ RAG Feedback → Captured techniques indexed to knowledge base ↓ Phase 1 retrieves captures for future predictions → SYSTEM GETS SMARTER ``` #### 关键能力 | 能力 | 详情 | |:---|:---| | **8 个服务模板** | SSH, SMB, RDP, HTTP, HTTPS, PostgreSQL, MySQL, LDAP —— 每个都有真实的 Banner 和行为 | | **3 个保真层级** | LOW (仅 Banner), MEDIUM (部分协议), HIGH (完整服务模拟) | | **墓碑 TTL** | 蜜罐在可配置的 TTL（默认：4小时）后自动销毁，以防止蔓延 | | **预测验证** | 将预测技术与实际攻击者 TTP 进行比较 —— 衡量阶段 1 的准确性 | | **零日检测** | 新颖的 Payload（从未见过的哈希）被标记为供 Tier 2+ 分析师审查 | | **RAG 反馈循环** | 每次捕获都被索引回 `security-logs-knn`，使 REDSPEC 更聪明 | #### 自我演进循环 ``` Phase 1 predicts attack → Honeypot deployed on path ↑ ↓ System gets smarter Attacker hits honeypot ↑ ↓ RAG indexes capture ← Validation Engine processes telemetry ``` 这不是一个静态系统。**每个接触 NeoVigil 的攻击者都会让下一个攻击者更难得手。** ### 🔄 阶段 3 — MUTATE：移动目标防御 阶段 3 是三位一体的最后一块拼图。当 MTD 综合威胁评分达到临界阈值时，NeoVigil **动态改变实时生产基础设施** —— 伪造服务器指纹并执行零停机容器迁移 —— 以便所有攻击者的侦察瞬间失效。 #### 工作原理 ``` Trigger Sources: • Phase 1: prediction risk ≥ 85 • Phase 2: validated honeypot capture • Scanner detection: repeated probes from same IP • Manual: analyst-initiated ↓ mtd_action_queue MTD Controller → Gathers multi-signal intelligence ↓ Composite Score = 40% prediction risk + 30% honeypot captures + 20% scanner frequency + 10% asset criticality ↓ Score ≥ 60 → Obfuscation (auto-approved) Score ≥ 75 → Migration proposed (Tier2 approval) Score ≥ 85 → Migration executed (Tier2 approval) ``` #### 关键能力 | 能力 | 详情 | |:---|:---| | **Nginx/OpenResty 混淆** | 基于 Lua 的单 IP 头部伪造 —— 当你运行 Nginx 时扫描器看到的是 Apache，运行 Node.js 时看到的是 IIS | | **6 个伪造配置文件** | Apache/PHP, IIS/ASP.NET, LiteSpeed, CloudFlare, Caddy, Custom —— 每个扫描器随机选择 | | **蓝绿部署迁移** | 4 阶段零停机容器迁移：克隆 → 启动绿环境 → 排空 → 交换 | | **回滚快照** | 每次迁移在可配置的 TTL（默认：4小时）内可逆 | | **迁移后蜜罐** | 迁移后，旧容器自动转换为蜜罐 | | **RBAC 审批门** | 混淆：自动批准。迁移：需要 Tier2+。紧急锁定：需要管理员 | | **审批超时升级** | 未批准的操作在 15 分钟（可配置）后升级 | | **不可变审计追踪** | 每个动作 —— 提议、批准、拒绝、执行、回滚 —— 都记录到 `mtd-audit-log` | ### 🚨 阶段 4 — CONTAIN：自动遏制与隔离 阶段 4 采取果断行动。当阶段 3 完成 MTD 变异后，遏制引擎自主生成 SOAR Playbook，执行硬件级防火墙阻断，并自愈易受攻击的基础设施 —— 同时维护取证级的审计追踪。 #### 工作原理 ``` Phase 3 MTD Action Completed ↓ contain_tasks queue Containment Engine → Three parallel sub-engines: ↓ ↓ ↓ Playbook Generator Firewall Client IaC Analyzer (LLM + STIX 2.1) (API / Mock mode) (Nginx / Terraform) ↓ ↓ ↓ contain-playbooks contain-actions iac-patches ↓ Audit Logger → immutable timestamped evidence ↓ Dispatch to adapt_tasks queue → Phase 5 ``` #### 关键能力 | 能力 | 详情 | |:---|:---| | **LLM Playbook 生成** | Commander AI 编写带有 STIX 2.1 包的 SOAR Playbook；如果 LLM 不可用，则回退到基于规则的模板 | | **硬件级防火墙阻断** | 双模式 `FirewallClient` —— 用于预发布环境的模拟模式，用于生产环境的 Live API 模式。在几秒钟内阻断攻击者 IP | | **IaC 自愈** | AI 分析 Nginx 配置和网络拓扑中的漏洞，自动生成补丁 | | **不可变审计追踪** | 每个遏制动作（阻断、打补丁、Playbook）都记录带有时间戳的签名，用于取证和合规证据 | | **Cap-20 安全限制** | 每次事件最多 20 个同时进行的防火墙阻断，以防止意外锁定 | | **跨阶段分发** | 自动将完整的事件上下文（杀伤链、IP、Playbook、补丁）转发给阶段 5 进行适应 | ### 🧠 阶段 5 — ADAPT：大脑自我演进 阶段 5 闭环。每一次事件 —— 成功的防御或部分失败 —— 都会反馈到 AI 的知识库中并调整其预测权重。系统不仅仅是防御；它在 **进化**。 #### 工作原理 ``` Phase 4 Containment Complete ↓ adapt_tasks queue Adaptation Engine → Five sequential sub-engines: ↓ 1. STIX Quality Control → validate_stix.py (STIX 2.1 compliance) ↓ 2. Knowledge Base Population → store TTPs in cti-knowledge-base (KNN vectors) ↓ 3. RLHF Feedback Loop → compare predictions vs. actual → adjust thresholds ↓ 4. Incident Timeline → query all 5 phase indices → build correlated timeline ↓ 5. Executive Report → to_pdf.py → PDF with full Phase 1–4 lifecycle → Dashboard ``` #### 关键能力 | 能力 | 详情 | |:---|:---| | **STIX 2.1 质量门** | 在存储之前根据 OASIS 标准验证所有生成的威胁情报 | | **KNN 知识库** | 将攻击者 TTP 作为可搜索向量存储在 OpenSearch 中 —— 未来的预测利用真实的事件数据 | | **RLHF 反馈循环** | 将阶段 1 的预测与实际攻击者行为进行比较；建议调整阈值以减少误报 | | **事件时间线** | 查询所有 5 个阶段的索引以构建关联时间线 —— 一份显示攻击完整生命周期的文档 | | **高管 PDF 报告** | 自动生成的 PDF，包含事件摘要、采取的遏制措施、添加的 KB 条目和 RL 建议 | | **预测准确性跟踪** | 计算并存储每次事件的预测准确性指标，以实现持续改进 | #### 自我演进循环 ``` Phase 1 predicts attack → Honeypot deployed → Infrastructure mutated ↑ ↓ System gets smarter Threat contained & patched ↑ ↓ RLHF tunes weights ← KB stores TTPs ← Incident timeline built ← PDF generated ``` **每个接触 NeoVigil 的攻击者都会让下一个防御周期更快、更准确、更难规避。** ## 🏗️ 系统架构 NeoVigil 由通过 Docker Compose 编排的 **22 个微服务** 组成： ``` graph TB subgraph "Layer 1: Ingestion" LOG[Log Sources] -->|Tail/Syslog| FB(Fluent Bit) RSS[RSS/OSINT Feeds] -->|Crawl| IC(Intelligence Crawler) MAN[Manual Upload] -->|Monitor| MASTER(Pipeline Master) end subgraph "Layer 2: Message Bus & AI Edge Filtering" FB & IC & MASTER -->|JSON| RMQ{RabbitMQ
16 Queues} RMQ -->|log.network| AWN[Network AI Worker] RMQ -->|log.endpoint| AWE[Endpoint AI Worker] RMQ -->|log.identity| AWI[Identity AI Worker] AWN & AWE & AWI -->|anomaly| ACQ[alert_critical
Priority Queue] ACQ --> RMQ end subgraph "Layer 3: Commander AI & 5-Phase Defense" RMQ --> WORKER[Pipeline Worker] WORKER <-->|RAG| OSEARCH[(OpenSearch
Vector KNN)] WORKER <-->|Analysis| LLM[GPT-4 / Local LLM] end subgraph "Phase 1: PREDICT" RMQ --> AE[Adversarial Engine] AE <-->|REDSPEC| LLM AE <-->|Topology| TOPO[Network Graph] AE -->|risk ≥ 70| DDQ[decoy_deploy_tasks] AE -->|risk ≥ 85| MTQ[mtd_action_queue] end subgraph "Phase 2: DECEIVE" DDQ --> DM[Decoy Manager] DM -->|Docker API| HONEY[Honeypot Container] DM -->|Data Poisoning| POISON[fake_secrets + poisoned_db] HONEY -->|Telemetry| FBSIDE[Fluent Bit Sidecar] FBSIDE --> SOAR[SOAR Server] SOAR --> HPQ[honeypot_events] HPQ --> VE[Validation Engine] VE -->|RAG feedback| OSEARCH VE -->|MTD trigger| MTQ end subgraph "Phase 3: MUTATE" MTQ --> MTDC[MTD Controller] MTDC -->|Score ≥ 60| OBFENG[Obfuscation Engine] OBFENG --> PROXY[MTD Proxy
OpenResty + Lua] MTDC -->|Score ≥ 85| MIGENG[Migration Engine] MTDC -->|Validate| TWIN[Cyber Digital Twin] MIGENG -->|Docker API| BLUEGREEN[Blue/Green Swap] MTDC -->|Dispatch| CTQ[contain_tasks] end subgraph "Phase 4: CONTAIN" CTQ --> CE[Containment Engine] CE -->|LLM| PLAYBOOK[SOAR Playbook] CE -->|API| FW[Firewall Blocks] CE -->|Analyze| IAC[IaC Self-Healing] CE -->|Dispatch| ATQ[adapt_tasks] end subgraph "Phase 5: ADAPT" ATQ --> ADAPT[Adaptation Engine] ADAPT -->|Validate| STIX[STIX 2.1 QC] ADAPT -->|Store| KB[Knowledge Base] ADAPT -->|Tune| RLHF[RLHF Feedback] ADAPT -->|Generate| PDF[Executive PDF] end subgraph "Layer 4: Visualization" OSEARCH --> UI[Streamlit Dashboard
10 Pages] UI --> SOC[SOC Monitor] UI --> PTMAP[Predictive Map] UI --> MTDDASH[MTD Dashboard] UI --> CONTAIN_UI[Containment Ops] UI --> ADAPT_UI[Adaptation & Learning] end ``` ### 服务清单 | # | 服务 | 用途 | 阶段 | |:-:|:---|:---|:-:| | 1 | `opensearch-node` | 向量搜索, KNN, 遥测索引 | Core | | 2 | `opensearch-dashboards` | 数据探索与可视化 | Core | | 3 | `rabbitmq` | 消息总线 (9 个队列) | Core | | 4 | `fluent-bit` | 实时日志流 | Core | | 5 | `soar-server` | 警报中继与蜜罐遥测桥接 | Core | | 6 | `log-generator` | 模拟日志源 | Core | | 7 | `setup-worker` | 索引初始化 | Core | | 8 | `cti-pipeline-master` | 文件摄取与调度 | Core | | 9 | `cti-pipeline-worker` | AI 分析 (RAG + LLM) | Core | | 10 | `threat-hunter` | 持续 IOC 扫描 | Core | | 11 | `intelligence-crawler` | OSINT Feed 聚合 | Core | | 12 | `cti-ui` | Streamlit SOC 仪表板 | Core | | 13 | `prediction-engine` | REDSPEC 攻击路径预测 | Phase 1 | | 14 | `decoy-manager` | 蜜罐生命周期编排 | Phase 2 | | 15 | `validation-engine` | 预测验证与 RAG 反馈 | Phase 2 | | 16 | `mtd-controller` | MTD 评分, RBAC, 动作分发 | Phase 3 | | 17 | `mtd-proxy` | 带有 Lua 混淆的 OpenResty | Phase 3 | | 18 | `ai-worker-network` | 网络日志边缘过滤（端口扫描, C2） | Layer 2 | |19 | `ai-worker-endpoint` | 端点日志边缘过滤 | Layer 2 | | 20 | `ai-worker-identity` | 身份日志边缘过滤（暴力破解, Kerberoasting） | Layer 2 | | 21 | `contain-engine` | 自动遏制, SOAR Playbook, 防火墙阻断 | Phase 4 | | 22 | `adapt-engine` | 大脑自我演进, KB 填充, RLHF, PDF 报告 | Phase 5 | ## 🛠️ 核心平台能力 除了 5 阶段防御生命周期，NeoVigil 还提供完整的企业 SOC 平台： - **AI Worker 边缘过滤** —— 三个特定领域的 Worker (Network, Endpoint, Identity) 执行亚秒级基于 KNN 的噪声过滤，仅将真正的异常上报给 Commander AI - **数据投毒** —— 生成语法有效的虚假机密、带有 Canary Token 的中毒数据库，以及旨在诱导攻击者 AI (WormGPT) 产生幻觉的矛盾数据 - **网络数字孪生** —— 在模拟的并行环境中预验证每个 MTD 变异，保证执行前零业务中断 - **自动遏制** —— LLM 生成的 SOAR Playbook，硬件级防火墙 API 阻断，以及 IaC 自愈补丁 —— 全部具有取证级的审计追踪 - **自我演进的知识库** —— 每一次事件都将攻击者 TTP 输入 KNN 向量存储；RLHF 反馈调整预测阈值，使系统永久变得更聪明 - **双层 RAG** —— 查询 MITRE/AIDEFEND 专家知识库和内部历史 CTI 报告，进行基于事实的 AI 分析 - **STIX 2.1 合规** —— 通过自动化质量门生成并验证行业标准的威胁情报包 - **高管 PDF 报告** —— 自动生成报告，包含完整的阶段 1–4 事件时间线、IOC、TTP 和 AI 建议的缓解措施 - **PII 脱敏** —— 在 LLM 处理之前自动编辑 IP/电子邮件 - **GeoIP 丰富** —— 用于威胁映射的实时攻击者地理位置定位 - **CMDB 集成** —— 用于动态警报优先级排序的资产关键性评分 - **5 级 RBAC** —— Viewer → Tier 1 → Tier 2 → Admin → System Owner (符合 ISO 27001 / SOC 2) - **SOAR 护栏** —— 关键资产保护，针对内部威胁的人在回路 - **不可变审计追踪** —— 所有分析师操作记录到跨所有 5 个阶段的防篡改索引中 - **死信队列 (Dead-Letter Queue)** —— 零数据丢失；失败的任务保留供取证审查，并提供 DLQ 监控 - **多租户** —— 通过所有索引中的 `tenant_id` 分区实现完全的数据隔离 - **隐私盾** —— 本地 LLM 强制模式阻止云 API 回退 ## 🚀 快速开始 ### 前置条件 | 组件 | 最低要求 | 推荐配置 | |:---|:---|:---| | **OS** | Linux / macOS / Windows | Linux (Ubuntu 22.04+) | | **RAM** | 16 GB | 32 GB | | **CPU** | 4 核 | 8 核 | | **Disk** | 20 GB 可用空间 | 50 GB 可用空间 | | **Docker Engine** | v24.0+ | 最新版 | | **Docker Compose** | v2.20+ | 最新版 | | **Python** | 3.9+ | 3.10+ | ### 1. 克隆与配置 ``` git clone https://github.com/uuluul/AI-powered-autonomous-SOC.git cd AI-powered-autonomous-SOC cp .env.example .env ``` 编辑 `.env` 配置你的 LLM 提供商凭据： ``` # 选项 A：Standard OpenAI OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxx OPENAI_MODEL=gpt-4o # 选项 B：Azure OpenAI AZURE_OPENAI_API_KEY=your_azure_key AZURE_OPENAI_ENDPOINT=https://your-resource.openai.azure.com/ AZURE_OPENAI_CHAT_DEPLOYMENT=gpt-4o AZURE_OPENAI_EMBEDDING_DEPLOYMENT=text-embedding-3-small AZURE_OPENAI_API_VERSION=2024-02-15-preview ``` ### 2. 启动 NeoVigil ``` docker compose up -d --build ``` 这将启动所有 22 个服务。在内存 < 16 GB 的机器上： ``` docker compose up -d --build --scale cti-pipeline-worker=1 ``` ### 3. 初始化知识库（仅首次运行） ``` docker compose exec cti-pipeline-master python /app/src/setup_knowledge_base.py ``` 等待：`✅ MITRE Import Completed` / `✅ AIDEFEND Import Completed` ### 4. 验证安装 运行生产验证套件以确保所有系统运行正常： ``` ./test_all.sh ``` ### 5. 访问仪表板 打开 **[http://localhost:8501](http://localhost:8501)** 并使用 `admin / admin` 登录。 ## 📖 使用与运维 ### SOC 仪表板页面 | 页面 | 描述 | |:---|:---| | 🚨 **内部威胁监控** | 带有严重性过滤的实时 SOC 警报 | | 📈 **丰富警报仪表板** | 威胁地图，地理位置，修复 Playbook | | 🕸️ **威胁图谱** | 带有攻击覆盖的可视化网络拓扑 | | 📚 **知识库** | 历史 CTI 报告，PDF 下载 | | 🔍 **CTI 报告审查** | AI 分析批准/拒绝工作流 | | 📜 **审计与合规** | 不可变操作日志 (ISO 27001 / SOC 2) | | 🎯 **预测性威胁地图** | 阶段 1 攻击路径预测 | | 🛡️ **移动目标防御** | 阶段 3 混淆规则，审批，迁移，数字孪生验证 | | 🚨 **遏制操作** | 阶段 4 防火墙阻断，SOAR Playbook，IaC 自愈补丁 | | 🧠 **适应与学习** | 阶段 5 知识库增长，RLHF 指标，事件时间线，PDF 报告 | ### 运维工作流 **自动收集** —— 情报爬虫持续从 BleepingComputer, TheHackerNews 和 OTX AlienVault 获取信息。 **威胁狩猎** —— 狩猎模块 24/7 运行，根据批准的 IOC 扫描内部日志。匹配项自动生成警报。 **预测性防御** —— 高严重性警报触发 REDSPEC 预测。风险 ≥ 70 部署诱饵。风险 ≥ 85 触发 MTD 评估。 **MTD 审批** —— 迁移提议出现在 🛡️ MTD 仪表板中。Tier 2+ 分析师在可配置的超时窗口（默认：15 分钟）内批准或拒绝。 ## 🎬 APT 杀伤链演示 NeoVigil 附带 `simulate_apt_killchain.py` —— 一个电影般的、彩色编码的终端脚本，实时演示完整的主动防御三位一体。 ``` # 确保 NeoVigil 正在运行，然后： python simulate_apt_killchain.py ``` 该脚本模拟跨越所有 5 个阶段的完整 APT 杀伤链： 1. **阶段 1 (预测)** —— 注入 Log4Shell 初始访问事件 → 强制 REDSPEC 预测杀伤链 2. **阶段 2 (欺骗)** —— 模拟攻击者命中预测的蜜罐 → 触发验证与 RAG 反馈 3. **阶段 3 (变异)** —— 泛洪扫描器探测 → 将 MTD 评分推至 ≥ 85 → 触发混淆 + 迁移提议 4. **阶段 4 (遏制)** —— 生成 SOAR Playbook → 通过防火墙 API 阻断攻击者 IP → 分发到适应阶段 5. **阶段 5 (适应)** —— 验证 STIX 质量 → 填充知识库 → 构建事件时间线 → 生成高管 PDF ## ⚙️ 配置参考 | 变量 | 默认值 | 描述 | |:---|:---|:---| | `RETENTION_DAYS` | `30` | 保留已处理文件的天数 | | `CONFIDENCE_THRESHOLD` | `80` | PDF/阻断警报的最低分数 | | `RAG_TOP_K` | `3` | 检索的相似历史案例数量 | | `MAX_ACTIVE_DECOYS` | `10` | 最大并发蜜罐数 | | `DECOY_TTL_HOURS` | `4` | 蜜罐自动销毁计时器 | | `MTD_APPROVAL_TIMEOUT` | `15` | 未批准操作升级前的分钟数 | | `MTD_DRAIN_TIMEOUT` | `30` | 迁移期间排空连接的秒数 | | `MTD_ROLLBACK_HOURS` | `4` | 迁移保持可回滚状态的小时数 | ## 🛠️ 技术栈 | 层 | 技术 | |:---|:---| | **语言** | Python 3.10+ | | **AI/LLM** | GPT-4o, LangChain (RAG), REDSPEC (对抗角色) | | **搜索与向量 DB** | OpenSearch (KNN, Vector Search, Lucene) | | **消息总线** | RabbitMQ (16 个队列, 优先队列, 持久化, DLQ) | | **日志摄取** | Fluent Bit (流式), RSS/OTX 爬虫 (批处理) | | **边缘 AI** | AI Worker (KNN 异常评分, 模式匹配, 按域分类) | | **欺骗** | Docker SDK (容器编排), Fluent Bit Sidecar, 数据投毒引擎 | | **MTD 代理** | OpenResty (Nginx + Lua), 网络数字孪生验证 | | **遏制** | SOAR Playbook 生成器, 防火墙 API 客户端, IaC 补丁生成器 | | **适应** | RLHF 反馈循环, KNN 知识库写入器, 事件时间线构建器 | | **容器编排** | Docker & Docker Compose (22 个服务) | | **前端** | Streamlit (10 页), PyDeck (3D 地图), Plotly, Mermaid.js | | **数据标准** | STIX 2.1, MITRE ATT&CK, AIDEFEND | | **测试** | Pytest (128 个单元测试), 集成套件, E2E 5 阶段流程, CI/CD | ## 🧪 测试与 CI/CD ``` # 运行完整的 Production Validation Suite（推荐） ./test_all.sh # 运行 Phase 4/5 模块单元测试（128 个测试，无需 Docker） python3 -m pytest tests/unit/test_phase4_phase5.py -v # 运行特定测试层 python3 tests/integration/test_components.py # Integration (RabbitMQ -> Worker -> OpenSearch) python3 tests/system/verify_brain_growth.py # System (AI Learning & Indexing) python3 tests/load/api_stress_test.py # Load (API Concurrency) ``` ### 预发布环境（无 API 成本） ``` docker compose -f docker-compose.staging.yml up -d --build ``` 在端口 8000 上使用 **Mock LLM** 在本地模拟 GPT-4 响应。 ## 📜 许可证与致谢 本项目采用 **MIT 许可证** 授权。 ### 框架归属 - **[MITRE ATT&CK®](https://attack.mitre.org/)** —— 对手战术与技术映射 - **[STIX™ 2.1](https://oasis-open.github.io/cti-documentation/)** —— 用于威胁情报的 OASIS 开放标准 - **[AIDEFEND](https://github.com/edward-playground/aidefense-framework)** —— 由 Edward Lee 提出的 AI 防御框架 (CC BY 4.0) - **[OASIS stix2-validator](https://github.com/oasis-open/cti-stix-validator)** —— STIX 2.1 合规性验证 ## 🚀 未来路线图与企业级扩展性 虽然当前架构已经足够健壮，可完全用于预发布环境和演示目的，但为了处理 PB 级遥测数据并确保高可用性，我们计划在生产环境中实施以下增强功能： ### 1. 数据生命周期管理与存储分层 为了优化海量安全日志的存储成本和查询性能，我们将通过索引状态管理 (ISM) 实施 **热-温-冷架构**： * **热层：** 用于实时摄取、主动 AI 丰富和高频查询（保留期：1-30 天）。 * **温/冷层：** 用于长期合规存储、历史审计和威胁狩猎（保留期：30-180+ 天）。 * *注意：初始 ISM 策略蓝图已在 `config/opensearch_ism_policy.json` 中定义。* ### 2. 高可用性 (HA) 与集群 从单节点部署过渡到完全分布式集群： * **OpenSearch 集群：** 跨多个可用区部署专用的 Master、Ingest 和 Data 节点。 * **RabbitMQ 镜像队列：** 将 `cti_exchange` 和队列升级为集群设置，以确保节点故障期间零消息丢失。 ### 3. 分布式 AI Worker 扩缩容 (KEDA) 使用 **KEDA** (Kubernetes Event-Driven Autoscaler) 对 AI Worker 边缘过滤层进行事件驱动的自动扩缩容。每个域 Worker (Network, Endpoint, Identity) 根据其 RabbitMQ 队列深度独立扩缩容，确保在 DDoS 泛洪期间零延迟，同时在空闲期间缩减规模以最大限度减少云成本。 ### 4. 容器编排与自动扩缩容 从 Docker Compose 迁移到完全托管的 **Kubernetes (K8s)** 集群（例如 AWS EKS, GCP GKE），以实现生产级编排和弹性： * **事件驱动自动扩缩 (KEDA)：** 根据 RabbitMQ `cti_queue` 深度动态扩缩 Python AI Worker Pod。这确保了在 DDoS 攻击或遥测激增期间零延迟，同时在空闲时缩减规模以节省云成本。 * **有状态弹性：** 通过 K8s StatefulSets 部署 OpenSearch 和 RabbitMQ，并使用直接映射到我们定义的热/温存储层的持久卷 claim (PVC)。 * **自愈与零停机** 利用 K8s 存活和就绪探针保证摄取和威胁检测管道的最大正常运行时间。

标签：AI驱动的安全, Beacon Object File, BOF, CISA项目, Cloudflare, Docker, HTTP/HTTPS抓包, HTTP工具, Kubernetes, MITRE ATT&CK, NeoVigil, PE 加载器, Python, RabbitMQ, RAG双索引, SOAR剧本, SOC自动化, STIX 2.1, 下一代SOC, 主动防御架构, 人工智能安全, 动态防御, 合规性, 向量搜索, 域名收集, 威胁情报, 安全运营中心, 安全防御评估, 密码管理, 开发者工具, 异常检测, 强化学习, 态势感知, 插件系统, 攻击路径预测, 无后门, 欺骗防御, 混合日志摄取, 移动目标防御, 网络安全, 网络安全审计, 网络映射, 自主网络防御, 自动化响应, 蜜罐技术, 请求拦截, 逆向工具, 防火墙隔离, 隐私保护