Many organizations hear from vendors, thought leaders, and perhaps strange women lying in ponds who distribute swords that they need to get to “Zero Trust.”  Zero trust as a marketing term has exploded over the past few years, and it feels like everywhere you look, the term is being used, but very little is being said on what it means—and indeed, what it means to identity. It would be prudent then to understand what is meant by zero trust, select a model that provides a basis by which a zero trust architecture may be achieved, and dig into the ramifications of the model chosen for identity.

What is Zero Trust?

Zero Trust is broadly defined by many sources. For instance, Gartner couches Zero Trust within the context of networks, stating, “Zero trust network access (ZTNA) is a product or service that creates an identity—and context-based, logical access boundary around an application or set of applications.” The UK’s NCSC also defines it within this context of networks-—they offer that “A zero trust architecture is an approach to system design where inherent trust in the network is removed.” If we are to believe NIST SP 800-207 (Zero Trust Architecture), it is “the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.” Given the spread of definitions, we should look to synthesize these definitions to provide a holistic perspective.

• Zero trust seeks to eliminate implicit trust.
• Zero trust seeks to make access determinations that are identity, context, and resource-driven.
• Zero trust seeks to move past using static network configurations as a defense.

What is Implicit Trust?

Implicit trust, put simply, is where actions taken between systems, users, and other resources are allowed due to some facet of their relationship with each other. In an extremely simple example, a database within a traditional, organizationally managed data center may have a line of sight from a network perspective to hundreds of other systems because of the tasks the database helps those systems perform. These in-datacenter systems may have a common set of administrators, and one of these administrators may have access to a laptop that uses a VPN client to get into the data center remotely for management, specifically that database. These systems then share a tremendous degree of implicit trust- an attacker who gets access to the administrator’s laptop could potentially do immense damage to a number of systems because each system in the chain has put some degree of faith in the next one down the line. Ransomware, in particular, exploits implicit trust, utilizing whatever tools it can to move laterally within an organization to cause as much damage as possible.

What Do Zero Trust Folks Mean When They Say “Identity,” “Context,” and “Resource”?

When we speak of identities in a zero-trust context, we refer to both traditional users (as in people) and non-person entities (such as machine accounts used for programmatic access). These identities must have appropriate context, meaning they must meet specific conditions (e.g., time of day, location, compliance to specific requirements identified by the organization, attributes, role-based access signifiers, etc.) to perform a given operation. Resources are objects an organization possesses that are subject to access determinations, such as applications, workflows, systems, assets that respond and conform to logical access (such as doors), and so on. We describe all of this to indicate that a user, in certain contexts, has access to perform actions on specific resources.

What Happens to the Network?

The network, as we understand it, still exists. However, the focus shifts from hardening the perimeter of a network to securing resources. Typical implementations focus on identities sufficiently authenticating and having sufficient authorization (by having appropriate context), with these entitlements being dynamic and assessed continuously such that if the identity no longer meets requirements, access is terminated immediately; if the identity is sufficiently authenticated and authorized, it is allowed access to the resource for that specific interaction. Each interaction with a given resource requires a new and separate assessment; prior successful assessments do not indicate future success. The common terminology used for the interaction of identity to resource under this model is “microsegmentation”—to effectively construct a network segment from resource to resource and dynamically assign it based on context.

What Models Are There of Zero Trust?

