MSSP Access to Azure Sentinel and M365 Defender – Securing and Auditing

Last month I wrote how you can establish MSSP access to customer environment Azure Sentinel and M365 Defender instances. This blog covers how you can secure and audit the access focusing on user identity, both sides covered but Privileged Access Workstation scenario is out of scope.

MSSP Azure AD Tenant Hardening

Hardening MSSP tenant is critical to establish strong secure posture in MSSP tenant. Azure AD tenant contains a bunch of security settings that needs to be hardened, or at least consider of doing so and I’m not covering those ones in here. I’m focusing the actual access between MSSP tenant and customer tenant, both through Azure Lighthouse delegation and B2B access to M365 Defender.

Thomas Naunheim has written good blog post about Azure AD tenant hardening and Microsoft has excellent documentation available:

• Azure AD Tenant Hardening by Thomas
• Azure AD Identity Management and Access Control best practices by Microsoft
• Five steps to securing identity infrastructure by Microsoft

Considerations in MSSP Tenant

Strengthen Identity Posture with CA, PIM & IPC

Azure AD Conditional Access

There are number of blogs around how you should create bulletproof Conditional Access policies and protect your workloads. I won’t highlight them separately here but suggest to start from Microsoft Conditional Access best practices and common Conditional Access policies, starting with “Block legacy authentication”.

Privileged Identity Management

Take PIM together with PAG into use in home tenant to protect own resources. More info from

• Start using PIM – Azure Active Directory | Microsoft Docs
• Managing privileged Azure AD groups in Privileged Identity Management (PIM) | Microsoft Docs

Azure AD Identity Protection (IPC)

Configure Azure AD Identity Protection to protect you identities in MSSP tenant. IPC policies can be configured from both, IPC or Conditional Access engine (CA). I would prefer to use CA because it adds more granularity for configuring the policies but keep in mind, the outcome is same no matter which method you use. Example approach for implementation:

• Policies can be configured from IPC or Conditional Access
• Preferred option is CA
  • Targeted in the first phase only to pilot group
• For privileged users, block users at high risk using conditional access
• For all users, enforce MFA on medium/high sign-in risk
• For all users, enforce secured password change on high user risk
• CA policies in reporting mode – evaluate results – enable policies
• Follow same best practice than with other Conditional Access policies

More info from:

• Azure AD Identity Protection Deep Diver – Part 2 – Sam’s Corner (samilamppu.com)
• Azure Active Directory Identity Protection security overview | Microsoft Docs

Privileged Identity Management (PIM) with Privileged Access Groups (PAG)

The benefit of using PAGs is the MSSP admins don’t have permanent access to the customer environments. Permissions are elevated when those are needed through PAGs. Number of PAG groups depends how roles and responsibilities are defined in the environments. In my example I have used the following roles

• Azure Sentinel Reader
• Azure Sentinel Responder
• Azure Sentinel Contributor
• Azure Subscription Reader

• 

• 

• 

PAG Auditing

When PAG’s are used there is a possibility to send notification email outside MSSP tenant. This enables customer to receive notifications when access to their environment is activated via Azure lighthouse. Even though it might sound a bit extravagant in the first phase, it adds visibility to customer side.

• 

PIM activities are found from Azure AD audit logs in MSSP tenant. Typical activity to monitor is ‘Access granted outside PIM’. Why? Nothing prevents admin to grant permission outside PIM

// Find members who has access outside PIM
AuditLogs
| where OperationName == "Add member to role outside of PIM (permanent)"
| extend AccountCustomEntity = Identity

Key Takeaway

• PAG affects only to Azure Sentinel access in this scenario. PAG & PIM events are found from Azure AD audit log.
• Access to M365 Defender and other security solutions such as MDE, MDO, MDI & MCAS is establish in B2B user context and it’s not honoring the delegations made through Azure Lighthouse.
• Even though PAW concept is no covered here – ‘Improve security and usability of privileged access in Azure’

Considerations in Customer Tenant

In the customer side you can control two pieces of the puzzle, Azure Lighthouse and M365 Defender access.

Azure Lighthouse

Azure Policy & Service Providers

In the Azure Policy there are two highly recommendable Azure built-in policies available:

• Audit delegation scopes of a managing tenant
• Allow managing tenant ids to onboard through Azure Lighthouse

With these policies the customer can audit the delegation scopes and limit the allowed delegations against own tenant.

If you need to verify MSSP’s permission those can easily seen from “Service providers” blade from the Azure portal.

• 

• 

• 

Take into account that role assignments nor users in the roles cannot seen from “Service Providers” blade.

