Um SIEM eficaz não é um produto que se liga na tomada — é um pipeline de engenharia que transforma bilhões de eventos brutos em alertas de alta fidelidade. Esta referência cobre a arquitetura interna, o design de regras de correlação e as técnicas de tuning que separam um SIEM operacional de um repositório de logs caro.

Arquitetura de um SIEM moderno

A arquitetura de um SIEM divide-se em seis camadas funcionais. Compreender cada uma é pré-requisito para otimizar desempenho, controlar custo e aumentar a capacidade de detecção.

1. Coleta e encaminhamento (Forwarders)

A ingestão começa nos forwarders — agentes instalados em endpoints e servidores, ou conectores que recebem syslog, Kafka, API pull ou file beat. O forwarder local reduz latência e permite filtragem na borda antes de consumir banda. Em ambientes de nuvem, o equivalente são as integrações nativas: AWS CloudTrail entregue via S3 ou Kinesis, Azure Monitor via Event Hub, GCP via Pub/Sub. A regra de ouro é nunca enviar dados brutos sem ao menos uma etapa de filtragem básica — heartbeats, logs de debug de aplicação e eventos de sistema de baixo valor devem ser descartados antes de entrar na fila de ingestão.

2. Normalização e parsing

Logs chegam em dezenas de formatos: CEF, LEEF, JSON, syslog RFC 3164, syslog RFC 5424, texto livre. O parser extrai campos estruturados e os mapeia para um schema comum. Os mais adotados são o Elastic Common Schema (ECS) para stacks baseadas em Elasticsearch e o Common Information Model (CIM) do Splunk. Campos obrigatórios em qualquer schema: timestamp em UTC com precisão de milissegundo, source.ip, destination.ip, user.name, host.name, event.action e event.outcome. A normalização correta é o que permite que uma regra única detecte brute force independentemente de o evento ter vindo de um Active Directory, de um VPN gateway ou de um sistema Linux com PAM.

3. Indexação e storage

O índice transforma eventos em estruturas pesquisáveis. As arquiteturas modernas separam hot storage (discos NVMe, retenção de 30 a 90 dias, consultas em tempo real) de warm e cold storage (object storage como S3 ou Azure Blob, retenção de 1 a 7 anos, custo por GB menor em uma ou duas ordens de magnitude). O dimensionamento correto exige conhecer o EPS médio e de pico de cada fonte, o tamanho médio do evento após parsing e a taxa de compressão — em média, logs de texto comprimem 4:1 a 8:1 com algoritmos como Zstandard. Uma organização com 5.000 usuários tipicamente gera entre 3.000 e 15.000 EPS dependendo da cobertura de fontes.

4. Motor de correlação

O motor de correlação é o núcleo do SIEM: ele avalia eventos contra regras e gera alertas quando condições são satisfeitas. Existem dois paradigmas principais. O primeiro é o baseado em regras de sequência — o motor mantém um estado temporal e dispara quando uma sequência específica de eventos ocorre dentro de uma janela de tempo, por exemplo, falha de autenticação seguida de sucesso seguido de criação de conta privilegiada em menos de dez minutos no mesmo host. O segundo é o baseado em estatística e comportamento — o motor calcula baselines por usuário, host ou entidade e alerta quando o desvio ultrapassa um limiar, cobrindo ameaças internas e contas comprometidas cujo comportamento é anômalo mas não corresponde a nenhuma assinatura conhecida.

5. Alerting e priorização

Alertas gerados pelo motor de correlação precisam de um sistema de priorização antes de chegar à fila do analista. A priorização eficaz combina três dimensões: severidade da regra (crítica, alta, média, baixa), criticidade do ativo afetado (servidor de produção versus estação de desenvolvimento) e contexto do usuário (conta privilegiada versus usuário comum). O resultado é uma pontuação de risco que ordena a fila e permite que alertas críticos em ativos críticos de contas privilegiadas apareçam no topo, independentemente do horário em que foram gerados.

6. Dashboards e relatórios

Dashboards operacionais para o analista de N1 mostram fila de alertas, SLA de triagem, MTTD e MTTR em tempo real. Dashboards táticos para o gestor do SOC exibem cobertura MITRE ATT&CK, volume de ingestão por fonte, taxa de FP por regra e tendências semanais. Relatórios executivos apresentam incidentes confirmados, tempo de contenção e impacto evitado. Separar esses três públicos evita que o painel do analista vire um mural de gráficos irrelevantes para a triagem imediata.

Fontes de log e valor de detecção

Nem todo log vale o mesmo. A tabela abaixo resume as principais fontes pela capacidade de detecção que oferecem:

Fonte Técnicas MITRE cobertas Volume típico Prioridade de ingestão
Active Directory / LDAP (eventos 4624, 4625, 4768, 4769, 4771) T1078, T1110, T1558, T1021 Médio P0 — obrigatório
DNS externo T1071.004, T1568, T1048 Alto P0 — obrigatório
EDR (telemetria de processo e rede) T1059, T1055, T1003, T1057 Muito alto P0 — obrigatório
Firewall / NGF T1046, T1571, T1090 Alto P1 — alta prioridade
Proxy web / gateway T1071.001, T1567, T1105 Muito alto P1 — alta prioridade
Cloud trail (AWS/Azure/GCP) T1078.004, T1530, T1537 Médio-alto P1 — alta prioridade
VPN / acesso remoto T1133, T1078 Baixo-médio P1 — alta prioridade
E-mail (gateway, headers) T1566, T1598, T1534 Médio P2
Banco de dados (audit log) T1005, T1213, T1190 Variável P2 — se dado sensível
Syslog de servidores Linux (auditd) T1548, T1053, T1136 Médio P2
IoT / OT / SCADA T0840, T0856 Variável P3 — conforme escopo

Regras de correlação: design e use cases

Regras de assinatura

Regras de assinatura são as mais simples e mais rápidas de implementar. Exemplos concretos de use cases de alto valor: detecção de LOLBins (binários nativos do Windows usados de forma abusiva, como mshta.exe executando URL externa, certutil.exe com flag -decode ou wmic.exe iniciando processo filho); detecção de Kerberoasting (eventos 4769 com tipo de cifra RC4-HMAC de contas de serviço); e exfiltração via DNS (volume anômalo de consultas TXT ou subdomínios longos para um domínio externo específico). Cada uma dessas regras tem implementação de referência no repositório SigmaHQ/sigma no GitHub, testada contra dezenas de SIEMs.

Formato Sigma e detection-as-code

Uma regra Sigma tem a seguinte estrutura canônica: campos de metadado (title, id, status, description, author, date, tags com referências MITRE ATT&CK), a seção logsource que define categoria e produto, a seção detection com os seletores e condições lógicas, e os campos falsepositives, level e fields. A conversão para a plataforma de destino — por exemplo, Splunk SPL, KQL do Microsoft Sentinel ou Elasticsearch Query DSL — é feita pela ferramenta pySigma. O fluxo de detection-as-code recomendado é: escrever a regra em Sigma, abrir pull request no repositório de detecção, executar testes automatizados com datasets de eventos sintéticos, aprovar e fazer merge, e acionar um pipeline CI/CD que converte e implanta a regra no SIEM de produção. Esse fluxo garante rastreabilidade, revisão por pares e capacidade de rollback imediato.

Regras comportamentais e UEBA

Regras comportamentais requerem 14 a 30 dias de aprendizado para construir baselines por entidade. Use cases típicos: acesso em horário fora do perfil do usuário, volume de downloads acima de 3 desvios padrão, impossible travel (autenticação de dois países em intervalo impossível), e sequência de escalada de permissões em janela curta. A fragilidade é a sensibilidade ao contexto — migrações e novos projetos distorcem o baseline. O antídoto é enriquecimento contextual: se o usuário está em um projeto de migração registrado no ITSM, o alerta de acesso a novos servidores deve ter severidade reduzida automaticamente.

Tuning sistemático de falsos positivos

O tuning não é um evento único — é um processo contínuo com ciclos semanais e mensais. A metodologia em quatro camadas garante redução consistente de FP sem eliminar verdadeiros positivos:

Supressão de origem: antes de aplicar qualquer regra, filtre eventos gerados por origens conhecidas e de baixo risco — scanners de vulnerabilidade internos (Nessus, Qualys, Tenable), agentes de monitoramento (Zabbix, Datadog), contas de serviço de backup e contas de integração entre sistemas. Mantenha essa lista em um CMDB ou planilha versionada e revise-a trimestralmente.

Ajuste de threshold: thresholds estáticos geram FP em ambientes dinâmicos. Use thresholds dinâmicos baseados em percentil — por exemplo, disparar quando o evento ultrapassar o percentil 99 do histórico dos últimos 30 dias para aquela entidade, em vez de um valor absoluto fixo.

Enrichment de contexto: adicione ao evento atributos que permitam modular a severidade: criticidade do ativo (P1 a P4), tipo de conta (humana ou de serviço), presença de controles compensatórios (MFA ativo, EDR instalado) e histórico de FP da regra naquele host. Uma regra que dispara FP em 60% do tempo em um host específico deve ter severidade reduzida automaticamente para esse host até que o ajuste seja feito.

Feedback loop estruturado: implante um sistema de triagem que registre o veredito do analista em cada alerta. Semanalmente, calcule a taxa de FP por regra. Qualquer regra com FP acima de 30% entra no backlog de tuning com prioridade alta. Regras com 100% de FP por mais de duas semanas devem ser desativadas ou completamente reescritas.

Pipeline de ingestão e controle de custo (EPS e GB)

Em plataformas com licenciamento por volume — Splunk, Microsoft Sentinel, Elastic Security — o custo cresce com o volume ingerido. Três técnicas de redução com baixo impacto na cobertura: (1) filtragem no forwarder de eventos audit success de operações de leitura em sistemas não críticos; (2) amostragem de NetFlow interno retendo 10% dos fluxos e priorizando destinos externos; (3) aggregation de eventos repetidos — o mesmo firewall deny 10.000 vezes por minuto para o mesmo par vira um evento com contador. Nunca aplique filtro ou amostragem a autenticação, EDR, DNS externo ou cloud trail — o custo de uma detecção perdida supera o de storage.

Integração com SOAR e EDR

A integração SIEM-SOAR-EDR forma o triângulo de resposta automatizada. O SIEM detecta e enriquece; o SOAR orquestra ações; o EDR executa contenção no endpoint. O fluxo de integração para um caso de ransomware em fase inicial ilustra bem o potencial: o EDR detecta vssadmin delete shadows (T1490), envia o evento ao SIEM, que correlaciona com eventos anteriores de conexão a IP suspeito e execução de script PowerShell codificado, gera um alerta crítico e o encaminha ao SOAR. O SOAR executa o playbook: isola o host via API do EDR, coleta a memória do processo via dump forense, bloqueia o IP de C2 no firewall, suspende temporariamente a conta do usuário no AD, abre um ticket P1 no ITSM e notifica o analista de plantão com um resumo da linha do tempo. Tudo isso acontece em menos de 90 segundos, antes que o ransomware consiga propagar lateralmente.

Métricas de maturidade do SIEM

Cinco métricas resumem a saúde de engenharia de detecção: MTTD — meta abaixo de 15 minutos para ataques ativos; MTTR — meta abaixo de 4 horas para incidentes críticos; taxa de FP — meta abaixo de 20% no agregado; cobertura ATT&CK — percentual de técnicas relevantes ao setor com ao menos uma regra ativa, meta acima de 60%; e crescimento de ingestão por fonte — crescimento acima de 30% semana a semana merece investigação imediata, pois pode indicar falha de configuração ou início de exfiltração por amplificação de log.

