Objetos, Relacionamentos e Observáveis STIX

Nota do capítulo 22 (Compartilhamento e Colaboração).
Cataloga de forma prática os objetos STIX 2.1 (SDOs e SCOs), os relacionamentos canônicos entre eles e como modelar uma intrusão completa como grafo navegável.
Complementa as notas 05 e 06 deste capítulo, que tratam do padrão STIX e do transporte TAXII em profundidade.

1. Contexto e Posicionamento na Biblioteca

O STIX 2.1 não é apenas um formato de serialização de indicadores; é uma linguagem para descrever o mundo das ameaças como grafo. Cada objeto representa uma entidade ou evento, e cada relacionamento conecta entidades em uma semântica previsível. Quem entende o catálogo de objetos e as regras de relacionamento consegue ler um bundle de terceiro e reconstruir a história da intrusão, e consegue escrever bundles que plataformas como MISP e OpenCTI interpretam sem perda de sentido.

Esta nota ocupa o papel de catálogo de referência rápida dentro da biblioteca. As notas 05 e 06 do capítulo 22 explicam o padrão e o transporte; aqui o foco é o vocabulário: quais objetos existem, quando usar cada um, como encadear relacionamentos canônicos e como montar um grafo de intrusão que sobreviva à importação por outra plataforma. O exemplo conduzido nas seções finais usa uma intrusão fictícia de ransomware para demonstrar a modelagem ponta a ponta.

2. Objetos STIX Domain Objects (SDOs)

Os SDOs representam entidades e eventos do domínio de ameaças. A tabela abaixo resume os SDOs de uso mais frequente, com o papel de cada um e um exemplo típico de conteúdo.

Duas distinções exigem disciplina na hora de modelar. A primeira é entre malware e tool: o mesmo Mimikatz aparece como tool quando o adversário usa a ferramenta de terceiros e como malware quando a própria amostra é o objeto em análise; a escolha afeta como outras plataformas correlacionam. A segunda é entre threat-actor e intrusion-set: attribution tênue deve ser modelada como intrusion-set, e o threat-actor só entra quando a confiança na atribuição suporta o vínculo, prática coerente com a escala de confiança tratada na nota 09 do capítulo 05.

3. Observáveis e SCO (STIX Cyber-observable Objects)

Os SCOs representam fatos técnicos imutáveis: hashes, IPs, domínios, URLs, arquivos, processos, certificados. Diferentemente dos SDOs, os SCOs não possuem ID gerado pelo produtor; recebem ID determinístico derivado de seu conteúdo, o que faz dois produtores gerarem o mesmo ID para o mesmo observável, propriedade fundamental para deduplicação entre plataformas, tema também abordado na nota 10 deste capítulo.

A prática de mercado é compor SCOs em estrutura: um network-traffic aponta para o ipv4-addr de destino e para o domain-name via SNI; um process aponta para o file do binário executado. Essa composição permite descrever contexto sem inventar SDOs redundantes. Em ambientes que consomem apenas indicadores simples, o SCO aparece embutido no objeto indicator via pattern, em linguagem STIX Patterning, como mostra o exemplo a seguir.

{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--d4f8...",
  "pattern": "[domain-name:value = 'cdn-updates-login.com']",
  "pattern_type": "stix",
  "valid_from": "2026-05-02T00:00:00Z",
  "valid_until": "2026-08-02T00:00:00Z",
  "labels": ["malicious-activity"],
  "confidence": 85
}

4. Relacionamentos Canônicos

Os relacionamentos carregam a semântica do grafo e são a parte mais descuidada na prática. Usar relationship errado quebra a interpretação do consumidor: um indicator que delivers malware em vez de indicates malware muda o significado da cadeia. A tabela reúne os pares canônicos de uso diário, com fonte, alvo e leitura natural da frase.

Três regras de higiene evitam grafos ilegíveis. Primeira: preferir o relacionamento mais específico disponível; beacons-to comunica mais que communicates-with. Segunda: never usar related-to como atalho quando a semântica real é known; grafos cheios de related-to perdem valor analítico. Terceira: toda atribuição passa por attributed-to a partir de intrusion-set, nunca direto de indicator, porque o indicador demonstra atividade, não autor.

5. Versionamento, Markings e Bundle

Todo SDO carrega created e modified, e a modificação segue versionamento: quando o produtor altera um objeto, mantém o mesmo id e incrementa modified; plataformas conciliam pela dupla id e modified, adotando a versão mais recente. Esse mecanismo é o que permite sincronização bidirecional segura entre TIPs, e ignorá-lo é a causa mais comum de loops de sincronização, armadilha documentada na nota 10 deste capítulo.

Os data markings (TLP como marking-definition) são vinculados aos objetos via object_marking_refs e devem ser respeitados em toda a cadeia: um bundle TLP AMBER não pode ser reexportado publicamente com os markings removidos. O bundle, por fim, é o envelope de transporte: uma lista de objetos que viaja pelo TAXII ou por arquivo. Um bundle bem formado inclui identity do produtor, markings apropriados e todos os objetos citados pelos relacionamentos, evitando referências órfãs que quebram a importação.

6. Modelando uma Intrusão em Grafo

O exemplo seguinte modela, em forma de grafo textual, uma intrusão fictícia de ransomware: campanha de phishing, loader, C2, exploração de CVE para escalação e ativação de criptolocker. A leitura em português de cada aresta facilita a conferência de coerência antes da serialização.

[identity--produtor]      Organização X, produtor da inteligência (TLP AMBER)
[campaign--phish-mai]     Campanha de phishing de maio de 2026
   | targets -> identity (setor financeiro brasileiro)
   | uses   -> attack-pattern (Phishing: Spearphishing Attachment)
   | delivers -> malware (loader LDR-2026)
[malware--ldr-2026]       Loader escrito em .NET
   | drops   -> malware (ransomware CRPT-2026)
   | beacons-to -> infrastructure (cluster C2)
   | exploits -> vulnerability (CVE de escalação local)
[indicator--dom-c2]       domínio cdn-updates-login.com
   | indicates -> malware (loader LDR-2026)
[indicator--hash-loader]  hash SHA-256 do loader
   | indicates -> malware (loader LDR-2026)
[infrastructure--c2]      Cluster de VPS com certificado autofirmado
   | controls -> malware (ransomware CRPT-2026)
[intrusion-set--fin]      Cluster de atividade financeira
   | attributed-to -> threat-actor (confiança moderada)
[campaign--phish-mai]     | attributed-to -> intrusion-set--fin (moderada)
[sighting--siem]          indicator--dom-c2 visto no SIEM em 2026-05-14

O mesmo grafo em bundle STIX serializa cada nó e aresta como objeto; o valor prático aparece na importação por uma plataforma como OpenCTI, que reconstrói a visão visual da intrusão e permite pivoting a partir de qualquer nó. A regra de fechamento é conferir completude: todo relacionamento referencia objetos presentes no mesmo bundle ou já publicados com o mesmo id, e todo objeto carrega marking compatível com o canal de compartilhamento escolhido.

7. Erros Comuns e Pontos de Atenção

Os erros abaixo aparecem com frequência em produtões reais e em feeds públicos, e cada um degrada a confiança do consumidor de forma silenciosa.

• Publicar indicator sem valid_until, o que faz o indicador viver para sempre nas ferramentas do consumidor e contaminar a telemetria com falsos positivos antigos.
• Usar threat-actor com atribuição fraca, quando o correto seria intrusion-set, transmitindo certeza que a evidência não sustenta.
• Confundir malware com tool, duplicando entidades e quebrando a correlação nas plataformas do consumidor.
• Escrever relacionamentos com direção invertida, como malware indicates indicator, semântica que nenhuma plataforma interpreta.
• Gerar SCOs com IDs aleatórios em vez de determinísticos, eliminando a deduplicação automática por conteúdo.
• Remover data markings no reexporto, violação de TLP que expõe o produtor e compromete a participação na comunidade.
• Criar referências órfãs no bundle, objetos citados por relacionamentos que não foram incluídos, provocando importações parciais silenciosas.

A disciplina coletiva é o que transforma STIX em infraestrutura de confiança: produtor cuidadoso gera consumidor confiante, e consumidor que devolve sightings e opiniões realimenta a qualidade da fonte. Esse circuito de reciprocidade é o mesmo argumento econômico do compartilhamento medido nas notas 01 e 02 do capítulo 22, agora operacionalizado em padrão aberto.

8. Integração com o Restante da Biblioteca

O catálogo desta nota sustenta as práticas de vários capítulos. Na coleta, o capítulo 02 usa SCOs como unidade de normalização no pipeline e no enriquecimento. Na produção, o capítulo 05 materializa atribuição e confiança nos campos confidence e nos relacionamentos attributed-to. No compartilhamento, as notas 05, 06, 08, 09 e 10 deste capítulo formam com esta nota o bloco completo de interoperabilidade STIX, TAXII, MISP e TIPs. No Framework CTH da seção 15, os controles PLT.3 (formatos de inteligência) e PLT.5 (TLP) dependem diretamente do vocabulário aqui consolidado, e a esteira INT.5 usa bundles como carga útil da orquestração end to end.