TAXII 2.1 em Profundidade

Nota 06 do capítulo 22, que aprofunda o protocolo de transporte da inteligência estruturada compartilhada em STIX.
O foco é o ciclo operacional de consumo e publicação sobre TAXII 2.1: serviços, autenticação, filtros, paginamento e diferenças em relação à 2.0.
Dialoga com a nota de STIX 2.1 desta mesma seção, que define os objetos transportados, e com as notas de MISP e OpenCTI da biblioteca.

1. Contexto e Posicionamento na Biblioteca

O STIX 2.1 define o que se compartilha; o TAXII (Trusted Automated eXchange of Intelligence Information) define como se compartilha. A especificação do OASIS descreve um protocolo de aplicação sobre HTTPS, com serviços de descoberta, catálogo de coleções e troca de objetos, e é o contrato que permite a uma organização consumir inteligência de um ISAC, de um fornecedor comercial e de um parceiro governamental com o mesmo cliente. Esta nota desce ao nível de operação: endpoints, cabeçalhos, autenticação, paginamento e filtros, o vocabulário exato que quem implementa conectores de ingestão precisa dominar.

A nota é o complemento direto da de STIX 2.1 desta seção, e fecha o conjunto iniciado no capítulo 02, onde o compartilhamento apareceu no nível de ecossistema, e no controle PLT.3 da seção 15, onde o par STIX-TAXII aparece como controle de plataforma. O objetivo prático é que o leitor saia daqui capaz de consumir uma coleção real com curl até dominar o ciclo completo, de publicar objetos numa coleção própria e de avaliar um servidor TAXII na hora de escolher fontes.

2. O Modelo de Serviços do TAXII 2.1

O TAXII 2.1 é pequeno de propósito: cinco recursos principais e verbos HTTP padrão. A descoberta acontece no endpoint de discovery, que informa os api-roots disponíveis; cada api-root hospeda collections, cada collection carrega objects e manifest; e o servidor publica metadados descritivos em cada nível. O cliente autentica, descobre, lista coleções e então consome ou publica objetos. A tabela abaixo resume os endpoints canônicos e seu papel no ciclo.

O envelope de resposta é o envelope TAXII, um JSON com três chaves: more, next e objects. A propriedade more indica que há mais resultados, next traz o token de continuação e objects carrega os objetos STIX completos. O mesmo envelope serve para objects e para manifest, e o cliente que não trata more e next recebe apenas a primeira página silenciosamente, o que é a causa clássica de ingestões parcialmente sincronizadas que ninguém percebe por semanas.

3. Tipos de Troca: Feed, Coleção e Push

O TAXII 2.1 simplificou o modelo de interação da 2.0 em dois padrões de uso, e a nomenclatura de mercado ainda usa o vocabulário mais amplo. No padrão de consumo, o cliente consulta periodicamente a coleção com filtros incrementais, o chamado feed de inteligência, e sincroniza objetos novos ou alterados. No padrão de publicação, o produtor empurra objetos para a coleção usando o método POST no endpoint de objects, o que na 2.1 substituiu formalmente o serviço de inbox da 2.0. A direção da troca é decisão do servidor: coleções podem ser somente leitura para o cliente, somente escrita, ou leitura e escrita, e as permissões são declaradas no recurso da coleção.

A cadência do consumo incremental é o detalhe que separa ingestão profissional de script de fim de semana. O parâmetro added_after, consultado com o carimbo da última sincronização bem-sucedida, devolve apenas objetos adicionados depois daquele momento, e o cliente guarda esse carimbo como parte do estado da sincronização, junto com a política de recuperação em caso de falha. Cadências típicas de mercado variam de cinco minutos para fontes de alta prioridade a uma hora para fontes agregadoras, e a escolha deve considerar a janela de utilidade dos indicadores consumidos, tema que o capítulo de ciclo de vida de IOCs da biblioteca já aprofundou.

4. Autenticação, TLS e Media Types

Todo tráfego TAXII 2.1 circula sobre HTTPS, e a autenticação recomendada pela especificação é OAuth 2.0, com HTTP Basic permitido para compatibilidade e reservado a ambientes controlados. Na prática de mercado, o Basic com TLS é comum em ISACs e comunidades fechadas, enquanto fornecedores comerciais operam OAuth com tokens de longa vida e rotação programada. A identidade do cliente define as coleções visíveis, e a granularidade de permissão por coleção é o mecanismo que permite a um servidor servir comunidades distintas com dados segregados.

Os media types fazem parte do contrato e merecem atenção do implementador: o conteúdo TAXII usa application/taxii+json;version=2.1, e o conteúdo STIX puro usa application/stix+json;version=2.1. O cabeçalho Accept do cliente deve declarar a versão, porque servidores em transição podem servir múltiplas versões da especificação, e o parâmetro match[spec_version] no filtro refina a escolha por objeto. Erros de media type produzem respostas 406 ou 415 que confundem quem trata todo erro como falha de rede, e a checagem de cabeçalhos é o primeiro passo de depuração.

5. Paginamento e Filtros

O paginamento usa os parâmetros next e limit, e o algoritmo correto é iterativo: consulte com limit, leia more e next do envelope, repita com o token até more ser falso. O parâmetro limit tem limite máximo definido pelo servidor, e respeitar o valor declarado no api-root evita respostas truncadas. Os filtros de consulta são poucos e poderosos, e a tabela abaixo resume os combináveis no consumo diário.

A combinação padrão de consumo incremental é added_after com limit e tratamento de more, e a disciplina de registro importa tanto quanto a consulta: o cliente deve persistir o carimbo da sincronização só após a página final confirmada, porque interromper no meio do paginamento e gravar o carimbo gera lacuna silenciosa no inventário de inteligência. Para auditoria, o manifest é o instrumento de reconciliação barato: comparar o manifest da coleção com o inventário local revela lacunas e objetos órfãos sem baixar conteúdo completo.

6. Ciclo de Consumo via curl e Publicação

O ciclo completo de consumo cabe em quatro chamadas, e o exemplo a seguir mostra a sequência realista contra um servidor de referência, com autenticação por token no cabeçalho.

# 1. Descoberta: lista api-roots disponiveis
curl -s -H "Accept: application/taxii+json;version=2.1" \
  -H "Authorization: Bearer $TOKEN" https://taxii.isac.org.br/taxii2/

# 2. Catalogo de colecoes do api-root
curl -s -H "Accept: application/taxii+json;version=2.1" \
  -H "Authorization: Bearer $TOKEN" https://taxii.isac.org.br/api/v21/collections/

# 3. Consumo incremental com filtro e paginamento
curl -s -G -H "Accept: application/taxii+json;version=2.1" \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "added_after=2026-02-03T10:00:00.000Z" \
  --data-urlencode "match[type]=indicator" \
  --data-urlencode "limit=50" \
  https://taxii.isac.org.br/api/v21/collections/2d1a4b6e-f2a1-4c8b-9d3e-5f7a8b9c0d1e/objects/

# 4. Reconciliacao via manifest sem baixar conteudo completo
curl -s -G -H "Accept: application/taxii+json;version=2.1" \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "added_after=2026-02-03T10:00:00.000Z" \
  https://taxii.isac.org.br/api/v21/collections/2d1a4b6e-f2a1-4c8b-9d3e-5f7a8b9c0d1e/manifest/

A resposta da etapa 3 traz o envelope com a página de indicadores, e o trecho a seguir mostra a forma do envelope com um objeto resumido, seguido do ciclo de publicação, em que o produtor empurra objetos novos para a coleção da comunidade.

{
  "more": true,
  "next": "eyJhZGRlZF9hZnRlciI6IjIwMjYtMDItMDNUMTA6MDA6MDAuMDAwWiJ9",
  "objects": [
    {
      "type": "indicator",
      "spec_version": "2.1",
      "id": "indicator--e5f6a7b8-0000-4000-8000-000000000005",
      "created": "2026-02-04T09:12:00.000Z",
      "modified": "2026-02-04T09:12:00.000Z",
      "name": "Dominio de portal falso",
      "pattern": "[domain-name:value = 'portal-banco-seguro.com']",
      "pattern_type": "stix",
      "valid_from": "2026-02-01T00:00:00.000Z",
      "valid_until": "2026-05-01T00:00:00.000Z"
    }
  ]
}

