What does a DSM do in QRadar?

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.

Why are building blocks evaluated before rules in the CRE?

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.

You want one offense per attacking source IP, not one per event. What controls that?

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.

An offense against a critical, vulnerable server ranks higher than the same alert against a test box. Which magnitude input explains this most?

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.

An interviewer asks: 'Is magnitude just the event severity?' Best answer?

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.

Best description of how UBA relates to QRadar's rules and offenses?

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.

IBM QRadar Rules, Offenses & AQL — From Normalized Events to a Prioritized Offense (2026)

Q: Where does a normalized QRadar event get its name, severity and category?

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.

Q: Which statement about building blocks is correct?

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.

Q: A noisy informational alert keeps firing against an unimportant test server. Why does its offense stay low priority?

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.

Q: You want every login event for user 'rkumar' in the last day to investigate an offense. What do you use?

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.

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.

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.

Quick check · Q1 of 10 · Remember

Where does a normalized QRadar event get its name, severity and category?

a) From the analyst on shiftb) From the QID it is mapped to by the DSMc) From the firewall hardwared) 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.

🏷️

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 severityb) They are appliances that collect flowsc) They use the same tests as rules but have no action, and are evaluated before rulesd) 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.

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.

'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 inAn auth server sends repeated 'login failed' logs then one 'login success' for an admin account from a single external IP.

▼

② NormalizeThe DSM maps each log to a QID, giving consistent event names and an 'Authentication' category.

▼

③ Rule firesA Custom Rule (using an 'admin accounts' building block) matches the failures-then-success sequence from one source.

▼

④ Offense rankedThe 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.

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 lowb) Because QRadar deletes test-server eventsc) Because building blocks block itd) 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 blockb) An AQL query against the events table filtered by username with LAST 24 HOURSc) A flow rule responsed) 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.

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

Type one line: walk me from a raw failed-login log to a ranked QRadar offense. Then compare with the expert version.

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.

📩 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 →

IBM QRadar Rules, Offenses & AQL — From Normalized Events to a Prioritized Offense

🎯 By the end you will be able to

Pick where you want to start

Events & QID

Rules in the CRE

Offenses & magnitude

AQL & UBA

① From raw log to normalized event — the QID recap

② Building rules in the Custom Rule Engine (CRE)

Building blocks vs rules

③ How offenses are built — and what drives magnitude

Magnitude = relevance + credibility + severity

▶ Watch a brute-force login become a ranked offense

④ Investigating — AQL searches and the UBA app

AQL in one line

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?