zkace01/threat-intel-mcp

# threat-intel-mcp 一个用于威胁情报查询和富化的 MCP 服务器，支持 STIX 2.1 标准化、MISP/YARA 富化，以及基于此构建的真实 Cortex XSOAR 集成。 ## 目标 本项目提供了一个可重用的威胁情报富化构建块，可以通过两种方式使用： 1. **作为 MCP 工具** — 任何兼容 MCP 的 AI 客户端（Claude、内部 SOC 副驾驶等）都可以调用它来查询指标（IP、哈希、域名），并获得一个标准化的、符合 STIX 规范的答案，而不需要模型直接知道如何调用 AbuseIPDB 或 MISP。 2. **作为 Cortex XSOAR 集成** — 相同的富化逻辑被作为一个标准的 XSOAR 集成（使用 `demisto-sdk` 构建）公开，因此它可以在 playbook 中作为自动化步骤运行，而不仅仅是由聊天代理驱动的对话。 以这种方式构建的意义在于，富化逻辑只需编写一次，就可以从 AI 代理环境和经典的 SOAR 自动化环境中同时使用 —— 这正是安全自动化工程师角色所面临的“AI + SOAR”问题的实际形态，而不是两个互不相连的演示。 次要目标：这是一个作品集项目。它的构建旨在供评估 MCP 服务器开发、威胁情报数据建模（STIX）和 SOAR 集成开发方面实际技能的人阅读 —— 它不是一个生产系统。 ## 架构 ``` ┌──────────────────┐ ┌───────────────────┐ │ MCP Client │ │ Cortex XSOAR │ │ (Claude / agent) │ │ Playbook │ └────────┬─────────┘ └─────────┬───────────┘ │ MCP protocol │ calls integration │ │ (demisto-sdk) ┌────────▼───────────────────────────────────▼───────────┐ │ Enrichment Core │ │ (shared Python package, no protocol-specific code)│ │ │ │ - lookup_indicator(value, type) -> NormalizedResult │ │ - enrich(indicator) -> EnrichedResult │ └────────────────────────┬─────────────────────────────────┘ │ ┌─────────────────────────┼─────────────────────────┐ │ │ │ ┌───────▼──────┐ ┌────────────▼────────┐ ┌──────────────▼──────┐ │ AbuseIPDB │ │ MISP │ │ YARA engine │ │ client │ │ (local, Docker) │ │ (sample/IOC │ │ (httpx) │ │ (pymisp) │ │ enrichment) │ └───────┬──────┘ └────────────┬────────┘ └──────────────┬──────┘ │ │ │ └─────────────────────────┼─────────────────────────┘ │ ┌────────▼─────────┐ │ STIX 2.1 │ │ normalization │ │ (stix2) │ └────────┬─────────┘ │ ┌────────▼─────────┐ │ Storage backend │ │ (abstract; │ │ in-memory by │ │ default, pluggable│ │ SQLite/Postgres) │ └───────────────────┘ ``` **值得说明的设计决策：** - **富化核心与协议无关。** MCP 服务器和 XSOAR 集成都是同一个核心包的轻量级适配器 —— 无论是 MCP 工具定义还是 demisto-sdk 集成脚本都不包含业务逻辑。这才是让“可从 AI 代理和 SOAR playbook 中同时使用”成为现实的原因，而不是两个随后会产生偏差的独立实现。 - **XSOAR 集成是真实的，而非模拟的。** 使用官方的 `demisto-sdk` (`demisto-sdk init --integration`) 构建，生成的是实际可安装的集成（YAML 规范 + Python 脚本），而不是模拟的调用。 - **没有用户管理。** 这不是多用户系统。MCP 服务器具有简单的 API 密钥认证来保护 endpoint —— 这是身份验证，而不是用户管理，这也是范围内唯一的访问控制问题。 - **存储被抽象化，没有预先实现。** 从一开始就存在一个 `StorageBackend` 接口 (`save_lookup()` / `get_cached()`)，默认使用内存存储。这使得 MVP 保持无状态，同时让以后插入 SQLite 或 Postgres（例如，用于缓存查询或保留富化历史记录）变得非常简单，且无需触及核心逻辑。 **组件：** - `core/` — 与协议无关的富化逻辑（`lookup_indicator`、`enrich`），由两个适配器共享 - `clients/` — 外部源客户端（AbuseIPDB、MISP、YARA） - `normalization/` — 将每个源的响应转换为 STIX 对象（Indicator、Observable） - `storage/` — 抽象存储后端 + 内存实现 - `models/` — 用于请求/响应的 Pydantic schema - `mcp_server/` — MCP 适配器（暴露工具：`check_ip`、`enrich_indicator`、`query_misp`） - `xsoar/` — Cortex XSOAR 集成（使用 `demisto-sdk` 构建），调用 `core/` - `tests/` ## 技术栈 - Python 3.12 - `httpx` — HTTP 客户端 - `pydantic` — schema 验证 - `stix2` — 标准化为 STIX 2.1 - `pymisp` — MISP 客户端 - `yara-python` — 规则匹配 - 官方 MCP SDK (Python) 用于服务器 - Docker 中的 MISP（本地实例，仅用于开发/演示） - Cortex XSOAR Community Edition（用于测试 playbook 集成） ## 安装说明 ``` git clone cd threat-intel-mcp python -m venv venv source venv/bin/activate pip install -r requirements.txt # 复制并填写环境变量 cp .env.example .env # ABUSEIPDB_API_KEY= # MISP_URL= # MISP_API_KEY= # MCP_SERVER_API_KEY= # 启动本地 MISP（可选，仅在测试 MISP 集成时需要） docker compose up -d misp # 运行 MCP server python -m mcp_server.main # 搭建 / 运行 XSOAR 集成（需要 demisto-sdk） pip install demisto-sdk demisto-sdk init --integration -o xsoar/ ``` ## 项目路线图 1. **MVP：** 带有针对 AbuseIPDB 的单一工具 (`check_ip`) 的 MCP 服务器，暂不支持 STIX —— 验证 MCP 协议和基本流程是否可以端到端工作，然后再添加建模复杂性。 2. 对 AbuseIPDB 响应进行 STIX 2.1 标准化，并将富化逻辑重构到与协议无关的 `core/` 包中。 3. 将本地 MISP 集成 (Docker) 作为第二来源，重用 STIX 标准化层。 4. 使用 `yara-python` 对样本/IOC 进行富化。 5. 真实的 Cortex XSOAR 集成（通过 `demisto-sdk`），调用 `core/`，并接入示例 playbook。 6. 最终文档：架构图、README、设计决策。 ## 状态 工作进行中 —— 作品集项目，不用于生产环境。 ## 待定决策 / 探讨中 - **MVP 优先于 STIX 的顺序：** 我倾向于在添加 STIX 之前，先针对原始 AbuseIPDB JSON 验证 MCP 服务器，而不是从第一天起就开始标准化。理由是：STIX 增加了建模复杂性；如果基本的 MCP 协议流程需要返工，最好在投入标准化之前发现。如果您更希望从一开始就使用 STIX 以避免以后重写，请明说，我们将更改顺序。 - **在 Docker 中运行本地 MISP：** 仅为演示增加了非同小可的基础设施（启动、维护、填充数据）。更轻量级的替代方案：使用 fixture 模拟 MISP 响应，并让真实集成保持“有文档记录但未部署”的状态。这取决于您想在该部分上花费多少时间，还是分配给其余部分。 - **从一开始就将 `core/` 作为共享包：** 我建议 MCP 服务器和 XSOAR 集成都建立在共享的、与协议无关的 `core/` 包之上，而不是各自实现自己的富化逻辑。这需要更多的前期设置（一个额外的抽象层），但避免了以后两个适配器产生偏差。如果时间紧迫，另一种替代方案是先构建 MCP 服务器，使其端到端工作，仅在 XSOAR 集成启动时（第 5 步）才提取 `core/` —— 前期设计较少，但以后会有一些重构风险。由您决定。

标签：AI编程协议(MCP), Cortex XSOAR, IP 地址批量处理, MISP集成, SOAR自动化, STIX标准, YARA, 云资产可视化, 威胁情报, 开发者工具, 请求拦截, 运行时操纵, 逆向工具