O que é SIEM e como funciona, desde a recolha de logs até ao Incidente

Porque é que uma organização precisa de um SIEM

O primeiro objetivo é a visibilidade centralizada. Quando um utilizador faz login a partir de um país incomum, o seu posto de trabalho executa o PowerShell, o DNS resolve para um novo domínio e a Firewall deteta tráfego de saída, cada registo por si só pode parecer inocente. A conexão entre eles, dentro de uma janela de tempo e no contexto do mesmo utilizador e ativo, pode indicar uma conta comprometida.

O segundo objetivo é a consistência. O SIEM permite que a organização defina Casos de Uso, Gravidade, Proprietários, Playbooks e critérios de encerramento. Em vez de cada analista decidir novamente como investigar um ataque de Password Spray ou um alerta de Malware, a equipa trabalha de acordo com uma lógica e documentação que podem ser medidas e melhoradas.

O terceiro objetivo é a retenção e investigação histórica. Às vezes, a organização descobre um Indicador apenas semanas após a intrusão. Se os logs relevantes foram guardados, é possível pesquisar o IP, o hash, o domínio ou a conta retrospetivamente, construir uma Linha do Tempo e avaliar a extensão do impacto. A retenção deve ser determinada pelo risco, regulamentação, custo e necessidades de investigação — não por uma predefinição arbitrária.

A primeira etapa: fontes de dados e recolha

Uma Fonte de Dados é o local onde o evento é gerado: Windows Security Log, Syslog de Firewall, Audit log de SaaS, Telemetria de EDR ou Authentication log de VPN. A recolha é feita através de Agente, Conector de Dados, API, Syslog/CEF, Event Forwarding ou serviço cloud integrado. Cada método tem vantagens, limitações e permissões.

Antes de conectar uma fonte, defina o objetivo da recolha. A questão não é “que logs podem ser enviados?”, mas sim “que comportamento queremos detetar ou investigar, e que campos são necessários para isso?”. O Password Spray, por exemplo, requer pelo menos tempo, resultado do login, utilizador, endereço de origem e, às vezes, aplicação ou Tenant. Se o campo do utilizador estiver em falta, uma Regra sofisticada não resolverá o problema.

Parsing, Normalização e Enriquecimento

Após a ingestão, o sistema precisa de entender o registo. O Parsing extrai campos de texto ou JSON. A Normalização mapeia nomes diferentes para um modelo consistente: src_ip, sourceAddress e ClientIP podem representar a mesma ideia. Na Microsoft, o ASIM fornece um modelo de normalização que permite escrever Query ou Deteção contra um Schema unificado, em vez de adaptar a lógica a cada produto separadamente.

A Normalização não elimina a fonte. Recomenda-se manter também o evento bruto para verificar detalhes e investigar Parsing incorreto. Quando um Parser muda, uma Regra pode parar de funcionar silenciosamente. Por isso, são medidas as alterações de Schema, campos vazios, atraso na Ingestão e volume incomum.

O Enrichment adiciona contexto que não apareceu no log: criticidade do ativo, proprietário do sistema, departamento, GeoIP, Threat Intelligence, se a conta é Privileged, se o IP pertence a uma VPN organizacional e se a atividade corresponde a uma Alteração aprovada. O enriquecimento muda a qualidade da decisão. Uma única tentativa falhada de login num servidor de testes não é o mesmo que a mesma tentativa numa conta de Domain Admin.

Deteção: de Query a Alerta

Uma regra de Deteção examina os dados de acordo com uma condição. Ela pode procurar um Indicador conhecido, uma sequência de eventos, um Limite (Threshold), um desvio da Baseline ou uma combinação de fontes. Uma regra Agendada executa uma Query em intervalos e examina uma janela de Lookback. Se os resultados ultrapassarem um limite, é gerado um Alerta. Outros produtos importam Alertas prontos, e o SIEM pode agregá-los em um único Incidente.

Uma boa Regra começa com um Caso de Uso e uma hipótese, não com um comando técnico. É preciso definir qual o comportamento, que fontes são necessárias, o que constitui uma unidade de resultado, que Entidades serão mapeadas, qual a Gravidade, qual o Expected noise e o que o analista deve fazer. Uma Regra que não pode ser investigada gera uma sobrecarga, mesmo que “capture” muitos eventos.

A Correlação conecta eventos. Ela pode detetar cinco falhas seguidas de um sucesso, um Processo suspeito após um novo login, ou o mesmo IP contra vários utilizadores. É importante lembrar: a correspondência com uma regra é uma Pista para investigação, não prova de um ataque. O analista deve verificar a fonte, o contexto, a Linha do Tempo e explicações legítimas.

