Group Power : Do you have control over your Conditional Access Policies?

Conditional Access is the game-changer in the Zero Trust security model, which thrives on the mantra "never trust, always verify."?? It dynamically evaluates real-time signals like user behavior, device health, and network conditions before granting access, ensuring only verified and compliant users and devices can reach sensitive resources.

This approach allows organizations to tailor access policies based on specific conditions, such as requiring multi-factor authentication (MFA) for high-risk activities or restricting access to managed devices. Acting as the policy engine for Zero Trust, Conditional Access defines and enforces policies that control access to resources based on various signals, incorporating real-time risk assessments and machine learning to adapt security measures on the fly.

As of 2024, over 500,000 tenants have implemented Conditional Access policies in Microsoft Entra ID, highlighting its critical role in modern enterprise security. ?? Adoption of Conditional Access policies continues to grow, driven by the need for enhanced security in a cloud-first, remote-enabled world. ?? With its dynamic, granular, and continuous verification, Conditional Access is essential for protecting organizational resources effectively. ??

How Entra ID Groups play a major role in your policies?

Groups play a crucial role in Conditional Access policies by streamlining user management and ensuring consistent security measures. Here's how:

• Efficient Management: Groups allow administrators to apply Conditional Access policies to specific sets of users, such as departments or roles, simplifying policy management.
• Dynamic Memberships: Groups can automatically update based on criteria like job role or department, ensuring policies stay current without manual updates.
• Policy Exclusions: Groups can exclude certain users from specific policies, providing flexibility in access control.
• Least Privilege Principle: By using groups, organizations can ensure users only have access to necessary resources, minimizing the risk of unauthorized access.
• Scalability: Managing policies at the group level rather than individually makes it easier to scale security measures across the organization.

In summary, groups are essential for efficiently managing and scoping users in Conditional Access policies, offering a scalable and flexible approach to enforcing security measures.

But, do you have power over the groups??????

I believe Group Administrator, Group Owners, or any identity with the Group.ReadWrite.All permission in Entra ID are like the secret superheroes(or supervillians!) of your tenant. ??♂???♀? They wield immense power, almost on par with Global Administrators. Here's why:

• Membership Magic: They can change group memberships, adding or removing users at will. Imagine the impact on your Conditional Access policies! ?? The membership changes does have impact on your enterprise applications as well!
• Delete Dynamo: They have the authority to delete groups entirely. This can disrupt your Zero Trust implementation (by deleting the group used in Conditional Access policies) if not managed carefully. ??
• Policy Puppeteers: By manipulating group memberships, they can indirectly control who has access to what, potentially bypassing critical security measures. ??

So, while these roles are incredibly powerful, they need to be handled with care. Mismanagement can throw a wrench in your Zero Trust strategy, making it crucial to monitor and manage these permissions diligently. ??

