Resolução de Entidades e Correlação de Dados

Nota do capítulo 02 (Fontes de Dados e Coleta), que transforma indicadores normalizados em uma visão relacional do adversário.
Trata de entity resolution, grafos de relacionamentos com OpenCTI e Neo4j, resolução de infraestrutura compartilhada e correlação temporal e espacial.
Assume as chaves canônicas da nota 09 e entrega o contexto que sustenta análise, hunting e atribuição nas fases seguintes do estudo.

1. Contexto e Posicionamento na Biblioteca

Um indicador isolado diz pouco; o valor da inteligência está nas relações. Saber que um domínio resolve para um IP é quase neutro, mas saber que o mesmo domínio compartilha certificado TLS, registrante e nameserver com a infraestrutura usada por um grupo de ameaça monitorado muda por completo a leitura operacional. A resolução de entidades é o processo que decide quando registros distintos se referem à mesma entidade do mundo real, e a correlação de dados é o processo que revela relações significativas entre entidades diferentes, no tempo e no espaço de infraestrutura.

Na arquitetura da biblioteca, esta nota opera sobre a saída do pipeline (08) e da normalização (09), que garantem que o mesmo objeto ocupe uma única chave canônica. O resultado é a camada relacional consultada pelos capítulos de análise e produção de inteligência (05) e pelas hipóteses de hunting (06 e 07), além de materializar na prática o que a seção 15 descreve nos controles PLT.2 (OpenCTI) e CTI.6 (análise de TTPs). O objetivo prático é simples de enunciar e difícil de executar: responder a qual campanha, qual ator e qual infraestrutura este observável pertence, com evidências e grau de confiança.

2. Entity Resolution: Definição e Armadilhas Conceituais

Entity resolution é a disciplina de decidir que registros provenientes de fontes distintas representam a mesma entidade, mesmo quando descritos de forma diferente. Em CTI, a entidade pode ser um servidor de C2, uma família de malware, um ator ou uma campanha. O problema clássico tem duas direções: a fusão indevida (dois objetos diferentes tratados como um) e a fragmentação (o mesmo objeto espalhado em vários registros). As duas direções causam danos opostos: a fusão indevida atribui a um ator atividades que não são dele, e a fragmentação impede a visão de campanha que sustenta a priorização.

A diferença entre identidade e similaridade é o conceito central a dominar. Identidade se estabelece por chave canônica (a mesma SHA-256 de arquivo é o mesmo arquivo, sempre) e por evidência determinística. Similaridade é evidência probabilística (dois domínios parecidos provavelmente pertencem à mesma campanha) e deve resultar em vínculo com pontuação, nunca em fusão automática. Toda decisão de resolução deve ser registrada com a evidência que a sustentou, permitindo desfazer vínculos quando nova informação chegar, pois resolução de entidades é processo iterativo, não veredito imutável.

A temporalidade complica o quadro de forma subestimada. Infraestrutura muda de dono: um IP que serviu C2 do grupo A em 2023 pode pertencer a um provedor limpo em 2025, e relações gravadas sem janela temporal viram mentiras futuras. A prática recomendada é que todo relacionamento carregue primeiro visto, último visto e, quando possível, razão do encerramento do vínculo, alinhado ao ciclo de expiração por TTL da nota 09. Relacionamento sem janela temporal é dado incompleto, e o grafo precisa refletir isso explicitamente.

3. Grafos de Relacionamentos: OpenCTI e Neo4j

O modelo relacional de objetos STIX 2.1 mapeia naturalmente para grafos: os SDO (Stix Domain Objects), como Indicator, Malware, IntrusionSet, DomainName e IPv4-Addr, são nós, e os SRO (Stix Relationship Objects) são arestas tipadas, como indicates, resolves-to, communicates-with, uses e based-on. O OpenCTI constrói exatamente essa camada sobre um grafo subjacente, expõe a API GraphQL para leitura e escrita e permite consultas diretas no grafo para análises que a interface não cobre. O Neo4j, que sustenta o OpenCTI, oferece Cypher como linguagem de consulta, e dominar consultas mínimas de Cypher multiplica o valor da plataforma para o analista.

O exemplo abaixo mostra um relacionamento STIX 2.1 completo, com confiança e janela temporal, no formato que o pipeline deve produzir ao registrar que um domínio de C2 se comunica com seu endereço IP:

