Microsoft Defender for Cloud continually assesses your subscriptions to identify resources and provide security recommendations for them.
For the large organizations with many subscriptions, it is recommended to manage access and policies using Azure Management Groups to organize their subscriptions according to the business needs. By moving multiple subscriptions under that management group, you can create one Azure role assignment on the management group level, which will inherit that access to all the subscriptions. Every directory is given a single top-level management group called “Root” management group. This root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. Similarly, when organizations need to enable Microsoft Defender for Cloud across different subscriptions that have different workloads and therefore different assessment needs, it is also common that they want to customize its policies and control it in the Management Group level rather than in the subscription level to maintain centralized policy management in Microsoft Defender for Cloud. Refer to this article if you haven’t already thought of this approach.
With the above understanding of Management Groups and visibility across multiple subscriptions, is important to always be aware of scenarios that a new subscriptions is created and by default stays in the Root Management Group. It is a common scenario for organizations provision new subscriptions on the daily basis and since those subscription will be added to the root management group, it creates a challenge to maintain them in the correct Management Group. This also creates a problem of monitored vs non-monitored subscriptions. In this blog, I’m introducing you to a workflow automation that helps you to identify subscriptions that are not monitored and take an action to fix the problem.
The automation uses User Assigned Managed Identity to be able to query the Root management group. Please follow the below step by step instructions:
How to deploy the automation playbook
You can find an ARM template that will deploy the Logic App Playbook and all necessary API connections in the Microsoft Defender for Cloud GitHub repository. Once you have deployed the ARM template, you will have some manual steps to take before the tool will work as expected.
Make sure to authorize the Office 365 API connection
This API connection is used to send emails weekly. To authorize the API connection:
Authorize the Tenant Root Group and Logic App’s managed identity
The Logic App is using a user assigned managed identity. For this purpose, you need to grant it the Reader role on tenant root management group, so it is able to query all the subscriptions.
Make sure you have User Access Administrator or Owner permissions for this scope.
Make sure you assign the User assigned managed identity to Logic App.
How it works
By default this automation runs weekly and queries the Root Management group to identify any new subscription(s) that are directly assigned to the root management group. If one or more subscriptions are found in the Root management group, the Logic App will send an email with the following details: Subscription Name, Subscription ID, Action, Status of the subscription (If ASC is enabled or disabled). Image 1 has an example of how this email look like:
Make sure to add the subscription(s) to the Management Groups in order to start monitoring using Microsoft Defender for Cloud. The automation artifact also creates a Storage account with a table storage in it during the deployment of the template. If the intent of assigning the subscription to the root management group was on purpose, you could exclude the subscription from being displayed in the email on next run by just clicking on the hyperlink ‘Exclude <subscriptionname>’ under the Action column of Image 1. When you click on the hyperlink, the subscription name will be added to the table storage of the storage account. The successful addition to the exclusion list will be confirmed in the browser as shown in Image 2.
With the help of Microsoft Azure Storage Explorer, you can connect to the storage account to confirm the subscription has been added successfully in the above step. Refer to the example in Image 3.
By doing so, during the next run of the logicapp, it queries the exclusion list (table storage) and incase the result matches to the subscription(s) already in the exclusion list, the logicapp does not alert you for that subscription(s) as it understands the assignment to the root management group was on purpose. This process makes it easy to the security admins to deal with monitored vs un-monitored subscriptions.
An example of next run is shown in the example screenshot Image 4 (Notice how ‘Azure Subscription 1’ is excluded and not notified in the email).
It is very important to notice the ASC Enabled field and make sure the subscription is monitored with the help of Microsoft Defender for Cloud so that Security Center is able to assess your environment and enables you to understand the status of the resources and eventually help you increase your organization’s secure score.
Go ahead, deploy the workflow in your environment to prioritize monitoring security hygiene. Make sure to let us know what you think by commenting on this article.
This logic app as well as many other can be found here:
Special Thanks to ‘Nicholas DiCola, Partner Director’ & ‘Gilad Elyashar, Principal Group Program Manager’, for envisioning this wonderful automation idea.
Special Thanks to ‘Yuri Diogenes, Principal PM Manager’ for reviewing this article and for the inputs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.