4.1 Defender for Cloud Architecture and Foundational Concepts

Defender for Cloud Architecture and Foundational Concepts

Introduction

Defender for Cloud is fundamentally different from the other Defender products you have studied. Defender for Endpoint protects devices. Defender for Office 365 protects email. Defender for Identity protects on-premises Active Directory. Defender for Cloud Apps protects SaaS applications. Defender for Cloud protects cloud infrastructure — the virtual machines, databases, storage accounts, containers, and application services that run your organisation’s workloads in Azure, AWS, and GCP.

The difference is not just scope. The threat model is different. Endpoint threats involve malware execution, credential theft, and lateral movement within a network. Cloud infrastructure threats involve misconfiguration exploitation, privilege escalation through IAM policies, data exposure through overly permissive storage accounts, cryptocurrency mining on compromised VMs, and container escape attacks. Defender for Cloud detects both categories — misconfigurations (posture problems that create opportunities for attack) and active threats (attacks that are currently happening).

This subsection teaches you the architectural foundation: what Defender for Cloud is, how it is structured, what it protects, how it relates to other Microsoft security products, and the licensing model that determines which capabilities are available. Every subsequent subsection builds on this foundation.

CNAPP: Cloud-Native Application Protection Platform

Defender for Cloud is a CNAPP — a Cloud-Native Application Protection Platform. This is not just a marketing label. CNAPP defines a specific architectural approach that combines two previously separate capabilities into one platform.

CSPM (Cloud Security Posture Management) continuously assesses your cloud environment’s configuration against security benchmarks. It evaluates every resource — virtual machines, storage accounts, databases, network configurations, IAM policies, encryption settings — and identifies misconfigurations that could be exploited by an attacker. The output is security recommendations: specific, actionable findings like “Storage account allows public blob access,” “Virtual machine does not have endpoint protection installed,” or “SQL server does not have auditing enabled.” Each recommendation includes the affected resources, the severity, the remediation steps, and the impact on your Secure Score.

CSPM is preventive. It does not detect active attacks. It identifies the conditions that make attacks possible and gives you the information to fix them before an attacker arrives. A storage account that allows public blob access is not under attack — but it is an open door that any attacker can walk through. CSPM finds the open doors.

CWP (Cloud Workload Protection) provides runtime threat detection for specific resource types. Each Defender plan monitors a specific workload type: Defender for Servers monitors virtual machines for malware, suspicious process execution, brute-force attacks, and lateral movement. Defender for SQL monitors databases for SQL injection, anomalous access patterns, and data exfiltration. Defender for Storage monitors storage accounts for access from suspicious IPs, unusual data download patterns, and malware uploads. Defender for Containers monitors AKS clusters for container escape attempts, malicious image deployment, and suspicious Kubernetes API calls.

CWP is reactive. It detects attacks that are currently happening and generates security alerts that land in your investigation queue. A VM running cryptocurrency mining software is an active threat that CWP detects through process monitoring. A SQL database receiving SQL injection attempts is an active attack that CWP detects through query analysis.

The CNAPP model combines both: CSPM reduces the attack surface by fixing misconfigurations, CWP detects attacks against the remaining surface. Neither alone is sufficient — CSPM without CWP finds problems but misses active attacks. CWP without CSPM detects attacks but does not address the misconfigurations that enabled them. Together, they provide a complete cloud security posture.

The Defender plans model

Defender for Cloud uses a plan-based licensing model. Each workload type has its own Defender plan that can be enabled or disabled independently. This is fundamentally different from M365 licensing where a single E5 license enables everything — in Defender for Cloud, you choose which workloads to protect and pay only for those.

Foundational CSPM (free) is enabled by default on every Azure subscription. It provides the Secure Score, basic security recommendations against the Azure Security Benchmark, and inventory of connected resources. If your organisation has Azure subscriptions, you already have Foundational CSPM data — even if nobody has looked at it. Navigate to Defender for Cloud in the Azure portal to see your current Secure Score and recommendations.

Defender CSPM (paid) extends the free tier with advanced capabilities: attack path analysis (traces paths from internet-facing resources to sensitive data), security graph (maps relationships between resources to identify exploitation chains), agentless vulnerability scanning (scans VMs without installing an agent), governance rules (automatically assign remediation tasks to resource owners), and data-aware security posture (identifies resources that store sensitive data and prioritises their protection).

Workload-specific Defender plans provide runtime threat detection. Each plan is enabled per subscription and protects all resources of that type in the subscription. You can enable Defender for Servers on one subscription and not another, allowing selective protection of production environments while keeping development environments on the free tier.

How Defender for Cloud relates to the broader Microsoft security ecosystem

Defender for Cloud does not operate in isolation. It connects to the same investigation tools you use for M365 security.

Defender for Cloud → Defender XDR. Security alerts from Defender for Cloud can be streamed to the Defender XDR portal. When enabled, cloud alerts appear in the same unified incident queue alongside endpoint, identity, email, and data protection alerts. The Defender XDR correlation engine can link a cloud alert (suspicious VM activity) with an identity alert (anomalous Azure AD sign-in) into a single incident — because the attacker who compromised the identity is the same attacker operating on the VM.

Defender for Cloud → Sentinel. The Defender for Cloud data connector in Sentinel streams both security alerts (SecurityAlert table) and security recommendations (SecurityRecommendation table) into your Sentinel workspace. This enables KQL investigation against cloud security data, custom analytics rules that combine cloud alerts with other data sources, and Sentinel workbooks that visualise cloud security posture trends over time.

Defender for Cloud → Azure Portal. The native Defender for Cloud experience in the Azure portal provides the richest management interface: enabling and configuring Defender plans, reviewing and remediating security recommendations, managing regulatory compliance, and configuring environment settings. Remediation actions (fixing misconfigurations) are performed in the Azure portal because they require Azure resource management permissions.

The practical workflow: Daily SOC triage uses the Defender XDR portal (cloud alerts appear alongside other alerts). Deep investigation uses Sentinel KQL (for correlation with other data sources). Remediation uses the Azure portal (for fixing the underlying Azure resource configurations). Configuration management uses the Azure portal (for enabling plans, configuring auto-provisioning, and setting up connectors).

Azure Policy integration

Defender for Cloud’s CSPM is built on Azure Policy — the Azure governance framework that evaluates resource configurations against defined rules. When Defender for Cloud says “this VM does not have endpoint protection installed,” it is because an Azure Policy definition evaluated the VM’s configuration and found it non-compliant.

Understanding this integration matters for two reasons. First, the security recommendations you see in Defender for Cloud are policy evaluations — they run continuously and update as resource configurations change. When you remediate a recommendation (install endpoint protection on the VM), the next policy evaluation cycle marks the resource as compliant and your Secure Score improves. Second, you can create custom policies that extend Defender for Cloud’s built-in assessments with organisation-specific requirements. If your security standard requires all storage accounts to use customer-managed encryption keys (not just Microsoft-managed), you can create a custom policy that evaluates this condition and surfaces non-compliant resources as security recommendations.

The Security Graph: understanding resource relationships

Defender CSPM’s Security Graph maps relationships between resources in your environment. This graph is what powers attack path analysis — the capability that traces exploitation paths from internet-facing resources to sensitive data.

The graph represents resources as nodes (VMs, storage accounts, databases, identities, network interfaces) and relationships as edges (this VM has network access to this database, this identity has permissions to this storage account, this network security group allows inbound traffic from the internet). By traversing the graph, Defender for Cloud identifies paths that an attacker could follow: internet → VM with public IP and known vulnerability → lateral movement to database server via network access → data exfiltration from database containing customer data.

Each attack path represents a chain of weaknesses that, when combined, create a viable exploitation route. Breaking any link in the chain eliminates the path. The Security Graph tells you which link is easiest to break (the recommendation with the lowest effort and highest impact) and which paths lead to your most sensitive resources (prioritising remediation of paths that reach critical data).

1
2
3
4
5
6
7
8

// Query attack paths in Sentinel
SecurityRecommendation
| where TimeGenerated > ago(7d)
| where RecommendationDisplayName has "attack path"
| extend Severity = tostring(Properties.severity)
| extend ResourceType = tostring(Properties.resourceDetails.ResourceType)
| summarize PathCount = count() by Severity
| order by case(Severity, "High", 1, "Medium", 2, "Low", 3, 4)

Multi-cloud architecture: Azure, AWS, and GCP

Defender for Cloud is not Azure-only. It extends to AWS and GCP through multi-cloud connectors that use cloud-to-cloud API integration. When you connect an AWS account, Defender for Cloud reads the AWS resource inventory (EC2 instances, S3 buckets, RDS databases, EKS clusters), evaluates their configuration against security benchmarks, and applies CWP threat detection.

The multi-cloud capability uses Azure Arc for server-level protection (AWS EC2 instances are onboarded as Arc-enabled servers, which enables Defender for Servers protection) and native cloud APIs for service-level assessment (S3 bucket configurations are evaluated directly via the AWS API). The result is a single pane of glass that shows your security posture across all three clouds — Azure, AWS, and GCP — with consistent recommendations, consistent alerts, and consistent scoring.

For SOC analysts, the multi-cloud integration means cloud security alerts from AWS and GCP appear in the same Defender XDR incident queue and Sentinel workspace alongside Azure alerts. You investigate a suspicious EC2 instance using the same methodology as a suspicious Azure VM. The attacker does not care which cloud provider hosts the workload. Your investigation should not either.

Pricing and cost management

Defender for Cloud pricing is consumption-based — you pay per protected resource, not per user or per subscription. This means cost scales with the size of your environment, not the size of your security team. Understanding the pricing model is important because enabling all Defender plans across a large Azure estate can be expensive, and you need to justify the cost to management by articulating the security value.

The cost management principle: protect production first, development second, and test environments on the free tier. Production workloads handling customer data and running business-critical services need both CSPM and CWP. Development environments need CSPM (to catch misconfigurations before they reach production) but may not need CWP (active threat detection is less critical on environments that do not face external traffic). Test environments can use the free Foundational CSPM tier — they do not need paid protection.

Defender for Servers is typically the largest cost component because server protection is priced per server per month. A large estate with 500 servers on Plan 2 at $15/server/month costs $7,500/month. Evaluate whether all servers need Plan 2 (which includes vulnerability assessment, JIT access, and file integrity monitoring) or whether some can use Plan 1 (which provides MDE integration and foundational protection at $5/server/month).

Knowledge check