CyberHound 365
CyberHound 365
  • Home
  • The Personas approach
  • Conditional Access logic
  • Cyberhound365 screenshots
  • Video (CA editor)
  • Video (manage users)
  • Get in touch

Try out our unique Conditional Access editor for FREE!

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Conditional Access policy editor

Creating and editing Conditional Access policies in CyberHound365 

What is Conditional Access?

Conditional Access is a capability within Microsoft Entra identity management that controls user access to company apps and data based on other factors, such as device state, location, risk levels and other contextual signals. 


It is the centerpiece of Zero Trust security, a model that does not grant access just because a user knows their username and password. 


Instead Conditional Access ensures additional security checks are passed before access is granted, such as requiring that a user is signing in from a company managed device that is also security compliant, and enforcing stronger MFA in particular circumstances.


We can scope Conditional Access policies in a number of ways, here we consider Baseline policies that are active across a whole Microsoft Tenant for all users, and Persona based policies, that are targeted at a specific set of users based on their role within the company, for example corporate staff in a given country or managers of a retail environment.


Baseline policies are relatively easy to implement- there are a number of Microsoft templates straight out-of-the box that can be implemented with little or no configuration changes.


 Persona based polices, on the other hand, require more complex analysis and provide an enhanced layer of security.


Note that Conditional Access only has control over those resources to which Microsoft Entra is the Identity Provider (IdP), for example Office365 or Azure portal access.

The Persona approach

 Understanding and defining expected access requirements for the various roles in a business (Personas) is a foundational strategy in identity and access management, playing a critical role in supporting a Zero Trust security framework.

With a well defined approach, Personas can be directly mapped into Conditional Access policies.

Persona example

This example persona describes a UK retail store manager. They are:

  • issued with a corporate laptop that is enrolled into Intune
  • able to use their personal phone to access company Microsoft O365 services
  • have access to a store manager App
  • able to log into the Point of Sale (POS ) device, an Intune managed iPhone
  • based in any UK store

 

We employ Microsoft's App Protection Policy with Grant actions to strengthen the security around using personal mobile devices to access corporate data.


Each Persona is built by understanding business operations

and ensuring they align with best security practice.


When conducting a Persona assessment, the following, as a minimum should be taken into account:

  • Microsoft licenses assigned to users
  • Groups assigned to users
  • User types, such as Member, Guest, Federated, External
  • Resources and resource types accessed by users
  • Platforms / hardware assigned to the users 
  • Device enrollment mechanisms / if the devices are company or personally owned
  • On-prem Entra hybrid joined devices that may be in use
  • Locations / network the users will be working in
  • Client types that are used, such as browser, client and mobile apps
  • Compliance of the devices that should be achieved
  • App Protection Policies that may be deployed
  • Password policies relevant to the user types
  • The type and strength of MFA that is required
  • Session security requirements, such as periodic authentication
  • Global Secure Access (Microsoft's new secure cloud access)


A risk based approach can also be added, that determines access based on a user's activity risk or sign-in risk, adding another layer of security.

Implementing Persona based Conditional Access policies

The complexity of implementing a persona based Conditional Access policy is due to the operation of Conditional Access itself; and although it's tempting to think of Conditional Access as a kind of 'Zero-Trust firewall', it's operation has a number of quite specific differences which have far reaching implications:


  • ALL conditions must be met for the policy to result in the desired action.
  • If ANY of the conditions in the policy are not met, the policy is ignored.
  • All policies operate in parallel, there is no ordering of polices.
  • No policy is exclusive, i.e. different policy conditions may overlap, and multiple polices may be in force simultaneously
  • For multiple policies in force simultaneously, the Grant options are ALL enforced, i.e. AND together.  If any applicable policy blocks access, the block takes precedence and access is denied. 
  • There is the no specific 'default block' policy; multiple policies must be created to block the unwanted scenarios, bearing in mind ALL of the above rules also apply to block policies as well.


Scratch beyond the surface, and we find that these rules open up a pandoras box of 'the unexpected' when creating Conditional Access policies.

Cyber resilience

It's clear that we need to think like the threat actor to secure our Conditional Access policies. 

In particular the second and last items in the above list are alarming, and will clearly create gaps for threat actors to exploit, unless we are careful in our Conditional Access design.

Conditional Access logic

To understand Conditional Access, we need to understand the logic it is built on.

Note that the Actions are only performed if ALL of Users, Resources and Conditions, that have an entry in their corresponding blue box, are matched TRUE; otherwise the policy has no effect.

This is the key to understanding Conditional Access.

Furthermore, all policies act as logic AND. There is no ordering; all policies act in parallel

Example persona - A solution

The above logic dictates that we will frequently require a range of block polices for each Persona grant policy. 

This is practically unmanageable using Microsoft's native interface, as we need to compare the configuration of each group of policies side by side to perform gap analysis.

Here is one possible set of Conditional Access policies to fit the example Persona of UK Store Manager, in practice there may be differences depending on the strength of the lock down required.

Threats mitigated with this policy set

Ten Conditional Access policies for a single Persona, might seem like overkill on the face of it, but we need to be sure that every policy is necessary for the precision result we desire.


Here is a summary of the implementation:


Persona based security segmentation

By targeting this policy set to the UK Store Managers only, we segment security policy to business requirements.

  • Aligns security controls with the least privilege principle of Zero Trust
  • Allows us to make changes that affect just one Persona type, for precision security and a layered approach
  • Makes testing and fault finding much easier as policies are defined against a specific set of users


Risky access from untrusted geographic locations:

Policy 22,25 and 27 block access from undesired locations and mitigate against:

  • Helps preventing stolen credential from being used outside the UK
  • Access through stolen POS devices by restricting their use to store locations
  • Helps to restrict access to the Store Manager application to the UK only


Data leakage from unmanaged or non-compliant devices

Policy 20 and 26 require a compliant device, 24 and 26 also require an App Protection policy. Policy 29 blocks access should any managed device become non-complaint and Policy 25 blocks personal mobile devices access from outside the UK. This helps mitigates against:

  • Exfiltration of data from personal devices abroad
  • Lost or stolen devices without device security controls (including encryption, PINs)
  • Use of UK Store Managers personal devices outside the UK from accessing corporate data


App-specific security enforcements

Access to O365 and the Manage Store application is blocked from the POS device. This mitigates against:

  • Phishing attacks via email and Teams to the store sales POS devices
  • Unintended IT usage, such as use of Teams and Facetime on the POS devices
  • Prevents other members of staff accessing the Manage Store application through the POS devices


OS/Platform specific risk management

Policy 21 blocks unsupported platforms accessing O365 and the Manage Store application, as well as blocking unknown platforms including, for example, Raspberry Pi which has been used in a number of high profile cyber attacks. Threats mitigated:

  • Prevents access from OS that can be purpose built for cyber attacks, such as Raspberry Pi and Linux.
  • Helps to protects systems by blocking unknown OS with the 'All platforms except Windows, iOS and Android' Conditional Access rule


Weak authentication and Conditional Access evasion

Policy 20 and 24 requires the stronger protection of Password-less MFA. Policy 21 and 22 together prevent the blind-spot that would otherwise been created with Policy 20 by accessing either from a non-windows device or from outside UK. Policy 25 prevents the blind-spot of Policy 24, and Policy 27 prevents the blind-spot of Policy 26. Policy 29 prevents POS access should the device become non compliant, such as when an OS update has not been implemented in line with the compliance policy. Threats mitigated:

  • Enforces strong MFA policy
  • Eliminates Conditional Access blind-spots
  • Prevents POS devices from being used if the OS becomes non-compliant

Conclusion

Achieving a secure Conditional Access policy, targeted on a Persona basis, requires a side-by-side comparison of the policy set; CyberHound365 makes this surprisingly easy.


If you're implementing Microsoft Conditional Access (or planning to) as part of your cyber security strategy, and you would like a complete strategy or policy review, get in touch, and we can make that happen.

CyberHound 365 screenshots

Manage users at scale

Enable / disable/ delete users in bulk.

Password reset users in bulk.

Search last login date and account age.

View and search last error code for all users.


View and search MFA options for all users.

Search privileged roles over all users.

Manage user attributes

View user information, assigned groups, associated devices, assigned licenses and roles, MFA methods, and the last error message in detail on a single screen!


Spit screen to see all users AND individual user details over two screens simultaneously.


Perform password reset, revoke session and enable / disable account with a single click.

Compare different Conditional Access policies, side by side

Search and order columns in Conditional Access policy data instantly, like never before.


Easily spot your Conditional Access gaps. 


Supports split screen for global policy view and edit mode simultaneously.

Create Persona policies- complete visibility of all Conditional Access configuration settings in one pane-of-glass

Intuitively visualize CA policy. Shown here: Group: UK Store Managers excluding a user, accessing Office365, Location: UK, Platform: Windows: Action: Grant access and require compliant device


Coming soon - AI mode Conditional Access creator!

Backup and restore

Backup all conditional Access policies in a single click.


Backup and restore all users, groups and devices in a single click - coming soon!

Manage devices at scale

Block access, scan and update AV settings for managed devices.


Monitor joined devices. Search owners of all devices and determine unusual or out of date OS, instantly, with just one click!

Search for privileged users

Dynamically search all or any subset of users for any privilege type.


This is a great feature, giving super fast visibility of where your high privileged users are, right across your tenant.

View groups in a more intuitive way

Compare groups side by side, sort by number of owners or members.

Spot those group with no users or owners, created years ago that need to be deleted.


View all nested groups, making it easier to determine group dependencies.

Full group visibility

View all group details in a separate window, so you don't lose sight of your  main group listing (screenshot above).


Easily spot those nested groups that can easily be missed!

Resource permissions

See all resources, app roles and Oauth permissions in one scrollable screen, without having to  select, view and reselect each resource one at a time.

Conditional Access policy editor

Creating and editing Conditional Access policies in CyberHound365 

User Management overview

Managing users in CyberHound 365

Louis’ background is electronic engineering, a Master’s degree in telecommunications, and is a CISSP certified cybersecurity professional.

With experience of large-scale telecoms environments at Orange Telecommunications, the American cyber security companies BreakingPoint and Ixia Technologies (now part of KeySight), together with Cyber Security Lead at C&J Clarks, he has first-hand experience spanning a diverse range of roles within the cyber security landscape.

Get in Touch

Attach Files
Attachments (0)

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Cancel

Copyright © 2025 CyberHound 365 - All Rights Reserved.

  • Privacy Policy

This website uses cookies.

We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.

DeclineAccept