Threat Intelligence Platforms (TIPs) - MISP, ThreatConnect

Nota 04 do capítulo 09 (Ferramentas e Plataformas), que trata a plataforma que organiza e distribui a inteligência consumida pelas caças das notas 01 a 03.
Detalha MISP e ThreatConnect, compara os dois e documenta a integração do TIP com SIEM, EDR e controles de bloqueio.
Dialoga com a nota 04 do capítulo 03 (plataformas de IOC), com os controles PLT.1 e PLT.3 do capítulo 15 e com o capítulo 10.

1. Contexto e Posicionamento na Biblioteca

Os capítulos 02 e 03 definiram as fontes de inteligência e o ciclo de vida dos indicadores; esta nota apresenta a plataforma que torna esse ciclo operável. Um TIP (Threat Intelligence Platform) é o sistema que centraliza indicadores e relatos de múltiplas fontes, deduplica, enriquece, pontua, distribui para as ferramentas de detecção e registra feedback de sighting. Sem TIP, o time de segurança administra feeds em planilha e copia indicadores para o firewall à mão, o que não escala e não deixa rastro de decisão. Sem disciplina de uso, por outro lado, o TIP vira depósito de indicadores vencidos que enche o SIEM de ruído.

Duas plataformas dominam a discussão prática e estruturam a nota: MISP, open source, padrão de facto para compartilhamento setorial e para programas que precisam de controle total da infraestrutura, e ThreatConnect, plataforma comercial com automação de playbooks e gestão de projetos de inteligência. A nota segue a lógica das anteriores: função primeiro, produtos depois, integração por último, com o fluxo completo de um indicador do feed até o bloqueio como fechamento.

2. A Função do TIP no Ciclo de Inteligência

Dentro do ciclo de inteligência do capítulo 01, o TIP ocupa o lado de processamento, análise e disseminação. Na entrada, ele conecta feeds comerciais, comunitários, compartilhamento setorial e produção interna do time de CTI, com controle de proveniência por fonte. No meio, ele deduplica indicadores idênticos de fontes diferentes, aplica enriquecimento com WHOIS, resolução passiva de DNS, reputação e sandbox, e mantém pontuação de confiança e validade por indicador. Na saída, ele distribui em formatos e canais que as ferramentas de detecção consomem, como exportações de lookup, feeds TAXII e integração por API.

O papel que o hunter consome é o de contexto consultável: ao encontrar infraestrutura suspeita em caça, o hunter pergunta ao TIP quem mais viu aquilo, quando apareceu, qual ator ou campanha está associado e qual o histórico de sightings. O papel que o hunter produz é o inverso: os achados de caça do capítulo 07, como domínios de C2 descobertos por beaconing, entram no TIP com proveniência interna e retornam como inteligência distribuída. Essa via de mão dupla é o que materializa o ciclo hunting-driven intelligence do controle INT.2 do capítulo 15.

A tabela abaixo mapeia cada etapa do ciclo de inteligência à função concreta do TIP e ao produto observável que a etapa deve gerar. Esse mapeamento serve de checklist de avaliação: uma plataforma que não entrega o produto observável de alguma etapa precisa compensar com integração, ou o ciclo fica furado naquele ponto.

3. MISP em Detalhe: Eventos, Atributos, Taxonomias e Galáxias

O MISP organiza o conteúdo em eventos, que são relatos com contexto, e em atributos, que são os indicadores individuais com tipo, categoria, distribuição e flag to_ids. Um evento de C2 típico carrega o domínio como ip-dst ou domain, o hash do binário, a observação de comportamento em texto livre e o vínculo com o ator. As taxonomias, como a MISP default, a Admiralty Scale para credibilidade e a TLP 2.0 para manuseio, são tags estruturadas aplicadas a eventos e atributos, e são a linguagem que permite filtrar o que circula. As galáxias complementam com clusters de conhecimento, como mitre-intrusion-set para atores e mitre-attack-pattern para técnicas, vinculando o evento ao vocabulário do ATT&CK.

A gestão de qualidade no MISP passa por três controles que o hunter precisa entender. O flag to_ids separa o indicador distribuído para bloqueio e alerta do indicador apenas contextual, e bloquear sem revisar esse flag é receita para bloquear CDN inteira. A distribuição em níveis, de 0 a 3, define com quem o evento circula, da organização à comunidade, e é o que permite respeitar TLP ao sincronizar. Os sightings registram quando o indicador foi visto no ambiente, e são o retorno que realimenta a pontuação das fontes, porque feed que nunca gera sighting útil perde peso.

