Cibersegurança e segurança da informação

Falsos Positivos em SOC: Como identificar, documentar e mitigar

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre Falso Positivo em SOC na área de SOC e operações

Resposta rápida

Um Falso Positivo em SOC ocorre quando um alerta é gerado devido a lógica incorreta ou dados imprecisos, mesmo que o comportamento perigoso que a regra pretendia detetar não tenha ocorrido. Para fechar corretamente, é necessário comprovar a causa, distingui-la de atividade suspeita, mas autorizada, documentar a Causa Raiz e fornecer feedback que reduza alertas semelhantes sem criar um Ponto Cego.

Os falsos positivos não são apenas um incómodo. Quando se repetem em grande número, criam Fadiga de Alertas, prolongam os tempos de resposta e ensinam os analistas a ignorar padrões que podem ser perigosos. No entanto, a filtragem excessivamente agressiva é igualmente perigosa: uma exceção ampla pode ocultar atividades maliciosas que exploram um utilizador, ferramenta ou endereço que foi considerado “conhecido”.

A primeira etapa é usar uma linguagem precisa. O Microsoft Sentinel e o Splunk distinguem entre Positivo Verdadeiro, Positivo Benigno e Falso Positivo. A atividade de um scanner autorizado pode ser um Positivo Benigno — a regra identificou corretamente um comportamento suspeito, mas é esperado. Por outro lado, se a regra interpretou um campo errado ou a fonte enviou dados imprecisos, trata-se de um Falso Positivo.

O objetivo não é atingir zero falsos positivos. Uma regra sensível pode produzir algum ruído para não perder um ataque. O objetivo é gerenciar o equilíbrio de forma mensurável, controlada e reversível.

O que é um Falso Positivo — e o que não é

Um Falso Positivo ocorre quando o mecanismo determina que um comportamento perigoso ocorreu, mas na verdade as condições básicas não são verdadeiras. Exemplo: uma regra identifica um processo chamado powershell.exe como uma execução suspeita, mas o dado veio de um campo que descreve um arquivo de destino e não um processo em execução. Outro exemplo é a localização geográfica incorreta devido a um banco de dados IP desatualizado.

Um Positivo Benigno é uma situação diferente: a atividade realmente ocorreu e a regra a identificou corretamente, mas foi realizada com autorização. A varredura de portas por uma equipe de PT, a criação de um usuário durante a instalação ou o PowerShell por um sistema de gerenciamento são exemplos possíveis. A classificação é importante porque a solução é diferente: um Falso Positivo pode exigir uma correção de regra ou dados; um Positivo Benigno pode exigir uma exceção limitada e gerenciada.

“Não encontrei prova de ataque” também não é um Falso Positivo. O evento pode ser inconclusivo, a telemetria pode estar ausente ou a atividade foi interrompida antes que outros sinais fossem gerados.

Que provas são necessárias para o encerramento

Antes de fechar, examine o evento original, não apenas a descrição do alerta. Verifique se os campos exibem o que você pensa que exibem, verifique o processo pai, assinatura, hash, usuário, origem da rede, tempo e ações relacionadas. Se a razão for atividade autorizada, encontre uma Solicitação de Alteração, proprietário do sistema, janela de manutenção, lista de scanners ou documento que a aprove.

Uma boa evidência permite que outra pessoa chegue à mesma conclusão. Uma frase como “o IP é conhecido” é fraca; uma frase como “o endereço pertence ao scanner corporativo Tenable de acordo com o CMDB, a varredura foi realizada na janela aprovada CR-4821 e os destinos correspondem à lista” é auditável.

Ao fechar, escolha uma classificação precisa e adicione um Comentário. O Microsoft Sentinel exige Classificação no encerramento de Incidentes e oferece, entre outros, Falso Positivo devido a lógica incorreta, Falso Positivo devido a dados imprecisos e Positivo Benigno.

Causa Raiz de Falsos Positivos

As causas podem ser divididas em cinco famílias: lógica muito ampla, dados de baixa qualidade, normalização incorreta, falta de contexto organizacional e mudança no ambiente. Uma regra que procura uma ferramenta legítima sem comportamento acompanhante será ampla; endereços IP que passaram por NAT podem criar uma associação de usuário incorreta; um campo process.name mapeado de uma fonte inadequada cria uma normalização problemática; e uma regra que não reconhece uma conta de serviço verá a atividade automática como anômala.

Mudanças operacionais são uma fonte comum: uma nova ferramenta, um script de distribuição, uma transição de VPN ou uma mudança de infraestrutura podem aumentar os alertas de uma só vez. Portanto, é importante verificar quando o ruído começou e o que mudou ao mesmo tempo.

Não se contente com uma lista de entidades a serem excluídas. Pergunte por que a entidade aciona a regra e se o comportamento em si pode ser refinado: processo + processo pai + destino de rede + permissão, em vez de apenas o nome do processo.

Documentação e feedback para Engenharia de Deteção

Um cartão de feedback deve incluir: nome e versão da regra, exemplo de incidente, classificação, Causa Raiz, frequência, usuários/ativos afetados, risco de exclusão e proposta de alteração. O Engenheiro de Deteção também precisa entender o que não deve ser alterado. Se uma regra detetou atividade administrativa legítima, excluir todo o grupo de administradores pode criar um Ponto Cego; pode ser preferível limitar a conta, ferramenta assinada, caminho, dispositivo de gerenciamento e janela de tempo.

O Microsoft Sentinel permite lidar com alguns Falsos Positivos por meio de Automation Rules, que mantêm um Audit Trail e podem ser limitadas no tempo, ou por meio da alteração da Analytics Rule, que permite expressões avançadas e Watchlists. O Elastic permite Rule Exceptions para processos ou atividades de rede confiáveis. Em qualquer caso, uma Exceção precisa de um proprietário, motivo, data de revisão e validade.

Após a alteração, é necessário realizar um Backtest em dados históricos e verificar se a regra ainda identifica exemplos perigosos. É aconselhável manter Casos de Teste positivos e negativos como parte do gerenciamento de versão.

Medir a melhoria ao longo do tempo

Meça pelo menos: quantidade de alertas por regra, taxa de Positivos Verdadeiros/Benignos/Falsos, tempo médio de Triage, número de Exceções, idade das Exceções e quantidade de eventos fechados automaticamente. As métricas não visam penalizar uma regra sensível, mas sim identificar onde os analistas estão a gastar tempo sem valor.

A taxa de Falsos Positivos por si só pode ser enganosa. Uma regra rara que identifica uma técnica perigosa pode justificar alguns falsos positivos. Por outro lado, uma regra com alta taxa de precisão, mas centenas de alertas por dia, ainda pode sobrecarregar. Portanto, combinam-se precisão, volume, gravidade e custo de investigação.

Estabeleça um ciclo de Revisão: semanal para regras ruidosas, mensal para regras principais e trimestral para Exceções. Exceções sem proprietário ou validade são uma dívida de segurança.

Três casos de exemplo

Caso 1 — Atividade de Administrador: PsExec foi executado a partir de um servidor de gerenciamento autorizado por uma conta Tier 0 como parte de uma alteração documentada. O comportamento é inerentemente suspeito, mas autorizado; uma classificação adequada pode ser Benigno Positivo. A exclusão deve ser restrita e baseada em fonte, conta, assinatura e janela.

Caso 2 — Varredura Autorizada: O IDS deteta um Port Scan de um endereço pertencente a um scanner de vulnerabilidades. Se a regra se destina a detetar varreduras não autorizadas, o comportamento é real, mas esperado. É possível adicionar uma lista gerenciada de scanners, mantendo os alertas se o scanner operar fora da janela ou contra um destino não autorizado.

Caso 3 — Ferramenta Legítima: Uma regra alerta sobre certutil.exe em qualquer uso. Uma equipe de desenvolvimento usa-o para conversão de codificação local sem conexão de rede. Em vez de excluir a ferramenta, a regra é alterada para procurar uso com download, URL, caminho incomum ou processo pai suspeito.

Checklist prático

Classifiquei Falso Positivo versus Positivo Benigno.
Encontrei evidências positivas para a explicação e não apenas a ausência de evidências.
Identifiquei a Causa Raiz.
Documentei a regra, versão e exemplo de incidente.
Avaliei o risco da exclusão.
Defini Proprietário e validade para a Exceção.
Testei a alteração em relação a eventos históricos.

Erros comuns

Excluir um usuário ou ferramenta inteira em vez de uma condição restrita.
Fechar todos os casos incertos como Falso Positivo.
Alterar uma regra sem Backtest.
Não distinguir entre um problema de dados e um problema de lógica.
Medir o sucesso apenas pela diminuição do número de alertas.

Resumo e CTA

Escolha uma regra que gera ruído no turno, colete os dez últimos alertas e classifique a Causa Raiz antes de propor uma exclusão. Em seguida, continue para o artigo sobre como construir um Playbook para SOC para tornar o processo de encerramento e feedback consistente.

Perguntas frequentes

É possível atingir zero Falsos Positivos?

Geralmente não, e nem sempre é desejável. A deteção de segurança é um equilíbrio entre sensibilidade e precisão, e o objetivo é um ruído controlável com cobertura de risco adequada.

O que é preferível — Exceção ou alteração de regra?

Uma Exceção é adequada para uma entidade ou condição específica, especialmente se for temporária. A alteração de uma regra é adequada quando o problema está na lógica ou no contexto geral. A decisão depende do escopo e do risco.

Qual a diferença entre Falso Positivo e Positivo Benigno?

Falso Positivo é uma deteção incorreta; Positivo Benigno é uma deteção correta de atividade suspeita, mas autorizada e esperada.

Quem deve aprovar uma exclusão?

De acordo com a governança da organização: geralmente o Engenheiro de Deteção ou o proprietário da regra, e às vezes o proprietário do sistema ou o gerente do SOC. Exclusões de alto risco exigem uma revisão mais ampla.

Quando excluir uma Exceção?

Quando a causa terminou, a ferramenta foi removida, a regra foi aprimorada ou a validade expirou. As Exceções devem ser verificadas periodicamente e não devem ser deixadas permanentemente como padrão.