Validação e Interoperabilidade entre TIPs

Nota do Capítulo 22, Compartilhamento e Colaboração.
Trata da fronteira entre plataformas de inteligência, MISP, OpenCTI e TIPs comerciais: formatos comuns e seus trade-offs, mapeamento de taxonomias, conflitos típicos, deduplicação, testes de interoperabilidade e sincronização bidirecional com fluxo etapa a etapa.
Dialoga com as notas de STIX 2.1 e TAXII 2.1 deste capítulo, com o modelo de eventos do MISP, com os controles PLT.2 e PLT.3 do capítulo 15 e com a nota de Normalização e Deduplicação de Indicadores do capítulo 02.

1. Contexto e Posicionamento na Biblioteca

Raro é o programa que vive com uma única plataforma de inteligência: o MISP recebe feeds técnicos, o OpenCTI organiza conhecimento em grafo e um TIP comercial ou o próprio SIEM completa a cadeia. Entre elas existe uma fronteira onde inteligência morre em silêncio, por diferença de modelo de dados, divergência de taxonomia, conflito de atributo ou sincronização em loop. Esta nota trata essa fronteira como engenharia: formatos comuns com seus trade-offs, regras de precedência, deduplicação, testes periódicos e um fluxo bidirecional descrito etapa a etapa com armadilhas documentadas.

O posicionamento na biblioteca é o de nota de garantia de qualidade do compartilhamento. As notas anteriores do capítulo definiram o objeto trocado, os formatos e as regras, e esta verifica se o objeto chega íntegro ao destino e volta utilitário. O tema se apoia no controle PLT.3 do Framework CTH, que fixa os formatos de inteligência, no PLT.2, que posiciona o OpenCTI na arquitetura, e na nota de STIX 2.1 deste capítulo, que fornece o vocabulário de entidades usado nas conversões aqui descritas.

2. Dois Modelos de Dados em Jogo: Evento versus Grafo

O MISP organiza inteligência em eventos com atributos planos, um modelo editorial onde contexto é texto e tag; o OpenCTI e os TIPs alinhados a STIX 2.1 organizam o mesmo conteúdo em grafo de entidades e relações, onde contexto é nó e aresta tipada. Nenhuma conversão é perfeita porque os modelos expressam coisas diferentes, e interoperabilidade começa por aceitar essa assimetria: o que vira nó no destino precisa ser decidido, não inferido. A tabela a seguir traz o mapeamento de referência usado em integrações reais.

A consequência prática do mapeamento é que a qualidade do grafo no OpenCTI é limitada pela qualidade do evento no MISP. Comment vago produz descrição vaga, tag inexistente produz nó órfão de marcação e evento genérico produz Report sem narrativa. A nota de Eventos, Objetos e Atributos MISP deste capítulo é o pré-requisito direto desta, porque define a origem dos dados que aqui viajam.

3. Formatos Comuns e Trade-offs: STIX 2.1, CSV e JSON

Existem três caminhos de integração em operação, com custos e fidelidades diferentes, e a escolha depende do consumo esperado no destino. O conector nativo é o caminho preferido quando existe, porque conhece os dois modelos de ponta a ponta; STIX 2.1 é o denominador comum com plataformas comerciais; CSV e JSON aderentes a schema próprio servem para SIEM e ferramentas simples. O transporte por TAXII 2.1 desses formatos está detalhado na nota própria do capítulo.

Cadeias híbridas são a regra em produção: MISP distribui para OpenCTI por conector, OpenCTI distribui para o TIP comercial por STIX 2.1 e ambos exportam CSV para o SIEM. Cada salto é um ponto de perda, e o teste de interoperabilidade da seção 7 existe para medir a perda em vez de assumi-la. O trecho abaixo mostra a exportação de referência em STIX 2.1 e os comandos de exportação do MISP usados como fonte dessa cadeia.

{
  "type": "bundle",
  "id": "bundle--3d5a1f2e-9c4b-4e87-a6d1-8b2f5c9e7a01",
  "objects": [
    {
      "type": "indicator",
      "spec_version": "2.1",
      "id": "indicator--a71b8c2d-4e5f-4c90-b3a2-6d1e8f5c4b02",
      "created": "2026-01-14T10:00:00.000Z",
      "modified": "2026-01-14T10:00:00.000Z",
      "name": "C2 da campanha de phishing do setor financeiro",
      "pattern": "[domain-name:value = 'cdn-metrics.example.xyz']",
      "pattern_type": "stix",
      "valid_from": "2026-01-14T10:00:00.000Z",
      "confidence": 80,
      "labels": ["malicious-activity", "admiralty:reliability-B"],
      "object_marking_refs": ["marking-definition--f88d31f6-486f-44da-b317-01333bde0b82"]
    }
  ]
}

