MSSPs and Identity

TL;DR – Identity configuration recommendations for MSSPs.

I’ve had this conversation with most of my partners at one point or another, which is probably because most of my partners are MSSPs. I’ve discussed this also during my Sentinel Deep Dive sessions for MSSPs, including the latest. It just keeps coming up and so I figured it would be easier to just publish this blog post.

I’ll warn you, dear reader, this blog post is my opinion, based on my personal experience, and I am happy to share my reasons.

The Challenge

MSSPs or Managed Security Service Providers have the responsibility to manage security services for their customers. Whether it is to access customers’ Sentinel workspaces or MDC via Lighthouse, as I’ve described here and here, or managing customers’ Defender 365 tenants, via GDAP or B2B, the MSSP identities have to exist somewhere. The challenge is deciding if your MSSP identities will exist within your corporate tenant or if you will create a separate MSSP tenant to manage your customers.

The Options

The Microsoft Sentinel Technical Playbook for MSSPs includes a section on “Azure AD tenant topologies” where they go over the pros and cons of the Single Identity Model vs the Multiple Identities Model. By the way, I encourage all MSSPs to read the entire whitepaper, since it’s a great resource.

Single Identity Model

Single Identity Model is where the MSSP corporate identity is used to access customers’ security services.

I can see this model working for POCs, where you are just testing the configuration, but not to access real customers. Yes, it is supported, but I would not recommend this as a final configuration goal. The reason is attacks on your corporate identities will not only risk your corporate data, but also your customers’ data. And vice-versa, customer attacks may also spread to your corporate resources.

Multiple Identities Model

Multiple Identities Model is where a new/separate tenant is deployed to manage the identities that have access to customers’ security services.

This model reduces the blast radius associated with any credential, device, or hybrid infrastructure compromise due to the common risks associated with the corporate tenant where employee accounts are used for day-to-day activities, including Microsoft 365 services. Think Zero Trust, specifically the assume breach principle. As a reminder, identity isolation is also one of the published CSP security best practices.

This is the ideal model to protect both your corporate resources as well as your customers’ resources. And if you are supporting or planning to support government organizations or organizations that need to meet government compliance requirements, then this is the model you will need to follow. Keep reading for more information on this. And, yes, it requires more work, but it is possible to configure and to automate as much as possible, including the JML (Joiners-Movers-Leavers) process. For a full overview of JML, please see my posts starting with part 1 here.

In-between?

Potentially there is also a third option, you could have separate identities within the same corporate tenant. This is not an option discussed on the whitepaper, but it is still an option to be considered. This is similar to what is explained on the Microsoft documentation about Protecting Microsoft 365 from on-premises attacks. The scenario described in the linked documentation is specifically targeted to use cloud-only accounts for Azure AD and Microsoft 365 privileged roles, which is exactly what the MSSP SOC analysts will have assigned to them on the customers’ tenants.

I see this option as a bare minimum for an MSSP, maybe one that doesn’t have the resources to manage a separate tenant and that has no plans to support customers that have to meet government compliance requirements. Although, you will still need additional configuration and a process to manage those accounts as user entitlements.

Compliance Requirements

Many MSSPs have authorizations that require them to meet compliance requirements among them government compliance requirements, such as FedRAMP. For those organizations to earn, and continue to hold, those authorizations they need have separate identities within the enclave. That means, not your regular corporate identity.

Here is a quote from my colleague, Rick Kotlarz, to expand on this topic:

In respect to U.S. Government / FedRAMP Information Systems, networks that have varying levels of security classification/impact levels always require separate identities. Those identities must also then be managed by an identity and access management system which is categorized at the same security classification/impact level.

Complete isolation of identities is not always required. One scenario where this isn’t the case, is when one or more network enclaves of the same security classification/impact level are federated or have a trust. Another scenario is when two or more network enclaves of varying security classification/impact levels implement a data diode. These are sometimes referred to as Cross Domain Solutions, that provide a bridge with limited data capabilities between these two networks. Typically, data is only permitted to travel from a lower security classification/impact level upward and is not bidirectional.

