Microsoft Defender for Cloud doesn’t actually "enable" in the way you might think; it’s already "on" by default for all Azure subscriptions, but its value is unlocked by configuring its security policies and features.
Let’s see it in action. Imagine you have a virtual machine in Azure. Without any Defender for Cloud configuration, it’s just a VM.
# This is what a basic VM looks like in Azure Resource Graph Explorer
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| project name, location, sku.name
Now, let’s say we want to leverage Defender for Cloud’s enhanced security features for this VM, specifically its advanced threat protection. To do this, we need to ensure the relevant Defender plan is enabled at the subscription level.
Here’s how you’d check and enable the Defender for Servers plan using Azure CLI. First, check the current status:
az security defender show --name Servers --query 'id'
If it returns null or an empty string, the plan isn’t active. To enable it, run:
az security defender create --name Servers --subscription <your-subscription-id>
Replace <your-subscription-id> with your actual subscription ID. This command tells Azure to start provisioning the necessary agents and services for enhanced server protection on resources within that subscription.
What happens under the hood? When you enable a Defender plan, Azure Defender for Cloud begins deploying agents (like the Log Analytics agent or Azure Monitor Agent) to your resources if they aren’t already present. For servers, this typically involves the Log Analytics agent for Windows/Linux VMs to collect security events and send them to a Log Analytics workspace. Defender for Cloud then analyzes this data, correlates it with threat intelligence, and generates security alerts.
The core problem Defender for Cloud solves is the lack of unified visibility and proactive threat detection across diverse cloud workloads. It aggregates security posture management (CSPM) and cloud workload protection (CWP) capabilities into a single pane of glass. CSPM helps you understand your security configuration and compliance status, while CWP focuses on detecting and responding to threats at runtime.
The exact levers you control are primarily through security policies and Defender plans. Security policies, often driven by Azure Policy, define what security best practices your resources should adhere to (e.g., "all storage accounts should have public network access disabled"). Defender plans, like Defender for Servers, Defender for Storage, Defender for SQL, etc., enable the advanced threat detection and vulnerability assessment capabilities for specific Azure service types. You can enable or disable these plans at the subscription or management group level.
You also configure Log Analytics workspaces. Defender for Cloud uses these workspaces to store collected security data. You can choose an existing workspace or let Defender for Cloud create a new one. The region of the workspace is important for data residency and performance.
Here’s a snippet of what you might see in your Log Analytics workspace after enabling Defender for Servers and generating some activity (e.g., a simulated brute-force attempt):
SecurityEvent
| where Computer has "your-vm-name"
| where EventID == 4625 // Logon failure
| summarize count() by IpAddress, Account, bin(TimeGenerated, 1h)
| order by TimeGenerated desc
This KQL query, run in your Log Analytics workspace, would show failed login attempts on your VM, originating from various IP addresses. Defender for Cloud’s CWP features would then analyze this pattern and potentially generate a "Brute force attack detected" alert.
A crucial aspect that often surprises people is how Defender for Cloud utilizes Azure Policy for its CSPM capabilities. When you enable Defender for Cloud, it automatically assigns a set of "ASC" (Azure Security Center) policies to your subscription. These policies are designed to audit your resources against security benchmarks like CIS or NIST. For example, a policy might audit for unencrypted disks or unpatched operating systems. The remediation of these policy violations can be automated via Azure Policy’s remediation tasks.
The next concept you’ll likely encounter is the detailed configuration of workflow automation to automatically respond to security alerts.