# Exportacao STIX 2.1 de eventos publicados nas ultimas 24 horas
curl -s -H "Authorization: ${MISP_KEY}" \
  "https://misp.interno/events/restSearch/format:stix2/published:1/timestamp:1d" \
  -o export_stix2.json

# Exportacao CSV filtrada por tipos alertaveis, para ingestao no SIEM
curl -s -H "Authorization: ${MISP_KEY}" \
  "https://misp.interno/attributes/restSearch/format:csv/published:1/to_ids:1" \
  "?type=sha256,ip-dst,domain,url&returnFormat=csv" -o export_siem.csv

O mesmo conteúdo sai por caminhos diferentes com fidelidades diferentes: o bundle STIX preserva marking e relações, o CSV carrega só valores alertáveis e o JSON interno carrega o que o time definir. A política de consumo deve documentar qual caminho serve a qual consumidor, e quando um consumidor exige formato que perde informação crítica, a solução é complementar o canal com relatório de contexto, e não empobrecer o padrão central para atender à ferramenta mais fraca da cadeia.

4. Mapeamento de Taxonomias e Tags entre Plataformas

Taxonomias divergentes são a causa silenciosa de inteligência invisível: o MISP marca o evento com a tag da técnica T1566.001 e o OpenCTI espera a entidade Attack-Pattern com external reference ATT&CK, e sem dicionário de mapeamento o dado chega sem contexto. O mapa de taxonomias é um artefato versionado em repositório, com entrada por par de vocabulários, cobrindo no mínimo TLP, ATT&CK, escala de Admiralty, tipos de evento e etiquetas internas de campanha. A tabela seguinte ilustra entradas típicas desse dicionário.

O dicionário é código, não conversa: cada mudança passa por revisão e versionamento, e o conector lê o dicionário em vez de embutir regras. Exceções concedidas a uma fonte específica ficam registradas com motivo e data, para que a exceção não vire regra por omissão. Quando uma plataforma nova entra no parque, o dicionário recebe um par de vocabulários novo antes do primeiro evento sincronizado, nunca depois do primeiro incidente de perda de contexto.

5. Conflitos Típicos e Regras de Precedência

Três famílias de conflito aparecem em toda integração madura e precisam de regras explícitas no conector. A primeira são atributos divergentes, quando duas plataformas carregam vereditos diferentes para o mesmo valor, como um domínio malicioso no feed A e legítimo no feed B, ou expirações e scores conflitantes para o mesmo indicador. A segunda são hashes diferentes do mesmo binário, quando o feed A publica apenas sha256, o feed B publica md5 e um terceiro publica ssdeep de uma variante empacotada, e o destino não reconhece que os três valores descrevem a mesma carga. A terceira são rótulos de confiança e TLP divergentes, quando o mesmo dado chega com tlp:amber em uma plataforma e tlp:green em outra, ou com threat_level_id 2 no MISP e confidence 40 no STIX, escalas que não se comparam sem tabela de conversão.

As regras operacionais recomendadas para o dicionário de precedência são as seguintes, e nenhuma delas pode ser resolvida silenciosamente pelo conector:

• Afirmação divergente nunca é sobrescrita: as duas versões coexistem com fonte, data e rótulo, e a resolução acontece na triagem analítica com registro da decisão, porque a divergência é dado de inteligência.
• Para campos técnicos como expiração e score, prevalece o valor mais recente de fonte com confiabilidade superior na escala de Admiralty, e a sobreposição anterior fica em histórico consultável.
• Para contagens acumuladas, como número de detecções ou de relatórios, os valores se agregam, e nunca se escolhe um deles arbitrariamente.
• Para labels de veredito, prevalece a marcação mais restritiva até que a triagem decida, porque o custo assimétrico de subrotular um C2 ativo é maior que o de investigação falsa.
• Para hashes do mesmo binário, o conector mantém todos os valores no mesmo objeto file, usa o hash mais forte disponível como chave canônica e correlaciona imphash e ssdeep como ligações fracas, jamais fundindo registros sem correspondência de arquivo.

O conflito é sinal, não defeito de pipeline, e o sistema que o esconde apaga exatamente a informação que o analista precisaria para decidir. A divergência de TLP merece atenção especial porque é risco legal além de técnico: prevalece sempre o rótulo mais restritivo na propagação, e a conversão de tag textual para marking definition é automática, porque TLP escrito à mão em campo de texto escapa de filtros e auditorias.

6. Deduplicação entre Plataformas

Deduplicação entre plataformas é mais difícil que dentro de uma, porque cada lado normaliza de forma própria e o mesmo IOC chega ao destino com representações distintas. A receita mínima inclui as seguintes práticas de chaveamento, aplicadas no conector e não manualmente:

• Normalização de valor antes da chave: domínio em minúsculas, IP sem zeros à esquerda, URL canônica com scheme e query ordenados, hash em minúsculas hexadecimais.
• Chave estável independente do evento: o mesmo valor de duas fontes distintas colide na mesma entrada, com vínculo para múltiplos eventos de origem, e não cria dois indicadores.
• Tratamento de compostos: pares como filename e hash viram chave composta derivada dos dois valores, nunca só de um deles.
• Deduplicação temporal: eventos sincronizados repetidos por feed e por push resolvem-se pelo uuid do evento e pela data de atualização mais recente, mantendo histórico de revisão.

A dupla dimensão deduplicação e conflito exige que o destino distinga valor repetido de afirmação repetida: valor repetido com fontes novas soma credibilidade e não cria linha nova, afirmação repetida da mesma fonte é sincronização redundante e deve ser descartada sem alerta. A nota de Normalização e Deduplicação de Indicadores do capítulo 02 detalha as regras de normalização por tipo, e o conector deve reaproveitar essa biblioteca em vez de reimplementar.

7. Testes de Interoperabilidade e Round-Trip

Interoperabilidade não se presume, se testa em agenda fixa, com indicadores canário e critérios objetivos. O teste canário injeta valores sintéticos na fonte em horários conhecidos e mede a chegada, a fidelidade e o prazo no destino, transformando integração em número. O round-trip é o teste mais exigente da matriz, porque exercita ida e volta: um valor parte do MISP, vira Indicator no OpenCTI e retorna como atributo de curadoria, e o critério de sucesso é voltar reconhecido como existente, sem duplicar e sem perder marking. A matriz a seguir organiza os testes mínimos de uma cadeia MISP, OpenCTI e TIP comercial.

O registro das rodadas fica no repositório do conector, com resultado, horário e versão das duas plataformas, porque integração que funciona hoje pode quebrar com atualização de qualquer lado, e o histórico é o que distingue regressão de acidente. Quando um canário falha, o alarme dispara para o dono da integração nomeado no repositório, e não para o grupo inteiro. A tendência das últimas rodadas vale mais que a rodada isolada, e o gráfico de latência semanal é a primeira coisa a consultar quando um consumidor reclama que inteligência não está chegando.

8. Sincronização Bidirecional: Fluxo MISP-OpenCTI Etapa a Etapa

O fluxo bidirecional clássico usa o MISP como fonte de IOCs técnicos e o OpenCTI como camada de conhecimento, com retorno seletivo do que o analista produziu no grafo. O ciclo completo, do evento publicado ao retorno curado, se descreve nas nove etapas a seguir, que servem de esqueleto para o runbook da integração:

• Etapa 1: o analista publica o evento no MISP com tags tlp, admiralty e galáxias anexadas; apenas eventos com published true e distribuição compatível com a política entram no fluxo.
• Etapa 2: o conector MISP do OpenCTI consulta a API restSearch em intervalos curtos, filtrando por published, por data de atualização e por tipos excluídos, com paginação para rajadas.
• Etapa 3: o conector converte o modelo: o Event vira Report, atributos com to_ids viram Indicator com observable derivado, atributos sem to_ids viram apenas Observable, objetos MISP viram SCOs com relações tipadas e galáxias viram SDOs.
• Etapa 4: o dicionário de marcação é aplicado: a tag tlp:green vira marking definition com URI padrão, tags admiralty viram labels e a técnica ATT&CK é vinculada como Attack-Pattern.
• Etapa 5: a ingestão aplica deduplicação por valor canônico: indicador já existente ganha sighting e vínculo com o Report novo, sem criar nó duplicado.
• Etapa 6: analistas curam no OpenCTI: enriquecem entidades, corrigem atribuição, criam relações e fixam createdBy no time de CTI, marcação que autoriza o retorno.
• Etapa 7: a exportação de retorno roda em intervalo maior e seleciona apenas Indicators criados ou editados pelo time curador, com marking autorizado para sair.
• Etapa 8: o conector grava os indicadores retornados no MISP como atributos de um evento de curadoria interna, com marcação de origem e distribuição restrita, sem republicação para comunidades externas.
• Etapa 9: o filtro de exclusão por fonte impede que esse evento de curadoria reingresse no OpenCTI, fechando o ciclo sem loop, e o canário semanal valida latência e fidelidade do caminho inteiro.

