AzClean Detections: validated Sentinel analytics rules

Twelve Sentinel analytics rules for configuration drift and privilege escalation, and a validator that proves every query runs in your own workspace before you deploy it.

The problem with copied KQL

A detection rule that cannot run does not tell you it cannot run. It simply never fires.

The usual causes are dull. The table does not exist in your workspace because the connector was never enabled. The schema changed and a column was renamed. The rule was written against a table you have in a different resource group. In every case the rule sits in the portal looking exactly like the working ones, and you discover the difference during the incident it was written for.

That is why the validator is the part worth paying for rather than the rules.

What the validator checks

For each rule, in this order:

The query parses. Genuine KQL parsing rather than a regular expression looking for keywords.
Every table referenced exists in the workspace you are targeting.
Every column referenced exists on those tables, against the live schema.
The query returns rows when run over your historic data, so a rule that is syntactically fine but semantically wrong gets caught.
Severity and MITRE tactics are set, because an unclassified alert is one nobody triages.

A rule that fails any of the first three does not deploy. A rule that passes those but returns nothing is reported rather than blocked, since a quiet detection can be legitimate.

Why drift and privilege escalation first

For a small estate those two categories catch the things that actually happen. Configuration drift is the Conditional Access policy someone excluded themselves from, the storage account that became public, the retention setting that got shortened. Privilege escalation is a role assignment nobody requested, a new credential on an existing app registration, a guest promoted to something they should not be.

Neither needs a mature SOC to be useful, which is the point.

A sample rule

Configuration drift on Conditional Access, which is the one people are most surprised to need:

AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has_any (
    "Update conditional access policy",
    "Delete conditional access policy")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend PolicyName = tostring(TargetResources[0].displayName)
| project TimeGenerated, OperationName, PolicyName, Actor, Result
| order by TimeGenerated desc

The rules ship as templates you review before deployment rather than as something applied on your behalf. Microsoft's Sentinel analytics rule documentation covers the surrounding concepts if you are new to writing them.

AzClean Baselines is the companion for the same problem on the endpoint side. Detections tells you a cloud configuration changed; Baselines tells you which property of which Intune policy changed and when. Most people who buy one eventually want the other, and neither depends on the other to be useful.

Questions

Do I need Microsoft Sentinel to use this?

Yes. These are Sentinel analytics rules, and the validator queries a Log Analytics workspace. Without Sentinel there is nothing for them to run in.

Will deploying twelve rules increase my Sentinel bill?

Analytics rules themselves are not the cost driver, ingestion is. These query tables you are most likely already ingesting, principally AuditLogs, SigninLogs and AzureActivity. If you are not ingesting those, the rules will fail validation rather than run up a bill quietly.

Does the validator write to my workspace?

No. It parses queries and runs them read-only against your existing data. Deployment of a validated rule is a separate, deliberate step.

What if a rule returns nothing in my environment?

It is reported as returning no rows rather than blocked. That can be correct, if the thing it detects has not happened. It can also mean the rule does not suit your estate, which is worth knowing before it is the only thing standing between you and an incident.

Can I edit the rules?

They are templates, so yes, and you should. The MITRE tags and severities are starting points that reflect a small estate rather than yours.