By now, you would have figured out where I am going. Sure you do have alerts or monitoring on the changes done to your conditional access policies (If you haven't already set up alerts or monitoring for changes to your Conditional Access policies, stop everything and do it now! ??). Set up alerts to stay informed about changes to your Conditional Access policies. Whether it's a Sentinel incident, an email, or a Teams message, make sure you're always in the loop! ????

an example of KQL query which can help alert you when conditional access policies are changed can be -

AuditLogs
| where LoggedByService == "Conditional Access"
| project InitiatedBy = coalesce(tostring(parse_json(InitiatedBy).user.userPrincipalName),"No Details in Logs"), ConditionalAccessPolicyName = tostring(parse_json(TargetResources[0]).displayName),TimeGenerated,OperationName,Identity = coalesce(Identity, "No Details in Logs")        

But that's not our main focus today! ?? Also, remember that changes to group memberships or groups within your conditional access policies won't trigger these alerts. ??

In this edition of the newsletter??, I propose a design that will alert your Identity or Security team whenever changes are detected in the groups used in your Conditional Access policies. ?? This proactive approach ensures that any modifications to group memberships or configurations are immediately flagged, keeping your Zero Trust implementation solid. ??? ??

The high-level solution is outlined as follows:

Now let us dive into the details!

First, we need to create a watchlist in Sentinel. We have created a watchlist as below which contains the objectIDs of the groups used in Conditional Access policies.

Next step is to add an item and give the column heading. You can create a csv file and upload it as in the steps described in Microsoft documentation.

To ensure the Watchlist is populated with the object IDs of all groups used in the conditional access policies and remains up-to-date, we can implement an automated solution. This involves running a Logic App that leverages the Graph API and the Sentinel connector. The Logic App will be scheduled to run daily, ensuring that any changes in the group object IDs are captured and updated in the Watchlist.

Logic App Implementation

First we fetch the policy details (name and groups) using graph API and parse the JSON content (response)

https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies?$select=displayname,conditions        

Then after a series of loops and hoops, we add the included groups and excluded groups in our conditional access policies to array variables.

Next we do an union and join the two arrays.

Now we have the objectIDs of all the groups used in the Conditional access policies. The union function ensures that we take only distinct objectIDs across all the policies.

Next step is to fetch objectIDs from our Watchlist, check if the item exists and if not, then add the objectIDs to our watchlist.

Now that we have our Watchlist populated with the necessary object IDs, it's time to build alerting around it. There are several ways to achieve this, such as using KQL in your workspace to generate alerts. These alerts can be sent via email, Teams, or by creating an incident in Sentinel. You can choose the option that best suits your needs.

One important consideration is that the list of groups may include dynamic groups (e.g., All Users) that update frequently. You likely don't want to generate alerts for these dynamic groups. To address this, you can exclude them from your analytics query. By excluding dynamic groups from your query, you ensure that alerts are only generated for relevant changes, reducing noise and focusing on actionable items.

Below is the KQL query which monitors for the changes -

AuditLogs
| where TimeGenerated > ago(1d)  // Adjust time range as needed
| where OperationName in ("Add member to group", "Remove member from group", "Add owner to group")
| extend GroupDisplayName = iff(isnotempty(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue))), parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].newValue)), parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[1].oldValue)))
| extend GroupObjectId = iff(isnotempty(parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue))), parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)), parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].oldValue)))
| where GroupObjectId in (_GetWatchlist('conditionalaccessgroups')
| project groupguids)
| project TimeGenerated,GroupDisplayName,GroupObjectId,OperationName,Identity        

and the result would be in the below format -

I would like to receive an alert via an Incident in Sentinel whenever there is a change. Let's proceed with setting it up.

We would need to create a scheduled query rule in Sentinel Analytics.

Next step is to provide the query name, description and set the severity.

Next, we will create the actual rule using the KQL query mentioned earlier. Although I have not done any entity mapping, it is recommended to include it. For now, I will fetch the details as Custom details, as shown below. Additionally, we need to set up the query schedule to determine how frequently the query should run.

By following these steps, we can ensure that our monitoring and alerting system is both effective and efficient.

We can also create a playbook to trigger a workflow (e.g., in a Logic App) for further actions once an incident is created. However, for now, I have chosen not to implement this step.

Now, time to get the alerts!! Below you can see that an Incident is created in Sentinel which contains the details. Time to take action!!

Closing Statement ??

In this edition of the newsletter, I have outlined the risks associated with changes made to your groups. Specifically, how group owners or anyone with permissions to edit groups can significantly impact your Zero Trust implementation. Understanding these risks is crucial for maintaining the integrity and security of your environment.

I have outlined a comprehensive approach to ensure the Watchlist is populated with the necessary object IDs and remains up-to-date. This involves setting up a Logic App to automate the process using the Graph API and Sentinel connector. Additionally, I discussed creating alerting mechanisms in Sentinel to generate incidents whenever there is a change in the Watchlist, ensuring prompt notifications and appropriate actions. ??

I value your feedback on this approach. Please let me know if you have any suggestions or if there are additional considerations I should take into account. ??