Late night testing and listening to some great Synthwave tunes. while waiting for some Azure Automation and Desired State Configuration to kick in, it dawned on me. I should start consolidating my notes around How to onboard your Linux VMs for Azure Defender and Microsoft Defender for Endpoint.
The following will be a lose draft idea but as time permits I should have a more thorough official guide for enterprise onboarding in the coming weeks.
So what started all of this research, onboarding and building assets ? Well at the beginning of August the Azure Defender product team released a public preview of the capabilities for Azure Security Center to push Microsoft Defender for Endpoint to Linux VMs. It also included the licensing for MDE under Azure Defender for Servers sku. Announcement Here.
What’s great about this is Azure VMs and Azure ARC connected servers will get the MDE.Linux VM Extension pushed deploying and configuring MDE to the Linux Server. Details Here.
This guide is assuming your enterprise is onboarding root management group or a set of management groups via Azure Policy. You have many subscriptions, Linux VMs, and will have more subscriptions and Linux server build outs in the future. You want to centralize and auto push this environment. You want all the capabilities of Azure Defender for Servers deployed.
Part 1: Setup Azure Security Center through Azure Policy
The following is a screenshot of ASC Pricing and Settings screen to show which Azure policies and where they apply
1b (There doesn’t appear to be a custom azure policy to push MMA\Dependency for ARC VMs)
2 (Contact Information - custom)
3 (Enable Integrations -MCAS and MDE - custom)
4 (Enable Azure Defender for Servers - custom)
5 (Optional - Deploy Qualys vulnerability assessment solution VMs- custom)
5b (Optional - Deploy Qualys vulnerability assessment solution ARC VMs- custom )
6 (Optional - Deploy AntiMalware extension for Windows Server 2008R2 - 2012R2)
*Note: Due to a Azure Policy Initiative assignment limit where you can only set one remediation task for a policy, many of these policies DeployIfNotExists use remediation tasks. Due to this limitation you must assign each policy definition independently - see feedback details.
There is also a policy for Azure Defender for All services to assign just once.
With the following set,
ASC - Auto Provisions Log Analytics and Dependency agents onto Azure VMs
ASC Integrations with MDE licenses and pushes MDE onto Azure VMs
Azure Policy will deploy Qualys vulnerability assessment solution to Azure and ARC VMs
AntiMalware extension will be deployed to Azure VMs Windows Server 2008R2 - 2012R2
Part 2: Updating Azure Sentinel - Data Connector for New Azure Subscriptions w/ Azure Defender
As new subscriptions are onboarded and Azure Defender is turned on through Azure Policy, the Azure Sentinel Data Connector for Azure Defender alerts needs to be updated and enabled for those new subscriptions. The following LogicApp: AutoConnect-ASCSubscriptions written by Lior Tamir acts as a 24 hour timer that checks for new Azure Subscriptions and enables them in the Azure Sentinel Data Connector for Azure Defender. Bi Directional Sync is also enabled to keep alerts aligned between Azure Sentinel and Azure Defender.
Part 3 (*work in progress): Azure Automation, Azure Policy, and Desired State Configuration
With MDE onboarded for Linux Servers there is also a Linux Defender AV installed. The standalone AV configuration for exclusions and other behaviors is done locally through a couple options.
Chef / Puppet / Ansible is usually the most preferred choice
Config file found: /etc/opt/microsoft/mdatp/managed/mdatp_managed.json
Azure Automation w/ Desired State Configuration to push mdatp_managed.json
Option 4 is currently what I am working on testing and will hopefully have some assets and detailed guidance soon.
At a high level as I am:
You deploy Azure Automation without RunAs creds
You search module gallery and add nx
You deploy a Storage Account and create a container and upload your custom mdatp_managed.json
Create a .ps1 DSC point the source url to storage blob uri of your mdatp_managed.json
Example DSC linuxavconfig.ps1
Within Desired State Configuration you upload DSC .ps1 and compile
Using Azure Policy you push DSC VM Extension to Linux Azure VMs
Example Azure Policy deploy-dsc-linux.json
I also built a ARM Deploy template for DSC VM Est for Linux server while testing the DeployIfNotExists for the Azure Policy.
What if I need to change the mdatp_managed.json and need to push again through policy. At a high level:
Create a new container and upload the new mdatp_managed.json
copy and create a new .ps1 DSC, make changes as needed including the new blob uri path, be sure to change the configuration name in dsc code and save the .ps1 with different name ex. linuxavconfigv2.ps1.
Within Desired State Configuration you upload DSC .ps1 and compile
Use a script or portal to reassign nodes to the new DSC .ps1 configuration
Update the Azure Policy Definition to the new DSC Configuration node name.
Hopefully with some more time and a few more engagements I will have this refined and in a more thorough enterprise onboarding guidance document. Stay safe and as always stay #synthwave.