Azure Sentinel News
  • Home
    • Home – Layout 1
    • Home – Layout 2
    • Home – Layout 3
  • Security and Compliance
  • SOC
  • Threat Intelligence
  • Security Ochestration & Automated Response
  • SOAR
  • Security Operations
  • Artificial Intelligence
No Result
View All Result
  • Home
    • Home – Layout 1
    • Home – Layout 2
    • Home – Layout 3
  • Security and Compliance
  • SOC
  • Threat Intelligence
  • Security Ochestration & Automated Response
  • SOAR
  • Security Operations
  • Artificial Intelligence
No Result
View All Result
Azure Sentinel News
No Result
View All Result
Home KQL

Protecting MSSP’s Intellectual Property in Azure Sentinel

Azure Sentinel News Editor by Azure Sentinel News Editor
December 1, 2020
in KQL
0
With new release, CrowdStrike targets Google Cloud, Azure and container adopters
2.9kViews
386 Shares Share on Facebook Share on Twitter

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:

pic1.png

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.

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 how to modify 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

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

Reference:https://techcommunity.microsoft.com/t5/azure-sentinel/protecting-mssp-s-intellectual-property-in-azure-sentinel/ba-p/1420941

Azure Sentinel News Editor

Azure Sentinel News Editor

Related Posts

What’s new: Microsoft Teams connector in Public Preview
KQL

New Azure Sentinel Learning Modules Released

February 1, 2021
What’s new: Microsoft Teams connector in Public Preview
KQL

How to Connect the New Intune Devices Log Azure Sentinel

January 26, 2021
What’s new: Microsoft Teams connector in Public Preview
KQL

How to Create a Backup Notification in the Event an Unauthorized User Accesses Azure Sentinel

January 11, 2021
Next Post
Vectra AI and Microsoft partner on security integration

Making your Azure Sentinel Workbooks multi-tenant (or multi-workspace)

CRITICALSTART Adds Support for Microsoft Azure Sentinel to MDR Services

Integrating open source threat feeds with MISP and Sentinel

Microsoft is quietly becoming a cybersecurity powerhouse

Using Azure Playbooks to import text-based threat indicators to Azure Sentinel

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Follow Us

  • 21.8M Fans
  • 81 Followers

Recommended

Emotet Attacks Microsoft, Taking Down Whole Network By Overheating The Computers

Emotet Attacks Microsoft, Taking Down Whole Network By Overheating The Computers

3 months ago
odix joins MISA program and integrates its FileWall with Microsoft Azure Sentinel

Upstream Security Joins the Microsoft Intelligent Security Association to Defend Against Automotive Cybersecurity Threats

3 months ago
Microsoft suspends 18 Azure accounts tied to China-based hackers

Building the Azure Sentinel Toolbox: MyEventLog

2 months ago
Why Insight Chose Microsoft Azure Sentinel as Core SIEM Over Splunk

Why Insight Chose Microsoft Azure Sentinel as Core SIEM Over Splunk

4 months ago

Instagram

    Please install/update and activate JNews Instagram plugin.

Categories

  • AI & ML
  • Artificial Intelligence
  • Incident Response
  • IR
  • KQL
  • Security and Compliance
  • Security Ochestration & Automated Response
  • Security Operations
  • SIEM
  • SOAR
  • SOC
  • Threat Intelligence
  • Uncategorized

Topics

anomaly automation Azure Azure DevOps Azure Security Center Azure Sentinel Azure Sentinel API Azure Sentinel Connector BlueVoyant Call cybersecurity Detection file GitHub Hunting Huntingy IAC incident response Incident Triage infrastructure as code Investigation jupyter LAQueryLogs MDR Microsoft microsoft 365 mssp Multitenancy Notebooks Pester Playbooks PowerShell python Records Security Sentinel Sharing SIEM signin Supply Chain teams Threat hunting Watchlists Workbooks XDR
No Result
View All Result

Highlights

New Items of Note on the Azure Sentinel GitHub Repo

Tuning the MCAS Analytics Rule for Azure Sentinel: System Alerts and Feature Deprecation

New Search Capability for Azure Sentinel Incidents

Follow-up: Microsoft Tech Talks Practical Sentinel : A Day in the Life of a Sentinel Analyst

Changes in How Running Hunting Queries Works in Azure Sentinel

Azure Sentinel can now Analyze All Available Azure Active Directory Log Files

Trending

What’s new: Microsoft Teams connector in Public Preview
IR

How to Generate Azure Sentinel Incidents for Testing

by Azure Sentinel News Editor
February 26, 2021
0

Do you want to generate an Incident in Azure Sentinel for testing/demoing? Here’s a couple easy ways...

What’s new: Microsoft Teams connector in Public Preview

Azure Sentinel Notebooks Loses It’s Preview Tag

February 25, 2021
Microsoft’s newest sustainable datacenter region coming to Arizona in 2021

The Holy Grail of Azure Sentinel Data Connections: The Azure Service Diagnostic Setting

February 22, 2021
Microsoft’s newest sustainable datacenter region coming to Arizona in 2021

New Items of Note on the Azure Sentinel GitHub Repo

February 18, 2021
Microsoft’s newest sustainable datacenter region coming to Arizona in 2021

Tuning the MCAS Analytics Rule for Azure Sentinel: System Alerts and Feature Deprecation

February 17, 2021

We bring you the best, latest and perfect Azure Sentinel News, Magazine, Personal Blogs, etc. Visit our landing page to see all features & demos.
LEARN MORE »

Recent News

  • How to Generate Azure Sentinel Incidents for Testing February 26, 2021
  • Azure Sentinel Notebooks Loses It’s Preview Tag February 25, 2021
  • The Holy Grail of Azure Sentinel Data Connections: The Azure Service Diagnostic Setting February 22, 2021

Categories

  • AI & ML
  • Artificial Intelligence
  • Incident Response
  • IR
  • KQL
  • Security and Compliance
  • Security Ochestration & Automated Response
  • Security Operations
  • SIEM
  • SOAR
  • SOC
  • Threat Intelligence
  • Uncategorized

[mc4wp_form]

Copyright © 2020 - Azure Sentinel News

No Result
View All Result
  • Home
  • Security and Compliance
  • SOC
  • Threat Intelligence
  • Security Ochestration & Automated Response
  • SOAR
  • Security Operations
  • Artificial Intelligence

Copyright © 2020 Azure Sentinel News