Detecção Imediata vs. Detecção Futura: O Custo Oculto de Priorizar Logs Brutos

Em ambientes MSSP ou em qualquer implementação de SIEM, a decisão sobre quais fontes de dados integrar raramente é simples. Orçamento limitado, equipes enxutas e contratos com escopo definido tornam cada escolha estratégica e cada escolha errada, cara.

O debate, na maioria das vezes, gira em torno de volume e cobertura: quantas fontes estão conectadas, quantos logs estão sendo coletados. Mas visibilidade não é detecção.

Sabemos que a escolha de uma fonte de dados depende de diversas variáveis objetivo, qualidade do log, maturidade do produto e capacidade da equipe para operacionalizá-lo. Entre todas essas variáveis, uma é frequentemente ignorada: o custo real de transformar aquele dado em detecção. Algumas tecnologias chegam com esse trabalho já feito. Outras entregam a matéria-prima e deixam o resto com você.

Este artigo é a minha opinião sobre essa escolha construída a partir de experiências reais em ambientes com restrições reais.

O problema começa antes da detecção

Integrar uma fonte de dados é, tecnicamente, a parte mais fácil do processo. O verdadeiro trabalho começa depois: garantir armazenamento adequado, assegurar que a coleta seja contínua e estável, normalizar os campos corretamente e, só então, construir detecções que não falhem quando o momento de usá-las chegar.

É um pipeline longo. E em cada etapa dele, existe a possibilidade de uma lacuna que só vai aparecer durante um incidente.

Um log não lido é como uma câmera sem monitoramento: registra tudo e protege nada.

Logs brutos são complementares — mas complementares a quê?

A afirmação é correta, mas incompleta sem contexto. Complementar só faz sentido se já existe algo principal definido. E na prática? O que mais vejo são logs brutos ocupando esse lugar de protagonista quando o papel deles deveria ser de suporte.

Aplicar Sysmon em todos os servidores Windows ou coletar logs de IIS de todas as aplicações indiscriminadamente não é uma estratégia de detecção é uma estratégia de armazenamento. O custo operacional, o volume de ingestão e a carga de trabalho gerada raramente se traduzem em detecções proporcionais.

Onde os logs brutos têm valor real

Vejo o valor dos logs brutos em dois cenários: análise de gaps de cobertura e resposta a incidentes em ativos críticos.

No primeiro cenário, considere um WAF integrado ao SIEM enviando apenas os eventos bloqueados o que é o comportamento padrão da maioria dos produtos. Você tem visibilidade do que foi contido, mas não do que passou. Habilitar o log bruto em ambiente de laboratório, de forma controlada e temporária, permite entender os gaps de cobertura atual e calibrar melhor as regras do controle. Isso é uso inteligente de telemetria bruta com objetivo definido, escopo limitado e prazo determinado.

No segundo cenário, o Sysmon é um exemplo preciso. Habilitá-lo indiscriminadamente em toda a infraestrutura raramente justifica o custo. Habilitá-lo em máquinas críticas para a operação, com retenção orientada a resposta a incidentes, é uma decisão diferente e correta.

Já presenciei casos reais em que um atacante comprometeu um ambiente impactando apenas os canais clássicos Security, System e Application. Os logs de Sysmon, habilitados seletivamente nas máquinas críticas, foram o que permitiu preencher as lacunas da linha do tempo e reconstruir a cadeia de ataque. Sem eles, a resposta seria incompleta. Com eles em toda a frota, o custo seria injustificável.

A lógica que orienta a decisão

Logs brutos têm valor quando há um objetivo claro que o controle nativo não consegue atender seja para análise de gap, laboratório ou cobertura forense em ativos selecionados. Fora de escopos, podem ser volumes sem detecção.

Você já passou por um cenário onde o log bruto foi o que salvou a resposta? Conta nos comentários. 👇

Agora vamos aos exemplos:

EDR x Sysmon

A comparação parece simples na superfície: você integra o EDR, habilita as features, e está quase pronto. Com o Sysmon, a jornada é outra. Instalação, manutenção, configuração de parsing, criação de detecções, versionamento das regras e, ainda assim, a incerteza constante sobre quais TTPs do MITRE você deixou descobertos.

Mas o ponto mais importante não é operacional é conceitual.

O problema da telemetria sem detecção

Quando você olha para um evento bruto de criação de processo um registro fiel do que aconteceu, com hostname, IP, linha de comando, usuário, hashes e demais campos a primeira pergunta natural é: e agora, como identifico o que é malicioso aqui?

A resposta honesta é: vai levar tempo. Muito tempo.

Para extrair detecção de qualidade de telemetria bruta, você precisa conhecer profundamente cada campo disponível, entender o contexto do ambiente, definir o que é comportamento normal e construir lógica capaz de separar ruído de sinal para cada técnica que quiser cobrir. E as técnicas são, na prática, infinitas.

É como ter petróleo bruto nas mãos. O valor está lá, mas entre o poço e o combustível existe uma refinaria inteira e ela não se constrói do dia para a noite.

A saída mais rápida existe e tem um custo também

A comunidade de segurança já percorreu parte desse caminho. Uma busca simples no repositório do SigmaHQ retorna dezenas de regras prontas apenas para o evento de criação de processo testadas, documentadas e mapeadas ao MITRE ATT&CK.

https://github.com/SigmaHQ/sigma/tree/master/rules/windows/process_creation

Mas aplicar, traduzir, testar, ajustar ao ambiente e manter esse volume de regras operacionalmente exige capacidade técnica contínua. Para uma equipe enxuta ou para EUQUIPE isso rapidamente se torna um projeto paralelo que compete com todas as outras demandas do dia a dia.

Você já tentou manter uma stack Sysmon + Sigma em produção? Se sim, sabe exatamente do que estamos falando. 🧐

O que isso significa na prática

O Sysmon não é uma solução ruim é uma solução cara em termos de esforço humano. O EDR resolve parte desse problema trocando controle e transparência por velocidade de operacionalização. Nenhum dos dois é absoluto, e a escolha entre eles raramente é técnica é uma questão de capacidade de equipe, maturidade do ambiente e quanto tempo você tem até precisar detectar algo de verdade.

Vamos a mais um exemplo.

WAF x Logs brutos de IIS/Apache…

O mercado de WAF é amplo oferecido por provedores de hospedagem, CDNs e plataformas de segurança. A adoção cresceu junto com a superfície de ataque: aplicações web são hoje o ativo mais visado, presentes em 43% dos incidentes analisados pelo Verizon DBIR 2025 dentro do padrão Basic Web Application Attacks um dos cinco padrões dominantes de brecha do relatório, combinando abuso de credenciais e exploração direta de vulnerabilidades.

O OWASP Top 10 continua sendo a referência central para cobertura de detecção e resposta em aplicações publicadas e todo WAF maduro do mercado já entrega regras nativas mapeadas a essas categorias, incluindo Broken Access Control, que lidera o ranking desde 2021.

https://owasp.org/Top10/2025/

O que você teria que fazer sem o WAF

Com logs brutos de IIS ou Apache, você tem o registro fiel de cada requisição método, URI, status code, IP de origem, user-agent. O dado está lá. O problema é o que vem depois.

Para detectar um ataque de SQL Injection ou Broken Access Control a partir desses logs, você precisaria conhecer cada aplicação do ambiente, mapear o comportamento normal de cada endpoint, definir thresholds por página e por origem, e construir lógica capaz de distinguir um scanner automatizado de um usuário legítimo com comportamento atípico. Multiplique isso pelo número de aplicações, ambientes e times de desenvolvimento que alteram rotas e parâmetros sem aviso e você tem um projeto de detecção sem data de entrega.

O custo real da decisão

Sua equipe provavelmente já opera com backlog de falsos positivos. Adicionar a responsabilidade de conhecer cada aplicação, cada página de autenticação, cada endpoint de upload e cada integração de API para construir detecções de qualidade é um investimento que poucas equipes têm capacidade de absorver sem garantia de cobertura e com risco real de bloquear origens legítimas no processo.

Com 43% dos incidentes passando por aplicações web, adiar essa cobertura não é uma decisão neutra. É uma janela de exposição com prazo indeterminado.

Os outros cenários seguem o mesmo princípio

A lógica se repete em praticamente qualquer comparação que você queira fazer:

• DLP vs. logs de e-mail e MS Message Trace
• EDR x Linux Auditd
• PAM vs. logs de RDP/SSH
• NDR vs. NetFlow/PCAP
• IdP/UEBA vs. logs de Active Directory
• EPP/XDR vs. logs de antivírus legado

Em todos eles, a estrutura é a mesma: de um lado, um controle com detecção embarcada, mantido por equipes especializadas cujo trabalho exclusivo é refinar essa inteligência. Do outro, telemetria bruta esperando que alguém com tempo, contexto e expertise suficientes transforme dado em alerta.

A pergunta que vale fazer antes de escolher o caminho dos logs brutos não é técnica é estratégica:

O quanto sua equipe está disposta a competir, em tempo real, contra fornecedores que dedicam centenas de engenheiros exclusivamente para resolver o mesmo problema que você tentaria resolver nas horas vagas?

Não existe resposta errada. Existe resposta honesta.

Confiar cegamente no controle de segurança é um risco por si só

Adquirir um controle de segurança não significa estar protegido significa ter uma ferramenta com potencial de proteção. A diferença entre os dois é justamente o que determina o retorno real sobre o investimento.

O controle está entregando o que você pagou?

Essa pergunta parece óbvia, mas raramente é respondida com dados concretos. O retorno de um controle de segurança depende diretamente do que ele oferece, de como foi implementado e de o quanto você conhece suas limitações e todo produto tem limitações.

EDR — visibilidade sem transparência

A maioria dos produtos EDR não expõe a lógica por trás das suas detecções. Você não tem acesso ao código, às condições de disparo ou à cobertura real de ameaças. Isso não é necessariamente um problema mas exige uma postura ativa de validação.

Processos de emulação de ameaças são essenciais nesse contexto. Sem eles, você está confiando em uma caixa preta. Um sinal claro de EDR mal calibrado: alguns produtos deixam de identificar uma ameaça simplesmente após uma renomeação de arquivo algo que qualquer atacante minimamente preparado fará.

Por outro lado, a maioria dos EDRs permite a criação de detecções personalizadas e esse recurso é subutilizado. Ele é justamente o que permite cobrir gaps de cobertura que o vendor não cobre nativamente.

Você já faz emulação de ameaças no seu ambiente? Me conta nos comentários e se quiser um artigo sobre o tema, deixa aqui também. 👇

WAF — entenda o produto antes de confiar nele

O WAF é um controle mais confinado em termos de customização, e seus limites técnicos têm impacto direto na efetividade da detecção. Um exemplo concreto: o AWS WAF possui um limite de tamanho para inspeção do corpo da requisição. Se sua aplicação trafega payloads que ultrapassam esse limite, ataques inteiros podem passar sem inspeção e sem alerta.

Esse tipo de gap não aparece em dashboards. Aparece em incidentes.

A fase de pesquisa e entendimento do produto não é burocracia é parte da implementação. Subestimá-la é aceitar riscos que você ainda não consegue enxergar.

https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-setting-body-inspection-limit.html

Considerações finais

Não existe fórmula universal existe contexto. O que funciona para uma equipe de 15 pessoas em uma enterprise pode ser inviável para um time de 3 cobrindo 40 clientes.

O que defendo aqui é simples: priorize controles de segurança com detecção nativa, use logs brutos com objetivo claro e escopo definido, e seja honesto sobre a capacidade real da sua equipe antes de assumir compromissos de cobertura que não conseguirá sustentar.

Não sou dono da verdade sou um profissional que erra, aprende e tenta documentar o que faz sentido na prática. Se você discorda, concorda parcialmente ou tem experiências que contradizem o que foi escrito aqui, deixe nos comentários. Esse tipo de troca é o que realmente eleva o nível técnico da comunidade.

Se este conteúdo foi útil, considere se inscrever para acompanhar os próximos artigos. E se quiser trocar ideias diretamente, pode me encontrar pelo LinkedIn ou pelo e-mail os links estão no perfil.

Até o próximo. 🔒