构建威胁情报平台TIP基于 MISP、OpenCTI、TheHive 与 Cortex 的统一 CTI 系统部署、数据管道与状态报告指南【免费下载链接】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导读本文以开源仓库 Anthropic-Cybersecurity-Skills 中building-threat-intelligence-platform技能为蓝本完整讲解如何设计并部署一套由 MISP、OpenCTI、TheHive、Cortex 等开源组件构成的统一威胁情报平台TIP从 Docker Compose 一键拉起存储与消息中间件到配置 OSINT 源摄取、构建 Cortex 富化管道、打通 STIX/TAXII 互操作再到产出可供安全团队日常巡检的《威胁情报平台状态报告》。读完本文你将掌握 TIP 的分层架构、四大组件的集成关系以及如何用 Python 脚本自动化健康检查、指标收集与报告生成从而把采集—分析—富化—共享的 CTI 生命周期落地为可运维、可度量的生产系统。1. 关联文档定位从状态报告模板反推平台全貌本技能目录下的核心操作文档 assets/template.md 提供了一份《Threat Intelligence Platform Status Report》威胁情报平台状态报告模板。它看似只是一张空表格实则是整个 TIP 平台运维视角的总纲——模板用五个维度定义了平台需要持续监控和汇报的内容报告板块核心观测项对应的平台组件/能力Platform Health各组件健康状态、版本号、访问 URLMISP、OpenCTI、TheHive、Cortex、ElasticsearchFeed Ingestion Status源名称、来源、状态、上次拉取时间、生成事件数各 OSINT/商业/内部 Feed 摄取管道Platform Metrics事件/报告总数、指标总数、活跃 Feed、24h 富化任务数MISP OpenCTI 聚合统计Connector Status连接器类型导入/富化/流、活跃度、上次运行OpenCTI Connector 体系Recommendations平台维护、Feed 配置、集成增强建议运维闭环这份模板不是孤立的纸面文档它与 SKILL.md 中设计 TIP 架构、配置 Feed 摄取管道、建立富化工作流、实现 STIX/TAXII 互操作、构建分析仪表盘的技能目标一一对应。换言之模板里的每一行空位都对应一套需要部署、配置、联调的具体能力。下文将沿着模板的五个板块逐一讲解如何把平台真正搭起来、把数据真正灌进去、把指标真正采出来。2. TIP 总体架构六层组件与四大集成点在动手部署之前先建立平台的整体心智模型。根据 SKILL.md 的 Key ConceptsTIP 架构由六个层次构成Collection Layer采集层从 OSINT、商业情报源、内部日志/告警源摄取 FeedStorage Layer存储层Elasticsearch/OpenSearch 以 STIX 2.1 schema 存储索引化 CTI 数据Analysis Layer分析层OpenCTI 负责知识图谱分析MISP 负责 IOC 关联Enrichment Layer富化层Cortex 分析器对 IOC 做自动化富化VT/Shodan/AbuseIPDBResponse Layer响应层TheHive 承担案件管理与应急响应集成Sharing Layer共享层TAXII Server 负责对外情报共享。层与层之间通过四个关键集成点构成数据通路见 references/workflows.md 中 Workflow 1 的端到端管道示意[外部 Feed] -- [MISP] -- [OpenCTI] -- [Cortex 富化] -- [SIEM/TheHive] | | | | | OSINT/商业 事件关联 知识图谱 VT/Shodan/AIPDB 告警/案件MISP ↔ OpenCTI通过 OpenCTI MISP Connector 实现双向同步OpenCTI ↔ TheHive高置信度指标自动生成告警/案件TheHive ↔ Cortex对案件观测对象observable自动分析与富化全平台 ↔ SIEM通过 API 或 Kafka 将 IOC 实时推送到 Splunk/Elastic。各组件使用的协议与数据格式references/standards.mdMISP 走 REST APIMISP JSON / STIX 2.1OpenCTI 走 GraphQL APISTIX 2.1TheHive 走 REST APITheHive JSONCortex 走 REST APICortex Report JSONElasticsearch 走 REST APIJSON。底层标准则围绕 STIX 2.1数据模型、TAXII 2.1传输协议、MITRE ATTCKTTP 映射、Diamond Model入侵分析框架与 Lockheed Martin Cyber Kill Chain攻击阶段追踪。3. 部署层用 Docker Compose 一键拉起五类基础设施模板的 Platform Health 表格需要汇报 MISP、OpenCTI、TheHive、Cortex、Elasticsearch 五个组件的健康状态与版本号而这些组件的落地从一份 Docker Compose 编排文件开始SKILL.md Step 1。3.1 存储与消息基础设施平台底层依赖四类基础服务它们是 OpenCTI 能够运行的前置条件services: # --- Storage Layer --- elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.12.0 environment: - discovery.typesingle-node - xpack.security.enabledfalse - ES_JAVA_OPTS-Xms2g -Xmx2g ports: - 9200:9200 volumes: - es-data:/usr/share/elasticsearch/data redis: image: redis:7 ports: - 6379:6379 rabbitmq: image: rabbitmq:3-management ports: - 5672:5672 - 15672:15672 minio: image: minio/minio command: server /data --console-address :9001 ports: - 9000:9000 - 9001:9001各组件定位Elasticsearch 承载全部 CTI 索引数据演示环境使用single-node并关闭 xpack 安全以简化部署生产环境应启用认证并配置多节点Redis 作为缓存与会话存储RabbitMQ 是 OpenCTI 连接器的异步消息总线依据 references/standards.mdOpenCTI Connector 基于 RabbitMQ 消息队列做异步处理MinIO 提供 S3 兼容的对象存储供 OpenCTI 存放导入文件与导出产物。3.2 四大业务组件# --- MISP --- misp: image: ghcr.io/misp/misp-docker/misp-core:latest ports: - 8443:443 environment: - MISP_ADMIN_EMAILadmintip.local - MISP_BASEURLhttps://localhost:8443 volumes: - misp-data:/var/www/MISP/app/files # --- OpenCTI --- opencti: image: opencti/platform:6.4.4 environment: - APP__PORT8080 - APP__ADMIN__EMAILadmintip.local - APP__ADMIN__PASSWORDTIPAdminPassword - APP__ADMIN__TOKENtip-opencti-token-uuid - ELASTICSEARCH__URLhttp://elasticsearch:9200 - MINIO__ENDPOINTminio - RABBITMQ__HOSTNAMErabbitmq - REDIS__HOSTNAMEredis ports: - 8080:8080 depends_on: - elasticsearch - redis - rabbitmq - minio # --- TheHive --- thehive: image: strangebee/thehive:5.3 environment: - TH_CORTEX_URLhttp://cortex:9001 ports: - 9000:9000 depends_on: - elasticsearch # --- Cortex --- cortex: image: thehiveproject/cortex:3.1.8 ports: - 9001:9001 depends_on: - elasticsearch几个值得注意的配置点OpenCTI 环境变量采用APP__前缀双层下划线分隔的命名约定如APP__ADMIN__TOKEN对应 admin token其中tip-opencti-token-uuid需替换为真实 UUID后续所有 pycti 客户端调用都要使用该 tokenTheHive 5.x通过TH_CORTEX_URL绑定 Cortex 地址此处 Cortex 容器在 9001 端口注意与 MinIO 控制台的 9001 端口在不同服务网络内互不冲突TheHive 自身管理端口映射到宿主 9000MISP通过MISP_BASEURL声明外部访问地址8443:443将容器内 HTTPS 443 暴露到宿主 8443浏览器访问 https://localhost:8443 即可进入管理界面。3.3 部署后的健康检查平台拉起后模板中 Platform Health 表格的版本号与URL两列即可被真实数据填充。仓库 scripts/process.py 提供了自动化健康检查实现TIPManager.check_healthMISP读取misp_instance_version属性获取版本号OpenCTI调用opencti.health.check()TheHive / Cortex请求/api/status端点HTTP 200 判定为 healthy异常则标记为 unreachable。process.py在命令行层面的用法如下脚本通过 argparse 接收连接参数python process.py --check-health \ --misp-url https://localhost:8443 --misp-key YOUR_MISP_KEY \ --opencti-url http://localhost:8080 --opencti-token tip-opencti-token-uuid \ --thehive-url http://localhost:9000 --thehive-key YOUR_THEHIVE_KEY \ --cortex-url http://localhost:9001 --cortex-key YOUR_CORTEX_KEY \ --output tip_health.json脚本会以 JSON 格式输出各组件健康状态并同时写入tip_report.json或--output指定的文件。值得注意的是process.py对pymisp与pycti做了可选导入处理try/except ImportError即使某些库缺失其余依赖requests的组件TheHive/Cortex 健康检查仍能正常工作——这正是模板中五个组件可以部分健康、部分报错时依旧能生成报告的原因。4. 数据层Feed 摄取管道的配置与编排模板的 Feed Ingestion Status 表格记录每个 Feed 的名称、来源、状态Active/Error、上次拉取时间与生成事件数。要让这些字段有内容必须先把摄取管道跑起来。4.1 在 MISP 中启用并抓取 OSINT FeedSKILL.md 的TIPFeedManager.configure_osint_feeds演示了用pymisp管理 Feed 的方式from pymisp import PyMISP from pycti import OpenCTIApiClient class TIPFeedManager: Manage threat intelligence feed ingestion across platform components. def __init__(self, misp_url, misp_key, opencti_url, opencti_token): self.misp PyMISP(misp_url, misp_key, sslFalse) self.opencti OpenCTIApiClient(opencti_url, opencti_token) def configure_osint_feeds(self): Enable default OSINT feeds in MISP. 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: try: self.misp.enable_feed(feed[id]) self.misp.fetch_feed(feed[id]) print(f[] Enabled feed: {feed[name]}) except Exception as e: print(f[-] Failed: {feed[name]}: {e})对应地process.py的configure_feeds方法给出了一个更自愈的变体它先枚举misp.feeds()再对未启用的 Feed 逐个调用enable_feed批量打开最后返回{enabled_feeds: [...], total_feeds: N}。两种写法都强调同一个事实enable_feed与fetch_feed是 MISP Feed 摄取的两个核心调用前者开关源后者触发拉取。Feed ID 与名称的对应关系来自 MISP 服务器内置的默认 Feed 列表不同版本可能略有差异生产环境应以misp.feeds()返回值为准。4.2 验证 OpenCTI 连接器状态Feed 数据进入平台后还需要连接器把事件从 MISP 搬运到 OpenCTI。TIPFeedManager.configure_opencti_connectors展示了用pycti枚举连接器的模式def configure_opencti_connectors(self): List and verify OpenCTI connector status. connectors self.opencti.connector.list() for conn in connectors: print( f Connector: {conn[name]} - fActive: {conn[active]} - fType: {conn[connector_type]} )sync_misp_to_opencti则进一步演示了按名称筛选连接器的运维技巧在connector.list()结果中过滤名称包含misp的连接器若存在则打印其active状态否则提示需要在 Docker Compose 中补充配置。这正好对应模板 Connector Status 表格中Import/Enrichment/Stream三种连接器类型的活跃度检查——process.py的get_platform_stats也统计了active_connectors与total_connectors两个指标可直接填入报告。5. 富化层Cortex 分析器管道模板 Platform Metrics 中的Enrichment Jobs (24h)字段统计的是 Cortex 富化任务量说明富化管道是平台的核心生产环节。SKILL.md Step 3 的CortexEnrichment类用纯requests实现了与 Cortex REST API 的三种交互import requests class CortexEnrichment: Integrate Cortex analyzers for automated enrichment. def __init__(self, cortex_url, cortex_key): self.url cortex_url self.headers {Authorization: fBearer {cortex_key}} def list_analyzers(self): List available Cortex analyzers. resp requests.get( f{self.url}/api/analyzer, headersself.headers, timeout30, ) if resp.status_code 200: analyzers resp.json() for a in analyzers: print(f {a[name]}: {a.get(description, )[:60]}) return analyzers return [] def analyze_observable(self, observable_type, observable_value, analyzer_id): Submit an observable for analysis. job { data: observable_value, dataType: observable_type, tlp: 2, message: TIP automated enrichment, } resp requests.post( f{self.url}/api/analyzer/{analyzer_id}/run, jsonjob, headersself.headers, timeout30, ) if resp.status_code 200: return resp.json() return None def get_job_report(self, job_id): Get the report for a completed analysis job. resp requests.get( f{self.url}/api/job/{job_id}/report, headersself.headers, timeout60, ) if resp.status_code 200: return resp.json() return None三个方法构成完整的富化闭环list_analyzers拉取可用分析器清单对应报告里配置了哪些分析器analyze_observable提交任务任务体中的dataType表示观测对象类型如ip、domain、hashtlp: 2对应 TLP:AMBER关于 TLP 分级与编码见下文第 6 节get_job_report轮询任务报告。根据 references/standards.mdCortex 分析器以 Docker 方式运行并遵循标准化 I/O因此可以轻松挂载 VirusTotal、Shodan、AbuseIPDB 等外部服务作为分析器后端。6. 共享层STIX 2.1 数据模型、TLP 标记与 TAXII 导出模板的 Validation Criteria 要求STIX/TAXII 导出对情报共享可用这需要全平台统一使用 STIX 2.1 数据模型。仓库 scripts/agent.py 提供了完整的 STIX 2.1 对象构造参考可直接执行观察输出python skills/building-threat-intelligence-platform/scripts/agent.py6.1 指标类型识别与 STIX Patternclassify_indicator函数通过正则从原始值推断指标类型IPv4[0-9]{1,3}(\.[0-9]{1,3}){3}、SHA-25664 位十六进制、MD532 位十六进制、域名、URL、邮箱等。随后create_stix_indicator依据STIX_INDICATOR_TYPES映射表生成标准 STIX patternSTIX 指标类型Pattern 模板ipv4-addr[ipv4-addr:value {}]domain-name[domain-name:value {}]url[url:value {}]file-sha256[file:hashes.SHA-256 {}]file-md5[file:hashes.MD5 {}]email-addr[email-addr:value {}]生成的对象结构与 references/api-reference.md 中的 STIX 2.1 Indicator 示例一致包含type: indicator、spec_version: 2.1、id: indicator--uuid5基于值的 UUID5保证同一指标幂等、pattern、pattern_type: stix、confidence、labels与object_marking_refs。6.2 TLP 标记与共享范围控制agent.py内置了 TLP 分级定义TLP_DEFINITIONS与 TLP→STIX Marking Definition ID 的映射tlp_to_marking_refTLP 级别共享范围STIX Marking Definition ID代码TLP:CLEAR无限制marking-definition--613f2e26-407d-48c7-9eca-b8e91df99dc90TLP:GREEN社区marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da1TLP:AMBER组织内部marking-definition--f88d31f6-486f-44da-b317-01333bde0b822TLP:AMBERSTRICT仅需知悉marking-definition--826578e1-40a3-4b46-a8d8-b9931fdd750e3TLP:RED仅指定接收人marking-definition--5e57c739-391a-4eb3-b6be-7d15ca92d5ed4这些 ID 是 STIX 2.1 标准库的官方标记定义直接决定了情报对象在 TAXII 共享与平台内部分发时的可见范围。agent.py中calculate_indicator_score还实现了置信度评分模型来源数每个 15上限 40、时效性每天 -0.5上限 30、确认观测次数每次 10上限 30、误报数每次 -15上限 30最终得分钳制在 0–100 区间——这个分数与 TLP 一起构成 IOC 的可信度 分发范围双维度属性。6.3 TAXII 2.1 端到端操作references/api-reference.md 给出了 TAXII 2.1 的标准交互流程Discovery → Collections → Objects# Discovery curl https://taxii.server.com/taxii2/ # Collections curl https://taxii.server.com/taxii2/collections/ # Get objects from collection curl https://taxii.server.com/taxii2/collections/{id}/objects?typeindicator # Add objects curl -X POST https://taxii.server.com/taxii2/collections/{id}/objects \ -H Content-Type: application/stixjson;version2.1 \ -d bundle.jsonagent.py的build_stix_bundle恰好生成bundle--uuid4类型的 STIX Bundle可直接作为上述 POST 请求的bundle.json载荷generate_tip_report则按指标类型统计数量并计算平均置信度为报告指标板块提供素材。而 MISP 侧的 REST API 添加属性操作同样简洁api-reference.mdcurl -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}OpenCTI 则通过 GraphQL mutation 创建指标indicatorAdd可附加x_opencti_score评分与 MISP 的 REST 风格形成对比但底层数据模型统一为 STIX 2.1。7. 指标层跨组件统计与状态报告生成现在回到关联文档 assets/template.md 本身。报告的核心是 Platform Metrics 表格它要求跨 MISP 与 OpenCTI 聚合四个指标。SKILL.md Step 4 的TIPMetrics类给出了采集逻辑class TIPMetrics: Collect platform metrics for analyst dashboards. def __init__(self, misp, opencti): self.misp misp self.opencti opencti def get_platform_stats(self): Collect statistics across all platform components. stats {} # MISP stats misp_stats self.misp.get_server_statistics() stats[misp] { total_events: misp_stats.get(event_count, 0), total_attributes: misp_stats.get(attribute_count, 0), active_feeds: len([ f for f in self.misp.feeds() if f.get(Feed, {}).get(enabled) ]), } # OpenCTI stats via GraphQL stats[opencti] { total_indicators: self.opencti.indicator.list( first0, withPaginationTrue ).get(pagination, {}).get(globalCount, 0), total_reports: self.opencti.report.list( first0, withPaginationTrue ).get(pagination, {}).get(globalCount, 0), } return stats采集要点MISP 侧get_server_statistics()返回event_count事件总数与attribute_count属性总数活跃 Feed 数通过遍历feeds()并判断Feed.enabled计算——这与模板中Active Feeds指标完全对应OpenCTI 侧pycti 的分页列表接口以first0, withPaginationTrue调用从返回的pagination.globalCount读取指标与报告总量process.py的get_platform_stats在该基础上又补充了时间戳与连接器统计active_connectors/total_connectors并支持--platform-stats命令行直接产出 JSONpython process.py --platform-stats \ --misp-url https://localhost:8443 --misp-key YOUR_MISP_KEY \ --opencti-url http://localhost:8080 --opencti-token tip-opencti-token-uuid \ --output tip_stats.json此外references/workflows.md 提供了两条重要的流程参考Workflow 2Incident-to-Intelligence 反馈闭环说明 SOC 告警如何经过 TheHive 案件 → Cortex 分析 → IOC 提取 → MISP 事件 → OpenCTI 知识更新 → 检测规则回灌 SIEM 的完整回路Workflow 3平台健康监控则建议用 Prometheus/Grafana 对组件健康、ES 集群健康、Feed 状态、连接器状态做持续告警。这两条流程直接支撑模板中 Recommendations 板块的撰写维护建议应当同时覆盖组件健康巡检与情报反馈闭环两个维度。8. 实战将报告模板五个板块填满综合以上所有能力一份可交付的《威胁情报平台状态报告》可以这样生成与填写Platform Health运行process.py --check-health将输出的 JSON 中各组件的status、version与各自访问 URLMISP 8443、OpenCTI 8080、TheHive 9000、Cortex 9001、Elasticsearch 9200填入表格Feed Ingestion Status执行configure_feeds或 SKILL.md 中的TIPFeedManager对每个启用且成功拉取的源记录名称、来源、Active 状态、最近fetch_feed时间与event_count增量Platform Metrics执行--platform-stats汇总 MISP 的事件/属性/活跃 Feed 数与 OpenCTI 的指标/报告总量富化任务数可从 Cortex 任务接口get_job_report覆盖的任务清单或 Cortex 管理界面按 24h 窗口统计Connector Status调用opencti.connector.list()按名称筛选 MISP 同步连接器与其他 Import/Enrichment/Stream 类型连接器标记 Active 与 Last RunRecommendations参照 references/workflows.md 的三条工作流从平台维护组件版本升级、ES 索引生命周期、Feed 配置补充商业源、调整拉取频率、监控失败源、集成增强接入 SIEM 的 Kafka 推送、启用 TAXII 对外共享、增加 Cortex 分析器三个层面给出可执行建议。9. 验收标准与能力边界技能定义 SKILL.md 的 Validation Criteria 提供了明确的验收清单也是报告模板各板块是否合格的判定依据所有平台组件MISP、OpenCTI、TheHive、Cortex均已部署且可访问MISP–OpenCTI 双向同步正常运行至少 3 个 OSINT Feed 正在摄取数据Cortex 分析器已配置并能返回富化结果平台指标仪表盘展示实时统计STIX/TAXII 导出对情报共享可用。需要说明的能力边界本技能演示的是面向评估、演练与学习环境的单节点部署如 Elasticsearchsingle-node、xpack.security.enabledfalse、PyMISP(..., sslFalse)生产环境必须替换为多节点集群、启用 TLS 与认证、使用密钥管理系统保存 API Key/Token并根据实际容量调整ES_JAVA_OPTS等资源参数。报告中的 Feed ID 列表、镜像版本如opencti/platform:6.4.4、thehive:5.3以当前仓库文档为准长期运维时应跟进上游版本迭代。10. 延伸阅读技能完整定义与部署步骤SKILL.md状态报告模板本文主体assets/template.md平台运维 CLI 工具scripts/process.pySTIX 构造与置信度评分实现scripts/agent.py平台架构标准与集成标准references/standards.mdSTIX/TAXII/GraphQL/MISP 接口参考references/api-reference.md端到端管道、反馈闭环与监控工作流references/workflows.md【免费下载链接】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），仅供参考 构建威胁情报平台（TIP）：基于 MISP、OpenCTI、TheHive 与 Cortex 的统一 CTI 系统部署、数据管道与状态报告指南
构建威胁情报平台TIP基于 MISP、OpenCTI、TheHive 与 Cortex 的统一 CTI 系统部署、数据管道与状态报告指南【免费下载链接】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导读本文以开源仓库 Anthropic-Cybersecurity-Skills 中building-threat-intelligence-platform技能为蓝本完整讲解如何设计并部署一套由 MISP、OpenCTI、TheHive、Cortex 等开源组件构成的统一威胁情报平台TIP从 Docker Compose 一键拉起存储与消息中间件到配置 OSINT 源摄取、构建 Cortex 富化管道、打通 STIX/TAXII 互操作再到产出可供安全团队日常巡检的《威胁情报平台状态报告》。读完本文你将掌握 TIP 的分层架构、四大组件的集成关系以及如何用 Python 脚本自动化健康检查、指标收集与报告生成从而把采集—分析—富化—共享的 CTI 生命周期落地为可运维、可度量的生产系统。1. 关联文档定位从状态报告模板反推平台全貌本技能目录下的核心操作文档 assets/template.md 提供了一份《Threat Intelligence Platform Status Report》威胁情报平台状态报告模板。它看似只是一张空表格实则是整个 TIP 平台运维视角的总纲——模板用五个维度定义了平台需要持续监控和汇报的内容报告板块核心观测项对应的平台组件/能力Platform Health各组件健康状态、版本号、访问 URLMISP、OpenCTI、TheHive、Cortex、ElasticsearchFeed Ingestion Status源名称、来源、状态、上次拉取时间、生成事件数各 OSINT/商业/内部 Feed 摄取管道Platform Metrics事件/报告总数、指标总数、活跃 Feed、24h 富化任务数MISP OpenCTI 聚合统计Connector Status连接器类型导入/富化/流、活跃度、上次运行OpenCTI Connector 体系Recommendations平台维护、Feed 配置、集成增强建议运维闭环这份模板不是孤立的纸面文档它与 SKILL.md 中设计 TIP 架构、配置 Feed 摄取管道、建立富化工作流、实现 STIX/TAXII 互操作、构建分析仪表盘的技能目标一一对应。换言之模板里的每一行空位都对应一套需要部署、配置、联调的具体能力。下文将沿着模板的五个板块逐一讲解如何把平台真正搭起来、把数据真正灌进去、把指标真正采出来。2. TIP 总体架构六层组件与四大集成点在动手部署之前先建立平台的整体心智模型。根据 SKILL.md 的 Key ConceptsTIP 架构由六个层次构成Collection Layer采集层从 OSINT、商业情报源、内部日志/告警源摄取 FeedStorage Layer存储层Elasticsearch/OpenSearch 以 STIX 2.1 schema 存储索引化 CTI 数据Analysis Layer分析层OpenCTI 负责知识图谱分析MISP 负责 IOC 关联Enrichment Layer富化层Cortex 分析器对 IOC 做自动化富化VT/Shodan/AbuseIPDBResponse Layer响应层TheHive 承担案件管理与应急响应集成Sharing Layer共享层TAXII Server 负责对外情报共享。层与层之间通过四个关键集成点构成数据通路见 references/workflows.md 中 Workflow 1 的端到端管道示意[外部 Feed] -- [MISP] -- [OpenCTI] -- [Cortex 富化] -- [SIEM/TheHive] | | | | | OSINT/商业 事件关联 知识图谱 VT/Shodan/AIPDB 告警/案件MISP ↔ OpenCTI通过 OpenCTI MISP Connector 实现双向同步OpenCTI ↔ TheHive高置信度指标自动生成告警/案件TheHive ↔ Cortex对案件观测对象observable自动分析与富化全平台 ↔ SIEM通过 API 或 Kafka 将 IOC 实时推送到 Splunk/Elastic。各组件使用的协议与数据格式references/standards.mdMISP 走 REST APIMISP JSON / STIX 2.1OpenCTI 走 GraphQL APISTIX 2.1TheHive 走 REST APITheHive JSONCortex 走 REST APICortex Report JSONElasticsearch 走 REST APIJSON。底层标准则围绕 STIX 2.1数据模型、TAXII 2.1传输协议、MITRE ATTCKTTP 映射、Diamond Model入侵分析框架与 Lockheed Martin Cyber Kill Chain攻击阶段追踪。3. 部署层用 Docker Compose 一键拉起五类基础设施模板的 Platform Health 表格需要汇报 MISP、OpenCTI、TheHive、Cortex、Elasticsearch 五个组件的健康状态与版本号而这些组件的落地从一份 Docker Compose 编排文件开始SKILL.md Step 1。3.1 存储与消息基础设施平台底层依赖四类基础服务它们是 OpenCTI 能够运行的前置条件services: # --- Storage Layer --- elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.12.0 environment: - discovery.typesingle-node - xpack.security.enabledfalse - ES_JAVA_OPTS-Xms2g -Xmx2g ports: - 9200:9200 volumes: - es-data:/usr/share/elasticsearch/data redis: image: redis:7 ports: - 6379:6379 rabbitmq: image: rabbitmq:3-management ports: - 5672:5672 - 15672:15672 minio: image: minio/minio command: server /data --console-address :9001 ports: - 9000:9000 - 9001:9001各组件定位Elasticsearch 承载全部 CTI 索引数据演示环境使用single-node并关闭 xpack 安全以简化部署生产环境应启用认证并配置多节点Redis 作为缓存与会话存储RabbitMQ 是 OpenCTI 连接器的异步消息总线依据 references/standards.mdOpenCTI Connector 基于 RabbitMQ 消息队列做异步处理MinIO 提供 S3 兼容的对象存储供 OpenCTI 存放导入文件与导出产物。3.2 四大业务组件# --- MISP --- misp: image: ghcr.io/misp/misp-docker/misp-core:latest ports: - 8443:443 environment: - MISP_ADMIN_EMAILadmintip.local - MISP_BASEURLhttps://localhost:8443 volumes: - misp-data:/var/www/MISP/app/files # --- OpenCTI --- opencti: image: opencti/platform:6.4.4 environment: - APP__PORT8080 - APP__ADMIN__EMAILadmintip.local - APP__ADMIN__PASSWORDTIPAdminPassword - APP__ADMIN__TOKENtip-opencti-token-uuid - ELASTICSEARCH__URLhttp://elasticsearch:9200 - MINIO__ENDPOINTminio - RABBITMQ__HOSTNAMErabbitmq - REDIS__HOSTNAMEredis ports: - 8080:8080 depends_on: - elasticsearch - redis - rabbitmq - minio # --- TheHive --- thehive: image: strangebee/thehive:5.3 environment: - TH_CORTEX_URLhttp://cortex:9001 ports: - 9000:9000 depends_on: - elasticsearch # --- Cortex --- cortex: image: thehiveproject/cortex:3.1.8 ports: - 9001:9001 depends_on: - elasticsearch几个值得注意的配置点OpenCTI 环境变量采用APP__前缀双层下划线分隔的命名约定如APP__ADMIN__TOKEN对应 admin token其中tip-opencti-token-uuid需替换为真实 UUID后续所有 pycti 客户端调用都要使用该 tokenTheHive 5.x通过TH_CORTEX_URL绑定 Cortex 地址此处 Cortex 容器在 9001 端口注意与 MinIO 控制台的 9001 端口在不同服务网络内互不冲突TheHive 自身管理端口映射到宿主 9000MISP通过MISP_BASEURL声明外部访问地址8443:443将容器内 HTTPS 443 暴露到宿主 8443浏览器访问 https://localhost:8443 即可进入管理界面。3.3 部署后的健康检查平台拉起后模板中 Platform Health 表格的版本号与URL两列即可被真实数据填充。仓库 scripts/process.py 提供了自动化健康检查实现TIPManager.check_healthMISP读取misp_instance_version属性获取版本号OpenCTI调用opencti.health.check()TheHive / Cortex请求/api/status端点HTTP 200 判定为 healthy异常则标记为 unreachable。process.py在命令行层面的用法如下脚本通过 argparse 接收连接参数python process.py --check-health \ --misp-url https://localhost:8443 --misp-key YOUR_MISP_KEY \ --opencti-url http://localhost:8080 --opencti-token tip-opencti-token-uuid \ --thehive-url http://localhost:9000 --thehive-key YOUR_THEHIVE_KEY \ --cortex-url http://localhost:9001 --cortex-key YOUR_CORTEX_KEY \ --output tip_health.json脚本会以 JSON 格式输出各组件健康状态并同时写入tip_report.json或--output指定的文件。值得注意的是process.py对pymisp与pycti做了可选导入处理try/except ImportError即使某些库缺失其余依赖requests的组件TheHive/Cortex 健康检查仍能正常工作——这正是模板中五个组件可以部分健康、部分报错时依旧能生成报告的原因。4. 数据层Feed 摄取管道的配置与编排模板的 Feed Ingestion Status 表格记录每个 Feed 的名称、来源、状态Active/Error、上次拉取时间与生成事件数。要让这些字段有内容必须先把摄取管道跑起来。4.1 在 MISP 中启用并抓取 OSINT FeedSKILL.md 的TIPFeedManager.configure_osint_feeds演示了用pymisp管理 Feed 的方式from pymisp import PyMISP from pycti import OpenCTIApiClient class TIPFeedManager: Manage threat intelligence feed ingestion across platform components. def __init__(self, misp_url, misp_key, opencti_url, opencti_token): self.misp PyMISP(misp_url, misp_key, sslFalse) self.opencti OpenCTIApiClient(opencti_url, opencti_token) def configure_osint_feeds(self): Enable default OSINT feeds in MISP. 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: try: self.misp.enable_feed(feed[id]) self.misp.fetch_feed(feed[id]) print(f[] Enabled feed: {feed[name]}) except Exception as e: print(f[-] Failed: {feed[name]}: {e})对应地process.py的configure_feeds方法给出了一个更自愈的变体它先枚举misp.feeds()再对未启用的 Feed 逐个调用enable_feed批量打开最后返回{enabled_feeds: [...], total_feeds: N}。两种写法都强调同一个事实enable_feed与fetch_feed是 MISP Feed 摄取的两个核心调用前者开关源后者触发拉取。Feed ID 与名称的对应关系来自 MISP 服务器内置的默认 Feed 列表不同版本可能略有差异生产环境应以misp.feeds()返回值为准。4.2 验证 OpenCTI 连接器状态Feed 数据进入平台后还需要连接器把事件从 MISP 搬运到 OpenCTI。TIPFeedManager.configure_opencti_connectors展示了用pycti枚举连接器的模式def configure_opencti_connectors(self): List and verify OpenCTI connector status. connectors self.opencti.connector.list() for conn in connectors: print( f Connector: {conn[name]} - fActive: {conn[active]} - fType: {conn[connector_type]} )sync_misp_to_opencti则进一步演示了按名称筛选连接器的运维技巧在connector.list()结果中过滤名称包含misp的连接器若存在则打印其active状态否则提示需要在 Docker Compose 中补充配置。这正好对应模板 Connector Status 表格中Import/Enrichment/Stream三种连接器类型的活跃度检查——process.py的get_platform_stats也统计了active_connectors与total_connectors两个指标可直接填入报告。5. 富化层Cortex 分析器管道模板 Platform Metrics 中的Enrichment Jobs (24h)字段统计的是 Cortex 富化任务量说明富化管道是平台的核心生产环节。SKILL.md Step 3 的CortexEnrichment类用纯requests实现了与 Cortex REST API 的三种交互import requests class CortexEnrichment: Integrate Cortex analyzers for automated enrichment. def __init__(self, cortex_url, cortex_key): self.url cortex_url self.headers {Authorization: fBearer {cortex_key}} def list_analyzers(self): List available Cortex analyzers. resp requests.get( f{self.url}/api/analyzer, headersself.headers, timeout30, ) if resp.status_code 200: analyzers resp.json() for a in analyzers: print(f {a[name]}: {a.get(description, )[:60]}) return analyzers return [] def analyze_observable(self, observable_type, observable_value, analyzer_id): Submit an observable for analysis. job { data: observable_value, dataType: observable_type, tlp: 2, message: TIP automated enrichment, } resp requests.post( f{self.url}/api/analyzer/{analyzer_id}/run, jsonjob, headersself.headers, timeout30, ) if resp.status_code 200: return resp.json() return None def get_job_report(self, job_id): Get the report for a completed analysis job. resp requests.get( f{self.url}/api/job/{job_id}/report, headersself.headers, timeout60, ) if resp.status_code 200: return resp.json() return None三个方法构成完整的富化闭环list_analyzers拉取可用分析器清单对应报告里配置了哪些分析器analyze_observable提交任务任务体中的dataType表示观测对象类型如ip、domain、hashtlp: 2对应 TLP:AMBER关于 TLP 分级与编码见下文第 6 节get_job_report轮询任务报告。根据 references/standards.mdCortex 分析器以 Docker 方式运行并遵循标准化 I/O因此可以轻松挂载 VirusTotal、Shodan、AbuseIPDB 等外部服务作为分析器后端。6. 共享层STIX 2.1 数据模型、TLP 标记与 TAXII 导出模板的 Validation Criteria 要求STIX/TAXII 导出对情报共享可用这需要全平台统一使用 STIX 2.1 数据模型。仓库 scripts/agent.py 提供了完整的 STIX 2.1 对象构造参考可直接执行观察输出python skills/building-threat-intelligence-platform/scripts/agent.py6.1 指标类型识别与 STIX Patternclassify_indicator函数通过正则从原始值推断指标类型IPv4[0-9]{1,3}(\.[0-9]{1,3}){3}、SHA-25664 位十六进制、MD532 位十六进制、域名、URL、邮箱等。随后create_stix_indicator依据STIX_INDICATOR_TYPES映射表生成标准 STIX patternSTIX 指标类型Pattern 模板ipv4-addr[ipv4-addr:value {}]domain-name[domain-name:value {}]url[url:value {}]file-sha256[file:hashes.SHA-256 {}]file-md5[file:hashes.MD5 {}]email-addr[email-addr:value {}]生成的对象结构与 references/api-reference.md 中的 STIX 2.1 Indicator 示例一致包含type: indicator、spec_version: 2.1、id: indicator--uuid5基于值的 UUID5保证同一指标幂等、pattern、pattern_type: stix、confidence、labels与object_marking_refs。6.2 TLP 标记与共享范围控制agent.py内置了 TLP 分级定义TLP_DEFINITIONS与 TLP→STIX Marking Definition ID 的映射tlp_to_marking_refTLP 级别共享范围STIX Marking Definition ID代码TLP:CLEAR无限制marking-definition--613f2e26-407d-48c7-9eca-b8e91df99dc90TLP:GREEN社区marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da1TLP:AMBER组织内部marking-definition--f88d31f6-486f-44da-b317-01333bde0b822TLP:AMBERSTRICT仅需知悉marking-definition--826578e1-40a3-4b46-a8d8-b9931fdd750e3TLP:RED仅指定接收人marking-definition--5e57c739-391a-4eb3-b6be-7d15ca92d5ed4这些 ID 是 STIX 2.1 标准库的官方标记定义直接决定了情报对象在 TAXII 共享与平台内部分发时的可见范围。agent.py中calculate_indicator_score还实现了置信度评分模型来源数每个 15上限 40、时效性每天 -0.5上限 30、确认观测次数每次 10上限 30、误报数每次 -15上限 30最终得分钳制在 0–100 区间——这个分数与 TLP 一起构成 IOC 的可信度 分发范围双维度属性。6.3 TAXII 2.1 端到端操作references/api-reference.md 给出了 TAXII 2.1 的标准交互流程Discovery → Collections → Objects# Discovery curl https://taxii.server.com/taxii2/ # Collections curl https://taxii.server.com/taxii2/collections/ # Get objects from collection curl https://taxii.server.com/taxii2/collections/{id}/objects?typeindicator # Add objects curl -X POST https://taxii.server.com/taxii2/collections/{id}/objects \ -H Content-Type: application/stixjson;version2.1 \ -d bundle.jsonagent.py的build_stix_bundle恰好生成bundle--uuid4类型的 STIX Bundle可直接作为上述 POST 请求的bundle.json载荷generate_tip_report则按指标类型统计数量并计算平均置信度为报告指标板块提供素材。而 MISP 侧的 REST API 添加属性操作同样简洁api-reference.mdcurl -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}OpenCTI 则通过 GraphQL mutation 创建指标indicatorAdd可附加x_opencti_score评分与 MISP 的 REST 风格形成对比但底层数据模型统一为 STIX 2.1。7. 指标层跨组件统计与状态报告生成现在回到关联文档 assets/template.md 本身。报告的核心是 Platform Metrics 表格它要求跨 MISP 与 OpenCTI 聚合四个指标。SKILL.md Step 4 的TIPMetrics类给出了采集逻辑class TIPMetrics: Collect platform metrics for analyst dashboards. def __init__(self, misp, opencti): self.misp misp self.opencti opencti def get_platform_stats(self): Collect statistics across all platform components. stats {} # MISP stats misp_stats self.misp.get_server_statistics() stats[misp] { total_events: misp_stats.get(event_count, 0), total_attributes: misp_stats.get(attribute_count, 0), active_feeds: len([ f for f in self.misp.feeds() if f.get(Feed, {}).get(enabled) ]), } # OpenCTI stats via GraphQL stats[opencti] { total_indicators: self.opencti.indicator.list( first0, withPaginationTrue ).get(pagination, {}).get(globalCount, 0), total_reports: self.opencti.report.list( first0, withPaginationTrue ).get(pagination, {}).get(globalCount, 0), } return stats采集要点MISP 侧get_server_statistics()返回event_count事件总数与attribute_count属性总数活跃 Feed 数通过遍历feeds()并判断Feed.enabled计算——这与模板中Active Feeds指标完全对应OpenCTI 侧pycti 的分页列表接口以first0, withPaginationTrue调用从返回的pagination.globalCount读取指标与报告总量process.py的get_platform_stats在该基础上又补充了时间戳与连接器统计active_connectors/total_connectors并支持--platform-stats命令行直接产出 JSONpython process.py --platform-stats \ --misp-url https://localhost:8443 --misp-key YOUR_MISP_KEY \ --opencti-url http://localhost:8080 --opencti-token tip-opencti-token-uuid \ --output tip_stats.json此外references/workflows.md 提供了两条重要的流程参考Workflow 2Incident-to-Intelligence 反馈闭环说明 SOC 告警如何经过 TheHive 案件 → Cortex 分析 → IOC 提取 → MISP 事件 → OpenCTI 知识更新 → 检测规则回灌 SIEM 的完整回路Workflow 3平台健康监控则建议用 Prometheus/Grafana 对组件健康、ES 集群健康、Feed 状态、连接器状态做持续告警。这两条流程直接支撑模板中 Recommendations 板块的撰写维护建议应当同时覆盖组件健康巡检与情报反馈闭环两个维度。8. 实战将报告模板五个板块填满综合以上所有能力一份可交付的《威胁情报平台状态报告》可以这样生成与填写Platform Health运行process.py --check-health将输出的 JSON 中各组件的status、version与各自访问 URLMISP 8443、OpenCTI 8080、TheHive 9000、Cortex 9001、Elasticsearch 9200填入表格Feed Ingestion Status执行configure_feeds或 SKILL.md 中的TIPFeedManager对每个启用且成功拉取的源记录名称、来源、Active 状态、最近fetch_feed时间与event_count增量Platform Metrics执行--platform-stats汇总 MISP 的事件/属性/活跃 Feed 数与 OpenCTI 的指标/报告总量富化任务数可从 Cortex 任务接口get_job_report覆盖的任务清单或 Cortex 管理界面按 24h 窗口统计Connector Status调用opencti.connector.list()按名称筛选 MISP 同步连接器与其他 Import/Enrichment/Stream 类型连接器标记 Active 与 Last RunRecommendations参照 references/workflows.md 的三条工作流从平台维护组件版本升级、ES 索引生命周期、Feed 配置补充商业源、调整拉取频率、监控失败源、集成增强接入 SIEM 的 Kafka 推送、启用 TAXII 对外共享、增加 Cortex 分析器三个层面给出可执行建议。9. 验收标准与能力边界技能定义 SKILL.md 的 Validation Criteria 提供了明确的验收清单也是报告模板各板块是否合格的判定依据所有平台组件MISP、OpenCTI、TheHive、Cortex均已部署且可访问MISP–OpenCTI 双向同步正常运行至少 3 个 OSINT Feed 正在摄取数据Cortex 分析器已配置并能返回富化结果平台指标仪表盘展示实时统计STIX/TAXII 导出对情报共享可用。需要说明的能力边界本技能演示的是面向评估、演练与学习环境的单节点部署如 Elasticsearchsingle-node、xpack.security.enabledfalse、PyMISP(..., sslFalse)生产环境必须替换为多节点集群、启用 TLS 与认证、使用密钥管理系统保存 API Key/Token并根据实际容量调整ES_JAVA_OPTS等资源参数。报告中的 Feed ID 列表、镜像版本如opencti/platform:6.4.4、thehive:5.3以当前仓库文档为准长期运维时应跟进上游版本迭代。10. 延伸阅读技能完整定义与部署步骤SKILL.md状态报告模板本文主体assets/template.md平台运维 CLI 工具scripts/process.pySTIX 构造与置信度评分实现scripts/agent.py平台架构标准与集成标准references/standards.mdSTIX/TAXII/GraphQL/MISP 接口参考references/api-reference.md端到端管道、反馈闭环与监控工作流references/workflows.md【免费下载链接】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），仅供参考