“Only the paranoid survive.”
Andy Grove’s iconic title for his 1999 recommendations for coping with rapid changes in business environments is especially appropriate for discussing one of the most popular phrases in IAM: “Zero Trust”. The problems it addresses have become more urgent in recent years due to both cloud technology and a better understanding of how cyber attacks occur in the field.
We believe “Zero Trust” has earned its place in IAM and should be considered an Authorization best practice for many companies.
The phrase "Zero Trust Architecture" was coined in 2010 by John Kindervag, then at Forrester. Kindervag was responding to the then prevalent attitude that “once a user is authenticated, they are trustworthy day or night, although they may not be granted access to all resources.” Kindeveg and others argued that because of this attitude, users were not asked to authenticate themselves again before accessing sensitive data. Cybercriminals could take advantage of this trust, using lateral movement to access the data they were after around the clock. Therefore, Kindervag and others argued that IAM should adopt an attitude of “never trust; always verify” with additional security measures, such as two-step verification, required at various points in a user session.
The case for Zero Trust IAM solutions became stronger with the advent of the cloud and B2B practices, such as granting suppliers access to company data. These changes erased the traditional definitions of “inside” and “outside”, which were the basis of many IAM solutions. Without these boundaries, there was no longer any reason to trust some authenticated users more than others.
There are a variety of approaches to Zero Trust. Some argue that calculations should be applied to evaluate the risk of granting a user access to a resource. Others, such as James Carder, argue that IAM solutions should “apply security controls only where they are needed, to compartmentalize and protect critical systems and data.” All implementations shift the “perimeters” that need to be guarded from the network boundary to the resources themselves.
Regardless of implementation, Zero Trust offers many benefits. First, it meets new business requirements, including supplying the greater architectural flexibility needed for current B2B functionality. At the same time, Zero Trust emphasizes increasing security where it’s needed the most, at the access points to critical data. As Symantec’s Gerry Grealish notes, unlike in the past, “corporate data can be … everywhere [including] cloud SaaS apps, workloads in AWS or Azure, [and] mobile devices.”
Although a Zero Trust approach can improve any IAM solution , it works better with policy-based access control (PBAC) solutions than with role-based access control (RBAC) and attribute-based access control (ABAC) ones.
While RBAC does specify exactly which resources each role can access, it does not take into account the context, such as time of day or a user’s location. This means it cannot support fine-grained Authorization. Moreover, many implementations of RBAC allow users to have more than one role, which can lead to users having access to too many resources. Finally, RBAC’s cumbersome maintenance requirements make it a poor match for a Zero Trust solution.
ABAC is a better match for Zero Trust than RBAC. By its very nature, ABAC supports making access decisions on the basis of contextual factors such as the time of day that an access request is made, as well as the user’s location. Therefore, it supports fine-grained Authorization. Because ABAC is designed to make run-time Authorization decisions, a platform using it can make the multiple decisions required by the Zero Trust approach. Unlike RBAC, ABAC does not assume that a single decision at the time of Authorization is sufficient.
Despite these advantages, ABAC runs on Boolean logic and advanced but complex languages such as XACML. This means that despite its advantages, ABAC solutions require coding to use and changes to its Authorization scheme may take some time.
And this is where PBAC has a significant advantage: it supports natural language and requires no coding. This means it supports basing Authorization decisions on a number of attributes, including roles, enabling authorized personnel to create fine-grained policies, just like ABAC. It also supports multiple Authorization decisions in a single session. But most importantly, it enables companies to create or change PBAC Authorization policies on-the-fly. For example, a B2B company might need to grant a supplier access to company data. A PBAC solution would allow them to change access rights immediately, without IT assistance.
The cloud and SaaS have changed fundamental assumptions about networks and securing them. These changes, combined with a better understanding of how cybercriminals actually work, have brought about the Zero Trust approach to Authorization and the rest of IAM.
These changes further reiterate the need for access management solutions such as PBAC, which fully supports dynamic fine-grained Authorization schemas which can be changed instantly. After all, you don’t need to be paranoid to know that you have to keep your guard up.
