PLT.3 - Formatos de Inteligência (STIX-TAXII)

Controle PLT.3 do grupo PLT (Plataformas de Inteligência de Ameaças) do Framework CTH, derivado do Capítulo 8 do PDF de referência. Define os padrões STIX 2.1 e TAXII 2.1 como vocabulário comum de representação e transporte da inteligência no programa. O controle sustenta DAT, PLT.1 e PLT.2 ao garantir que indicadores, entidades e relacionamentos circulem entre ferramentas e organizações sem integrações customizadas frágeis.

1. Contexto e Posicionamento no Framework CTH

O STIX (Structured Threat Information Expression) e o TAXII (Trusted Automated Exchange of Intelligence Information) são os padrões internacionais, mantidos no âmbito do OASIS, para representar e trocar informações de ameaças. Sem a adoção desses padrões, a interoperabilidade entre MISP, OpenCTI, SIEM, plataformas comerciais, ISACs e agências depende de scripts ad hoc que quebram a cada mudança de formato. O STIX fornece o vocabulário estruturado e o TAXII define o protocolo de troca automatizada sobre HTTPS.

Dentro do grupo PLT, este controle é a camada de interoperabilidade que liga a gestão de fontes do PLT.4, o compartilhamento do PLT.1, o conhecimento do PLT.2 e a política de divulgação do PLT.5. A regra operacional do Framework CTH é que toda importação e toda exportação de inteligência entre sistemas deve ocorrer em STIX 2.1, com TAXII 2.1 quando houver troca automatizada. Formatos proprietários são tolerados apenas na fronteira, com conversão documentada para STIX no primeiro ponto de ingestão.

2. Por Que Padronizar Representação e Transporte

A padronização resolve dois problemas distintos que costumam ser confundidos. O primeiro é semântico, porque ferramentas diferentes nomeiam conceitos parecidos de formas diferentes, e o STIX estabelece objetos e propriedades com significado único. O segundo é logístico, porque transferir grandes volumes de inteligência de forma segura, incremental e rastreável exige um protocolo próprio, papel do TAXII.

O benefício aparece em situações concretas do dia a dia. Um indicador recebido de um ISAC em STIX chega com fonte, validade, marcação TLP e relacionamento com a campanha, pronto para enriquecer o grafo do OpenCTI sem leitura manual. A mesma informação em CSV sem cabeçalho padronizado demanda interpretação humana, não tem marcação confiável e não carrega validade, forçando a equipe a decidir atributos críticos sob pressão. A tabela abaixo resume as famílias de objetos STIX 2.1.

3. STIX Patterning em Resumo

O campo pattern do objeto indicator usa a linguagem STIX Patterning para expressar condições de correspondência, convertíveis em consultas de SIEM ou regras de detecção. Um pattern combina propriedades de observáveis com operadores de comparação, lógica e funções de tempo. O vocabulário essencial cabe em poucos operadores, e a leitura correta de patterns é competência mínima para quem consome feeds.

[domain-name:value = 'portal-falso.example']
[ipv4-addr:value = '198.51.100.7' AND network-traffic:dst_port = 443]
[file:hashes.'SHA-256' = 'a94a8fe5ccb19ba61c4c0873d391e987982fbbd3' OR
 file:name LIKE '%invoice%.exe']
[domain-name:value = 'painel-atacante.example'
 AND created >= '2025-01-01T00:00:00.000Z']

Recomendações práticas reduzem erros de consumo. Prefira patterns simples por indicador, porque expressões gigantes dificultam a conversão automática; valide a sintaxe na ingestão, rejeitando objetos malformados; e mantenha tabela de conversão para a linguagem do SIEM, documentando equivalências e limitações de cada operador.

4. TAXII 2.1 e o Fluxo de Consumo

O TAXII define uma API REST sobre HTTPS com endpoints padronizados. O cliente descobre os serviços pelo endpoint de discovery, escolhe um api-root, lista as collections disponíveis e consome objetos por intervalo de tempo. Cada collection agrupa um conjunto de dados, e a resposta traz os objetos STIX paginados, com possibilidade de consulta ao manifest para metadados.

O fluxo de consumo incremental é a prática que evita reprocessamento e sobrecarga. A sequência recomendada para cada fonte TAXII é a seguinte:

1. Consultar discovery e autenticar com credenciais dedicadas à fonte.
2. Listar collections e registrar quais são elegíveis pela política de TLP da organização.
3. Consumir objetos com added_after do último checkpoint persistido.
4. Validar cada objeto contra o esquema STIX 2.1 antes de inserir na plataforma.
5. Atualizar o checkpoint e registrar volume, erros e marcações recebidas.

# Consumo incremental de uma collection TAXII 2.1
curl -s --user "${TAXII_USER}:${TAXII_PASS}" \
  "https://taxii.parceiro.example/api/collections/${COLECAO}/objects/?added_after=2025-01-10T00:00:00.000Z"

As credenciais TAXII merecem tratamento equivalente às demais chaves de API. Cada fonte deve ter usuário próprio, com escopo somente leitura e rotação periódica, porque chaves compartilhadas entre fontes impedem rastrear o consumo por parceiro e dificultam a revogação pontual quando um acesso é desativado. Registre a rotação no calendário de segurança e teste o consumo logo após cada troca, para confirmar que o checkpoint incremental segue avançando.

5. Diferenças entre STIX 2.0 e STIX 2.1

A versão 2.1 é o alvo do Framework CTH, e saber o que mudou evita equívocos de migração. Plataformas antigas ainda emitem 2.0, e conversores robustos tratam a transição. A tabela resume as mudanças com impacto operacional.

6. Exemplo de Objeto STIX Simplificado

O bundle abaixo traz um indicator mínimo, com padrão de domínio, validade, rótulos e marcação TLP:AMBER referenciada por marking-definition. Esse é o nível de informação que um feed maduro entrega por objeto, e a ausência de qualquer um desses campos na ingestão deve gerar alerta de qualidade.

{
  "type": "bundle",
  "id": "bundle--7b6f5a1e-0d2c-4f8a-9c1e-6a2b4d8e0f11",
  "objects": [
    {
      "type": "indicator",
      "spec_version": "2.1",
      "id": "indicator--c3d1a2f4-5b6e-4c7d-8a9b-0f1e2d3c4b5a",
      "created": "2025-01-12T10:00:00.000Z",
      "modified": "2025-01-12T10:00:00.000Z",
      "created_by_ref": "identity--f4311d2f-7a1c-4e1f-9c2d-0b1a2c3d4e5f",
      "name": "Dominio de phishing contra banco parceiro",
      "pattern": "[domain-name:value = 'portal-cobranca-falsa.example']",
      "pattern_type": "stix",
      "valid_from": "2025-01-12T10:00:00.000Z",
      "valid_until": "2025-02-12T10:00:00.000Z",
      "labels": ["phishing", "malicious-activity"],
      "object_marking_refs": ["marking-definition--55d920e0-6eb1-4f76-a51b-1d1b3f8a4317"]
    }
  ]
}

7. Limitações Práticas e Compatibilidade

O padrão é bom apenas quanto à adoção real das fontes. Muitos feeds públicos entregam apenas listas de IOC em CSV, sem contexto, sem validade e sem marcação, e a conversão técnica para STIX não cria o contexto que nunca existiu. Nesses casos, o conector deve registrar a fonte como origem, aplicar marcação padrão conservadora e marcar o material como candidato a enriquecimento, em vez de fingir qualidade inexistente.

A compatibilidade entre plataformas também exige atenção contínua. Conversões do modelo de eventos do MISP para STIX nem sempre preservam todos os contextos, e versões legadas, como feeds que ainda publicam 2.0, demandam mapeamento explícito. Testes de ida e volta, exportando e importando amostras entre as plataformas da organização, fazem parte da validação trimestral do pipeline de inteligência.

8. Integração no Pipeline da Biblioteca

Na arquitetura da seção PLT, o STIX 2.1 é o formato canônico de troca e o TAXII 2.1 é o transporte. O MISP do PLT.1 exporta eventos e atributos em STIX para o OpenCTI do PLT.2, que mantém entidades nativas no mesmo padrão e publica coleções TAXII para consumidores internos e parceiros. As fontes do PLT.4 são priorizadas quando suportam STIX/TAXII, e a marcação do PLT.5 viaja junto com os objetos como marking-definition.

9. Implementação Prática e Salvaguardas por Nível

O Framework CTH organiza as salvaguardas do controle em três níveis cumulativos. A implantação deve registrar evidência de cada marco, incluindo amostras de objetos validados e logs de consumo. A tabela resume os objetivos e entregáveis.

10. Erros Comuns e Pontos de Atenção

Os erros abaixo comprometem a interoperabilidade que o controle existe para garantir. Cada item traz o efeito observável e a correção recomendada.

• Tratar CSV convertido a STIX como inteligência com contexto; efeito: grafo com entidades vazias; correção: rotular como sem contexto e priorizar enriquecimento.
• Aceitar objetos sem marcação TLP por simplicidade; efeito: risco de divulgação indevida; correção: rejeitar ou aplicar marking padrão conservador na ingestão.
• Consumir coleções inteiras sem added_after; efeito: reprocessamento e sobrecarga; correção: checkpoints incrementais persistidos por fonte.
• Manter 2.0 e 2.1 misturados sem política; efeito: perda de campos e bugs silenciosos; correção: normalizar para 2.1 no primeiro ponto de entrada.
• Patterns complexos demais para conversão no SIEM; efeito: indicadores que nunca acionam; correção: padrões simples e tabela de conversão testada.
• Servidor TAXII aberto sem controle de coleção; efeito: exposição de conteúdo restrito; correção: autenticação por parceiro e coleções segregadas por TLP.

11. Integração com Outros Controles do Framework CTH

O PLT.3 é a linguagem comum que permite aos demais controles conversar sem perda de informação. DAT define os atributos que os objetos SCO carregam, AUT consome indicators via TAXII para alimentar detecção contínua, e MET mede a qualidade das trocas por volume validado, taxa de rejeição e latência entre publicação e consumo. Na comunidade, a participação em ISACs do PLT.5 depende diretamente de este controle estar operando, porque a troca mútua em STIX/TAXII é a moeda aceita por parceiros maduros.

No plano de maturidade, o marco Básico exige exportação e importação STIX 2.1 em produção e duas fontes TAXII ativas; o Intermediário exige validação automática de objetos e conectores de conversão documentados; o Avançado exige servidor TAXII próprio com coleções segregadas por TLP e monitoramento de consumo. A métrica de fechamento é a proporção de inteligência circulando em formato padronizado, que deve tender a cem por cento das trocas automatizadas.