Recently, I was asked about our strategy around providing controls to Azure Lighthouse, and it’s ability to DRM external users from external tenants or subscriptions, and guest them into a production or customer owned tenant, providing a significant data exfiltration risk where a malicious, or unaware privileged user could cause a serious security incident. A modern risk requires a modern approach to machine detection and prevention at the earliest level possible in the kill-chain.
There are two parts of your defence in depth strategy that can help here. 1) Controlling which tenants are trusted via a custom Azure Policy. 2) Detecting the events via a custom analytics rule to be flagged as an incident in Microsoft Sentinel. If you wish to easily setup this delegation, you can easily do so via the GUI interface within Azure Lighthouse, that generates JSON within an Azure resource manager template, you can leverage the template here Azure-Lighthouse-samples/templates/delegated-resource-management/subscription at master · Azure/Azure-Lighthouse-samples · GitHub and deploy into the subscription using this quick link GitHub – Azure/Azure-Lighthouse-samples: Provide samples for understanding managed service solutions. There is also some really cool stuff in Azure AD, such as tenant access policies and tenant restrictions that can also provide some additional B2B control, but in this circumstance wouldn’t be the right solution to stop DRM events via Azure Lighthouse.
Apply the policy rule on the alias for the managedByTenantId on registrationDefinition resource as you can see below, as part of your Azure Policy definition to block any subscriptions that aren’t on this list.
The next thing you can do is block via your SIEM tool. In Microsoft Sentinel, you can create a custom analytic rule to look at the activity log, and look for the specific events generated from the Azure Lighthouse DRM action.
In this circumstance, the following events are specifically unique to the DRM action:
| Operation name | Status |
| Add Managed Services Registration Definition | Started |
| Add Managed Services Registration Definition | Succeeded |
| Add Managed Services Registration Assignment | Started |
| Add Managed Services Registration Assignment | Accepted |
Therefore, creating a KQL script as part of that custom analytics rule here, will provide you with the right monitoring to detect these events.
You then set your code to look for these specific operationnames and define your threshold (between 5mins and 14 days).
You can then run automation in response to this incident. Whether it’s raising an incident, all the way through to taking more invasive approaches such as disabling the listed user’s account, reapplying controls, or something else that is more custom, there is plenty of controls for you to meet whatever use cases you may have.
Don’t forget folks to automate and leverage your SOAR capabilities where you can. Some say 2023 is the year of AI / ML, and I expect to see much more innovation in this space to provide a matured, modern incident response strategy.
You must log in to post a comment.