In both cases, the process is similar. A certificate authority establishes itself in the marketplace, and others (content owners) come to it to obtain a credential, token, or certificate that they can provide to a content user as proof of the content owner's trustworthiness. Content users can then challenge the content by requesting a verification or authentication service from the certificate authority. Certificates issued by a certificate authority can, in some circumstances, in effect delegate authority to a subordinate.
Zero Trust Architectures
In late 2020 the information security profession began a major paradigm shift away from focusing on defense in depth and its association with trust but verify (or verify at initial access, then trust until end of session) as the dominant metaphor. Zero trust as a set of concepts focuses instead on protecting data assets first and foremost. NIST published its SP 800-207 Zero Trust Architecture (ZTA) as a reference and guide in August 2020; a number of vendors have begun providing implementation roadmaps that use this, and in May 2021, the US Defense Information Systems Agency published its zero trust reference architecture. All of these represent snapshots in time of a rapidly evolving set of concepts, ideas, strategies, and tactics.
NIST SP 800-207 describes a ZTA as one that demonstrates the following design tenets:
Data and computing services are treated as resources to be managed and protected.
All communications are secured regardless of network (or physical) locations; trust is not implied by where on the network it originates.
Resource access is granted on a per-session basis, with requestor trustworthiness being evaluated with each access request, and granted with least privileges.
Dynamic policies based on observable behavior dictate access control decisions.
Integrity and security posture of all owned and associated assets is measured and monitored by the system's owners and administrators.
Strict enforcement of authentication and authorization, including on a continuing basis, is required for all access attempts.
Systems owners and administrators continuously monitor systems, network infrastructures, communications, and asset security posture, and use this information to continually improve security posture.
As an individual person, you are an entity; you then use multiple identities, which are the dataset that an organization or its systems creates and uses to bind to your assertion as an entity of who (or what) it is to the sets of privileges that organization chooses to grant to you. Systems like just in time identity provisioning and identity as a service require us to keep the concepts of entities and identities separate and distinct. Logging into your systems at work involves multiple entities—you, the endpoint device you're using, the applications you're using, each of which are part of fulfilling your purpose for accessing the system. Traditional views of identity management treated entities and human user identities as separate problems; zero trust architectures and systems like user and entity behavioral analytics (UEBA) bring them back closer together.
PARTICIPATE IN THE IDENTITY MANAGEMENT LIFECYCLE
Traditionally, identity management has only been thought of in terms of human users. With the publication of the Open ID 2.0 standard, it's clear that identity management has to embrace both human users (the traditional subjects of access control and identity management) and nonhuman users such as the devices people use, autonomous mobile systems, IoT devices, bots, and other software entities. As of this writing, we do not have an “entity and identity” management lifecycle, but this will have to change as more organizations go towards zero trust architectures and their need to identify, track, and model the behavior of all entities, human or non, that are attempting to access their resources.
Identity management is often described as a set of major functions, such as provisioning, review, and revocation. These actually involve a number of more fine-grained tasks at the detailed level, by which systems administrators do the following:
Create a new identity.
Determine which systems and assets that identity should have access privileges to.
Determine what authentication factors, including what security tokens or devices (company-owned, employee-owned or BYOD, or a mix of both) will be used for access and for work-related functions.
Provision that identity into those systems.
Review those privileges as circumstances, on-the-job duties and responsibilities, or business needs evolve.
Add, modify, or revoke some or all privileges as required.
Suspend or revoke an identity.
Delete the identity from active systems.
From this list, you can see that creating and provisioning an identity creates the data that drives your authentication and authorization processes; accounting then links this new identity to the transaction-level history of access attempts and their results. Accounting data is then used during privilege review.
Previous sections in this chapter have looked at authentication in greater detail. Let's look further at some of the other identity management tasks and processes.
Authorization
Every access attempt by a subject should test that subject's identity in two ways: first, by authentication of that identity, and second, by testing what the subject wants to do to see whether it is authorized to do so. Prior to the first access attempt, administrators must decide which permissions or privileges to grant to an identity and whether additional constraints or conditions apply to those permissions. The results of those decisions are stored in access control tables or access control lists in the access control database.
Authorization systems use one or more of the concepts known as access control models. These models, such as role-based, subject-based, or attribute-based, translate your information security choices about information classification, and the relative importance of integrity versus confidentiality (think Bell–LaPadula versus Biba), into which technologies you choose and their implementation details. These models were examined in some detail in the “Access Control via Formal Security Models” section. You'll need that conceptual foundation as you look to the “Implement Access Controls” section later in this chapter for more practical guidance.
Whatever identity management and access control scheme you select, you will need to ensure that it has the following attributes:
Fast in operation: Logic that is involved in every decision on the network must be crisp. Keep in mind that, usually, simpler principles lead to faster execution.
Scalable: Whether you need to control hundreds of assets or billions, you will want to use the same basic approach. Most enterprises, especially successful ones, grow and change and sprawl and spurt. You do not want your access scheme to hinder growth.
Comprehensive: It is not always possible
