Cibersegurança e segurança da informação

QRadar Offense: Como ler e investigar um Offense

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre a investigação de Offense no QRadar na área de SIEM e detecção

Resposta rápida

Um Offense no QRadar é um caso priorizado criado quando o Custom Rules Engine correlaciona Eventos ou Flows de acordo com uma regra. Uma investigação profissional não começa e termina com a Magnitude: é preciso entender a regra que disparou, abrir os Eventos e Flows contribuintes, verificar Source, Destination, ativos, tempo e contexto de negócio, e então documentar a decisão e o Closing Reason.

O IBM QRadar recebe Eventos de fontes de log e Flows de fontes de tráfego, os processa através do Custom Rules Engine — CRE — e pode gerar um Offense quando as condições de uma Rule são atendidas. Um Offense centraliza as informações necessárias para priorização e investigação, mas não é prova de que um ataque ocorreu. É um caso que diz: “O sistema de detecção viu um padrão que justifica uma verificação”.

O erro comum é olhar para a Magnitude, abrir alguns Eventos recentes e fechar o caso. A Magnitude de fato ajuda na priorização, mas o QRadar a calcula a partir de uma combinação de Relevância, Gravidade e Credibilidade, e também considera fatores como o número de Eventos e Flows, número de fontes, idade do Offense, peso dos ativos e contexto de vulnerabilidades. Portanto, é preciso decompor o caso em seus componentes.

O que cria um Offense

Uma Rule no QRadar é um conjunto de Testes que são aplicados a um Evento, Flow, série de eventos, Offense ou outra combinação, dependendo do tipo da regra. Quando as condições são atendidas, uma Resposta pode criar um Offense, adicionar dados a um Reference set, enviar uma notificação ou executar outra ação. O nome da Rule é apenas um ponto de partida; o analista deve entender a pilha de Testes e o Scope dos dados.

Antes de abrir Raw events, pergunte: É uma Event rule ou uma Flow rule? Trata-se de um Threshold em uma janela de tempo? A condição é Stateful? A Rule depende de um Building Block que define um grupo, por exemplo, “servidores de e-mail” ou “scanners de vulnerabilidades”? O Offense está associado a um Source IP, Destination IP, Username ou outra característica?

Campo no Offense	O que ele diz	O que ele não diz
Rule(s)	Qual lógica contribuiu para a criação	Que a lógica está correta no ambiente atual
Magnitude	Métrica de priorização calculada	Probabilidade de violação
Source/Destination	A entidade à qual o QRadar associou o caso	Necessariamente o atacante e a vítima
Event/Flow count	Volume de registros contribuintes	Número de operações únicas
Start/Last event	Janela observada no Offense	Necessariamente o início e o fim do evento real

Magnitude, Relevance, Credibility e Severity

A Magnitude mede a importância do Offense no ambiente e é usada para classificação. A Relevance refere-se ao impacto potencial na rede e nos ativos. A Credibility representa a confiabilidade do sinal e é influenciada, entre outras coisas, pela confiabilidade da fonte de log e pelo reforço de outras fontes. A Severity refere-se ao nível da ameaça em relação à prontidão do alvo. O QRadar reavalia a Magnitude quando novos dados são adicionados e em horários agendados.

Não interprete cada pontuação isoladamente sem entender os dados. Uma alta Credibility de uma única fonte não garante que o evento seja malicioso; um Parser pode classificar uma atividade legítima como uma categoria grave. Uma alta Relevance pode resultar de um ativo crítico, mas se o alvo for um Honeypot ou Lab, o contexto é diferente. Uma alta Severity pode ser justificada em termos do tipo de evento, mesmo que a ação tenha sido bloqueada.

Events e Flows: duas lentes

Um Evento geralmente descreve um registro de log: Autenticação, Firewall deny, Processo, Auditoria ou um evento aplicativo. Um Flow descreve uma conversa ou comunicação de rede: fonte, destino, Ports, Protocol, Bytes, Pacotes e tempos. Um Offense pode incluir um ou ambos. A conexão entre Eventos e Flows permite verificar não apenas “o que o produto relatou”, mas também “se o tráfego ocorreu e qual foi seu volume”.

Na investigação, abra a lista de Eventos, classifique por tempo e categoria, e verifique QID, Log Source, Username, Payload e campos personalizados. Em seguida, passe para os Flows: O Source contatou o destino? Houve comunicação bidirecional? Qual foi o volume de dados? A Porta corresponde ao serviço esperado? A ausência de um Flow não prova que não houve comunicação; pode ser que não haja cobertura de NetFlow naquele Segmento.

Source, Destination e Assets

O QRadar correlaciona um Offense por “Offense source” que é determinado pela regra e pelos eventos. Às vezes, o Source é um endereço externo, às vezes um usuário, um Host interno ou um destino. Não presuma que o campo Source é sempre o atacante. No exemplo de um Malware callback, um Source interno pode ser uma estação de trabalho comprometida; no exemplo de um Scan, o Source pode ser um Scanner organizacional autorizado.

O contexto do ativo muda a priorização: um servidor Domain Controller, uma estação de trabalho de administrador e um servidor de testes não são os mesmos. Verifique o Asset weight, Owner, Network hierarchy, aberturas, Vulnerabilities e conexões de negócios. Se o QRadar não reconhece o ativo ou o reconhece com um nome antigo, anote isso como uma lacuna nas evidências.