O trecho abaixo mostra a espinha dorsal de configuração desse arranjo no conector MISP do OpenCTI, com os parâmetros que governam cada etapa descrita.

connector-misp:
  name: MISP instancia interna
  interval: 5
  import_from_date: "2026-01-01"
  import_only_published: true
  report_type: misp-report
  create_indicators: true
  create_observables: true
  create_relationships: true
  exclude_types: ["text", "comment"]
  guess_threat_actor_from_tags: false
  # retorno seletivo: apenas indicadores curados pelo time de CTI
  export_indicators:
    interval: 30
    filters: '{"mode":"and","filters":[{"key":"createdBy","values":["time-cti"]}]}'

Mesmo com dicionário, filtros e canários, o fluxo bidirecional concentra as armadilhas mais caras da interoperabilidade, e a tabela a seguir as consolida com sintoma e mitigação para uso direto no runbook.

A armadilha de versionamento merece detalhe porque é a mais contraintuitiva: quando o MISP republica um evento antigo revisado horas depois de o analista ter corrigido a atribuição no OpenCTI, um conector ingênuo sobrescreve o trabalho humano com dado mais velho. A regra é comparar o campo modified do objeto antes de qualquer gravação e tratar divergência como conflito da seção 5, coexistindo versões até triagem, em vez de aplicar last-writer-wins sobre relógios de plataformas diferentes.

9. Erros Comuns e Pontos de Atenção

Os erros recorrentes em integrações de TIP se concentram em ignorar a fronteira como superfície de engenharia. Vale revisar a lista a seguir antes de qualquer go-live:

• Sincronizar tudo por medo de perder algo, transformando o destino em acúmulo que ninguém usa, quando o filtro deveria seguir os PIRs do programa.
• Sobrescrever conflitos silenciosamente, escolhendo o último valor recebido e apagando a divergência que era o sinal mais valioso.
• Converter tags texto para marking manualmente em cada incidente, quando o dicionário de mapeamento deveria automatizar essa decisão.
• Testar a integração apenas na implantação, sem canário recorrente, descobrindo a quebra semanas depois por reclamação de consumidor.
• Ignorar expiração no destino, mantendo IOCs mortos alertando em plataforma que desconhece o ciclo de vida definido na origem.
• Assumir que o conector nativo preserva tudo, sem validar fidelidade com canário, porque conectores evoluem e campos mudam de nome entre versões.
• Deixar de fixar versão do conector e da plataforma em repositório, impossibilitando correlacionar uma mudança de comportamento com uma atualização específica.

O ponto de atenção central é que interoperabilidade é processo vivo, com dono, agenda de teste e dicionário versionado, e o custo de mantê-la é ordens de magnitude menor que o custo de descobrir, durante um incidente, que o IOC crítico nunca chegou ao destino.

10. Integração com o Restante da Biblioteca

A nota de Eventos, Objetos e Atributos MISP define a origem dos dados que aqui viajam, a nota de STIX 2.1 em Profundidade detalha as entidades de destino e a nota de TAXII 2.1 cobre o transporte entre coleções. A nota de Políticas de Compartilhamento e FIRST IEP define o que pode viajar e com qual rótulo, cuja preservação é verificada pelo teste de fidelidade desta nota, e os controles PLT.2 e PLT.3 do capítulo 15 formalizam a arquitetura OpenCTI e os padrões de formato adotados aqui.

Do lado do consumo, os indicadores que atravessam a fronteira alimentam as caças baseadas em IOC do capítulo 10 e os controles de plataforma do capítulo 15, e a normalização aplicada no conector reaproveita as regras da nota de Normalização e Deduplicação de Indicadores do capítulo 02. Uma extensão natural é alimentar o painel de ROI do compartilhamento do capítulo 22 com os resultados dos testes canário, porque latência média e taxa de fidelidade por plataforma são métricas objetivas de qualidade de fornecedor, capazes de justificar a renovação ou o corte de um feed comercial com dado medido em vez de impressão.