Recorded Future, Anomali, ThreatConnect

Nota da subpasta 01 - Threat Intelligence Platforms (TIPs), no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Examina as três plataformas comerciais de Threat Intelligence Platform (TIP) mais difundidas em produção: Recorded Future, Anomali ThreatStream e ThreatConnect.
Dialoga com a nota de Cyble e CloudSEK da mesma pasta, com o stack open source de OpenCTI, MISP, IntelOwl e YETI e com os controles PLT do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O Capítulo 09 já apresentou o conceito de Threat Intelligence Platform e o controle PLT do Capítulo 15 definiu como a organização opera fontes, formatos e compartilhamento. Esta nota desce ao nível de produto e examina as três plataformas comerciais que dominam os ciclos de compra de TIP no mercado: Recorded Future, Anomali ThreatStream e ThreatConnect. A escolha entre elas raramente é decidida por uma lista de funcionalidades isolada, e sim pelo ajuste entre o modelo operacional de cada produto e a maturidade do programa de CTI-TH da organização.

A leitura recomendada segue três movimentos. Primeiro, entender o que uma TIP comercial entrega de fato, além do discurso de marketing. Segundo, conhecer os diferenciais concretos de cada plataforma, com os nomes das capacidades como elas aparecem no produto. Terceiro, aplicar critérios de seleção que sobrevivem a uma demonstração de 60 minutos, porque demos são desenhadas para impressionar e a operação diária é que cobra a conta. A tabela comparativa da seção 6 e os critérios da seção 7 são o material de trabalho para esse momento de decisão.

2. O que uma TIP Comercial Entrega de Fato

Abaixo do discurso comercial, toda TIP madura executa cinco funções que se combinam em um ciclo: agregação de fontes, normalização e deduplicação de indicadores, enriquecimento contextual, priorização e distribuição para os pontos de detecção. A agregação recebe feeds comerciais, comunitários e internos; a normalização resolve o problema clássico de milhares de IP duplicados em formatos diferentes; o enriquecimento anexa quem, o quê, quando e com que confiança; a priorização transforma volume em fila acionável; a distribuição empurra indicadores para SIEM, EDR, firewall, proxy e SOAR por API, TAXII ou listas exportáveis. O Capítulo 03 tratou dos tipos de indicador e o Capítulo 02 da avaliação de fontes, e ambos os conteúdos continuam válidos independentemente da plataforma comprada.

A tabela decompõe o ciclo em funções com a pergunta operacional que cada uma responde e o artefato que produz, servindo de base para avaliar qualquer plataforma, comercial ou não.

O que diferencia o produto comercial da pilha caseira não é o ciclo em si, e sim três propriedades: escala de coleta proprietária, que nenhuma organização individual replica; curadoria analítica humana em cima dos dados brutos; e integrações mantidas pelo fornecedor, que economizam meses de engenharia. O contraponto é custo de licença normalmente por tamanho de organização, dependência de fornecedor na taxonomia de risco e risco de o time tratar o produto como caixa preta. As três plataformas a seguir equilibram essas propriedades de maneiras distintas.

3. Recorded Future: Intelligence Cloud, Risk Lists e Coleções

A Recorded Future se posiciona como intelligence cloud, um serviço de inteligência em escala de internet que coleta de fontes abertas, dark web, pastes, registros técnicos e dados de sensores, e condensa o resultado em entidades pontuadas. O conceito central do produto é o Risk Score por entidade, combinado com risk rules que explicam por que a pontuação existe, por exemplo comunicação com infraestrutura maliciosa recente ou presença em dumps de credenciais. Para o analista, isso significa trocar a caça manual em múltiplas fontes por uma consulta de entidade que devolve contexto consolidado e histórico.

Duas capacidades merecem destaque prático para o capítulo. As risk lists são exportações agendadas de indicadores que passam de limiares configuráveis de risco, no formato CSV ou via API, e alimentam diretamente lookups de SIEM e blocos de bloqueio de perímetro; elas resolvem o problema de manter watchlists vivas sem coleção artesanal. As coleções, por sua vez, agrupam automaticamente entidades relacionadas a um tema, um malware ou uma campanha, funcionando como ponto de partida de análise que o time valida e recorta, e não como verdade pronta. O exemplo a seguir mostra o consumo de uma risk list como lookup de enriquecimento em Splunk.

# transforms.conf: lookup de enriquecimento com risk list da Recorded Future
[rf_risklist_ip]
filename = rf_risklist_ip.csv
max_matches = 1
match_type = CIDR(dest_ip)
fields_list = dest_ip, rf_risk, rf_evidence, rf_first_seen, rf_last_seen

O consumo por API segue o mesmo espírito do lookup, consultando a entidade no momento do alerta e recebendo o contexto consolidado. A chamada abstrata a seguir ilustra o padrão de integração usado por playbooks de triagem em SOAR.

