Special thank you to @Ofer_Shezaf and @Koby Koren for reviewing this article
In the last few months helping MSSPs adopt and build services around Azure Sentinel, one of the common concerns for them is protecting the Intellectual Property (IP) that they develop.
This IP can be in multiple forms, it might be a Workbook that provides additional features and visualizations, a new Analytics Rule that can detect a specific attack or a Playbook that extends Sentinel’s functionality.
But what happens if you deploy that IP into the customer’s Sentinel environment? Well, there are two scenarios depending on how your customer buys Azure: Cloud Solutions Provider (CSP) and Enterprise Agreement (EA). Let’s look at each of them separately.
CSP customers
If you are reselling Azure as a Cloud Solutions Provider (CSP), you are supposed to manage the Azure subscription(s) on behalf of the customer. There is a mechanism called Admin-On-Behalf-Of (AOBO) that automatically will provide some users from the partner organization Owner access to the customer subscription and the customer will have NO access by default. The users that get this access are the ones inside the Admin Agents group in the partner’s Azure AD tenant attached to the CSP contract (this tenant might differ from the partner’s main AAD tenant).
It is recommended to use Azure Lighthouse to provide additional users with access to the customer environment. This provides finer granularity as you can grant users or groups access to a specific scope (resource group or subscription) with one of the available built-in roles. See here for more details.
As explained above, in this model the customer has no access by default, and only if you grant them access explicitly, they will see the Azure environment. If the customer needs to access to the Azure environment, the recommendation is to grant them access at the resource group level. That way, you can show/hide parts of the environment. For example, you might grant access to the customer to several RGs where customer applications are located, but keep the Sentinel environment in a different RG where the customer has no access. With this model, you can still allow customers to see playbooks and workbooks, because these are separate resources and can reside in a separate RG. Also, keep in mind that the customer will only be able to see log data for the resources they have access to (eg. logs from a VM). If they KQL query in the workbook is trying to get data from a resource the customer doesn’t have access to, the query will not work. You can find more in detail information about data RBAC options in this article.
In the following picture you can see how this option would work from a permissions point of view:
In this picture, the users that are part of the Admin Agents group, come from the partner’s CSP tenant (the one associated with their CSP contract). Partner users and groups in the yellow and purple boxes above (the ones that are using Lighthouse), might come from a different tenant than the one used as the partner’s CSP tenant.
If your customer needs to access the whole subscription, then move to the next section (EA Customers).
EA customers
If your customer is buying directly from Microsoft, then the customer already has full access to the Azure environment so you won’t be able to hide things that are located in the customer tenant. This is because RBAC permissions are inherited, so if a customer has owner permissions at the subscription level, then they will have that same permission on anything inside it, even the Sentinel environment that you manage on their behalf. So, how can you protect the Intellectual Property that you develop on top of Sentinel?
Let’s look at this by type of resource that needs to be protected.
Analytics Rules
Analytics rules live within the Sentinel solution, so they cannot be separated from the Sentinel resource and workspace. Even if the customer user has only Sentinel Reader permissions, he/she will be able to see the query in your rule from the Analytics Rule blade within Sentinel. So how do we hide them?
The trick here is to host those Analytics Rules in your own MSSP tenant instead of the customer tenant. For that, you will need a workspace in your own tenant that has the Sentinel solution enabled and you would also need to see the customer workspace through Azure Lighthouse. But how do I make sure that the rule is executed in the customer workspace?
You need to use a little trick with KQL, which is specify what workspace is the query executed against. For that you can use the workspace statement like this:
workspace('<customer-workspace>').SecurityEvent
| where EventID == ‘4625’Take into account, that with this method, there will be no alerts in the customer workspace and therefore no incidents either. All those will reside in your Sentinel instance. Please visit this article for further details and best practices with these types of rules.
One additional consideration that comes with this approach is how you separate customers. The recommended approach as of now is to create one analytics rule per customer and detection (see image below). You can even append the name of the customer to the alert for easier identification when an alert is triggered. The main challenge with this option is that you might end up with a very large number of rules, but you can manage those efficiently using scripting or the Sentinel as Code approach.
Hunting Queries
Similar to the previous case, Hunting Queries live inside the Sentinel solution. If you need to hide a specific query from your customer, you could always store the query on your own tenant (MSSP) and run it against the customer workspace as shown in the previous section using the workspace statement.
Workbooks
If you have developed a workbook that you don’t want your customer to copy, you should store it in your tenant. The good news is that you can modify that workbook to use whatever customer workspaces you want as long as you have access to them via Lighthouse.
In this other blog post you have details on how to modify your workbooks to make them multi-tenant.
An additional use case with workbooks, is when a customer needs to see the workbook visualizations, but the MSSP wants to keep the workbook code secret. In that case, the recommended approach is to export the workbook to PowerBI as explained here.
Playbooks
Regarding protecting your playbooks, we have two scenarios depending on where the analytics rules have been created: in the customer tenant or in the MSSP tenant.
- Analytics Rules in the MSSP tenant. In this case, the customer workspace won’t have any information about the alerts and incidents, so your playbooks need to get all the information from your own workspace. There’s nothing special that you need to do in this case, just create your playbooks in the MSSP tenant as you would do in the customer tenant and make sure you get all the incident/alert data from your own MSSP workspace. You will be able to attach these playbooks when you create a new rule within your tenant.
- Analytics Rules in the customer tenant. Using Lighthouse, it is straight forward to create analytics rules in the customer’s Sentinel environment and attach to it a playbook hosted in your own tenant. The playbook in this case will get the alert/incident (and any other info related to customer info) data from the customer workspace.
