STIX 2.1 em Profundidade

Nota 05 do capítulo 22, que aprofunda o vocabulário estruturado de compartilhamento de inteligência de ameaças.
O foco é o modelo de dados do STIX 2.1: objetos de domínio, observáveis, relacionamentos, IDs e versionamento, com bundle completo comentado.
Dialoga com a nota de TAXII 2.1 desta mesma seção, que transporta estes objetos, e com as notas de MISP e OpenCTI da biblioteca.

1. Contexto e Posicionamento na Biblioteca

A biblioteca já apresentou o STIX (Structured Threat Information eXpression) como formato de intercâmbio no capítulo 02 e no controle PLT.3 da seção 15, no nível necessário para entender o ecossistema de compartilhamento. Esta nota desce para o interior do formato: quem escreve regras de ingestão, modela campanhas numa TIP (Threat Intelligence Platform) ou constrói automação que produz e consome inteligência precisa dominar o modelo de objetos na precisão do campo. O STIX 2.1 é a versão vigente da especificação do OASIS, e sua diferença central em relação à 2.0 é a elevação dos observáveis a objetos de primeira classe, o que permite representar a infraestrutura do adversário com grafos nativos e não mais como embutidos dentro de indicadores.

A nota dialoga diretamente com a de TAXII 2.1, que é o transporte para os objetos aqui descritos, e alimenta as plataformas de gerenciamento de inteligência da biblioteca: o MISP converte de e para STIX, e o OpenCTI foi desenhado sobre o modelo de dados do STIX 2.1, herdando seus tipos e relacionamentos. O objetivo prático é que o leitor saia daqui capaz de ler um bundle real sem ambiguidade, modelar uma campanha com os objetos corretos e produzir objetos que outras organizações consigam consumir sem perda de semântica.

2. O Modelo de Dados: Quatro Famílias de Objetos

O STIX 2.1 organiza os objetos em quatro famílias, e a confusão entre elas é a fonte mais comum de erros de modelagem. As SDOs (STIX Domain Objects) representam entidades de domínio da ameaça e carregam semântica analítica; as SCOs (STIX Cyber-observables) representam fatos técnicos atômicos sobre a infraestrutura, com propriedades específicas por tipo; as SROs (STIX Relationship Objects) ligam objetos entre si, na forma de relacionamentos e de object refs com destaque (sighting); e os SMOs (STIX Meta Objects) anotam os demais, com linguagem e definições de extensão. Tudo isso viaja dentro de um bundle, o contêiner sem identidade própria que agrupa objetos para transporte.

A regra de ouro de modelagem é separar fato de inferência. O fato técnico, um domínio resolve para um endereço IP, mora em SCOs conectadas por relacionamento do tipo resolves-to; a inferência analítica, que aquele domínio é infraestrutura de staging de um grupo, mora em SDOs e em seus atributos, como os labels e o campo description. Essa separação é o que permite que duas organizações com conclusões diferentes sobre a mesma infraestrutura compartilhem os fatos sem discórdia, e é a diferença conceitual mais importante em relação ao STIX 1.x, que misturava observável e interpretação dentro do mesmo objeto.

3. SDOs Essenciais para a Operação

Sete SDOs concentram o uso diário da operação, e cada uma tem campos obrigatórios que o produtor de inteligência precisa dominar. A tabela abaixo resume o papel de cada uma e os relacionamentos mais típicos que ela mantém.

A distinção entre threat-actor e intrusion-set é a que mais gera dúvida, e a especificação resolve: o threat-actor é quem age, com motivação e recursos; o intrusion-set é o conjunto de comportamento observado na intrusão, com intenção inferida do que aconteceu. Na prática de rastreamento, o intrusion-set é o clique de atribuição intermediário: você pode ter certeza de que uma atividade pertence ao conjunto X e apenas hipótese de que o conjunto X pertence ao ator Y, e o modelo reflete exatamente essa confiança com relacionamentos em cadeia. O report é o objeto que amarra tudo numa narrativa: sem ele, o bundle é uma coleção solta de itens; com ele, é inteligência, porque a análise é que dá contexto aos objetos referenciados.

4. SCOs: Observáveis 2.1 e Propriedades Customizadas

Os SCOs são a novidade estrutural da 2.1 e o motivo de a versão existir. Cada tipo de observável tem propriedades próprias definidas pela especificação, o file tem hashes, size e name, o ipv4-addr tem value, o network-traffic tem src_ref, dst_ref, protocols e portas, e o email-message tem is_multipart e referências para cabeçalho e corpo. Os SCOs não têm campos de ciclo de vida analítico como created_by_ref ou revoked; eles são fatos, e a interpretação fica nos objetos que os referenciam. Essa separação permite grafo de infraestrutura adversária nativo, o que conecta esta nota à análise de infraestrutura do capítulo 03.

Quando a especificação não cobre um campo, o STIX 2.1 define convenção de propriedades customizadas, e a disciplina aqui decide a interoperabilidade. O prefixo x_ marca propriedade customizada dentro de objeto existente, como x_mitre_platforms no attack-pattern do MITRE, e o extension-definition é o mecanismo formal para criar tipos novos ou estender tipos existentes de forma declarável. As regras de bom vizinho são diretas: nunca sobrescrever propriedade da especificação, documentar toda extensão com URL descritiva e preferir o prefixo com identificador de organização, porque x_acme_internal_score deixa claro para o consumidor que aquele campo é interno da ACME e pode ser ignorado sem perda.

5. IDs Determinísticos e Versionamento

O STIX 2.1 define dois esquemas de identificador, e a diferença é o que permite deduplicação confiável. As SDOs, SROs e SMOs usam UUIDv4 aleatório, e a identidade do objeto é o par type e UUID; as SCOs usam UUIDv5 determinístico, derivado das propriedades do próprio observável, de forma que o mesmo fato técnico produza sempre o mesmo ID, independentemente de quem o observou. É esse determinismo que permite que duas organizações, sem combinar nada, descubram que estão falando do mesmo endereço IP ou do mesmo hash, e é por isso que os grafos de infraestrutura compartilhados funcionam na prática.

O versionamento do objeto usa o par de propriedades created e modified, e a regra é simples e rigorosa: criar uma nova versão de um objeto significa reemitir o objeto com o mesmo ID e novo modified, com as alterações aplicadas. O consumidor mantém a versão de modified mais recente e pode auditar a evolução. O campo revoked, quando verdadeiro, marca o objeto como permanentemente revogado e não mais confiável, o que é diferente de expirado: o indicator tem valid_until que encerra sua utilidade de detecção, e revoked que encerra sua validade como inteligência. Granularidade de atualização importa: alterar a descrição de um threat-actor não requer novo objeto, requer nova versão, e o correto uso de modified é o que separa histórico auditável de reescrita silenciosa.

6. Padrões de Relacionamento

Os relacionamentos têm vocabulário controlado, com origem, tipo e destino definidos pela especificação por combinação de tipos, e a adesão ao vocabulário é o que faz o grafo do consumidor ser navegável. A tabela abaixo lista os padrões mais usados na operação, com a leitura semântica de cada um.

Dois cuidados de modelagem preservam a utilidade do grafo. O primeiro é nunca usar related-to quando existe relacionamento específico, porque o vocabulário específico é o que permite consulta semântica, como todos os alvos dos intrusion-sets que usam a técnica X. O segundo é resistir à tentação de inventar verbos: o consumidor genérico ignora relacionamento desconhecido e o grafo perde arestas silenciosamente; quando falta vocabulário, a descrição do relacionamento e a extensão formal são o caminho, não o verbo improvisado. O sighting merece nota própria: ele registra a observação concreta de um objeto, como a vez em que o indicador casou com telemetria, e é a aresta que liga inteligência compartilhada a evidência produzida internamente.

7. Exemplo de Bundle Completo Comentado

O bundle a seguir modela um cenário completo e pequeno: um relatório de campanha de phishing com infraestrutura, indicador, técnica e grupo. Os comentários com duas barras são ilustrativos para o estudo e não fazem parte da sintaxe JSON, devendo ser removidos em produção.

{
  "type": "bundle",
  "id": "bundle--0f5d4a3c-8a2e-4b7e-9c1d-6a3f2e8b9c04",
  "objects": [
    {
      "type": "report",
      "spec_version": "2.1",
      "id": "report--c1e9a2b4-3d5f-4a6b-8c9d-0e1f2a3b4c5d",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "name": "Campanha de phishing contra o setor financeiro de fevereiro de 2026",
      "published": "2026-02-02T18:00:00.000Z",
      "report_types": ["threat-report"],
      "labels": ["phishing", "credential-harvesting"],
      "object_refs": [
        "threat-actor--a1b2c3d4-0000-4000-8000-000000000001",
        "intrusion-set--b2c3d4e5-0000-4000-8000-000000000002",
        "attack-pattern--c3d4e5f6-0000-4000-8000-000000000003",
        "malware--d4e5f6a7-0000-4000-8000-000000000004",
        "indicator--e5f6a7b8-0000-4000-8000-000000000005",
        "domain-name--f6a7b8c9-0000-4000-8000-000000000006"
      ],
      "description": "Analise consolidada da campanha, com infraestrutura registrada em dominio novo e coleta de credenciais em portal falso."
    },
    {
      "type": "threat-actor",
      "spec_version": "2.1",
      "id": "threat-actor--a1b2c3d4-0000-4000-8000-000000000001",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "name": "Grupo Litoral",
      "threat_actor_types": ["crime-syndicate"],
      "motivations": ["financial-gain"],
      "description": "Ator de ganho financeiro focado em bancos da regiao."
    },
    {
      "type": "intrusion-set",
      "spec_version": "2.1",
      "id": "intrusion-set--b2c3d4e5-0000-4000-8000-000000000002",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "name": "Operacao Maré",
      "description": "Atividade de phishing persistente com portal falso de home banking."
    },
    {
      "type": "attack-pattern",
      "spec_version": "2.1",
      "id": "attack-pattern--c3d4e5f6-0000-4000-8000-000000000003",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "name": "Spearphishing Link",
      "external_references": [
        {"source_name": "mitre-attack", "external_id": "T1566.002", "url": "https://attack.mitre.org/techniques/T1566/002/"}
      ],
      "kill_chain_phases": [{"kill_chain_name": "mitre-attack", "phase_name": "initial-access"}]
    },
    {
      "type": "malware",
      "spec_version": "2.1",
      "id": "malware--d4e5f6a7-0000-4000-8000-000000000004",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "name": "FerryLoader",
      "is_family": false,
      "malware_types": ["downloader"],
      "description": "Loader entregue pelo link de phishing, coleta credenciais do navegador."
    },
    {
      "type": "indicator",
      "spec_version": "2.1",
      "id": "indicator--e5f6a7b8-0000-4000-8000-000000000005",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "name": "Dominio de portal falso",
      "indicator_types": ["malicious-activity"],
      "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"
    },
    {
      "type": "domain-name",
      "spec_version": "2.1",
      "id": "domain-name--f6a7b8c9-0000-4000-8000-000000000006",
      "value": "portal-banco-seguro.com"
    },
    {
      "type": "relationship",
      "spec_version": "2.1",
      "id": "relationship--11223344-0000-4000-8000-000000000007",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "relationship_type": "attributed-to",
      "source_ref": "intrusion-set--b2c3d4e5-0000-4000-8000-000000000002",
      "target_ref": "threat-actor--a1b2c3d4-0000-4000-8000-000000000001",
      "description": "Confianca media: infraestrutura e TTPs coincidem com operacoes anteriores."
    },
    {
      "type": "relationship",
      "spec_version": "2.1",
      "id": "relationship--22334455-0000-4000-8000-000000000008",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "relationship_type": "uses",
      "source_ref": "intrusion-set--b2c3d4e5-0000-4000-8000-000000000002",
      "target_ref": "attack-pattern--c3d4e5f6-0000-4000-8000-000000000003"
    },
    {
      "type": "relationship",
      "spec_version": "2.1",
      "id": "relationship--33445566-0000-4000-8000-000000000009",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "relationship_type": "delivers",
      "source_ref": "attack-pattern--c3d4e5f6-0000-4000-8000-000000000003",
      "target_ref": "malware--d4e5f6a7-0000-4000-8000-000000000004"
    },
    {
      "type": "relationship",
      "spec_version": "2.1",
      "id": "relationship--44556677-0000-4000-8000-00000000000a",
      "created": "2026-02-02T18:00:00.000Z",
      "modified": "2026-02-02T18:00:00.000Z",
      "relationship_type": "indicates",
      "source_ref": "indicator--e5f6a7b8-0000-4000-8000-000000000005",
      "target_ref": "malware--d4e5f6a7-0000-4000-8000-000000000004"
    }
  ]
}

A leitura do bundle mostra o modelo em funcionamento: o report referencia os objetos que analisa, a cadeia de relacionamentos constrói o grafo atribuição, técnica, entrega, carga e o indicator aponta para o malware enquanto o domain-name carrega o fato técnico puro. Note que o ID do domain-name em produção seria UUIDv5 determinístico derivado do valor do domínio, e não o UUIDv4 de exemplo; em ambiente real, qualquer consumidor recalculando o UUIDv5 do valor portal-banco-seguro.com chegaria ao mesmo identificador e fundiria os grafos sem esforço adicional.

8. Erros Comuns e Pontos de Atenção

• Produzir SCOs soltos sem nenhum objeto analítico: coleção de fatos sem SDO nem report é telemetria, e não inteligência; o contexto é o produto, o observável é o insumo.
• Inventar propriedades fora da convenção: campo sem x_ e sem extension-definition quebra parsers estritos e exclui a organização do intercâmbio sério.
• Confundir valid_until com revoked: expiração encerra a utilidade de detecção do indicador; revogação encerra a validade do objeto inteiro e é permanente.
• Criar nova versão com ID novo: alteração de conteúdo em SDO é nova versão com mesmo ID e novo modified; objeto novo com ID novo é outra entidade, e o grafo do consumidor se fragmenta.
• Usar related-to como atalho: verbo genérico destrói a navegabilidade semântica do grafo; escolher o relacionamento específico do vocabulário é o trabalho de modelagem.
• Embutir observável dentro de texto: descrição com o domínio citado em prosa não é observável; o fato técnico mora em SCO conectado, e não em parágrafo.
• Ignorar spec_version no objeto: bundles 2.1 com objetos sem spec_version ambiguidam o comportamento de campos novos, como granular markings e SCO de primeira classe.

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 via ISACs e plataformas é o contexto de uso, e a qualidade de fonte do capítulo se traduz aqui em metadados de confiança e origem.
• Capítulo 03: os indicadores de comprometimento ganham estrutura formal no SDO indicator, com o ciclo de vida de criação, validação e expiração mapeado em valid_from e valid_until.
• Capítulo 05: a análise de campanhas e a análise de links são exatamente as operações que o grafo de objetos STIX materializa, e a atribuição com incerteza aparece na cadeia intrusion-set para threat-actor.
• Capítulo 22: o TAXII 2.1 transporta estes bundles, e o MISP e o OpenCTI da biblioteca consomem e produzem este modelo em operação.

A métrica que avalia a maturidade de produção é a proporção de objetos emitidos com relacionamentos semânticos válidos e com report de contexto, e não apenas indicadores planos. Consumir STIX 2.1 bem é sempre possível; produzir bem é o que faz a organização sair de consumadora de feeds para parceira de troca, e é esse salto que as notas do capítulo 22 sustentam.