共享协议与平台：TAXII 2.1 与 MISP

01 · TAXII 2.1设计目标与演进

1.1 从TAXII 1.x到2.x

TAXII（Trusted Automated eXchange of Intelligence Information）最初与STIX一同由美国国土安全部于2012年发起。TAXII 1.x版本定义了Inbox（收件）、Poll（轮询）、Discovery（发现）、Collection Management（集合管理）四类服务，消息采用XML编码，交互模式复杂，不同实现之间的互操作性始终不理想。

TAXII 2.x按"简单、安全、绑定STIX 2"的原则重新设计：全面转向资源导向的REST风格API，消息体使用JSON并与STIX 2.x对象绑定，传输层强制HTTPS。2021年6月，TAXII 2.1与STIX 2.1一并成为OASIS标准，构成当前国际机器交换的事实标准。

1.2 设计目标

• 互操作性：任何符合规范的实现可自由对接，避免私有接口锁定。
• 分层访问：以Collection（集合）为授权粒度，读写权限独立控制。
• 增量同步：客户端按时间增量拉取，支撑大规模IOC的持续分发。
• 双向流动：同一协议同时支持生产者发布（Push）与消费者订阅（Poll）。

02 · 概念模型与三类服务

TAXII 2.1的核心概念层级为：TAXII Server → API Roots（API根） → Collections / Channels。API Root是按权限或业务划分的逻辑分组（如按成员组织、按行业划分），其下挂若干集合；集合内承载具体的STIX 2.1对象。规范定义三类核心服务：

03 · 集合与对象资源

3.1 Collection资源

Collection（集合）是TAXII 2.1中授权与同步的基本单元，其资源表示包含：标识id、标题title、描述description、别名alias，以及权限与格式字段can_read、can_write、media_types。对象资源端点支持：

• GET objects：读取集合内STIX 2.1对象，支持added_after参数实现按时间增量拉取——这是断点续传与增量同步的基础。
• POST objects：生产者向集合发布一个STIX Bundle；服务端返回HTTP 202及Status资源标识，发布者随后可查询该状态资源确认每个对象的写入结果（成功数、失败数、失败原因），实现异步可靠投递。
• GET manifest：返回集合内对象的元数据清单（对象id、版本时间、加入时间），供订阅方做本地去重与同步状态比对，避免重复传输。

3.2 与STIX 2.1的绑定

TAXII 2.1传输的载荷为TAXII信封（Envelope）：顶层type为envelope，objects数组承载Indicator、Observed Data、Identity、Marking Definition等STIX 2.1对象。业界常统称"以STIX Bundle传输"，但严格而言TAXII 2.1已用Envelope取代早期草案中的STIX Bundle载荷形式，二者objects内容完全一致。

内容协商通过HTTP Accept/Content-Type头中的版本参数完成，例如：application/taxii+json;version=2.1（TAXII信封）与application/stix+json;version=2.1（STIX对象）。

04 · 传输安全与认证

• 传输层：规范强制使用HTTPS，明文HTTP不被允许；建议启用TLS 1.2及以上并禁用弱密码套件。
• 认证机制：TAXII 2.1规范以RFC 7235框架定义认证，建议实现HTTP Basic认证（RFC 7617）作为基线方案，具体认证强度由部署约定；在成员制共享社区场景中，业界通行做法是在HTTPS之上叠加双向TLS（mTLS）客户端证书——成员准入时由共享中心签发组织证书，证书吊销即成员退出；也可叠加Bearer令牌用于应用层调用。成员证书体系与PKI衔接，正是第3页信任模型的技术锚点。
• 授权粒度：按API根与集合授予读/写权限（can_read / can_write），遵循最小权限原则；高敏集合（如TLP:RED）仅对指定成员开放读权限。
• 审计留痕：服务端记录每次读写的成员身份、时间、对象范围，支撑合规审计与争议追溯（第3页§06、第4页§05衔接）。

05 · Push与Poll模式对比

06 · MISP数据模型

MISP（Malware Information Sharing Platform，恶意软件信息共享平台）由卢森堡计算机事件响应中心（CIRCL）主导的开源社区维护，是社区级情报共享的事实标准平台。其核心数据模型分三层：

6.1 标注、富化与命中回传

• Taxonomy与Tags：社区维护的分类体系（含TLP taxonomy），为事件与属性打标签，驱动分发策略与过滤订阅。
• Galaxy：知识库星簇，如MITRE ATT&CK技术/战术、攻击组织画像，实现情报与知识图谱的关联（衔接子课题03）。
• Warninglist：知名合法基础设施名单（如公有云IP段、CDN域名），压制误报——与子课题01的去重置信度机制互补。
• Sighting：消费方回传"某属性在自家环境被命中"的记录，含命中次数与时间，构成生产者质量评估的第一手数据（第4页§04的指标来源）。
• Modules：可插拔的富化（查被动DNS、WHOIS）、导入（批量IOC）、导出（STIX、CSV、IDS规则）扩展。

07 · MISP同步与部署形态

7.1 分发层级与Sharing Group

MISP原生四级分发范围：组织内（Your organisation only）、本社区（This community only）、连接社区（Connected communities）、全体社区（All communities）；另有Sharing Group（共享组）支持按成员名单精确圈定接收方——与TLP标记组合即可实现"标记+机制"双保险（第3页§02衔接）。

7.2 服务器间同步

• Push / Pull双向同步：社区节点之间互相同步事件，支持全量与增量；同步通道使用客户端证书或API密钥认证。
• REST API与PyMISP：官方Python库PyMISP封装全部API，是自动化管道（第4页）的主要编程接口。
• STIX互转：内置STIX 1.x/2.x导入导出，并可经社区扩展对外提供TAXII服务端点，实现"MISP对内协同 + TAXII对外标准化"的混合架构。
• Feeds：支持订阅外部开源情报源（如abuse.ch系列），作为社区数据水位补充（复用子课题01的源评估结论）。

7.3 部署形态

参考部署路径：单节点起步（Docker/Ansible部署，MariaDB+Redis）→ 社区枢纽节点（前置负载均衡、只读副本分流查询）→ 联邦化（多节点按TLP层级互联）。暗网来源数据的采集与分析环境必须与本组织生产网络隔离（子课题01合规要求），MISP节点本身亦建议置于独立安全域。

08 · 平台选型对比

注：上表为通用能力的定性对比，仅用于架构选型参考，不构成对任何具体产品或厂商的推荐；OpenCTI由法国Filigran公司主导开发。

09 · 工程示例

9.1 发现服务端点

GET /taxii2/ HTTP/1.1
Host: ti.example.com
Accept: application/taxii+json;version=2.1

# 响应（discovery资源，节选）
{
  "title": "DiMiao Threat Intelligence Server",
  "default": "/api1/",
  "api_roots": ["/api1/", "/api2/"]
}

9.2 Collection资源（示例数据）

{
  "id": "ba9f3a3a-1c2d-4e5f-8a9b-0c1d2e3f4a5b",
  "title": "迪妙安全 钓鱼IOC共享集合",
  "description": "面向工作组成员单位的仿冒域名与URL指标集合（示例）",
  "alias": "dimiao-phishing-iocs",
  "can_read": true,
  "can_write": false,
  "media_types": ["application/stix+json;version=2.1"]
}

9.3 待共享的STIX 2.1 Bundle（示例数据）

说明：域名与IP均为保留示例值（example.com及RFC 5737文档保留地址段198.51.100.0/24），生产环境应为每条对象附加TLP标记（marking-definition）并填写真实的external_references。

{
  "type": "bundle",
  "id": "bundle--8f3a2c16-6c4a-4e1b-9f2a-1b2c3d4e5f6a",
  "objects": [
    {
      "type": "identity", "spec_version": "2.1",
      "id": "identity--c3a85f28-7a2f-4d4f-8a3c-3a2b1c4d5e6f",
      "created": "2026-09-01T08:00:00.000Z",
      "modified": "2026-09-01T08:00:00.000Z",
      "identity_class": "organization",
      "name": "DiMiao Threat Intel Lab"
    },
    {
      "type": "indicator", "spec_version": "2.1",
      "id": "indicator--7f1e2d3c-4b5a-4c6d-8e7f-9a0b1c2d3e4f",
      "created_by_ref": "identity--c3a85f28-7a2f-4d4f-8a3c-3a2b1c4d5e6f",
      "created": "2026-09-01T08:05:00.000Z",
      "modified": "2026-09-01T08:05:00.000Z",
      "indicator_types": ["malicious-activity"],
      "name": "仿冒银行登录域名（示例）",
      "pattern": "[domain-name:value = 'ibank-secure-example.com']",
      "pattern_type": "stix",
      "pattern_version": "2.1",
      "valid_from": "2026-09-01T08:05:00.000Z",
      "confidence": 85,
      "labels": ["phishing"]
    }
  ]
}

9.4 发布与增量拉取

# 生产者发布：POST bundle 至目标集合，返回 202 + Status 资源
curl -X POST \
  -H 'Content-Type: application/taxii+json;version=2.1' \
  -H 'Accept: application/taxii+json;version=2.1' \
  -d @bundle.json \
  https://ti.example.com/api1/collections/{collection-id}/objects/

# 消费者增量拉取：按加入时间过滤，断点续传
curl -H 'Accept: application/taxii+json;version=2.1' \
  'https://ti.example.com/api1/collections/{collection-id}/objects/?added_after=2026-09-01T00:00:00Z'

10 · Status资源与错误处理语义

TAXII 2.1的发布可靠性建立在Status资源之上。生产者向集合POST对象后收到HTTP 202与Status资源标识，随后通过GET status端点跟踪处理结果。Status资源的核心字段：

10.1 常见HTTP语义对照

11 · MISP规模化部署的性能要点

社区节点从试点走向枢纽，性能与可用性成为独立工程议题。以下要点为生产部署的通用工程实践（定性描述，具体参数以MISP官方文档与本社区实测基线为准）：

• 后台工作进程（Workers）：发布、邮件通知、导出缓存等后台任务由队列工作进程处理，应按CPU核数配置多Worker并以进程守护保证崩溃自恢复；
• 相关性引擎开销：全量属性关联（correlation）是数据库负载的主要来源，日增百万级指标时应按事件粒度控制关联范围，并监控correlation表增长趋势；
• 缓存与存储分离：启用Redis承接会话与临时缓存，样本/附件存储置于独立数据卷，避免数据库目录膨胀拖慢备份与迁移；
• 只读副本分流：消费端查询（REST拉取、Feed导出）走只读副本，写入与服务器间同步走主库——这是社区枢纽节点最常用的横向扩展手段；
• 备份与恢复演练：数据库每日全备加增量日志，加密离线副本留存，恢复演练纳入季度runbook（与第4页§05文档化要求衔接）。

12 · TAXII 2.1新增能力、分页与开源实现生态

12.1 相对2.0的关键新增（规范变更清单）

依据TAXII 2.1规范"Changes from Earlier Versions"章节，相对2.0版本对共享工程影响最大的新增能力包括：

• limit / next分页参数：objects端点支持按条数截断并以上游不透明游标（next参数）翻页，消费端处理大集合时不再需要一次性载入全量结果；
• object versions端点：GET .../objects/{object-id}/versions返回某对象的全部历史版本列表，支撑消费端的版本对账与审计回溯；
• DELETE object端点：支持按对象ID从集合中撤下对象（如误报指标下线），与第7页误报闭环的"止血"动作直接对应；
• spec_versions匹配过滤器：消费端可按STIX版本过滤拉取，为混合版本环境（STIX 2.0/2.1并存）提供互操作通道；
• 发现URL变更：Discovery端点由/taxii/变更为/taxii2/（DNS SRV记录相应变更），客户端迁移时需同步更新（§09示例已按新路径给出）。

12.2 开源客户端、服务端与参考实现

注：开源项目活跃度与API随版本变化，集成前以其官方仓库当前文档为准；上表不构成对任何商业产品的推荐。

本节参考来源（第2页）

以下均为官方规范与项目站点，示例中的端点路径、资源字段与HTTP语义以TAXII 2.1规范原文为准。