企业官网建设流程全解析

从采集到告警：Anthropic-Cybersecurity-Skills 情报平台（TIP）三大核心工作流架构解析

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

本文以 building-threat-intelligence-platform 技能的 workflows.md 为主线，逐层拆解一套以 MISP、OpenCTI、TheHive、Cortex 为核心的开源威胁情报平台（TIP）的三大工作流——端到端情报流水线、事件反馈闭环与平台健康监控。读完本文，你将掌握 TIP 各层组件（采集、存储、分析、富化、响应、共享）之间的调用关系，以及如何在 Docker Compose、Python 脚本与 Prometheus 监控体系中落地这三条关键链路。

一、TIP 整体架构与六层组件定位

在深入工作流之前，先明确本技能定义的 TIP 架构分层。根据 SKILL.md 的 Key Concepts，一套完整的开源 TIP 由六层组成：

组件间的标准集成点如下：

• MISP ↔ OpenCTI：通过 OpenCTI MISP Connector 双向同步；
• OpenCTI ↔ TheHive：高置信度指标触发告警/案件创建；
• TheHive ↔ Cortex：对案件 observable 自动分析与富化；
• 全部组件 ↔ SIEM：通过 API 或 Kafka 将 IOC 实时推送到 Splunk/Elastic。

从 standards.md 可以看到各组件遵循的协议与数据格式标准：

底层标准还包括：MISP 基于 HTTPS + API Key 的推送/拉取同步协议、OpenCTI 基于 RabbitMQ 消息队列的异步 Connector 机制、Cortex 基于 Docker 且 I/O 标准化的 Analyzer，以及 Syslog/Kafka/REST API/文件导出等多种 SIEM 集成方式。这些正是三大工作流得以串起来的"管道"。

二、Workflow 1：端到端情报流水线（External Feeds → SIEM/TheHive）

这是整个 TIP 的主动脉，负责把外部原始情报加工成可被检测与响应体系直接消费的情报成品。workflows.md 给出的链路如下：

[External Feeds] --> [MISP] --> [OpenCTI] --> [Enrichment (Cortex)] --> [SIEM/TheHive] | | | | | v v v v v OSINT/Commercial Correlate Knowledge Graph VT/Shodan/AIPDB Alerts/Cases

2.1 采集与关联：外部 Feed → MISP

链路的第一跳是从外部源采集情报并汇入 MISP。本技能在 SKILL.md 的 Step 2 中给出了通过pymisp配置与拉取 OSINT Feed 的实现，默认启用四个经典开源源：

osint_feeds = [ {"name": "CIRCL OSINT", "id": 1}, {"name": "Botvrij.eu", "id": 2}, {"name": "abuse.ch URLhaus", "id": 5}, {"name": "abuse.ch Feodo Tracker", "id": 6}, ] for feed in osint_feeds: self.misp.enable_feed(feed["id"]) self.misp.fetch_feed(feed["id"])

对应地，process.py 中的configure_feeds()会遍历self.misp.feeds()，对未启用的 Feed 逐个调用enable_feed()，并返回{"enabled_feeds": [...], "total_feeds": len(feeds)}供运维确认。这一步完成"采集层 + 分析层"的初步关联：MISP 负责把异构源数据规整为事件（Event）与属性（Attribute）结构。

2.2 知识图谱化：MISP → OpenCTI

第二跳把 MISP 中的 IOC 同步进 OpenCTI 构建知识图谱。该同步由 OpenCTI MISP Connector 自动完成，SKILL.md 中的sync_misp_to_opencti()方法演示了如何验证这条链路是否健康：

connectors = self.opencti.connector.list() misp_connector = [c for c in connectors if "misp" in c["name"].lower()] if misp_connector: print(f"[+] MISP connector active: {misp_connector[0]['active']}")

值得强调的是，OpenCTI 的 Connector 基于 RabbitMQ 消息队列异步运行（见 standards.md），这意味着数据同步不会阻塞主链路。在 Docker Compose 部署清单中，OpenCTI 服务通过RABBITMQ__HOSTNAME=rabbitmq、REDIS__HOSTNAME=redis、MINIO__ENDPOINT=minio等环境变量接入消息总线、缓存与对象存储，正是为 Connector 生态准备的。

