Protecting MSSP intellectual property in Azure Sentinel
This article describes the methods that managed security service providers (MSSPs) can use to protect intellectual property they've developed in Azure Sentinel, such as Azure Sentinel analytics rules, hunting queries, playbooks, and workbooks.
The method you choose will depend on how each of your customers buy Azure; whether you act as a Cloud Solutions Provider (CSP), or the customer has an Enterprise Agreement (EA)/Pay-as-you-go (PAYG) account. The sections below describe each of these methods separately.
Cloud Solutions Providers (CSP)
If you're reselling Azure as a Cloud Solutions Provider (CSP), you're managing the customer's Azure subscription. Thanks to Admin-On-Behalf-Of (AOBO), users in the Admin Agents group from your MSSP tenant are granted with Owner access to the customer's Azure subscription, and the customer has no access by default.
If other users from the MSSP tenant, outside of the Admin Agents group, need to access the customer environment, we recommend that you use Azure Lighthouse. Azure Lighthouse enables you to grant users or groups with access to a specific scope, such as a resource group or subscription, using one of the built-in roles.
If you need to provide customer users with access to the Azure environment, we recommend that you grant them access at resource group level, rather than the entire subscription, so that you can show / hide parts of the environment as needed.
You might grant the customer with access to several resource groups where their applications are located, but still keep the Azure Sentinel workspace in a separate resource group, where the customer has no access.
Use this method to enable customers to view selected workbooks and playbooks, which are separate resources that can reside in their own resource group.
Even with granting access at the resource group level, customers will still have access to log data for the resources they can access, such as logs from a VM, even without access to Azure Sentinel. For more information, see Manage access to Azure Sentinel data by resource.
If you need to provide your customers with access to the entire subscription, you may want to see the guidance in Enterprise Agreements (EA) / Pay-as-you-go (PAYG).
Sample Azure Sentinel CSP architecture
The following image describes how the permissions described in the previous section might work when providing access to CSP customers:
In this image:
The users granted with Owner access to the CSP subscription are the users in the Admin Agents group, in the MSSP Azure AD tenant.
Other groups from the MSSP get access to the customer environment via Azure Lighthouse.
Customer access to Azure resources is managed by Azure RBAC at the resource group level.
This allows MSSPs to hide Azure Sentinel components as needed, like Analytics Rules and Hunting Queries.
For more information, also see the Azure Lighthouse documentation.
Enterprise Agreements (EA) / Pay-as-you-go (PAYG)
If your customer is buying directly from Microsoft, the customer already has full access to the Azure environment, and you cannot hide anything that's in the customer's Azure subscription.
Instead, protect your intellectual property that you've developed in Azure Sentinel as follows, depending on the type of resource you need to protect:
Analytics rules and hunting queries
Analytics rules and hunting queries are both contained within Azure Sentinel, and therefore cannot be separated from the Azure Sentinel workspace.
Even if a user only has Azure Sentinel Reader permissions, they'll still be able to view the query. In this case, we recommend hosting your Analytics rules and hunting queries in your own MSSP tenant, instead of the customer tenant.
To do this, you'll need a workspace in your own tenant with Azure Sentinel enabled, and you'll also need to see the customer workspace via Azure Lighthouse.
To create an analytic rule or hunting query in the MSSP tenant that references data in the customer tenant, you must use the
workspace statement as follows:
workspace('<customer-workspace>').SecurityEvent | where EventID == ‘4625’
When adding a
workspace statement to your analytics rules, consider the following:
No alerts in the customer workspace. Rules created in this manner, won’t create alerts or incidents in the customer workspace. Both alerts and incidents will exist in your MSSP workspace only.
Create separate alerts for each customer. When you use this method, we also recommend that you use separate alert rules for each customer and detection, as the workspace statement will be different in each case.
You can add the customer name to the alert rule name to easily identify the customer where the alert is triggered. Separate alerts may result in a large number of rules, which you might want to manage using scripting, or Azure Sentinel as Code.
Create separate MSSP workspaces for each customer. Creating separate rules for each customer and detection may cause you to reach the maximum number of analytics rules for your workspace (512). If you have many customers and expect to reach this limit, you may want to create a separate MSSP workspace for each customer.
The key to using this method successfully is using automation to manage a large set of rules across your workspaces.
For more information, see Cross-workspace analytics rules
If you have developed an Azure Sentinel workbook that you don't want your customer to copy, host the workbook in your MSSP tenant. Make sure that you have access to your customer workspaces via Azure Lighthouse, and then make sure to modify the workbook to use those customer workspaces.
For more information, see Cross-workspace workbooks.
If you want the customer to be able to view the workbook visualizations, while still keeping the code secret, we recommend that you export the workbook to Power BI.
Exporting your workbook to Power BI:
- Makes the workbook visualizations easier to share. You can send the customer a link to the Power BI dashboard, where they can view the reported data, without requiring Azure access permissions.
- Enables scheduling. Configure Power BI to send emails periodically that contain a snapshot of the dashboard for that time.
For more information, see Import Azure Monitor log data into Power BI.
You can protect your playbooks as follows, depending on where the analytic rules that trigger the playbook have been created:
Analytics rules created in the MSSP workspace. Make sure to create your playbooks in the MSSP tenant, and that you get all incident and alert data from the MSSP workspace. You can attach the playbooks whenever you create a new rule in your workspace.
Analytics rules created in the customer workspace. Use Azure Lighthouse to attach analytics rules from the customer's workspace to a playbook hosted in your MSSP workspace. In this case, the playbook gets the alert and incident data, and any other customer information, from the customer workspace.
In both cases, if the playbook needs to access the customer’s Azure environment, use a user or service principal that has that access via Lighthouse.
However, if the playbook needs to access non-Azure resources in the customer’s tenant, such as Azure AD, Office 365, or Microsoft 365 Defender, you'll need to create a service principal with appropriate permissions in the customer tenant, and then add that identity in the playbook.
If you use automation rules together with your playbooks, you must set the automation rule permissions on the resource group where the playbooks live. For more information, see Permissions for automation rules to run playbooks.
For more information, see: