Plataformas de Gerenciamento de IOCs (MISP, OpenCTI, YETI)

Quarta nota do subcapítulo de IOCs no capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Compara em profundidade MISP, OpenCTI e YETI, com critérios de escolha e integração com SIEM e EDR.
Operacionaliza o ciclo de vida e a pontuação das notas anteriores e conecta com os controles PLT da seção 15.

1. Contexto e Posicionamento na Biblioteca

A partir de algumas centenas de indicadores e mais de duas fontes, planilhas e listas textuais deixam de dar conta: falta deduplicação, falta contexto, falta expiração e falta distribuição automática. A plataforma de gerenciamento de IOCs, no jargão de mercado a TIP (Threat Intelligence Platform), é a resposta infraestrutural para esse ponto de inflexão. Ela materializa mecanicamente tudo que as notas anteriores definiram conceitualmente: o ciclo de vida vira estados e tarefas, a pontuação vira modelos de decaimento, a contextualização vira campos obrigatórios e o compartilhamento vira sincronização controlada.

Esta nota compara as três plataformas open source mais relevantes para o uso brasileiro e latino-americano: MISP, OpenCTI e YETI. A leitura correta não busca o vencedor único, e sim o casamento entre o papel que falta na operação e o desenho de cada ferramenta. Na seção 15 da biblioteca, os controles PLT.1 e PLT.2 tratam MISP e OpenCTI como controles separados, e esta nota fornece a base de decisão de arquitetura que aqueles controles pressupõem.

2. Funções Essenciais de uma Plataforma de Indicadores

Qualquer plataforma candidata precisa cumprir um conjunto mínimo de funções, e a ausência de qualquer delas no desenho escolhido vira custo manual recorrente. O checklist abaixo é o padrão mínimo para avaliação, antes de qualquer comparação entre produtos.

• Ingestão estruturada de fontes múltiplas, com conectores para feeds, relatórios e API, e normalização de tipos na entrada.
• Deduplicação e correlação entre valores idênticos ou relacionados, revelando que duas fontes observaram o mesmo artefato.
• Gestão de contexto e de metadados obrigatórios, incluindo TLP, confiança, fonte, campanha e janela de validade.
• Pontuação e decaimento automáticos por tipo de indicador, com threshold de exportação configurável.
• Exportação em formatos de detecção, incluindo STIX 2.1, CSV, JSON e regras de rede, para SIEM, EDR, NDR e proxy.
• Controle de acesso e compartilhamento, com grupos, distribuição granular e registro de auditoria das trocas.

3. MISP em Profundidade

O MISP (Malware Information Sharing Platform) é a plataforma de referência para gestão e compartilhamento de indicadores, com modelo de dados centrado em eventos que agregam atributos. A força do MISP está na camada social e de sincronização: instâncias trocam eventos por push e pull com filtros de TLP, taxonomias padronizam rotulagem, galáxias trazem clusters de atores e de malware, e o histórico de correlação revela que o mesmo IP já apareceu em três eventos de fontes distintas. O modelo de decaimento tratado na nota de pontuação é nativo, e a exportação cobre os formatos de detecção mais comuns, inclusive regras Suricata e Snort.

A fraqueza correspondente é analítica. O MISP não foi desenhado para manter perfis de atores, cronologias de campanha ou grafos de relacionamento; tentar usar eventos como se fossem dossiês analíticos produz bases ilegíveis e exportações sujas. O ponto forte operacional é a combinação de API REST madura, SDK PyMISP e milhares de instalações que servem de referência. Para equipes que precisam resolver o problema do compartilhamento tático primeiro, o MISP é a escolha de menor risco.

O inventário de recursos nativos define o que a equipe ganha de imediato ao implantar a plataforma. Cada recurso abaixo resolve um problema clássico de gestão de indicadores e deve ser configurado antes de qualquer integração avançada.

• Feeds: ingestão de fontes externas em modo cache, que guarda apenas hashes remotos e baixa conteúdo somente quando há correspondência local, reduzindo volume e exposição.
• Taxonomias: vocabulários de tags prontos, como tlp, admiralty-scale e mitre-attack, que padronizam filtros e exportações de forma auditável.
• Galáxias: bibliotecas de conhecimento reutilizáveis, com clusters de atores, malware e ferramentas, que rotulam eventos sem recriar descrições à mão.
• Modelos de decaimento: política de score e expiração por tipo de atributo, descrita em detalhe na nota de pontuação deste subcapítulo.
• Notificações e alertas: regras que avisam quando um atributo publicado corresponde a algo que a organização observou, ativando o MISP como sensor passivo.

As exportações nativas cobrem os consumidores clássicos de detecção, e conhecer as opções evita conversões manuais desnecessárias no pipeline.

4. OpenCTI em Profundidade

