# IBM QRadar Building Blocks & Reference Sets — CRE Rules Engine Deep Dive Source: https://ai.techclick.in/blog_ibm_qradar_building_blocks_reference_sets Markdown: https://ai.techclick.in/blog_ibm_qradar_building_blocks_reference_sets.md Publisher: Techclick Infosec Pvt Ltd Master IBM QRadar's Custom Rules Engine (CRE) in 2026: building blocks, reference sets and maps, response limiters, test conditions, and how to author threat-detection rules that fire only on real threats. IBM QRadar Building Blocks & Reference Sets — CRE Rules Engine Deep Dive student learning map A visual study map for IBM QRadar Building Blocks & Reference Sets — CRE Rules Engine Deep Dive showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP IBM QRadar Building Blocks & Reference Sets —... IBM · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① How the Custom Rules Engine... 4. Practice ② Building blocks — reusable rule... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. - CRE evaluation pipeline — event to offense Event arrives log source ingests Test 1..N CRE evaluates each Rule fires all tests passed Response offense / email / script Offense queue analyst triage 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. QRadar rule types — which events they see Event rule Evaluates each individual event in the event pipeline Flow rule Evaluates each network flow captured by QRadar Common rule Evaluates both events and flows with shared tests Offense rule Re-evaluates after an offense is created or updated 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 passes b) When all ordered test conditions in the rule pass c) Only when the event comes from a network IDS d) 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. Building block — shared logic, many rules Building Block named test group Brute-force rule Privilege escalation Data exfil rule Lateral movement Insider threat rule 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 rules b) Add an exclusion test to each of the 30 rules individually c) Disable all 30 rules when the monitoring account is active d) 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. Reference set vs reference map vs map-of-sets Reference Set Flat list of values Test: IP in set? Good for threat-IP lists Updated via API or console Reference Map / Map-of-Sets Key maps to value(s) Test: key exists? get value Good for IP-to-dept lookups Joins context to offenses 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 arrives An authentication failure event from a Linux host arrives in QRadar and enters the CRE evaluation pipeline. ▼ ② Ref set check The CRE tests whether the source IP is contained in ReferenceSet:KnownBruteForceActors — a live list maintained by the threat-intel feed. ▼ ③ Rule fires The source IP is in the reference set; all rule tests pass. The CRE fires the brute-force detection rule. ▼ ④ Offense raised A 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. ▶ Play Next ▶ ⚠ Break it ↺ Reset 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-sets b) A reference table c) A reference set d) 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. Response limiter — brute-force without noise 100+ failures same source IP Limiter check fired in last 10 min? First fire create offense once Suppress rest within the window New window limiter resets 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 one b) Increase the QRadar license to handle more offenses c) Add a response limiter — e.g. fire once per source IP per 10 minutes d) 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. What is the Custom Rules Engine (CRE) in QRadar? What is a building block and why is it used? What is the difference between a reference set and a reference map? How does a response limiter work and when should I set one? What is rule chaining in QRadar? How do I safely test a new CRE rule without flooding the offense queue? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which QRadar rule type re-evaluates after an offense is created or updated? a) Event rule b) Flow rule c) Common rule d) Offense rule 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. Q6 · Understand What distinguishes a building block from a standard QRadar rule? a) Building blocks run only on flows, not events b) Building blocks can only reference external threat feeds c) Building blocks have no offense response — they package reusable tests for other rules to reference d) Building blocks require a separate QRadar license module 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. Q7 · Apply 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? a) Create a new event rule for each IP address b) Populate a reference set via the REST API and test membership in CRE rules c) Add each IP to a building block as a static test condition d) Import the list into a QRadar offense directly 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. Q8 · Analyze Why might a rule never fire even though matching events are arriving in QRadar? a) The rule type does not match the data type (e.g. a flow rule receiving events) b) The reference set contains too many entries c) Building blocks always prevent offense creation d) Response limiters permanently disable rules after the first fire 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. Q9 · Evaluate What is the safest workflow for deploying a new brute-force detection rule to a production QRadar environment? a) Deploy with response = Create Offense and fix noise later b) Clone an existing rule and enable it without testing c) Set the response limiter to one second to capture every event d) Deploy with response = Dispatch New Event, monitor for a week, tune false positives, then switch to Create Offense 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. Q10 · Evaluate 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? a) QRadar will automatically rebuild the map from log sources b) Offenses will be raised with stale or missing department context, reducing analyst efficiency c) The CRE will crash and stop processing events d) All rules that reference the map will be automatically disabled 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. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 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. Compare with expert answer 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. Generate my one-liner 📩 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 → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt