Notes

Azure security for estates with nobody watching the screen

Most security tooling assumes somebody is looking at it. A rota, a triage queue, a person whose job is to notice. At small scale that person does not exist, and the honest question is not "how do we detect everything" but "which handful of things would we genuinely act on, and are they actually working".

These notes are about azure security under that constraint. The bar is not comprehensive coverage. The bar is a small number of checks and detections that are known to run, that fire rarely, and that a single person can respond to without dropping everything else they were hired to do.

The two azure security failure modes worth designing against

Small estates lose to the same two things, and neither of them is a sophisticated attacker.

The first is configuration that drifted. A Conditional Access policy someone excluded themselves from during a bad afternoon. A storage account that became public for a migration and stayed that way. A retention setting shortened to save money in a month nobody remembers. None of these are breaches. All of them are the conditions under which a breach becomes easy and undetectable.

The second is privilege that accumulated. An Owner assignment from a project in 2022. A guest account with standing access to a subscription. An app registration with a client secret that was set to expire in ten years because the person creating it did not want to think about it again. Access is easy to grant, nobody is incentivised to remove it, and there is rarely a moment when somebody notices.

Both are boring. Both are visible in data you already have. Neither needs a SOC to find.

Detections that are known to work

The single most useful thing in this cluster is also the least glamorous: a detection rule you have not tested is a rule you do not have.

Copied KQL fails quietly. A table that does not exist in your workspace because the connector was never enabled. A column renamed in a schema update. A rule written against a different tenant's table layout. In every case the rule sits in the portal looking exactly like the working ones, produces no error, and never fires. You find out during the incident it was written for, which is the worst possible time to learn something.

That argues for fewer rules, validated, over a large imported ruleset nobody has checked. Twelve that provably run beat sixty that might.

Cost is a security control here

Sentinel bills on ingestion, which makes the volume decision a security decision rather than a finance one.

Ingest everything and the bill exceeds the value of the thing you are protecting, at which point somebody turns tables off in a hurry and usually the wrong ones. Ingest too little and the investigation you eventually need has no data behind it. Deciding deliberately which tables are worth it, and writing down why, is more useful than either extreme, and it is a decision that should be made before the invoice rather than after.

Read-only first

Everything in this cluster can be checked without changing anything, and that matters more than it sounds when the estate is not yours or is not fully understood yet. An audit that only reads can run on day one. A remediation script needs a conversation, a change window and somebody to carry the risk.

The related habit is failing loudly. A security check that cannot authenticate and reports nothing has produced a clean result from an empty search, and a clean result is exactly what everyone wants to see. "Found nothing" and "could not look" have to be distinguishable, and the second one should exit non-zero so whatever scheduled it goes red.

Reading order

Start with detection validation, because it changes how you think about every rule you already have. Then ingestion cost, since that constrains what is possible. The NSG, public storage, RBAC and credential notes are independent checks and can be read in any order, though they are roughly in the sequence I would run them on an unfamiliar estate.

The last note explains why none of the tooling here writes to Azure, which is either the least interesting design decision or the most important one, depending on whose subscription you are pointing it at.