O OpenCTI é uma plataforma de conhecimento, construída sobre o modelo de dados STIX 2.1, em que entidades como indicadores, malwares, atores, campanhas e infraestrutura se ligam por relacionamentos tipados num grafo consultável. A arquitetura combina Elasticsearch ou OpenSearch, Redis, RabbitMQ e MinIO, com conectores Python que ingerem fontes externas e publicam objetos no grafo. O valor central aparece na investigação: a partir de um domínio, o analista navega para a campanha que o usou, o malware entregado, os atores atribuídos e a infraestrutura irmã, com linha do tempo e visualização de grafo nativas.

O OpenCTI não substitui o compartilhamento ponto a ponto do MISP, mas consome dele: o conector oficial ingere eventos e atributos do MISP e os converte para entidades STIX preservando marcações TLP. A curva de aprendizado é maior, e a exigência de infraestrutura também, com quatro serviços de apoio no mínimo. O uso adequado emerge quando a equipe já produz análise, precisa de contexto interligado e quer responder a perguntas do tipo onde mais esse ator apareceu, que nenhum sistema de listas responde.

O ecossistema de conectores é o diferencial prático da plataforma, e as categorias abaixo cobrem a maioria das fontes de um programa CTI. A configuração é padronizada em YAML por conector, o que torna a gestão do parque de conectores previsível.

• Fontes de inteligência: MISP, feeds RSS, STIX/TAXII, MITRE ATT&CK e repositórios públicos de IOCs, com ingestão agendada.
• Enriquecimento: consultas a serviços de reputação, WHOIS, sandbox e resolução DNS, anexando dados externos às entidades.
• Detecção: exportação para SIEM e ferramentas de resposta, incluindo formatos de watchlist e de regras.
• Produtividade: conexões com sistemas de ticket, planilhas e armazenamento de arquivos, para integrar o fluxo de trabalho do time.

opencti:
  url: "https://opencti.interno"
  token: "TOKEN_DO_CONECTOR"
connector:
  id: "ID_UNICO_DO_CONECTOR"
  type: "EXTERNAL_IMPORT"
  name: "Feed URLhaus"
  scope: "url,ip,domain"
  duration_period: "PT1H"

O trecho mostra o esqueleto de um conector de importação externa com ciclo horário. Repare que o escopo declara os tipos de entidade que o conector produz, o que permite prever o impacto no grafo antes de ativar a fonte.

5. YETI em Profundidade

O YETI (Your Everyday Threat Intelligence) organiza observáveis, indicadores, TTPs e conhecimento em um repositório único orientado à rotina de CTI e DFIR. Seu modelo é direto: feeds são configurados e ingeridos por tarefas agendadas; observáveis são extraídos automaticamente; indicadores podem ser definidos com expressões regulares, o que permite detectar padrões e não apenas valores exatos; e cada observável carrega contexto de fonte e de detecção. A força do YETI está na simplicidade operacional e no papel de ponte entre o analista de resposta a incidentes e o processo de inteligência, transformando artefatos que chegam no DFIR em conhecimento estruturado e consultável.

O YETI não tem o ecossistema de compartilhamento do MISP nem a profundidade analítica do OpenCTI, e é nessas lacunas que se decide seu uso: equipes pequenas, com um analista acumulando papéis, ganham uma base organizada com custo baixo de manutenção. O vocabulário do YETI é curto, e dominá-lo acelera a avaliação.

• Feed: fonte externa configurada com agendamento próprio, cujo conteúdo é processado em busca de observáveis.
• Observable: valor técnico extraído, como domínio, IP, hash ou caminho de arquivo, com histórico de fontes.
• Indicator: afirmação de detecção sobre observáveis, incluindo a possibilidade de expressão regular que casa padrões e não apenas valores fixos.
• TTP: técnica ou comportamento associado a amostras e campanhas, mantendo o elo entre artefato e método.
• Task: execução agendada de ingestão ou enriquecimento, com histórico visível de sucesso e falha.

O exemplo abaixo consulta a API REST do YETI em busca de observáveis cujo valor contenha o padrão de caminho usado na campanha de exemplo das notas anteriores, para ilustrar o estilo de integração via linha de comando.

curl -s -H "X-Api-Key: ${YETI_KEY}" \
  "https://yeti.interno/api/v2/observables/?value__endswith=upd.php&limit=50"

6. Comparativo e Critérios de Escolha

A tabela abaixo compara as três plataformas nos eixos que efetivamente mudam a operação. As colunas de uso ideal e de limitação resumem a experiência de implantações reais, e a leitura recomendada é por linha, procurando a ferramenta que resolve o gargalo atual.

Três critérios completam a decisão. Volume de compartilhamento externo empurra para o MISP, porque a sincronização federada é insubstituível. Necessidade de análise ligada, com perfis de ator e cronologias, empurra para o OpenCTI, porque grafo e linha do tempo são nativos. Restrição de equipe e infraestrutura empurra para o YETI, porque uma base organizada de observáveis já muda o patamar de maturidade com custo mínimo. O padrão de arquitetura mais comum em operações médias é MISP como hub de indicadores, OpenCTI como camada de conhecimento alimentada por conector do MISP, e YETI como ferramenta pontual de equipes de DFIR quando presente.