Azure Monitor and Activity Log

Azure Activity Log is your friend from auditing perspective. When SOC analyst makes changes to customer’s Azure Sentinel instance (update incidents etc.) those activities are logged to Azure Activity log which is component of Azure Monitor. What’s also interesting, you can see if MFA was used by the partner from activity logs by inspecting the claims, kudos to @SantasaloJoosua for highlighting this one.

• 

MSSP Resource Activities

Activities made by MSSP are found from the Activity Log from customer side. In this example, “Analyst2” has update security incident.

• One the left, incident on the customer side
• On the right, in home tenant

• 

• 

M365 Defender

As written above, M365 Defender is not honoring Azure Lighthouse and M365D access is granted through Azure AD B2B user identities & groups that can be configured in the M365D management portal (security.microsoft.com) ‘permissions & roles’ section & Azure AD Identity Governance, more info here.

Azure AD Identity Protection (IPC)

Consider configuring IPC policies so that guest users are in scope, or create separate policies for MSSP users with Conditional Access. Take in to account:

• The user risk for B2B collaboration users is evaluated at their home directory.
• The real-time sign-in risk for these users is evaluated at the resource directory when they try to access the resource.

Conditional Access – Allowed Locations

In general, consider allowing admins to authenticate only from certain locations and with strong-factor authentication.

• 

• 

Conditional Access – App Control

In the Conditional Access & MCAS policy side configure policies that are targeted to groups containing MSSP Analysts identities. As a pre-requisite I imported the MSSP groups to MCAS.

• 

• 

Cloud App Security (MCAS) Session Proxy

Experimental testing of leveraging MCAS as protection mechanism, pay attention to key takeaways.

If the customer organization has MCAS deployed I would definitely leverage that one as a protection mechanism in MSSP scenario. The MCAS session proxy, together with Azure AD Conditional Access would helps you to monitor (or even block certain activities) the sessions with session policies.

To achieve aforementioned scenario you need to to add M365 Defender aka Microsoft XDR aka security.microsoft.com to Cloud App Security as a conditional access application that you can redirect the traffic to app to session proxy, and scope your policies to it.

Session Proxy Description- docs.microsoft.com

Conditional Access App Control replaces all the relevant URLs, Java scripts, and cookies within the app session with Microsoft Cloud App Security URLs. For example, if the app returns a page with links whose domains end with myapp.com, Conditional Access App Control replaces the links with domains ending with something like myapp.com.mcas.ms. This way the entire session is monitored by Microsoft Cloud App Security.

• 

• 

• 

• 

User Experience in MCAS Scenario

MCAS jumps in the game when the analyst is accessing from Azure Sentinel to M365 Defender portal (security.microsoft.com). Conditional Access policies will be evaluated and the policy will redirect to the MCAS proxy as seen on picture 2. When landing to M365 Defender the MCAS Conditional Access App control has done its magic whic can be seen in the browser URL field.

• 

• 

• 

From MCAS Activity Log you can easily filter out MSSP’s SOC Analyst activities based on access & session controls.

• 

• 

Key Takeaways

• Use MCAS with session proxy in MSSP scenario, it adds extra layer of protection and possibilities.
  • Keep in mind that MCAS doesn’t cover all client scenarios, only browser based traffic
  • Onboard M365 Defender as custom app to MCAS if you want to achieve the scenario
  • + create Azure AD Conditional Access policy for MSSP users
• Be patient, in my environment it took a while before it started to work as expected
• Consider configuring authentication session policies for your admins – Configure authentication session management – Azure Active Directory | Microsoft Docs
• Passwordless such as FIDO was left out on purpose here. I will address passwordless scenario in B2B context in different blog post.

Summary

Where	Scenario	Solution
Customer tenant	Deploy Azure Policies – Audit delegation scopes of a managing tenant – Allow managing tenant ids to onboard through Azure Lighthouse	Azure Policy
Customer tenant	Restrict MSSP access only from allowed location(s) with strong-factor authentication	Conditional Access
Customer tenant	Protect browser based access with CA & MCAS – MCAS doesn’t cover all possible scenarios	Conditional Access, Cloud App Security
MSSP tenant	Use Privileged Access Groups (PAG’s) for managing, limiting & monitoring the access to the customer environment	Privileged Identity Management (PIM) + Privileged Access Groups (PAG)
MSSP tenant	Harden Azure AD tenant	Azure AD settings
MSSP tenant	Strengthen identity security posture	Azure AD security controls, Conditional Access, Identity Protection

Hope this helps when planning MSSP access either in service provider or customer side.