Mito: “Se eu tiver SIEM, estou protegido”. Realidade: sem processo, ele é só um coletor de logs caro

Em reunião, já ouvi de tudo: “temos SIEM”, “contratamos XDR”, “estamos cobertos”. Na tica, quando chego perto, encontro alertas silenciados, regras genéricas, fontes de log faltando e ninguém responsável por afinar nada. A ferramenta existe, mas a detecção é quase decorativa. É o clássico teatro de segurança.

 

Mito

O SIEM (ou XDR/SOAR) resolve segurança “por si”. Basta ligar conectores, criar dashboards e pronto: proteção garantida.

Realidade

Sem processo, contexto de negócio e engenharia de detecção, o SIEM vira log storage caro. Ele coleciona eventos, mas não distingue o que importa, não reduz tempo de detecção e não orienta a resposta. Pior: produz fadiga de alerta o time passa a ignorar ruído e o que é critico se perde no meio.

Caminho recomendado (do estratégico ao aplicado)

 

1. Comece pelo risco do negócio

Mapeie 5-7 cenários que realmente doem: indisponibilidade de ERP, sequestro de arquivos, abuso de identidade privilegiada, fraude em e-mail, exfiltração de dados. Traduza isso em hipóteses de ataque. Use o MITRE ATT&CK como gramática, não como fim em si.

2. Fontes de dados essenciais (menos, porém melhores)

Priorize qualidade: identidade (AD/Azure AD/M365), endpoints (EDR), firewall/VPN/WAF, DNS/Proxy, cloud (Cloud Trail/Azure Activity), infra de backup. Sem identidade e endpoint, a maioria das hipóteses fica cega.

3. Engenharia de detecção, não “regras de catálogo”

Mantenha um backlog de detecções com dono, versão e critérios de qualidade. Enriqueça alertas com criticidade do ativo, dono do sistema, janela de trabalho, serviços sensíveis. Defina limiares e correlações (ex.: múltiplos falhos + sucesso de login + alteração de grupo privilegiado). Toda regra nova entra com período de tuning.

4. Operação com SLOs claros

Estabeleça SLOs: triagem em até 10 min para P1; contenção em 30-60 min (quando aplicável). Tenha runbooks e rotas de escalonamento. Métricas que importam: MTTD/MTTR, % de falsos positivos, alertas/dia por analista.

5. Automação com propósito (SOAR)

Automatize o que é repetitivo e seguro: enriquecimento de IP/usuário/host, isolamento de endpoint pelo EDR, reset de sessões suspeitas, bloqueio de indicadores. Automação boa encurta o caminho até a decisão.

6. Saúde da plataforma.

Monitore coletores, filas, falhas de ingestão, retenção vs, custo, cobertura por fonte. Alerta quebrado detecção inexistente.

7. Ciclo de melhoria continua

Revisão quinzenal de detecções (o que pegou, o que não pegou, o que gerou ruído). Tabletop trimestral com Ti/negócio. Pós-incidente vira lição aprendida → nova regra/ajuste de playbook.

8. Gente, sempre

Treine analistas para investigar hipóteses, não só “abrir/fechar ticket”. Faça rodízio, cuide da carga mental. Fadiga crônica cegueira operacional.

Ferramenta é motor. Processo é direção. Gente é piloto. Quando esses três se alinham, o SIEM deixa de ser figurante e passa a encurtar o tempo entre suspeita e ação.

É exatamente por isso que eu acredito tanto na modalidade de SIEM como serviço, que temos estruturada na Gruppen hé quase 10 anos: nesse modelo, consigo aplicaressa abordagem ponta a ponta e somar a minha equipe ao time de TI/SI do cliente em cogerenciamento. Na prática, unimos contexto do negócio + engenharia de detecção + operação com SLOs, mantendo o ciclo de melhoria continua vivo. O resultado não é um painel bonito é capacidade real de detectar, conter e voltar a operar.