2.3 富化：Cortex 自动分析

第三跳是富化层。SKILL.md 的 Step 3 用requests直接调用 Cortex REST API，完整覆盖了"列出 Analyzer → 提交分析 → 拉取报告"三个动作：

# 列出可用 Analyzer resp = requests.get(f"{self.url}/api/analyzer", headers=self.headers, timeout=30) # 提交 observable 分析任务 job = { "data": observable_value, # 如 "198.51.100.42" "dataType": observable_type, # 如 "ip" "tlp": 2, # TLP 级别（数字编码） "message": "TIP automated enrichment", } resp = requests.post( f"{self.url}/api/analyzer/{analyzer_id}/run", json=job, headers=self.headers, timeout=30, ) # 获取完成的分析报告 resp = requests.get(f"{self.url}/api/job/{job_id}/report", headers=self.headers, timeout=60)

按 workflows.md 的标注，该层对接的典型 Analyzer 是VirusTotal、Shodan、AbuseIPDB等外部情报服务，产出的是经过第三方验证的富化结果，供后续置信度评估使用。

2.4 情报落地：推送 SIEM / 触发 TheHive

链路终点是把富化后的高置信度 IOC 推送给消费方：

• SIEM（Splunk/Elastic）：通过 API 或 Kafka 实时推送，将 IOC 写入检测规则与告警检索；
• TheHive：高置信度指标在 OpenCTI 中触发告警，进而创建案件供分析师跟进。

至此，一条"外部 Feed → 关联 → 知识图谱 → 富化 → 检测/响应"的完整情报生命周期闭环成形。值得一提的补充是，情报在 OpenCTI 中以 STIX 2.1 对象存储，写入指标时的模式定义可参考 api-reference.md 中的 GraphQL mutation 示例（indicatorAdd），而 agent.py 的create_stix_indicator()则演示了在代码侧如何生成带 TLP 标记、confidence 评分与 STIX pattern 的标准指标对象。

三、Workflow 2：事件到情报的反馈闭环（SOC Alert → Updated Detections）

第二条工作流解决的是"如何让内部实战经验回流成情报资产"，这是 TIP 从单向管道进化为自我增强体系的关键。链路如下：

[SOC Alert] --> [TheHive Case] --> [Cortex Analysis] --> [IOC Extraction] | v [MISP Event Creation] | v [OpenCTI Knowledge Update] | v [Updated Detections --> SIEM]

3.1 事件接入与关联分析：SOC Alert → TheHive Case → Cortex

起点是一条 SOC 告警。分析师或自动编排在 TheHive 中建立案件（Case），并把告警中的 observable（IP、域名、哈希、URL 等）交给 Cortex 分析。这部分的能力直接复用了 2.3 节的CortexEnrichment类——analyze_observable()提交分析、get_job_report()取回报告，只是调用场景从"外部情报富化"变为"案件线索深挖"。

3.2 IOC 提取与事件沉淀：→ MISP Event Creation

分析确认恶意后，从案件与 Cortex 报告中提取 IOC，在 MISP 中创建事件（Event）。MISP 的 REST API 支持直接以属性形式写入 IOC，api-reference.md 给出的示例为：

curl -X POST "https://misp/attributes/add/EVENT_ID" \ -H "Authorization: MISP_KEY" \ -H "Content-Type: application/json" \ -d '{"type":"ip-dst","value":"198.51.100.42","category":"Network activity","to_ids":true}'

注意to_ids: true表示该属性将参与 IDS 规则匹配，是"回到 SIEM 生成检测"的前置条件。

3.3 知识库回写与检测更新：→ OpenCTI → SIEM

MISP 中的新事件再通过双向同步流入 OpenCTI，更新知识图谱中实体与关系的置信度、来源与关联案件信息。最后，更新后的 IOC 被推回 SIEM，转化为新的检测规则或告警关联逻辑。由于 SKILL.md 明确要求"MISP-OpenCTI bidirectional sync operational"与"STIX/TAXII export functional"，反馈循环产出的新 IOC 也可以打包成 STIX Bundle（见 agent.py 的build_stix_bundle()）通过 TAXII 对外共享，从而让闭环收益扩散到整个情报共享社区。

