The detection library
What detection content ships, how a rule is put together, which parts are mandatory and why, and the contract that stops a rule claiming coverage it lacks.
A detection rule is a written description of a pattern in your logs that is worth noticing, together with everything a person needs in order to decide what to do about it. The detection library is the set of those rules that ships with the product. This article describes what is in it, how one rule is put together, and which parts of a rule exist for your benefit rather than the software's.
You do not have to write rules. The library is authored, maintained and versioned by us, and it arrives switched on. What you may well want to do is adjust one — that is Tuning a detection rule — and this article is the thing to read first, because it explains what the parts you are adjusting are for. If you do want to write one, you can; that is covered under Rules you write yourself below.
What ships
| Detection rules | 100 |
|---|---|
| Of those, active — can raise an alert | 90 |
| Of those, shadow mode — evaluated, feeds risk, raises no alert | 10 |
| Correlation chains | 8 |
| Distinct MITRE ATT&CK techniques | 80 |
| Distinct MITRE ATT&CK tactics | 12 of 14 |
| By severity | 21 critical, 64 high, 13 medium, 2 low |
| Rules requiring a third-party licence attribution in the interface | 0 |
The two ATT&CK tactics not covered are Reconnaissance and Resource Development. That is structural rather than a gap we intend to close: both happen outside your estate. An attacker reading your staff list on a professional network or registering a lookalike domain produces no event inside your Microsoft 365 tenant or on your machines, and a product claiming to detect them from your own logs would be claiming something it cannot do.
Rules are grouped into numbered blocks. Identifiers are stable and are never reused; a withdrawn rule is marked deprecated rather than deleted, because your tuning, your suppression lists and your historical alerts all reference the identifier.
| Block | Family | Rules | In shadow |
|---|---|---|---|
NES-SIEM-001–009 | Brute force, credential stuffing and password spraying | 6 | 0 |
010–019 | Privilege escalation and account manipulation | 5 | 0 |
020–029 | Discovery and lateral movement | 5 | 0 |
030–039 | Collection and exfiltration | 5 | 1 |
100–119 | Entra ID sign-in logs | 13 | 0 |
120–139 | Entra ID directory audit | 11 | 0 |
140–149 | Microsoft 365 and Exchange Online — business email compromise | 8 | 0 |
150–159 | Logging and defence tampering | 9 | 0 |
200–219 | Endpoint execution and defence evasion | 7 | 0 |
220–229 | Credential dumping and theft on the endpoint | 4 | 0 |
230–239 | Persistence | 4 | 0 |
240–249 | Impact — ransomware and destruction | 6 | 0 |
300–319 | Cloud control plane (AWS, Azure) | 5 | 0 |
400–409 | Non-human identity and AI service administration | 6 | 4 |
450–459 | Privileged access and just-in-time privilege | 6 | 5 |
Identifiers inside a block are sparse — there is no 111, no 202, no 454. The block boundary is what is stable, not the density. A gap means the identifier was either never issued or was withdrawn.
The weighting is deliberate. 32 of the 100 rules are identity rules against Microsoft 365, because roughly 70% of small and medium businesses are a Microsoft shop, and abuse of a valid cloud account is the most prevalent confirmed technique in the 2025/2026 threat data. The library is shaped like the threat, not like a feature matrix.
How a rule is put together
A rule is data, not code, which is what makes it tunable without a software release. Its parts:
| Part | What it is |
|---|---|
| Identifier and title | The stable identifier, and a title that is unique across the whole library — the validation gate rejects a duplicate, because two rules with the same name in an alert queue is an unanswerable question. |
| Description | What the rule detects and why it matters, written for somebody who has never heard of the technique. |
| Severity | informational, low, medium, high or critical. A statement about consequence, not confidence — see Alert severity, and what a match actually means. |
| Status | draft, testing, active, disabled or deprecated — derived from the field contract, not hand-set. See below. |
| MITRE mapping — mandatory | At least one technique with its tactic. The searchable attack.* tags are generated from the mapping rather than typed separately, so the two cannot disagree. |
| Detection block | The selections, the condition expression that combines them, and the aggregation settings: time window, group-by fields, threshold, distinct field, minimum events and cooldown. |
| Threshold rationale — mandatory whenever a threshold is set | Why that number. A threshold without a stated reason is a number nobody can tune. |
| False-positive guidance — mandatory | The innocent explanations, and what to do about each. The validation gate refuses to load a rule without it. |
| Response actions — mandatory | What the platform should do or propose when the rule fires — notify, revoke sessions, require multi-factor, isolate, record an audit trail. |
| Risk score and risk entities | A weight from 0 to 100, and which entity kinds the risk attaches to: user, host or source address. Zero on a non-informational rule is rejected, because it could never contribute to an incident. |
| Data sources — mandatory | The telemetry the rule needs, so the console can tell you what to connect. |
| Provenance | Who authored it, under what licence, and the public reference it was derived from. |
The mandatory fields exist for you, not for the evaluator
A rule would evaluate perfectly well with no false-positive guidance, no threshold rationale and no listed data sources. All three are refused at load time anyway, and the reasoning is worth stating because it is the difference between a library that gets used and one that gets ignored.
False-positive guidance is mandatory because a rule without it is a rule you switch off in week two. The first time a legitimate business process trips a detection, you have two choices: work out which specific thing to exclude, or turn the whole rule off. Without guidance, only the second is available to you, and it is the one that removes a class of visibility you will not remember having removed. So the guidance is not a paragraph of general advice — it names the specific innocent cause and the specific field to narrow on.
A threshold rationale is mandatory for the same reason from the other direction. Ten in five minutes is a judgement somebody made about a trade-off. Nine months later, when the figure is wrong for your organisation, the rationale is what tells you what the original number was protecting against — so you can move it deliberately rather than doubling it until the noise stops.
Data sources are mandatory because a rule whose telemetry you have not connected is not coverage. The console has to be able to tell you this rule needs Entra ID sign-in logs rather than leaving you to infer it from the field names.
One rule in full
NES-SIEM-100, Entra ID - Device Code Authentication Flow Used, severity high, mapped to T1528 Steal Application Access Token and to T1078.004 Valid Accounts: Cloud Accounts. Its data source is Entra ID sign-in logs; its risk attaches to the user and the source address; its response actions are to notify, revoke sessions, require multi-factor and record an audit trail. It matches an authentication event from Entra whose grant flow is the device-code flow and whose outcome is success.
A sign-in completed through the OAuth device-authorization grant. The flow was designed for input-constrained devices such as smart TVs, and almost no SMB has a legitimate user of it. It is the preferred phishing flow for stealing a refresh token because the victim authenticates on a genuine Microsoft page and the attacker receives the token, so no credential ever crosses the phishing site and MFA is satisfied legitimately.
Its three false-positive entries are what the mandatory field looks like in practice:
- Genuine shared-device enrolment: Microsoft Teams Rooms, Surface Hub, and conference-room displays legitimately use the device-code flow during setup. Expect a cluster at deployment time, then silence.
- Azure CLI and Azure PowerShell fall back to the device-code flow when no browser is available, so an administrator working over SSH will trigger this. Allowlist by the specific admin's
user_idrather than disabling the rule. - If the tenant genuinely operates input-constrained devices, tune to exclude the known
metadata.app_idvalues rather than the flow.
Note the shape of the last two. Each names a field and a narrowing, not a switch. That is deliberate, and it is the thing to copy when you are dealing with noise of your own — see Suppressing a false positive.
The contract that stops a rule lying about itself
This is the most important mechanism in the library, and it is unglamorous.
A rule that reads a field the pipeline never populates does not fail. It silently never matches anything. The rule looks shipped, the coverage report counts it, and it detects nothing — potentially for years, because nothing about it looks wrong. This is the single most expensive failure mode a detection library has, and it is invisible by construction.
So every field any rule may reference is declared in a contract, each with an availability of available (populated today) or pending (agreed, but ingest does not produce it yet) and the name of whoever must populate it. The validation gate then refuses two things outright: a rule that references any field outside the contract, and active status on a rule that reads a field still marked pending. A rule's status is therefore derived rather than chosen — all fields available means it ships active, one pending field means it ships in shadow.
That has a pleasant consequence: a rule promotes itself. The moment the ingest side lands the last missing field, the rule flips to active on its own, with nobody having to remember to change a status by hand. The corresponding unpleasant consequence is that some shipped rules are quiet, and the count of rules that can alert is published separately from the total for exactly that reason. Shadow detections, and why some rules stay quiet names each one and what it is waiting for.
Two further protections work the same way. Group-by fields and distinct-count fields are included in the check, because a rule that groups on a field nobody populates buckets every event under the empty string. And your own suppression entries are validated against the same contract, so you cannot suppress on a field that does not exist and then believe you have suppressed something.
The condition language, and a rule that shipped dead
A rule's selections are combined by a condition expression with real precedence — and, or, not, parentheses, 1 of a group and all of them. Within one selection, tests are combined with AND. The available tests are eq, ne, contains, not_contains, contains_any, contains_all, startswith, endswith, regex, regex_any, in, not_in, in_cidr, gt, lt, gte, lte and exists, each of which can be negated.
The validation gate checks the operator name against that list, and compiles every pattern at load time. Both checks exist because of the same class of silent failure: an operator the evaluator does not implement returns false forever, and a pattern that fails to compile does not error at match time — it simply never matches.
One more detail with a real effect: numeric comparisons parse strings. Values arriving inside a JSON metadata document are frequently quoted, and treating a quoted number as non-numeric made every greater-than and less-than condition on metadata silently false.
Who wrote the rules, and under what licence
The whole library is first-party authored. Each rule records its origin as Qorionix-authored, its licence as our own, and a public reference — typically the MITRE ATT&CK technique page plus the relevant vendor documentation — so a reviewer can see what the detection was derived from. NES-SIEM-103, the multi-factor fatigue rule, cites the T1621 technique page and Microsoft's guidance on Authenticator number matching.
The machinery for third-party content exists ahead of any need for it, and is dormant today. Two parts of it are worth knowing about if you are answering a procurement questionnaire. Content under the SigmaHQ Detection Rule License requires the original author to be displayed in any view that shows a match, so the credit line travels on the signal itself rather than sitting in a source file, and the licence cannot be recorded without an author. Content under the Elastic License v2 may not be provided as a managed service at all, so that licence exists in the code only so the validation gate can reject it by name, alongside content whose licence was never recorded. The refusal is mechanical, at build time — a policy memo does not survive contact with a team, and a failing test does.
Because everything is first-party, no rule currently requires an attribution line and the console has none to render. That is a true zero rather than a missing feature.
Rules you write yourself
Everything above describes the shipped library. You are not limited to it: you can author an entirely new detection rule from scratch, at Detection Rules → New rule. The full walkthrough — the five parts of the form, what it refuses to save and why, and how to replay a draft rule over your own events before you trust it — lives in Testing a rule before you trust it. This is the short version, so you know the option exists and how a rule of yours behaves differently from one of ours.
- They get their own reference identifiers, under a prefix distinct from the
NES-SIEM-block above, so a rule of yours can never be confused with a shipped one in an alert, an audit entry or a report. - They are marked as yours in the rule list — a Yours badge on the row, and Written here rather than As shipped in the tuning column.
- They can be edited and deleted freely. Shipped rules cannot: those you tune, and the boundary is described in Tuning a detection rule.
- They are capped at 200 per organisation. Past that, saving a new one is refused until you delete one.
- They start in shadow mode — evaluated, recorded, alerting nobody — until you deliberately switch them on.
The mandatory fields described earlier in this article are mandatory for your rules too: an ATT&CK mapping, a note on what legitimate activity could look similar, and a stated reason for whatever threshold you set. That is not bureaucracy applied to you for its own sake — it is the same argument made above, and it applies with more force to a rule whose author sits in your building and may not still be here in a year.
Two limits to know about
Correlation chains ship as content; the runtime sequence evaluator is not wired into the ingest path. Eight chains are defined, validated and served over the API — a chain cannot reference a rule that is absent from the library, and cannot outlive the rules it depends on. What is not observable in the live ingest path is the evaluator that walks an ordered sequence of rule matches. Treat the eight chains as shipped detection content and as a description of the sequences we consider decisive, not as alerts you should expect today.
Collected is not the same as alerted, and today they are not the same thing here. Everything above describes what the rules are capable of. What they are currently applied to is narrower: events arriving over the HTTP Event Collector, OTLP, syslog, Microsoft 365, AWS CloudTrail, Google Workspace or the Windows Event Log collector are parsed, normalised, stored and searchable, and they are not evaluated against this library. Only events written through the platform's internal service ingest path reach the evaluator, and nothing joins the two halves. Both are built and correct on their own; the join is missing.
So a library that validates cleanly, passes its contract test and reports honest coverage can still be firing on nothing in a given tenant. The rules, the field contract and the coverage view are all real and none of them is overstated by this — but the coverage view is telling you what the library covers, not what is currently being watched. Until the join lands, treat log collection as delivering search, evidence and retention, and keep Microsoft's and Google's own alerting switched on rather than retiring it on the assumption that we have replaced it. The source-by-source detail is in Connecting your first log source.
What to read next
- Tuning a detection rule — exactly what you may change, and what you may not.
- Suppressing a false positive — the safe way to silence noise.
- How your logs are normalised — the field vocabulary the rules are written against.
- Scheduled detection rules and templates — the second rule shape, and the 104-template gallery.