Gartner’s Cybersecurity Mesh Architecture (CSMA) is a great framework for enterprises to organize their cyber defenses. The CSMA includes a consolidated policy management architectural component, as well as an identity fabric component which includes externalized authorization management. Together, these two components provide an architecture for enterprises to effectively manage access policies to infrastructure and applications.
While Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) provide a good baseline for access management, they need to be complemented with a more dynamic, policy driven access management strategy in an effective cybersecurity mesh architecture. Just-in-time Access Management (JITAM) can effectively fulfill this need.
Role-Based Access Control
RBAC is used very commonly across enterprises. It is used at the infrastructure level to control access to resources and managed services, and at the application level both in terms of determining who has access to which applications, and within an application to determine who has, say, “power user” privileges.
Any authorization architecture involves at least one Policy Decision Point (PDP) and a Policy Enforcement Point (PEP). If the PDP is in a software component that is independent of the software component that enforces the decision, then we can say that the authorization is externalized.
RBAC can be externalized, but more often than not, the application will directly read from a role / group directory to determine access privileges. As a result, the PDP and PEP are most often combined to be within the application in RBAC. At the infrastructure or managed services level, access decisions are based on configurations that may be independently managed.
Externalized Authorization Management
Externalized Authorization Management requires that applications do not make authorization decisions solely on their own. Instead authorization decisions should be delegated to a centralized PDP. In a real-time enforcement scenario, this PDP provides real-time decisions to the PEP, which is still the application.
Externalized Authorization Management may also be applied to infrastructure such as storage buckets, VPCs and SaaS or other managed service configurations. In this case, the enforcement is often not real-time, but based on configurations updated frequently by the PDP based on updated policies
Centralized Policy Management
How the PDP makes a decision to authorize specific accesses, is the realm of the policy framework.
In systems that support real-time enforcement, the access context of a specific request is the input to the PDP, which then tries to find a justification why that access should be allowed or denied. In other systems, the policy may be distilled into configurations that are published to the appropriate resources or services that make decisions by directly consulting this configuration.
Where do RBAC and ABAC fall short?
RBAC has been the “go to” technology for authorization controls in most organizations. Recently, ABAC has complemented RBAC by providing finer-grained authorization over just roles. However, these techniques create “privilege sprawl” over time, which makes access to applications and within applications less secure than desired in most cases. Learn more in this related blog post which goes into further detail on these issues.
Commercial Plane Analogy
To draw on a real-world analogy that explains the difference / limitations of RBAC and ABAC, let’s think about what it takes for a commercial airline pilot to fly a plane. If we were using just RBAC, then the airline policy would simply be “If one is hired as a pilot, they are allowed to fly any plane”. With ABAC, the policy could be more fine-grained, e.g. “A pilot certified to fly a Boeing 737 is allowed to fly that type of aircraft”.
If we were using just RBAC, then the airline policy would simply be “If one is hired as a pilot, they are allowed to fly any plane.” With ABAC, the policy could be more fine-grained, e.g. “A pilot certified to fly a Boeing 737 is allowed to fly that type of aircraft”
However, RBAC and ABAC lack the richness required to capture the real world policies…
However, RBAC and ABAC lack the richness required to capture the real world policies like “An employee currently on duty as a pilot may fly the aircraft assigned to flight 2157 from EWR to SFO at the specified time of the flight if they are assigned to fly that particular flight and have a valid qualification to fly that type of aircraft”
Just-In-Time Access Management
JITAM is actually able to realize the above rich policy, by taking an innovative approach that provides least-privilege access.
Just-In-Time Access Management (JITAM) includes four primary features
- Dynamic Graph Directory: Data is continuously fetched from systems of record, such as HR systems, ticketing systems and CRM systems (in addition to the usual IdP and directories), and ingested into a graph that captures the up-to-date relationships between entities and sanctioned activities in an organization
- Rich policies: Because the underlying graph data structure is far deeper than a list of “tuples”, policies can be expressed far more richly. For example, a policy may be written as “A customer’s data may be accessed by a user in the customer service department only if the user or one of their direct or indirect reportees is assigned to an open support case that relates to that customer”
- Real-time enforcement: Since the graph has a rapid response time to most queries (order of milliseconds), it is possible for applications to provide the real-time access context and check whether access should be permitted with reference to the latest data in the graph
- Comprehensive audit: Since every decision is made in real-time, it is logged with specific details such as the policies that allowed or denied the access and the parameters of the access that failed or matched the policy
In summary, JITAM is a “defense-in-depth” strategy, which takes into account current activities and current data in systems of record, and overlays that information on top of the normal role data to provide least-privilege access.
In summary, JITAM is a “defense-in-depth” strategy, which takes into account current activities and current data in systems of record, and overlays that information on top of the normal role data to provide least-privilege access.
Comparison with ABAC
In theoretical terms, JITAM could be considered ABAC: In our airline example, you could define an attribute for each flight-aircraft combination and match that attribute with computed values derived from the source data (flight assignments, schedules, certifications, duty hours, etc.). However, as you can probably imagine, this is not a great fit on the PDP side. JITAM can coexist with ABAC on the PEP side where the PEP performs real-time access checks. So an existing implementation that checks policy with an ABAC PDP could in principle, still work the same after the ABAC PDP is replaced by a JITAM PDP
Zero Trust Maturity
JITAM is a technology that provides the most control to organizations that are on the zero-trust adoption path.
Just-In-Time Access Management (JITAM) is a technology that provides the most control to organizations that are on the zero-trust adoption path.
Zero-Trust Architectures (ZTA) began with the dissipation of the “trusted network” behind the firewall, enabling users to access cloud services from any trusted device, after authentication as a legitimate user.
Evolving Attack Vectors
Before ZTA, the network perimeter formed the focus of most of the attacks, and consequently, heavy investments in securing this perimeter were warranted. With most cloud-based services running over infrastructure shared by thousands of organizations and managed by leading technology companies, the more tempting target for attackers is to compromise a specific organization’s system. The easiest way to do this is often compromising the access that legitimate users have to such systems.
The plurality of user types and the and how they protect their accounts has made this a lucrative target. Even after organizations enable multi-factor-authentication (MFA), attacks such as cookie or token theft can enable attackers to compromise enterprise user sessions.
Even after organizations enable multi-factor-authentication (MFA), attacks such a cookie or token theft can enable attackers to compromise enterprise user sessions.
Applications enable ordinary business users to all types of access to enterprise assets, and as a result, such a compromise can wreak enormous damage. And in the post-pandemic world, with a hybrid and an extended workforce consisting of vendors, temps and contractors, the opportunity and motivation for compromise is virtually limitless, both for attackers posing as business users, and for malicious insiders.
JITAM Minimizes the “Blast Radius”
JITAM increases the control that organizations can exercise both within internal apps and over 3P SaaS apps automatically in response to enterprise activity such as ticket assignment changes or organizational changes. As a result, a user account or session compromise or a malicious insider can only access application functionality that is justified through sanctioned business activity.
The following diagram captures this evolution:
