Continuously Assuring Access – Learning to Say “Yes” More

In my blog on Zero Trust (“Castles to Cities”) I promised a follow-up on CARTA.

 

What is CARTA? 

Coined by Gartner, this term stands for Continuous Adaptive Risk and Trust Assessment.  

At the highest level, CARTA as a concept gives us a roadmap for taking a more dynamic and ongoing approach to securing our applications and services.

Let’s break some of these terms down. Security and risk are often looked at through three lenses: protect, detect, and respond. The continuous aspect tends to be focused on a runtime evaluation of some sort, typically involving another buzzword – that of context. The context normally refers to non-identity related signals associated with  login and access events.  

“Continuous” could be said to fall within the “protect” and “detect” buckets.

So what about “adaptive”? Adaptive falls into the “respond” section, where, based on the runtime context check, access to a particular resource is dynamically altered to fall in line with the accepted trust level. An example of adaptive access based on risk is redacting the price field within a database, as the end user has swapped a known corporate network to a public Wi-Fi.

From a design perspective, a CARTA pattern could be used to help implement a Zero Trust infrastructure.

So how does this all apply to identity and access management? 

Let’s look at two basic examples: login and resource access, typically known as authentication and authorization. During login, a CARTA model would see us collect a lot more information – data signals from internal and external systems – anything to help us understand who or what is attempting to login. Based on that runtime check, the first step in the adaptive access journey is triggered. We can start to tag the user with different labels.  

Those labels can then be used for further validations. For example, device assurance levels, network botnet likelihood, days since password change, risk of breached credentials,  and so on. The labels tend to get added to web cookies, OAuth2 access tokens, or even OpenID Connect ID tokens.

The concept makes a great deal of sense. If I log in to application X and stay logged in the entire time, how can we be sure that it’s still me accessing the app two hours later? What if I went to grab a snack and someone else is on my laptop?

If we capture more contextual information during the login event, we can effectively make more informed decisions throughout the life time of the user’s activity.

The approach with CARTA is to verify the context at frequent intervals, or at least every time the user attempts to access a resource. Much of this will be invisible to the end user, however.

A very basic version of this has been around for quite some time in web applications. Cookies get set with a time limit for the session, and, if you’re inactive for a defined period or come to the end of the session life, you get logged out. The thing is, that’s a pretty poor user experience. It would be quite rare to perform any intra-session validations. This is where CARTA can help.

Every time the cookie, session, or access tokens are being used, we then look to perform those transparent contextual validation checks. Looking for differences (remember the detect step) before responding dynamically.

So as the IAM platform is continuously evaluating changes and risk, what is happening? The system is evaluating the user/application context and comparing it to that initial authenticated state. As it does this, it is taking into account many inputs (or signals) – from the device you are using to the network you are on – and even behavioral signals that could be being compared in back-end risk systems.

But what happens when a difference is found? This is where the adaptive aspect comes into play. Traditionally, anything looking suspicious, either during login or resource access time, would typically trigger a blocking event – a clumsy step up or even the dreaded “Access Forbidden” label. End users, especially in the consumer world, demand better user experiences.

Being adaptive during the risk response process is critical to not only improving security but also improving user experience. Let’s look at an example. Say that, during login, we label a user as potentially using a network that has previously been involved in botnet activity.  Coupling that with using an outdated internet browser might result in an adaptive access response that involves increased audit logging for that event and a throttling of the number of hits that user can make against a protected resource or API.  

We’re not saying “no access,” we’re simply degrading access until the risk level reduces.

With the advent of more modern and capable security solutions in the IAM, authenticator, behavioral analytics, and risk analytics spaces – along with better hardware and new standards, such as FIDO, not to mention the all-powerful and pervasive smartphone, where a more fine-grained, less intrusive approach is possible while increasing the overall levels of protection for your applications and services.

As I explained in my previous blog, Zero Trust is the sensible approach to distributed applications/services as well as staff, but it is also pretty much the same approach we have already been taking with consumers. The convergence of employee and consumer use cases is also driving the need for a continuous approach to assuring the right people are accessing the correct resources at the right times.

In the constant arms race around securing and protecting your applications and services, taking a continuous approach to understanding and acting on risk is a key step forward. As with many examples across the identity and security space, context is vital and constant evaluation and reaction to the user’s context is the next logical step. 

When combined with modern approaches to strong authentication, risk decisioning, machine learning, and behavioral biometrics, CARTA is a way to increase your security posture while reducing user friction. The key to enabling these approaches is a combination of standards-based application development, SDKs for security, a wide catalogue of integrations to external signal generators and authenticators, and the engine to orchestrate it all together. For a deeper look at this, check out this webinar.