Referências

  • SigmaHQ/sigma — regras de detecção em formato aberto (github.com/SigmaHQ/sigma)
  • MITRE ATT&CK — táticas, técnicas e procedimentos adversariais (attack.mitre.org)
  • NIST SP 800-92 — Guide to Computer Security Log Management
  • Elastic Common Schema (ECS) e OCSF — schemas de normalização abertos para logs de segurança

Perguntas frequentes

Qual a diferença entre uma regra de assinatura e uma regra comportamental no SIEM?

Regras de assinatura comparam eventos a padrões fixos — por exemplo, um hash de malware conhecido ou uma string específica em log de firewall. São determinísticas e geram poucos falsos positivos quando bem mantidas, mas falham contra ameaças novas. Regras comportamentais detectam desvios estatísticos: um usuário que nunca acessou o servidor de backups passa a fazer isso às 3h da madrugada. A combinação das duas abordagens é o que permite cobertura ampla com precisão adequada.

O que é Sigma e por que ele importa para engenharia de detecção?

Sigma é um formato aberto de regras de detecção para SIEMs, mantido pela comunidade SigmaHQ no GitHub. Uma regra Sigma descreve a lógica de detecção de forma agnóstica à plataforma e é convertida em sintaxe nativa por ferramentas como pySigma. O benefício prático é detection-as-code: regras versionadas em repositório Git, revisadas via pull request, testadas automaticamente e implantadas de forma rastreável. A MITRE ATT&CK referencia técnicas que Sigma cobre, tornando-o o vocabulário padrão de detecção entre times de inteligência e SOC.

Como calcular o custo de ingestão de um SIEM e evitar explosão de EPS?

O custo de ingestão depende de eventos por segundo (EPS) e, em plataformas baseadas em volume de dados, de GB/dia. Para reduzir volume sem perder cobertura, filtre na borda eventos de baixíssimo valor — heartbeats de monitoramento, varreduras internas conhecidas. Use amostragem apenas para telemetria de alto volume e baixo risco, como NetFlow de links internos. O log de DNS interno gera volume enorme mas é indispensável para detecção de C2; a saída é reter só consultas externas e domínios não vistos anteriormente.

Quais fontes de log têm maior valor de detecção e devem entrar primeiro no SIEM?

A sequência mais comum começa por: (1) logs de autenticação — Active Directory/LDAP, VPN, SSO; (2) DNS externo e proxy/gateway web; (3) EDR; (4) firewall e NDR; (5) cloud trail (AWS CloudTrail, Azure Activity Log, GCP Audit Logs); e (6) logs de aplicação crítica. Fontes como impressoras e IoT genérica têm valor marginal e devem entrar só depois de consolidada a base de cobertura.

O que é tuning de SIEM e como reduzir falsos positivos de forma sistemática?

Tuning é o processo contínuo de ajustar regras, thresholds e allowlists para que o SIEM produza alertas de alta fidelidade. A abordagem usa quatro camadas: supressão de origem, ajuste de threshold, enrichment de contexto e feedback loop. O objetivo não é zero alerta, mas alta proporção de alertas acionáveis — menos de 20% de FP no agregado é o benchmark de maturidade.

Como integrar SIEM com SOAR e EDR para resposta automatizada?

A integração opera em três camadas: o SIEM enriquece o alerta e o encaminha ao SOAR via API; o SOAR executa playbooks — isolamento via EDR, bloqueio no firewall, suspensão de conta no AD, abertura de ticket no ITSM; o analista recebe o alerta já triado com evidências coletadas e ações tomadas. Ações destrutivas que afetam serviços de produção devem sempre requerer confirmação humana.

A Decripte opera SOC 24x7 com engenharia de detecção dedicada, integrando SIEM, SOAR e EDR para organizações de 1 a mais de 100.000 colaboradores. O plano de Gestão de Ameaças inclui correlação de eventos, tuning contínuo e cobertura MITRE ATT&CK rastreável — disponível gratuitamente para o primeiro diagnóstico. Conheça os planos ou comece grátis.