Azure Landing Zone · Deep dive 03

Ten ISM controls you can diff, not just document

October's Azure Blob attack wave was misconfiguration, not zero-days. Here are ten ISM controls written as Azure Policy you can enforce and prove.

Draft outline · Compliance-as-code lens
The anchor

In October 2025 Microsoft warned of rising attacks on Azure Blob Storage exploiting exposed credentials and misconfiguration, and industry data attributes a large share of cloud breaches to misconfiguration. Written as Azure Policy, a control is enforced continuously and its state is a thing you can diff, not a claim in a document.

Sources we build on
Primary

Primary reporting on the misconfiguration attack wave and the specific mistakes exploited.

Journalism
Dark Reading: cloud storage misconfiguration risk

Independent analysis of the data-exposure pattern and why misconfiguration keeps winning.

Article outline
  1. Misconfiguration beats zero-days. What the Blob Storage wave actually exploited.
  2. Control text to code. Taking an ISM control and expressing it as enforceable policy.
  3. Ten worked examples. Deny public blob access, require private endpoints, enforce encryption, and more.
  4. Prove it. Compliance state as evidence an assessor can read directly.
  5. Drift and remediation. What happens when someone changes a setting.
How it aligns to what we do

The purest expression of deployed configs, not strategy documents. Compliance-as-code is defensible in procurement and auditable by an assessor, and it shows our work is inspectable rather than asserted.

Points to hit
Control it ratifies
ISM / E8 Directly implements selected ISM controls (system hardening, access control, cryptography) as Azure Policy, with continuous compliance evidence.