The Official (ISC)2 SSCP CBK Reference. Mike Wills

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.

       How Useful Is Your Identity Management and Access Control System?

      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 to subsume all of an enterprise's assets under a single identity or access management scheme. You may not be able to ensure that each employee and consultant and advisor in every department can be given a username and appropriate access regardless of when they join the company and what it is they do. Strive, however, for the minimal number of arrangements that is possible to achieve in managing assets and identities.

       Maintainable: Your organization will change. In a big company, divisions may be added, product groups may be invented, or an entire business arm may be broken up. Even in a small enterprise, individual contributors will be reassigned, and reporting relationships will change. You want an identity scheme that will power through any such changes and not require that someone changes their internal email address or even their username because of a transfer or promotion.

       Adaptable: Ideally, the same scheme and decision factors should be capable of controlling access on individual computer systems, within a wholly owned data center, in a globe-circling cloud environment, or (more realistically) in all of these environments and more simultaneously.

       Just (and justifiable): Authorization decisions need to be justifiable in the eyes of those who are denied as well as those who are granted permission. Arbitrary decisions, or decisions that can reasonably be criticized as discriminatory or frivolous, will at the least drain energy away from security as they are defended.

       Comprehensible: Do not underrate the advantage of being able to explain the reasoning behind the identity and access management scheme you have selected. Management, vendors, board members or advisors, and many curious and sometimes frustrated employees will want to know how names and access roles are determined and what policy and infrastructure is carrying out access decisions.

      Proofing

      Provisioning starts with the initial claim of identity and a request to create a set of credentials for that identity; typically, a responsible manager in the organization must approve requests to provision new identities. (This demonstrates separation of duties by preventing the same IT provisioning clerk from creating new identities surreptitiously.) Key to this step is identity proofing, which separately