Implement Conditional Access to support Zero Trust Architecture

We’ve already discussed how identity plays a critical role in Zero Trust Architecture. And to maximize this capability, conditional access must be a part of your identity policies.

Beyond usernames and passwords

Using conditional access within identity management, you can control access depending on various parameters, such as location, time, device state, etc. Feeding additional information like the users’ location or device health provides context when the system is making decisions about access. It allows decisions to be made with more certainty than only depending on the accuracy of username or password.

Sadly, it’s not hard for attackers to get leaked credentials from the dark web in today's environment. Under the old system, that would be enough to do considerable damage. But under conditional access, malicious actors have a more complicated job. Conditional access may process risk information derived from the user sign-on behavior to prevent access, such as impossible travel. (Impossible travel is when two login attempts are made from far-off places that are physically impossible to travel in the time between the attempts—often signifying that one of the attempts was fraudulent.)

Since compromised accounts are among the top attack vectors, blocking access to credentials, even when an accurate password is provided, can be invaluable to preventing breaches. And because of this, both OKTA and Azure AD have enhanced their products to work with key technologies to enable a risk-based approach to providing access. Conditional access takes security signals from multiple platforms and facilitates better decisions assuring that people logging in are genuine.

Zero Trust demands a well-integrated environment that allows security signals to be shared across various platforms. Shared signals between InTune and Azure AD, for example, will enable you to detect if a user is logging in from a non-corporate-owned or controlled device and increases the assurance that the correct user is logging in. One example of this would be an application requiring a second authentication factor when connecting from a hotel kiosk computer. At its simplest, conditional access policies function like if-then statements: if a user wants to access a resource, then they must complete an action. And if a user’s context is less secure than another context, then they must provide more proof of identity.

In addition to requiring different levels of authentication depending on the context of an access request, conditional access can even allow us to present different sets of applications depending on where a user is, based on different risk levels from the other kind of connection. It can also allow various applications depending upon the level of access authorization. A simple example of this is already common practice: the finance team will have access to finance apps, or the marketing team will have access to marketing apps. It can also control which apps can be presented to managers and which apps to subordinates.

The power of access control

Traditionally, identity management took the form of Role-Based Access Control (RBAC). Most of us are familiar with this system, where you grant different access to different users based on their roles. For example, an employee will have access to expense reporting, and the manager will have access to approve that. This model has many inherent challenges: role accumulation, access governance, overprovisioning, etc. We’ve all worked with that guy who’s been with the company for ages and has access to everything, simply because he needed access five years ago, and nobody ever shut that connection.

Attribute-Based Access Control (ABAC) addresses a few of the challenges of RBAC. We can think of ABAC as a more granular way of applying conditional access. According to NIST, ABAC is defined as “An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.” Attributes for subjects and objects are maintained in separate databases and updated regularly during the subject/object lifecycle, and access control policies are also held in a separate repository.

Whenever access is requested for any particular object, the corresponding subject and object attributes are fetched from the database, environmental conditions are considered, and evaluated against policy. The access is granted or denied (or, crucially, limited access is provided) based on this computation decision. For example, a policy could be that only CFO and their direct reports can read/write in to the company's quarterly financial reports. Suppose users with attributes such as department (finance) and designation (CFO/direct reports) try to read/write into files with attributes such as financial reports. In that case, the policy enforcement process will grant access as it meets the policy evaluation criteria.

However, it’s worth keeping in mind that ABAC implementation can be time-consuming. It could be a costly affair, and you will need to establish the business case by doing a cost/benefit analysis. You may need to develop a new business process or refine your business process to build and maintain subjects/objects attributes and access policies.

Greater context and nuance

Conditional access allows greater context and nuance around providing access rather than a binary yes/no based on a username and password. Requiring additional context to offer risk-based criteria to access is key to Zero Trust. Conditional-based access and just-in-time access to privileged accounts go a long way to ensure that the Zero Trust tenets of assuming breach and least privilege are fulfilled within your identity architecture. Implementation and management of conditional access in an enterprise can be challenging, but the added security that comes with it is often well worth the effort. An experienced partner is always recommended.

As a trusted advisor, NTT DATA can help you in this journey.