While vendors quickly provide their own view of zero trust, few (if any) have provided comprehensive models that outline critical functions necessary to achieve such a state in a distributed computing environment. Various countries and blocs, such as the UK and the EU, have offered either broad guidance (https://www.ncsc.gov.uk/collection/zero-trust-architecture) or pay lip service to it in reports (https://www.europarl.europa.eu/doceo/document/A-9-2021-0313_EN.html) but few government-sponsored and independent reference models have been put forward. The US Government has offered some guidance on this across its agencies, notably NIST by way of its work in the NCCoE (https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture) as well as NIST SP 800-207, and the Department of Defense with its Zero Trust Reference Architecture (henceforth the DoD ZTRA). While all of the NIST SPs are great reading on this subject, let’s focus for a bit on the DoD ZTRA.

An Extremely High-Level View of the DoD ZTRA for Identity

The DoD ZTRA asserts that zero trust’s goal is to protect data. It does this through the interrelated nature of six separate focus areas: User, Device, Network/Environment, Applications/Workload, Visibility/Analytics, and Automation/Orchestration. The DoD ZTRA asserts that conditional authentication and authorization are critical to each focus area and provides a figure that offers capabilities related to those areas. See Figure 1 for their highlighted capabilities.

Figure 1: Authentication and Authorization Capability Taxonomy. Source: DoD ZTRA

A point that the DoD ZTRA really drives home with this figure, as well as the other capability taxonomies and capabilities outlined, is that authentication and authorization need to be driven into every decision possible, as close as possible to the point of decision. These authentication and authorization decisions need to be constant, fine-grained, adaptive, and provide rapid mechanisms for restricting access should it become incongruent with a user’s standard use patterns.

The DoD ZTRA indicates that a service external to the previously mentioned focus areas, known as the “Enterprise Identity Service” (EIS), should be utilized at the control plane to facilitate this. The EIS is made up of three capabilities: the Enterprise Federated Identity Service (EFIS), Automated Account Provisioning (AAP), and the Master User Record (MUR). At a high level, these capabilities map to federated authentication and authorization, identity governance/lifecycle management, and the aggregation of contextually important attributes for a given entity (person or otherwise) for the purposes of driving those authentication and authorization decisions. Examples include credentials, roles, attributes defining access classifications, policy/context-driving attributes (such as a risk score for a given user), and so on.

This begs a question of scale: is the DoD ZTRA meant to construct one system to rule them all?  Not necessarily. To quote the DoD ZTRA on this, “DoD enterprise ICAM service providers provide one or more services that support ICAM capabilities. A service is defined as DoD enterprise if it can be used by anyone across the DoD, and, for externally facing federation services, by any DoD mission partner”. The document goes on to define requirements for these service providers, as well as DoD component organization requirements. Ultimately, there will be many implementations of an EIS across the DoD. In these many implementations, they will be able to best meet the needs of the mission while still conforming to the goal of eliminating implicit trust wherever possible.

A goal of this externalized service is then to be reusable and interoperable- while the DoD does not provide specifics around each service, it is to be assumed that an EIS for a given DoD organizational component should be able to communicate effectively to every other DoD organizational component and mission partner as it needs to. If this were not the case, the DoD would be back to building stovepipe systems- systems with limited scope and function, possessing data that, by the nature of the system, is difficult to use outside of the system. Identity commonly falls into this trap, where a given system owner may wish to implement their own flavor of an identity capability with a custom schema or custom relationship model.

In Summary

There should be minimal surprise when we see that the DoD ZTRA offers no revolutions in security or identity thought. It is instead a synthesis of practices that identity and security practitioners have been pointing towards as being critical for years. Whether the people who perform integrations across the federal government take this guidance to heart remains to be seen. It is this author’s hope that given time and appropriate space the DoD ZTRA will not act as the final word on the topic but is merely the beginning of the conversation with respect to integrating sound identity practices into large and distributed organizations.

Author Bio

Rusty Deaton has been in Identity and Access Management for over a decade. He began in technology as a technical support engineer for a Broker-Dealer and has since worked across many industries, carrying forward a passion for doing right by people. When not solving problems, he loves to tinker with electronics and read. He currently works as Federal Principal Architect for Radiant Logic.

The post The Identity-Driven Reality of Zero Trust appeared first on IDPro.

Identity and Human Rights

The Universal Declaration of Human Rights enshrines the concept of recognition as a person before the law as a fundamental human right. Digital identity is a new aspect of that fundamental right, a topic covered by Elizabeth Garber and Mark Haine in the white paper “Human-Centric Digital Identity: for Government Officials.” This right has also inspired the United Nations Development Programme (UNDP) Model Governance Framework for Digital Legal Identity System. 

Source: UNDP Digital Legal ID Governance website – https://www.governance4id.org/ 

Digital Identity and the United Nations

It might seem like a big stretch to go from our day-to-day worries about our IAM systems to a governance framework designed for governments worldwide to adapt as they build their digital identity programs, but it’s happening. The UNDP argues that there is a significant social and economic benefit for governments to digitize their identity programs and close the identity gap. Just in financial services alone, a strong digital public infrastructure is expected to speed up growth by 20-33%. 

Think about it. Our little corner of the world, which focuses on a specialty so young you almost certainly don’t have a degree in it, is now a core aspect of global economic growth!

Eight Core Themes

So, what does the UNDP’s framework look like? As expected of the UN, they are taking a broad approach that considers all elements of society. Specifically, they offer guidance on:

• Equality and Non-Discrimination
• Accountability and the Rule of Law
• Legal and Regulatory Framework
• Capable Institutions
• Data Protection and Privacy
• User Value
• Procurement and Anti-Corruption
• Participation and Access to Information

The UNDP model comes from their legal identity AND digital public infrastructure efforts, which is the right combination of organizations to bring together. Digital transformation is a bit of a buzzword, and yet, that’s what is happening. The UNDP is trying to help provide some guidance so countries are at least somewhat going in the same direction. They’ve already noted that there are at least as many failed identity programs as successful ones, usually because of inadequate governance. 

Digital identity always comes down to governance.

Applying the Framework

We can always learn from others, and we have an opportunity, regardless of what sector we work in, to learn from the UNDP framework. While targeted towards governments and civil society, there is quite a bit here that the public sector can apply to their IGA programs. The need to take into account as a foundational principle the need to support equity and diversity is one example. Another is ensuring the systems and programs are adequately funded and clear of undue influence. 

Wrap Up

So why is this a Letter from Leadership post (which we’re also posting to the blog)? Because identity governance is our space and everyone in this organization has an opportunity to be a leader in ensuring the identity programs they are part of are well-designed and developed. So, as one leader to the next (that’s you), I hope you take a few moments to think about this bigger picture and how you can make the governance of the identity systems around you better.

Author

Heather Flanagan, Acting Executive Director and Principal Editor for IDPro (and Principal at Spherical Cow Consulting) comes from a position that the Internet is led by people, powered by words, and inspired by technology. She has been involved in leadership roles with some of the most technical, volunteer-driven organizations on the Internet, including the IETF, IAB, and IRTF as RFC Series Editor, ICANN as a Technical Writer, and REFEDS as Coordinator, just to name a few. If there is work going on to develop new Internet standards, or discussions around the future of digital identity, she is interested in engaging in that work.

The post Identity and Human Rights appeared first on IDPro.

Background

The true beginning of scientific activity consists rather in describing phenomena and then in proceeding to group, classify and correlate them.

Sigmund Freud

Identity and Access Management (IAM) systems have become critical in ensuring the security of enterprise applications. In the good old days of the on-premise / co-located data center, an enterprise could easily implement perimeter-based security – one where you would build a castle and a moat around your prized assets and then control the ingress & egress points to provide a reasonable security posture. The majority of access was granted to humans. Every human was given the appropriate level of access according to their job role, and everybody lived happily ever after… that is, until a dark cloud of disruption rained on the perimeter-based security parade. We are, of course, referring to the advent of cloud technology.

With a cloud-first approach, enterprises now have a significant portion of their prized enterprise assets and data deployed outside of their traditional data centers. Enterprises are shrinking their on-premise footprint and running workloads in the cloud. Identity, not network, is the new perimeter. One of the interesting aspects of this seismic shift was the rise of Infrastructure As Code (IAC) and, by extension, non-human accounts that manage the infrastructure. It is also not unusual to have cloud systems with thousands (if not tens of thousands) of permissions. This led to a proliferation of roles, and it became clear very quickly that the orthodox job role-based approach to access control needed adjusting.

Another unfortunate side effect of the identity-based perimeter approach was the rise of identity-based threats. A vast majority of breaches can be traced to compromised credentials and over-privileged accounts. It is becoming abundantly clear that an access control methodology that is dynamic and can evaluate access continuously based on risk signals in real-time is the need of the hour and a cornerstone of Zero Trust Architecture. Identity professionals responded to the challenge, and a variety of authorization and access control methods and corresponding ecosystems have developed. This is our attempt to enumerate these access control methods, categorize them, explore relationships between them, and, most importantly, provide guidance on how to choose your authorization system.

How to choose your next authorization system?

As highlighted in the preceding section, organizations need to shift their focus from old/legacy authorization models and systems to new ones capable of coping with today’s problems. This is not easily done when an organization’s whole infrastructure has evolved into its current state over a period of years or even decades… One therefore faces the two following questions right away:

• What authorization model or language to even choose to face these challenges?

We will answer these questions by first providing a Taxonomy of modern authorization models and then using it to provide some answers.

What is an Authorization Model?

Authorization systems are made of several complex components. Typically, an engine that makes access decisions, along with some other systems whose roles are to execute the decisions made by the engine or to fetch the data necessary for the engine to reach its decisions.

Our goal here is not to list all possible architectures of such systems or to describe them but rather to focus solely on the Policy Engine itself, which is at the core of the Policy Decision Point (PDP). Any PDP uses at least one methodology to compute its decisions. We call these methodologies for building PDPs “Authorization Models,” and the following sections describe a taxonomy of such Authorization Models.

What is a Taxonomy?

In simple terms, it is the science of naming and classifying things. To the authors’ knowledge, this hasn’t been done yet for authorization models, even though there is a great deal of confusion throughout the industry about the various ways authorization can be implemented. Each category in a Taxonomy may have subcategories, but it is important to note that the things being classified may belong to several categories at the same time. Objects can therefore be duplicated under several branches of the Taxonomy Tree if it makes sense (for example, consider a taxonomy of fish: salmon would be present under both the “Ocean” and “River” categories…).

A Taxonomy of Authorization Models

The first question when creating a taxonomy is to choose the right categories. This may be a contentious subject, especially in the field of authorization, given the enthusiasm of the Authorization community (the #Authorati) and the fact that there could be many ways to go about it. In the end, we opted for a set of categories that met the two following criteria:

1. The categories, and the Taxonomy in general, should be helpful to all and not just serve a small community of specialists. In particular, it should help any Identity practitioner in making implementation decisions based on real-world criteria.

2. It should cover all the existing models by avoiding duplicates as much as possible, as well as be easily expandable to any new, not yet invented models.

Figure 1 below depicts our proposed Taxonomy of authorization methodologies.

Figure 1 – A Taxonomy of Authorization Models

Level 1 – Centralized vs decentralized control

All models described here involve some kind of rules, even the simplest of them. The first categorization is to distinguish between those models owned and maintained by the owners of the Resources being protected  (DAC branch) or whether these rules need to be centralized and administered by specialized administrators in a central location – see the Mandatory Access Control (MAC) branch. We find here our first authorization models

DAC branch:

• ACL: Access Control Lists, the oldest of all and the first model introduced through the Multics OS in 1969. Here, a resource owner maintains a list of all the subjects allowed to access any given resource they own, along with the type of access granted (typically read, write, or delete). Popular in operating systems such as Unix or in LDAP Directories.

• FGA/Zanzibar: Fine-Grained Access Control (FGA) solutions are all inspired by, or implementations of, the Google Zanzibar paper published in 2019. The paper describes Google’s own authorization model used throughout its various tools and offerings. Like ACLs, FGA solutions require resource owners to maintain “tuples” (text strings, essentially) that describe the type of access any subject may have to their resources. Because of the considerable amount of tuples potentially required by such a system, they are best suited for DAC applications (which is also Google’s use case).

• ReBAC: Relationship-Based Access Control (ReBAC) is an approach that uses the paths between subject and resource nodes in a data graph in order to determine access. Access is granted if such paths exist. ReBAC uses native graphs and requires a proper Graph Database store (more on this further). Note that ReBAC can be used for both DAC or Mandatory Access Control (MAC) applications.

Note: We make a distinction here between FGA systems and ReBAC: we view these as different models altogether. Although FGA tuples describe a graph, those tuples are not stored in graph databases but are rather strings stored in SQL or custom databases. On the other hand, ReBAC systems use graph databases and express policies as Graphs, not as programming languages. This means that path traversals and tooling are vastly different between those systems. A Graph-based ReBAC policy is therefore an image/diagram and not a block of code, as is the case for FGA systems.

Level 2 – MAC Models

Centralized access policy models are of two kinds: those that can be context-aware and can implement environmental or other contextual conditions and those that are ignorant of context. The contextual conditions can be based on date and time, locations, or even specific attribute values.

Level 3 – Context-Aware models

At this level, and on the context-aware branch, we find two subcategories. Here, the authorization models can be based on rule sets or instead use relationships between entities in order to compute access. Relationship-based systems are graph systems.

Graph Approach

Graphs can implement two types of context-aware models:

• Next Generation Access Control (NGAC), which is an ANSI Standard (* See: https://webstore.ansi.org/standards/incits/incits4992018 ). Look for NGAC-compliant systems that provide no-code / low-code interfaces.

• Risk and Behaviour-Based Access Control (BeBAC): a model by which subjects’ behavior is tracked as a graph, and baselines established for acceptable behavior. These systems can then apply graph pattern-matching or graph analytics techniques to find outliers and thus compute the risk of any given access request.

Another common technique here is to compute the risk score of a given user/entity (similar to a ‘FICO score’) and calibrate ‘access credit’ based on the user/entity risk score, the nature of the request (e.g., privileged v/s nonprivileged) and the type of object/resource that is being accessed. For instance, a user/entity may be denied privileged access to a resource (such as a high-risk PCI database) if their risk score passes a certain threshold (the equivalent of an ‘Excellent’ FICO score due to recent activity that falls outside of the established behavioral norms for the user/entity).

Rule-Based Approach

The non-graph approach is more traditional and, in the case of some vendors, has been available since the beginnings of ABAC and the XACML standard. In this approach, the access policies are defined by a set of programmatic rules, defined either using modern authorization languages or through solutions that provide more business-friendly front ends. The rules combine Subject and Resource attributes with environmental conditions in order to compute a logical decision.

At this level, we find:

• Authorization languages: Any specialized language that can express access policies using attributes and their values. We find some standardized languages (XACML, ALFA) and as well as some vendor-specific ones (the others). These languages let developers typically implement their own flavor of ABAC/PBAC (see below).

• ABAC / PBAC: Attribute/Policy-Based Access control systems. These systems implement ABAC without a language per se; they rather rely on tooling and/or GUI widgets to help or guide users during the creation of the policies. Note that the authors believe ABAC and PBAC are synonymous in that all ABAC systems also need to define and manage policies.

• Risk and Behaviour-Based Access Control (see definition above).

• Organization-Based Access Control (OrBAC): A model driven by the subject’s and Resource’s membership to an organization. This can be based on business units within a company or even on different organizations altogether. OrBAC uses dynamic rules and context, as well as a hierarchy of Organization, Role, Activity, and View in order to determine access to its resources.

Level 3 – Context Agnostic Models

On this side of the tree, the authorization models don’t support the use of any environmental conditions. These are easier models to use and understand, but they are also much more limited. The two sub-branches here refer to the way to group Subjects and the Resources they try to access.

On the Set-based branch, subjects and resources are grouped together by some common factors, such as users sharing the same semantic role, security level or organization. The other side is, again, relationship-based and uses graphs to determine access.

Note that the set-based approaches are all prone to rule “explosions”: over time, the number of sets increases to the point where it eventually becomes very difficult to certify with certainty the access of subjects to all resources.

Set-Based Models

We find here:

• Role-Based Access Control (RBAC): in use since its creation in 1992 by NIST researchers, this is still to this day the most popular (by far) Access Control model. Users are placed in roles; each role is granted a set of entitlements over resources.

• Lattice-Based Access Control (LBAC): Uses the mathematical concept of lattices to define the levels of security a subject may have and may be granted access to. The Subject can thus only access any given Resource if their security level is greater than or equal to that of the protected resource.

Relationship-Based Models

Here we find only ReBAC, which can also be used with centralized control. Generalizing in a graph is easily done by just adding intermediary nodes. Adding extra hops can make ReBAC less fine-grained and, hence, easier to handle and manage.

How to choose?

Figure 2 below represents a decision tree that can be used to help choose the right model. Simply answer some basic questions to follow a path in the tree to a leaf node.

Figure 2 – An Authorization Decision Tree

Conclusion

This publication is the authors’ attempt to provide a first cut of a taxonomy model for authorization. Without taxonomy, we’re explorers without a map, scientists without a method. It brings order to chaos and meaning to complexity. As the saying goes, all models are wrong, but some are useful; we hope that readers will find the taxonomy model useful in disambiguating some commonly used terms, putting them in context, and simplifying complexity. We fully expect the taxonomy and the decision tree to evolve over time to meet the needs of the changing technology, threat, and business landscape. The accompanying decision tree can be a very useful tool in the Identity professional’s toolkit to aid in the selection of an authorization model that is appropriate for the business case. So the next time you are wondering which authorization model to select for your application, go ahead and use the taxonomy and the accompanying decision tree to guide your selection.

Authors

Alex Babeanu

 Alex leads the research and development of 3Edges, which created the best and easiest to use Graph platform on the market, specifically built for graph-aware dynamic authorization. His past experience includes building pieces of the Oracle Identity Manager server as a Principal at Oracle, and over 10 years spent as a consultant in the field, architecting many solutions for public and private organizations in all verticals.  Alex holds an MSc in Knowledge Based Systems from the University of Edinburgh, UK, and is an avid Sci-Fi enthusiast.

Tariq Shaikh

Tariq is an Identity Architect, Director & Distinguished Engineer at Capital One. He has 25 years of technology experience and a passion for developing innovative technology solutions to solve cybersecurity problems. Prior to Capital One, Tariq led the Cloud Identity & Access Management (IAM) and Privileged Access Management (PAM) initiatives at CVS Health.  He started his career as a software developer before taking on cybersecurity leadership & advisory roles. He speaks and posts extensively about Identity & Access Management topics.

The post A Taxonomy of Modern Authorization Models appeared first on IDPro.