Demystifying Security: Conditional Access

What is the challenge?

Nowadays, with employees able to access work resources from different types of devices (e.g., desktop, tablet, mobile phone) and different locations (e.g., office, home, public), the challenge for security and mobility teams is ensuring that only authorized devices are allowed onto the network.

It’s also about striking the right balance that allows users/employees to be productive from anywhere, at any time, while still protecting corporate resources. Conditional Access is here to ensure that only authorized devices are permitted to connect with the corporate infrastructure.

How is it usually dealt with?

Traditionally, usernames and passwords have sufficed as credentials to allow an employee to access a corporate resource or service from a device, either desktop or mobile; this means one factor only (the user) was used to decide whether to grant access or not. As we migrate to a Zero Trust architecture, an additional layer of access should be included to ensure that not only the user but also the device itself is authorized to access those resources, services, and handle corporate data, ensuring said data will not be compromised in any of its states (in transit, at rest and in use); a second factor (the device) is also taken into the equation. Combined with the Zero Trust architecture, which consists of providing only the minimum access required, on a per-resource basis, would deliver better protection. However, this is no longer enough to attend to today’s needs in term of cybersecurity.

What is Conditional Access?

Conditional Access enables corporations to strengthen and fine-tune their access control policies with additional factors like device, location, application, or real-time risk level to determine whether a user will be allowed to access a service, be blocked, or be allowed but only after validating additional checks.

How does it work?

Conditional Access uses multiple factors to make decisions and enforce organizational policies.

Common factors considered to make decisions include:

· User: Specific users or group of users can be targeted with different policies

· Location: Where is the user connecting from?

o Known, trusted location (e.g., office)

o Known, untrusted location (pre-defined area, region, country)

o Unknown, untrusted location (any other location)

· Device: Specific platform

· Application: Specific to an application or groups of applications (e.g., email)

· Real-time, calculated risk

o If the device is compliant with company security policy (e.g., managed by UEM solution)

o If the device is at a potential risk level (e.g., threat detected by MTD solution)

Unlike a default allow/block approach, a third one is included, which triggers complementary authentication and/or requests additional factors before allowing access:

· Block access (most restrictive)

· Allow full/limited access

· Allow access but first require one or multiple additional options

o Request Multi Factor Authentication (MFA)

o Device to be marked as compliant

Use cases

Connection from unusual/unknown location:

An employee is travelling to a foreign country and connecting from a public place (e.g., airport) at arrival; the user is authenticated, the device managed and safe, however, the location is unusual, and so an additional confirmation is triggered (e.g., validate from another known, trusted device) to ensure that the request is legit and coming from the user, not a possible attacker trying to impersonate one of his devices.

Unapproved software:

An employee managed to install a supposedly safe, yet still unapproved, software on his device. That is detected by the UEM software and the device is marked as uncompliant. The device status is then sent to the organization’s back-end infrastructure (e.g., Microsoft 365) so access to certain/all services, including email, internal website, etc. is prevented until the situation is fixed and the device reports back as compliant by UEM software.

Note:
Conditional Access feature must be available directly, embedded into the solution or service for which we want to restrict access (e.g., mail, web), either on-premises or cloud-based.

Conclusion

While moving from a traditional security approach to a more advanced, optimal one for your organization, Conditional Access is an important tool of any security strategy, involving all five pillars of Zero Trust architecture (identity, device, network, application, and data).

It can be leveraged across the whole infrastructure, using factors not only gathered by the corresponding service provider (e.g., Microsoft 365) but also from other complementary third-party solutions. Such data can include device compliance status (compliant/uncompliant) and enrollment state (managed/unmanaged) provided by a Unified Endpoint Management (UEM) software, and/or device risk level (e.g., threat detected, sideloaded app, encryption disabled) provided by a Mobile Threat Detection (MTD) software. The more factors involved, the better the security.