CoursesAzure securityDefender for Cloud: CSPM + CWPP

Defender for Cloud: CSPM + CWPP

Secure Score, workload protection, org-wide.

Advanced30 min · lesson 10 of 15

A big office building stays safe two different ways at once. A safety inspector walks the floors with a checklist: are the fire doors clear, are the locks rated for the job, is the wiring up to code. She hands back a graded report and a list of what to fix. That is prevention. Separately, an alarm system with guards watches for someone forcing a door right now, tonight, while everyone is asleep. That is detection. You need both. One tells you where you are weak. The other tells you when someone is pushing on the weak spot.

Microsoft Defender for Cloud (formerly Azure Security Center, renamed in 2021) does both jobs across your whole Azure estate from one place. Hundreds of subscriptions, each stuffed with storage accounts, virtual machines, AKS (Azure Kubernetes Service) clusters, SQL (Structured Query Language) databases, and Key Vaults, all folded into a single graded posture and a single stream of live alerts. Turn every signal on by hand and you drown in logs nobody reads. Defender for Cloud keeps that manageable, and it splits cleanly along the inspector-versus-alarm line.

Two jobs: the inspector and the alarm

CSPM (Cloud Security Posture Management) is the inspector. It keeps comparing how your resources are actually configured against a security benchmark, and reports back a Secure Score plus a ranked list of recommendations: a storage account open to the public internet, a database with encryption switched off, a management port reachable from anywhere, a role assignment that hands out far more access than anyone needs. The foundational CSPM tier is free and switched on the moment you have a subscription. The paid plan, Defender CSPM, is billed under the plan name CloudPosture and adds the sharp tools: agentless machine scanning, attack path analysis, the cloud security explorer, and data-aware posture that knows which storage holds sensitive data. Its real trick is reasoning about how weaknesses chain into a breach instead of scoring each one alone.

CWPP (Cloud Workload Protection Platform) is the alarm system with guards on the floor. These are paid plans, priced per workload, one each for Servers, Containers, Storage, SQL databases, Key Vault, App Service, and APIs (application programming interfaces, the endpoints other software calls). They watch running workloads and raise an alert the moment something happens that should not: a reverse shell opening inside a container, a connection to your storage account from a Tor exit node (an anonymizing network your real users almost never come through), a burst of failed reads against a Key Vault that looks like someone guessing at a password. Each plan bills on what it guards. Servers charge per server-hour. Storage charges a flat rate per storage account each month, and malware scanning adds a per-gigabyte charge on top. SQL charges per protected database server. Containers charge per vCore (a single virtual CPU core) across the cluster. At scale you switch these on per workload type, matched to what you actually run, rather than flipping everything to Standard and swallowing the bill.

Hold onto one sentence. CSPM tells you what could be exploited. CWPP tells you what is being exploited. They are separate products with separate billing, and turning on one does nothing for the other.

terminal
# Defender plans are set per SUBSCRIPTION. Enable posture plus the workloads you run.
# 'CloudPosture' is Defender CSPM (posture); the rest are CWPP (workload) plans.
az security pricing create -n CloudPosture --tier Standard
az security pricing create -n VirtualMachines --tier Standard --subplan P2 # Servers P2: MDE, agentless scan, FIM, JIT
az security pricing create -n StorageAccounts --tier Standard --subplan DefenderForStorageV2
az security pricing create -n Containers --tier Standard
az security pricing create -n KeyVaults --tier Standard
az security pricing create -n SqlServers --tier Standard
# Verify: which plans are Standard, and which are still Free?
az security pricing list \
--query "value[].{plan:name, tier:pricingTier, sub:subPlan}" -o table
output
Plan Tier Sub
--------------- -------- --------------------
CloudPosture Standard
VirtualMachines Standard P2
StorageAccounts Standard DefenderForStorageV2
Containers Standard
KeyVaults Standard
SqlServers Standard
AppServices Free # <-- not covered; enable if you run App Service
Api Free # <-- not covered; enable if you expose APIs
The Storage plan does not turn on malware scanning by itself
Setting StorageAccounts to Standard with subplan DefenderForStorageV2 gives you activity-based threat detection only. On-upload malware scanning and sensitive-data threat detection are SEPARATE extensions, and via the CLI they default to off. If you assumed a poisoned blob would be caught on upload, it will not be until you pass the OnUploadMalwareScanning extension explicitly. Enable them, then confirm with 'az security pricing show -n StorageAccounts' and read the extensions array.
terminal
# Malware scanning + sensitive-data detection are extensions on the Storage plan.
# CapGBPerMonthPerStorageAccount caps the monthly scanned volume so the bill cannot run away.
az security pricing create -n StorageAccounts --tier Standard --subplan DefenderForStorageV2 \
--extension name=OnUploadMalwareScanning isEnabled=True \
additionalExtensionProperties='{"CapGBPerMonthPerStorageAccount":"5000"}' \
--extension name=SensitiveDataDiscovery isEnabled=True
output
{
"name": "StorageAccounts",
"pricingTier": "Standard",
"subPlan": "DefenderForStorageV2",
"extensions": [
{
"name": "OnUploadMalwareScanning",
"isEnabled": "True",
"additionalExtensionProperties": { "CapGBPerMonthPerStorageAccount": "5000" }
},
{ "name": "SensitiveDataDiscovery", "isEnabled": "True" }
]
}

