Sentinel POC – Architecture and Recommendations for MSSPs – Part 1

TL;DR – Common topics that come up when partners, specifically MSSPs, are testing Microsoft Sentinel features to evaluate its SIEM and SOAR capabilities. Part 1

If you are the first in line to take advantage of the recently announced service Security Copilot, the best step you can take now is ensure you are using Defender and Sentinel. Part of my job is helping partners that offer managed security services and are evaluating migration from legacy SIEM solutions to Sentinel. Based on my experience, I’ve put together this guide to hopefully answer many of the questions I receive from partners as they work on Sentinel POCs.

This post is a part of series that covers various topics from the very basics, to ensure partners that may be familiar with other SIEMs, but that are not yet familiar with Azure can get all the information they need to be successful.

• Part 1 – MSSP Architecture Goal, Tenants and Subscriptions required for the POC, Required Permissions, and Azure Lighthouse. (this post)
• Part 2 – B2B or GDAP, CSPs, Where is the data?, Migrations, Which connectors?
• Part 3 – Agents and Forwarders, Sample Data, Storage Options, Repositories, Workspace Manager, Cross-workspace, and Other Resources.

If the Contoso Hotels demo instance is not sufficient to evaluate specific Sentinel features, such as testing MSSP type configurations, then partners will need to build their own environments. The following sections will go over the options available, as well as recommendations on how to go about building these environments.

MSSP Architecture Goal

The diagram below shows an overview of the typical architecture an MSSP partner should build to evaluate Sentinel’s capabilities. At the core of Sentinel is a Log Analytics Workspace (LAW), where Sentinel is configured. Both Sentinel and the LAW are resources that exist within a resource group, which exists within a subscription. MSSPs will also need to deploy those resources within a subscription, which is associated with the MSSP tenant, to have access to MSSP customers’ resources using Azure Lighthouse.

Tenants and Subscriptions for the Sentinel POC in the context of an MSSP

Tenants – Partners will need a tenant that will work as the MSSP tenant and at least one tenant that will work as the customer’s tenant. Microsoft Sentinel and its associated Log Analytics Workspaces are subscription resources. However, all subscriptions must be associated with a tenant. So, that’s where it all starts.

Subscriptions – Partners will need a subscription within the MSSP tenant and at least one subscription within each of the customer tenants. A subscription is needed because the Log Analytics Workspace (LAW) where the data is ingested and Sentinel, which is a service deployed on a LAW, are both resources that exist within a subscription.

Considerations:

• Which tenant will be the MSSP tenant? Partners performing a POC can choose to use their corporate tenant as their MSSP tenant. However, the ultimate goal should be to isolate the MSSP tenant, using the multiple identities model described on my previous post, MSSPs and Identity. If the requirement is to follow the same procedures that will be expected to be followed during go-live, then create a new tenant. If the requirement is just to test Sentinel’s features for a period of time, then partners can just use the single identity model, i.e., the corporate tenant.
• Are there any options or credits to cover the costs of tenants/subscriptions? – Partners cannot use the CDX environments by themselves because those environments do not include a subscription and they have restrictions that prevent anyone from adding payment instruments, which is required to create a new subscription. However, partners can attach a Visual Studio subscription to one of those tenants. The Visual Studio subscription is offered as part of the Developer Program. This same program offers a Microsoft 365 developer sandbox, which can be the MSSP tenant as well. Therefore, partners can combine that Visual Studio subscription with the Microsoft 365 developer sandbox, and that will result in a tenant and a subscription with the costs covered by the developer program. This is very useful because partners will get an E5 license with that tenant, which means they will be able to test scenarios using some of the Defender 365 Security services.
• Free Trial – As noted in the pricing guide, New workspaces can ingest up to 10GB/day of log data for the first 31-days at no cost. Both Log Analytics data ingestion and Microsoft Sentinel charges are waived during the 31-day trial period. This free trial is subject to a 20 workspace limit per Azure tenant.
• Which region? – This may not be as important for a POC, but if the partner is trying to follow the same procedures that will be expected during go-live, then this information will be useful. There are various elements to consider when evaluating the region where the Log Analytics Workspace will be created, such as egress costs, feature availability, compliance requirements, etc. There is a decision tree available in the documentation that can guide partners when making these decisions.
• An Isolated subscription – Microsoft recommends the Sentinel workspace be placed on a separate subscription or even better, a separate management group, to be able to isolate permissions of the security data and prevent permissions being inherited. More on permissions below.

Required Permissions

As I shared in a previous blog post, MSSPs and Identity: Q&A, Azure permissions can be at tenant level, i.e., Azure AD roles, or they can be at subscription/resource/management group level, i.e., Azure RBAC roles. The diagram below references the two types of permissions.

As resources that exist within a subscription, both Sentinel and Log Analytics Workspaces require Azure RBAC roles. To be able to create the Log Analytics Workspace, or any other resource within a subscription, users will need at least contributor role within that subscription, as referenced in the documentation. Additionally, some users will need to have the owner permission, so they can delegate the required access over the workspace to other users.  As I mentioned above, permissions can be inherited, so any users assigned permissions at management group level may inherit those permissions at subscription, resource group, and resource level.

Once the Log Analytics Workspace is created, as noted in the documentation, users will need the contributor role within the subscription to enable Sentinel. Once Sentinel is onboarded, partners need to assign permissions within Sentinel to their SOC teams, so they can manage Sentinel workspaces.  The permissions are shown below and also covered in detail in the documentation.

Azure Lighthouse

Partners can use Azure Lighthouse to configure delegated access at subscription or resource group level, so they can access their customers’ Sentinel workspaces. On one of my previous posts, I discussed in detail how to delegate access using Azure Lighthouse for a Sentinel POC. Furthermore, I go into detail about a more advanced scenario where partners can create a configuration that allows them to assign access to managed identities in the customer tenant. This will be required for partners that need to create playbooks (Azure Logic Apps) on the customer’s subscription, which may require them to assign permissions to the identities associated with those playbooks.

Partners can use the template option I describe in my blog post for a POC. However, they should plan to publish an Azure Lighthouse marketplace offer for their go-live, so their customers can easily delegate access to them using the public offer. For that reason, I recommend that prior to go-live partners create a private offer in the marketplace, which can be available only to specific tenants for initial testing purposes. Going through the process is highly recommended because it gets partners familiar with the process of publishing the offer.

The same process I described in this section can be used by partners to request delegation of access to manage any other security services that exist at subscription level. For example, Defender for Cloud (MDC) and its various Defender plans, including Defender for Servers, Defender for Containers, Defender for Storage, etc., as well as Defender for IoT. The only difference is the role required to manage those, i.e., Security Admin and/or Security Reader.

In Part 2 of this series of posts, I cover the following topics: B2B or GDAP, CSPs, Where is the data?, Migrations, Which connectors?