Protecting MSSP’s Intellectual Property in Azure Sentinel

Published May 27 2020 08:47 AM 10.4K 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 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? 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 Azure Sentinel environment. Please leave a comment below if you have any questions!



Senior Member

@Javier Soriano 
thank you for this well described blog post and it gave us some usefull insights and these 2 specific models. An additional question I have is related to our specific organisation. Within our company we have specialized managed detect & respond services, however we are not a CSP as we don't offer specific technologies, it is more a service. Within this perspective we typicalle have to work via the customer and their CSP to get the necessary access. Do you know any approach that would be in line of our setup se were the CSP typically delivers the technology and we as a security company deliver our expertise in security monitoring and incident response ? Normally we use external guest accounts and RBAC to achieve this but maybe you have a better view or idea ? 


Again thanks for you insights really appreciated ! 


Hi @Jeroen Vandeleur , in your case the best approach is to use Azure Lighthouse. You could for example publish a managed services offer in the Azure Marketplace that would grant you delegated access to the customer's Sentinel environment with whatever roles you need to perform your functions. External guest accounts (B2B) work fine, but Lighthouse has several benefits compared to B2B. First, Lighthouse provides you with cross-tenant visibility without switching context, so you can for example build cross-tenant dashboards or use the multi-workspace incident view. Lighthouse also allows you to do management as scale, for example, you could build a PS script that updates all your customers in parallel. Take a look at this other post for more details on this.


Hope this helps!

Senior Member

Dear @Javier Soriano , 


Thank you for the quick reply, I agree that B2B accounts are not the way to go for this. We will take a look at the lighthouse option, I thought this was primarily developed for a CSP. However, from our perspective Lighthouse would be the ideal solution to get the required roles & responsibilities for our MDR service. So if we can connect our customer tenants towards our lighthouse service it would be the ideal solution! 


Thank you ! 


Best Regards, 


Jeroen Vandeleur 


Yes, Lighthouse is the way to go as it works the same across any licensing model.

Occasional Contributor

Thanks for the great info; sharing with my Linkedin Network

New Contributor

@Javier Soriano, Thanks for the info... Can you please elaborate on your statement "If you have developed a workbook that you don’t want your customer to copy, you should store it in your tenant"


As an MSSP, we have the multiple workbooks in our tenant, I want customers to use these workbook from their sentinel workspace and also they should be prevented from copying the code (our Intellectual Property).


Thanks for your comment @KrishhnaM . 


The idea is that you build/deploy your workbook in your tenant (MSSP) and query customer workspaces from there. It is true that if you want the customer to see it, you have no easy option as of today. Even if you use reverse Lighthouse granting only Reader role, the customer would still be able to see the queries underneath. We hope to have a solution for this soon.


I will update the article to reflect this case.

New Contributor

Yes @Javier Soriano , even with reverse concept (customer with reader role) the workbook code is visible and also that the customer is able to edit the workbook!!!


Thanks for your reply, kindly let us know once the solution is available to secure analytical rule and workbook.


Hi @Javier Soriano,


With CSP (indirect reseller) and Azure lighthouse we have built sentinel workspace at he customer estate on our CSP subscription.  Inspite of Delegate Admin Access it is interesting to see that we are not allowed to enable the connectors in sentinel (for example: Microsoft Defender ATP).


Is it a must only thier Global admin or Security Admin can enable the connector to collect logs or is there any other best practice ?   


How will their global admin see this CSP subscription if they are not added under AdminAgents within out partner portal ? 


Looking for advice on this.





Hi @PrashTechTalk , yes, Global Admin/Security Admin permissions is a requirement for some connectors, and there's no workaround for that.


In CSP, you might have Delegated Admin Privileges over the customer tenant and be able to perform this. Whether or not you have this permission depends on how you onboarded that customer into your CSP.


Makes sense?


@Javier Soriano 


Thanks for your response. Here is my experience with a recent on-boarding for one of the CSP workspace.

It was interesting to see that for an indirect reseller owned subscription inspite of having DAP and the user is part of AOBO group we couldn't enable Sentinel Connector (example: Microsoft Defender ATP) for the workspace in the customer tenant though the subscription is owned by us as a CSP (indirect seller) with owner access at the subscription level.  The expectation at sentinel workspace is that user must have Global or Security Admin privilege at the workspace tenant to enable connectors like defender or office.  To assign Global Admin or Security Admin at the customer at the workspace tenant  the user needs to be local to their tenant which mean either we end up creating an additional user at client tenant to assign Global or Security Admin privilege or grant access to their tenant global admin user so that they activate required connectors. 


I do not see DAP fully serve the required ownership for a CSP user who is a indirect seller. 


My question how do I achieve taking complete ownership including activation of required sentinel connectors without having a local user at customer tenant? 





Hi @PrashTechTalk , as far as I know, you don't need to be in the customer tenant to be global or security admin. You can be a B2B guest user and still have the global or security admin role. Did you try this?


@Javier Soriano - Sorry i meant a local user can be be either B2B guest or user at the customer tenant. But one has to have a user at the customer tenant to connect on-boarding logs into sentinel inspite of Azure lighthouse + CSP which i see it as a downside as it again increases the dependency.


