PLT.1 - Plataforma de Compartilhamento de Inteligência (MISP)

Controle PLT.1 do grupo PLT (Plataformas de Inteligência de Ameaças) do Framework CTH, derivado do Capítulo 8 do PDF de referência. Posiciona o MISP (Malware Information Sharing Platform) como hub operacional de gestão de indicadores de comprometimento e de disseminação tática dentro do programa integrado de CTI e Threat Hunting. O controle sustenta DAT, INS e AUT ao transformar listas dispersas de IOCs em um fluxo automatizado, correlacionado e distribuído para SIEM e EDR.

1. Contexto e Posicionamento no Framework CTH

O MISP é a plataforma open source de referência para armazenar, classificar e compartilhar IOCs e produtos de inteligência técnica. Sem um ponto central de gestão, a organização opera com listas estáticas em planilhas, perde a correlação entre indicadores de fontes distintas e não consegue automatizar a entrega de inteligência para as ferramentas de detecção. O Framework CTH trata esse controle como pré-requisito para a operação tática do programa, porque ele converte a coleta de DAT em material acionável pelo SOC.

Dentro do grupo PLT, o MISP cobre a função de compartilhamento e gestão de indicadores, enquanto o controle PLT.2 cobre a função de conhecimento analítico em OpenCTI e o PLT.4 cobre a governança das fontes que abastecem ambos. Essa divisão evita que a equipe force uma única ferramenta a cumprir propósitos incompatíveis. A implantação recomendada é uma instância dedicada, em infraestrutura própria, com backup diário, HTTPS obrigatório e autenticação multifator, acessível apenas a usuários autorizados de CTI e SOC.

2. Conceitos Centrais do MISP

A modelagem do MISP gira em torno de objetos simples e previsíveis, o que facilita a automação. Dominar esses conceitos evita a criação de eventos mal classificados, que depois poluem as exportações para o SIEM. A tabela a seguir resume o vocabulário mínimo para operar a plataforma com disciplina.

2.1 Níveis de Distribuição de Atributos

Cada evento e cada atributo carrega um nível de distribuição próprio, herdado quando configurado como novo. Esse controle granular é o que permite publicar um evento internamente sem expor atributos sensíveis. Os níveis possuem semântica fixa e devem ser respeitados pelas chaves de sincronização.

3. Feeds e Sincronização entre Instâncias

O MISP opera com feeds de terceiros, como abuse.ch (MalwareBazaar, URLhaus, Feodo Tracker), AlienVault OTX e Cisco Talos, além de feeds personalizados. Em modo de cache, a instância guarda os hashes dos itens remotos e só baixa o conteúdo quando um atributo local corresponde, o que reduz a ingestão de ruído. A configuração mínima sugerida pelo Framework CTH é de dois feeds públicos de alta confiabilidade no nível Básico, com avaliação de qualidade posterior sob o controle PLT.4.

A sincronização entre instâncias ocorre em dois modos complementares. No modo pull, a instância local busca eventos de um servidor remoto conforme filtros por tag, organização e TLP. No modo push, a instância local envia eventos aprovados para o servidor remoto, respeitando as regras de publicação definidas no PLT.5. Grupos de trabalho e ISACs operam dessa forma, com filtros que bloqueiam TLP:RED e automatizam o tráfego de conteúdo TLP:CLEAR e TLP:GREEN.

4. Fluxo Típico de Operação

O fluxo operacional segue uma sequência estável que deve estar documentada como playbook do CTI. Cada etapa tem dono claro e critério de saída, evitando que a base cresça com material não validado. A sequência recomendada é a seguinte:

1. Ingestão de feeds e de eventos sincronizados, com labels automáticos por fonte.
2. Deduplicação baseada em correlação de valores idênticos, que a plataforma executa ao criar atributos.
3. Correlação interna, que liga o novo atributo a eventos anteriores e revela recorrência de campanha.
4. Enriquecimento por módulos, com consultas a serviços de reputação, WHOIS e sandbox.
5. Triagem analítica, que ajusta falsos positivos, corrige contexto incompleto e aplica taxonomias.
6. Publicação, que libera o evento para exportação nos formatos de consumo dos controles de detecção.

A exportação é o produto final do fluxo e precisa chegar em formato que cada consumidor aceita sem retrabalho. Os formatos usuais cobrem JSON completo para o OpenCTI, listas de valores para blocagem no proxy, regras Suricata e Snort para o NDR e CSV filtrado por tipo para o SIEM. O trecho abaixo ilustra consultas REST comuns usadas para alimentar o SIEM e para produção de regras de rede.

# Indicadores publicados, marcados to_ids, em JSON para ingestão no SIEM
curl -s -H "Authorization: ${MISP_KEY}" \
  "https://misp.interno/attributes/restSearch/json/published:1/to_ids:1/limit:5000"

# Regras Suricata geradas a partir dos mesmos atributos, para NDR
curl -s -H "Authorization: ${MISP_KEY}" \
  "https://misp.interno/events/restSearch/export/suricata/published:1"

5. APIs e Automação

A API REST do MISP permite automatizar todo o ciclo, da criação de eventos à consulta de indicadores durante a triagem de alertas. O SDK PyMISP encapsula as chamadas e é a via recomendada para integrações com SOAR e playbooks do SOC. O exemplo abaixo cria um evento de phishing com distribuição restrita e atributo marcado para detecção.

from pymisp import PyMISP, MISPEvent

misp = PyMISP("https://misp.interno", "CHAVE_API", False)