这条循环的价值在于：每一次真实事件处置都会反哺平台的检测能力，使得下一次同类攻击能被更快识别，形成"检测 → 响应 → 学习 → 更强检测"的持续增强螺旋。

四、Workflow 3：平台健康监控（Prometheus/Grafana → Alert）

TIP 由多个分布式组件构成，任何一环失效都会导致情报断流或检测延迟，因此第三条工作流聚焦平台自身的可观测性：

[Prometheus/Grafana] --> [Component Health] --> [Feed Status] --> [Alert on Failure] | | v v [ES Cluster Health] [Connector Status]

4.1 组件健康探测的实现

本技能在 process.py 中提供了check_health()的工程化实现，可作为 Prometheus 自定义 Exporter 或独立健康检查脚本直接运行：

• MISP：读取self.misp.misp_instance_version，成功则标记 healthy 并附带版本号；
• OpenCTI：调用self.opencti.health.check()；
• TheHive：GET {thehive_url}/api/status，200 视为 healthy；
• Cortex：GET {cortex_url}/api/status，200 视为 healthy。

python process.py --check-health \ --misp-url https://misp.local --misp-key KEY \ --opencti-url https://opencti.local --opencti-token TOKEN

脚本把各组件探测结果汇总为 JSON（并写入--output指定的报告文件，默认tip_report.json），正好对应 workflows.md 中"Component Health"这一监控维度。

4.2 数据面与连接器状态监控

• ES Cluster Health：Elasticsearch 作为统一存储层，其集群健康状态（green/yellow/red）是 TIP 读写能力的前置指标。在 docker-compose 部署中，ES、OpenCTI、TheHive、Cortex 均声明了depends_on: elasticsearch，可见存储层一旦劣化会级联影响多个组件。
• Feed Status 与 Connector Status：这两个指标分别对应情报流入与组件协作。get_platform_stats()实现了 MISP 侧active_feeds（统计feeds()中 enabled 的 Feed 数量）与 OpenCTI 侧active_connectors（统计connector.list()中active为真的 Connector 数）的采集：

stats["misp"] = { "events": server_stats.get("event_count", 0), "attributes": server_stats.get("attribute_count", 0), "active_feeds": len([f for f in feeds if f.get("Feed", {}).get("enabled")]), } stats["opencti"] = { "active_connectors": len([c for c in connectors if c.get("active")]), "total_connectors": len(connectors), }

4.3 告警触发与运维面板

Prometheus 抓取上述指标后，由 Grafana 展示看板（组件健康、Feed 状态、Connector 状态、ES 集群健康），并基于阈值规则在组件失联、Feed 抓取失败或 Connector 停止时触发告警。template.md 提供了现成的运营报告骨架，包含平台健康表、Feed 摄入状态表、平台指标表（Total Events/Reports、Total Indicators、Active Feeds、Enrichment Jobs 24h）与 Connector 状态表，可直接作为日常巡检与告警后复盘的标准模板。

五、三大工作流如何协同：一次完整的情报生命周期

将三条工作流放在一起看，它们分别覆盖了 TIP 运行的不同阶段：

三者形成"流水线供血、闭环增强、监控护航"的整体运转模式。部署时建议按 SKILL.md 的 Docker Compose 清单一次性拉起存储层（Elasticsearch/Redis/RabbitMQ/MinIO）与四大应用（MISP/OpenCTI/TheHive/Cortex），随后依次验证三条链路。技能给出的 Validation Criteria 可作为落地验收清单：四个组件均可访问、MISP-OpenCTI 双向同步正常、至少 3 个 OSINT Feed 在摄取数据、Cortex Analyzer 能返回富化结果、指标看板实时更新、STIX/TAXII 导出可用——其中 Feed、Connector、指标与同步状态，正是三大工作流各自健康与否的直接判据。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills