Eventos, Objetos e Atributos MISP

Nota do Capítulo 22, Compartilhamento e Colaboração.
Detalha o modelo de dados do MISP: eventos, atributos, objetos, galáxias, clusters, taxonomias, níveis de distribuição e sharing groups, com um evento estruturado descrito campo a campo.
Dialoga com o controle PLT.1 do capítulo 15, com a nota de Políticas de Compartilhamento deste capítulo e com a nota de Interoperabilidade entre TIPs, que converte este modelo em STIX 2.1.

1. Contexto e Posicionamento na Biblioteca

O MISP estrutura toda inteligência técnica em um modelo de dados simples e previsível, e é esse modelo que permite a uma comunidade com dezenas de organizações trocar informação sem renegociar formato a cada evento. Sem domínio do modelo, o analista cria eventos mal classificados, atributos sem contexto e tags inconsistentes, e o dano só aparece meses depois, quando as exportações para SIEM e EDR já estão contaminadas. Esta nota detalha cada bloco do modelo e fecha com um evento real descrito campo a campo, funcionando como referência de consulta para todo o capítulo.

O posicionamento na biblioteca é o de camada técnica do compartilhamento. As notas anteriores do capítulo trataram de feeds e fontes, esta trata do objeto efetivamente trocado, e a nota de políticas trata das regras que governam a troca. O modelo dialoga diretamente com o controle PLT.1 do Framework CTH, que posiciona o MISP como hub operacional, e com a interoperabilidade entre TIPs, que mapeia estes objetos para grafos STIX 2.1 consumidos pelo OpenCTI e por plataformas comerciais.

2. Eventos: a Unidade de Agregação de Contexto

O evento é o agregador central do MISP e conta uma história: uma campanha de phishing, um incidente interno, a leitura estruturada de um relatório de terceiros. Todo evento carrega metadados que definem confiança, maturidade analítica e alcance de disseminação, e são esses metadados que os sincronizadores respeitam ao propagar conteúdo entre instâncias. A tabela a seguir resume os campos essenciais que o analista precisa dominar antes de criar o primeiro evento.

O nível de ameaça e o estágio de análise operam em conjunto e costumam ser mal usados em bases reais. Um evento em initial nunca deveria estar published, porque o estágio indica que a análise ainda não fechou; e um evento de campanha ampla com threat_level_id 1 exige justificativa, porque força priorização automática nos SOC que consomem o feed. A disciplina mínima recomendada é publicar apenas eventos em ongoing maduro ou completed, com nível de ameaça calibrado pela relevância da campanha para o setor, e nunca pela ansiedade do analista.

3. Atributos: Categorias, Tipos e Semântica de Detecção

O atributo é a unidade atômica de detecção e herda o contexto do evento em que vive. Cada atributo combina uma categoria, que descreve onde o valor aparece na cadeia de ataque, com um tipo, que descreve o formato do valor, e carrega a flag to_ids, que decide se o valor pode virar alerta automático nos consumidores. A tabela a seguir apresenta o recorte de categorias e tipos mais usado em operação, suficiente para o fluxo tático diário.

A flag to_ids merece tratamento conservador, porque é ela que transforma o atributo em material de alerta na cadeia de consumo. IOCs de infraestrutura dedicada, como domínios recém-registrados de uma campanha, são bons candidatos; hashes de documentos legítimos mal identificados, URLs de serviços públicos e filenames genéricos devem permanecer fora, sob pena de inundar a fila de triagem de toda a comunidade. Como regra editorial, todo atributo to_ids precisa de comment explicando por que merece alertar, e a disciplina de expiração definida no capítulo sobre ciclo de vida de IOCs se aplica integralmente a cada valor criado.

4. Objetos MISP: Modelagem de Relações Compostas

Um único atributo raramente descreve um fenômeno complexo, e é para isso que existem os objetos MISP: templates que agrupam múltiplos atributos relacionados com relações nomeadas entre eles. O objeto file carrega filename, md5, sha256 e size-in-bytes no mesmo pacote; o objeto network-connection descreve uma conexão inteira com ip-dst, port, hostname e protocol; o objeto email modela remetente, assunto, anexo e infraestrutura de envio em uma única unidade correlacionável. A vantagem aparece na correlação: os valores continuam sendo atributos detectáveis, mas ganham relações explícitas, como dropped-by ou communicates-with, que permitem ao OpenCTI reconstruir grafos de ataque sem inferência.

O trecho abaixo mostra a estrutura conceitual de um objeto network-connection com seus atributos e relações, formato que serve de guia para modelagem manual de fenômenos sem template pronto.

{
  "name": "network-connection",
  "Attribute": [
    {"object_relation": "ip-src", "type": "ip-src", "value": "198.51.100.24"},
    {"object_relation": "ip-dst", "type": "ip-dst", "value": "203.0.113.77"},
    {"object_relation": "dst-port", "type": "port", "value": "443"},
    {"object_relation": "hostname-dst", "type": "hostname", "value": "cdn-metrics.example.xyz"},
    {"object_relation": "protocol", "type": "text", "value": "tcp"}
  ]
}

Quando não existe template adequado, a prática recomendada é consultar o repositório de templates antes de inventar, porque objetos customizados quebram a correlação entre instâncias. Se a invenção for inevitável, o template deve ser documentado internamente com relações de nomes estáveis, para que o grafo gerado por outra instância continue interpretável. Objetos mal modelados são uma das principais fontes de ruído em sincronizações com OpenCTI, tema aprofundado na nota de interoperabilidade deste capítulo.

5. Galáxias, Clusters e Taxonomias

Galáxias são bibliotecas de conhecimento estruturado que o MISP carrega de fábrica e anexa a eventos na forma de clusters. A galáxia mitre-attack permite rotular eventos com técnicas e táticas ATT&CK; as galáxias threat-actor e malware trazem dossiês de atores e famílias com sinônimos normalizados; a galáxia sigma referencia regras de detecção já escritas. Anexar o cluster correto substitui um parágrafo de contexto em texto livre por um objeto indexável, que ferramentas downstream interpretam sem processamento de linguagem, e conecta o evento diretamente às métricas de cobertura do capítulo 18.

Taxonomias são vocabulários de tags simples, e o par formado por tlp e admiralty-scale constitui o núcleo mínimo de qualquer instância. A taxonomia tlp carrega o protocolo de compartilhamento detalhado na próxima nota; a admiralty-scale transporta a escala de confiabilidade de fonte e credibilidade de informação, ligando esta nota ao capítulo 5 da biblioteca. Outras taxonomias de valor imediato incluem event-class para classificar o fenômeno e vocabulários setoriais mantidos por CSIRTs nacionais. Tags livres existem, mas a política interna deve exigir que toda tag livre recorrente seja candidata a virar entrada de taxonomia própria, revisada e publicada para a comunidade de consumo.

6. Distribuição, Sharing Groups e Regras de Propagação

A distribuição controla o alcance de eventos e atributos e é o mecanismo primário de controle de vazamento da plataforma. O nível 0 restringe à organização local; o 1 alcança a comunidade da instância, incluindo descendentes diretos; o 2 alcança comunidades conectadas por sincronização; o 3 alcança todas as comunidades; e o nível 4 delega o controle ao sharing group, o mecanismo fino da plataforma. Eventos e atributos carregam distribuição própria, e o padrão seguro é restringir no evento e abrir apenas os atributos de baixa sensibilidade que valem disseminação ampla.

O sharing group define explicitamente a lista de organizações e instâncias destinatárias, com papéis de leitura e de redistribuição separados, e é a resposta correta para consórcios fechados, comunidades setoriais e acordos bilaterais. Sincronizações respeitam distribuição e sharing groups por design, mas o operador ainda configura filtros de push e pull por tag para impedir, por exemplo, que conteúdo tlp:amber ou tlp:red propague para servidores de comunidade ampla. A tabela seguinte resume a decisão prática de alcance no momento da criação.

7. Exemplo de Evento Estruturado, Campo a Campo

O evento abaixo modela uma campanha de phishing que entrega um loader via anexo com macro, cenário recorrente contra emissores financeiros. O JSON está podado para caber em referência, mas preserva todos os campos de decisão, e as tabelas seguintes explicam cada bloco.

{
  "Event": {
    "uuid": "5f3a1c9e-8b7d-4e2a-9c1d-0b6f4a2e8d10",
    "info": "Phishing setor financeiro: anexo com macro entrega loader com C2 em domínio novo",
    "date": "2026-01-14",
    "threat_level_id": "2",
    "analysis": "2",
    "published": true,
    "distribution": "3",
    "sharing_group_id": "0",
    "Tag": [
      {"name": "tlp:green"},
      {"name": "admiralty-scale:source-reliability=\"B\""},
      {"name": "misp-threat-actor=\"FIN7\""},
      {"name": "mitre-attack:attack-pattern=\"T1566.001\""}
    ],
    "Attribute": [
      {"category": "Payload delivery", "type": "email-src",
       "value": "faturamento@cobrancas-financa.example",
       "to_ids": false, "distribution": "3",
       "comment": "Remetente forjado, sem envio ativo observado"},
      {"category": "Payload installation", "type": "sha256",
       "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
       "to_ids": true, "distribution": "3",
       "comment": "Loader em anexo de macro, confirmado em sandbox"},
      {"category": "Network activity", "type": "domain",
       "value": "cdn-metrics.example.xyz",
       "to_ids": true, "distribution": "3",
       "comment": "C2 com beacon HTTPS a cada 300 segundos"}
    ]
  }
}

A leitura correta desse evento por um consumidor é imediata: bloquear e alertar sobre o hash e o domínio, usar o remetente como contexto, mapear a técnica T1566.001 no heat map de cobertura e, havendo suspeita, puxar a caça de beacon HTTPS com janela de 300 segundos. É exatamente essa produtividade que separa um evento bem modelado de um descarte de valores soltos.

8. Erros Comuns e Pontos de Atenção

Erros de modelagem se acumulam silenciosamente e cobram juros na fase de consumo, quando o custo de correção é alto. Os padrões mais frequentes em auditorias de instâncias reais são os seguintes:

• Evento sem contexto: empilhar dezenas de atributos em um evento genérico chamado IOCs diversos, sem info descritivo, sem galáxia e sem data coerente, o que torna a correlação impossível.
• to_ids indiscriminado: marcar filenames genéricos, IPs de serviços legítimos e valores de sandbox como alertáveis, transferindo ruído para todos os consumidores.
• Tags livres sem taxonomia: usar vocabulário pessoal que ninguém consegue filtrar, quebrando dashboards e regras de sincronização baseadas em tag.
• Distribuição relaxada por comodidade: criar eventos com distribution 3 e depender do TLP sozinho, sem notar que atributos sensíveis escorreram junto.
• Galáxias ausentes ou duplicadas: não anexar clusters ATT&CK, ou anexar o mesmo cluster escrito de formas diferentes, fragmentando as métricas de cobertura.
• Sharing group substituído por convite manual: enviar CSV por e-mail em vez de formalizar o grupo na plataforma, perdendo auditoria e controle de redistribuição.

A atenção central é tratar o modelo de dados como contrato editorial da comunidade. Cada campo tem semântica acordada, e a qualidade do compartilhamento é a soma da disciplina individual na criação de eventos, porque nenhum filtro downstream recupera contexto que nunca existiu.

9. Integração com o Restante da Biblioteca

A nota de Políticas de Compartilhamento e FIRST IEP define os rótulos TLP que aparecem aqui como tags e formaliza o contrato organizacional por nível. A nota de Validação e Interoperabilidade entre TIPs mapeia este modelo para STIX 2.1 e OpenCTI, mostrando como eventos, objetos e galáxias viram observables, SDOs e relações em grafo. Os controles PLT.1 e PLT.3 do capítulo 15 operam o MISP com os fluxos de ingestão e exportação aqui descritos, e o PLT.5 aplica as políticas desta sequência ao compartilhamento operacional.

Para o lado de hunting, os atributos e objetos alimentam as caças baseadas em IOC do capítulo 10, e os clusters da galáxia mitre-attack conectam eventos a hipóteses priorizadas por frameworks como THRIVE e TaHiTI no capítulo 23. O ciclo de vida e a expiração de IOCs do capítulo 3 completam a imagem, definindo quando atributos to_ids saem da rotação e o que permanece como contexto histórico no evento.