Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Protecting MSSP’s Intellectual Property in Microsoft Sentinel
Published May 27 2020 08:47 AM 15.1K Views
Microsoft

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:

 

pic1.png

 

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:

 

 

 

 

 

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

 

Picture5.png

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 modifying your workbooks to make them multi-tenant.

 

pic3.png

 

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

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.

pic4.png

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

pic5.png

 

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!

 

 

42 Comments
Copper Contributor

@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 ! 

Microsoft

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!

Copper Contributor

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 

Microsoft

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

Iron Contributor

Thanks for the great info; sharing with my Linkedin Network

Copper 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).

Microsoft

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.

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

Brass Contributor

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.

 

Thanks. 

 

Microsoft

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?

Brass Contributor

@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? 

 

Thanks

 

Microsoft

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?

Brass Contributor

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

Copper Contributor

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

Microsoft

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

 

Regards

Copper Contributor

@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.
    workspace('<customer-workspace>').SecurityEvent
    | 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!

Copper Contributor

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.

Microsoft

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: https://techcommunity.microsoft.com/t5/azure-sentinel/what-s-new-cross-workspace-analytics-rules/ba-... . 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.

 

Regards

 

Microsoft

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: https://techcommunity.microsoft.com/t5/azure-sentinel/what-s-new-cross-workspace-analytics-rules/ba-... 

 

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

Copper Contributor

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

Brass Contributor

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 (github.com)

Copper Contributor

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

Copper Contributor

@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 

('<customer-workspace>').SecurityEvent

does the cost stay with the customer?

 

Thanks for all your support.  

Microsoft

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.

 

Regards

Copper Contributor

Hi @Javier Soriano 

 

Thaks for great writeup.

 

We are building a new MSSP solution.

Here we don't want to feed TI to all customers LA's as it cost to them, instead of that we are thinking to feed to MSSP tenant LA and creating a cross analytical rule which verify customer security logs based on MSSP tenant TI feed. Is it possible?

 

If yes, how the costing works as we are utilizing customer LA logs and MSSP LA logs? 

 

And in general, who will be charged for cross tenant analytical rules?

 

Thanks in advance.

Microsoft

@Ram71310  you’re not charged for cross-workspace (or cross-tenant) analytics rules, you’re only charged in the workspace where data is ingested. The only requirement for cross-workspace analytic rules is that both source and target workspaces have Sentinel enabled. Yes, the scenario you describe for TI is feasible.

Copper Contributor

Hi #microsoft #sentinel #community
I am acting as a bridge between two companies. I have been able to setup #Azure #lighthouse to delegate Sentinel management.

But I have an issue currently:

I have set up the delegation with Sentinel Responder, Playbook Operator and Logic App operator role. The service provider is able to modify/assign/update incidents but unable to run the playbooks from under the incidents with the error:
Caller is missing required playbook triggering permissions on playbook resource < playbook-name-here >, or Microsoft Sentinel is missing required permissions to verify the caller has permissions

Can someone tell me how to solve this?

++ some additional info:

I have seen the documentation about Lighthouse permissions on https://lnkd.in/dbegk7cA. but
1. None of the resources are deployed in the service provider's tenant. Infact my tenant doesn't even have a sentinel deployed. Do I still need to assign Azure Security Insights the Automation Contributor permission?
2. If yes, I do not see Azure Security Insights in my Enterprise Applications dashboard.(Do i need to install something extra for this?)

Microsoft

@AliAhmedDar Yes, Sentinel's application needs the proper permissions. Please see details here: Automate threat response with playbooks in Microsoft Sentinel | Microsoft Learn

 

and also step #5 here:  Tutorial - Automate threat response in Microsoft Sentinel | Microsoft Learn

Copper Contributor

Hey @Javier Soriano sorry i did not mentioned earlier

Am important thing to note here is that I don't have any resources (such as Sentinel and resource group) deployed in the Service Provider tenant and neither do we plan to do so. The service provider tenant is just to be used to access the customer's Sentinel and investigate alerts and run play books from the incidents tab. So in this case, I don't have the Azure Security Insights application in that Azure tenant. Then how am I supposed to execute the playbook in the customer's tenant even manually?

Please suggest a solution considering this scenario, thanks 

Microsoft

@AliAhmedDar in that case, you just access the customer workspace via Lighthouse and execute the Playbooks from there. Permissions of the local Azure Security Insights application in the customer tenant are still needed, and this can be granted through the instructions mentioned above. 

Copper Contributor

Well @Javier Soriano the customer tenant's Sentinel has playbook permissions already assigned as mentioned. And i am accessing the customer's Sentinel through lighthouse delegation. Everything else seems to be working fine except the execution of playbooks.

Error is: 

Caller is missing required playbook triggering permissions on playbook resource < playbook-name-here >, or Microsoft Sentinel is missing required permissions to verify the caller has permissions

 

Do I need to configure Security Insights in the customer tenant as well ? 

Copper Contributor

The documentation links only contain guide for scenarios where automation rules are present in MSSP tenant, while that's not my case. Everything is in the customer's tenant

Microsoft

@AliAhmedDar did you follow step #5 instructions from my link above? Tutorial - Automate threat response in Microsoft Sentinel | Microsoft Learn

 

JavierSoriano_0-1698093507253.png

 

Copper Contributor

The first thing, Playbook Permissions in Sentinel settings in customer tenant is done. 

The second thing, assigning permissions to Azure Security Insights, it's not possible because I don't have a Sentinel or any other deployment in the Service Provider tenant. 

Microsoft

@AliAhmedDar you will need to create an empty sentinel workspace in order to create the Azure Security Insights app in the AAD tenant. Doesn't need to have any data, it's just to trigger the creation of the app. I haven't tested but you might even be able to create the workspace, grant the permissions as explains and then delete the workspace.

Copper Contributor

1. Are we sure that Security Insights application is the reason if this issue ? 

2. Is setting up Sentinel and assigning permissions to Security Insights going to solve this issue?

3. Are there any extra costs involved or any license required for setting up Sentinel workspace or Security Insights application?

4. Does the Security Insights application keep working even after deleting Sentinel workspace? 

 

Microsoft

@AliAhmedDar 

 

1. I'm pretty sure that's the issue. It's documented like this as you can see.

2. Same as above.

3. No, no costs involved as you don't need to ingest any data

4. I haven't tested this, but it's worth a try.

 

If you continue having issues after following the documented steps, I'd recommend opening a support ticket.

 

Regards

Copper Contributor

I'll test it out 

Copper Contributor

Okay I was able to execute the playbooks, thanks a lot to you @Javier Soriano 

Another thing that I want to ask is that the customer wants to have an insight into the auth logs of the group that is able to access their resources. For example, the customer wants to know which member of the group logged in to the Service Provider's Azure. And the customer wants to set up a detection to get an alert when there is a brute force attempt or any other incident against any other user in the SP's group.

Microsoft

@AliAhmedDar you can easily modify one of our brute force rules to just target a particular group. Regarding audit for lighthouse, see this: Monitor service provider activity - Azure Lighthouse | Microsoft Learn

Copper Contributor

Are the SP's tenant's Signinlogs captured in the Customer's tenant as well ?

Copper Contributor

@Javier Soriano how can a customer make sure or enforce that the certain group that will access the delegated resources should have MFA enabled ?

I know there is eligibleAuthorizations option available but that is only for JustInTime access roles, I want it generic for all roles, how can i modify the template to acheive this?

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