Protecting MSSP’s Intellectual Property in Microsoft Sentinel
Published May 27 2020 08:47 AM 15.7K Views

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 Microsoft 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? Two scenarios depend 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 who 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 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 see log data for the resources they can access (e.g., logs from a VM). If the workbook's KQL query is trying to get data from a resource the customer doesn't have access to, the query will not work. You can find more detailed 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 Admin Agents group users 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 using Lighthouse) might come from a different tenant than those used as the partner’s CSP tenant.


If your customer needs to access the whole subscription, 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 located in the customer tenant. RBAC permissions are inherited, so if a customer has owner permissions at the subscription level, 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: specify what workspace the query is executed against. For that, you can use the workspace statement like this:






| 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 is to create one analytics rule per customer and detection (see image below). You can even append the customer's name 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 huge 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.



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 modifying 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.



We have two scenarios regarding protecting your playbooks depending on where the analytics rules have been created: in the customer tenant or 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 a playbook hosted in your own tenant. In this case, the playbook will get the alert/incident (and any other info related to customer info) data from the customer workspace.   



In Summary

This post explains the different options that an MSSP has to protect its intellectual property in an Microsoft Sentinel environment. Please leave a comment below if you have any questions!



Version history
Last update:
‎Nov 02 2021 06:53 AM
Updated by: