grrttmrtn1/mitre-map
GitHub: grrttmrtn1/mitre-map
面向企业防御团队的检测覆盖率管理平台，将 SIEM 检测与安全工具映射到 MITRE ATT&CK 和 D3FEND 框架，结合威胁组织追踪、合规映射和紫队演习实现检测能力的闭环管理。
Stars: 1 | Forks: 1
# MitreMap
**面向网络防御团队的企业检测覆盖率平台。**
MitreMap 可将您的 SIEM 检测和安全工具映射到完整的 MITRE ATT&CK Enterprise 框架，将它们与 MITRE D3FEND 对抗措施和 ATT&CK 缓解措施相关联，针对跟踪的威胁组织对您的风险暴露进行评分，并突出显示优先级缺口——所有这些都在一个深色模式的仪表板中完成。
## 功能特性
### 身份验证与用户管理
- **登录页面** — 使用 JWT 访问令牌（15 分钟过期）和 30 天 httpOnly 刷新 Cookie 进行邮箱/密码登录
- **多用户角色** — `admin`（完全访问权限），`analyst`（读/写），`readonly`（仅查看）
- **OIDC / SSO** — 可配置的 OAuth2/OIDC 提供商；新用户在首次登录时自动配置为 `analyst`
- **引导模式** — 无锁定：应用程序在创建第一个用户或 API 密钥之前开放运行
- **引导管理员** — 在 `.env` 中设置 `ADMIN_EMAIL` + `ADMIN_PASSWORD`，以便在首次运行时生成初始管理员
- **用户管理** — 用户的完整 CRUD 操作、密码重置（使所有活动会话失效）以及激活/非激活切换
### 覆盖率情报
- **ATT&CK 矩阵热力图** — 包含父技术和子技术的完整 14 战术矩阵；每个单元格的状态（`full` / `detected` / `mitigated` / `tuning` / `planned` / `gap`）
- **D3FEND 映射** — 跨越 Harden / Detect / Isolate / Deceive / Evict 的 68 项对抗措施，映射到 ATT&CK 技术
- **覆盖率快照** — 时间点基线；趋势线显示一段时间内的覆盖率百分比
- **缺口分析** — 根据威胁组织暴露程度、合规性影响和现有缓解措施对每个未检测到的技术进行排名
### 检测管理
- 针对具有多选技术、严重性、置信度、误报率的 SIEM 检测的完整 CRUD 操作
- **批量操作** — 多选行、批量更新状态或删除
- **CSV 导入** — 粘贴或上传带有分号分隔的技术 ID 的检测 CSV 文件
- **SIGMA 规则导入** — 粘贴 YAML，预览提取的 ATT&CK 技术 ID，作为检测导入
- 按状态、严重性和源平台进行过滤
### 安全栈管理
- 具有供应商、类别和状态跟踪的工具清单
- 每个工具的 D3FEND 对抗措施和 ATT&CK 缓解措施链接
- 覆盖率贡献 — 每个工具对整体覆盖率矩阵的贡献
### 威胁情报
- **18 个追踪的威胁组织** — APT29、APT28、Lazarus、APT41、FIN7、Sandworm、Turla、Scattered Spider、Wizard Spider 等
- **完整 CRUD** — 创建、编辑和删除威胁组织；使用内联可搜索选择器分配 ATT&CK 技术的任何子集
- **每个 TTP 的程序** — 记录组织使用的每项技术的特定观察到的行为：命令行、脚本、工件路径、文字描述或参考链接。每个程序都有类型、颜色编码，并且可以在详细信息面板中内联编辑。
- 每个组织的检测覆盖率，带有技术级状态（detected / exposed）
- 每个组织的暴露百分比和风险级别
- 分面板详细信息视图，包含完整的技术和程序细分
### 风险评分
- **总体风险评分（0–100）** — 根据覆盖率缺口、暴露的威胁组织和高组织重叠技术进行加权
- 按战术划分的风险评分 — 条形图识别暴露最高的杀伤链阶段
- 按技术划分的风险评分 — 用于热力图优先级排序的可排序表格
### 合规映射
- **NIST CSF 2.0** — 所有 6 个功能（GV / ID / PR / DE / RS / RC）及控制级别的覆盖情况
- **CIS Controls v8** — 映射到 ATT&CK 技术的 18 项控制措施
- 每个框架的缺口报告 — 显示哪些控制措施没有活动的检测覆盖
### 报告与导出
**报告构建器** — 从模块化部分（覆盖总结、风险评分、缺口表、威胁环境、战术细分、合规缺口）撰写自定义执行和操作报告，并导出为 PDF 或复制为 Markdown。
| 导出 | 格式 | 端点 |
|---|---|---|
| ATT&CK Navigator 层 | JSON | `GET /api/exports/navigator` |
| 检测 | CSV | `GET /api/exports/detections/csv` |
| 安全工具 | CSV | `GET /api/exports/tools/csv` |
| 覆盖率矩阵 | JSON | `GET /api/exports/coverage/json` |
| 执行摘要 | JSON API | `GET /api/reports/executive` |
| 威胁环境 | JSON API | `GET /api/reports/threat-landscape` |
| 优先级缺口 | JSON API | `GET /api/reports/gaps` |
### ATT&CK 实时更新
- **版本跟踪** — 活动的 ATT&CK 版本存储在数据库中并显示在设置中
- **更新检查** — 管理员可以检查 GitHub 上是否有更新的 ATT&CK 版本，而无需离开应用程序
- **一键更新** — 从官方 MITRE 仓库获取最新的企业 STIX 包，并在单个事务中更新插入所有战术、技术、缓解措施和关系；可选择特定版本
- **已弃用技术跟踪** — 被更新移除或撤销的技术会记录在 `deprecated_techniques` 中，并在可用时提供被取代的指针
- **迁移扫描** — 扫描所有检测中是否引用了已弃用的技术 ID，并列出需要更新的检测
### Atomic Red Team 与自定义测试
- **ART 测试库** — 浏览按技术分组的已导入 Atomic Red Team 测试；每个测试显示名称、GUID、平台、执行器类型和生成的命令
- **实时 ART 植入** — 在首次运行时，服务器从 GitHub 获取完整的 Atomic Red Team 索引并自动植入所有测试；如果网络不可用，则回退到静态基线
- **YAML 导入** — 粘贴来自 Red Canary Atomic Red Team 仓库的任何 `atomics/*.yaml` 文件；按 GUID 跳过重复项
- **自定义测试** — 针对非来源于 ART 的自身检测测试的完整 CRUD；每个测试标记为 `source: custom`，并与导入的 ART 测试分开管理
- **测试结果** — 记录每次检测的测试结果（`untested` / `tested` / `validated` / `failed`），并附带备注和运行归属
- **覆盖率统计** — 每个 ATT&CK 技术的测试（ART + 自定义）数量的技术级计数
### 红队 / 紫队演习
将进攻性测试与防御性覆盖率闭环的正式演习管理。每次演习包含四个选项卡的工作流：
- **计划** — 创建演习（类型：`red_team` / `purple_team` / `tabletop`），分配目标威胁组织，并定义技术范围。在创建时选择威胁组织后，其所有 TTP 都会自动填充到范围中。
- **执行** — 对于范围内的每个技术，浏览可用的 ART 测试，记录结果（`detected` / `partial` / `not_detected` / `blocked` / `n/a`），并附带每次测试运行的内联备注。
- **发现** — 记录结构化的发现（类型：`gap` / `detection_validated` / `detection_failed` / `control_weakness` / `new_ttp`），包括严重性、相关技术、描述和修复建议。
- **报告** — 自动生成的紫队报告：执行摘要 KPI（检测率、范围技术、执行测试、发现）、逐技术的覆盖率细分、按严重性分组的发现以及检测缺口列表。
- **演习状态** — `planning` / `active` / `completed` / `cancelled`，包含负责人/操作员、开始/结束日期以及范围/交战规则说明。
### ATT&CK 数据源
- **源清单** — 跟踪您的组织收集了哪些日志源（Windows Event Logs、Sysmon、CloudTrail 等）；已分类且可搜索
- **收集状态** — `collecting` / `partial` / `not_collecting`，每个源都有一个自由文本的 collection-method 和备注字段
- **技术映射** — 将每个数据源链接到它能够实现检测的 ATT&CK 技术；内联显示检测覆盖情况
- **缺口分析** — 识别未检测到的技术并对缺口进行分类：无已知数据源、有收集源但无规则，或未知
### TAXII 威胁情报源
直接将来自任何 TAXII 2.1 服务器的外部威胁情报摄入到 MitreMap 中——在分析师审查之前，任何内容都不会触及您的数据。
- **服务器管理** — 通过 URL 注册 TAXII 2.1 服务器，支持 `none`、`basic` 或 `bearer` 身份验证；针对内部/自签名端点的 SSL 验证切换
- **连接测试** — 从服务器列出可用集合，而无需提交完整获取
- **计划作业** — 创建基于 cron 的摄入作业（每小时、每天、每周或自定义表达式），在后台自动获取
- **手动获取** — 随时从任何配置好的服务器触发临时获取
- **分析师审查队列** — 摄入的 STIX 对象（入侵集合、攻击模式、关系）作为待处理项暂存；分析师可以单独批准或拒绝每个项目，或者一次性批准/拒绝整批项目
- **建议操作** — 每个待处理项已预分类：`create_group`、`update_group`、`create_technique` 或 `link_technique`；批准的项目将自动应用到威胁组织和技术表
- **批次历史** — 按服务器浏览所有过去的摄入批次，包含待处理/已批准/已拒绝的计数和时间戳
- **获取状态** — 每个服务器显示上次获取状态（`running` / `success` / `error`）、项目数、跳过重复数以及失败时的错误消息
### API 测试区
- 交互式内置 API 资源管理器 — 按资源分组浏览每个端点，填充路径/查询/请求体参数，并使用您存储的 API 密钥触发实时请求。响应以语法高亮内联显示。
### OpenAPI / Swagger 文档
- **机器可读规范** — 完整的 OpenAPI 3.0 规范，通过 `GET /api/openapi.json` 提供
- **Swagger UI** — 位于 `/api/docs` 的交互式文档浏览器；无需身份验证即可浏览
### 协作
- **标签** — 应用于任何实体（检测、技术、工具、缺口）的颜色编码标签
- **评论** — 在任何实体上的线索式分析师备注
- **分配** — 将缺口或检测分配给分析师，带有优先级、截止日期和状态跟踪
- **审计日志** — 记录每个创建/更新/删除/导入/清除事件，包含操作者（远程调用时为 API 密钥名称）、源 IP 和变更差异
### 管理
- **API 密钥** — 创建具有范围的 API 密钥（`read` / `write` / `admin`），可选择过期时间；密钥在静态存储时使用 SHA-256 哈希，并且仅在创建时显示一次
- **API 密钥强制执行** — 一旦存在任何密钥，所有 API 流量都需要有效的 `Authorization: Bearer ` 标头。引导绕过允许在尚无密钥时创建密钥，因此您永远不会被锁定。
- **数据管理** — 具有实时行计数的按数据集清除（检测、工具、威胁组织、标签、评论、分配、快照、审计日志）；可在危险区域进行完全擦除
## 架构
```
┌─────────────────────────────────────────────────────┐
│ Browser │
│ React 18 · React Router · Recharts · Tailwind CSS │
└──────────────┬──────────────────────────────────────┘
│ /api/* (same-origin in production)
│ Vite proxy in development
┌──────────────▼──────────────────────────────────────┐
│ Express 4 · TypeScript · Node 20 │
│ HTTPS in production (self-signed or custom cert) │
│ │
│ Routes │
│ ├── /api/auth Login · logout · OIDC SSO │
│ ├── /api/users User management │
│ ├── /api/attack ATT&CK tactics/techniques │
│ │ ├── /check-updates Compare DB vs latest STIX │
│ │ ├── /apply-update Live STIX upsert │
│ │ ├── /version Active ATT&CK version │
│ │ ├── /deprecated Deprecated techniques │
│ │ └── /migration-scan Detection hygiene scan │
│ ├── /api/d3fend D3FEND techniques │
│ ├── /api/detections SIEM detection CRUD │
│ ├── /api/tools Security tool CRUD │
│ ├── /api/coverage Matrix & stats │
│ ├── /api/tags Entity tagging │
│ ├── /api/assignments Analyst assignments │
│ ├── /api/comments Threaded comments │
│ ├── /api/audit Audit log │
│ ├── /api/snapshots Coverage snapshots │
│ ├── /api/threat-groups APT / cybercrime groups │
│ ├── /api/compliance NIST CSF 2.0 · CIS v8 │
│ ├── /api/sigma SIGMA rule import │
│ ├── /api/atomic ART tests, custom tests │
│ │ └── /custom Custom test CRUD │
│ ├── /api/exercises Exercise management │
│ │ ├── /:id/techniques Technique scope CRUD │
│ │ ├── /:id/tests Test run CRUD │
│ │ ├── /:id/findings Finding CRUD │
│ │ └── /:id/report Purple team report │
│ ├── /api/data-sources ATT&CK data source mgmt │
│ ├── /api/exports Navigator / CSV / JSON │
│ ├── /api/reports Pre-computed reports │
│ ├── /api/risk Risk scoring │
│ ├── /api/api-keys API key management │
│ ├── /api/admin Data purge / admin ops │
│ ├── /api/motivations Threat group motivations │
│ ├── /api/countries Threat group countries │
│ ├── /api/taxii TAXII 2.1 feed management │
│ │ ├── /servers Server CRUD + test/fetch │
│ │ ├── /jobs Scheduled ingest jobs │
│ │ ├── /batches Ingest batch review │
│ │ └── /pending Per-item approve/reject │
│ ├── /api/openapi.json OpenAPI 3.0 spec │
│ └── /api/docs Swagger UI │
│ │
│ Auth middleware: JWT Bearer · API key · bootstrap │
│ Knex.js query builder · versioned migrations │
│ better-sqlite3 (synchronous WAL-mode SQLite) │
└──────────────┬──────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────┐
│ SQLite · mitremap.db │
│ │
│ attack_tactics · attack_techniques │
│ attack_mitigations · technique_mitigations │
│ attack_version_info · deprecated_techniques │
│ d3fend_techniques · attack_d3fend │
│ tools · tool_d3fend · tool_mitigations │
│ detections · tags · entity_tags │
│ comments · assignments · audit_log │
│ coverage_snapshots · threat_groups │
│ group_techniques · group_technique_procedures │
│ compliance_frameworks · compliance_controls │
│ technique_compliance · api_keys │
│ users · refresh_tokens · oidc_providers │
│ data_sources · technique_data_sources │
│ org_data_sources · art_tests (source: atomic|custom)│
│ detection_art_results │
│ exercises · exercise_techniques │
│ exercise_test_runs · exercise_findings │
│ taxii_servers · taxii_ingest_jobs │
│ taxii_pending_ingests │
└─────────────────────────────────────────────────────┘
```
**关键设计选择：**
- **SQLite + WAL 模式** — 零依赖持久化；WAL 日志实现并发读取而不阻塞写入。足以满足一个分析师团队的需要；如果需要横向扩展，请切换到 PostgreSQL（参见 [POSTGRES.md](POSTGRES.md)）。
- **全局 HTTPS** — 生产环境始终运行 TLS。如果未提供 `SSL_CERT_PATH`/`SSL_KEY_PATH`，服务器会自动生成 `selfsigned` 证书，因此不存在纯 HTTP 回退。
- **多态实体模型** — `entity_tags`、`comments` 和 `assignments` 都使用 `(entity_type, entity_id)` 键，因此相同的模式无需单独的连接表即可处理检测、技术、工具和缺口。
- **同步 DB 层** — `better-sqlite3` 是同步的，消除了服务器上的异步瀑布错误，同时保持 API 单。
- **无库的 SIGMA 解析** — 一个最小的逐行 YAML 解析器提取 MitreMap 需要的少量字段（`title`、`id`、`level`、`tags`），而无需完整的 YAML 依赖。
- **引导安全认证** — 认证中间件在请求时检查是否有任何用户或 API 密钥。零配置 → 开放访问（引导模式）。这可以防止永久锁定，并意味着全新安装无需预置凭据即可工作。
- **JWT + 刷新令牌会话模型** — 短期 JWT（15 分钟）保持服务器无状态；30 天的 httpOnly 刷新 Cookie（静态存储时使用 SHA-256 哈希）处理静默更新，而不会在 JavaScript 内存中暴露长期有效的凭据。
- **Knex.js 迁移** — 数据库模式通过编号的迁移文件进行版本控制。在启动时自动应用；可安全重复运行。
- **实时 ATT&CK 更新** — 专用的 STIX 获取模块查询官方 `mitre-attack/attack-stix-data` GitHub 仓库；更新在单个数据库事务中以更新插入语义运行，从而保留现有的覆盖率数据。
- **非 root 容器** — Docker 以专用 `mitremap` 用户（uid 1001）身份运行服务器；`gosu` 在安装任何企业 CA 证书后，在入口点处理从 root 的权限降级。
## 快速开始
### 前置条件
- Node.js ≥ 20
- npm ≥ 9
### 开发
```
git clone mitremap
cd mitremap
# 安装所有 workspace deps
npm install
# 同时启动 server (端口 4000) + client dev server (端口 3000)
npm run dev
```
打开 [http://localhost:3000](http://localhost:3000)。Vite 开发服务器将所有 `/api` 请求代理到端口 4000 上的 Express。
数据库在首次运行时在 `server/data/mitremap.db` 自动创建，并植入以下内容：
- 完整的 MITRE ATT&CK Enterprise（14 种战术，技术 + 子技术，缓解措施）— 首次运行时从 GitHub 实时获取；如果离线则回退到静态 v14.1 基线
- 68 个带有 ATT&CK 映射的 D3FEND 对抗措施
- 18 个带有技术关联的主要威胁组织
- NIST CSF 2.0 和 CIS Controls v8 合规映射
- 带有技术映射的 ATT&CK 数据源目录
- 完整的 Atomic Red Team 测试库 — 首次运行时从 GitHub 实时获取；如果离线则回退到静态基线
- 30 多个演示检测和 10 个安全工具
- 8 个预先应用于检测的演示标签
## Docker
### 设置
在启动之前将 `.env.example` 复制到 `.env` 并填写所需的值：
```
cp .env.example .env
# 编辑 .env — 至少设置 JWT_SECRET、ADMIN_EMAIL 和 ADMIN_PASSWORD
```
```
JWT_SECRET=replace-with-a-strong-random-secret
ADMIN_EMAIL=admin@example.com
ADMIN_PASSWORD=changeme
```
### 单条命令
```
docker compose up -d
```
应用程序可在 **[https://localhost:8443](https://localhost:8443)** 访问。
首次启动时会自动生成自签名 TLS 证书。接受浏览器警告或提供您自己的证书（参见下方 [自定义 TLS 证书](#custom-tls-certificate))。
SQLite 数据库持久化在命名 Docker 卷（`mitremap-data`）中。
### 自定义端口
```
MITREMAP_PORT=9443 docker compose up -d
```
### 自定义 TLS 证书
在 `.env` 中将 `SSL_CERT_PATH` 和 `SSL_KEY_PATH` 设置为容器内的路径，然后挂载您的证书目录：
```
SSL_CERT_PATH=/app/certs/server.crt
SSL_KEY_PATH=/app/certs/server.key
```
在 `docker-compose.yml` 中取消对 certs 卷的注释：
```
volumes:
- ./certs:/app/certs:ro
```
### 企业 CA 证书
信任内部/企业 CA 的两种选择：
**选项 A — 运行时注入（无需重新构建）**
挂载您的 CA 证书并在 `.env` 中设置 `ENTERPRISE_CA_BUNDLE`：
```
ENTERPRISE_CA_BUNDLE=/app/certs/enterprise-root-ca.crt
```
在 `docker-compose.yml` 中取消对 certs 卷的注释：
```
volumes:
- ./certs:/app/certs:ro
```
入口点在启动服务器之前将证书安装到操作系统信任库中。
**选项 B — 烘焙到镜像中**
在构建之前将任何 `*.crt` 文件放入仓库根目录的 `certs/` 目录中。它们将被复制到镜像中并在构建时安装。
```
mkdir -p certs
cp /path/to/enterprise-root-ca.crt certs/
docker compose build
```
### 仅构建（无 compose）
```
docker build -t mitremap:latest .
docker run -d \
-p 8443:4000 \
-e JWT_SECRET=your-secret \
-e NODE_ENV=production \
-v mitremap-data:/app/server/data \
--name mitremap \
mitremap:latest
```
### 备份数据库
```
docker exec mitremap \
sqlite3 /app/server/data/mitremap.db ".backup '/app/server/data/backup.db'"
docker cp mitremap:/app/server/data/backup.db ./mitremap-backup-$(date +%Y%m%d).db
```
### 升级
```
git pull
docker compose build --no-cache
docker compose up -d
```
现有数据库卷在重建过程中得以保留；模式在启动时会自动迁移。
### PostgreSQL
MitreMap 默认使用 SQLite。将 `DATABASE_URL` 设置为 `postgres://` 连接字符串以切换到 PostgreSQL——无需更改代码。有关完整的设置说明、Docker Compose 示例和模式兼容性说明，请参见 [POSTGRES.md](POSTGRES.md)。
```
DATABASE_URL=postgres://mitremap:changeme@localhost:5432/mitremap
```
## API 参考
所有端点都在 `/api` 下。除非另有说明，响应均为 JSON。
一旦创建了至少一个 API 密钥，每个请求都必须包含：
```
Authorization: Bearer
```
### 身份验证
| 方法 | 路径 | 描述 |
|---|---|---|
| `POST` | `/api/auth/login` | 登录 `{ email, password }` — 返回 JWT + 设置刷新 Cookie |
| `POST` | `/api/auth/refresh` | 使用刷新 Cookie 换取新的 JWT |
| `POST` | `/api/auth/logout` | 使刷新令牌失效并清除 Cookie |
| `GET` | `/api/auth/me` | 当前用户信息 |
| `GET` | `/api/auth/oidc/providers` | 列出已配置的 OIDC 提供商 |
| `POST` | `/api/auth/oidc/providers` | 创建 OIDC 提供商 `{ name, slug, issuer_url, client_id, client_secret }` |
| `PUT/DELETE` | `/api/auth/oidc/providers/:id` | 更新/删除 OIDC 提供商 |
| `GET` | `/api/auth/oidc/:slug` | 发起 OIDC 登录流程（重定向） |
| `GET` | `/api/auth/oidc/:slug/callback` | OIDC 回调处理程序（重定向到应用程序） |
### 用户
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/users` | 列出用户（id, email, name, role, is_active） |
| `POST` | `/api/users` | 创建用户 `{ email, name, password, role? }` — 角色：`admin`、`analyst`、`readonly` |
| `PUT` | `/api/users/:id` | 更新 name / role / is_active |
| `DELETE` | `/api/users/:id` | 删除用户并撤销所有会话 |
| `POST` | `/api/users/:id/reset-password` | 重置密码 `{ password }` — 使所有刷新令牌失效 |
### ATT&CK
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/attack/tactics` | 列出所有战术 |
| `GET` | `/api/attack/techniques` | 列出技术（查询参数：`tactic`，`include_subtechniques=true`） |
| `GET` | `/api/attack/techniques/:id` | 技术详情，包含缓解措施、D3FEND 和检测 |
| `GET` | `/api/attack/mitigations` | 列出所有缓解措施 |
| `GET` | `/api/attack/mitigations/:id` | 缓解措施详情，包含技术和涵盖工具 |
| `GET` | `/api/attack/version` | 数据库中活动的 ATT&CK 版本 |
| `GET` | `/api/attack/check-updates` | 将数据库版本与最新的 GitHub 版本进行比较（管理员） |
| `POST` | `/api/attack/apply-update` | 获取并应用 ATT&CK STIX 更新 `{ version? }`（管理员） |
| `GET` | `/api/attack/deprecated` | 列出已弃用/已撤销的技术 |
| `GET` | `/api/attack/migration-scan` | 引用了已弃用技术 ID 的检测 |
### 检测
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/detections` | 列表（过滤器：`status`、`severity`、`source`、`technique`） |
| `POST` | `/api/detections` | 创建检测 |
| `PUT` | `/api/detections/:id` | 更新检测 |
| `DELETE` | `/api/detections/:id` | 删除检测 |
| `PATCH` | `/api/detections/bulk` | 批量状态更新 `{ ids, status }` |
| `DELETE` | `/api/detections/bulk` | 批量删除 `{ ids }` |
| `POST` | `/api/detections/import` | 导入检测数组 |
### SIGMA 导入
| 方法 | 路径 | 描述 |
|---|---|---|
| `POST` | `/api/sigma/parse` | 解析 SIGMA YAML，返回预览 `{ title, technique_ids, ... }` |
| `POST` | `/api/sigma/import` | 将 SIGMA 规则字符串数组作为检测导入 |
### 覆盖率与风险
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/coverage/stats` | KPI 和按战术的细分 |
| `GET` | `/api/coverage/matrix` | 完整的 ATT&CK 矩阵，包含每个单元格的状态 |
| `GET` | `/api/coverage/gaps` | 缺口技术，包含 D3FEND / 缓解建议 |
| `GET` | `/api/risk/score` | 总体风险评分及组件细分 |
| `GET` | `/api/risk/by-tactic` | 按战术划分的风险评分 |
| `GET` | `/api/risk/by-technique` | 按技术划分的风险评分 |
### 威胁组织
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/threat-groups` | 列出所有组织 |
| `POST` | `/api/threat-groups` | 创建组织 `{ id, name, aliases, country, motivation, url, description, technique_ids }` |
| `GET` | `/api/threat-groups/:id` | 带有技术和检测覆盖率的详情 |
| `PUT` | `/api/threat-groups/:id` | 更新组织字段和技术分配 |
| `DELETE` | `/api/threat-groups/:id` | 删除组织及级联关联 |
| `POST` | `/api/threat-groups/:id/techniques` | 添加技术 `{ technique_ids }` |
| `DELETE` | `/api/threat-groups/:id/techniques` | 移除技术 `{ technique_ids }`（为空 = 移除所有） |
| `GET` | `/api/threat-groups/:id/exposure` | 按技术划分的暴露/检测/缓解细分 |
| `GET` | `/api/threat-groups/:id/procedures` | 该组织在所有技术中的所有程序 |
| `POST` | `/api/threat-groups/:id/techniques/:technique_id/procedures` | 添加程序 `{ type, content, source? }` |
| `PUT` | `/api/threat-groups/:id/procedures/:proc_id` | 更新程序字段 |
| `DELETE` | `/api/threat-groups/:id/procedures/:proc_id` | 删除程序 |
**程序类型：** `command` · `script` · `description` · `artifact` · `reference`
```
{
"type": "command",
"content": "powershell.exe -nop -w hidden -enc JABjAGwAaQBlAG4AdA...",
"source": "FireEye UNC2452 Report, Dec 2020"
}
```
### API 密钥
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/api-keys` | 列出密钥（已掩码 — 原始密钥在创建后永不返回） |
| `POST` | `/api/api-keys` | 创建密钥 `{ name, scopes, expires_at? }` — 仅一次返回原始密钥 |
| `PATCH` | `/api/api-keys/:id` | 更新 name / scopes / expiry |
| `DELETE` | `/api/api-keys/:id` | 撤销密钥 |
**范围：** `read`、`write`、`admin`。密钥变更（创建/更新/撤销）和数据清除操作需要 Admin 范围；`read` 范围足以列出密钥和查看可清除的数据集。密钥在静态存储时使用 SHA-256 哈希；`masked_key` 字段显示前 8 个和后 4 个字符。
### 管理 / 数据管理
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/admin/purgeable` | 每个可清除数据集的实时行计数（`read` 范围） |
| `DELETE` | `/api/admin/purge/:dataset` | 清除一个数据集：`detections`、`audit`、`snapshots`、`comments`、`assignments`、`threat_groups`、`tags`、`tools`（`admin`范围） |
| `DELETE` | `/api/admin/purge-all` | 擦除所有可变数据（FK 安全排序）（`admin` 范围） |
### 动机与国家
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET/POST` | `/api/motivations` | 列出 / 创建威胁组织动机 |
| `PUT/DELETE` | `/api/motivations/:id` | 更新 / 删除动机 |
| `GET/POST` | `/api/countries` | 列出 / 创建威胁组织国家 |
| `PUT/DELETE` | `/api/countries/:id` | 更新 / 删除国家 |
### 合规
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/compliance/frameworks` | 带有覆盖率 % 的框架 |
| `GET` | `/api/compliance/frameworks/:id` | 带有按控制覆盖率的框架详情 |
| `GET` | `/api/compliance/gap?framework_id=` | 无检测覆盖的控制 |
### 协作
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET/POST` | `/api/tags` | 列出 / 创建标签 |
| `PUT/DELETE` | `/api/tags/:id` | 更新 / 删除标签 |
| `GET/POST` | `/api/tags/:type/:id` | 获取 / 添加实体标签 |
| `DELETE` | `/api/tags/:type/:id/:tagId` | 移除实体标签 |
| `GET/POST` | `/api/comments/:type/:id` | 列出 / 添加评论 |
| `PUT/DELETE` | `/api/comments/:id` | 编辑 / 删除评论 |
| `GET/POST` | `/api/assignments` | 列出 / 创建分配 |
| `PUT/DELETE` | `/api/assignments/:id` | 更新 / 删除分配 |
| `GET` | `/api/audit` | 审计日志（过滤器：`entity_type`、`entity_id`、`actor`、`action`） |
### Atomic Red Team 与自定义测试
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/atomic/tests` | 列出所有测试（ART + 自定义） |
| `GET` | `/api/atomic/tests/:technique_id` | 特定技术的测试 |
| `GET` | `/api/atomic/coverage` | 技术级测试计数和总体覆盖率 % |
| `POST` | `/api/atomic/import` | 导入 ART YAML `{ yaml }` — 返回 `{ imported, skipped, total }` |
| `POST` | `/api/atomic/custom` | 创建自定义测试 `{ technique_id, name, description?, platform?, executor_type?, command? }` |
| `PUT` | `/api/atomic/custom/:id` | 更新自定义测试字段 |
| `DELETE` | `/api/atomic/custom/:id` | 删除自定义测试 |
| `POST` | `/api/atomic/results` | 记录测试结果 `{ detection_id, art_test_id, status, notes?, run_by? }` |
| `PUT` | `/api/atomic/results/:id` | 更新结果 status / notes |
| `DELETE` | `/api/atomic/results/:id` | 删除结果 |
**测试结果状态：** `untested` · `tested` · `validated` · `failed`
### 演习
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/exercises` | 列出所有演习（带汇总计数） |
| `POST` | `/api/exercises` | 创建演习 `{ name, type?, status?, threat_group_id?, lead?, start_date?, end_date?, scope_notes?, description? }` — 威胁组织技术自动填充 |
| `GET` | `/api/exercises/:id` | 包含技术、测试运行和发现的演习详情 |
| `PUT` | `/api/exercises/:id` | 更新演习字段 |
| `DELETE` | `/api/exercises/:id` | 删除演习及级联 |
| `POST` | `/api/exercises/:id/techniques` | 添加技术 `{ technique_ids }` |
| `DELETE` | `/api/exercises/:id/techniques/:technique_id` | 从范围中移除技术 |
| `POST` | `/api/exercises/:id/tests` | 添加测试运行 `{ art_test_id, outcome?, notes?, ran_by? }` |
| `PUT` | `/api/exercises/:id/tests/:run_id` | 更新测试运行 outcome / notes |
| `DELETE` | `/api/exercises/:id/tests/:run_id` | 删除测试运行 |
| `POST` | `/api/exercises/:id/findings` | 添加发现 `{ title, finding_type?, severity?, technique_id?, description?, recommendation? }` |
| `PUT` | `/api/exercises/:id/findings/:finding_id` | 更新发现 |
| `DELETE` | `/api/exercises/:id/findings/:finding_id` | 删除发现 |
| `GET` | `/api/exercises/:id/report` | 紫队报告 — 检测率、技术细分、缺口、按严重性分组的发现 |
**演习类型：** `red_team` · `purple_team` · `tabletop`
**演习状态：** `planning` · `active` · `completed` · `cancelled`
**测试运行结果：** `pending` · `detected` · `partial` · `not_detected` · `blocked` · `n_a`
**发现类型：** `gap` · `detection_validated` · `detection_failed` · `control_weakness` · `new_ttp`
**发现严重性：** `critical` · `high` · `medium` · `low` · `informational`
### ATT&CK 数据源
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/data-sources` | 列出所有数据源，包含组织收集状态和技术计数 |
| `POST` | `/api/data-sources` | 创建数据源 `{ name, category, description? }` |
| `PUT` | `/api/data-sources/:id` | 更新数据源字段 |
| `DELETE` | `/api/data-sources/:id` | 删除数据源及所有关联 |
| `GET` | `/api/data-sources/:id/techniques` | 映射到此源的技术（包含 `has_detection` 标志） |
| `POST` | `/api/data-sources/:id/techniques` | 添加技术映射 `{ technique_id }` |
| `DELETE` | `/api/data-sources/:id/techniques/:technique_id` | 移除技术映射 |
| `PUT` | `/api/data-sources/:id/status` | 设置组织收集状态 `{ status, collection_method?, notes? }` |
| `GET` | `/api/data-sources/technique/:technique_id` | 映射到特定技术的数据源 |
| `GET` | `/api/data-sources/analysis` | 缺口分析：按数据源可用性分类的未检测技术 |
**收集状态：** `collecting` · `partial` · `not_collecting`
### TAXII 源集成
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/taxii/servers` | 列出所有 TAXII 服务器（不含凭据） |
| `POST` | `/api/taxii/servers` | 注册服务器 `{ name, url, api_root?, collection_id?, auth_type?, username?, password?, token?, ssl_verify?, notes? }` |
| `PUT` | `/api/taxii/servers/:id` | 更新服务器字段 |
| `DELETE` | `/api/taxii/servers/:id` | 删除服务器及级联作业 |
| `POST` | `/api/taxii/servers/:id/test` | 测试连接 — 返回可用集合 |
| `POST` | `/api/taxii/servers/:id/fetch` | 触发临时获取（在后台运行，立即返回） |
| `GET` | `/api/taxii/batches` | 列出摄入批次，包含待处理/已批准/已拒绝计数 |
| `GET` | `/api/taxii/batches/:batch_id/items` | 批次中包含建议数据的项目 |
| `POST` | `/api/taxii/batches/:batch_id/approve` | 批准批次中的所有待处理项目 |
| `POST` | `/api/taxii/batches/:batch_id/reject` | 拒绝批次中的所有待处理项目 |
| `POST` | `/api/taxii/pending/:id/approve` | 批准单个待处理项目 |
| `POST` | `/api/taxii/pending/:id/reject` | 拒绝单个待处理项目 |
| `GET` | `/api/taxii/jobs` | 列出所有计划的摄入作业 |
| `POST` | `/api/taxii/jobs` | 创建作业 `{ server_id, name, schedule }` — `schedule` 是一个 cron 表达式 |
| `PUT` | `/api/taxii/jobs/:id` | 更新作业名称、计划或启用标志 |
| `DELETE` | `/api/taxii/jobs/:id` | 删除作业并停止其计划 |
| `POST` | `/api/taxii/jobs/:id/run` | 手动触发计划作业 |
**验证类型：** `none` · `basic` · `bearer`
**建议操作：** `create_group` · `update_group` · `create_technique` · `link_technique`
**待处理项目状态：** `pending` · `approved` · `rejected`
### 导出
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/exports/navigator` | ATT&CK Navigator 层 JSON（下载） |
| `GET` | `/api/exports/detections/csv` | 检测 CSV（下载） |
| `GET` | `/api/exports/tools/csv` | 工具 CSV（下载） |
| `GET` | `/api/exports/coverage/json` | 覆盖率矩阵 JSON（下载） |
### API 文档
| 方法 | 路径 | 描述 |
|---|---|---|
| `GET` | `/api/openapi.json` | OpenAPI 3.0 规范（机器可读，无需身份验证） |
| `GET` | `/api/docs` | Swagger UI（交互式浏览器，无需身份验证） |
## 技术栈
| 层 | 技术 |
|---|---|
| 前端 | React 18、TypeScript、React Router v6、Recharts、Tailwind CSS |
| 构建工具 | Vite 5 |
| 后端 | Node.js 20、Express 4、TypeScript |
| 数据库 | SQLite（通过 `better-sqlite3`，WAL 模式）或 PostgreSQL 14+（通过 `pg`）— 设置 `DATABASE_URL` |
| 模式迁移 | Knex.js（版本化迁移文件，在启动时或通过 `npm run migrate` 运行） |
| 身份验证 | JWT（`jsonwebtoken`）、bcrypt（`bcryptjs`）、OIDC（Authorization Code 流程） |
| TAXII | TAXII 2.1 客户端（原生 `http`/`https`）；用于计划摄入作业的 `node-cron` |
| API 文档 | OpenAPI 3.0 规范 + Swagger UI（`swagger-ui-express`） |
| 测试 | Vitest（单元 + 集成测试，内存 SQLite 硬件加速） |
| TLS | `selfsigned`（自动自签名证书）或通过 `SSL_CERT_PATH`/`SSL_KEY_PATH` BYO 证书 |
| 运行时工具 | `tsx`（TS 开发运行器）、`concurrently` |
| 容器 | Docker（多阶段 Alpine 构建，非 root `mitremap` 用户，`gosu` 权限降级） |
## 项目结构
```
mitremap/
├── server/
│ └── src/
│ ├── index.ts # Express app entry (HTTP dev / HTTPS prod)
│ ├── middleware/
│ │ └── auth.ts # requireApiKey — Bearer token + SHA-256 validation
│ ├── db/
│ │ ├── database.ts # getKnex(), logAudit(), raw* helpers
│ │ ├── knex.ts # Knex connection + migration runner
│ │ ├── seed.ts # Idempotent seeding
│ │ └── migrations/
│ │ ├── 001_core_schema.ts # Base schema
│ │ ├── 002_new_features.ts # Auth, ART, data sources, ATT&CK versioning
│ │ ├── 003_custom_tests.ts # source column on art_tests
│ │ ├── 004_exercises.ts # Exercises, test runs, findings
│ │ ├── 005_exercises_blocked.ts # blocked column on exercise_test_runs
│ │ ├── 006_taxii.ts # TAXII servers, jobs, pending ingests
│ │ ├── 007_taxii_fetch_status.ts# last_fetch_* columns on taxii_servers
│ │ └── 008_taxii_skipped.ts # last_fetch_skipped column
│ ├── data/
│ │ ├── attack.ts # ATT&CK tactics, techniques, mitigations
│ │ ├── d3fend.ts # D3FEND techniques + ATT&CK mappings
│ │ ├── stix-fetch.ts # Live ATT&CK STIX fetcher (GitHub)
│ │ ├── threat-groups.ts
│ │ ├── compliance.ts # NIST CSF 2.0, CIS Controls v8
│ │ ├── atomic-tests.ts # Live ART fetch + static baseline
│ │ ├── data-sources.ts # Seed ATT&CK data sources
│ │ └── demo.ts # Demo tools and detections
│ ├── taxii/
│ │ ├── client.ts # TAXII 2.1 HTTP client (basic + bearer auth)
│ │ ├── parser.ts # STIX bundle → proposed-action records
│ │ ├── ingest.ts # runFetch(), applyPendingItem(), rejectPendingItem()
│ │ └── scheduler.ts # node-cron job lifecycle
│ ├── scripts/
│ │ └── migrate.ts # Standalone migration runner (dist/scripts/migrate.js)
│ ├── openapi.ts # OpenAPI 3.0 spec definition
│ ├── __tests__/ # Vitest unit/integration tests
│ │ ├── auth.test.ts
│ │ ├── coverage.test.ts
│ │ ├── database.test.ts
│ │ ├── detections.test.ts
│ │ ├── risk.test.ts
│ │ └── helpers/testDb.ts # In-memory SQLite test harness
│ └── routes/ # One file per resource group
│ ├── attack.ts # Tactics, techniques, live updates, versioning
│ ├── auth.ts # Login, refresh, logout, OIDC
│ ├── users.ts # User CRUD + password reset
│ ├── atomic.ts # ART import, custom tests, coverage, results
│ ├── data-sources.ts # ATT&CK data source management
│ ├── exercises.ts # Exercise / purple team workflow
│ ├── taxii.ts # TAXII servers, jobs, pending-item review
│ ├── threat-groups.ts # CRUD + technique assignment + procedures
│ ├── api-keys.ts # API key lifecycle (hash, mask, revoke)
│ └── admin.ts # Data purge endpoints
├── client/
│ └── src/
│ ├── api.ts # Typed fetch wrappers for every endpoint
│ ├── types.ts # Shared TypeScript interfaces
│ ├── components/
│ │ ├── Sidebar.tsx
│ │ ├── Modal.tsx
│ │ ├── StatusBadge.tsx
│ │ ├── CoverageBar.tsx
│ │ ├── TagBadge.tsx
│ │ ├── CommentThread.tsx
│ │ ├── AssignmentPanel.tsx
│ │ └── ReportBuilder.tsx # Modular report composer
│ ├── context/
│ │ └── AuthContext.tsx # JWT auth state, OIDC, role helpers
│ └── pages/
│ ├── LoginPage.tsx # Email/password + OIDC login
│ ├── Dashboard.tsx
│ ├── AttackMatrix.tsx # Heatmap with subtechnique support
│ ├── Detections.tsx
│ ├── Tools.tsx
│ ├── DefenseMapping.tsx
│ ├── GapAnalysis.tsx
│ ├── ThreatGroups.tsx # Per-TTP procedure editor
│ ├── AtomicTests.tsx # ART + custom test browser/editor
│ ├── DataSources.tsx # ATT&CK data source management
│ ├── Exercises.tsx # Red/purple team exercise workflow
│ ├── TaxiiIngest.tsx # TAXII feed management + review queue
│ ├── Reports.tsx
│ ├── ApiPlayground.tsx # Interactive API explorer
│ └── Settings.tsx # API keys · users · ATT&CK updates · data mgmt
├── certs/ # Optional: TLS / enterprise CA certs (not committed)
├── entrypoint.sh # Docker entrypoint: CA injection → gosu privilege drop
├── Dockerfile
├── docker-compose.yml
├── .env.example # Copy to .env before running docker compose
├── POSTGRES.md # PostgreSQL setup and compatibility guide
└── package.json # npm workspaces root
```
## 许可证
MIT
## 功能特性
### 身份验证与用户管理
- **登录页面** — 使用 JWT 访问令牌（15 分钟过期）和 30 天 httpOnly 刷新 Cookie 进行邮箱/密码登录
- **多用户角色** — `admin`（完全访问权限），`analyst`（读/写），`readonly`（仅查看）
- **OIDC / SSO** — 可配置的 OAuth2/OIDC 提供商；新用户在首次登录时自动配置为 `analyst`
- **引导模式** — 无锁定：应用程序在创建第一个用户或 API 密钥之前开放运行
- **引导管理员** — 在 `.env` 中设置 `ADMIN_EMAIL` + `ADMIN_PASSWORD`，以便在首次运行时生成初始管理员
- **用户管理** — 用户的完整 CRUD 操作、密码重置（使所有活动会话失效）以及激活/非激活切换
### 覆盖率情报
- **ATT&CK 矩阵热力图** — 包含父技术和子技术的完整 14 战术矩阵；每个单元格的状态（`full` / `detected` / `mitigated` / `tuning` / `planned` / `gap`）
- **D3FEND 映射** — 跨越 Harden / Detect / Isolate / Deceive / Evict 的 68 项对抗措施，映射到 ATT&CK 技术
- **覆盖率快照** — 时间点基线；趋势线显示一段时间内的覆盖率百分比
- **缺口分析** — 根据威胁组织暴露程度、合规性影响和现有缓解措施对每个未检测到的技术进行排名
### 检测管理
- 针对具有多选技术、严重性、置信度、误报率的 SIEM 检测的完整 CRUD 操作
- **批量操作** — 多选行、批量更新状态或删除
- **CSV 导入** — 粘贴或上传带有分号分隔的技术 ID 的检测 CSV 文件
- **SIGMA 规则导入** — 粘贴 YAML，预览提取的 ATT&CK 技术 ID，作为检测导入
- 按状态、严重性和源平台进行过滤
### 安全栈管理
- 具有供应商、类别和状态跟踪的工具清单
- 每个工具的 D3FEND 对抗措施和 ATT&CK 缓解措施链接
- 覆盖率贡献 — 每个工具对整体覆盖率矩阵的贡献
### 威胁情报
- **18 个追踪的威胁组织** — APT29、APT28、Lazarus、APT41、FIN7、Sandworm、Turla、Scattered Spider、Wizard Spider 等
- **完整 CRUD** — 创建、编辑和删除威胁组织；使用内联可搜索选择器分配 ATT&CK 技术的任何子集
- **每个 TTP 的程序** — 记录组织使用的每项技术的特定观察到的行为：命令行、脚本、工件路径、文字描述或参考链接。每个程序都有类型、颜色编码，并且可以在详细信息面板中内联编辑。
- 每个组织的检测覆盖率，带有技术级状态（detected / exposed）
- 每个组织的暴露百分比和风险级别
- 分面板详细信息视图，包含完整的技术和程序细分
### 风险评分
- **总体风险评分（0–100）** — 根据覆盖率缺口、暴露的威胁组织和高组织重叠技术进行加权
- 按战术划分的风险评分 — 条形图识别暴露最高的杀伤链阶段
- 按技术划分的风险评分 — 用于热力图优先级排序的可排序表格
### 合规映射
- **NIST CSF 2.0** — 所有 6 个功能（GV / ID / PR / DE / RS / RC）及控制级别的覆盖情况
- **CIS Controls v8** — 映射到 ATT&CK 技术的 18 项控制措施
- 每个框架的缺口报告 — 显示哪些控制措施没有活动的检测覆盖
### 报告与导出
**报告构建器** — 从模块化部分（覆盖总结、风险评分、缺口表、威胁环境、战术细分、合规缺口）撰写自定义执行和操作报告，并导出为 PDF 或复制为 Markdown。
| 导出 | 格式 | 端点 |
|---|---|---|
| ATT&CK Navigator 层 | JSON | `GET /api/exports/navigator` |
| 检测 | CSV | `GET /api/exports/detections/csv` |
| 安全工具 | CSV | `GET /api/exports/tools/csv` |
| 覆盖率矩阵 | JSON | `GET /api/exports/coverage/json` |
| 执行摘要 | JSON API | `GET /api/reports/executive` |
| 威胁环境 | JSON API | `GET /api/reports/threat-landscape` |
| 优先级缺口 | JSON API | `GET /api/reports/gaps` |
### ATT&CK 实时更新
- **版本跟踪** — 活动的 ATT&CK 版本存储在数据库中并显示在设置中
- **更新检查** — 管理员可以检查 GitHub 上是否有更新的 ATT&CK 版本，而无需离开应用程序
- **一键更新** — 从官方 MITRE 仓库获取最新的企业 STIX 包，并在单个事务中更新插入所有战术、技术、缓解措施和关系；可选择特定版本
- **已弃用技术跟踪** — 被更新移除或撤销的技术会记录在 `deprecated_techniques` 中，并在可用时提供被取代的指针
- **迁移扫描** — 扫描所有检测中是否引用了已弃用的技术 ID，并列出需要更新的检测
### Atomic Red Team 与自定义测试
- **ART 测试库** — 浏览按技术分组的已导入 Atomic Red Team 测试；每个测试显示名称、GUID、平台、执行器类型和生成的命令
- **实时 ART 植入** — 在首次运行时，服务器从 GitHub 获取完整的 Atomic Red Team 索引并自动植入所有测试；如果网络不可用，则回退到静态基线
- **YAML 导入** — 粘贴来自 Red Canary Atomic Red Team 仓库的任何 `atomics/*.yaml` 文件；按 GUID 跳过重复项
- **自定义测试** — 针对非来源于 ART 的自身检测测试的完整 CRUD；每个测试标记为 `source: custom`，并与导入的 ART 测试分开管理
- **测试结果** — 记录每次检测的测试结果（`untested` / `tested` / `validated` / `failed`），并附带备注和运行归属
- **覆盖率统计** — 每个 ATT&CK 技术的测试（ART + 自定义）数量的技术级计数
### 红队 / 紫队演习
将进攻性测试与防御性覆盖率闭环的正式演习管理。每次演习包含四个选项卡的工作流：
- **计划** — 创建演习（类型：`red_team` / `purple_team` / `tabletop`），分配目标威胁组织，并定义技术范围。在创建时选择威胁组织后，其所有 TTP 都会自动填充到范围中。
- **执行** — 对于范围内的每个技术，浏览可用的 ART 测试，记录结果（`detected` / `partial` / `not_detected` / `blocked` / `n/a`），并附带每次测试运行的内联备注。
- **发现** — 记录结构化的发现（类型：`gap` / `detection_validated` / `detection_failed` / `control_weakness` / `new_ttp`），包括严重性、相关技术、描述和修复建议。
- **报告** — 自动生成的紫队报告：执行摘要 KPI（检测率、范围技术、执行测试、发现）、逐技术的覆盖率细分、按严重性分组的发现以及检测缺口列表。
- **演习状态** — `planning` / `active` / `completed` / `cancelled`，包含负责人/操作员、开始/结束日期以及范围/交战规则说明。
### ATT&CK 数据源
- **源清单** — 跟踪您的组织收集了哪些日志源（Windows Event Logs、Sysmon、CloudTrail 等）；已分类且可搜索
- **收集状态** — `collecting` / `partial` / `not_collecting`，每个源都有一个自由文本的 collection-method 和备注字段
- **技术映射** — 将每个数据源链接到它能够实现检测的 ATT&CK 技术；内联显示检测覆盖情况
- **缺口分析** — 识别未检测到的技术并对缺口进行分类：无已知数据源、有收集源但无规则，或未知
### TAXII 威胁情报源
直接将来自任何 TAXII 2.1 服务器的外部威胁情报摄入到 MitreMap 中——在分析师审查之前，任何内容都不会触及您的数据。
- **服务器管理** — 通过 URL 注册 TAXII 2.1 服务器，支持 `none`、`basic` 或 `bearer` 身份验证；针对内部/自签名端点的 SSL 验证切换
- **连接测试** — 从服务器列出可用集合，而无需提交完整获取
- **计划作业** — 创建基于 cron 的摄入作业（每小时、每天、每周或自定义表达式），在后台自动获取
- **手动获取** — 随时从任何配置好的服务器触发临时获取
- **分析师审查队列** — 摄入的 STIX 对象（入侵集合、攻击模式、关系）作为待处理项暂存；分析师可以单独批准或拒绝每个项目，或者一次性批准/拒绝整批项目
- **建议操作** — 每个待处理项已预分类：`create_group`、`update_group`、`create_technique` 或 `link_technique`；批准的项目将自动应用到威胁组织和技术表
- **批次历史** — 按服务器浏览所有过去的摄入批次，包含待处理/已批准/已拒绝的计数和时间戳
- **获取状态** — 每个服务器显示上次获取状态（`running` / `success` / `error`）、项目数、跳过重复数以及失败时的错误消息
### API 测试区
- 交互式内置 API 资源管理器 — 按资源分组浏览每个端点，填充路径/查询/请求体参数，并使用您存储的 API 密钥触发实时请求。响应以语法高亮内联显示。
### OpenAPI / Swagger 文档
- **机器可读规范** — 完整的 OpenAPI 3.0 规范，通过 `GET /api/openapi.json` 提供
- **Swagger UI** — 位于 `/api/docs` 的交互式文档浏览器；无需身份验证即可浏览
### 协作
- **标签** — 应用于任何实体（检测、技术、工具、缺口）的颜色编码标签
- **评论** — 在任何实体上的线索式分析师备注
- **分配** — 将缺口或检测分配给分析师，带有优先级、截止日期和状态跟踪
- **审计日志** — 记录每个创建/更新/删除/导入/清除事件，包含操作者（远程调用时为 API 密钥名称）、源 IP 和变更差异
### 管理
- **API 密钥** — 创建具有范围的 API 密钥（`read` / `write` / `admin`），可选择过期时间；密钥在静态存储时使用 SHA-256 哈希，并且仅在创建时显示一次
- **API 密钥强制执行** — 一旦存在任何密钥，所有 API 流量都需要有效的 `Authorization: Bearer 标签：AMSI绕过, ATT&CK框架, D3FEND, JWT认证, OIDC, Web安全, 企业安全, 威胁情报, 威胁检测, 安全仪表盘, 安全合规, 安全态势管理, 开发者工具, 权限管理, 模型越狱, 测试用例, 漏洞分析, 网络代理, 网络安全, 网络资产管理, 自动化攻击, 蓝队分析, 请求拦截, 路径探测, 防御覆盖率, 隐私保护