Because both scenarios require multiple levels of security leadership to accept the underlying risk of trusting an external identity provider operating outside of their purview, existence of these two scenarios are few and far between.

Furthermore, while some systems operating within a FedRAMP authorized environment may be Internet connected, they often are only authorized to support inbound data pulled from the Internet via highly restricted sources (e.g., Windows Updates).

Impact level reference: https://www.fedramp.gov/understanding-baselines-and-impact-levels/

I’ve worked with large MSSPs that followed the same entitlements management process for their government and for their commercial customer access because of the risk isolation I mentioned above. However, there was one main difference is the automation of the JML process. For commercial, they could just trigger a workflow to create/modify/delete the account on the MSSP tenant. For the government instance, they used a queue-based system, where the source would create a message in a mid-point area, that would then be picked up by the gov side process later. Basically, it would be a pull from the gov side, as opposed to a push to the gov side.

How?

Once MSSPs (and their auditors) come to the conclusion that the best, and sometimes only, option is the multiple identities model, then the “How?” questions begin. I am discussing below the most common questions I receive. I am sharing what I normally share with my partners, but I would love to hear other ideas.

How do we make sure these separate tenant accounts are removed once when the employees are terminated?

This is by far the no.1 question I get, and I completely agree, it should be the no.1 concern. This is where I go back to the JML (Joiners-Movers-Leavers) process. These external tenant accounts need to be tracked throughout the employee lifecycle, just like any other entitlement.

This is where Entra Identity Governance solutions, such as Lifecycle Workflows, can make this an automated process. There are a few existing templates, such as “Offboard an employee” or “Pre-Offboarding of an employee“, which trigger based on the emploeeeLeaveDateTime attribute, which you can then configure with rules based on specific attributes, such as department (i.e. ‘SOC’), or jobTitle, or a combination of attributes. This workflow will then execute a set of tasks, such as removing the user from groups and even running a custom task extension, which is basically a Logic App. You can configure that Logic App to take the steps to disable or remove that user from groups or access packages, etc. on the MSSP tenant, or any other steps you need to take to clean up that account.

How do we onboard and audit users on the separate MSSP tenant?

You can take similar actions for provisioning, by using tools such as Lifecycle Workflows joiner templates, as well as Access Packages withing Entra IGA Entitlement Management. Access Packages are groups of resources that are packaged together and can be assigned to or requested by users. You can create these within the MSSP tenant.

This just makes it easier to assign only those permissions the analysts will need within the tenant. You can also include in this package the MSSP tenant group membership they will need to access those customers’ resources as configured using Azure Lighthouse. Access packages also allow you to configure an expiration of those permissions, which can be extended upon request.

You can even use PIM, Privileged Identity Management, for managing those privileged groups. Additionally, you can also include access reviews for either the group membership or for the access packages, so you can consistently ensure only the right people have the right access and only for the amount of time they need it. Yes, our goal is still Zero Trust, and specifically here the principle of least privilege.

One thing to keep in mind for provisioning of users into an MSSP tenant on Azure Gov, is the compliance requirements to ensure the enclave is still isolated. Please see my note above on Compliance Requirements.

How will device based conditional access policies be implemented on the MSSP tenant?

The ultimate goal would be to have PAWs, Privileged Access Workstations, and those can be physical or virtual. I’ve seen organizations use jump-boxes (some call them bastions) in the past for this purpose. I am not an expert on cloud PCs, but it may be another option to explore given the ability to configure Conditional Access policies on those. You could then use Conditional Access policies with Identity Protection to protect those users and sign-ins in the same way you do for your corporate resources.

You can also use those conditional access policies to ensure MSSP SOC analysts only authenticate using phishing resistant methods, which in some cases may be a compliance requirement.

Summary

Configuring, maintaining, and monitoring a separate tenant means additional work, but it is the right thing to do in order to protect your customers’ resources as well as your corporate resources. Even if you don’t have compliance requirements that force you to select a more secure configuration, I would still highly encourage you to consider it. I know you will not regret it!

Update: There is a follow-up post to answer some questions that came up after this blog was published. Please reference MSSPs and Identity: Q&A