I remember those good to old days without CSP and Lighthouse where MSSP's used to have users in customer tenant to manage their security. But With Lighthouse I see no changes other than centralized model of managing multiple customers.  With CSP relation granting DAP I was expecting AOBO users having ability to do perform all actions not depending on having a local or B2B user in customer tenant. I think microsoft has opportunity for enhancement of capabilities for users under AOBO off-course with security in mind. 


Thanks it was a good discussion.

Senior Member

@Javier Soriano Great articles, and we are now follow the ideas here to build our MSSP service with lighthouse. We setup the schedule queries in our own MSSP tenant, but, we now tackled with the analystic rules of Microsoft Security incident creation analytics rules or Fusion that could not edit the query or select the workspace of our customers even connected with light house. Apprecited if you have any ideas on this issue. Thanks.


Hi @ivaryung , why would you want to create the Microsoft Security Incident of Fusion analytics rules in your MSSP tenant? 



Senior Member

@Javier Soriano, Thank you for the information. It has helped immensely.


I have a couple of questions if you don't mind.


  1. For scheduled Analytic Rules created in the customer tenant via Wortell's PowerShell scripts and a corresponding JSON file, is there any way to attach a playbook that was created in the MSSP tenant and not in the customer tenant? When trying to do so, I get a warning stating: "WARNING: Unable to find LogicApp XYZ under Subscription Id: xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx". After the rules are created, I can manually assign a Playbook created in the MSSP tenant to an Analytic rule that was created in the customer tenant, but not via the PowerShell script.
  2. As for the Analytic Rules themselves, If we want to store all Analytic Rules in our MSSP tenant, you mentioned using the following format in the query.
    | where EventID == ‘4625’​
    Would you recommend we duplicate this query replacing the customer workspace for each client, or creating one rule and adding all our client's workspace name to each rule using the union operator?

For example, If we have set up 100 rules in the MSSP tenant for a single client, and we onboard 5 other clients to Azure Lighthouse, we would end up with 600 rules in our tenant with the only difference being the workspace name in the queries.


The other option would be to set up those 100 rules, but using the union operator to add the other 5 clients workspaces to the existing rules. Every new client that we onboard, we would just append the workspace name to the table we are referencing. For example: 

"union SigninLogs, workspace('ClientWorkspace1').SigninLogs,workspace('ClientWorkspace2').SigninLogs"

I appreciate your help on this!

Senior Member

Hi @Javier Soriano, For centralized the monitoring purpose, we would like to create some workbooks for our 7x24 center to triage and investigate the alerts/incidents from all our customer's tenant. It would be nice if we built all the analytic rules in MSSP tenant as your mentioned, while all the alerts/incidents generated among MSSP tenant. However, some of our customer has other MS security products, like ATP, MCAS, AADIP that generated security alerts. We are not able to turn on Microsoft Security incident creation analytics rules in MSSP side, because it only could grab the security alerts on MSSP tenant, not our customer's tenant. But turn on the rules on Customer's tenant is not our wish because our team need to login every customer's sentinel for investigation. Hope there is any solutions/alernatives to "escalate" the security alerts from customer tenant to MSSP for central monitoring and reporting. Thanks.


HI @GeorgeAbouSamra 


For 1), I don't think that is possible with AzSentinel. Tagging @Pouyan Khabazi to take it as feedback


For 2) please read the following article about cross-workspace analytics rules: . If the rule that you're defining doesn't contain intellectual property, our recommendation is to create the rule in the customer tenant. If you do need to protect your IP, then use each rule for a single customer, because it may be difficult to tell which customer was the alert triggered on and it will complicate investigation.


It is true that you will end up with a high number of rules, but with good naming convention and proper configuration management via infrastructure as code, this should not be a problem. Further more, you can define in the MSSP tenant a workspace for each target customer to streamline management.





HI @ivaryung , why do you want to create all the rules in the MSSP tenant? Please take a look at this article to see our recommendations around cross-workspace analytics rules: 


You should use our cross-workspace incident view to monitor multiple customers.

Senior Member

@Javier Soriano- Thank you for the clarification and guidance.

Senior Member

hi @Javier Soriano and @GeorgeAbouSamra thanks for the feedback! The described configuration is indeed not supported in the current version. I am working on a fix for the described feature request, will be released in the next version. Here you can follow the status: Add support for Playbook attachment from MSSP tenant · Issue #138 · wortell/AZSentinel (

Senior Member

@Pouyan Khabazi - That's great news. Thank you!

Frequent Visitor

@Javier Soriano I hope this finds you safe and well, I've been consuming a lot of your info for an Sentinel MSSP its been very helpful.


Currently our created custom scheduled Alert rules and Playbooks sit in the lighthouse delegated Log Analytics works space and we are looking to bring them inside our own tenancy as described in this article.


It is not clear to me yet what actually triggers Sentinel ingestion cost, I have an Azure case open but no answer yet, however I believe Sentinel ingestion is triggered by Alert rules.


Currently our customers pay for the Sentinel cost. 


Question: If we bring in the Alert rule to our own LAW and use the 


does the cost stay with the customer?


Thanks for all your support.  


Hi @qsecurity , yes, the cost for the customer would be the same, because the tables where Sentinel alerts and incidents are free of charge. If you create the analytic rule in your tenant, the alert and incident will be in your tables, but with no impact to costs.



Version history
Last update:
‎Dec 28 2020 11:27 PM
Updated by: