Which QRadar rule type re-evaluates after an offense is created or updated?

Correct: d. An offense rule is specifically designed to fire after an offense is created or updated in the system, enabling rule chaining and escalation patterns. Event and flow rules fire on individual events and flows respectively.

What distinguishes a building block from a standard QRadar rule?

Correct: c. A building block is a rule whose response type is set to 'No offense'. It packages reusable test conditions under a named block that other rules reference. This is the entire point of building blocks — maintainability through shared logic.

A new threat-intel feed provides a daily list of malicious IPs. You want CRE rules to match against this list in real time. What QRadar feature do you use?

Correct: b. Reference sets are live, in-memory lists updated via the QRadar REST API. You populate the set from your threat-intel feed and write CRE rule tests that check 'source IP is contained in ReferenceSet:MaliciousIPs'. No rule rebuild is needed when the set updates.

Why might a rule never fire even though matching events are arriving in QRadar?

Correct: a. Rule type is the first thing to check. An event rule only evaluates events; a flow rule only evaluates flows. If you write an event rule to detect a flow-based behavior, it will never receive the data it needs to evaluate and will never fire.

What is the safest workflow for deploying a new brute-force detection rule to a production QRadar environment?

Correct: d. Running in monitor mode (Dispatch New Event) for a week lets you measure false-positive rate and tune test conditions before enabling offense creation. Skipping this step is how you flood the SOC queue and lose analyst trust in the detection stack.

A reference map stores username → department for use in rule annotations. Your threat-intel script stopped updating it 48 hours ago. What is the risk?

Correct: b. Reference maps do not self-heal — if the update script fails, the data goes stale. Rules still fire, but offenses lose the enrichment context (department, owner, risk tier) that the map provides, making triage slower. Monitor feed health and alert on unexpected count drops.

IBM QRadar Building Blocks & Reference Sets — CRE Deep Dive (2026)

Q: When does a QRadar CRE rule fire?

Correct: b. The CRE evaluates tests in order and fires only when every test passes. A single passing test is not enough — all conditions must be true for the rule to trigger its response.

Q: You have 30 rules that all need to exclude a monitoring service account. What is the most maintainable approach?

Correct: a. A building block packages the exclusion test once. All 30 rules reference it by name, so a single change to the building block propagates to all dependents — no individual rule editing required.

Q: What kind of QRadar reference data would you use to store a live list of known malicious IPs?

Correct: c. A reference set is a flat list of values (IPs, usernames, hashes) that can be tested for membership inside a CRE rule. It is updated live via the API or console without any rule rebuild.

Q: A brute-force rule with no response limiter is flooding the offense queue with hundreds of offenses per attack. What is the correct fix?

Correct: c. A response limiter collapses repeated firings for the same correlated context into one offense per time window, preserving analyst bandwidth without removing visibility entirely.

Most engineers think…

Most people picture QRadar rules as simple if-then statements — 'if we see a failed login, alert'. That mental model breaks the moment you try to tune noise in a real SOC.

QRadar's Custom Rules Engine (CRE) is more layered: rules are stacks of test conditions that are evaluated in order, building blocks let you factor out common tests so twenty rules share one definition, and reference sets turn your threat-intel feeds into live lookup tables inside rule logic. Add response limiters to control how often offenses re-fire, and you have a noise-controlled, maintainable detection stack — not a pile of single-use alert rules.

① How the Custom Rules Engine (CRE) works

Every event and flow that arrives in QRadar is passed through the Custom Rules Engine (CRE) — a sequential rule evaluator. Each rule contains an ordered list of test conditions. The CRE evaluates those tests from top to bottom; only when all tests pass does the rule fire.

When a rule fires it can do one of several things: create or update an offense (the primary use case), dispatch a response such as sending an email or running a script, or simply annotate the event. Rules also carry a rule name, a log source scope, and an enable/disable toggle — disabled rules are skipped entirely by the engine.

Rules are evaluated in real time against the event pipeline. QRadar uses the rule's test group type — event rules fire on individual events, flow rules on flows, common rules on both, and offense rules re-evaluate after an offense is created. Getting the type right is the first thing to check when a rule never fires.

Figure 1 — CRE evaluation pipeline — event to offense

Every event passes the CRE test stack in order; a rule fires only when all tests pass.

Figure 2 — QRadar rule types — which events they see

Rule type determines what the CRE feeds into the test stack — choose wrong and the rule never fires.

Quick check · Q1 of 10 · Understand

When does a QRadar CRE rule fire?

a) When any single test in its list passesb) When all ordered test conditions in the rule passc) Only when the event comes from a network IDSd) Only during scheduled batch processing

Correct: b. The CRE evaluates tests in order and fires only when every test passes. A single passing test is not enough — all conditions must be true for the rule to trigger its response.

👉 So far: The CRE evaluates ordered tests; all must pass for a rule to fire. Rule type (event/flow/common/offense) determines what the engine feeds into the test stack.

② Building blocks — reusable rule fragments

A building block is a QRadar rule configured to not generate an offense on its own. Instead, it packages a group of tests under one name so other rules can reference it as a single logical block. Think of it as a named boolean: IS_ADMIN_LOGIN might test that the event category is Authentication Success AND the username is in the Admins reference set. Any rule that needs that logic includes the building block by name rather than re-typing the tests.

Why building blocks matter in production

In a real QRadar estate you may have dozens of rules that all need to exclude noise from a monitoring account. Without building blocks you update every rule individually. With a building block called BB:ExcludeMonitoringAccounts, one edit propagates everywhere. Building blocks also make rule logic readable — the offense rule tests three or four named blocks rather than fifteen raw conditions.

You create a building block in Offenses > Rules > Actions > New Building Block Rule. The key difference from a normal rule is in the Rule Response tab — leave the response type as No offense.

Figure 3 — Building block — shared logic, many rules

One building block definition is referenced by many offense rules, so one edit propagates everywhere.

⚙️

Custom Rules Engine (CRE)

tap to flip

QRadar's real-time rule evaluator — tests every event and flow against ordered test conditions; fires a response only when all tests pass.

🧩

Building Block

tap to flip

A rule with no offense response, used purely to package reusable test conditions. Other rules reference it by name, so one edit updates all dependents.

📋

Reference Set

tap to flip

A live, in-memory flat list (IPs, usernames, hashes) that CRE rules test membership against in real time — updated via API or console without a rule rebuild.

⏱️

Response Limiter

tap to flip

Controls how often a rule fires its response for the same correlated context — e.g. once per source IP per 10 minutes — to prevent offense queue flooding.

Name building blocks with a BB: prefix

The QRadar convention is to prefix building block names with 'BB:' — for example 'BB:ExcludeServiceAccounts'. This makes building blocks instantly identifiable in the rule list and in test conditions, and distinguishes them from offense-generating rules at a glance.

Quick check · Q2 of 10 · Apply

You have 30 rules that all need to exclude a monitoring service account. What is the most maintainable approach?

a) Create a building block with the exclusion test and reference it in all 30 rulesb) Add an exclusion test to each of the 30 rules individuallyc) Disable all 30 rules when the monitoring account is actived) Create a separate rule for each log source

Correct: a. A building block packages the exclusion test once. All 30 rules reference it by name, so a single change to the building block propagates to all dependents — no individual rule editing required.

👉 So far: Building blocks are reusable sub-rule fragments (response = No Offense). Reference them by name in many rules; one edit propagates everywhere. Prefix with BB: by convention.

③ Reference sets, maps and map-of-sets

Reference sets are dynamic lists — a flat collection of IP addresses, usernames, hostnames, or hashes that rules can test membership against. The test reads: source IP is contained in ReferenceSet:KnownThreatIPs. You populate reference sets via the Admin console, the REST API, a custom action script, or an automated feed. Anything that can POST to the QRadar API can update a reference set in real time.

A reference map is a key → single-value lookup (e.g. username → department). A reference map-of-sets is a key → set-of-values lookup (e.g. IP → set of observed ports). Rules can test whether a key exists in a map, or retrieve the value to use in a rule test or an offense annotation. This lets you join threat-intel context to an alert at rule-fire time rather than hunting for it after the fact.

The important operational point: reference sets and maps are not static files. They are live, in-memory structures in the QRadar Data Node. A rule that tests membership in a reference set gets the current state of that set at the moment the event arrives. If you remove an IP from the set, the next event from that IP will not match — no rule rebuild required.

Figure 4 — Reference set vs reference map vs map-of-sets

Three reference data structures serve different lookup needs in CRE rule tests.

Treating reference sets as static config files

Reference sets are live, in-memory structures updated via the API. If you rebuild them only at deployment time you lose the real-time advantage — threat-intel additions will not take effect until the next rebuild. Automate the feed: have your TI platform POST to the QRadar reference set REST endpoint continuously.

▶ Watch a failed login trigger a CRE rule and raise an offense

Step through how a single authentication failure becomes a QRadar offense via reference set lookup. Press Play for the healthy path, then Break it.

① Event arrivesAn authentication failure event from a Linux host arrives in QRadar and enters the CRE evaluation pipeline.

▼

② Ref set checkThe CRE tests whether the source IP is contained in ReferenceSet:KnownBruteForceActors — a live list maintained by the threat-intel feed.

▼

③ Rule firesThe source IP is in the reference set; all rule tests pass. The CRE fires the brute-force detection rule.

▼

④ Offense raisedA new offense is created, annotated with the matching reference set entry and the source context from the reference map. The SOC analyst sees it in the offense queue.

Press Play to step through the healthy path. Then press Break it to see the classic failure.

Quick check · Q3 of 10 · Remember

What kind of QRadar reference data would you use to store a live list of known malicious IPs?

a) A reference map-of-setsb) A reference tablec) A reference setd) A building block

Correct: c. A reference set is a flat list of values (IPs, usernames, hashes) that can be tested for membership inside a CRE rule. It is updated live via the API or console without any rule rebuild.

👉 So far: Reference sets = live flat lists; reference maps = key to single value; reference map-of-sets = key to set of values. All update in real time via the REST API — no rule rebuild needed.

④ Response limiters, chaining and tuning for production

A response limiter (also called a rule response limiter) controls how often a rule fires its response action for the same correlated context. The most common setting is: fire no more than once per source IP per 10 minutes. Without a limiter, a brute-force attack with hundreds of events per minute creates hundreds of offenses in the queue, drowning analysts. With a limiter, you still get one offense per attacker per window.

Rule chaining

Rule chaining is the pattern of using one rule's offense as input to another. A first rule fires on any authentication failure and creates a small-magnitude offense; a second rule — scoped to offenses of type Authentication Failure — re-evaluates after the offense is created and escalates only if the count exceeds a threshold. This gives you both visibility (offense exists from event 1) and noise control (escalation only after real brute-force volume).

Tuning workflow: start in monitor mode (rule response = Dispatch New Event, not Create Offense), watch the rule log for a week, then promote the rule to create offenses once you have confirmed the false-positive rate is acceptable. Keep your response limiters aligned with the attack window — too short and you miss sustained attacks, too long and you mask follow-on behavior.

Figure 5 — Response limiter — brute-force without noise

The limiter collapses hundreds of events into one offense per attacker window, preserving analyst bandwidth.

Arjun at a Mumbai fintech's SOC faces this

A new brute-force detection rule creates 800 offenses in one hour during a penetration test, drowning the analyst queue and causing real alerts to be missed.

Likely cause

The rule has no response limiter, so every authentication failure event from the pen-test source creates a separate offense.

Diagnosis

Open Offenses — the queue shows hundreds of offense entries all from the same source IP and same rule. The rule in the Rule Editor has no limiter set under the Rule Response tab.

Offenses ▸ Rules ▸ Select rule ▸ Edit ▸ Rule Response ▸ Limiter

Fix

Add a response limiter: fire no more than once per source IP per 10 minutes. Additionally, consider using rule chaining — a first rule dispatches an event for visibility; a second offense rule escalates only when the count in a reference set exceeds the threshold.

Verify

Re-run the pen-test scenario: the offense queue shows one offense per attacker IP per 10-minute window, not hundreds. Real alerts from other sources are no longer buried.

Test rules in monitor mode before enabling offenses

Before setting a rule response to 'Create Offense', switch it to 'Dispatch New Event' for a week and watch the custom event log. Confirm the false-positive rate is acceptable, then promote to offense creation. Skipping this step is how you flood the SOC queue on day one.

Quick check · Q4 of 10 · Analyze

A brute-force rule with no response limiter is flooding the offense queue with hundreds of offenses per attack. What is the correct fix?

a) Delete the rule and write a new oneb) Increase the QRadar license to handle more offensesc) Add a response limiter — e.g. fire once per source IP per 10 minutesd) Switch the rule type from event to flow

Correct: c. A response limiter collapses repeated firings for the same correlated context into one offense per time window, preserving analyst bandwidth without removing visibility entirely.

👉 So far: Response limiters cap offense creation per correlated context per time window. Use rule chaining for tiered visibility: first rule dispatches event, second rule escalates only on volume threshold.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 In your own words

In one line: what is the relationship between a building block and a CRE rule — and why does it matter for maintenance? Then compare with the expert version.

Expert version: A building block is a rule with no offense response whose sole purpose is to package reusable test conditions under a single name. A CRE rule references that building block as one of its tests, so when the shared logic needs to change — for example, a new service account must be excluded — you edit only the building block and every rule that references it is instantly updated. Without building blocks you must manually update each of the dozens of rules that share the same test, which is error-prone and slow in an active SOC.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on IBM QRadar at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

Custom Rules Engine (CRE): QRadar's real-time rule evaluator — tests ordered conditions against every event and flow; fires a response only when all conditions pass.
Building Block: A rule with response type 'No Offense' that packages reusable test conditions under a named block for other rules to reference.
Reference Set: A live, in-memory flat list (IPs, usernames, hashes) stored in QRadar that CRE rules test for membership in real time, updated via the REST API.
Reference Map: A live key-to-single-value store (e.g. IP → department) used to enrich rule logic or offense annotations with context from external data.
Reference Map-of-Sets: A live key-to-set-of-values store (e.g. IP → observed ports) used for multi-value lookups inside CRE rule tests.
Response Limiter: A rule setting that caps how often the rule creates an offense for the same correlated context within a defined time window.
Rule Chaining: Using one rule's offense output as the trigger for a second rule (offense rule), enabling tiered detection: visibility at event 1, escalation on volume threshold.
Offense Rule: A QRadar rule type that re-evaluates after an offense is created or updated, enabling chaining and post-creation escalation logic.

📚 Sources

IBM — IBM QRadar SIEM Administration Guide: Custom Rules Engine and Rule Types. ibm.com/docs/en/qradar-siem
IBM — QRadar Reference Sets, Reference Maps and Reference Map-of-Sets. ibm.com/docs/en/qradar-siem
IBM — QRadar Rule Response Limiters and Offense Management. ibm.com/docs/en/qradar-siem
IBM Security Learning Academy — QRadar SIEM Foundations: Building Blocks and Rule Best Practices. securitylearningacademy.com
IBM — QRadar REST API Reference: Reference Data Collections (reference sets, maps). ibm.com/docs/en/qradar-siem
IBM — QRadar Deployment Intelligence: Tuning and Noise Reduction with Response Limiters. ibm.com/support

What's next?

Understand the CRE rules engine? Next, go deep on QRadar offense management — how offenses are created, merged, closed and escalated — and why the offense index determines which event owns the case.

Next · All interview lessons → Practice on exam.techclick.in →

IBM QRadar Building Blocks & Reference Sets — CRE Rules Engine Deep Dive

🎯 By the end you will be able to

Pick where you want to start

CRE basics

Building blocks

Reference sets & maps

Limiters & tuning

① How the Custom Rules Engine (CRE) works

② Building blocks — reusable rule fragments

Why building blocks matter in production

③ Reference sets, maps and map-of-sets

▶ Watch a failed login trigger a CRE rule and raise an offense

④ Response limiters, chaining and tuning for production

Rule chaining

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?