# IBM QRadar Rules, Offenses & AQL — From Normalized Events to a Prioritized Offense Source: https://ai.techclick.in/blog_ibm_qradar_rules_offenses Markdown: https://ai.techclick.in/blog_ibm_qradar_rules_offenses.md Publisher: Techclick Infosec Pvt Ltd A clear, interactive guide to IBM QRadar detection and triage (2026): how raw logs are normalized into events with a QID and category, how the Custom Rule Engine (CRE) uses rule tests, building blocks and rule responses, exactly how rules create and contribute to offenses, how offense magnitude is built from relevance, credibility and severity, how to investigate offenses, how to search with AQL (Ariel Query Language), and where the User Behavior Analytics (UBA) app fits. IBM QRadar Rules, Offenses & AQL — From Normalized Events to a Prioritized Offense student learning map A visual study map for IBM QRadar Rules, Offenses & AQL — From Normalized Events to a Prioritized Offense showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP IBM QRadar Rules, Offenses & AQL — From... 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 ① From raw log to normalized event... 4. Practice ② Building rules in the Custom... 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 think a SIEM 'just shows all the alerts' and that an offense is simply 'a log that looked bad'. That model falls apart the moment an interviewer asks how the offense was built or why it ranked where it did. In QRadar there is a clear pipeline. A DSM normalizes a raw log into an event with a QID (which carries the event name, severity and category). The Custom Rule Engine (CRE) runs rules — sets of tests , often reusing building blocks — and a rule's response can create or contribute to an offense . The offense is indexed by an offense source and ranked by magnitude , which QRadar derives from relevance, credibility and severity . Knowing that chain is what lets you explain, tune and triage instead of just staring at a queue. ## ① From raw log to normalized event — the QID recap Nothing in QRadar reasons about raw syslog text directly. A DSM (Device Support Module) parses each incoming log and normalizes it into a structured event with common fields — source IP, destination IP, username, event count and more. The key piece is the QID (QRadar Identifier) . The DSM maps each device's event ID and category to a QID record , and that QID is what carries the human-readable event name , a severity , and a low-level category (which rolls up into one of QRadar's high-level categories). So 'an SSH login failure' from any vendor lands on a consistent QID and category — that normalization is exactly what makes one rule work across many log sources. If events arrive as Unknown or in the wrong category, you fix the event mapping (or QID map) — because rules and magnitude both lean on that category, not on the raw text. Figure 1 — The detection pipeline — log to ranked offense Every QRadar detection runs this chain: a raw log is normalized, the CRE tests it, an offense is built and then ranked. - The detection pipeline — log to ranked offense Raw log from any device Normalize DSM → QID + category CRE tests rules + building blocks Offense created / contributed Magnitude ranked for triage Every QRadar detection runs this chain: a raw log is normalized, the CRE tests it, an offense is built and then ranked. Figure 2 — What a QID gives a normalized event The DSM maps a raw event to a QID, and that QID carries the metadata rules and magnitude rely on. What a QID gives a normalized event Event name Human-readable label, e.g. SSH login failed Severity Baseline threat level stored on the QID Low-level category Rolls up into a high-level category The DSM maps a raw event to a QID, and that QID carries the metadata rules and magnitude rely on. Quick check · Q1 of 10 · Remember Where does a normalized QRadar event get its name, severity and category? a) From the analyst on shift b) From the QID it is mapped to by the DSM c) From the firewall hardware d) From the offense magnitude Correct: b. The DSM maps each raw event to a QID record, and that QID carries the event name, a severity and a low-level category. Rules and magnitude lean on that category, not the raw text. 👉 So far: A DSM normalizes each raw log into an event and maps it to a QID, which carries the event name, severity and category that everything downstream relies on. ## ② Building rules in the Custom Rule Engine (CRE) The Custom Rule Engine (CRE) is where detection logic lives. A rule is a collection of tests that, when all matched, triggers a rule response . Tests can check events, flows, a sequence over time , or even existing offenses. ### Building blocks vs rules A building block (BB) uses the same tests as a rule but has no action of its own — it just defines a reusable condition, like 'is an admin account' or 'is in the DMZ IP set'. Rules then reference building blocks so logic stays clean and consistent. Note the order: building blocks are evaluated before rules . When a rule's tests are satisfied, its rule response decides what happens: dispatch a new event, annotate, change severity/credibility/relevance, email or notify, add to a reference set, and — crucially — create or contribute to an offense . That last response is what turns detection logic into something an analyst sees. Figure 3 — Anatomy of a Custom Rule A rule is tests (often reusing building blocks) wired to a rule response — and that response is what creates an offense. Anatomy of a Custom Rule Custom Rule tests + response Event tests Flow tests Sequence test Building blocks Create offense Notify / dispatch A rule is tests (often reusing building blocks) wired to a rule response — and that response is what creates an offense. 🏷️ QID tap to flip The QRadar Identifier a DSM maps an event to. It carries the event name, severity and low-level category that rules and magnitude rely on. 🧩 Building block tap to flip A reusable set of tests with no action of its own — e.g. 'is an admin account'. Evaluated before rules so they can reference it. 🚨 Offense tap to flip A correlated, prioritized record created by a rule response. Indexed by an offense source (often source IP); later events contribute to it. 📊 Magnitude tap to flip A 0–10 ranking blended from relevance, credibility and severity, plus event counts, asset weight, age and categories. Lean on building blocks, not copy-paste In an interview, say you keep logic DRY by putting reusable conditions ('admin accounts', 'DMZ ranges') in building blocks and referencing them from many rules. Remember they evaluate before rules, so a well-built BB makes every rule that uses it cleaner and faster to tune. Quick check · Q2 of 10 · Understand Which statement about building blocks is correct? a) They are offenses with extra severity b) They are appliances that collect flows c) They use the same tests as rules but have no action, and are evaluated before rules d) They can only test source IP Correct: c. A building block is a reusable condition that uses rule-style tests but performs no action of its own. Building blocks are evaluated before rules so rules can reference them. 👉 So far: The CRE runs rules (tests + a rule response); building blocks are reusable, action-less conditions evaluated before rules. The 'create offense' response is what surfaces detection to analysts. ## ③ How offenses are built — and what drives magnitude An offense is QRadar's prioritized, correlated record of suspicious activity. When a rule with a 'create offense' response matches, QRadar opens an offense indexed by an offense source — usually the source IP, but it can be username, destination IP, or another field you choose. Later matching events contribute to the same offense instead of spawning new ones, so the count grows rather than the queue. ### Magnitude = relevance + credibility + severity QRadar ranks offenses by magnitude , a single 0–10 score it uses to decide what to investigate first. Magnitude is derived from three inputs: relevance (how much it matters to your network — driven by asset weight and importance), credibility (how trustworthy the source is — set per log source and refined by corroboration), and severity (the threat level relative to the target). QRadar also factors in the number of events/flows, the number of log sources, the offense's age, asset vulnerabilities and the event categories. The interview line: magnitude is not the severity of one event. It is a blended score so a noisy-but-harmless alert sinks and a credible threat against a critical asset floats to the top. Figure 4 — Rule vs building block Both use the same tests; only a rule has an action. Building blocks are reusable conditions, evaluated first. Rule vs building block Custom Rule Has a rule response / action Can create or contribute to an Can email, annotate, dispatch Evaluated after building blocks Building Block No action of its own Defines a reusable condition e.g. admin accounts, DMZ IPs Evaluated before rules Both use the same tests; only a rule has an action. Building blocks are reusable conditions, evaluated first. Figure 5 — How magnitude is blended Magnitude is a single 0–10 score blended from relevance, credibility and severity, then nudged by counts, asset weight and age. How magnitude is blended Relevance asset weight / impact Credibility source trust Severity threat vs target + Context counts, age, assets Magnitude 0–10 ranking Magnitude is a single 0–10 score blended from relevance, credibility and severity, then nudged by counts, asset weight and age. 'Magnitude = severity' is the classic wrong answer Magnitude is not the severity of a single event. It is a blended 0–10 score from relevance, credibility and severity, plus event counts, asset weight, age and categories. Saying 'it's just severity' signals you don't understand offense prioritization. ### ▶ Watch a brute-force login become a ranked offense How one attack walks the QRadar pipeline end-to-end. Press Play for the healthy path, then Break it to see the classic failure. ① Raw logs in An auth server sends repeated 'login failed' logs then one 'login success' for an admin account from a single external IP. ▼ ② Normalize The DSM maps each log to a QID, giving consistent event names and an 'Authentication' category. ▼ ③ Rule fires A Custom Rule (using an 'admin accounts' building block) matches the failures-then-success sequence from one source. ▼ ④ Offense ranked The rule response creates an offense indexed by source IP; magnitude is high because the target is a critical asset. Press Play to step through the healthy detection path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply A noisy informational alert keeps firing against an unimportant test server. Why does its offense stay low priority? a) Because magnitude blends relevance, credibility and severity, so low asset weight and low severity keep magnitude low b) Because QRadar deletes test-server events c) Because building blocks block it d) Because AQL hides it Correct: a. Magnitude is a blended 0–10 score. Low relevance (unimportant asset) and low severity keep the magnitude down, so it sinks below credible threats to critical assets — exactly the design intent. 👉 So far: An offense is indexed by an offense source and ranked by magnitude — a blend of relevance, credibility and severity, plus counts, asset weight, age and categories. ## ④ Investigating — AQL searches and the UBA app Triage starts at the offense summary: the offense source, the contributing rules, top events, and the source/destination involved. To go deeper you search the Ariel database with AQL (Ariel Query Language) , QRadar's SQL-like language for events and flows. ### AQL in one line A query selects fields, filters and time-bounds: SELECT sourceip, username, eventcount FROM events WHERE username = 'rkumar' LAST 24 HOURS . You refine with WHERE, GROUP BY, HAVING, ORDER BY, LIMIT and LAST . AQL is how you confirm the story behind an offense and feed tuning back into rules. For behaviour-based detection, the UBA / UEBA app sits on top. It consumes QRadar data, assigns risk to users and entities across many use cases, unifies a person's identities, and (with the Machine Learning app) learns each user's normal baseline to flag anomalies like impossible travel or first-time admin use. UBA doesn't replace rules and offenses — it adds a per-user risk lens on top of them. Priya, a SOC analyst at a Pune fintech, faces this A high-magnitude offense fires for 'multiple failed logins then success' on an admin account, but Priya isn't sure if it's a real attack or a fat-fingered admin. Likely cause The rule correctly chained failures + a success from one source IP and created an offense indexed by source IP; magnitude is high because the target is a tagged critical asset. Diagnosis Open the offense summary to see the contributing rule and offense source, then run AQL to pull the full login timeline for that user and source IP. Offenses ▸ Offense summary ▸ contributing rules, then Log Activity ▸ AQL Fix AQL: SELECT sourceip, username, eventcount FROM events WHERE username = 'admin_rk' LAST 24 HOURS — confirm whether the success came from a known host; check UBA for the user's risk and any impossible-travel flag. Verify If the source IP and geo match the admin's normal baseline in UBA and the timeline shows a legitimate reset, close as benign and tune the rule's building block to exclude that jump host. Prove it with AQL, not a hunch Never close a QRadar offense on 'looks fine'. Run an AQL query against the Ariel database to pull the exact events for that user/IP and time window. The query result — not a feeling — is what justifies escalate or close. Quick check · Q4 of 10 · Analyze You want every login event for user 'rkumar' in the last day to investigate an offense. What do you use? a) A new building block b) An AQL query against the events table filtered by username with LAST 24 HOURS c) A flow rule response d) The QID map editor Correct: b. AQL searches the Ariel database. SELECT … FROM events WHERE username = 'rkumar' LAST 24 HOURS returns exactly those events. WHERE filters and LAST sets the lookback window. 👉 So far: Investigate offenses with AQL queries against the Ariel database, and add per-user risk context with the UBA/UEBA app and its machine-learning baselines. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is a QID and why does it matter? What is the difference between a rule and a building block? How does a rule create an offense? How is offense magnitude calculated? What is AQL and when do you use it? Where does the UBA app fit? 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 What does a DSM do in QRadar? a) Parses raw logs and normalizes them into events mapped to a QID b) Calculates offense magnitude c) Stores the offense queue d) Runs AQL queries Correct: a. A Device Support Module parses each device's logs and normalizes them into structured events, mapping event ID/category to a QID that carries the name, severity and category. Q6 · Understand Why are building blocks evaluated before rules in the CRE? a) To make offenses appear faster b) To delete duplicate flows c) Because they have higher severity d) Because rules reference building blocks as reusable conditions, so the blocks must resolve first Correct: d. Building blocks define reusable, action-less conditions that rules call. They are evaluated first so the rule tests that depend on them have a resolved result to test against. Q7 · Apply You want one offense per attacking source IP, not one per event. What controls that? a) The AQL LIMIT clause b) The offense index (offense source), so later events contribute to the same offense c) The DSM severity d) The UBA risk score Correct: b. An offense is indexed by an offense source (e.g. source IP). Matching events contribute to that same offense instead of spawning new ones, keeping the queue short and the count meaningful. Q8 · Analyze An offense against a critical, vulnerable server ranks higher than the same alert against a test box. Which magnitude input explains this most? a) Credibility only b) Severity only c) AQL syntax d) Relevance — asset weight and impact raise it Correct: d. Relevance reflects the impact on your network, driven by asset weight, importance and vulnerabilities. A critical, vulnerable target raises relevance, so magnitude climbs even for the same event. Q9 · Evaluate An interviewer asks: 'Is magnitude just the event severity?' Best answer? a) Yes, magnitude equals the highest event severity b) No — magnitude is a 0–10 blend of relevance, credibility and severity, plus counts, asset weight, age and categories c) Magnitude is set manually by the analyst d) Magnitude only depends on credibility Correct: b. Magnitude is a blended ranking, not a single event's severity. It combines relevance, credibility and severity with event/flow counts, log-source count, age, asset weight and categories to prioritize triage. Q10 · Evaluate Best description of how UBA relates to QRadar's rules and offenses? a) UBA replaces the CRE and offenses entirely b) UBA is a separate SIEM you buy instead of QRadar c) UBA sits on top, adding per-user/entity risk and ML baselines while rules and offenses still run d) UBA only writes AQL queries Correct: c. UBA/UEBA consumes QRadar data and layers user and entity risk (with ML-learned baselines) on top of the existing rule and offense pipeline — it augments detection, it does not replace it. 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 Type one line: walk me from a raw failed-login log to a ranked QRadar offense. Then compare with the expert version. Compare with expert answer Expert version: A DSM normalizes the raw 'login failed' log into an event mapped to a QID, which gives it a consistent name, severity and Authentication category. The Custom Rule Engine runs a rule — often using a building block like 'admin accounts' — and when the failures-then-success sequence from one source matches, the rule response creates an offense indexed by the source IP, with later events contributing to it. QRadar ranks that offense by magnitude, a 0–10 blend of relevance (asset weight), credibility (source trust) and severity (threat vs target), plus counts, age and categories. I then investigate with AQL against the Ariel database and check the user's risk in UBA before I escalate or close. ### 🗣 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 DSM (Device Support Module) Parses a device's raw logs and normalizes them into QRadar events, mapping each to a QID with a name, severity and category. QID (QRadar Identifier) The record an event is mapped to; carries the human-readable event name, a severity and a low-level category. Event mapping / QID map The lookup that ties a device's event ID and category to a QID; fixing it corrects Unknown or mis-categorized events. Custom Rule Engine (CRE) The component that evaluates rules and building blocks against events and flows and triggers rule responses. Rule A collection of tests that, when matched, fires a rule response — e.g. create an offense, notify, or annotate. Building block (BB) A reusable set of tests with no action of its own, evaluated before rules; rules reference it to keep logic clean. Offense A correlated, prioritized record created by a rule response, indexed by an offense source; later events contribute to it. Magnitude A 0–10 ranking of an offense blended from relevance, credibility and severity, plus counts, asset weight, age and categories. AQL (Ariel Query Language) QRadar's SQL-like language for searching the Ariel database of events and flows using SELECT, WHERE, LAST and more. UBA / UEBA app An app that layers user and entity risk on QRadar data, with ML-learned baselines to flag anomalous behaviour. #### 📚 Sources IBM Documentation — Rules and offenses (QRadar SIEM, tuning guide) . ibm.com/docs/en/qsip — rules - IBM Documentation — Custom rules, building blocks and rule responses (Custom Rule Engine) . ibm.com/docs/en/qsip - IBM Documentation — Offense magnitude: relevance, credibility and severity . ibm.com/docs/en/qsip — offense magnitude - IBM Documentation — Ariel Query Language Guide (AQL query structure, SELECT/WHERE/LAST) . ibm.com/docs/en/SSKMKU/pdf/b_qradar_aql.pdf - IBM Documentation — Event mapping and QID map (DSM normalization, categories) . ibm.com/docs/en/qradar-on-cloud — event map - IBM Documentation — QRadar User Entity Behavior Analytics (UEBA) and Machine Learning Analytics apps . ibm.com/docs/en/qradar-common ### What's next? Want the foundation under all of this? The first QRadar lesson maps the architecture — Event/Flow Collectors and Processors, the Console, the Ariel database and DSMs — so you can see where rules, offenses and AQL actually run. 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