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

从采集到告警:Anthropic-Cybersecurity-Skills 情报平台(TIP)三大核心工作流架构解析 从采集到告警Anthropic-Cybersecurity-Skills 情报平台TIP三大核心工作流架构解析【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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、外部 Feed从 OSINT、商业情报源与内部源接入原始情报存储层Elasticsearch/OpenSearch按 STIX 2.1 模式索引 CTI 数据分析层OpenCTI、MISPOpenCTI 构建知识图谱分析MISP 做 IOC 关联富化层Cortex通过 Analyzer 自动富化 IOC响应层TheHive案件管理与应急响应集成共享层TAXII Server对外发布情报组件间的标准集成点如下MISP ↔ OpenCTI通过 OpenCTI MISP Connector 双向同步OpenCTI ↔ TheHive高置信度指标触发告警/案件创建TheHive ↔ Cortex对案件 observable 自动分析与富化全部组件 ↔ SIEM通过 API 或 Kafka 将 IOC 实时推送到 Splunk/Elastic。从 standards.md 可以看到各组件遵循的协议与数据格式标准组件协议数据格式MISPREST APIMISP JSON、STIX 2.1OpenCTIGraphQL APISTIX 2.1TheHiveREST APITheHive JSONCortexREST APICortex Report JSONElasticsearchREST APIJSON底层标准还包括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/Cases2.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__HOSTNAMErabbitmq、REDIS__HOSTNAMEredis、MINIO__ENDPOINTminio等环境变量接入消息总线、缓存与对象存储正是为 Connector 生态准备的。2.3 富化Cortex 自动分析第三跳是富化层。SKILL.md 的 Step 3 用requests直接调用 Cortex REST API完整覆盖了列出 Analyzer → 提交分析 → 拉取报告三个动作# 列出可用 Analyzer resp requests.get(f{self.url}/api/analyzer, headersself.headers, timeout30) # 提交 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, jsonjob, headersself.headers, timeout30, ) # 获取完成的分析报告 resp requests.get(f{self.url}/api/job/{job_id}/report, headersself.headers, timeout60)按 workflows.md 的标注该层对接的典型 Analyzer 是VirusTotal、Shodan、AbuseIPDB等外部情报服务产出的是经过第三方验证的富化结果供后续置信度评估使用。2.4 情报落地推送 SIEM / 触发 TheHive链路终点是把富化后的高置信度 IOC 推送给消费方SIEMSplunk/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并把告警中的 observableIP、域名、哈希、URL 等交给 Cortex 分析。这部分的能力直接复用了 2.3 节的CortexEnrichment类——analyze_observable()提交分析、get_job_report()取回报告只是调用场景从外部情报富化变为案件线索深挖。3.2 IOC 提取与事件沉淀→ MISP Event Creation分析确认恶意后从案件与 Cortex 报告中提取 IOC在 MISP 中创建事件Event。MISP 的 REST API 支持直接以属性形式写入 IOCapi-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 → SIEMMISP 中的新事件再通过双向同步流入 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 → AlertTIP 由多个分布式组件构成任何一环失效都会导致情报断流或检测延迟因此第三条工作流聚焦平台自身的可观测性[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()TheHiveGET {thehive_url}/api/status200 视为 healthyCortexGET {cortex_url}/api/status200 视为 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 HealthElasticsearch 作为统一存储层其集群健康状态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 运行的不同阶段工作流面向对象核心目标关键产物端到端情报流水线外部情报情报的采集、关联、富化、分发富化后的 IOC、SIEM 检测规则、TheHive 案件事件反馈闭环内部事件实战经验反哺情报资产MISP 事件、OpenCTI 知识更新、新检测规则平台健康监控平台自身保障数据面与协作链路稳定健康状态、Feed/Connector 状态、运维告警三者形成流水线供血、闭环增强、监控护航的整体运转模式。部署时建议按 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 ATTCK, 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考