Dois recursos avançados valem lugar no desenho de qualquer instância séria. Os MISP objects estruturam conjuntos de atributos relacionados, como um artefato de phishing com remetente, URL, hash e domínio na mesma chave, e substituem a colcha de atributos soltos quando o contexto importa. As warninglists, por sua vez, são listas de exclusão embutidas, com provedores de nuvem, registradores e domínios corporativos conhecidos, e são a defesa automática contra o clássico erro de tratar um IP de provedor global como indicador acionável. O hunter que recebe exportação do MISP deve confirmar que warninglists e filtros de tipo estão ativos na exportação, e não apenas na interface.

4. MISP: Feeds, Sincronização e API

O MISP ingere conteúdo por quatro caminhos complementares. Os feeds nativos são coleções remotas públicas ou privadas que o MISP sincroniza em agenda, como os feeds mantidos pela própria comunidade; a sincronização servidor a servidor conecta instâncias de ISAC e de parceiros com push, pull e filtros por tag; a API REST recebe produção interna do time de CTI e de automação; e a importação manual cobre relatos ad hoc. O exemplo abaixo busca via API os indicadores de tipo IP e domínio marcados como TLP amber nos últimos sete dias, consulta típica que alimenta a exportação para o SIEM:

curl -s -X POST https://misp.interno/attributes/restSearch \
  -H "Authorization: $MISP_API_KEY" -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "returnFormat": "json",
    "type": ["ip-dst", "domain"],
    "to_ids": 1,
    "tags": ["tlp:amber"],
    "last": "7d",
    "limit": 500
  }'

O desenho de sincronização merece as mesmas regras de qualquer pipeline de coleta: filtros por tag e por tipo evitam que a instância absorva volume que não atende aos PIRs da organização, e o agendamento define a latência máxima aceitável entre o evento do parceiro e o indicador disponível internamente. Para caça, o MISP ainda oferece consultas de contexto pela API, como histórico do atributo e sightings agregados, que transformam a plataforma em fonte de enriquecimento chamável por notebook ou por playbook do SOAR.

5. ThreatConnect: Owners, Playbooks e Batching

O ThreatConnect organiza o mundo em owners, que são os espaços de dados: a organização, comunidades de compartilhamento e assinaturas de provedores. Todo indicador, grupo, tarefa e documento pertence a um owner, e a permissão segue a adesão do usuário, o que permite um mesmo TIP servir ao SOC e à inteligência sem misturar o que circula. Indicadores carregam rating e confidence nativos, tags e atributos, e o histórico de cada item é auditável, o que atende programas com exigência formal de proveniência.

Os playbooks são o diferencial prático da plataforma: triggers de tipo app, webhook ou timer iniciam sequências de passos que enriquecem, deduplicam, notificam e propagam o indicador para integrações de destino. O batching, por sua vez, é o mecanismo de importação em lote via API: o cliente abre um job de batch, envia o lote de indicadores em JSON e o ThreatConnect processa deduplicando e aplicando as regras de associação do owner, como no esqueleto abaixo:

POST /v2/batch?owner=ACME&format=tc&attributeWriteType=append
body: job file com array de indicadores tipo Address e Host
POST /v2/batch/{jobId}  (dispara o processamento)
GET  /v2/batch/{jobId}  (consulta status e contagens)

Na prática, o batching é o caminho padrão para carregar a produção interna diária, como os IOCs extraídos de campanhas de phishing analisadas pelo time, enquanto os playbooks cobrem o fluxo contínuo, como enriquecer todo host novo no TIP e notificar o canal do SOC quando o rating cruza o limiar acordado. Os dois mecanismos coexistem sem conflito porque atendem ritmos diferentes: lote para volume com revisão, playbook para latência com reação.

A modelagem fina em ThreatConnect usa tags para campanhas e operações e atributos para campos estruturados, como fonte, descrição e data de primeiro visto, com a mesma disciplina de proveniência que o MISP cobra em distribuição. O ponto de atenção para o hunter é a política de rating e confidence: são dois números diferentes, rating é o julgamento de maliciosidade e confidence é a confiança na informação, e misturá-los na automação gera bloqueios de alta confiança em indicador medíocre.

6. Comparação e Critérios de Escolha

A tabela abaixo compara as duas plataformas sob a ótica de uso pelo programa de CTI e TH. A escolha real também envolve orçamento, requisitos de hospedagem e ecossistema setorial: programas que compartilham com ISAC cuja infraestrutura é MISP ganham muito ao rodar MISP, e organizações que já vivem no ecossistema do fornecedor avaliam o custo de integração do ThreatConnect.

Os dois cumprem a mesma função de fundo, e o erro de avaliação comum é decidir por recurso de demonstração em vez de por requisito: liste os PIRs, as fontes, os destinos de disseminação e o volume esperado, e a plataforma que atende com menos fricção aparece sozinha na comparação. A demonstração mostra o caminho feliz; o requisito escrito revela o caminho real de integração, de manutenção e de custo anual.

7. Integração do TIP com SIEM, EDR e Bloqueio

A integração do TIP com o restante do parque tem três formatos, e cada formato atende um consumo diferente. O formato lookup é o mais comum: o TIP exporta lookup table para o Splunk, reference set para o QRadar, índice de threat intelligence para o Elastic ou lista gerenciada para o EDR, e as consultas de detecção e de caça cruzam o tráfego com essa lista. O formato feed API é o inverso: SIEM e SOAR consultam o TIP por API em tempo de execução para enriquecer um evento específico, como no restSearch da seção 4. O formato push é o de bloqueio: o SOAR ou a própria integração do TIP propaga indicadores com flag de resposta para firewall, proxy e gestão de IOCs do EDR.

A autenticação segue o padrão de chave por integração, com rotação e escopo mínimos: chave de leitura para a integração do SIEM, chave de escrita restrita para o playbook que publica achados de caça, e nada de chave de administrador em automação. O registro de proveniência é o requisito que sobrevive a qualquer troca de ferramenta: todo indicador que entra no parque de detecção precisa carregar fonte, data, TLP e limiar de decisão, porque sem isso a auditoria de bloqueio do mês seguinte vira arqueologia.

No lado do SIEM, o consumo típico da lookup em caça cruza o tráfego do dia com o acervo de inteligência e conserva o contexto da fonte, como no exemplo abaixo em SPL sobre logs de proxy:

index=proxy earliest=-24h
| lookup intel_feed domain AS site OUTPUT source, tlp, confidence
| where isnotnull(source)
| stats count AS acessos, dc(src_ip) AS hosts BY site, source, tlp
| sort - hosts

O mesmo padrão roda no Elastic com o enrich processor ou com o termo de lookup em Lens, e no QRadar com reference set alimentado pela exportação do TIP. O que muda de plataforma para plataforma é o mecanismo; o que não pode mudar é o conteúdo: fonte, TLP e data de carga acompanhando o indicador em todos os destinos.

8. Do Feed ao Bloqueio: Fluxo Completo de um Indicador

O exemplo abaixo costura o ciclo com um caso concreto, o IP 203.0.113.87 publicado por um feed de infraestrutura de C2, o mesmo endereço usado nos exemplos de beaconing da biblioteca. Primeiro, o feed entra no MISP como feed agendado, e o atributo nasce com tag tlp:amber, flag to_ids e vínculo com a galáxia do ator. Segundo, o enriquecimento automático consulta WHOIS, resolução passiva e reputação, e a pontuação confirma a validade do indicador.

Terceiro, o export do MISP gera o lookup que o SIEM carrega, e a consulta de caça retrospectiva procura o indicador nos noventa dias de histórico:

index=firewall OR index=proxy dest_ip="203.0.113.87" earliest=-90d@d
| stats count AS conexoes, min(_time) AS primeiro, max(_time) AS ultimo
    BY src_ip
| sort - conexoes

Quarto, o resultado da caça registra sightings no MISP pela API, o que eleva a confiança do indicador e revela os hosts que falavam com o C2 antes da publicação do feed:

curl -s -X POST https://misp.interno/sightings/add \
  -H "Authorization: $MISP_API_KEY" -H "Content-Type: application/json" \
  -d '{"value":"203.0.113.87","source":"HUNT-2025-032","type":"1"}'

Quinto, o playbook do SOAR recebe o indicador com sighting confirmado, abre a tarefa de resposta com o contexto anexado e propaga o bloqueio para proxy e firewall com prazo de expiração definido. Sexto e último, o feedback fecha o ciclo: a seção de detecção permanente derivada do caso entra no catálogo Sigma, e o TIP mantém o indicador como contexto da campanha, mesmo depois da expiração do bloqueio.

O exemplo mostra por que o TIP é plataforma e não lista: em cada etapa o indicador carrega contexto, proveniência e decisão registrada. O mesmo fluxo em planilha perderia o sighting, o vínculo com a campanha e a rastreabilidade do bloqueio, e é exatamente essa rastreabilidade que o capítulo 10 usa para ligar inteligência e caça em evidência.

Note ainda o papel do TLP em cada etapa do fluxo: o feed chega como amber, a caça interna roda com o contexto completo porque ocorre dentro do perímetro de manuseio, o sighting registrado é interno e a exportação para bloqueio pode circular, porque ação de defesa não é redistribuição do relato. Quando o time quiser compartilhar o achado de volta, seja para o ISAC seja para o feed comunitário, o relato precisa ser reescrito como novo evento sem herdar restrições que não lhe pertencem, e é essa decisão de manuseio que a nota 05 do capítulo 15 e o controle PLT.5 disciplinam.

9. Erros Comuns e Pontos de Atenção

• Ingerir feeds sem filtros por PIR; efeito: TIP inchado, deduplicação custosa e exportação que enche o SIEM de ruído; correção: filtrar por tipo, tag e relevância setorial na entrada e revisar a lista de feeds por trimestre.
• Bloquear qualquer indicador com to_ids; efeito: bloqueio de CDN, de provedor de nuvem ou de domínio legítimo reaproveitado; correção: bloquear apenas indicadores revisados com contexto, e tratar o resto como filtro de caça.
• Ignorar expiração de indicadores; efeito: listas de bloqueio que só crescem e falsos positivos acumulados de infraestrutura reciclada; correção: política de expiração por tipo de IOC alinhada ao capítulo 03.
• Chave de administrador em automação; efeito: integração comprometida vira comprometimento do TIP inteiro; correção: chave por integração, escopo mínimo e rotação agendada.
• TIP sem retorno de sighting; efeito: pontuação das fontes desconectada da realidade e feeds ruins tratados como bons; correção: registrar sighting de toda detecção e de toda caça que confirma ou descarta o indicador.
• Tratar o TIP como depósito final; efeito: indicadores entram e nada circula, e a plataforma vira arquivário; correção: medir saída por destino, lookup, feed e bloqueio, como métrica do capítulo 11.
• Ignorar o TLP na sincronização; efeito: relato amber de parceiro circulando em feed público e quebra de confiança do compartilhamento; correção: filtros de tag TLP em todo push, pull e exportação, revisados por trimestre.
• Deixar a mesma infraestrutura virar indicador em dois eventos sem ligação; efeito: perda do agrupamento por campanha e análise que reinventa o vínculo a cada caso; correção: usar objects e referências entre eventos para a infraestrutura compartilhada.

10. Integração com o Restante da Biblioteca

Esta nota é a camada de inteligência do capítulo 09 e dialoga em três direções. Para trás, com a nota 04 do capítulo 03, que já apresentou MISP, OpenCTI e YETI como plataformas de gestão de IOC, e com o capítulo 02, que avaliou as fontes que o TIP ingere. Para o lado, com as notas 01 a 03 deste capítulo, cujas plataformas consomem os lookups e as APIs aqui descritos. Para frente, com o capítulo 10, que formaliza o ciclo integrado CTI e TH, e com os controles PLT.1, PLT.3 e PLT.4 do capítulo 15, que definem os requisitos de plataforma, formato e gestão de fontes.

Um ganho composto fecha a nota: meça o TIP pela saída e não pela entrada. O número que importa é quantos indicadores do acervo foram consumidos por detecção, por caça e por bloqueio no mês, com quantos sightings confirmados e quantos falsos positivos causados. Esse painel simples, alimentado pelos mesmos registros que o fluxo do feed ao bloqueio produz, é o que transforma o TIP em objeto de melhoria contínua em vez de caixa preta que ingere feeds.

O segundo ganho é de arquitetura: defina desde o início qual sistema é a fonte canônica de cada dado. O TIP é canônico para indicador e contexto, o SIEM para evento, o EDR para telemetria de endpoint e o SOAR para decisão executada; quando duas plataformas viram canônicas para o mesmo dado, a divergência aparece em produção no pior momento possível. Esse princípio, anotado no desenho do capítulo 10, evita a competição silenciosa entre TIP e SIEM que degrada ambos.