Asad Ali | Director of Strategy
In the spring of 2019, if you were to stroll through the vast exhibition halls of the Moscone Center during RSA Conference, you would be overwhelmed by the sheer number of booths - some crammed for space and some with room to spare. Regardless of their size, they were all selling the same thing; security. This was expected. However, what was not expected was that they all seemed to have gravitated towards two overarching security themes of zero-trust and machine learning. These terms have become buzz words in the industry and taken on a larger than life persona. This pull is either because vendors truly believe in these technologies and see them as saviors of our digital security problems, or because they just realize the gold rush has started and they don’t want to be left behind. It was hard to determine which vendor fell into which camp.
Coincidently, around the same time Atul Tulshibagwale, an engineer at Google, published a blog that introduced Continuous Access Evaluation Protocol (CAEP) as a new way of thinking about federated identities, and offered a possible solution to perform continuous authentication and access. On the surface this may appear to be yet another attempt to achieve seamless access management. However, the industry response was positive and very swift. In less than six months, a dedicated working group was formed in the OpenID Foundation with support from major identity and security players such as Amazon, Cisco, Duo, Microsoft, Okta, Ping, SailPoint and Thales. One reason for this quick adoption was the allure of the two dominant themes we saw at RSA Conference; zero trust and machine learning. CAEP can, in fact, help deliver zero trust by utilizing machine learning capabilities.
What is CAEP?
The main premise of CAEP is based on a limited publish and subscribe model, where subscribers express interest in information available through publishers. A publisher will broadcast changes in session and user information as update events to all those who are interested in them. The interested parties are of course the subscribers who have expressed interest in such information. CAEP defines a standard protocol for how this “express interest” handshake takes place and how the update events are exchanged. These events represent context signals about user activities on various end points and servers. Collectively, they represent a very rich set of data that a single entity (e.g. a bank) cannot collect unilaterally.
But really, what is CAEP?
To illustrate this point, let us look at how we currently grant access to a resource, and how it would change with CAEP. Figure 1 shows a typical flow of how a user accesses an online resource, and Figure 2 shows how this flow changes when CAEP is introduced.
The four steps in Figure 1 are as follows:
1. A user requests service from a relying party through a device or app.
2. The relying party checks the context of this request.
3. The replying party then applies a policy to this request, given the context.
4. Finally a service response is generated. The relying party either allows or denies the service request received in step #1.
These steps assume that the replying party is able to apply the right context to the request. This context could be based on past user actions, interactions with other systems, the nature of the current request etc. It is not possible to capture all of these through a single entity; the relying party. As such this context is narrow and based on limited visibility of user activities. On the other hand the CAEP model uses input from multiple sources to build a more precise security context for the user. In this model, not one but multiple relying parties and identity providers share their updates about user behavior so that any of these relying parties can make a more precise decision about whether to grant or deny access.
Figure 2 shows the steps in such a flow, as described below:
1. A user requests service from a relying party through a device or app.
2. The relying party publishes unusual activity about the user and asks other participating nodes if they have any such information about the user.
3. The policy service collects this information and publishes to all subscribers.
4. The relying party either allows or grants access based on its own interactions with the user as well as on a collective understanding of what the user has done with other applications or relying parties.
This resembles Zero Trust
Yes, you are right. This fine grained access control based on current context is what zero trust is all about. That is, instead of checking user access once at the perimeter, do it at every access while considering the most current context. In order to collectively build this context, participating entities can either build proprietary protocols, (which will be hard and have limited adoption) or they can use a standard way. CAEP promises to be that standard protocol.
Standardization
Work on CAEP is being done under the Shared Signals and Events (SSE) working group in the OpenID Foundation. We expect to have a first draft of the specification available by early Q4 2020. Thales is an active member of this working group, and is one of the editors of the Use Case and Scenarios document, while also contributing to other specification documents.
What Next?
You may also be wondering about machine learning? Well, machine learning is the “secret recipe” that would differentiate one CAEP implementation from the other. Agreeing to follow CAEP and participate in a publisher-subscriber model will only get you a seat at the table. To ensure your voice is heard, you will have to convince customers how your CAEP implementation is superior to others, how it can filter out noise and unwanted events and signals better, and how it can provide a more seamless zero trust experience. The more superior your AI/machine learning based risk engine is, the more CAEPable (a favorite pun of CAEP working group members) you will be. Of course only time will tell if CAEP is the panacea we are looking for, but for now it has the backing of all the right players, including Amazon, Google, Microsoft and, of course, Thales.
I would encourage you to attend an upcoming webinar, Securing Cloud Security with Continuous Access Evaluation Protocol, on Thursday, Sept. 24 at 8:00 a.m. PDT where I will discuss this topic with my very CAEPable friend Atul Tulshibagwale from Google.