Welcome to our multi-part series!
Have you read all the docs only to find yourself overwhelmed by all the features and agents available and need help deciding which to onboard? Do you need help with the nuances of setting up Private Link for Azure Arc? Are you using SCOM to onboard MMA to your servers still and unsure of the path forward to AMA? Then look no further! With this multi-part series, we will guide you through the decision process to find the best path on your monitoring and endpoint protection journey with the end goal being successfully deployment of Defender for Servers.
Link to Part 2 (focuses on Arc Agent Deployment)
Link to Part 3 (focuses on Defender for Servers at Scale Deployment)
What’s in this blog:
- Agent Decisions: Which agents do you actually need to achieve your goals?
- Review of deployment options for Defender for Servers
- Considerations for FIM and MDVM features
- Scenarios requiring Arc agent
- Long-term usage of SCOM with MMA/AMA
What’s not in this blog:
Detailed deployment of Microsoft Defender for Endpoint
If you’d like a refresher on successfully migrating from a 3rd party EDR solution and onboarding to Defender for Endpoint, see here: David McWee - MDE Get Healthy with MDfS Driven Migration
Do we even need the Azure Arc agent or the Azure Monitor Agent?
The question of the decade…and the answer is now ‘it depends!' As it stands, The Defender for Servers Product Team is de-prioritizing the Arc Agent and Azure Monitoring Agent as requirements for the deployment of Defender for Servers. Let’s first consider a scenario where you will benefit with the new Direct Onboarding feature and may not need to add one or both of the abovementioned agents.
|
|
Defender for Servers P1 |
Defender for Servers P2 |
Update Management, Azure Policy, Change Tracking etc.1 |
|
Non-Azure server |
Arc not required with Direct onboarding, AMA not required |
Arc required, AMA required (FIM2) |
Arc required, AMA required |
|
Azure server |
Arc not required, AMA not required |
Arc not required, AMA required |
Arc not required, AMA required for some features |
1 Full overview of features and benefits of Arc
Scenario 1: Direct Onboarding Defender for Servers P1 w/o Azure Agents
Review this QuickStart on Direct Onboarding as a starting point.
Scenario:
This deployment scenario is designed for organizations and users that want to monitor and alert on Defender for Endpoint-enabled servers in Defender for Cloud, but are not ready to roll out Azure agents to their workloads. To clarify, direct onboarding does not require the Azure Arc agent or the Azure Monitor Agent. For example, you may have a mix of Azure servers, as well as on-premises machines. You have potentially onboarded a portion, if not all, to Defender for Endpoint. The long-term plan for you is to onboard all of your digital estate to Defender for Endpoint as your EDR solution, and you would like to be able to see the alerts from MDE in Defender for Cloud in a single pane of glass. Alternatively, you could be using another product as your EDR and AV solution, but you would like to leverage Defender for Vulnerability Management and see vulnerability assessment results in Defender for Cloud.
Outcomes:
- Direct Onboarding doesn't provide server management capabilities such as Azure Policy, Extensions, or Guest configuration. To enable server management capabilities, that will require the Azure Arc agent (see Scenario 2) and potentially, other extensions depending on the use case, such as Change Tracking.
- Once enabled, it also shows your non-Azure servers onboarded to MDE in Defender for Cloud, under a designated Azure Subscription you configure (in addition to their regular representation in the M365D portal).
- Affects both existing and new servers onboarded to MDE in the same Azure AD tenant.
Impact:
The Direct Onboarding option will tie all your mssense agents (extension for MDE) to an Entra tenant and connect them to a specified Azure Subscription; when you view your alerts in Defender for Cloud, you will need to filter to that subscription to see data from MDE on those servers. This deployment method may complicate billing as it will ultimately bill the licensing for the associated products to a singular chosen subscription. See the note on billing further below.
To turn on Direct Onboarding, in Defender for Cloud, navigate to Defender for Servers => Environment Settings.
Select Direct Onboarding => Toggle to ON => Select or create a subscription for all your objects.
If the designated subscription is a newly created subscription, don’t worry about the “Missing plan” message that you may receive next to the subscription name, as Defender for Servers P1 will be automatically enabled.
When complete, make sure to click “Save” at the top left. It could take up to 24 hours before all resources populate in your panel. Navigate back to this pane and click Resource Inventory to ensure there are no missing objects.
NOTE:
In this pane you will notice that you are onboarding non-Azure servers to Defender for Servers only using the Defender for Endpoint agent and no other agent is required.
All MDE agents under this tenant will now be billed in a singular subscription you choose in a Defender for Servers P1 state. Unfortunately, at the time of article publication, you cannot select multiple subscriptions. The billing is supposed to be automatic but it is prudent to put in a CSS (Support) request for billing after enablement to ensure you move from licensing to per server per user Azure Consumption.
Scenario 2: Defenders for Servers with Azure Arc Enablement
Scenario:
This is ideal for organizations with a hybrid cloud environment with servers running on-premises and in the cloud. You want all the server management and automation capabilities that Arc enables for you in Azure, while ensuring that all servers are protected against cyber threats and comply with security standards. Furthermore, you are looking to use Arc as an orchestration agent to help push other agents/extensions to your non-Azure servers. In this deployment option, you first onboard all applicable servers to Arc, and then simply enable your desired Defender for Servers plan in Defender for Cloud Environment Settings.
Outcomes & Impact:
- Visibility of all servers’ recommendations, alerts, Defender for Endpoint data, etc. in one single pane of glass in Defender for Cloud.
- Simplified deployment of other agents and extensions to Arc-enabled servers. For example, Defender for Endpoint can be mass deployed to all Arc servers via the following setting:
Azure Monitor Agent vs. Microsoft Monitoring Agent
There is now no requirement to have monitoring agents deployed to enable Defender for Servers nor does Azure Arc have a dependency on the Azure Monitor Agent or the legacy Microsoft Monitoring Agent.
NOTE: The legacy Microsoft Monitoring Agent will be retired on 31 August, 2024. If you are using the Microsoft Monitoring Agent in your any of your scenarios, we recommend that you start planning your migration to the Azure Monitor Agent (AMA): Migrate from legacy agents to Azure Monitor Agent.
- Automanage and the Inventory and Change Tracking solutions are still available with the Azure Monitoring Agent (AMA). Unfortunately, the Azure Automation Update Management solution does not work with AMA, and requires the legacy MMA, so the guidance is to transition to move to Azure Update Manager for your software update needs.
- Azure Monitoring Agent has been benchmarked to consume at 10,000 simulated Syslog event per second. Check out benefits for a detailed list of agent improvements from the legacy one.
- To help you migrate to AMA, please see the requirements for installing the Azure Monitor Agent to on-premises servers. For networking guidance specifically, please see firewall requirements for the Azure Monitor Agent.
- Previously, there was an option to select Azure Monitor Agent or Log Analytics Agent (also known as Microsoft Monitoring Agent) to auto-provision to the servers in the filtered subscription, but as Defender for Servers has shifted away from a dependency on either agent, the option is solely for onboarding Microsoft Monitoring Agent (see screenshot below). If you have done this auto-provisioning to your servers, then adding the new Azure Monitor Agent to a server will not disrupt or remove the Microsoft Monitoring Agent.
- Having both agents (AMA and MMA) on your servers will give you more time to decide on your migration process while still enabling Defender for Cloud and taking advantage of the 500MB/server data credit through Defender for Servers Plan 2. In this instance you will have a dual agent scenario. For tips and guidance on preventing data duplication during the transition period with two agents, please see: Migrate from legacy agents to Azure Monitor Agent - Azure Monitor | Microsoft Learn
Azure Monitor Agent (AMA), Microsoft Monitoring Agent (MMA), Azure Arc AND System Center Orchestration Manager (SCOM)
Azure Arc and Azure Monitoring agent (AMA) can be run in parallel with your Microsoft Monitoring Agent (MMA)/System Center Orchestrator Manager (SCOM): Running SCOM agent in parallel with MMA and/or AMA. This scenario applies to customers running System Center Orchestration Manager on-premises that have either deployed the SCOM agent to forward data to Log Analytics workspace (LAW) or the SCOM agent with Microsoft Monitoring Agent (MMA) to forward to LAW.
- The only support scenario in 2024 for SCOM with MMA is to migrate to the AMA, and the future state is using AMA only to forward logs to Log Analytics. The SCOM agent can continue to forward data to SCOM servers. Another option for the current state is to move to SCOM Managed Instance, but ideally, shifting to Azure Monitor Agent is the best option long-term. See Agent recommendations for SCOM users - Microsoft Community Hub.
In this configuration, pictured below, the MMA/SCOM maintains its connection to SCOM while the AMA with Data Collection Rules (DCR) is allowed to process logs to different locations in Azure, while allowing for the enablement of Update Management and other Automation features. The process is to disconnect (DO NOT delete) the Microsoft Monitoring Agent from Log Analytics.
Considerations for File Integrity Monitoring
With File Integrity Monitoring, you can monitor critical files and directories for changes, and receive alerts when changes are detected. You can also view detailed information about the changes, such as who made the change and when it was made. FIM through Defender for Servers currently depends on the Microsoft Monitoring Agent or the Azure Monitor Agent, as well as the Change Tracking extension.
- FIM is migrating to Defender for Endpoint so it will no longer require MMA or AMA but will rather depend on integration with the MDE agent (transition will occur by August 2024).
- In the meantime, it is advised to implement FIM using the MMA to monitor file and registry changes on your machines.
Considerations for Microsoft Defender Vulnerability Management
For vulnerability assessment on machines enrolled in Defender for Servers, the Qualys scanner option is being deprecated, and the way forward is leveraging the MDVM (Defender Vulnerability Management) component of Defender for Endpoint (MDE). To review the options for deploying a vulnerability assessment solution to your servers, please see the screenshot below:
- Agentless scanning does vulnerability assessment and is powered by MDVM (Defender Vulnerability Management) in the backend; currently, the capability is for Azure VMs, but is also available for any AWS and GCP machines. Thus, for any AWS, GCP, Azure servers, you can rely on the Agentless option instead of going the MDE onboarding route.
- The Endpoint protection option deploys Azure policy in the backend that attempts to onboard servers in scope to Defender for Endpoint.
- If you select Microsoft Defender Vulnerability Management as your vulnerability assessment tool, results will be displayed in the unified pane in Defender for Cloud either from agentless scanning or through the MDE agent, depending on what is enabled on the server.
Are you using a third-party EDR/AV solution, but still want to take advantage of all the features of Defender for Servers and leverage MDVM for vulnerability assessments?
For on-premises servers, you will currently need to onboard them to MDE to get the MDVM capability; thus, it is recommended you add Defender into the exclusions of your third-party product and make sure MDAV (Defender Antivirus) is in passive mode if you are planning to use the third-party AV.
On Windows Server 2019, Windows Server, version 1803 or newer, Windows Server 2016, or Windows Server 2012 R2, Microsoft Defender Antivirus (MDAV) doesn't enter passive mode automatically so you will need to set it manually using a registry key. For all other servers, MDAV should go into passive mode automatically after detection of third-party products.
Link to Part 2 (focuses on Arc Agent Deployment)