O dimensionamento também muda com o nível de maturidade do programa, e forçar a arquitetura completa antes da hora gera custo sem retorno. Em nível inicial, uma única instância de MISP com dois feeds e exportação para o SIEM resolve. Em nível intermediário, acrescenta-se OpenCTI para conhecimento e integração com resposta a incidentes. Em nível avançado, a tríade completa com sincronização externa, automação de conectores e métricas de qualidade por fonte, alinhada aos níveis do modelo de maturidade da biblioteca.

7. Integração com SIEM, EDR e o Pipeline de Detecção

A plataforma só cumpre seu papel quando o produto chega às ferramentas de detecção sem retrabalho manual. O padrão de integração tem três camadas. Na primeira, a exportação filtrada por validade e por score entrega listas ao SIEM, que as materializa em watchlists ou listas de referência. Na segunda, consultas de detecção cruzam a telemetria com essas listas, como no exemplo KQL abaixo. Na terceira, o EDR e o NDR recebem bloqueios por API ou por feeds nativos, com regra clara de que bloqueio automático exige score alto e taxa de falsos positivos baixa.

let Iocs = _GetWatchlist("ioc_domains") | project Domain = SearchKey;
DeviceNetworkEvents
| where Timestamp > ago(1d)
| where RemoteDomain in (Iocs)
| summarize Conexoes = count(), PrimeiroVisto = min(Timestamp), UltimoVisto = max(Timestamp)
    by DeviceName, RemoteDomain, InitiatingProcessFileName
| order by Conexoes desc

A consulta exemplifica o contrato mínimo de integração: a watchlist recebe o que a plataforma exporta, a consulta cruza com telemetria de rede e a saída prioriza volume de conexões para triagem. O mesmo padrão vale para hashes no EDR, com listas de bloqueio, e para domínios no proxy, com categorização dinâmica. O erro estrutural a evitar é ingestão direta de feed no SIEM sem passar pela plataforma: sem deduplicação, sem decaimento e sem contexto, o SIEM vira o depósito de lixo que a TIP deveria impedir.

O contrato de integração precisa ser monitorado como serviço, porque falha silenciosa de exportação é invisível no dia a dia e descoberta tarde, quando um incidente revela que o indicador da campanha nunca chegou ao SIEM. Três verificações recorrentes mantêm o contrato saudável e devem entrar na rotina de operação.

• Comparar o número de itens exportados com o número de itens recebidos na watchlist, alertando sobre divergência acima de uma margem pequena.
• Medir a latência entre publicação na plataforma e disponibilidade no consumidor, com meta explícita, por exemplo inferior a uma hora.
• Testar periodicamente um indicador sintético de canal de teste, confirmando que o pipeline completo, da publicação ao acionamento, está vivo.

8. Erros Comuns e Pontos de Atenção

As implantações de plataforma falham por padrões repetidos, e reconhecê-los antes da escolha poupa meses de retrabalho.

• Escolher a ferramenta da moda e não a que resolve o gargalo, implantando OpenCTI onde falta o básico de compartilhamento; correção: mapear o gargalo com as funções essenciais da seção 2.
• Usar o MISP como repositório de relatórios e dossiês, poluindo a base de indicadores com documentos; correção: manter análise no OpenCTI ou em wiki, com referência no evento.
• Instalar plataforma sem dono e sem rotina, virando cofre de dados mortos; correção: atribuir responsabilidade operacional e cadência semanal de triagem.
• Pular o controle de acesso, com todos editando tudo e sem auditoria de mudanças; correção: grupos de usuário, papéis mínimos e log de alterações desde o primeiro dia.
• Subestimar a operação do OpenCTI, que exige vigilância de serviços, índices e conectores; correção: monitorar saúde dos containers e falhas de conector como serviço crítico.
• Duplicar funções entre plataformas, com decaimento no MISP e score paralelo no pipeline; correção: definir local autoritativo por função, como discutido na nota de pontuação.
• Deixar de versionar configurações de conectores e modelos, perdendo rastreabilidade de mudanças de política; correção: guardar configurações em repositório de código com revisão.
• Tratar a plataforma como projeto com fim, sem orçamento de manutenção, que degrada em meses; correção: incluir a plataforma no inventário de serviços críticos com janela de atualização trimestral.

9. Integração com o Restante da Biblioteca

Esta nota traduz em infraestrutura o que as notas anteriores definiram em processo: o ciclo de vida vira estados e expiração automática, a pontuação vira modelos e thresholds, a contextualização vira campos obrigatórios de ingestão, e o compartilhamento vira sincronização e TLP. Na seção 15, o PLT.1 detalha a operação do MISP como controle, o PLT.2 detalha o OpenCTI, o PLT.3 cobre os formatos STIX e TAXII que mediam essas integrações e o PLT.4 governa as fontes ingeridas. O próximo passo prático recomendado é mapear o fluxo atual de indicadores da sua operação, do relatório à detecção, e marcar em qual função essencial da seção 2 cada etapa falha hoje; esse mapa, e não a tabela comparativa isolada, é o que escolhe a plataforma certa.