Incidente e Gestão de Casos

Um Alerta descreve uma correspondência específica. Um Incidente é um caso de investigação que centraliza Alertas, Entidades, Evidências, Linha do Tempo, Tarefas, Proprietário, Gravidade, Status e respostas. A Gestão de Casos permite Hand-off, escalada, documentação e geração de métricas. O sistema deve manter a separação entre factos, interpretação e decisão.

Ao abrir um Incidente, o analista verifica: quem é o utilizador e o ativo, qual o tempo da atividade, que fontes participaram, existem Alertas adicionais, qual a criticidade do ativo e o que mudou em relação ao hábito. Em seguida, ele executa Queries complementares, verifica Indicadores, constrói uma Linha do Tempo e decide se é um Falso Positivo, Positivo Benigno ou Positivo Verdadeiro.

Cenário: Evento de login do servidor para o ecrã do analista

1. Um servidor Windows regista um evento de login com tempo, utilizador, tipo de Logon e endereço de origem.
2. Um Forwarder ou Conector envia o evento para o SIEM. O sistema adiciona tempo de ingestão e identifica a fonte de dados.
3. O Parser extrai Conta, Computador, IP de Origem e Resultado. A camada de Normalização mapeia-os para campos uniformes.
4. O Enrichment marca que a conta é Privileged e que o servidor é de Produção. O Threat Intelligence não identifica o IP, mas o GeoIP aponta para um país inesperado.
5. Uma Regra deteta várias falhas seguidas de um sucesso dentro de uma janela de tempo. Ela mapeia Utilizador, Host e IP e cria um Alerta.
6. Outro Alerta de EDR deteta um Processo anómalo na mesma estação. O agrupamento de Alertas agrupa ambos num Incidente.
7. O analista verifica MFA, VPN, árvore de Processos, DNS e outras atividades, constrói uma Linha do Tempo e decide sobre a Contenção e Escalada.

O que o SIEM não faz sozinho

O SIEM não garante que todos os dados existam ou estejam corretos. Não substitui um inventário de Ativos, um IAM funcional, EDR, controlos de Rede ou profissionais. Também não sabe automaticamente o que é normal para a organização. Sem Proprietários e Ajustes (Tuning), o sistema pode inundar com Alertas ou criar uma falsa sensação de segurança.

A automação pode enriquecer, abrir um Ticket ou isolar um ativo, mas uma ação automática deve corresponder ao nível de certeza e impacto. Bloquear um utilizador crítico com base numa Regra ruidosa pode causar uma interrupção. Por isso, definem-se Aprovação, Exceções, Rollback e Audit trail.

SIEM vs. Sistemas Similares

Checklist para implementação de Casos de Uso

• ✓O comportamento foi definido e não apenas o nome da Regra.
• ✓As fontes de dados e os campos necessários estão disponíveis.
• ✓O tempo dos eventos está sincronizado e o fuso horário é claro.
• ✓Parsing e Normalização foram verificados com exemplos reais.
• ✓Entidades e criticidade dos ativos estão mapeadas.
• ✓Threshold, Gravidade e Expected noise foram definidos.
• ✓Existe um Playbook com Queries complementares e um caminho de escalada.
• ✓Foram definidos Proprietário, data de Revisão e métricas de qualidade.
• ✓Foram verificadas Retenção, custo e permissões de acesso.

Erros comuns

• Conectar todas as fontes possíveis antes de definir Casos de Uso.
• Confiar no Timestamp da ingestão em vez do tempo do evento.
• Assumir que todo campo chamado "user" representa a mesma identidade.
• Criar uma Regra sem mapeamento de Entidades ou instruções de investigação.
• Fechar Alertas como ruído sem fornecer feedback ao proprietário da Deteção.
• Apresentar um Dashboard verde quando uma fonte de dados parou de enviar.
• Guardar logs por um período que não permite investigação histórica.

Resumo e CTA

Escolha um Caso de Uso — por exemplo, Password Spray — e mapeie toda a cadeia: fonte, campos, Parser, Query, Entidade, Incidente e ação do analista. Depois, vá para o guia KQL para escrever a primeira pesquisa. No curso Cybersecurity & AI da HPI, o SIEM é praticado como parte de um processo completo de investigação, incluindo logs, redes, Windows e resposta a incidentes.

Perguntas frequentes