Defender For Cloud - under the hood: Defender For Servers Deployment options
Defender for Servers Deployment Methods
To get the most out of this series, I recommend starting with Part One, where I explored why Defender for Servers is a valuable investment for your cloud workload protection strategy. In this post, I will focus on how to deploy Defender for Servers, explain the agent requirements, detail the deployment methods, and highlight a few important considerations you should be aware of.
If you've decided to enhance your Cloud Workload Protection (CWP) using Microsoft Defender for Servers for your Azure, hybrid, or multi-cloud virtual machines, you're moving towards a more secure posture. However, before diving into deployment, it's crucial to understand the underlying mechanisms.
Do I Really Need an Agent?
The first common question is whether an agent is truly necessary. For the comprehensive CWP capabilities offered by Defender for Servers, the short answer is yes.
While Microsoft Defender for Cloud offers valuable agentless capabilities including cloud security posture management (CSPM), agentless secret scanning, and agentless vulnerability scanning (typically using periodic disk snapshots for point-in-time assessments) the full, real-time CWP features within Defender for Servers require agents to be installed on your machines.
These agent-based features provide deeper insights and protection. This reliance on agents for deep CWP is a key difference compared to solutions like Wiz, which often emphasize a fully agentless approach.
TL;DR drawbacks?
There are some clear advantages to agentless setups. They are easier to deploy, require less operational management, and place minimal load on your servers. If your goal is to move quickly and maintain a lightweight footprint, agentless might seem attractive. However, going agentless also comes with limitations. You will miss out on deeper protection capabilities like advanced threat detection, real-time telemetry, and more granular response options that only agent-based solutions can provide. Agent deployments do require more planning. You need to select the right agent, manage its installation and maintenance, and ensure that network communication requirements are met. If you are interested in a full comparison between agent-based and agentless protection models, you can find a detailed guide.
Breakdown of Microsoft agents
Microsoft uses different agents depending on how you decide to onboard your resources. To make things easier, here is a high-level overview summarising which agents are needed based on your deployment method and plan, Information about which agent collects what data can be found here.
At a glance plan one and plan two:
Plan One mainly provides foundational endpoint detection and response (EDR) features for servers, based on Defender for Endpoint. Plan Two includes all of Plan One, plus additional advanced defence features like Just-in-Time VM access, adaptive network hardening, file integrity monitoring, and more. For a detailed comparison:
Deployment options
Azure Native VMs:
This is the most streamlined scenario. To ensure the necessary agents are installed for full Defender for Servers capabilities:
Enable the Plan: Activate Defender for Servers Plan 1 or Plan 2 on the relevant Azure subscription(s) within the Defender for Cloud portal -> Environment Settings.
Enable Auto-Provisioning:
Ensure the Azure Monitor Agent (AMA) auto-provisioning policy is enabled if required for your needs (especially for certain Plan 2 features or log collection).
Ensure the Defender for Endpoint integration is enabled. This setting automatically deploys the MDE agent extension (
MDE.WindowsorMDE.Linux) to your VMs.
Under the hood: These actions leverage Azure Policy behind the scenes to automatically deploy and configure the required agents/extensions on existing and new Azure VMs within the scope. Agentless scanning alone will not provide the full real-time protection and EDR functionality.
Multi Cloud ( AWS and GCP)
For extending comprehensive CWP to AWS EC2 instances or Google Compute Engine VMs, Azure Arc-enabled servers is the recommended approach.
Azure Arc: By onboarding your AWS or GCP VMs to Azure Arc, they appear as resources within Azure Resource Manager. This allows Defender for Cloud to manage and deploy extensions to them, just like Azure VMs. Crucially, Arc facilitates the deployment of both the MDE agent and the Azure Monitor Agent (AMA), unlocking the full feature set of both Plan 1 and Plan 2.
CSPM: Basic Cloud Security Posture Management (CSPM) for AWS/GCP doesn't require agents. It uses API connectors (setup via Defender for Cloud -> Environment Settings) to fetch configuration data and detect misconfigurations. This involves setting up a Connector in Azure and configuring permissions (e.g., via CloudFormation/IAM roles in AWS, or Service Accounts/permissions in GCP) to allow Azure read-only access.
Deployment: Instructions for connecting AWS and GCP accounts and deploying Azure Arc vary. You'll need appropriate permissions in both Azure and your target cloud provider. Instead of a detailed walkthrough here, check out resources like the Defender for Cloud in the Field show for practical guidance:
On premises servers
Similar to multi-cloud, Azure Arc-enabled servers is the standard and recommended method for integrating your on-premises physical or virtual servers with Defender for Cloud.
Why Arc? It unlocks the full feature set of Defender for Servers Plan 1 and Plan 2, including threat detection, vulnerability management, FIM, Adaptive Application Controls, and security recommendations integrated with your overall cloud security posture.
Alternative (Limited): You could install only the Microsoft Defender for Endpoint (MDE) agent directly using the onboarding script from the Microsoft Defender XDR portal. However, this approach primarily provides Plan 1 EDR features. You would miss out on Plan 2 capabilities that rely on the Azure Monitor Agent (like FIM, Adaptive Application Controls) and the seamless integration with Azure management and security recommendations provided by Arc. Read more about MDE-only onboarding limitations here
For my ARC deployment, I chose to onboard on-premises servers through Azure Arc Azure portal experience. I find this method straightforward and well-integrated, although for larger environments or automated deployments, Microsoft also provides detailed command-line instructions here.
The process starts by navigating to the Azure Arc page and selecting the option to add an existing server.
Depending on the number of servers you are onboarding, you can either add a single machine or scale up using scripted deployments that support managed identities and automation tools.
Since I was onboarding a single machine, I selected the "Single Server" option and entered basic information such as resource group, Azure region, and connectivity method.
After setting up the configuration, Azure provides a script tailored to your environment. You will need to run this script locally on the server you are onboarding, using a local administrator account.
The script handles downloading and installing the Azure Arc agent, creating the Arc-enabled server resource within your Azure subscription, and linking the server to the appropriate resource group and region.
Once the agent is successfully installed and registered, the server will appear within the Azure portal where it can be managed, monitored, and secured under the Defender for Servers plans.
Using the standalone MDE extension:
Using the MDE extension is NOT recommended ( instead use azure arc) but you can access it from the XDR portal under settings > endpoints > onboarding.
MDE Plan support: Direct onboarding provides access to all Defender for Servers Plan 1 features. However, certain features in Plan 2 still require the deployment of the Azure Monitor Agent, which is only available with Azure Arc on non-Azure machines.
Multi-cloud support: You can directly onboard VMs in AWS and GCP using the Defender for Endpoint agent. However, if you plan to simultaneously connect your AWS or GCP account to Defender for Servers using multi-cloud connectors, it's currently still recommended to deploy Azure Arc.
Simultaneous onboarding limited support: For servers simultaneously onboarded using multiple methods, Defender for Cloud makes every effort to correlate them into a single device representation. However, devices using older versions of Defender for Endpoint agent might face certain limitations. In some instances, this could result in overcharges.
Important Setting: If you choose this MDE-only direct onboarding method for non-Azure machines (and are not using Arc or the multi-cloud connectors for CWP), ensure you enable the "Enable direct onboarding" setting within Defender for Cloud -> Environment Settings -> Relevant environment (e.g., default settings or specific group). This helps Defender for Cloud recognize these MDE-managed machines.
Keep in mind:
Servers onboard to defender for cloud plan one or two will appear in the Microsoft XDR portal, in the device inventory.
Read about onboarding defender for servers via defender for endpoint onboarding package here.
At a glance quick reference server onboarding methods:
Have blog ideas, want to engage on a topic, or explore collaboration? Let’s take it offline reach out on LinkedIn. I’d love to connect and continue the conversation!