GET /v2/ips/{ip}?fields=risk.score,risk.rules,metrics.counts
Autorizacao: Bearer {token_de_servico}
Resposta esperada: score, regras de risco, ultima observacao e feeds de origem
Regra do playbook: score acima de 60 abre caso, entre 40 e 60 enriquece, abaixo arquiva

O padrão de operação típico coloca a Recorded Future como camada de enriquecimento e triagem, e não como repositório master de indicadores. A organização consulta a plataforma quando um IOC aparece em alerta, usa as risk lists para alimentar detecção contínua e consome relatórios analíticos como insumo de hipóteses de caça. O time que assume o papel de repositório master tende a mantê-la em outra nota de stack, geralmente OpenCTI ou MISP, e a nota 03 desta pasta trata exatamente dessa combinação.

4. Anomali ThreatStream: Feeds e Threatstreaming

O Anomali ThreatStream nasce do mundo de agregação de feeds e é forte exatamente aí: coleta, normalização, deduplicação e curadoria de milhares de fontes, com destaque para a rede Anomali Community e integrações com ISACs e ISAOs setoriais. O modelo de operação centra-se no conceito de threatstreaming, a prática de trazer fluxos de inteligência de múltiplas origens, filtrar pelo que é relevante para o setor e o perfil de ameaça da organização e empurrar os indicadores selecionados para os controles de detecção. Para equipes cujo ponto de dor é gerenciar dezenas de feeds com qualidade, essa herança é o principal atrativo.

A plataforma trabalha com a ideia de extensions e de integração direta com SIEM para match retroativo: quando um indicador entra na plataforma, a organização dispara uma busca histórica nos logs para saber se ele já passou pelo ambiente nos últimos 30, 60 ou 90 dias, o que transforma feed em caça executável imediatamente. O fluxo de configuração típico de uma fonte externa ilustra o modelo de trabalho por coleção filtrada.

# Exemplo de importação TAXII 2.1 em ThreatStream, com filtro de qualidade
fonte: isac-setorial-taxii
tipo: taxii-2.1
discovery: https://isac.exemplo.org/taxii2/
colecao: colecao-indicadores-setor
intervalo_horas: 6
tlp_maximo: amber
confianca_minima: 60
tag_automatica: isac, setor-energia
acao_match_retroativo: buscar_ultimos_90_dias

O match retroativo merece disciplina de janela, porque buscar 90 dias sem indexação adequada custa caro em qualquer SIEM. A janela deve seguir a criticidade da fonte, com feeds setoriais em janela longa e feeds de curto prazo em janela de sete dias. O resultado do retro match vira evidência em caso, e não apenas tabela consultada, porque é ele que prova o impacto real do feed pago.

O modelo de confiança por fonte, com pontuação de confiabilidade e de idade do indicador, conversa diretamente com a nota de pontuação de qualidade de IOCs do Capítulo 03. Em comparação com a Recorded Future, o ThreatStream entrega menos inteligência analítica produzida pelo fornecedor e mais controle sobre o pipeline de feeds, o que agrada times que possuem analistas próprios e um processo formal de avaliação de fontes.

5. ThreatConnect: Playbooks e Case Management

O ThreatConnect se diferencia por transformar a TIP em plataforma operacional de resposta, com dois pilares que as concorrentes tratam de forma mais rasa. O primeiro é o case management nativo, no qual cada investigação, triagem de IOC ou resposta a phishing vive como um caso com artefatos, tarefas, atribuições, linha do tempo e vínculo com os indicadores analisados, eliminando a lacuna entre a ferramenta de inteligência e a ferramenta de gestão de trabalho. O segundo é o motor de playbooks, que orquestra respostas acionadas por eventos, como o ingresso de um indicador de alta confiança, com ações de enriquecimento, contenção e notificação sem código ou com código.

A tabela a seguir mostra um playbook de resposta a credencial vazada descoberta em feed, com as etapas na ordem de execução e o produto de cada etapa.

A combinação de case management com inteligência é o que separa o ThreatConnect das TIPs de catálogo: a pontuação do indicador passa a refletir o andamento dos casos em que apareceu, e o tempo de resolução alimenta os KPIs do Capítulo 16. Times que já possuem SOAR maduro precisam definir a fronteira entre o playbook da TIP e o playbook do SOAR, para evitar dois motores de automação competindo pelo mesmo fluxo. A decisão documentada dessa fronteira vale mais do que qualquer funcionalidade da comparação.

Para o programa de CTI-TH, esse desenho reduz a distância entre inteligência e operação: o indicador não morre numa lista, ele vira trabalho rastreado com dono e prazo. O contraponto é que o valor do playbook depende da qualidade das integrações configuradas, e a nota AUT do Capítulo 15 sobre orquestração com SOAR discute exatamente os limites dessa automação.

6. Comparativo por Capacidade

A tabela resume as diferenças centrais observadas na operação real das três plataformas, com o entendimento de que recursos mudam de release para release, enquanto o posicionamento de produto muda devagar.

A leitura fina da tabela orienta a prova de conceito: os pontos fortes de cada coluna são verificáveis em demonstração com dados reais, enquanto os pontos médios só aparecem na operação. Peça que a prova de conceito cubra ao menos uma função em que a plataforma é mais fraca, porque é ali que o contrato de suporte e a engenharia interna serão cobrados. E fixe critérios de aceite por escrito antes da demonstração, para que a avaliação não seja guiada pelo roteiro do vendedor.

7. Critérios de Seleção

A decisão entre as três deve partir dos requisitos de inteligência da organização, e não do folheto. A tabela traduz os critérios que sobrevivem à demonstração comercial em perguntas verificáveis.

Os pesos dos critérios variam com o contexto organizacional. O SOC pequeno prioriza enriquecimento e triagem automática; o programa com CTI dedicado prioriza pipeline de feeds e compartilhamento; a operação orientada a resposta prioriza casos e playbooks. O erro caro é comprar pelo critério do vizinho, e a auditoria de amostras após a implantação é o corretivo mais barato para um erro dessa natureza.

Uma regra prática encerra a seção: se o problema é contexto e triagem, a Recorded Future tende a acelerar mais; se o problema é gestão de feeds e setor, o ThreatStream; se o problema é operacionalizar resposta com histórico auditável, o ThreatConnect. Muitos programas maduros acabam combinando uma dessas com o stack open source da nota 03, usando a comercial como fonte e o open source como repositório master.

8. Erros Comuns e Pontos de Atenção

• Comprar a TIP antes de definir os requisitos de inteligência, resultado típico é uma plataforma alimentada por feeds que ninguém consome; os PIRs e EEIs do Capítulo 01 precisam existir antes da licença.
• Acreditar na pontuação automática sem amostragem: todo Risk Score e toda confiança de fonte devem ser auditados com amostras mensais, comparando o que a plataforma diz com o que a telemetria interna confirma.
• Deixar a integração com SIEM e EDR para depois da implantação, o que congelou mais de um programa na fase de catálogo; a distribuição para os pontos de detecção é parte do escopo inicial, não fase dois.
• Tratar a TIP como repositório master e como fonte ao mesmo tempo, duplicando indicadores com taxonomias diferentes entre ferramentas; defina qual sistema é a fonte da verdade para cada tipo de objeto.
• Ignorar o ciclo de vida dos indicadores, com watchlists crescendo sem expiração até degradarem a detecção; a nota de ciclo de vida de IOCs do Capítulo 03 define os prazos por tipo.
• Subestimar o esforço de governança de casos e playbooks, permitindo automação que abre casos sem dono ou notifica que ninguém lê; cada playbook precisa de revisão periódica com métrica de resultado.
• Assumir que a curadoria do fornecedor substitui a análise própria, quando ela acelera o analista e não elimina a validação local contra os requisitos de inteligência.
• Contratar módulos de inteligência geográfica ou setorial sem PIR que os justifique, pagando por conteúdo que fica sem consumo auditável.

9. Integração com o Restante da Biblioteca

Os indicadores que circulam nas três plataformas são os mesmos objetos do Capítulo 03, e as decisões de confiança e prioridade usam os critérios de avaliação de fontes do Capítulo 02 e de qualidade de IOCs da mesma pasta. A nota de Cyble e CloudSEK desta pasta cobre a fatia de exposição digital e dark web que as TIPs clássicas atendem de forma parcial, e a nota de stack open source mostra como completar a arquitetura sem comprar dois produtos comerciais. Os controles PLT do Capítulo 15 descrevem o processo que a plataforma deve servir, e o Capítulo 07 usa a TIP como fonte de hipóteses de caça.

Para o hunting, o consumo prático mais valioso é o match retroativo e a risk list consultada em janelas históricas, padrões explorados nas notas de caça baseada em IOC do Capítulo 10. Para a engenharia de detecção do Capítulo 18, a TIP fornece o contexto que transforma regras genéricas em regras priorizadas por ameaça ativa no setor. A recomendação de fechamento é operacional: trate a plataforma comercial como componente de um pipeline documentado, com PIRs na entrada e detecções na saída, e a escolha de fornecedor vira uma decisão de engenharia e não uma aposta de marketing.

O ciclo de feedback também passa pela plataforma: resultados de caça e de casos devem voltar às fontes como avaliação de qualidade, na lógica do controle CTI.9 do Capítulo 15, fechando o ciclo que transforma a TIP de catálogo de IOCs em parte viva do processo de inteligência. Com esse retorno estruturado, a renovação do contrato deixa de ser decisão de fidelidade e passa a ser decisão baseada em evidência de uso e de impacto, o único critério que aguenta auditoria.