Logs não protegem uma empresa. Decisões bem tomadas, sim.

Eu explico SIEM de uma forma simples: é uma camada de centralização, análise e correlação de eventos que ajuda a transformar registros técnicos em visibilidade operacional. Ele recebe dados de fontes diferentes, facilita buscas, cria alertas, apoia investigações e mantém histórico útil para auditoria, resposta a incidentes e melhoria contínua.

Mas é importante não vender uma promessa que nenhuma plataforma entrega sozinha. Um SIEM não corrige uma falha, não confirma todo alerta, não conhece a criticidade de um processo de negócio e não substitui uma equipe preparada para investigar. Ele amplia a capacidade de enxergar e responder. O resultado depende da cobertura de dados, das regras, da qualidade do inventário, da retenção, dos responsáveis e do processo de atuação.

Ampliar imagem

Leitura operacional

Monitorar não é apenas receber evento.

Um alerta precisa chegar acompanhado de contexto suficiente para que alguém consiga confirmar, descartar, conter ou escalar o caso. Quando a organização não sabe quem faz essa decisão, o monitoramento vira apenas acúmulo de dados.

Não existe uma lista única de fontes de log que sirva para toda empresa. Eu começo pelaquilo que representa acesso, privilégio, exposição, movimentação e mudança. A prioridade é construir uma visão mínima do ambiente crítico antes de tentar coletar tudo.

Na minha visão, o Wazuh é valioso quando entra como parte de uma arquitetura de visibilidade. Ele pode coletar telemetria dos endpoints, analisar eventos, manter inventário, identificar vulnerabilidades conhecidas, acompanhar alterações de arquivos e apontar configurações inseguras. Isso cria uma base importante para investigação e gestão de riscos.

Eu não trataria o Wazuh como “a solução completa”. A plataforma precisa estar conectada a um processo: cobertura de agentes, integração de fontes, criação de regras aderentes ao ambiente, governança de alertas, plano de resposta, rotina de correção e validação. Sem isso, o dashboard pode até ser bonito, mas a empresa continuará reagindo tarde.

Ampliar painel

Quando eu recebo uma lista de vulnerabilidades, a primeira pergunta não é “quantas críticas existem?”. A pergunta é “quais delas colocam a operação em risco agora?”. Uma CVE é um identificador. O CVSS informa severidade técnica. Nenhum dos dois, isoladamente, conhece o contexto da empresa.

Uma vulnerabilidade crítica em um equipamento desligado, isolado e sem dados sensíveis não recebe a mesma prioridade de uma falha com exploração conhecida em um serviço exposto à internet, usado por uma área crítica e acessível por uma conta privilegiada. É por isso que eu separo gravidade de risco real.

1. O ativo é crítico para a operação ou trata dados sensíveis?
2. O serviço está exposto à internet ou acessível por terceiros?
3. Existe exploração conhecida, evidência de ataque ou técnica associada?
4. A vulnerabilidade é realmente aplicável à versão instalada?
5. Há controle compensatório enquanto a correção não pode ser aplicada?
6. Quem é o responsável pelo ativo e qual a janela de mudança?
7. Como a correção será validada e documentada?

Ampliar relatório

Uma operação madura não termina quando o SIEM dispara um alerta. Ela começa ali. A equipe precisa saber como confirmar o evento, preservar evidências, medir impacto, conter o risco, corrigir a causa, validar o resultado e transformar o que aprendeu em melhoria.

O objetivo inicial não é monitorar tudo. É garantir que os ativos e processos mais importantes deixem rastros suficientes e que esses rastros estejam disponíveis quando forem necessários. Para isso, eu buscaria uma arquitetura simples, com separação de responsabilidades e capacidade de crescer sem perder controle.