JaytlinRepo/threat-intel-platform

GitHub: JaytlinRepo/threat-intel-platform

一款企业级威胁情报平台的交互式原型,以证据严谨性、闭环处置和租户级隔离为核心差异化,对标ThreatConnect等成熟产品。

Stars: 0 | Forks: 0

# 威胁情报平台 这是一款围绕 `docs/design.md` 设计规范构建的企业级威胁情报平台交互式原型。其定位对标 ThreatConnect / Anomali / Recorded Future,但在范围上刻意更加聚焦,并在证据严谨性、闭环处置以及租户级隔离方面有着更明确的承诺。 这是一个**功能性 UI 原型**。没有实时后端,没有真实的 Azure 租户,也没有真实的订阅源——该平台连接的是一个预置的内存存储(Zustand),因此每个屏幕都表现得像一款真实产品,而无需底层基础设施支持。提交的数据会在当前会话中持久化;刷新页面会重置状态。 ## 三项架构承诺(差异化所在) 1. **拒绝无上下文的指标** —— 每次提交都必须携带或自动生成证据包,随后才能被查询。 2. **闭环处置** —— 每个已发布的指标都会被全程追踪,以确认其是否真正拦截了攻击,并对绕过原因进行分类。 3. **基于 Azure 的租户级隔离** —— 专用订阅、CMK、无共享数据平面、无跨租户 ML。 ## 包含的功能 - **分发 / Dashboard** —— 相关性排名队列。内部观测是最强的单一信号。数量被明确排除在权重计算之外;批量扫描器会被视觉标记并抑制,除非在内部也被观测到。 - **指标详情** —— 三层裁决,包含评分 + 不确定性区间 + 完整度。完整分解:单条证据贡献度、独立性加权聚合、完整度调整。包含监管链、传递性证据视觉区分和闭环处置的证据卡片。**来源资源**面板可用于刷新现有记录的 GreyNoise / VirusTotal 上下文。 - **提交流程** —— 包含 4 个字段的表单。三层验证(schema → 内容质量 → 厂商富化 → 完整度缺口检测)。将厂商声明作为输入展示,而非平台结论。LLM 充当指导者,而非守门人。在同行评审下从临时状态转为发布状态。 - **案例、处置、来源、情报需求、威胁组织、审计、设置** —— 均已上线并可导航。 - **角色切换器** —— 在 Viewer / Analyst / Senior Analyst / CTI Lead / Admin 之间切换,以查看权限模型的实际约束。强制默认为 Viewer;提交需要 Analyst 及以上权限;提升需要 Senior Analyst 及以上权限。 - **租户标签** —— 位于每个页面的顶部。展示专用的 Azure 订阅、区域和 CMK 信息。 ## 技术栈 - Next.js 14 (App Router) + TypeScript - TailwindCSS + shadcn 风格的基础组件 - Zustand 用于内存状态管理 - Radix UI 基础组件 + Lucide 图标 ## 在本地运行 ``` npm install npm run dev # 打开 http://localhost:3000 ``` ## 项目结构 ``` app/ (app)/ layout.tsx # Sidebar + topbar shell dashboard/ # Relevance-ranked triage queue indicators/ # List + detail (verdict decomposition, evidence, disposition) submit/ # 4-field submission with 3 validation layers + gap questions cases/ # Case list + detail disposition/ # Closed-loop dashboard sources/ # Per-tenant source reliability intelligence-requirements/ threat-groups/ # Alias resolution (APT29 = Cozy Bear = Midnight Blizzard) audit/ # Immutable, customer-owned audit trail settings/ # Tenant, identity, integrations, service principals components/ ui/ # Button, Card, Badge, Input, Select, Tabs, etc. shell/ # Sidebar, Topbar verdict/ # VerdictBar, VerdictDecomposition, EvidenceList triage/ # TriageRow with relevance breakdown lib/ types.ts # Indicator, Evidence, Verdict, Disposition, Case, IR, etc. scoring.ts # Three-layer verdict model relevance.ts # Composite relevance computation validation.ts # Schema / content / completeness validators rbac.ts # Two-role permission model (User / Admin) store.ts # Zustand session store seed.ts # Seeded dataset enrichment/ # On-submit + on-demand vendor enrichment (GN, VT) connectors/ # Adapter framework + vendor API fixtures integration-credentials.ts # Per-vendor credential vault (prototype: localStorage) tests/ enrichment.test.ts # Orchestrator, gaps, evidence mapping enrichment-vendor-contracts.test.ts # Mock API → adapter → display → storage enrichment-apply.test.ts # Idempotent evidence attach on detail refresh ``` ## 与设计文档的映射关系 | 文档章节 | 已实现的功能 | |---|---| | §2.1 拒绝无上下文指标 | `validateSchema` + `app/(app)/submit` 中必需的分析上下文 | | §2.3 结合检测栈的闭环 | `app/(app)/disposition` + 单个指标的处置卡片 | | §2.5 租户级隔离 | 顶栏租户标签,`app/(app)/settings` 的 Tenant 标签页 | | §2.6 数据展示,而非摘要 | 全局无 AI 生成的叙述;Dashboard 均展示原始数据 | | §2.7 相关性优于数量 | `lib/relevance.ts` + Dashboard 排序,批量扫描器抑制 | | §3.1–3.3 数据模型 | `lib/types.ts` — Indicator/Evidence/Verdict/Disposition + 传递性区分 | | §4.1–4.6 三层评分 | `lib/scoring.ts` — 分层贡献度 → 聚合 → 裁决组装 | | §5.2 临时状态 vs. 发布状态 | Indicator 状态机;提升受限于 Senior Analyst 角色 | | §5.5 闭环处置追踪 | 种子数据中已分类的绕过原因;处置页面摘要 | | §6.2 三层验证 | `lib/validation.ts` + 带覆盖路径的提交 UI;在检查完整度缺口前进行厂商富化 | | §6.7 LLM 角色边界 | 验证面板叙述了该边界;确定性模拟;厂商展示资源,而非结论 | | §7 角色与权限 | `lib/rbac.ts` + 顶栏中的角色切换器 + 受控 UI | ## 刻意未包含的内容(暂无) - 真实的后端 / 数据库。预置的内存存储是该原型的唯一事实来源。 - 真实的 RAG / 订阅源 / Azure 租户。架构层面的设计通过 UI 标签和租户标签来呈现。 - 实施计划 / 设计文档中的 §8+ 部分。这些内容应随后单独进行。 - 会议风格自由格式输入 —— 这是 Sovexa 的概念,并不属于本平台设计的一部分。 ## 许可证 私有。保留所有权利。
标签:masscan, React, Syscalls, UI设计, Zustand, 企业安全, 前端原型, 威胁情报平台, 网络资产管理, 自动化攻击