A new “signals plane” is needed to achieve zero-standing access
By Atul Tulshibagwale and Sean O’Dell
Security online is no longer a periodic snapshot of users and authorizations. We need an efficient architecture to respond to events and updates in real-time.
Background
Recently, Andi Hindle (of the Identiverse conference fame) and Ian Glazer (former SVP, Identity Product Management at Salesforce, and now President of Weave Identity) both published blog posts about how the area of identity and access management is changing to a more continuous model.
- Andi’s blog: The Era of Continuous Identity
- Ian’s blog: Misalignment and the rise of Event-Time IAM
Earlier work around the Identity Fabric popularized by Gartner defines a framework for how different identity systems could collaborate to provide more complete security coverage for all constituent users and all protected systems. Among its “Must-Have” characteristics are things like “event-based integration connectivity” and “adaptive continuous, risk-aware and resilient security”. These also point to a continuous and event-driven methodology to ensure identity security…enter the concept of continuous security.
A Paradigm Shift
All this got us thinking: we’re seeing a paradigm shift in how we think about security. It’s a paradigm where there is no single point of control—each system needs to enforce its own access security—but you still need to define centralized policies and management.
Lately, the real security action has shifted to identity and the behavior of users. The specific concern here is whether that behavior represents legitimate usage or malicious behavior, either because an attacker has assumed a user’s identity or the user themself is deviating from what is or has been perceived as “normal”.
What does this mean when all your services run independently in a zero-trust architecture? There is no central point of control, other than the login-time participation of the identity provider. Like Ian said in his blog post, the “event-time” dimension comes in after you login, and this is what leads to the “Continuous Identity” state that Andi mentions in his blog.
What Is the Continuous Security Paradigm
So let’s consider a new model more suited to today’s dynamic security requirements: the Continuous Security Paradigm. As we move forward in identity, we are emulating behavioral characteristics from the real world in the digital realm. As an example, say you are having work done on your house and have contracted with a company. The company has notified you in advance that someone named Erik will arrive at a certain date and time to do the work.. When Erik shows up at the expected date and time, do you go back and verify if Erik is employed by the company doing the work? You probably don’t. Instead, you make a decision based on context and risk. You know to expect a person named Erik to be at your home between a certain time from a certain company to perform a task. This is exactly what zero-standing access is in the digital realm. Would you always grant Erik access to your home just because of this one task that they had to perform? No, that is too risky. These same principles are why the shift to a Continuous Security Paradigm is not only needed but required.
The Continuous Security Paradigm is a system-centric view of security. Your particular application or system is one node in a tapestry of loosely coupled nodes. In addition to the usual data plane and control plane, this paradigm introduces a new “Signals Plane” of asynchronous communication, which enables event-time processing. Runtime decisions are, as expected, made in the Data Plane, but they are based on the context derived from the Signals Plane. The Control Plane defines the trust topology of the Signals Plane.
The Control Plane
Rather than viewing the network as a uniform “fabric”, the Continuous Security Paradigm models it as a loosely coupled and more diverse tapestry that captures the differences in how much each node trusts another, and who owns individual nodes. A node in such a network is not about physical or virtual connectivity as represented by Virtual Private Clouds (VPCs) or firewalls, but a logical definition of what information is asynchronously communicated (either received or transmitted) between which nodes in the tapestry. This may include nodes that you “own”, e.g., VPCs, SaaS tenants, or IaaS tenants, but it may also contain nodes that are trusted sources of public information (e.g., public securities data or dark web credential monitoring data).
The control plane is used to specify this trust topology. Specifically, how each node is connected to another with respect to the trust, entities, and attributes. For example:
- A CRM node trusts the HR node as the authoritative source for employee entities and their attributes such as their cost center.
- An application node trusts the HR node as an authoritative source for employee entities and trusts the CRM node as the authoritative source for customer entities and as a non-authoritative source for employee entities, which it correlates with the authoritative employee entity source, the HR node.
- The CRM node trusts the application node to receive customer entities and certain attributes of customer entities from it.
- The HR node trusts the CRM node and the application node to receive employee entities and specific attributes of those entities.
The control plane also specifies the frequency of ingestion or transmission of specific entities to / from specific nodes. It also specifies the policies to be applied when using information received from other nodes.
The Signals Plane
The signals plane enables each node to asynchronously collect the entities and attributes that are important to its own data-plane decisions. It also enables each node to communicate any changes to its entities and attributes that may be relevant for other nodes it trusts. The asynchronous ingestion and transmission of trusted data enables each node to decouple its runtime decisions from the availability and latency characteristics of other nodes in the network. Open standards such as the OpenID Shared Signals Framework (SSF) are designed for conveying such information asynchronously.
The Data Plane
The actual access decisions in response to API calls or user requests are done in the data plane. The signals plane enables each node to ensure that it or other nodes in its network do not make decisions based on outdated information. Yet, because the information is conveyed asynchronously, the decisions each node makes are based on “event-time”, or “continuously updated” information – without sacrificing efficiency. When a data plane event occurs, e.g., a user attempts to access specific data in a node, the policies specified by the control plane govern how the asynchronously ingested data and the runtime data from the data plane are used to make decisions.
Computation in CSP
To ensure security for an application, e.g., one node in your organization’s network, you need to:
- Obtain trusted signals about all interesting interactions/events (identities, devices, environmental factors (e.g., IP location, geo-location, etc.). Some signals are obtained from the user request, but most may be obtained asynchronously using the signals plane from other nodes
- Make your own policy decisions about granting or denying access: Your application or system needs to have its own rules to determine access and know user behavior as far as your own application is concerned
- Communicate changes to other nodes: The control plane may obligate you to communicate any changes to certain entities to other trusted nodes, at a certain cadence. Doing this enables all nodes to make decisions based on event-time data.
Why introduce a new paradigm?
We’re seeing escalating tensions on a couple of axes: Between having to constantly re-evaluate access decisions, the desired performance, and the computational impact of doing so; and between the independence and resilience of each system and the enforcement of common policies. The Continuous Security Paradigm enables independent, decoupled execution while being able to leverage the latest data, and one that enables real-time decisions without huge availability and performance requirements. It also enables independent services to be good citizens of a larger network that can both help other services make good decisions and be a part of a common trust topology.
Managing a Continuous Security Paradigm-based Network
Even though each node operates independently in terms of the decisions it makes, your organization needs to centrally manage the trust topology between various nodes and the policies that you need to comply with within each application or system (e.g., within each node). A centralized management system can use the control plane to set the rules. This is different from a central point of control for each access decision. At the same time, each node is free to dynamically modulate the trust it places in systems it receives data from, based on the quality of signals it receives from them. Diagrammatically, this can be represented as follows:
In the diagram above, all types of systems, including SaaS apps, cloud infrastructure, custom apps, and APIs, follow the same continuous security paradigm.
- All of them consume signals from other systems, make access decisions for themselves, and selectively convey signals to other systems. This is the new “signals plane” of asynchronous communication that is disjoint from the data plane or the control plane
- An organization would, of course, need to manage trust between various systems (internal or external) and would need to set org-wide contextual rules. That is provided by the control plane described by the long rectangle at the top of the diagram.
- Finally, the systems need to respond to inline requests from the client, regardless of whether the client is a robotic principal or an end-user. Access decisions need to be made for each one of these requests. This is the data plane.
Looking Ahead: The Continuous Security Paradigm in Practice
Where do we begin?
The CSP includes components that may be within your control (such as custom apps) and some that you will need support from (e.g. SaaS apps). However, keeping this paradigm in mind as you build out your strategy is key. You might find solutions that help you realize parts of this picture, and you can influence others in moving to support this architecture. For instance, building out a signals plane by adopting the OpenID Shared Signals Framework can help build out the context for your existing components – whether they are SaaS apps or custom apps.
Use Cases
The big picture here offers a way for cybersecurity and identity practitioners to think about securing systems and services in a way that supports real-time considerations. In our next blog post, we’ll break this down and discuss specific use cases where continuous security paradigms can be used today and the standards that already support this model.
Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.
Authors
Atul Tulshibagwale is the CTO of SGNL, a company backed by Microsoft and Cisco and founded by ex-Googlers that helps enterprises mitigate damage from identity breaches. Named in the Okta “Identity 25”, Atul is a federated identity pioneer and the inventor of the Continuous Access Evaluation Protocol (CAEP). He was previously at Google, where his seminal blog post kicked-off the industry-wide movement that culminated in the OpenID Foundation’s Shared Signals working group, which he co-chairs. Atul is also a Corporate Board Member of the OpenID Foundation. His leadership in developing and promoting SSF and CAEP, the critical zero-trust standards, has been influential in their widespread adoption. Apple, Okta, Cisco, and others have announced support for these standards. Previously, Atul was a co-founder and the CEO of Trustgenix, a federated identity pioneer that was acquired by HP. Trustgenix contributed to the development of federated identity standards such as SAML 2.0 and the Liberty Alliance Framework.
Sean O’Dell is a Senior Staff Security Engineer spanning both Consumer and Workforce IAM at The Walt Disney Company. He is a co-chair of the Shared Signals Working Group in the OpenID Foundation and has been on podcasts covering identity security and written about the subject…with more coming soon. He is a technical leader and trusted technical advisor to executives at The Walt Disney Company where he has been instrumental in both Workforce and Consumer IAM strategy over the past 10 years covering security, product, engineering, implementation, and architecture while also acting as a principal advisor in the same capacity for key mergers and acquisitions helping to shape overall company decisions and direction. His vision, leadership, and implementation expertise are helping to promote and drive the adoption of both SSF and CAEP overall in the industry. His current focus around identity security is zero standing privilege, next-gen authorization, ITDR, shared signals, CAEP, behavioral analysis, data science, identity data…all of the continuous aspects of identity security.
