Microsoft Defender for Cloud (former Azure Security Center) provides ‘Enhanced Security Features’ also known as Defender plans, to protect workloads in the Azure environment. What I see often is that these plans, or features, are not consistently enabled between subscriptions even though there would be a decision that the features should be enabled. The main reason often is manual configuration instead of automatic configuration of the settings (technical control is missing).
In this blog post, I share a simple solution on how the challenge can be tackled. The assumption on this write-up is that decision of enabling the features has been made (including cost impact).
Setting up the Scene
In the last Microsoft Ignite new name for the former Azure Security Center was announced – Microsoft Defender for Cloud. Earlier there were two different modes available: Free & Standard but nowadays Microsoft is talking about ‘Enhanced Security Features’.
In general, Defender for Cloud (MDC) can be categorized into three (3) different categories
In the last category, there are Microsoft Defender Advanced Threat protection, security alerts, and integration with Microsoft Sentinel or 3rd party SIEM. For enabling MDC Advanced Threat protection the plans need to be enabled (those are not enabled by default). At the time of writing the plans are:
- Microsoft Defender for servers
- Microsoft Defender for Storage
- Microsoft Defender for SQL
- Microsoft Defender for Containers
- Microsoft Defender for App Service
- Microsoft Defender for Key Vault
- Microsoft Defender for Resource Manager
- Microsoft Defender for DNS
- Microsoft Defender for open-source relational databases
Enable Enhanced Security Features for the Subscription
Enhanced security features can be managed with any of the following methods:
- Azure portal
- REST API
- Azure CLI
- Azure Policy
It doesn’t matter what mechanism you are using as long as you use one. What is important is that you have your settings aligned with your security policy and decisions. In the larger environments, there might be also a differentiation between enhanced security features configuration in the subscriptions. One of my customers has more than 100 subscriptions and for example, in that specific environment, there are small variations in the settings between different sub-categories (test/dev/QA/prod).
Once you have a decision in place, you should make sure that every time the new subscription is created these settings are aligned with the policy. This can be achieved by adding configurations to your deployment processes depending on how you deploy your Azure subscriptions (Portal, ARM, Bicep, Blueprints, Terraform to name a few options).
Configuring Security Features (Azure Policy)
Nowadays, Azure Policy supports configuring Enhanced Security Features by policies. This is a very handy way to ensure that all features are configured from the start when Azure subscription is ramped up. At the time of writing, the following Azure Defender (MDC) related built-in policies are available in Azure Policy.
Side note: As you can see there is already one (1) policy named “Microsoft Defender” instead of “Azure Defender”.
There are both, Audit and DeployIfNotExist types of policies available. The most efficient way to enable ‘Enhanced Security Features’ when using Azure Policy is to create a custom initiative where you add individual ‘Azure Defender’ & ‘Microsoft Defender’ related policies, save the initiative to tenant root group so that is available for all subscriptions, and also assign the policy from the tenant root group.
If you create your own initiative, you need to maintain it! Microsoft publishes new built-in policies all the time, so it’s an organization’s responsibility to have a continuous development process in place to add new policies and remove deprecated ones. A good example of this is the latest announcement in Defender for Cloud Enhance Security Features plans. There was a change in ‘Container’ plans that are seen in the portal.
In the examples below I’m using Azure Policy in my demo environment to configure MDC plans. At the end of the day, there is non-compliant status in both, ‘Deploy – Microsoft Defender for Cloud Enhanced Security Features Configuration‘ and ‘Audit – – Microsoft Defender for Cloud Enhanced Security Features Configuration‘ policies.
Defender for Containers
Side note: There is a new built-in policy for the new MDC plan ‘Microsoft Defender for Containers’ available if would like to have the latest plans enabled automatically included in the custom policy definition.
Configuring Security Features (PowerShell)
If you are using other methods such as REST API or PowerShell there are interfaces available to configure the settings (status also seen in Azure Resource Graph). As said, it depends on how the Azure environment and especially security settings are maintained in your organization.
Auditing Security Features
Even though the configuration of the settings is possible through Azure Policy there is room for a slightly different approach.
Many organizations are using IaC to configure their Azure environment. In this scenario, it’s better to have configuration-related settings in one place instead of multiple ones. Also, a version history is under better control if the DevOps platform is used to manage configurations.
The second aspect is remediation tasks. If there are constant changes to the configuration we’ve seen that it might lead to a situation where there are a number of Azure Policy remediation tasks (which need to be managed). This might not be the case with MDC plans but it’s best practice to be consistent in this area.
That being said, the approach we (me & my awesome colleagues) are suggesting to customers is in a nutshell: ‘If Azure platform is managed as IaC use the same method to configure MDC plans and use audit policy (custom initiative) to audit compliance status. If IaC is not in use then Azure Policy is feasible’.
I have created a custom initiative that contains all the Microsoft Defender / Azure Defender audit policies. With the audit policy, you can easily monitor the compliance status and verify that Defender plans are consistent in the whole organization.
As you can see, there is one with the “Non-compliant” status. I created an exemption for that specific subscription because old plans are still used in there (will be migrated later).
With the exemption of resources, I can remove the specific resources from specific policies or policy sets. This is a fairly new feature that is absolutely crucial because you want to keep your dashboards green (exempt the resources that are not compliant because of some good reason).
After initial configuration, it takes approximately 30min after policy exemption is re-evaluated and all green now and good to go 🙂
Azure Log Analytics
The MDC ‘Continuous Export’ provides an opportunity to export the following data types to the external source (Azure Event Hub or Azure Log Analytics):
- Security recommendations
- Secure score
- Security alerts
- Regulatory compliance
Side note: If you are exporting audit data to Event Hub and outside Azure, for example, 3rd party SIEM, take into account that the Azure Monitor log contains the same events (+more) which are exportable from MDC.
When Log Analytics export is used you can fine-tune your queries based on the recommendations in LA.
Azure Policy deep diver by Markus Pitkäranta (@PitkarantaM)