Secure Score: what the number actually means

The score is not a vibe. Recommendations are bundled into security controls, groups like Remediate vulnerabilities or Restrict unauthorized network access, and each control is worth a fixed maximum number of points. Think of it as a report card where every subject is worth a set amount, and your grade in that subject depends on how many of your resources pass it.

You earn a control's full points only when every in-scope resource passes. Fix some but not all, and you get proportional credit. The math is literally (max points / total resources) * healthy resources. A control worth 4 points with 30 of 50 resources healthy gives you 4 * (30 / 50), which is 2.4 points. Your Secure Score is the sum of points earned over the sum of maxima, shown as a percentage. Every recommendation carries an assessment with a severity and a remediation, and many ship a Quick Fix (a one-click repair) or a DeployIfNotExists policy (one that automatically deploys the missing setting) that fixes the resource in place.

terminal
# Current Secure Score for the subscription (trend this weekly, assign controls to owners).
az security secure-scores show -n ascScore \
--query "{current:score.current, max:score.max, pct:score.percentage}"
output
{
"current": 42.5,
"max": 58.0,
"pct": 0.73
}
terminal
# Per-control breakdown: where the points are, and how many resources still fail.
az security secure-score-controls list \
--query "[].{control:displayName, cur:score.current, max:score.max, unhealthy:unhealthyResourceCount}" -o table
output
Control Cur Max Unhealthy
--------------------------------------------- ----- ----- -----------
Restrict unauthorized network access 2.4 4 20
Remediate vulnerabilities 3.0 6 12
Enable MFA 0.0 10 3
Manage access and permissions 3.2 4 2
Encrypt data in transit 2.0 2 0

Read that table like a plan, not a scoreboard. Enable MFA (multi-factor authentication) sits at 0 of 10 points with only three failing accounts. Three fixes there move the number more than twenty network fixes worth 4 points between them. Prioritize by points at stake, not by count of findings. And treat the score as a floor to hold, not a finish line to cross. A perfect score means the automated checks pass. It says nothing about whether your architecture makes sense or whether the threats specific to your business are covered.

Agentless scanning and attack paths

Agentless scanning, included with both Defender CSPM and Servers Plan 2, takes a snapshot of a VM or container disk and inspects the copy for vulnerabilities, exposed secrets, and malware, with nothing installed on the machine itself. It is like photographing every floor from a drone instead of posting a guard on each one. Broad, cheap, and it never touches the running workload. The catch is timing. It runs on a fixed schedule, roughly once every 24 hours, and you cannot make it faster. So it finds the weak lock, but it is not standing there when someone picks it. Pair it with a real-time agent for anything that matters.

The highest-value thing agentless posture produces is the attack path. Instead of a thousand scattered findings, it draws the actual route an attacker would walk: an internet-exposed VM, running a high-severity unpatched CVE (Common Vulnerabilities and Exposures, a publicly catalogued software bug with its own tracking number), holding a managed identity (a login that Microsoft Entra ID, the identity service formerly called Azure AD, manages automatically for that machine) that can read a Key Vault full of secrets. Each path is ranked by how exploitable it is and how much damage it opens up, so you fix the one or two hops that snap the whole chain instead of chasing every finding on its own.

terminal
# Attack paths (needs Defender CSPM + the resource-graph extension:
# az extension add -n resource-graph).
az graph query -q "securityresources
| where type =~ 'microsoft.security/attackpaths'
| project path = properties.displayName" \
--query "data[]" -o table
output
Path
------------------------------------------------------------------------------------------
Internet exposed VM with a high severity vulnerability has read access to a Key Vault
Internet exposed AKS pod with a high severity vulnerability has permissions to a storage account

CWPP in action: catching the attack in progress

Posture is prevention. The workload plans are what catch a break-in while it is happening. Defender for Servers Plan 2 wires in Microsoft Defender for Endpoint (MDE), a full EDR (Endpoint Detection and Response, the software that watches process and network behavior on a machine and flags attacks in real time). It adds File Integrity Monitoring (FIM), which alerts when critical operating-system or application files change unexpectedly, the digital version of a tamper seal on a cabinet. And it enables Just-in-Time (JIT) VM access: the management ports, SSH (Secure Shell) on 22 and RDP (Remote Desktop Protocol) on 3389, stay shut at the network security group (NSG) until an operator requests a time-boxed window, then close again. That shrinks the attack surface the networking lessons kept warning you about. Alerts come through the same command surface as your recommendations, so you can triage from the shell before anyone gets paged.

