Alert, Event, Incident e Offense: as diferenças que todo analista deve conhecer

Event: A Observação Básica

Um Event é o registo de uma ação, estado ou mudança. Exemplos: login bem-sucedido, falha de autenticação, criação de um Process, consulta DNS, mudança de Policy ou conexão de rede. A maioria dos Events são legítimos; o seu valor vem dos campos e do contexto.

Um Event pode vir de um Raw Log, Telemetry de EDR, Audit Log na cloud ou Flow de rede. O SIEM executa Parsing e normalização para exibir campos uniformes, mas o registo ainda não é uma afirmação de que ocorreu um ataque.

A qualidade de um Event depende da fonte: Timestamp, Host, User, Action, Result e um identificador único. Um Event em falta ou incorreto pode levar a um Alert enganoso, por isso, uma investigação profissional, por vezes, volta aos Raw Data.

Alert: Um sinal gerado por lógica

Um Alert é criado quando uma regra, modelo, assinatura ou Analytics identifica uma correspondência. Pode ser baseado num único Event, sequência, Threshold, Anomaly ou IOC. Um Alert significa “deve verificar”, não “o evento é malicioso”.

Um Alert geralmente inclui um Title, Severity, tempo, Entities, Evidence e nome de Detection. Pode ser um True Positive, Benign Positive ou False Positive. O papel do Triage é entender se há contexto suficiente para abrir uma investigação, fechar ou enriquecer.

Em diferentes sistemas, um Alert pode ser chamado de Detection, Finding ou Signal. É importante verificar na documentação do produto se é um resultado bruto, uma agregação ou já um objeto de investigação.

Incident: Uma história de investigação e resposta

Um Incident centraliza Alerts, Entities, Evidence, Timeline e ações em torno de um único cenário. No Microsoft Defender XDR, os Alerts relacionados são agrupados para exibir a história do ataque em Endpoint, Identity, Email e Cloud. Um Incident pode ser atualizado à medida que novas informações chegam.

No nível organizacional, um Incident não é apenas um objeto técnico. Inclui Owner, Status, Severity, Classification, Tasks, Comments e resposta. Pode haver um Alert real que não se tornará um Incident se tiver um impacto insignificante e for tratado automaticamente; e pode haver um Incident aberto manualmente após o relatório de um utilizador, mesmo sem um Alert automático.

O termo deve estar ligado aos critérios da organização: quando uma descoberta se torna um evento que requer Response, quem está autorizado a declará-lo e como é encerrado.

Offense no QRadar

O QRadar recolhe Events e Flows e executa um Custom Rule Engine. Quando as condições são atendidas, uma Rule pode contribuir para a criação de um Offense. Um Offense centraliza os Events e Flows relacionados e exibe Context para investigação.

Offense não é uma palavra geral para todo Incident. É um objeto específico do modelo QRadar. Inclui Magnitude, que é calculado com base em Severity, Relevance, Credibility e outros fatores. O analista abre o Offense, verifica Rules, Events, Source/Destination, Assets, Notes e Timeline.

Às vezes, um Offense representa uma suspeita de política ou ataque, mas ainda precisa ser classificado. Pode ser encerrado como False Positive, Non-Issue, Policy Violation ou de acordo com uma Taxonomy local.

Finding, Case e Detection

Finding é uma descoberta que requer atenção, comum em ferramentas de Cloud e Vulnerability. Detection pode ser a lógica de deteção ou o seu resultado, dependendo do produto. Case é um invólucro de trabalho amplo que centraliza vários Incidents ou uma investigação entre sistemas.

Em vez de discutir sobre “a palavra correta”, construa um dicionário organizacional: o nome do termo, a origem, o que representa, quem é o Owner, quais Status existem e o que o cria ou encerra. O dicionário é especialmente importante ao conectar vários produtos ao SOAR.

Cadeia do exemplo de log a Incident

1. Um Domain Controller regista um Event de cinquenta falhas de login de um único endereço. 2. Uma SIEM Rule conta os eventos numa janela de cinco minutos e cria um Alert de Password Spray. 3. Um Alert adicional exibe um login bem-sucedido para um dos utilizadores. 4. Um motor de correlação unifica os dois Alerts num Incident. 5. Um analista verifica o Scope, cancela as Sessions e classifica o Incident como True Positive.

No QRadar, os mesmos Events e Flows podem acionar Rules e criar um Offense que exibe a origem do ataque, os utilizadores, a Magnitude e os eventos contribuintes. As informações são semelhantes, mas os nomes e as relações entre os objetos são diferentes.

Tabela de comparação

Exercício de classificação

Checklist prático

• ✓Verifiquei a definição do termo na documentação do produto.
• ✓Sei a origem e o Trigger de cada objeto.
• ✓Não tratei um Alert como prova de um ataque.
• ✓Associei Events a Alerts e a Incident usando identificadores.
• ✓Documentei a Classification e o Owner.
• ✓Construí um dicionário de termos para a equipa e o SOAR.

Erros comuns

• Chamar a cada linha de log de “Incident”.
• Usar Offense fora do contexto QRadar como se fosse um padrão geral.
• Contar Events e Incidents na mesma métrica.
• Fechar um Alert sem verificar se faz parte de um Incident mais amplo.
• Assumir que os termos são idênticos entre Sentinel, Defender, QRadar e Elastic.
• Não manter a ligação entre os objetos num sistema de Ticketing.

Resumo e CTA

Abra um SIEM ou um cenário de laboratório e selecione dez itens. Para cada um, classifique-o como Event, Alert, Incident, Offense ou Finding e explique quem o criou. Em seguida, consulte o artigo “O que é SIEM e como funciona” para entender o pipeline de dados completo. No curso HPI, os termos são praticados dentro das ferramentas de investigação e não apenas como definições.

Perguntas frequentes