This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Azure Lighthouse provides capability for cross-tenancy management of Azure services for Managed Service Providers (MSPs) and organizations with multiple Azure tenants, all from a single Azure portal. Azure Lighthouse is integrated with Azure Sentinel allowing organizations to easily manage Azure Sentinel workspaces from across multiple tenants. In this blog we will show you how to configure Azure Lighthouse, and how to use its capabilities to investigate an attack as it targets several customers at once.
Full documentation on Azure Lighthouse can be found here: https://docs.microsoft.com/en-us/azure/lighthouse/how-to/onboard-customer
Enabling Azure Lighthouse for Sentinel requires configuration on both the managing tenant and customer tenant (for the purpose of this blog we will refer to customer tenant to describe the tenant to be managed, whether this is an external customer or separate internal tenant), we will address these elements separately.
Managing Tenant Configuration
Several items are needed to configure Lighthouse for Azure Sentinel:
- The tenant ID of the managing tenant.
- The ID of the Azure AD group in the managing tenant that you wish to have access to Azure Sentinel in the customer tenant. It is advised that a specific Azure AD group is created for this purpose.
(Get-AzADGroup -DisplayName "<Group Name>").id
- The ID of the user role that you wish the AD group to have within the customers tenant. For this you can use built in Role Definitions such as Security Reader, or create a custom definition.
(Get-AzRoleDefinition -Name “<Role Name>”).id
The core deployment of the Azure Lighthouse configuration will be made using this Azure Resource Manager (ARM) template - https://github.com/Azure/Azure-Lighthouse-samples/blob/master/Azure-Delegated-Resource-Management/templates/delegated-resource-management/delegatedResourceManagement.json
In order to ensure this ARM template deploys the required configuration it is accompanied by a parameters file which you must populate with the ID details listed above. A template for this parameters file can be found here: https://github.com/Azure/Azure-Lighthouse-samples/blob/master/Azure-Delegated-Resource-Management/templates/delegated-resource-management/delegatedResourceManagement.parameters.json
To complete the parameters file, update the values as follows:
- mspOfferName – provide a display name for your managed service offering (this can be seen within the customer tenant).
- mspOfferDescription – provide a description for your managed service offering (this can be seen within the customer tenant).
- managedByTenantId – the tenant ID of the managing tenant.
- authorizations
- principalId – the ID string of the Azure AD Group in the managing tenant you want to grant access.
- roleDefinitionId – the ID of the user role that you wish the AD group to have within the customers tenant.
- principalIdDisplayName – provide a name for the group being granted access (this can be seen within the customer tenant and does not have to be the same as the AD group name).
Once complete your parameters file should look something like this:
Note: If you want to grant multiple groups access at differing role levels, you can include multiple entries under the authorizations section– see https://docs.microsoft.com/en-us/azure/lighthouse/how-to/onboard-customer for an example of this.
Once you have completed the parameters file you will need to provide the ARM template and parameters file to a user with the Owner role within the customer tenant.
Customer Tenant Configuration
After receiving the ARM template and parameters file from the managing tenant, the customer tenant must deploy the configuration within the subscription that contains the Azure Sentinel workspace to be managed.
The first step in provisioning Lighthouse access within the customer tenant is to register the ManagedServices Resource in Azure. You can check if this is already registered via PowerShell with:
Get-AzResourceProvider -ProviderNameSpace Microsoft.ManagedServices
(If you are not using Azure Cloud Shell you will first need to run the Connect-AzAccount cmdlet to authenticate to Azure)
This should return an output similar to this:
If the RegistrationState does not read ‘Registered’ for all Workspaces in the output run the following command in PowerShell to register the service:
Register-AzResourceProvider -ProviderNamespace Microsoft.ManagedServices
Once the ManagedServices Resource is registered you can deploy the Lighthouse ARM template with the correct parameters provided by the managing tenant. First select the subscription that the Azure Sentinel workspace to be managed is part of using:
Select-AzSubscription -SubscriptionId ‘<Your Subscription ID>’
Then deploy the ARM template with:
New-AzDeployment -Name <deploymentName> `
-Location <AzureRegion>`
-TemplateFile <Path to ARM template> `
-TemplateParameterFile <Path to parameters file>`
-Verbose
(You can deploy in any region, if you are unsure you can use the region your Azure Sentinel workspace is deployed in.)
If deployed correctly the output should look like this:
.png)
To confirm if this deployment has been successful navigate to the Azure Portal and search for Service Providers. In here select Service provider offers where you should see the details of the configuration you just deployed.
Note:
There are also options to publish an MSP offering as a service via the Azure Marketplace and Cloud Partner Portal enabling customers to purchase and onboard the resources via the Azure portal rather than having to deploy an ARM template as described above. This process requires the MSP to publish several additional details about their service. For details regarding this process please see this documentation - https://docs.microsoft.com/en-us/azure/lighthouse/how-to/publish-managed-services-offers
Managing Tenants
Once the customer tenant has deployed the Lighthouse configuration the managing tenant can also validate the deployment by navigating to the Service Provider Portal and opening the Customers tab. Here you should see a list of customer tenants who have successfully deployed your Lighthouse configuration.
To view customer resources within the managing tenant’s Azure Portal open the portal and select the Directory + subscription filter at the top of the page, here you should see the customer tenant directories and subscriptions on-boarded for you to select:
Once selected the customer tenants Workspaces will appear in your Azure Sentinel workspaces list alongside your own workspaces.
Currently most features within Azure Sentinel are directly tied to a single workspace, however it is possible to query multiple tenant’s workspaces with one unified query in order to investigate and hunt for threats that might be impacting several tenants at once. To do this you can use the union operator to merge a table from one workspace with another. For example, if you wanted to see a list of all security alerts from the last week from two workspaces you would use the following query:
union SecurityAlert, workspace('<Second Workspace Name>').SecurityAlert
| where TimeGenerated > ago(7d)
This can also be extended to any number of workspaces simply by adding more workspaces to the union query:
union SecurityAlert, workspace('<Second Workspace Name>').SecurityAlert, workspace(‘<Third Workspace Name>’).SecurityAlert
| where TimeGenerated > ago(7d)
The result set will appear as a single table, but you can use the TenantId field to identity which customer each item comes from.
Tracking an attack across multiple customer tenants
Exposed management endpoints on the internet are a regular attack target. Often attackers will scan the internet for exposed endpoints and then attempt to login using common credentials in the hopes of gaining access to at least some hosts. As a multi-customer monitoring team, it is common to see such attacks impacting several tenants simultaneously as commodity attackers indiscriminately attack any exposed interface they can find.
In this example we start with an alert in one of our customer’s workspaces for an attempted brute force attempt:
Upon inspecting the logs associated with this alert we can see all the attempts are coming from the same IP address:
To quickly assess if there is an impact from this activity we want to see if that IP address has successfully logged into any hosts in the environment. However, as we suspect this attack might be wider than just one of our customers, we can also simultaneously query our other workspaces for the same IP address.
union Syslog, workspace('<Customer2 Workspace Name>').Syslog
| where TimeGenerated > ago(7d)
| where ProcessName == "sshd"
| extend LogonIP = extract("([0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3})", 1, SyslogMessage)
| where SyslogMessage contains 'Accepted'
| where LogonIP == "174.116.122.126"
| extend Customer = iif(TenantId == "<Customer2 Tenant ID>", "Customer2", "Customer1")
| project TimeGenerated, Customer, Computer, LogonIP, SyslogMessage
The results of this query shows us that whilst there was no impact for the customer where we saw the Brute Force alert there were 2 successful logons for that IP address in another customer environment, highlighting these as events to investigate further.
Summary
A key principle to effective and scalable security operations is streamlining the security analysts’ job so that they can focus on threat detection and response. Azure Lighthouse’s integration with Azure Sentinel simplifies management of workspaces from multiple Azure tenants, whether they be external customer tenants or other tenants used internally within an organization, so that analysts can easily and effectively monitor multiple environments at once. In addition, the union operator within KQL allows analysts to query multiple environments at once, and track threats across them without having to repeat analysis.
If you want to know more about using Azure Sentinel in a multi-tenant or Managed Service Provider environment
Special thanks must also go to