Cybersecurity & Information Security

QRadar Rules and Building Blocks: A Practical Guide

6 min readPublished: August 5, 2026

Professional visual illustration on QRadar Rules and Building Blocks in the SIEM and detection field

Quick answer

In QRadar, a Rule is a collection of Tests that triggers a Response when conditions are met. A Building Block uses the same Tests to describe a group or recurring logic but does not trigger a Response itself. Good planning starts with the Use Case and data, orders Tests from the cheapest and most restrictive to the most expensive, uses State and Reference sets carefully, and is tested before deployment to production.

The Custom Rules Engine — CRE — is the engine that evaluates Events, Flows, and Offenses against QRadar Rules. A good Rule is not a single “if-then statement.” It is a translation of a logical Use Case into a real-time system: what data comes in, what are the conditions, what is the time window, how is State maintained, what is the grouping unit, and what happens when there is a match.

Building Blocks allow separating environmental knowledge from the Rule's logic. Instead of writing a list of mail servers, vulnerability scanners, or Privileged accounts in every Rule, you can define a Building Block and use it in several Rules. Since a Building Block has no responses, it serves as a maintainable logical component.

How CRE Evaluates Events and Flows

When an Event or Flow arrives in QRadar, it is normalized and passed through the CRE. The engine evaluates relevant Rules based on the data type. A Test can check a simple Property, category, Log Source, Network location, a value in a list, Regex in a Payload, or a sequence over time. If all conditions are met, a Rule Response is triggered.

The order of Tests is important for performance. IBM recommends starting with conditions that reduce the amount of data: Log Source Type, Network, Event category, or Direction. Then add IP, Port, Username, or other attributes. Payload and Regular Expression should come later, as they are more expensive. A Rule that applies Regex to all Events in an organization can create a load even if the result is correct.

Rule vs. Building Block

Attribute	Rule	Building Block
Purpose	Identify a condition and trigger a Response	Describe a group or recurring logic
Tests	Yes	Yes, same types of Tests
Response	Yes, by definition	No
Reusability	Possible but less modular	Intended for use within Rules and other Building Blocks
Example	Many failures for different accounts from the same IP	BB: Privileged Accounts or BB: Approved Scanners

A Building Block is not a “weak Rule.” It's a logic library. For example, BB:Approved Scanners can contain IPs or Network ranges of vulnerability scanners. A Rule to detect an external Scan can add a condition NOT when source matches BB:Approved Scanners. If the scanner changes, one component is updated.

However, overuse of Building Blocks creates a dependency chain that is difficult to understand. Document Owner, Purpose, and Consumers. A name like BB:Temp2 is not useful. A good name explains Scope, for example BB:HostDefinition:DomainControllers or BB:UserDefinition:PrivilegedAccounts.

Types of Rules

QRadar supports various Rule types. Event rules examine Log Activity data. Flow rules examine Network Activity. Common rules can work with attributes shared by Events and Flows. Offense rules examine Offense attributes to trigger additional Responses. The choice should match the data and constraint.

If the question is “Has a user failed to log in many times?”, an Event rule is appropriate. If the question is “Has a Host generated abnormal traffic volume?”, a Flow rule might be appropriate. If a response is needed only when a specific Offense reaches a certain Magnitude or acquires an attribute, an Offense rule can be relevant.

Stateful Tests and Thresholds

A Stateful Test remembers activity over a time window. Examples: more than N Events from the same Source, activity against more than M Destinations, or a series of events. You must define a Key by which to count: Source IP, Username, Destination, a combination of fields, or another value. An incorrect Key will mix entities or split a Pattern.

A Threshold should be based on a Baseline. Ten failures in five minutes may be abnormal for a regular user but expected for a RADIUS server. A short window identifies a Burst; a long window identifies slow activity but increases State and noise. Write down the Threat behavior in advance, not just “a number that seems reasonable.”

Component	Design Question	Risk if Incorrect
Grouping key	Which entity is being counted?	Mixing users or splitting an attacker
Threshold	What volume justifies detection?	Noise or missed detection
Time window	What is the behavior rate?	Missing a Slow attack or unnecessary State
Reset/expiry	When does the history expire?	Old events affecting a new decision
Exclusions	What activities are expected?	Sweeping blind spot

Responses and Reference Sets

A Response can create an Offense, send an Email or Syslog, add a value to a Reference set, dispatch an Action, or perform another operation depending on permissions and version. Separate Detection from Response: a Rule can be correct but a Response dangerous. During initial Tuning, prefer Offense creation or Notification before automated Blocking.

A Reference set is a collection of unique values that can be used in searches, Filters, Tests, and Responses. It can store IOCs, users, IPs, or business context. A Rule can check if a value is in a list or add it. Define Type, TTL, or a cleanup process, Owner, and source. An old Reference set of IOCs can generate False Positives or hide activity if used for Whitelisting.

Exercise: Planning a Multi-Stage Rule for Password Spray

This exercise is planning only in a lab environment. The goal: to identify a Source IP that generates failures against many users, not just many failures against one user.

Stage	Proposed Logic	Explanation
Scope	Events from Authentication Failure category from identical sources	Early filter
Network	Source is not in BB:ApprovedIdentityInfrastructure	Excludes approved infrastructure modularly
State	Same Source IP against at least 8 different Usernames within 10 minutes	Expresses Spray rather than Brute force for a single account
Context	Destination in organizational domain and user is not Test account	Adds business Scope
Response	Create offense + Add Source to temporary reference set	Enables Case and time-limited tracking

Before deployment, check VPN, Proxy, and NAT data. A shared Source address can represent many legitimate users. A combined Key of Source, Application, and Tenant may be needed. Also check if Username is normalized; changing letters or a Domain prefix can inflate the number of unique users.

Testing and Tuning

Write a Detection specification: Threat behavior, Data source, fields, key, threshold, window, exceptions, and response.
Run a Historical search to understand the Baseline. CRE operates in real-time, but historical search helps estimate volume and examples.
Test simulated Positive cases and Negative cases. Ensure the Rule is not dependent on a field missing in some Log Sources.
Deploy in a Test environment or with a conservative response mode. Measure Offense volume and Event contribution.
Check performance: broad Tests initially, Regex/Payload at the end, and avoidance of a Global rule if Local is sufficient.
Document every Exception with a reason, Owner, and expiration date. Prefer a managed Building Block or Reference set.
After a change, perform a Regression test on real and simulated cases.

Checklist Before Enable

Use Case and threat are clearly articulated.
Rule type is suitable for Event, Flow, or Offense.
Tests are ordered from most restrictive and cheapest to most expensive.
Grouping key, Threshold, and Time window have been verified.
Building Blocks are documented and do not create circular dependencies.
Reference sets include Owner, source, and expiration process.
Response is safe and appropriate for the Confidence level.
A plan exists for Tuning, Metrics, and Rollback.

Common Mistakes

Starting with Regex on Payload instead of filtering Log Source and category.
Copying a Rule from another environment without Network hierarchy and Asset context.
Using a Building Block as a sweeping Whitelist.
Defining a Global rule when Local is sufficient.
Counting by Source IP in a NAT environment without additional Context.
Adding values to a Reference set without Expiration.
Enabling automated response before Tuning.

Summary and CTA

Build a Rule specification for Password Spray in the lab, but do not deploy immediately. Present the Tests in order, mark which ones are Stateless and which are Stateful, define a Building Block for approved infrastructure, and write a conservative Response. Then ask someone else to explain the Rule solely from the documentation. If they cannot, the Rule is not yet ready.

FAQ

Can a Building Block create an Offense?

Not directly. It uses Tests but does not include Responses. A Rule that refers to it can create an Offense.

What is the difference between a Local and a Global rule?

A Local rule is processed by the Event Processor where the data was received. A Global rule sends matches to the console for broader processing and may consume more resources. The choice depends on the Scope.

When should I use a Reference set?

When you need a managed list of values for use in searches, Tests, or Responses, such as IOCs or a user group. Expiration and source should be managed.

How do you choose a Threshold?

Using a Threat model and local Baseline. There is no universal number. Also check Distribution, not just the average.

Can a Rule check a sequence?

Yes, certain Test types track series and Counters over time. A Key and window must be defined, and State costs evaluated.