Um SIEM coleta logs, normaliza os campos, roda regras de correlação e gera alertas para triagem. Aprenda o caminho com um exemplo que você executa.
Quando uma equipe de segurança diz que "viu o ataque", geralmente quer dizer que o ataque deixou registros em vários lugares e que um sistema juntou esses registros e levantou um alerta. Esse sistema costuma ser um SIEM, sigla de security information and event management, ou gerenciamento de informações e eventos de segurança. Boa parte do trabalho diário de um SOC começa aí: o analista abre um alerta, confere os eventos por trás dele e decide se alguém precisa agir.
Este artigo explica o que um SIEM faz, passo a passo. Você vai ver de onde vêm os dados, por que os logs precisam ser reorganizados antes de servirem para alguma coisa, como regras de correlação transformam eventos em alertas e o que acontece depois que um alerta dispara. Também vai ver onde o SIEM fica em relação às ferramentas de EDR e SOAR, e vai mapear um alerta de exemplo para uma técnica do MITRE ATT&CK, para entender como uma detecção se liga ao comportamento do atacante.
Você não precisa de laboratório para esta parte. A parte prática é um pequeno script em Python que roda em qualquer máquina com Python 3.12, usando logs sintéticos. Ele gera um alerta real a partir de linhas brutas, e você pode mudar os dados e ver o resultado mudar. Se preferir uma pilha completa, as últimas seções citam duas opções gratuitas que você mesmo pode instalar.
Um SIEM faz três trabalhos numa mesma plataforma. Ele coleta dados de log e de eventos de muitas fontes. Guarda esses dados para você pesquisar depois. E roda regras sobre os dados que disparam alertas quando algo combina com um padrão.
O guia da NIST sobre gerenciamento de logs de segurança de computadores, o SP 800-92, traz orientações práticas para desenvolver, implantar e manter o gerenciamento de logs em uma organização. O guia trata o gerenciamento de logs como uma prática contínua, que a equipe precisa planejar e manter funcionando. O SIEM é uma forma comum de executar essa prática em escala, mas não é a única. Uma equipe pequena consegue muita coisa com um servidor central de logs e algumas buscas bem escritas.
A palavra "segurança" no nome importa menos do que a palavra "evento". Um SIEM não sabe por padrão o que é um evento ruim. Ele conhece os eventos que você envia e as regras que você escreve. A qualidade dele depende dos dados que entram e das detecções que rodam por cima.
Atacantes raramente produzem um sinal claro. Uma falha de login, uma nova tarefa agendada e uma conexão de saída para um host desconhecido são, cada um, coisas comuns. Juntos podem descrever uma intrusão. O SIEM é útil porque consegue colocar esses registros lado a lado, entre máquinas, contas e horários. Uma pessoa lendo arquivos individuais em máquinas individuais não consegue fazer isso em escala.
O volume é a outra razão. Uma organização com algumas centenas de máquinas pode gerar milhões de linhas de log por dia. Nenhum analista lê tudo. O trabalho do SIEM é reduzir esse volume a uma lista curta do que uma pessoa deve olhar, com contexto suficiente para decidir rápido.
Um SIEM funciona em etapas. Cada etapa pode quebrar, e muitos problemas de detecção remontam a uma delas.
Uma fonte de log é qualquer coisa que registre algo que aconteceu. Na maioria dos ambientes, as mais comuns são:
Cada fonte descreve o mundo do seu próprio ponto de vista. Um firewall enxerga uma conexão. Um host Windows enxerga um logon. Nenhum dos dois enxerga a história inteira.
A coleta leva os registros da fonte até o SIEM. Os métodos mais usados são um agente instalado no host, um encaminhador que lê arquivos de log, mensagens syslog enviadas pela rede ou uma API que puxa eventos de um serviço em nuvem. Agentes capturam mais detalhes do host. O syslog é simples e muito suportado, mas pode perder mensagens sob carga se nada as armazenar temporariamente.
Falhas de coleta são silenciosas. Se um servidor para de enviar logs, o SIEM não mostra erro por padrão. Ele simplesmente não tem nada a dizer sobre aquele servidor, e o silêncio pode parecer calma. Boas equipes acompanham o volume de eventos por fonte e criam alerta quando uma fonte fica muda.
Cada fonte usa o próprio formato. Um sistema escreve o nome de usuário como user, outro como account, um terceiro como subject.name dentro de um JSON aninhado. A normalização mapeia esses campos para um esquema comum, para que uma regra possa dizer "o campo de usuário" e significar a mesma coisa em todas as fontes.
A maioria dos produtos SIEM faz isso por você, com parsers embutidos ou um esquema publicado. Qualquer que seja o produto, o objetivo é o mesmo: depois da normalização, uma busca por logons falhos fica igual, venha o evento do Linux, do Windows ou de um provedor de identidade na nuvem.
O script de exemplo abaixo faz isso em pequena escala. Ele pega uma linha bruta de SSH e produz um dicionário com os mesmos nomes de campo todas as vezes.
Retenção é o tempo que você guarda os logs antes de apagá-los. Parece uma questão administrativa, mas ela define o que você consegue investigar. Uma intrusão descoberta três meses depois precisa de logs de três meses atrás. Se a retenção for de duas semanas, a evidência já sumiu quando alguém olhar.
O período certo depende da sua política, das obrigações legais e regulatórias e do custo de armazenamento. Orientações de gerenciamento de logs, como a NIST SP 800-92, cobrem toda a vida dos dados de log. Por isso a retenção deve entrar no plano desde o começo, e não aparecer quando o disco enche. Anote o que você guarda, por quanto tempo e quem pode ler. Depois confira se a exclusão realmente acontece.
Dados recentes costumam ficar em armazenamento rápido e caro. Dados antigos podem ir para um armazenamento mais barato e mais lento para pesquisar. O equilíbrio é simples: quanto mais antigo o evento, mais demorado é encontrá-lo.
Correlação é a etapa em que o SIEM olha através de vários eventos, e não dentro de um só. Uma regra de correlação descreve um padrão: uma condição, uma janela de tempo e uma chave de agrupamento. Quando o padrão aparece, a regra cria um alerta.
Aqui está uma regra em linguagem simples para password spraying. Vamos testá-la na seção prática.
Group events by source IP over a 10-minute window.
Count distinct user accounts with a failed login from that source.
If the count is 4 or more, and the same source later has a successful login,
create an alert with the source IP, the accounts and the successful login.Duas coisas tornam uma regra assim útil. Ela usa mais de um evento, então uma única falha de login fica quieta. E agrupa por uma chave que combina com o ataque. Atacantes que chutam senhas costumam testar uma senha contra muitas contas a partir de um mesmo lugar, e esse formato aparece com clareza quando você agrupa por origem.
Um alerta é uma afirmação de que algo precisa de atenção. Ele não é a conclusão de que houve um ataque. A triagem é a primeira decisão depois que o alerta dispara. O analista faz quatro perguntas: o alerta se baseia em dados reais, a conta ou o host importa, o que aconteceu antes e depois, e qual é o próximo passo. Muitos alertas se fecham aqui como benignos, por exemplo uma varredura de vulnerabilidades que você mesmo rodou, ou um usuário que digitou a senha errada depois de uma troca.
O resultado de uma boa triagem é uma decisão e uma nota. A nota registra o que o analista verificou, para que a próxima pessoa não refaça o trabalho. Equipes que pulam a nota acabam investigando o mesmo alerta benigno toda semana.
Três termos aparecem juntos na maioria dos SOCs, e os escopos se sobrepõem.
Um SIEM coleta e correlaciona registros de muitas fontes em todo o ambiente. Sua força é a amplitude e o histórico. Seu limite é que ele só vê o que cada fonte informa.
EDR, endpoint detection and response, ou detecção e resposta em endpoints, observa os endpoints em detalhe. Registra atividade de processos, mudanças em arquivos e conexões de rede em cada host, e muitas vezes consegue isolar a máquina. Sua força é a profundidade no endpoint. Ele não enxerga um log de firewall ou um trilho de auditoria da nuvem, a menos que você o conecte a eles.
SOAR, security orchestration, automation and response, ou orquestração, automação e resposta de segurança, executa playbooks. Um playbook pode enriquecer um alerta com uma consulta de reputação, abrir um chamado, desativar uma conta depois de aprovação ou avisar quem está de plantão. Sua força é a resposta repetível. Os resultados dependem da qualidade dos alertas que ele recebe.
Este exercício precisa apenas de Python 3.12. Os logs são sintéticos e usam endereços do bloco 192.0.2.0/24, reservado para documentação. Você não toca em nenhum sistema. O script lê as linhas, normaliza, aplica a regra de password spraying e mostra o resultado.
Salve isto como siem_demo.py:
# Synthetic logs only. 192.0.2.0/24 is a documentation range (TEST-NET-1).
import re
from collections import defaultdict
RAW = """\
2026-11-07T10:00:01Z sshd[811]: Failed password for alice from 192.0.2.44 port 50111
2026-11-07T10:00:03Z sshd[812]: Failed password for bob from 192.0.2.44 port 50112
2026-11-07T10:00:05Z sshd[813]: Failed password for carol from 192.0.2.44 port 50113
2026-11-07T10:00:07Z sshd[814]: Failed password for dave from 192.0.2.44 port 50114
2026-11-07T10:00:09Z sshd[815]: Failed password for erin from 192.0.2.44 port 50115
2026-11-07T10:00:11Z sshd[816]: Accepted password for erin from 192.0.2.44 port 50116
2026-11-07T10:02:00Z sshd[820]: Accepted password for frank from 192.0.2.10 port 50200
2026-11-07T10:03:00Z sshd[821]: Failed password for frank from 192.0.2.10 port 50201
"""
PATTERN = re.compile(
r"^(?P<ts>\S+) sshd\[\d+\]: (?P<outcome>Failed|Accepted) password for "
r"(?P<user>\S+) from (?P<src>\S+) port \d+$"
)
def normalize(line):
m = PATTERN.match(line)
if not m:
return None
return {
"timestamp": m["ts"],
"event_type": "authentication",
"outcome": "success" if m["outcome"] == "Accepted" else "failure",
"user": m["user"],
"source_ip": m["src"],
}
events = [e for e in (normalize(l) for l in RAW.splitlines()) if e]
print(f"normalized {len(events)} events")
# Rule: one source IP fails against 4+ different accounts, then gets a success from that IP.
fails = defaultdict(set)
successes = defaultdict(list)
for e in events:
if e["outcome"] == "failure":
fails[e["source_ip"]].add(e["user"])
else:
successes[e["source_ip"]].append(e)
for ip, users in fails.items():
if len(users) >= 4 and successes.get(ip):
s = successes[ip][0]
print(f"ALERT src={ip} failed_accounts={len(users)} then_success_user={s['user']} at={s['timestamp']}")
print(" mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)")Rode a partir da pasta onde você salvou:
python -I siem_demo.pyA flag -I roda o Python em modo isolado. Ela ignora variáveis de ambiente e impede que a pasta do script entre no caminho de importação. É um bom hábito quando você roda um script que não escreveu.
Na máquina Windows 11 onde este artigo foi conferido, com Python 3.12.10, a saída foi:
normalized 8 events
ALERT src=192.0.2.44 failed_accounts=5 then_success_user=erin at=2026-11-07T10:00:11Z
mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)O script mantém a regra curta de propósito. Ele não aplica a janela de 10 minutos da versão em linguagem simples e não confere se o sucesso veio depois das falhas. Uma regra em produção faria as duas coisas.
Cinco contas falharam a partir de um mesmo endereço em cerca de dez segundos. Depois, erin entrou com sucesso a partir do mesmo endereço. A regra disparou porque as duas condições valeram: muitas contas, poucas tentativas em cada uma, e um sucesso depois. Um erro de digitação ou uma senha salva raramente se parecem com isso.
Agora olhe a segunda fonte, 192.0.2.10. Frank entrou com sucesso, e depois apareceu uma falha. A regra ficou quieta, porque só uma conta falhou a partir daquele endereço. É aí que está a função da chave de agrupamento. Uma falha de login é ruído. Cinco contas diferentes falhando a partir de um mesmo lugar formam um padrão.
Mude os dados para ver os trade-offs. Se você apagar a linha de sucesso de erin, o alerta some, mesmo com as falhas ainda lá, porque a regra exige as duas coisas. Se subir o limite para 6, o alerta também some, já que só cinco contas falharam. Em produção, uma regra mais rígida deixa passar ataques mais lentos, e uma regra mais frouxa dispara com mais comportamento comum.
O MITRE ATT&CK é uma base pública de conhecimento sobre comportamento de adversários. Cada técnica tem um ID, uma tática e uma descrição, e a orientação de detecção de algumas técnicas lista as fontes de dados que as revelam.
O alerta se encaixa em T1110, Brute Force, sob a tática Credential Access. O ATT&CK descreve brute force como tentativas repetidas de acessar contas quando o atacante não conhece a senha. Ele lista quatro sub-técnicas. Password Spraying (T1110.003) é testar uma ou poucas senhas contra muitas contas, o que evita bloquear qualquer conta específica. Password Guessing (T1110.001) testa muitas senhas contra uma conta. Credential Stuffing (T1110.004) reutiliza senhas vazadas de outros serviços. A página também aponta para uma estratégia de detecção que correlaciona falhas de autenticação entre plataformas, a mesma ideia da nossa regra pequena.
Repare na palavra "candidato" na saída. A regra casa com um padrão, e esse padrão é compatível com spraying. Também é compatível com um serviço mal configurado que testa várias credenciais guardadas, ou com um teste interno. A triagem precisa descobrir qual dos casos é. O mapeamento no ATT&CK mostra onde olhar e qual comportamento relacionado checar em seguida, como o uso de contas válidas (T1078) depois de um login bem-sucedido. Ele não prova que o ataque aconteceu.
Dá para aprender a maior parte disso sem comprar nada. Duas opções abertas cobrem o caminho da coleta até o alerta. Rode qualquer uma delas numa máquina sobrando ou numa máquina virtual.
A documentação do Wazuh descreve a plataforma como uma plataforma de segurança gratuita e de código aberto que unifica capacidades de XDR e SIEM. Ela tem três componentes centrais, o indexador Wazuh, o servidor Wazuh e o painel Wazuh, além de um agente universal instalado nos sistemas monitorados. O guia de primeiros passos oferece um quickstart que instala a pilha em poucos minutos. Ele também documenta instalações passo a passo, máquinas virtuais, Docker e Kubernetes. Confira a documentação atual para saber a versão e os comandos exatos, porque eles mudam entre versões.
Para praticar, instale um agente numa máquina virtual Linux. De uma segunda máquina virtual que você controla, faça algumas tentativas de login SSH com falha e depois acompanhe os eventos chegando no painel. Isso cobre coleta, normalização e alertas num pipeline real.
O Elastic Security documenta um SIEM construído sobre o Elastic Stack. A visão geral descreve coleta de dados por integrações e pelo Elastic Agent, detecção com regras prontas, regras próprias e machine learning, triagem de alertas, o Timeline para caça a ameaças e os Cases para registrar investigações. Quais desses recursos uma instalação self-managed inclui depende do nível de licença, então leia a página de assinaturas da Elastic antes de implantar. A visão geral não lista quais recursos de SIEM uma instalação self-managed recebe sem custo, então não presuma que um plano gratuito cubra algum recurso de detecção específico.
Comece pelo guia NIST SP 800-92. Ele é organizacional e de alto nível, então leia-o pelas perguntas que faz, como quem é dono de cada fonte de log e por quanto tempo você guarda cada uma. Depois abra a página do ATT&CK para T1110 e leia as notas de detecção ao lado das sub-técnicas.
Em seguida, instale o Wazuh ou o Elastic numa máquina virtual e envie logs de uma fonte que você controla. Escreva uma regra que case com um padrão que você consiga disparar de propósito, e depois escreva a nota de triagem como se um colega fosse pegar aquilo amanhã.
O próximo artigo desta série trata do log de eventos do Windows e dos IDs de evento que muitas regras de correlação usam, o que facilita ler essas regras: logs de eventos do Windows e IDs de evento. Se quiser ver como uma detecção é escrita na prática, escrever uma regra YARA contra um arquivo de teste benigno mostra a mesma ideia de testar uma regra com dados conhecidos antes de confiar nela.
Detecção e blue team
Leia o log Security do Windows: política de auditoria, eventos 4624, 4625, 4634, 4672, 4688 e 1102, o que o Sysmon acrescenta e um logon com falha seu.
Detecção e blue team
Escreva uma regra Sigma para falhas de logon no Windows, valide, converta para Splunk e teste com eventos bons e ruins.