Home

Blogposts

Uma breve reflexão sobre plataformas de Threat Intelligence e operações de segurança

Recife, 19 de fevereiro de 2026.

Nos últimos 12 meses, dediquei uma parte significativa dos meus esforços à construção da Resonant; uma marca que representa o time e o portfólio de Threat Intelligence da Tempest. Essa jornada passou por diferentes etapas: concepção, definição de estratégia, GTM, identidade visual e, principalmente, reflexões profundas sobre o produto.

Nesse contexto, gostaria de compartilhar uma reflexão sobre como a interação entre Threat Intelligence e a operação de segurança pode (e, na minha opinião, deve) ser abordada.

Por vezes, o óbvio é difícil de enxergar. Levei tempo para chegar às conclusões que compartilho aqui.

Tradicionalmente, quando falamos da integração entre Threat Intelligence e operações de segurança, pensamos na incorporação de dados de inteligência diretamente em ferramentas de detecção; normalmente na forma de IoCs, IoAs ou TTPs, consumidos por SIEMs, EDRs, NDRs ou IDSs. Esse modelo é válido e amplamente utilizado.

No entanto, ao observar o dia a dia de operações de segurança, fica evidente que grande parte do trabalho gira em torno de receber alertas, triá-los, analisá-los e responder a eles. Esses alertas costumam surgir basicamente de duas formas:

Pela detecção direta em ferramentas especializadas;
Pela correlação de eventos e logs em um SIEM.

Durante o processo de priorização do roadmap da Resonant, um feedback apareceu de forma quase unânime: “Gostaríamos de ver os dados de Threat Intelligence integrados ao nosso SOC.”

A resposta instintiva para esse pedido costuma ser óbvia: integrar IoCs, por exemplo via MISP, diretamente ao SIEM.

É justamente aqui que mora o ponto central dessa reflexão.

O maior “ponto de dor” da operação de segurança não está onde a detecção é trivial, mas onde o tratamento exige interação humana. Detectar um IoC em um SIEM é relativamente simples para quem tem a ferramenta. Tratar eventos como credenciais vazadas, tentativas de aliciamento, phishings direcionados ou venda de dados é significativamente mais complexo e sensível ao contexto.

Nesses casos, um analista precisa transitar por múltiplas plataformas, consolidar informações, validar acessos, entender contexto de negócio e só então responder. Esse processo é naturalmente mais custoso, sujeito a erro e altamente dependente de contexto.

Ao analisar diversas plataformas de inteligência, chegamos a uma constatação incômoda: no contexto de operações de segurança, Threat Intelligence costuma ser tratada como um oráculo. Algo que se consulta via API, muitas vezes apenas na fase de resposta, como mecanismo de enriquecimento de um alerta já existente.

Discordo dessa premissa.

A simples existência de uma credencial vazada, de uma tentativa de cooptação, de um site de phishing ou da venda de dados já é, por si só, um alerta independentemente de qualquer correlação adicional.

Essa percepção direcionou nosso desenvolvimento para uma ideia simples: se geramos alertas acionáveis, eles devem ser tratados dentro do fluxo normal de alertas do SOC. Manter uma plataforma de detecção fora do ecossistema operacional apenas aumenta fricção, enquanto o objetivo deveria ser justamente o oposto: transparência e fluidez operacional.

Na prática, isso significa que tudo o que a Resonant gera como alerta a partir do seu monitoramento (após processos de triagem, correlação, uso de IA e, quando necessário, análise humana) pode ser consumido diretamente por ferramentas de tratamento de alertas, como um SIEM, SOAR, n8n etc.

Estamos falando de eventos como: credenciais vazadas, cartões recuperados, tentativas de cooptação de colaboradores, venda de dados, URLs suspeitas, perfis falsos, entre outros.

Tomemos como exemplo o caso clássico de credenciais vazadas. Um dos debates recorrentes nesse tipo de finding é o de falso positivo. Imagine uma credencial vazada pertencente a um colaborador já desligado. Para quem detecta, trata-se de um novo vazamento e, portanto, um alerta legítimo. Para quem opera, pode ser apenas “mais um caso conhecido”.

O problema surge porque quem detecta não tem, e muitas vezes não deve ter, acesso às regras de negócio, ao estado atual das contas ou aos meios de resposta. Logo, não consegue classificar o evento como falso positivo. Por outro lado, quem opera não quer continuar recebendo alertas desse tipo para essas contas.

Esse tipo de tensão operacional não se resolve removendo dados, exportando planilhas ou criando exceções manuais. Resolve-se com automação de resposta bem definida, baseada em casos de uso claros.

Tudo começa com um bom caso de uso de detecção, entendido como a definição do que detectar, com que prioridade e como responder. Um exemplo simples seria um caso de uso de “Detecção de Credencial via Resonant”, com descrição, versão e playbook de resposta.

Nesse fluxo, a própria operação decide, no seu dia a dia, quando um alerta deve ser tratado como válido ou encerrado sem depender de ajustes artificiais na detecção.

Uma pergunta comum que surge é: por que não incorporar esses playbooks diretamente na plataforma de inteligência?

A resposta tem dois aspectos.

O primeiro é prático: concentrar automações em mais uma plataforma cria acoplamento desnecessário. Em operações maduras, a mesma automação pode ser reutilizada para diferentes fontes de alerta, inclusive múltiplos fornecedores de Threat Intelligence.

O segundo é conceitual: uma plataforma de inteligência não deve assumir responsabilidades além da sua projeção. Seu papel é gerar as melhores detecções possíveis. A operação de segurança, como sistema amplo, normalmente combina SIEM, Case Management e SOAR. Misturar essas responsabilidades tende a gerar mais complexidade, não menos.

Após alguns meses de trabalho, a Resonant Intelligence Platform passou a enviar seus alertas para qualquer sistema capaz de ingerir eventos via webhook, como: Splunk, Vector, Google SecOps, Microsoft Sentinel, entre outros.

Por fim, é justo dizer que operações de segurança não falham por falta de dados. Elas falham por excesso de fricção.

Cada clique extra, cada plataforma paralela, cada exportação manual de dados é uma oportunidade para atraso, erro ou fadiga. É nesse espaço, entre o alerta e a decisão, que os incidentes crescem.

Threat Intelligence que detecta, mas não entra no fluxo operacional, não reduz risco: ela transfere risco para o humano.

Se um sinal exige triagem, priorização e resposta, ele precisa nascer como alerta. Precisa ser tratado como qualquer outro evento crítico do SOC.

Inteligência que não chega onde o SOC opera não é inteligência operacional. É apenas conhecimento desconectado da realidade.