# Publicacao: produtor empurra bundle de objetos novos para a colecao
curl -s -X POST -H "Accept: application/taxii+json;version=2.1" \
  -H "Content-Type: application/taxii+json;version=2.1" \
  -H "Authorization: Bearer $TOKEN_PRODUTOR" \
  --data @bundle-campanha-fevereiro.json \
  https://taxii.isac.org.br/api/v21/collections/9e3f2a41-7c8d-4b5e-a1f0-2d3c4b5a6e7f/objects/

A resposta da publicação é um envelope que ecoa os IDs aceitos, e o produtor deve tratar falhas parciais com a mesma seriedade das falhas totais: objeto rejeitado por validação de schema, por data inválida ou por política da coleção precisa voltar à fila de correção, e a publicação que ignora rejeições parciais fabrica lacunas na coleção da comunidade. O ciclo se fecha com a leitura de confirmação: o produtor consulta o manifest da própria coleção e compara com o que enviou, replicando para si a reconciliação que exige dos consumidores.

7. Diferenças entre TAXII 2.0 e 2.1

A migração da 2.0 para a 2.1 removeu mecanismos e simplificou o modelo, e quem opera servidores das duas versões precisa do mapa das diferenças. A tabela abaixo resume as mudanças com impacto operacional direto.

O efeito prático das mudanças é a redução de infraestrutura necessária para operar troca bidirecional. Na 2.0, um parceiro que publicava precisava de inbox configurado de cada destinatário ou de canal compartilhado, e essa fricção era a causa mais comum de integrações paradas; na 2.1, a publicação é uma chamada autenticada à coleção do destinatário, e a governança passa a morar nas permissões da coleção. Para consumidores, o ganho central é o filtro por spec_version, que permite operar transições de formato sem quebrar ingestões, tema relevante porque comunidades reais convivem com produtores em ritmos de migração diferentes.

8. Erros Comuns e Pontos de Atenção

• Ignorar more e next no paginamento: cliente que consome só a primeira página sincroniza frações da coleção sem erro aparente; o laço de paginamento completo é obrigatório.
• Gravar o carimbo de added_after antes do fim da sincronização: falha no meio do laço gera lacuna silenciosa; o carimbo só persiste após a última página confirmada.
• Tratar erro de media type como falha de rede: 406 e 415 indicam negociação de conteúdo errada; verificar Accept e a versão declarada é o primeiro passo da depuração.
• Usar HTTP Basic fora de TLS ou em ambiente aberto: a credencial circula em cada chamada, e a especificação recomenda OAuth 2.0 exatamente por isso.
• Publicar sem tratar rejeições parciais: envelope de resposta com IDs recusados é falha de publicação que precisa de fila de correção, não de log ignorado.
• Consumir sem reconciliar com o manifest: lacunas e objetos perdidos só aparecem em auditoria quando o manifest é comparado com o inventário local em cadência regular.
• Misturar credenciais de leitura e escrita: cliente de consumo não precisa de permissão de publicação, e a segregação de tokens é o guardrail que impede vazamento de escrita.

9. Integração com o Restante da Biblioteca

As conexões estruturais desta nota com o restante da biblioteca seguem quatro caminhos:

• Capítulo 02: o compartilhamento por ISACs e o pipeline de coleta são o contexto, e a avaliação de qualidade de fonte se aplica diretamente à escolha de coleções.
• Capítulo 22: o STIX 2.1 define os objetos transportados, e o MISP e o OpenCTI da biblioteca operam como produtores e consumidores TAXII em implementações reais.
• Seção 15: o controle PLT.3 formaliza o par STIX-TAXII como controle de plataforma, e o grupo MET mede a efetividade da inteligência ingerida por coleção.
• Capítulo 03: o ciclo de vida de IOCs consumido via TAXII alimenta as regras de expiração e a pontuação de qualidade aplicadas na chegada.

A métrica que avalia o consumo é a proporção de objetos ingeridos que passam validação, deduplicação e entram em uso nas detecções, medida por coleção, e ela transforma a escolha de fontes em decisão baseada em dados. A segunda métrica, derivada da sincronização incremental, é a idade média dos objetos no momento da ingestão, porque inteligência que chega velha custa o mesmo da que chega fresca e vale muito menos; a cadência de consulta e a qualidade do servidor são as variáveis sob seu controle, e esta nota é o manual técnico de ambas.