evento = MISPEvent()
evento.info = "Campanha de phishing contra portal de cobrança"
evento.distribution = 0            # Apenas organização local
evento.threat_level_id = 3         # Baixo
evento.analysis = 2                # Concluído
evento.add_tag("tlp:amber")
evento.add_tag("phishing")

atributo = evento.add_attribute("domain", "portal-cobranca-exemplo.example", to_ids=True)
misp.add_event(evento)

Duas práticas completam a automação de forma segura. Primeiro, use chaves de API distintas por integração, com papel de usuário automatizado e distribuição limitada, para conter vazamentos. Segundo, registre chamadas automatizadas em log separado, porque volumes altos de consultas de triagem indicam demanda de cache prévio no SIEM, no lugar de consultas diretas à instância.

6. Boas Práticas de Operação

A qualidade da base depende de disciplina de catalogação diária. Os pontos abaixo concentram as decisões que mais afetam a utilidade da plataforma ao longo do tempo.

• Organizar eventos por campanha ou incidente, com título normalizado, em vez de acumular coleções genéricas sem contexto analítico.
• Definir distribuição por padrão conservadora, no nível da organização, e ampliar apenas após revisão analítica consciente.
• Aplicar data de expiração em atributos voláteis, como IPs de C2, para reduzir falsos positivos em consultas antigas.
• Padronizar taxonomias obrigatórias por evento, incluindo TLP, tipo de evento e setor afetado, com política de tags proibidas.
• Revisar eventos vencidos e rejeitados em rotina quinzenal, arquivando em vez de excluir quando houver valor forense.
• Separar usuários automatizados de usuários humanos, com papéis e distribuições distintas, para rastreabilidade de mudanças.

A vida útil dos indicadores merece atenção especial, porque o MISP não decide sozinho o que é velho. Hashes de malware têm validade longa, domínios de phishing expiram em dias e endereços IP de bots raramente superam poucos dias úteis. O controle PLT.4 detalha a política de expiração por tipo, e a exportação para o SIEM deve filtrar apenas atributos dentro da janela válida.

7. Limitações e Integração com OpenCTI

O MISP não é uma plataforma de conhecimento analítico. Ele não foi projetado para manter perfis de atores, cronologias de campanha ou grafos de relacionamento entre entidades, e tratar esses produtos como eventos com tags leva a bibliotecas ilegíveis. Perfis de ator, mapeamento de TTP por grupo e visualização de infraestrutura pertencem à plataforma de gerenciamento de CTI do controle PLT.2.

A integração entre as duas plataformas é o padrão de mercado recomendado. Conectores do OpenCTI consomem eventos e atributos do MISP, convertem os dados para entidades STIX 2.1 e preservam as marcações TLP como marcações de objeto. O sentido contrário também existe, com indicadores enriquecidos ou criados no OpenCTI publicados de volta no MISP para compartilhamento. A tabela abaixo resume a divisão de papéis.

Quando a organização ainda não implantou o OpenCTI, o MISP pode atuar temporariamente como repositório único, mas com limites explícitos e documentados. Relatórios e avaliações estratégicas devem permanecer em outro sistema, com referência apenas no campo de descrição do evento, para não inflar a base de indicadores com documentos difíceis de exportar. Sem essa separação, as exportações automáticas carregam lixo estrutural e o SIEM começa a rejeitar lotes de ingestão por inconsistência de formato.

8. Implementação Prática e Salvaguardas por Nível

O Framework CTH organiza as salvaguardas do controle em três níveis cumulativos. O plano de implantação deve tratar cada nível como marco mensurável, com evidência de execução arquivada. A tabela resume os objetivos e os entregáveis esperados.

9. Erros Comuns e Pontos de Atenção

Os erros abaixo aparecem com frequência em implantações reais e derrubam a confiança do SOC na plataforma. Cada item inclui o efeito observável e a correção recomendada.

• Publicar eventos sem tag TLP, o que bloqueia a sincronização ou, pior, vaza conteúdo restrito; correção: política de tags obrigatórias no fluxo de criação.
• Marcar atributos com to_ids sem validar falsos positivos, gerando ruído no SIEM; correção: triagem analítica antes da publicação e revisão de whitelists.
• Usar a instância como repositório de relatórios, acumulando PDFs sem atributos; correção: armazenar relatórios no controle PLT.2 e manter apenas indicadores.
• Chaves de API amplas em scripts improvisados, sem papéis nem distribuição limitada; correção: contas de serviço dedicadas e revisão trimestral de chaves.
• Correlações tratadas como verdade absoluta, sem verificação de fonte; correção: aplicar a avaliação de confiabilidade do PLT.4 antes de repassar inteligência externa.
• Expiração inexistente, mantendo IPs mortos em detecção por meses; correção: política de expiração por tipo de atributo exportada em filtro.

10. Integração com Outros Controles do Framework CTH

O PLT.1 é o ponto de convergência de coleta e o ponto de partida da detecção guiada por inteligência. DAT fornece telemetria para validar indicadores, INS consome a exportação em hunts com dados históricos e AUT orquestra a entrega contínua ao SIEM e ao EDR. A qualidade do que sai da plataforma depende diretamente do PLT.4, que governa as fontes, e do PLT.5, que define o que pode ser compartilhado em cada nível de TLP.

No plano de maturidade, o marco Básico exige instância, taxonomias e feeds mínimos operando; o Intermediário exige integração viva com SIEM e grupos de compartilhamento; o Avançado exige participação bidirecional em comunidades com métricas de qualidade. A evidência de maturidade é a combinação de métricas de acionamento no ambiente, taxa de falsos positivos por fonte e registros de contribuição externa, todos conectáveis ao MET para medir o valor do programa.