terminal
# Active threat alerts across the subscription (this is CWPP output, not posture).
az security alert list \
--query "[?status=='Active'].{alert:alertDisplayName, sev:severity}" -o table
output
Alert Sev
------------------------------------------------- ------
Digital currency mining related behavior detected High
Suspicious process executed High
Access from a Tor exit node to a storage account Medium
terminal
# Which management ports are locked behind Just-in-Time access right now?
az security jit-policy list --query "[].virtualMachines[].ports[].number" -o tsv
output
22
3389

The container and storage plans work by behavior. Defender for Containers watches the AKS runtime for suspicious activity and scans images in your registry before they run, so a known-bad image is flagged instead of quietly starting. Defender for Storage flags anomalous access patterns and, once the OnUploadMalwareScanning extension is on, checks blobs for malware the moment they land, so a poisoned file cannot sit in a blob container waiting for someone to download it. That first alert in the list above, the crypto-mining one, only exists because Defender for Containers was on. Without it, the miner runs for hours in silence.

Defender CSPM is not workload protection
A common, expensive mistake: a team turns on Defender CSPM (CloudPosture), sees attack paths and a rising Secure Score, and assumes workloads are protected. They are not. CSPM finds misconfiguration and exposure only. Runtime threat detection lives in the CWPP plans, each enabled and billed separately. A crypto-miner in an AKS pod raises NO alert until Defender for Containers is on; a Key Vault brute-force goes unseen until Defender for Key Vault is on. Confirm real coverage with 'az security pricing list'. CloudPosture at Standard, on its own, is not coverage.

Make it a property of the org

Here is the trap. 'az security pricing create' acts on exactly one subscription. Run it by hand today, and a subscription somebody spins up tomorrow quietly lands on the free tier with no workload protection at all. That silent new-subscription gap is precisely what an attacker goes looking for, because it is the one place nobody is watching.

Make protection a property of the organization instead of a chore you repeat. Azure ships built-in policy initiatives called Configure Microsoft Defender plans that use DeployIfNotExists to provision any plan a subscription is missing. Assign them at a management-group scope, the level that sits above subscriptions in the hierarchy, and every subscription underneath, today's and next year's, inherits every plan you chose. Pair that with agentless scanning so a brand-new VM gets assessed within a day of coming online, not weeks later when someone finally remembers it exists.

Then send the output somewhere it becomes action. Recommendations and alerts flow into Microsoft Sentinel (a SIEM, or Security Information and Event Management system, that collects security events at scale, wired to SOAR, Security Orchestration, Automation, and Response, which runs automated playbooks against them) and into the unified Microsoft Defender portal, where correlation across signals and those playbooks turn a raised alert into a contained one. That handoff, from a detection sitting in a list to a machine isolated and a ticket opened, is where the next lesson picks up.

Defender for Cloud: two planes plus response
CSPM: posture (what could be exploited)
Foundational CSPM
free, on by default
Defender CSPM
plan CloudPosture, paid
Agentless scan
disk snapshot, every 24h
Attack paths
chains, not single findings
CWPP: workloads (what is being exploited)
Servers P2
MDE, FIM, JIT
Containers
AKS runtime + image scan
Storage
anomalies + malware scan
SQL / Key Vault
per-workload alerts
Response
Microsoft Sentinel
SIEM + playbooks
Unified Defender portal
correlate + contain
Enable both planes at a management-group scope so every current and future subscription inherits coverage, with no per-subscription gaps.
Quick check
01Defender for Cloud splits into CSPM and CWPP. Which statement describes the division of labor correctly?
Correct — posture is preventive and config-based, workload protection is real-time detection.
Incorrect — Backwards: detection is CWPP, and the config scan plus Secure Score are CSPM.
Incorrect — CSPM raises no runtime threat alerts at all, whatever tier you pay for.
Incorrect — the two run in parallel and Secure Score never switches detection on or off.
02A security control is worth a maximum of 4 points. Of 50 in-scope resources, 30 are healthy. How many points does this control currently add to your Secure Score?
Incorrect — controls give proportional credit, not all-or-nothing.
Correct — a control's current score is (max points / total resources) * healthy resources.
Incorrect — full points require every in-scope resource to pass, not just one.
Incorrect — the formula counts the 30 healthy resources, not the 20 unhealthy ones.
03'az security pricing list' shows CloudPosture: Standard and Containers: Free. A crypto-miner has run inside an AKS pod for hours with no Defender alert. What is happening, and what fixes it?
Incorrect — alerting never depends on Secure Score reaching any threshold.
Incorrect — attack paths are posture findings and do not suppress runtime alerts.
Correct — set the Containers plan to Standard to get AKS runtime alerts like this one.
Incorrect — with the Containers plan off, no container alert is generated for Sentinel to receive.

Try this

Run az security pricing create -n CloudPosture --tier Standard on a scratch host or disposable cluster and read the output against what this lesson described. Then change one input so it fails, and re-run: the error you get is the one you will meet in production.

Takeaway

The trap worth remembering here: the Storage plan does not turn on malware scanning by itself. Check that on your own systems before you need to, because it is cheaper to find on a quiet afternoon than during an incident.

Related