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

Regras e Blocos de Construção do QRadar: Um Guia Prático

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre Regras e Blocos de Construção do QRadar na área de SIEM e Deteção

Resposta rápida

No QRadar, uma Regra é uma coleção de Testes que aciona uma Resposta quando as condições são atendidas. Um Bloco de Construção usa os mesmos Testes para descrever um grupo ou lógica reutilizável, mas não aciona uma Resposta por si só. Um bom planeamento começa com o Use Case e os dados, ordena os Testes do mais barato e restritivo para o mais caro, usa State e Reference sets com cuidado, e é testado antes da produção.

O Custom Rules Engine — CRE — é o motor que examina Eventos, Flows e Offenses contra as Regras do QRadar. Uma boa Regra não é uma única “instrução se-então”. É a tradução de um Use Case lógico para um sistema em tempo real: quais dados entram, quais são as condições, qual é a janela de tempo, como o Estado é mantido, qual é a unidade de agrupamento e o que acontecerá quando houver uma correspondência.

Os Blocos de Construção permitem separar o conhecimento ambiental da lógica da Regra. Em vez de escrever em cada Regra uma lista de servidores de e-mail, scanners de vulnerabilidades ou contas Privileged, é possível definir um Bloco de Construção e usá-lo em várias Regras. Como o Bloco de Construção não tem respostas, ele serve como um componente lógico que pode ser mantido.

Como o CRE avalia Eventos e Flows

Quando um Evento ou Flow chega ao QRadar, ele é normalizado e passado pelo CRE. O motor examina as Regras relevantes de acordo com o tipo de dado. Um Teste pode verificar uma Propriedade simples, Categoria, Log Source, Network location, valor numa lista, Regex no Payload ou sequência ao longo do tempo. Se todas as condições forem atendidas, a Resposta da Regra é acionada.

A ordem dos Testes é importante para o desempenho. A IBM recomenda começar com condições que reduzam a quantidade de dados: Log Source Type, Network, Event category ou Direction. Em seguida, adicione IP, Port, Username ou outras características. Payload e Regular Expression devem vir mais tarde, porque são mais caros. Uma Regra que aplica Regex a todos os Eventos na organização pode criar uma sobrecarga, mesmo que o resultado seja correto.

Regra vs. Bloco de Construção

Característica	Regra	Bloco de Construção
Objetivo	Identificar uma situação e acionar uma Resposta	Descrever um grupo ou lógica reutilizável
Tests	Sim	Sim, os mesmos tipos de Testes
Resposta	Sim, de acordo com a definição	Não
Reutilização	Possível, mas menos modular	Projetado para uso em Regras e outros Blocos de Construção
Exemplo	Muitas falhas para contas diferentes do mesmo IP	BB: Privileged Accounts ou BB: Approved Scanners

Um Bloco de Construção não é uma “Regra fraca”. É uma biblioteca de lógica. Por exemplo, BB:Approved Scanners pode conter IPs ou Network ranges de scanners de vulnerabilidades. Uma Regra para identificar Scan externo pode adicionar a condição NOT when source matches BB:Approved Scanners. Se o scanner mudar, atualiza-se um componente.

No entanto, o uso excessivo de Blocos de Construção cria uma cadeia de dependência difícil de entender. Documente Owner, Purpose e Consumers. Um nome como BB:Temp2 não é útil. Um bom nome explica o Scope, por exemplo BB:HostDefinition:DomainControllers ou BB:UserDefinition:PrivilegedAccounts.

Tipos de Regras

O QRadar suporta diferentes tipos de Regras. As Regras de Evento examinam dados de Log Activity. As Regras de Flow examinam Network Activity. As Regras comuns podem funcionar com características partilhadas por Eventos e Flows. As Regras de Offense examinam as características de um Offense para acionar Respostas adicionais. A escolha deve corresponder aos dados e à restrição.

Se a pergunta for “O utilizador falhou em entrar várias vezes?”, uma Regra de Evento é apropriada. Se a pergunta for “O Host gerou tráfego com volume anormal?”, uma Regra de Flow pode ser apropriada. Se for necessário reagir apenas quando um Offense específico exceder a Magnitude ou receber uma característica, uma Regra de Offense pode ser relevante.

Stateful Tests e Thresholds

Um Stateful Test memoriza a atividade ao longo de uma janela de tempo. Exemplos: mais de N Eventos da mesma Origem, atividade para mais de M Destinos, ou uma sequência de eventos. Deve-se definir uma Key pela qual se conta: Source IP, Username, Destination, combinação de campos ou outro valor. Uma Key incorreta misturará entidades ou dividirá um Pattern.

O Threshold deve ser baseado numa Baseline. Dez falhas em cinco minutos podem ser anormais para um utilizador comum, mas esperadas num servidor RADIUS. Uma janela curta deteta um Burst; uma janela longa deteta atividade lenta, mas aumenta o Estado e o ruído. Escreva com antecedência qual é o Threat behavior, não apenas “um número que parece razoável”.

Componente	Questão de planeamento	Risco se incorreto
Grouping key	Sobre qual entidade se conta?	Mistura de utilizadores ou divisão do atacante
Threshold	Qual volume justifica a identificação?	Ruído ou falha
Time window	Qual é a taxa de comportamento?	Perda de ataque lento ou Estado desnecessário
Reset/expiry	Quando a história expira?	Eventos antigos afetam uma nova decisão
Exclusions	Quais atividades são esperadas?	Ponto cego abrangente

Responses e Reference sets

Uma Resposta pode criar um Offense, enviar Email ou Syslog, adicionar um valor a um Reference set, executar o Dispatch de uma Action ou outra operação de acordo com as permissões e a versão. Separe a Deteção da Resposta: uma Regra pode ser correta, mas uma Resposta perigosa. No início do Tuning, prefira a criação de um Offense ou Notificação antes de um Blocking automático.

Um Reference set é uma coleção de valores únicos que pode ser usada em pesquisas, Filters, Tests e Responses. É possível armazenar IOCs, utilizadores, IPs ou Contexto de negócio. Uma Regra pode verificar se um valor está na lista ou adicioná-lo. Defina Type, TTL ou processo de limpeza, Owner e origem. Um Reference set antigo de IOCs pode gerar False Positives ou ocultar atividade se usado para Whitelist.

Exercício: Planeamento de uma Regra de várias etapas para Password Spray

O exercício é apenas planeamento num ambiente de laboratório. Objetivo: identificar um Source IP que gera falhas para vários utilizadores, e não apenas muitas falhas para um único utilizador.

Etapa	Lógica sugerida	Explicação
Scope	Eventos da categoria Authentication Failure de fontes idênticas	Filtro precoce
Network	A Origem não está em BB:ApprovedIdentityInfrastructure	Exclui infraestrutura aprovada de forma modular
State	O mesmo Source IP contra pelo menos 8 Usernames diferentes dentro de 10 minutos	Expressa Spray e não Brute force para uma única conta
Context	Destino na área organizacional e o utilizador não é uma conta de Teste	Adiciona Scope de negócio
Response	Criar offense + Adicionar Source a um Reference set temporário	Permite Case e acompanhamento por tempo limitado

Antes da implementação, verifique os dados de VPN, Proxy e NAT. Um endereço Source partilhado pode representar muitos utilizadores legítimos. Pode ser necessário uma Key combinada de Source, Application e Tenant. Verifique também se o Username é normalizado; alteração de letras ou Domain prefix pode inflacionar o número de utilizadores únicos.

Testing e Tuning

Escreva a especificação de Deteção: Threat behavior, Data source, fields, key, threshold, window, exceptions e response.
Execute uma pesquisa histórica para entender a Baseline. O CRE opera em tempo real, mas a pesquisa histórica ajuda a avaliar o volume e exemplos.
Teste casos positivos simulados e casos negativos. Certifique-se de que a Regra não depende de um campo ausente em algumas Log Sources.
Ative num ambiente de Teste ou em modo de resposta conservador. Meça o volume de Offenses e a contribuição de Eventos.
Verifique o desempenho: Testes amplos no início, Regex/Payload no final, e evite Global rule se Local for suficiente.
Documente todas as Exceções com razão, Owner e data de expiração. Prefira um Bloco de Construção ou Reference set gerido.
Após a alteração, execute um teste de Regressão em casos reais e simulados.

Checklist antes de Ativar

O Use Case e a ameaça são formulados de forma clara.
O tipo de Regra é adequado para Evento, Flow ou Offense.
Os Testes são organizados do mais restritivo e barato para o mais caro.
Grouping key, Threshold e Time window foram verificados.
Os Blocos de Construção estão documentados e não criam dependência circular.
Os Reference sets incluem Owner, origem e processo de expiração.
A Resposta é segura e adequada ao nível de Confiança.
Existe um Plano para Tuning, Metrics e Rollback.

Erros comuns

Começar com Regex no Payload em vez de filtrar Log Source e categoria.
Copiar uma Regra de outro ambiente sem Network hierarchy e Asset context.
Usar um Bloco de Construção como Whitelist abrangente.
Definir Global rule quando Local é suficiente.
Contar por Source IP num ambiente com NAT sem Contexto adicional.
Adicionar valores a um Reference set sem Expiration.
Ativar uma resposta automática antes do Tuning.

Resumo e CTA

Construa no laboratório uma Rule specification para Password Spray, mas não implemente imediatamente. Apresente os Testes por ordem, marque quais são Stateless e quais são Stateful, defina um Bloco de Construção para a infraestrutura aprovada e escreva uma Resposta conservadora. Em seguida, peça a outra pessoa para explicar a Regra apenas a partir da documentação. Se não conseguir, a Regra ainda não está pronta.

Perguntas frequentes

Um Bloco de Construção pode criar um Offense?

Não diretamente. Ele usa Tests, mas não inclui Responses. Uma Regra que o referencia pode criar um Offense.

Qual é a diferença entre Local e Global rule?

Local é processada no Event Processor onde os dados foram recebidos. Global envia correspondências para a consola para processamento mais amplo e pode consumir mais recursos. A escolha depende do Scope.

Quando usar um Reference set?

Quando é necessária uma lista de valores gerida para uso em pesquisas, Tests ou Responses, por exemplo IOCs ou um grupo de utilizadores. A expiração e a origem devem ser geridas.

Como escolher um Threshold?

Através de um Threat model e da Baseline local. Não há um número universal. Verifique também a Distribuição e não apenas a média.

Uma Regra pode verificar uma sequência?

Sim, certos tipos de Testes monitorizam séries e Counters ao longo do tempo. É preciso definir a Key e a janela e verificar os custos de State.