QRadar to Defender: A Bilingual Detection Engineer’s Field Notes
Most security teams run one SIEM. The ones migrating between two — usually IBM QRadar toward Microsoft Defender / Sentinel — discover that the hard part is not the query syntax. It is that the two platforms encode different philosophies of detection, and translating a detection means translating the assumptions underneath it, not just rewriting the WHERE clause.
These are field notes from operating both. They are not a syntax cheat sheet — those exist and go stale. They are about the conceptual translation, where it is clean, and where it quietly breaks.
The two mental models
QRadar is built around the offense — a correlated, stateful construct that accumulates context as events and flows match rules over time. You think in terms of building offenses: a rule fires, contributes to an offense, and the offense carries magnitude, credibility, and relevance. The model is inherently aggregative and stateful — QRadar is opinionated about correlating disparate events into a single investigable thing for you.
Defender / Sentinel with KQL is built around the query over a data lake. You think in terms of shaping tables: filter, project, summarize, join. Detection is a scheduled query that returns rows; the correlation logic is whatever you express in the query, plus the analytics-rule and incident layer above it. The model is compositional and explicit — you assemble the correlation yourself, with far more freedom and far less built-in opinion.
That difference — opinionated aggregation vs. explicit composition — is the root of almost every translation friction below.
AQL to KQL: the clean parts
The basic operations map cleanly enough that the translation feels easy at first, which is exactly the trap. The shape is familiar:
- Filtering, field selection, time-bounding — direct conceptual equivalents.
- Aggregations and grouping — both express “count these by that over this window,” just with different operators and pipe semantics.
- KQL’s pipe-forward composition is, if anything, more pleasant than AQL’s SQL-like structure for chaining transformations.
A QRadar analyst learning KQL picks up the data-shaping in days. The pipe model is intuitive: each | is a stage, data flows left to right, and you build the result incrementally. If translation were only syntax, this post would end here.
Where the philosophies diverge — and translations break
State and correlation across time. QRadar’s offense accumulates context for you across events and time. KQL queries are, by default, point-in-time over a window — the stateful correlation that QRadar does implicitly, you must construct explicitly in Sentinel (via the analytics rules, the incident layer, and careful windowing). A QRadar rule that “just works” because the platform aggregates may require deliberate engineering in Sentinel to reproduce the same stateful behaviour. Translation trap: assuming a rule’s logic is fully captured by its query — half its behaviour may live in QRadar’s offense engine, invisible in the rule text.
Building blocks vs. data lake. QRadar’s building blocks, reference sets, and the way it pre-correlates have no one-to-one Sentinel equivalent. In Sentinel you reach for watchlists, functions, and saved queries — conceptually similar, operationally different, with different performance and maintenance characteristics. A migration is partly an exercise in re-deciding where each piece of correlation logic should live.
Performance economics. QRadar’s performance model (EPS licensing, the appliance/event-pipeline architecture) is a different economy from Sentinel’s ingestion-and-query cost model. A query that is cheap in one can be expensive in the other. Translation trap: porting a high-frequency QRadar rule directly into a Sentinel scheduled query without rethinking ingestion volume and query cost, then getting a surprising bill or a throttled workspace.
Data normalisation. QRadar’s DSM/QID normalisation and Sentinel’s table schemas (and the ASIM normalisation layer) make different assumptions about how raw logs become queryable fields. A field you relied on being parsed a certain way in QRadar may live differently — or require explicit parsing — in Sentinel. The normalisation layer is where a lot of silent translation loss happens.
The migration traps, collected
For anyone actually doing this, the traps that cost the most time:
- Half the rule lives in the engine. QRadar offenses carry behaviour not visible in the rule text. Audit what the offense logic contributes before assuming the query is the whole detection.
- Stateful → stateless is real work. Time-correlated QRadar detections need deliberate windowing and incident-layer logic to reproduce in Sentinel. Budget for it.
- Cost model inversion. Re-evaluate every high-volume rule against Sentinel’s ingestion/query economics rather than QRadar’s EPS model.
- Normalisation drift. Verify field parsing per data source; do not assume the field you used exists or means the same thing.
- Reference data has to be rehomed. Reference sets, building blocks → watchlists, functions. Map them deliberately, not at the end.
- Coverage gaps hide in the translation. A detection that “didn’t port cleanly” and got deferred is a coverage gap. Track it explicitly against your ATT&CK map so the migration does not quietly degrade detection coverage.
Why the bilingual view is worth having
The instinct during a migration is to treat the old platform as legacy and rush to the new one. The more useful stance: the two philosophies teach each other. QRadar’s opinionated aggregation is a reminder of how much correlation logic you are now responsible for expressing explicitly in Sentinel — and Sentinel’s compositional freedom exposes how much QRadar was doing for you that you never had to think about.
A detection engineer who can think in both models writes better detections in either, because they can see the correlation logic as a thing to be designed rather than a feature to be inherited. The translation is not just a migration cost. It is a forcing function for understanding your own detections more deeply than either platform alone would require.
An independent piece by johlem.net — IT security, Luxembourg. SOC operations across QRadar and Microsoft Defender.