Fluxo de trabalho de investigação de Offense

Leia Description, Rule(s), Offense type, Source, Destination, Magnitude, Start time e Last event.
Abra a Rule ou os detalhes da regra e entenda os Testes, Threshold, janela de tempo e Building Blocks.
Analise os Eventos contribuintes. Agrupe por QID, Log Source, Username, Source e Destination para identificar recorrências e duplicidades.
Verifique os Flows relacionados, se houver, e procure comunicação antes e depois do Evento central.
Verifique a Network hierarchy e o Asset profile. Pergunte se os endereços são internos, VPN, NAT, Proxy ou Shared infrastructure.
Construa uma Timeline e uma pesquisa complementar em Log Activity e Network Activity para um escopo mais amplo.
Verifique outros Offenses nos mesmos ativos, usuários, Domínios ou Rules. A conexão entre casos pode expandir o Scope.
Classifique, documente Notes, atribua um Owner e decida se deve escalar, fechar ou manter em monitoramento.

Cenário: Múltiplas fontes versus um alvo crítico

No laboratório, foi criado um Offense chamado “Múltiplas falhas de autenticação seguidas de sucesso” em um servidor de arquivos crítico. A Magnitude é 8, existem 180 Eventos de três Log Sources, e o Offense source é um IP interno. A tabela de trabalho pode ser assim:

Verificação	Achado	Possível significado	Próximo passo
Rule	Muitas falhas e então Sucesso	Password spray ou serviço com senha antiga	Verificar usuários e ordem cronológica
Log Sources	AD, VPN, File server	Várias camadas reforçam a história	Confirmar Time sync e NAT
Source IP	Servidor de gestão	Pode ser uma ferramenta de automação	Verificar Owner e Change window
Target	Servidor de arquivos de Produção	Alto impacto nos negócios	Verificar Access e atividade de arquivos
Flows	SMB após Sucesso	Comunicação real	Verificar Bytes, Sessions e outros destinos

Se o Source é um servidor de gestão e as falhas correspondem a um Job que falhou após uma mudança de senha, pode ser um Benign Positive. Mas um Sucesso seguido de SMB para um Share sensível ainda requer verificação da conta e da ação. Se não houver Change aprovado, deve-se escalar para o IR ou para a equipe de identidades, de acordo com o Playbook.

Fechamento, Notes e Tuning

As Notes devem incluir a hipótese, evidências, pesquisas realizadas, lacunas, Classificação e ações. O Closing Reason deve ser consistente para permitir Metrics e Tuning. “False Positive” sem explicação não é suficiente; especifique se a causa raiz é um Scanner autorizado, Parser incorreto, Threshold, Duplicata, Asset context ou atividade de usuário legítima.

O Tuning pode incluir a alteração de uma Rule, Building Block, Reference set, Network hierarchy, Log source credibility ou Asset weight. Qualquer alteração deve ter um Owner, documentação, teste de Regression e data de Review. Não exclua um Source IP inteiro se for possível excluir apenas um Event name, Destination, janela de manutenção ou Service account.

Lista de verificação

Entendi o que criou o Offense e quais Rules contribuíram.
Dividi a Magnitude em seus componentes de contexto e não a usei como prova.
Verifiquei Eventos e Flows quando presentes.
Confirmei Source, Destination, NAT, Proxy e Network hierarchy.
Verifiquei a Asset criticality e Vulnerabilities.
Construí uma Timeline e procurei atividade antes e depois.
Escrevi Notes e Closing Reason detalhados.
Apliquei um Tuning focado com Owner e data de Review.

Erros comuns

Fechar por baixa Magnitude sem abrir os eventos.
Assumir que o Offense source é o atacante.
Contar Eventos sem verificar duplicidades ou Aggregation.
Ignorar Flows ou a falta de cobertura de tráfego.
Confiar em um Asset profile desatualizado.
Alterar uma Rule em produção sem Baseline e Regression test.

Resumo e CTA

Escolha um Offense de laboratório e escreva uma página de investigação: o que o criou, o que a Magnitude diz, quais Eventos e Flows contribuem, quem são o Source e o Destination, qual é o Asset context e qual é a decisão de fechamento. Em seguida, compare sua página com o Ticket de outro analista. O exercício ensina a trabalhar com o QRadar como uma plataforma de investigação e não apenas como uma fila de alertas.

Perguntas frequentes

Qual a diferença entre Evento e Offense?

Um Evento é um registro de origem ou um evento normalizado. Um Offense é um Caso criado depois que o CRE correlacionou dados de acordo com uma Rule e adicionou priorização e contexto.

A Magnitude 10 é sempre mais grave que 8?

É priorizado mais alto de acordo com o cálculo do QRadar, mas a decisão de investigação deve incluir ativos, evidências, tipo de regra e contexto de negócios.

O que é um Flow na investigação?

Um registro de tráfego sumarizado que apresenta as características de uma conversa. Ele pode confirmar comunicação, volume e protocolo, mas nem sempre inclui o Payload.

Quando um Offense é fechado como False Positive?

Somente depois que há uma explicação fundamentada e evidências de que a lógica identificou uma atividade que não é a ameaça pretendida. Às vezes, a classificação correta é Benign Positive ou Duplicate.

A alteração do Closing Reason muda a Rule?

Não. O Closing Reason documenta o resultado da investigação. O Tuning requer uma mudança proativa na Rule, Building Block, Reference set ou outro Contexto.