{
  "type": "relationship",
  "spec_version": "2.1",
  "id": "relationship--8c5a3f2b-7d41-4e0f-9b6a-2f1d3e5a7c90",
  "created": "2025-11-10T14:03:00.000Z",
  "modified": "2025-11-10T14:03:00.000Z",
  "relationship_type": "communicates-with",
  "source_ref": "domain-name--9f3b6c1e-8a2d-4f47-b5c0-1e2d3a4b5c6d",
  "target_ref": "ipv4-addr--3c7d9e2a-5b18-4a60-9f21-c8d4e6f0a1b3",
  "confidence": 65,
  "start_time": "2025-11-01T00:00:00.000Z",
  "stop_time": "2026-01-31T23:59:59.000Z",
  "description": "Domínio observado em beaconing resolve e comunica com o IP na janela declarada"
}

A consulta Cypher abaixo responde a uma pergunta operacional frequente: dado um indicador encontrado no ambiente, que outros indicadores apontam para o mesmo contexto de ameaça, com confiança mínima estabelecida. É a base de várias regras de pivotação usadas tanto na análise quanto no hunting orientado a IOC. Vale registrar que o OpenCTI também expõe esse tipo de resposta por interface, mas a consulta direta ao grafo permite filtrar por janela temporal e por confiança com precisão que a camada visual nem sempre oferece, além de servir de especificação para automatizar a pivotação dentro do próprio pipeline:

MATCH (i:Indicator {value: $valor})-[r1:indicates]->(o)
MATCH (o)<-[r2:indicates]-(i2:Indicator)
WHERE i.id <> i2.id AND i2.confidence >= 50
  AND coalesce(r2.last_seen, r2.created) >= datetime() - duration('P90D')
RETURN i2.value AS indicador_correlato, labels(o) AS contexto,
       i2.confidence AS confianca
ORDER BY i2.confidence DESC LIMIT 25;

Para o hunting retroativo, uma consulta complementar enumera a infraestrutura de um ator monitorado em janela recente, combinando o vínculo de uso com a proximidade temporal, o que alimenta watchlists e hipóteses do capítulo de hunting:

MATCH (s:IntrusionSet {name: $ator})-[u:uses]->(d:DomainName)
WHERE u.last_seen >= datetime() - duration('P180D')
OPTIONAL MATCH (d)-[c:resolves-to]->(ip:IPv4-Addr)
RETURN d.value AS dominio, ip.value AS endereco, u.last_seen AS visto_em;

4. Resolução de Infraestrutura Compartilhada

A resolução de infraestrutura compartilhada é o núcleo técnico da pivotação: dado um observável, descobrir com quem ele compartilha recursos e o que isso indica. As fontes de evidência clássicas são o RDAP (sucessor operacional do WHOIS, com dados de registrante e datas de registro), o passive DNS (histórico de resoluções domínio-IP), os certificados TLS visíveis em logs de Certificate Transparency (SHA-256, SANs, emitente), a vizinhança de rede por ASN e bloco, os nameservers e MX compartilhados e, com cautela legal, identificadores de rastreamento presentes em páginas de phishing, como IDs de analytics.

Cada evidência tem peso diferente porque o grau de compartilhamento natural varia muito. Duas páginas hospedadas na mesma CDN não revelam nada, pois milhões de sites compartilham essa infraestrutura; já o mesmo certificado TLS autofirmado com SAN único em dois domínios de campanha é evidência forte de operador comum. A tabela abaixo organiza as evidências usuais, o peso sugerido e a principal armadilha de cada uma, servindo de ponto de partida para uma política de pontuação local.

A política de decisão recomendada combina evidências somadas com exigência de independência: nenhum vínculo relevante deve se apoiar em uma única evidência de peso médio ou baixo. Como ponto de partida operacional, soma acima de 0,5 caracteriza candidato a correlação para revisão, soma acima de 0,7 caracteriza correlação forte que pode alimentar campanha e watchlist, e qualquer soma com evidência única nunca ultrapassa o patamar de candidato. Os pesos são calibrados com o histórico de acerto do próprio time, tema retomado na nota de qualidade (11).

5. Correlação Temporal e Espacial

A correlação temporal e a correlação espacial respondem perguntas diferentes e pedem instrumentos diferentes, e confundir as duas é erro de desenho comum. A tabela abaixo contrasta as duas abordagens, com os riscos característicos de cada uma e o uso operacional recomendado:

A correlação temporal procura significado na coincidência de eventos dentro de janelas definidas. Exemplos clássicos: domínio registrado três dias antes do primeiro beacon observado para ele; criação de conta de serviço seguida, em minutos, de autenticação vinda de ASN desconhecido; submissão de amostra em sandbox precedendo varredura de infraestrutura de destino pela mesma origem. A disciplina técnica está em definir janela e direção: janela muito larga cria coincidências falsas, e a direção importa, pois causa precede efeito em investigação, e o inverso só serve para descobrir preparação prévia.

A consulta abaixo exemplifica a correlação temporal entre falhas de autenticação e conexões de saída do mesmo usuário em janela de cinco minutos, padrão compatível com técnicas de execução após acesso inicial; o formato é SQL sobre eventos centralizados com timestamp normalizado em UTC:

SELECT a.usuario, a.host, a.evento AS autenticacao,
       c.destino, c.porta, c.timestamp AS conexao
FROM autenticacoes a
JOIN conexoes_rede c
  ON c.usuario = a.usuario
 AND c.timestamp BETWEEN a.timestamp - INTERVAL '5' MINUTE
                      AND a.timestamp + INTERVAL '5' MINUTE
WHERE a.evento = '4625'
  AND a.timestamp >= CURRENT_TIMESTAMP - INTERVAL '24' HOUR
ORDER BY a.timestamp, c.timestamp;

A correlação espacial, no contexto de CTI, é a sobreposição no espaço de infraestrutura: ASN, bloco de rede, país de hospedagem e coordenadas geográficas. O uso mais sólido é por ASN e bloco, que descrevem quem opera a rede; o país de registro do IP e a geolocalização de coordenada são o uso mais frágil, porque hospedagem, VPN e CDN fazem o tráfego aparecer onde o provedor está, e não onde o operador está. A regra prática é usar geografia para triagem e narrativa, nunca como evidência de atribuição, e preferir ASN, autônomo de origem e histórico de bloco para qualquer correlação com consequência operacional.

6. Falsas Correlações e Como Mitigá-las

As falsas correlações em CTI têm padrões repetidos e conhecidos, e conhecê-los é metade da defesa. Infraestrutura legítima compartilhada (CDN, nuvem, hospedagem barata) gera vizinhança falsa em massa; endereços IP reciclados carregam reputação velha para novos inquilinos; scanners de massa (os grandes serviços de varredura de internet) tocam praticamente todos os endereços públicos, criando sobreposição de contato que não significa relação; sinkholes e sandboxes aparecem no passive DNS como resolveu para, sem que nada disso seja infraestrutura do adversário; e feeds que republicam a mesma origem primária criam a impressão de confirmação independente onde há apenas eco.

A mitigação combina desenho e processo. No desenho: exigir janela temporal em todo relacionamento, exigir evidência independente para vínculos de consequência, manter listas de contexto (faixas de CDN e nuvem, ranges de sinkhole, ASN de scanners) para descontar peso das evidências ambientais, e distinguir eco de fonte independente na deduplicação da nota 09. No processo: toda correlação que gera consequência operacional (bloqueio, atribuição pública, abertura de incidente) passa por revisão humana documentada, com as evidências listadas e a possibilidade de desfazer o vínculo.

A pontuação proposta na seção 4 deve ser auditada por amostragem mensal: selecionar correlações fortes fechadas no período e verificar retrospectivamente quantas resistiram a nova informação. Essa auditoria alimenta os pesos e revela vieses sistemáticos, como evidências que pontuam alto e quase nunca se confirmam. Sem esse laço de retroalimentação, o sistema de pontuação congela em erros e a equipe aprende a ignorá-lo, o que é pior que não ter pontuação, porque consome tempo de análise com aparência de rigor.

7. Caso Prático: Correlacionando Infraestrutura de Campanha

Um caso prático fixa o método melhor que qualquer definição. Suponha que a triagem do SOC encontre o domínio de phishing "portal-financeiro-suporte.com" em uma mensagem capturada, e o analista de CTI precise decidir se trata de campanha conhecida e se há mais infraestrutura associada. O primeiro passo é verificar o TIP e o grafo: o domínio não existe como objeto, mas a busca por similaridade de certificado e por provedor de envio retorna dois domínios com alto grau de sobreposição de atributos, já ligados a uma IntrusionSet monitorada. O segundo passo é coletar evidências frescas: RDAP dos três domínios, certificados em logs de Certificate Transparency, passive DNS, bloco de rede e portas abertas no levantamento dos serviços de enriquecimento já integrados ao pipeline.

O terceiro passo é aplicar a política de pontuação da seção 4, documentando cada evidência com valor, peso e fonte. O exemplo abaixo mostra a ficha de correlação resultante, no formato que o time arquiva junto ao objeto de campanha no TIP:

Evidencia coletada                       Peso   Resultado
Certificado TLS (SHA-256) identico        0,35   sim, autofirmado com SAN exclusivo
Registrante RDAP (e-mail exclusivo)       0,30   sim, mesmo e-mail dos dois dominios
Mesmo /24 com portas 443 e 8443 abertas   0,15   sim, mesmo segmento de hospedagem
Nameserver especifico compartilhado       0,10   sim, par de NS fora de provedor popular
Passive DNS sobreposto na janela          0,10   nao, IPs de resolucao distintos
Soma ponderada                            0,90   correlacao forte, revisao humana exigida

O quarto passo é a decisão com registro: acima do limiar de correlação forte, o analista cria o objeto de campanha no OpenCTI, vincula os três domínios com relacionamentos tipados e janela temporal, conecta a campanha à IntrusionSet com confiança 70 e justifica cada aresta com referência às evidências da ficha. Em seguida, a retro-busca opera sobre as duas perguntas clássicas: os domínios correlatos já apareceram nos logs da organização (consulta ao SIEM por resolução e por acesso) e a infraestrutura do ator monitorado nos últimos 180 dias inclui algum destes valores (consulta Cypher da seção 3). O resultado, positivo ou negativo, entra no registro da campanha, e os domínios entram na watchlist de detecção com confiança e TTL da nota 09.

O valor do caso prático está no formato, mais que no resultado: a ficha de correlação com evidências, pesos e decisão é um artefato replicável, que pode virar playbook automatizado para os vínculos mecânicos, mantendo a revisão humana para os que terão consequência. Times que documentam correlações dessa forma constroem, ao longo dos meses, uma base de precedentes que calibra os pesos da política com dados próprios, exatamente o laço de auditoria descrito na seção 6.

8. Erros Comuns e Pontos de Atenção

O erro mais grave é usar correlação espacial geográfica como evidência de atribuição, prática que produziu historicamente conclusões absurdas baseadas em país de hospedagem. O segundo é gravar relacionamentos sem janela temporal, transformando o grafo em um depósito de vínculos permanentes entre objetos cuja relação já acabou há anos. O terceiro é a fusão automática por similaridade, discutida na nota 09, que no contexto de entidades transforma dois atores distintos em um só e contamina toda a produção analítica a jusante.

Erros operacionais complementares incluem: construir correlações sobre dados não canonizados, gerando grafos fragmentados; tratar o grafo como verdade sem registrar a evidência de cada aresta, impossibilitando auditoria; e deixar que o volume de dados de uma fonte dominante (por exemplo, um feed com milhões de relacionamentos de baixa confiança) ofusque as relações ricas de baixo volume, como as documentadas em relatórios analíticos. Cada aresta gerada por automatismo deve carregar origem, regra e confiança, distinguindo-se visualmente das arestas curadas por analista.

Um ponto de atenção frequentemente esquecido é o efeito do tempo de vida dos vínculos sobre a busca retroativa. Para o hunting, vínculos expirados continuam úteis como histórico e devem permanecer consultáveis com filtro de época; para a detecção automatizada, apenas vínculos ativos podem alimentar regras. Confluir os dois usos na mesma consulta é erro de desenho que gera tanto bloqueio por informação velha quanto caça que ignora histórico relevante, e a solução é modelar os dois caminhos de consumo de forma separada desde o início.

9. Integração com o Restante da Biblioteca

A camada relacional construída aqui alimenta diretamente o capítulo 05 (análise e produção de inteligência), onde campanhas e atores ganham narrativa, e os capítulos de hunting (06 e 07), onde hipóteses de pivot partem exatamente das relações documentadas nesta nota. No mapeamento com a seção 15, este material apoia PLT.2 (OpenCTI como plataforma de grafo), CTI.6 (análise de TTPs) e as técnicas de grouping e clustering (TH.7 e TH.9), que são, na essência, aplicações de entity resolution sobre observáveis e eventos.

A conexão com os capítulos de detecção é dupla: correlações fortes alimentam detecção automatizada por infraestrutura, e correlações propostas alimentam hipóteses de hunting com grau de confiança explícito, preservando a lógica da Pirâmide de Dor ao priorizar domínios e infraestrutura sobre artefatos voláteis. Como evolução de maturidade, o time deve aspirar a registrar no grafo não apenas relações técnicas, mas também relações de contexto analítico (campanha, motivação, alvo), com as evidências correspondentes, porque é essa camada de contexto que transforma o grafo de infraestrutura em inteligência utilizável por decisão, e não apenas em um mapa mais bonito de conexões.