Chapter 7

IN THIS CHAPTER

Controlling physical and logical access to assets

Managing identification and authentication of people, devices, and services

Federating identity with a third-party service

Implementing and managing authorization mechanisms

Managing the identity and access provisioning life cycle

Implementing authentication systems

Identity and access management (IAM) is often the first — and sometimes the only — line of defense between adversaries and sensitive information. In fact, in the modern cloud era, with ubiquitous mobile computing and anywhere, anytime access to applications and data, many security practitioners now refer to identity as “the new perimeter.” Security professionals must have a thorough understanding of the concepts and technologies involved. This domain represents 13 percent of the CISSP certification exam.

IAM is a collection of processes and technologies that are used to control access to critical assets. Together with other critical controls, IAM is part of the core of information security; when it’s implemented correctly, unauthorized people are not permitted to access critical assets. Breaches and other abuses of information and assets are less likely to occur.

Control Physical and Logical Access to Assets

The purpose of IAM systems and processes is the management of access to information, systems, devices, and facilities. A variety of controls are used for this purpose in several contexts that are discussed in this section. Chapter 3 contains a discussion of the types and categories of controls.

This section covers Objective 5.1 of the Identity and Access Management (IAM) domain in the CISSP Exam Outline (May 1, 2021).

Information

Controlling access to information assets is achieved primarily through logical controls that determine which people or systems (known as subjects) are permitted to access which files, directories, databases, tables, records, or fields (known as objects). The mechanisms used to control access to information include

· File- and directory-level permissions: These permissions are typically managed at the operating-system level or within a file sharing system (such as a file server, SharePoint, or Box).

· Database table, view, field, and row permissions: Usually managed within a database management system or a third-party tool, permissions can be granted at various levels.

Systems and devices

Controlling access to systems and devices is achieved mainly through mechanisms built into those systems, including

· Port-level access control: At the network level, a system can be configured to accept incoming connection requests based upon their origin (such as IP address, IP network, or geographic region), as well as the port number.

· Console login: A physical or logical console controls access to the system, generally based on the proven identity of the subject who wants to connect.

· Remote console login: A system can be accessed via a remote console connection, which has the general appearance of a local, physical console but is accessed via a network. Again, access permission is based on the proven identity of the subject who wants to connect.

· Application programming interfaces (APIs): A system or application can be accessed programmatically through an API, typically used by an application that needs to access data or functions.

Systems and devices include far more than servers and routers. Many kinds of business and consumer products are marketed as “smart” devices and equipped with Ethernet, Wi-Fi, and Bluetooth connectivity. When pondering systems and devices, be sure to include the vast array of things that are connected to networks, including the following:

· Industrial control systems: This category includes systems that perform remote monitoring and control of utility infrastructure, including electric power and distribution, water supplies, and sewage treatment. Don’t forget automated manufacturing, 3D printing, environmental systems, and voting machines.

· Medical devices: These devices include equipment used in hospitals, such as patient monitoring and IV pumps, as well as things on or in our bodies, including insulin pumps and pacemakers.

· Wearables: This category consists of watches, fitness devices, video glasses, and the like.

· Transportation: This category includes automobiles, self-driving cars, drones, and satellites, as well as GPS navigation, autopilots, air traffic control, and more.

DEVICE SECURITY AND LIFE SAFETY

A staggering variety of smart devices is available today — smart automobiles, smart television sets, and smart appliances, among others. These devices include wearable and life safety products, such as those that monitor vital signs (heart rate, respiration, and so on), insulin pumps, IV pumps, patient monitoring, robotic surgery, pacemakers, autonomous vehicles, and aircraft navigation and control.

Security experts have observed that many of these new products have security capabilities that range from well-designed to poorly designed to outright absent. But IAM has never been so important: Exceptionally good authentication and authorization are needed for all these new types of devices to prevent unauthorized access to them. The consequences of doing IAM wrong can literally cost someone their life.

Facilities

The purpose of controlling access to facilities is to ensure the safety of personnel who work in those facilities, as well as to protect information systems and other assets located there. Controlling access to facilities is accomplished by different means, including

· Key card access systems: With optional biometric readers and/or personal identification number (PIN) pads, these systems control who is permitted to access which buildings and rooms. These systems are used in both preventive (by restricting access to sensitive areas) and detective (by recording subjects’ movement) contexts.

· Escorts: Visitors and subjects with lower security clearances may be escorted by other personnel.

· Guards and guard dogs: Security personnel with optional canine assistants ensure that only authorized and/or properly escorted personnel can enter a building.

· Visitor logs: Although they serve as an administrative control, visitor logs provide a business record of guests and visitors who enter and leave a facility. This control is improved somewhat through the verification of visitor identity via government-issued photo identification.

· Fences, walls, and gates: These features help establish a secure physical perimeter and controlled entry/exit points around a building or facility.

· Mantraps and sally ports: These combinations of passageways and entryways restrict access to an area, for example, with a set of interlocking doors that require one set of doors to be closed before the next set can open.

· Bollards and crash gates: These features control vehicle flow approaching and near facilities.

Many other aspects of physical security are discussed in Chapter 5.

Applications

Access to applications (and their associated data) is typically controlled through an identity management system (discussed in the following section). Attackers can target vulnerabilities in applications, APIs, or — increasingly commonly — user credentials to gain access to application data. Enterprise applications such as customer relationship management (CRM), e-commerce, enterprise resource planning (ERP), and financial systems can contain sensitive information that is valuable to an attacker, including customer data, financial information, and intellectual property. These applications may be hosted in an on-premises data center and may be accessible only internally or via a virtual private network (VPN) connection, or they may be hosted as web applications that can be accessed over the Internet. These applications may also run as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) workloads hosted in a public cloud.

Manage Identification and Authentication of People, Devices, and Services

The core activity within IAM is the management of identities, including people, devices, and services. In this section, we describe the processes and technologies in use today.

This section covers Objective 5.2 of the Identity and Access Management (IAM) domain in the CISSP Exam Outline (May 1, 2021).

Identity management implementation

Implementing identity management (IdM) begins with a plan. IdM is a complex, distributed system that touches systems, networks, and applications, and also controls access to assets within an organization. IdM also includes the business processes that work together with IAM technologies and personnel to get the job done.

Single-/multifactor authentication

Authentication is a two-step process that consists of identification and authentication (I&A). Identification is the means by which a user or system (subject) presents a specific identity (such as a username) to a system (object). Authentication is the process of verifying that identity. A username/password combination is one common technique (albeit a weak one) that demonstrates the concepts of identification (username) and authentication (password).

Authentication is based on any of these factors:

· Something you know (such as a password or PIN): This concept is based on the assumption that only the owner of the account knows the secret password or PIN needed to access the account. Username and password combinations are the simplest, least expensive, and therefore most common authentication mechanism implemented today. Passwords, of course, are often shared, stolen, guessed, or otherwise compromised; thus, they’re among the weakest authentication mechanisms.

· Something you have (such as a smart card, security token, or smartphone): This concept is based on the assumption that only the owner of the account has the necessary key to unlock the account. Smart cards, USB tokens, smartphones, and key fobs are becoming more common, particularly in relatively secure organizations, such as government and financial institutions. Many online applications, such as LinkedIn and Twitter, have implemented multifactor authentication (MFA) as well. Although smart cards and tokens are somewhat more expensive and complex than other, less-secure authentication mechanisms, they’re (usually) not prohibitively expensive or overly complicated to implement, administer, and use. Smartphones that can receive text messages or run soft token apps such as Google Authenticator or Microsoft Authenticator are increasingly popular because of their lower cost and convenience. Regardless of the method chosen, all forms of multifactor authentication provide a significant boost to authentication security. Tokens, smartcards, and smartphones are sometimes lost, stolen, or damaged, however.

Because of the risks associated with text messages (such as mobile phone porting scams), the U.S. National Institute of Standards and Technology has deprecated the use of text messages for multifactor authentication.

· Something you are (such as fingerprint, face, voice, retina, or iris characteristics): This concept is based on the assumption that the face, finger, or eyeball attached to your body is actually yours and uniquely identifies you. (Fingers and eyes can be lost, of course.) Actually, the major drawback with this authentication mechanism is acceptance; people are sometimes uneasy about using these systems. There is also the issue of spoofing: Some biometric systems, such as fingerprint and facial recognition, are not immune to spoofing attacks. Software-based biometric systems such as facial recognition are generally inexpensive, but hardware-based biometric systems are more costly to deploy.

Authentication is based on something you know, something you have, or something you are.

The various I&A techniques that we discuss in the following sections include passwords/passphrases and PINs (knowledge-based); biometrics and behavior (characteristic-based); and one-time passwords, tokens, and single sign-on.

The identification component is normally a relatively simple mechanism based on a username or, in the case of a system or process, on a computer or process name, Media Access Control (MAC) address, IP address, or Process ID (PID). Identification requirements include only unique identification of the user (or system/process) without identifying that user’s role or relative importance in the organization. That is, the identification shouldn’t include labels such as accounting or CEO. Common, shared, and group accounts such as root, admin, or system should not be permitted. Such accounts provide no accountability and are prime targets for malicious beings.

Identification is the act of claiming a specific identity. Authentication is the act of verifying that identity.

Single-factor authentication

Single-factor authentication requires only one of the three preceding factors discussed in the preceding section (something you know, something you have, or something you are) for authentication. Common single-factor authentication mechanisms include passwords and passphrases, one-time passwords, and PINs.

PASSWORDS AND PASSPHRASES

“A password should be like a toothbrush. Use it every day; change it regularly; and don’t share it with friends.” — USENET

Passwords are easily the most common — and weakest — authentication credentials in use today. Although more advanced and secure authentication technologies are available, including tokens and biometrics, organizations typically use those technologies as supplements to or in combination with — rather than as replacements for — traditional usernames and passwords.

A passphrase is a variation on a password that uses a sequence of characters or words rather than a single password. Generally, attackers have more difficulty breaking passphrases than breaking regular passwords because longer passphrases are generally more difficult to break than shorter, complex passwords. Passphrases also have the following advantages:

· Users frequently use the same passwords to access numerous accounts, such as their corporate networks, their home computers, their email accounts, their eBay accounts, and their Amazon.com accounts. So, an attacker who targets a specific user may be able to gain access to their work account by going after a less secure system, such as their home computer, or by compromising an Internet account (because the user has passwords conveniently stored in that bastion of security, Internet Explorer!). Internet sites and home computers typically don’t use passphrases, so you improve the chances that your users have to use different passwords/passphrases to access their work accounts.

· Users can remember and type passphrases more easily than they can remember and type much shorter, cryptic passwords that require contorted finger acrobatics to type on a keyboard.

Passphrases also have down sides:

· Users can find passphrases inconvenient (“You mean I need to have a 20-character password now?”), so you may find them difficult to implement.

· Not all systems support passphrases. Such systems ignore anything longer than the system limit (such as eight characters).

· Many command-line interfaces and tools don’t support the space character that separates words in a passphrase.

· Ultimately, a passphrase is still a password (albeit a much longer and better one) and thus has some of the problems associated with passwords.

You, as a CISSP candidate, should understand the general problems associated with passwords, as well as common password controls and management features.

Password/passphrase have the problems of being

· Insecure: Passwords are generally insecure for several reasons, including

· Human nature: In the case of user-generated passwords, users often choose passwords that they can easily remember and, consequently, attackers can easily guess (such as a spouse’s or pet’s name, birthday, anniversary, or hobby). Users may also be inclined to write down passwords (particularly complex, system-generated passwords) or share their passwords with others.

· Transmission and storage: Many applications and protocols — such as Telnet, File Transfer Protocol (FTP), and Password Authentication Protocol (PAP) — transmit passwords in clear text. These applications and protocols may also store passwords in plaintext files or in a security database that uses a weak hashing algorithm.

· Easily broken: Passwords are susceptible to brute-force and dictionary attacks by readily available programs such as John the Ripper and L0phtCrack (pronounced loft-crack).

· Easily stolen: From phishing scams to watering-hole attacks and key loggers, users can be tricked into giving up passwords, and malware can steal those passwords as users type them. Some organizations store their users’ passwords unencrypted, hashed without salting, or encrypted with an easily discovered key; any of these methods makes it relatively easy for an intruder to obtain passwords from a poorly protected system.

· Inconvenient: Easily agitated users can find entering passwords tiresome. In an attempt to bypass these controls, users may select an easily typed, weak password; they may automate logins (such as using a keyboard macro or selecting the Remember My Password check box in a browser); and they can neglect to lock their workstations or log out when they leave their desks.

· Refutable: Transactions authenticated with only a password don’t necessarily provide absolute proof of a user’s identity. Authentication mechanisms must guarantee nonrepudiation, which is a critical component of accountability. (For more on nonrepudiation, see “Accountability” later in this chapter.)

Passwords have the following login controls and management features that you should configure in accordance with an organization’s security policy and security best practices:

· Length: Generally, the longer the better. A password is in effect an encryption key. Just as larger encryption keys (such as 1024-bit or 2048-bit) are more difficult to crack, so are longer passwords. You should configure systems to require a minimum password length of 10 to 15 characters. Users can easily forget long passwords, of course, or may simply find them too inconvenient, leading to some of the human-nature problems discussed earlier in this section.

· Complexity: Strong passwords contain a mix of upper- and lowercase letters, numbers, and special characters such as # and $. Be aware that some systems may not accept certain special characters. Also be aware that those characters may perform special functions (such as in terminal emulation software).

· Expiration (or maximum password aging): You should set maximum password aging to require password changes at regular intervals; 30-, 60-, and 90-day periods are common.

· Minimum password aging: This approach prevents a user from changing their password too frequently. The recommended setting is one to ten days to prevent a user from easily circumventing password history controls (such as by changing their password five times within a few minutes and then setting it back to their original password).

· Reuse: Password reuse settings (five to ten are common) allow a system to remember previously used passwords (or, more appropriately, their hashes) for a specific account. This security setting prevents users from circumventing maximum password expiration by alternating among two or three familiar passwords when they’re required to change passwords.

· Limited attempts: This control limits the number of unsuccessful login attempts and consists of two components: counter threshold (such as three or five) and counter reset (such as 5 or 30 minutes). The counter threshold is the maximum number of consecutive unsuccessful attempts permitted before some action occurs (such as automatic disabling of the account). The counter reset is the amount of time between unsuccessful attempts. Three unsuccessful login attempts within a 30-minute period, for example, may result in an account lockout for a set period, such as 24 hours, but two unsuccessful attempts in 25 minutes and a third unsuccessful attempt 10 minutes later wouldn’t result in an account lockout. A successful login attempt also resets the counter.

· Lockout duration (or intruder lockout): When a user exceeds the counter threshold that we describe in the preceding item, the account is locked out. Organizations commonly set the lockout duration to 30 minutes, but you can set it for any duration. If you set the duration to forever, an administrator must unlock the account. Some systems don’t notify the user when it locks out an account, instead quietly alerting the system administrator to a possible break-in attempt. An attacker can use the lockout duration as a simple means to perform a denial of service attack (intentionally making repeated bad login attempts to keep the user’s account locked).

· Limited time periods: This control restricts the time of day when a user can log in. You can effectively reduce the period when attackers can compromise your systems by limiting users’ access to business hours. This type of control is becoming less common in the modern age of the workaholic and the global economy, both of which require users to perform work legitimately at all hours of the day.

· System messages: System messages include the following:

· Login banner: Welcome messages invite criminals to access your systems. Disable any welcome message and replace it with a legal warning that requires the user to click OK to acknowledge the warning and accept the legal terms of use.

· Last username: Many popular operating systems display the username of the last successful account login. Users (who need only type their password) find this feature convenient — and so do attackers (who need only crack the password without worrying about matching it to a valid user account). Disable this feature.

· Last successful login time: After a user successfully logs in to the system, this message tells the user the last time that they logged in. If the system shows that the last successful login for a user was Saturday morning at 2 a.m., and the user knows that they couldn’t possibly have logged in at that time because they have a life, they know that someone has compromised their account, and they can report the incident.

· Last successful login location: After a user successfully logs in to the system, this message tells the user the last geographical location used when they logged in. If the system reports that the user last logged in from some obscure, far-away country, this message can be a clue that the user’s account has been compromised.

We’re sure that you know many of the following widely available, well-known guidelines for creating more secure passwords, but just in case, here’s a recap:

· Use a mix of upper- and lowercase letters, numbers, and special characters (such as !@#$%).

· Do not include your name or other personal information (such as spouse, street address, school, birthdays, and anniversaries).

· Replace some letters with numbers (such as e with 3). This technique of modifying spelling is known as leet or leetspeak.

· Use nonsense phrases, misspellings, substitutions, or before-and-after words and phrases (combining two unrelated words or phrases, such as “Wheel of Fortune Cookies”).

· Combine multiple words by using special characters (such as sALT&pEPPER or W3’r3-n0t-in-K4ns4s-4nym0r3).

· Create a longer password that is actually a passphrase (such as “I Love Green Bananas”).

· Use a combination of all the other tips in this list (so that “Snow White and the Seven Habits of Highly Effective People”, for example, becomes SW&t7HoH3P!).

· Do not use repeating patterns between changes (such as password1, password2, password3).

· Do not use the same passwords for work and personal accounts.

· Do not use passwords that are too difficult to remember.

· Do not use any passwords you see in a book, including this one. (But you knew that.)

The problem with these guidelines is that they’re widely available and well known! In fact, attackers use some of these same guidelines to create their aliases or handles: super-geek becomes 5up3rg33k. Also, a password such as Qwerty12! technically satisfies these guidelines, but it’s not really a good password because it’s a relatively simple and obvious pattern (the first row on your keyboard). Many dictionary attacks include not only word lists, but also patterns such as this one.

You can use a software tool that helps users evaluate the quality of their passwords when they create them. These tools are commonly known as password/passphrase generators or password appraisers. Also, a password manager can be used to securely store passwords so that users are less tempted to write down or re-use their passwords.

ONE-TIME PASSWORDS

A one-time password is valid for one login session only. After a single login session, the password is no longer valid. Thus, if an attacker obtains a one-time password that someone has already used, that password has no value. A one-time password is a dynamic password, meaning that it changes at some regular interval or event. Conversely, a static password is a password that remains the same for each login. Similar to the concept of a one-time pad in cryptography (which we discuss in Chapter 5), a one-time password provides maximum security for access control.

Security professionals should be sure to distinguish one-time passwords from passwords that are valid for a short period. Often, what is considered to be a one-time password is actually a password that is valid for several minutes. Limited-time passwords are a big improvement in security, but they’re subject to replay attacks if the attacker acts quickly.

PERSONAL IDENTIFICATION NUMBERS

A PIN in itself is a relatively weak authentication mechanism because you have only 10,000 possible combinations for a four-digit numeric PIN. Therefore, organizations usually use some other safeguard in combination with a PIN. A PIN used with a one-time token password and an account lockout policy is also very effective, allowing a user to attempt only one PIN/password combination per minute and then locking the account after three or five failed attempts, as determined by the security policy.

Two examples of one-time password implementations are tokens (which we discuss in the following section) and the S/Key protocol. The S/Key protocol, developed by Bell Communications Research and defined in Internet Engineering Task Force (IETF) Request For Comment (RFC) 1760, is client/server–based and uses MD4 and MD5 to generate one-time passwords. MD4 and MD5 are algorithms used to verify data integrity by creating a 128-bit message digest from data input.

Multifactor authentication

Multifactor authentication (MFA) involves two or more of what you know, what you have, and what you are. MFA is more challenging for an adversary to attack, because a successful attack of MFA requires the attacker to possess the user’s token or the ability to trick a biometric reader. Types of MFA discussed in this section include tokens, certificates, and biometrics.

TOKENS

Tokens are access control devices such as key fobs, dongles, USB keys, smart cards, magnetic cards, software (known as soft tokens and installed on a tablet, mobile device, smartphone, laptop, or PC), and keypad or calculator-type cards that store static passwords (or digital certificates) or that generate dynamic passwords. The three general types of tokens are

· Static password tokens: Store a static password or digital certificate.

· Synchronous dynamic password tokens: Continuously generate a new password or passcode at a fixed time interval (such as 60 seconds) or in response to an event (such as every time you press a button). Typically, the passcode is valid only during a fixed time window (say, 1 minute) and only for a single login, so if you want to log in to more than one system, you must wait for the next passcode.

· Asynchronous (or challenge-response) dynamic password tokens: Generate a new password or passcode asynchronously by calculating the correct response to a system-generated random challenge string (known as a nonce) that the owner enters manually.

Tokens provide two-factor authentication (something you have and something you know) by either requiring the owner to authenticate to the token first or by requiring the owner to enter a secret PIN along with the generated password. Both RADIUS and Terminal Access Controller Access Control System (TACACS+), which we discuss later in this chapter support various token products.

A soft token that’s installed on a laptop or PC doesn’t provide strong (two-factor) authentication because the “something you have” is the computer you’re trying to log in to! A soft token such as Google Authenticator and Microsoft Authenticator on a smartphone, however, would provide adequate two-factor authentication, provided that the user is not trying to log in to an application from a smartphone.

You can use tokens to generate one-time passwords and provide two-factor authentication.

SMARTPHONE / SMS PASSWORDS

When a user attempts to log in to a system, a one-time or short-duration password can be sent to a smartphone or mobile device via a text message or other messaging mechanism. Upon receiving this password, the user would enter it into the system’s password field and complete the login procedure.

Because of the proliferation of subscriber identity module swap and mobile device takeover scams, Short Message System (SMS) text messages generally should not be used for MFA.

DIGITAL CERTIFICATES

A digital certificate can be installed on the user’s device. When the user attempts to authenticate to a system, the system will query the user’s device for the digital certificate to confirm the user’s identity. If the digital certificate can be obtained and is confirmed to be genuine, the user is permitted to log in.

Digital certificate authentication also helps ensure that users log in by using only company-provided devices. This presupposes the fact that the user is unable to copy the digital certificate to another, perhaps personally owned, device, or that an intruder is unable to copy the certificate to his own device.

When implementing digital certificates on devices such as laptop computers, administrators need to be sure that they implement a per-device or per-user certificate on each laptop, not a general company certificate.

BIOMETRICS

The only absolute method for positively identifying a person is basing authentication on some unique physical or behavioral characteristic of that person. Biometric identification uses physical characteristics, such as fingerprints, hand geometry, and facial features such as retina and iris patterns. Behavioral biometrics are based on measurements and data derived from an action, and they indirectly measure characteristics of the human body. Behavioral characteristics include voice, signature, and keystroke patterns.

Biometrics are based on the third factor of authentication: something you are. Biometric access control systems apply the concept of I&A slightly differently, depending on their use:

· Physical access controls: The person presents the required biometric characteristic, and the system attempts to identify them by matching the input characteristic with its database of authorized personnel. This type of control is also known as a one-to-many search.

· Logical access controls: The user enters a username or PIN (or inserts a smart card), and then presents the required biometric characteristic for verification. The system attempts to authenticate the user by matching the claimed identity and the stored biometric image file for that account. This type of control is also known as a one-to-one search.

Biometric authentication in and of itself doesn’t provide strong authentication because it’s based on only one of the three authentication requirements: something you are. To be considered a truly strong authentication mechanism, biometric authentication must include something you know or something you have. (Although you might argue that your hand or eye is something you have and something you are, for the purposes of the CISSP exam, you’d be wrong!)

The necessary factors for an effective biometrics access control system include

· Accuracy: The most important characteristic of any biometric system. The uniqueness of the body organ or characteristic that the system measures to guarantee positive identification is an important element of accuracy. In common biometric systems today, the only organs that satisfy this requirement are the fingers/hands and eyes.

Another important element of accuracy is the system’s ability to detect and reject forged or counterfeit input data. The accuracy of a biometric system is normally stated as a percentage, in the following terms:

· False Reject Rate (FRR) or Type I error: Authorized users to whom the system incorrectly denies access, stated as a percentage. Reducing a system’s sensitivity reduces the FRR but increases the False Accept Rate (FAR).

The FRR Rate (or Type I error) is the percentage of authorized users to whom the system incorrectly denies access.

· False Accept Rate (FAR) or Type II error: Unauthorized users to whom the system incorrectly grants access, stated as a percentage. Increasing a system’s sensitivity reduces the FAR but increases the FRR.

The FAR (or Type II error) is the percentage of unauthorized users to whom the system incorrectly grants access.

· Crossover Error Rate (CER): The point at which the FRR equals the FAR, stated as a percentage. (See Figure 7-1.) Because you can adjust the FAR and FRR by changing a system’s sensitivity, the CER is considered to be the most important measure of biometric system accuracy.

· The CER is the point at which the FRR equals the FAR, stated as a percentage.

· Speed and throughput: The length of time required to complete the entire authentication procedure. This time, measurement includes stepping up to the system, inputting a card or PIN (if required), entering biometric data (such as inserting a finger or hand into a reader, pressing a sensor, aligning an eye with a camera or scanner, speaking a phrase, or signing a name), processing the input data, and opening and closing an access door (in the case of a physical access control system). Another important measure is the initial enrollment time required to create a biometric file for a user account. Generally accepted standards are a speed of less than five seconds, a throughput rate of six to ten per minute, and enrollment time of less than two minutes.

· Data storage requirements: The size of a biometric system’s input files can be as small as 9 bytes or as large as 10,000 bytes, the normal range being 256 to 1,000 bytes.

· Reliability: An important factor in any system. The system must operate continuously and accurately without frequent maintenance outages.

· Acceptability: The biggest hurdle to widespread implementation. Certain privacy and ethics issues arise with the prospect of organizations using these systems to collect medical or other physical data about employees. Other factors that might alarm users include intrusiveness of the data collection procedure and undesirable physical contact with common system components, such as pressing an eye against a plastic cup or placing lips close to a microphone for voice recognition.

© John Wiley & Sons, Inc.

FIGURE 7-1: Use CER to compare FAR and FRR.

Gaining user acceptance is the most common difficulty with biometric systems.

Table 7-1 summarizes the generally accepted standards for the factors described in the preceding list.

TABLE 7-1 Generally Accepted Standards for Biometric Systems

Characteristic	Standard
Accuracy	CER < 10%
Speed	5 seconds
Throughput	6–10 per minute
Enrollment time	< 2 minutes

Common types of physical biometric access control systems include

· Fingerprint recognition and finger scan systems: The most common biometric systems in use today, these systems analyze the ridges, whorls, and minutiae (bifurcations and ridge endings, dots, islands, ponds and lakes, spurs, bridges, and crossovers) of a fingerprint to create a digitized image that uniquely identifies the owner of the fingerprint. A fingerprint recognition system stores the entire fingerprint as a digitized image. A disadvantage of this type of system is that it can require a lot of storage space and resources. More commonly, organizations use a finger scan system, which stores only sample points or unique features of a fingerprint and therefore requires less storage and processing resources. Also, users may more readily accept the technology because no one can re-create an entire fingerprint from the data in a finger scan system. See Table 7-2 for general characteristics of finger scan systems.

Finger scan systems, unlike fingerprint recognition systems, don’t store an image of the entire fingerprint — only a digitized file describing its unique characteristics. This fact should allay the privacy concerns of most users.

· Facial recognition systems: Fast becoming a popular authentication method used by Apple, Microsoft, and others, facial recognition works through recognition of the unique geometry of the user’s facial features. Facial recognition software examines the face as the user looks into the device’s camera and decides whether the person looking into the camera is the same person who is authorized to use the device.

TABLE 7-2 General Characteristics of Finger Scan and Hand Geometry Systems

Characteristic	Finger Scan	Hand Geometry
Accuracy	< 1%–5% (CER)	< 1%–2% (CER)
Speed	1–7 seconds	3–5 seconds
File size	~250–1500 bytes	~10 bytes
Advantages	Nonintrusive, inexpensive	Small file size
Disadvantages	Sensor wear and tear; accuracy may be affected by swelling, injury, or jewelry	Sensor wear and tear; accuracy may be affected by swelling, injury, or jewelry

· Hand geometry systems: Like finger scan systems, hand geometry systems are nonintrusive and therefore generally better accepted than other biometric systems. These systems generally can more accurately uniquely identify a person than finger scan systems do, and they have some of the smallest file sizes compared with other biometric system types. A digital camera simultaneously captures a vertical and a horizontal image of the subject’s hand, acquiring the 3D hand geometry data. The digitized image records the length, width, height, and other unique characteristics of the hand and fingers. See Table 7-2 for general characteristics of hand geometry systems.

· Retina pattern: These systems record unique elements in the vascular pattern of the retina. Major concerns with this type of system are fears of eye damage from a laser (which is only a camera with a focused low-intensity light) directed at the eye and, more feasibly, privacy concerns. Certain health conditions, such as diabetes and heart disease, can cause changes in the retinal pattern, which these types of systems may detect. See Table 7-3 for general characteristics of retina pattern systems.

· Iris pattern: This system is by far the most accurate biometric system. The iris is the colored portion of the eye surrounding the pupil. The complex patterns of the iris include unique features such as coronas, filaments, freckles, pits, radial furrows, rifts, and striations. The characteristics of the iris, formed shortly before birth, remain stable throughout life. The iris is so unique that even the two eyes of a single person have different patterns. A camera directed at an aperture mirror scans the iris pattern. The subject must glance at the mirror from a distance of approximately 3 to 10 inches. It’s technically feasible — but perhaps prohibitively expensive — to perform an iris scan from a distance of several feet. See Table 7-3 for general characteristics of iris pattern systems.

TABLE 7-3 General Characteristics of Retina and Iris Pattern Systems

Characteristic	Retina Pattern	Iris Pattern
Accuracy	1.5% (CER)	< 0.5% (CER)
Speed	4–7 seconds	2.5–4 seconds
File size	~96 bytes	~256–512 bytes
Advantages	Overall accuracy	Best overall accuracy
Disadvantages	Perceived intrusiveness; sanitation and privacy concerns	Subject must remain absolutely still; subject can’t wear colored contact lenses or glasses (clear contacts are generally okay)

Common types of behavioral biometric systems include

· Voice recognition: These systems capture unique characteristics of a subject’s voice and may also analyze phonetic or linguistic patterns. Most voice recognition systems are text-dependent, requiring the subject to repeat a specific phrase. This functional requirement of voice recognition systems also helps improve their security by providing two-factor authentication: something you know (a phrase) and something you are (your voice). More advanced voice recognition systems may present a random phrase or group of words, which prevents an attacker from recording a voice authentication session and later replaying the recording to gain unauthorized access. See Table 7-4 for general characteristics of voice recognition systems.

· Signature dynamics: These systems typically require the subject to sign their name on a signature tablet. The enrollment process for a signature dynamics system captures numerous characteristics, including the signature pattern itself, the pressure applied to the signature pad, and the speed of the signature. Signatures commonly exhibit some slight changes because of different factors, of course, and they can be forged (although the signature dynamics are difficult to forge). See Table 7-4 for general characteristics of signature dynamics systems.

· Keystroke or typing dynamics: These systems typically require the subject to type a password or phrase. The keystroke dynamic identification is based on unique characteristics such as how long a user holds down a key on the keyboard (dwell time) and how long it takes a user to get to and press a key (seek or flight time). These characteristics are measured by the system to form a series of mathematical data representing a user’s unique typing pattern or signature, which is used to authenticate the user.

TABLE 7-4 General Characteristics of Voice Recognition and Signature Dynamics Systems

Characteristic	Voice Recognition	Signature Dynamics
Accuracy	< 10% (CER)	1% (CER)
Speed	10–14 seconds	5–10 seconds
File size	~1,000–10,000 bytes	~1,000–1,500 bytes
Advantages	Inexpensive; nonintrusive	Nonintrusive
Disadvantages	Accuracy, speed, file size; affected by background noise, voice changes; can be fooled by voice imitation	Signature tablet wear and tear; speed; can be fooled by a forged signature

Digital signatures and electronic signatures — which are electronic copies of people’s signatures — are not the same as the signatures used in biometric systems. These terms are not related and are not interchangeable.

In general, the CISSP candidate doesn’t need to know the specific characteristics and specifications of the different biometric systems, but you should know how they compare. You should know, for example, that iris pattern systems are more accurate than retina pattern systems, and you should be familiar with the concepts of FRR, FAR, and CER.

Accountability

The concept of accountability refers to the capability of a system to associate users and processes with their actions (what they did). Audit trails and system logs are components of accountability.

Systems use audit logs and audit trails primarily as a means of troubleshooting problems and verifying events. Users should not view audit logs and audit trails as a threat or as Big Brother watching over them because they cannot be trusted. As a matter of fact, astute users consider these mechanisms to be protective, because the system not only prove what they did, but also help prove what they did not do. Still, it’s wise for users to be mindful of the fact that the systems they use are recording their actions.

An important security concept that’s closely related to accountability is nonrepudiation. Nonrepudiation means that a user (username Madame X) can’t deny an action because her identity is positively associated with her actions. Nonrepudiation is an important legal concept. If a system permits users to log in by using a generic user account, a user account that has a widely known password, or no user account, you can’t absolutely associate any user with a given (malicious) action or (unauthorized) access on that system, which makes it extremely difficult to prosecute or otherwise discipline that user.

Accounting in authentication, authorization and accounting (AAA) services records what a subject did.

Nonrepudiation means that a user can’t deny an action because you can irrefutably associate them with that action.

Session management

A session is a formal term referring to an individual user’s dialogue, or series of interactions, with an information system. Information systems need to track individual users’ sessions to properly distinguish one user’s actions from another’s.

To protect the confidentiality and integrity of data accessible through a session, information systems generally use session or activity timeouts to prevent an unauthorized user from continuing a session that has been idle or otherwise inactive for a specified period.

Two primary means of implementing session timeouts are

· Screen savers: Implemented by the operating system, a screen saver locks the workstation or mobile device itself and requires the user to log back into the system after a period of inactivity. The workstation’s or mobile device’s screen saver protects all application sessions. Make sure that this feature actually locks the screen or device, as some systems can be configured to not require a PIN or password to unlock them.

· Inactivity timeouts: Individual software applications may use an auto-locking or auto-logout feature if a user has been inactive for a specific period.

If an authorized user leaves a computer terminal unlocked or a browser window on a workstation unattended, for example, an unauthorized user can simply sit down at the workstation and continue the session.

Workstation inactivity timeouts were originally called screen savers, to prevent a static image on a cathode ray tube display from being burned into the display. Although today’s monitors do not require this protection, the term screen saver is still in common use.

Registration, proofing, and establishment of identity

Formal user registration processes are important for secure account provisioning, particularly in large organizations where it is not practical or possible to know all the workers. This type of process is particularly critical in single-sign on (SSO), federated, and PKI environments (see Chapter 5), where users will have access to multiple systems and applications.

Proof of identity often begins at the time of hire, when new workers are usually required to show government-issued identification and legal right-to-work status. These procedures should form the basis for initial user registration in information systems.

Organizations need to take several precautions when registering and provisioning users:

· User identity: The organization must ensure that new user accounts are provisioned for, and given to, the correct user.

· Protection of privacy: The organization should not use Social Security number, date of birth, or other sensitive private information to authenticate the user. Instead, other values should be used, such as employee number (or other values that cannot be obtained by other employees).

· Temporary credentials: The organization must ensure that temporary login credentials are assigned to the correct person. Others should not be able to easily guess temporary credentials. Finally, temporary credentials should be set to expire in a short period.

· Birthright access: The organization should periodically review the birthright access granted to new workers, following the principles of need to know and least privilege.

Additional considerations about user identity occur when a user is attempting to log on to a system:

· Geographic location: Location can be derived from the IP address of the user. The IP address is not absolutely reliable but can be helpful for determining the user’s location. Many devices, particularly smartphones and tablet computers, use GPS technology for location information, which is generally more reliable than IP address.

· Workstation in use: The organization may have policies about whether a user is permitted to log in on a personally owned device or from a public kiosk.

· Elapsed time since last login: This metric is how long it has been since the user last logged in to the system or application.

· Login attempt after failed attempts: This metric records whether there have been recent unsuccessful login attempts.

Depending on the preceding conditions, the system may be configured to present additional challenges to the user. These challenges ensure that the person attempting to log in actually is the authorized user, not another person or machine. This type of challenge is known as risk-based authentication.

Federated identity management

Federated identity management (FIM) enables multiple organizations to use one another’s user identification and authentication systems to access their networks and systems. Federation of identity (FIdM) comprises the standards, technologies, and tools used to facilitate the portability of identity across separately managed organizations.

FIdM permits organizations that want to facilitate easier user access to their systems without having to create custom solutions. Instead, they need only configure existing tools and occasionally add connectors to facilitate inter-organization identity management.

Technologies in common use in federated environments (all discussed later in this chapter) include

· Single sign-on (SSO)

· Security Assertion Markup Language (SAML)

· Open Authorization (OAuth) and OpenID Connect (OIDC)

Credential management systems

Credential management systems enable an organization to centrally organize and control user IDs and passwords. This type of system should not be confused with systems used to store and manage users’ professional credentials (such as the CISSP certification).

Credential management systems are available as commercial software products that can be implemented either on-premises or in the cloud.

Credential management systems create user accounts for subjects and provision those credentials as required in both individual systems and centralized identity management systems (such as LDAP or Microsoft Active Directory). Credential management systems can be either separate applications (as explained previously) or an integral part of an IAM system.

Single sign-on

The concept of single sign-on (SSO) addresses a common problem for both users and security administrators. Every account that exists in a system, network, or application is a potential point of unauthorized access. Multiple accounts that belong to a single user represent an even greater risk:

· Users who need access to multiple systems or applications often must maintain numerous sets of credentials. Inevitably, this requirement leads to shortcuts in creating and recalling passwords. Left to their own devices, users create weak passwords that have only slight variations; worse, they use the same passwords everywhere they can. When they have multiple sets of credentials to manage, users are more likely to write them down. The problem doesn’t stop at the organization’s boundary: Users often use the same passwords at work that they do for their personal accounts.

· Multiple accounts also affect user productivity (and sanity!) because the user must stop to log in to different systems. Someone must also create and maintain accounts, which involves unlocking accounts and supporting, removing, resetting, and disabling multiple sets of user IDs and passwords.

At first glance (alas), SSO seems to be the perfect solution that users and security administrators seek. SSO allows a user to present a single set of login credentials, typically to an authentication server, which then transparently logs the user into all other enterprise systems and applications in which the user is authorized. SSO does have some disadvantages, of course, which include the following:

· Woo-hoo!: After you’re authenticated, you have the keys to the kingdom. Read that as access to all authorized resources! This situation is the security professional’s nightmare. If login credentials for a user’s accounts are compromised, an intruder can access everything the user was authorized to access.

· Complexity: Implementing SSO can be difficult and time-consuming. You have to address interoperability issues among systems and applications. But hey — that’s why you get paid (or should get paid) the big bucks!

Just-in-Time

Just-in-time (JIT) access provides temporary, granular access to an application or resource (such as a virtual machine) only when it is needed to perform a specific task or function. This approach helps organizations implement and enforce the principle of least privilege (discussed in chapters 5 and 9). An organization might provide JIT access for a system administrator or a process that temporarily requires elevated privileges on a sensitive system. JIT access can be implemented in several ways:

· Key vault: A centralized vault securely stores shared account credentials that are checked out for a specified, limited period by an authorized user when elevated privileges are needed. The user typically needs to provide justification for using the credentials, and access is automatically enforced via defined policies. This approach is commonly used in privileged access management (PAM) solutions.

· Ephemeral accounts: These temporary, one-time accounts are created dynamically with the required privilege when needed; after use, they are immediately and automatically deprovisioned and/or deleted.

· Temporary elevation: An account may be assigned elevated privileges for a specified and limited period. The elevated privileges are removed automatically when the time period expires.

Federated Identity with a Third-Party Service

Most organizations have a variety of business applications, some of which run on-premises and others of which are in the cloud. To avoid the issue of users having to manage multiple sets of user credentials, many organizations have implemented some form of third-party federated identity service. The benefits to organizations are twofold:

· Increased convenience: Users have fewer sets of login credentials (as few as one) for access to business systems.

· Reduced risk: Users are more likely to use stronger passwords and less likely to handle credentials unsafely (such as using sticky notes on monitors). Many organizations employ multifactor authentication, further reducing risk.

This section covers Objective 5.3 of the Identity and Access Management (IAM) domain in the CISSP Exam Outline (May 1, 2021).

The manner in which organizations implement a centralized IAM system depends on several factors, including

· Integration effort: Newer applications have one or more interfaces available to facilitate automated account provisioning and SSO. Older applications usually lack these interfaces.

· Available resources: Even for easily integrated applications, some effort is still required to perform and maintain integrations over time.

· Efficiency tolerance: If the organization is intolerant of inefficiencies, such as users having to log in to business applications many times each day, they may be more likely to pursue an IAM solution.

· Risk tolerance: If an organization is averse to the risks associated with users possessing multiple sets of login credentials for critical business systems, it will be more likely to implement an IAM solution.

Although each IAM platform has its own unique capabilities and architecture, an IAM system generally resembles the architecture depicted in Figure 7-2.

© John Wiley & Sons, Inc.

FIGURE 7-2: Typical identity and access management system architecture.

Organizations with on-premises systems often purchase and integrate identity management tools into their environments to reduce the burden of identity management, as well as improve end user experience. Where Microsoft servers are used, organizations can integrate their systems and applications with Active Directory, which is included with Microsoft server operating systems. In organizations without Microsoft servers, open source tools that use Lightweight Directory Access Protocol (LDAP) are a preferred choice. Also, several commercial on-premises identity service products can be installed and integrated with systems, devices, and software applications.

On-premises identity management tools generally have the same features as their cloud-based counterparts. Some of these tools can be implemented on-premises or based in the cloud, and a few offer solutions in which cloud-based and on-premises tools work together as a single identity access solution.

On-premises

An organization may choose to implement federated identity to manage access among multiple on-premises environments, such as when a trusted connection is needed for partners on different networks or domains.

Cloud

Because business systems and applications are increasingly cloud-based, many organizations are opting to implement cloud-based identity management and/or SSO systems to provide federated identity management.

Hybrid

Federated identity management is particularly helpful in hybrid environments comprised of on-premises data centers and multiple public or private cloud environments. Many organizations today have a multicloud strategy that uses services from different public cloud providers (such as Microsoft Azure and Amazon Web Services [AWS]) and SaaS providers (such as Concur, Salesforce, and Workday).

Implement and Manage Authorization Mechanisms

Authorization mechanisms are the portions of operating systems and applications that determine the data and functions a user is permitted to access, based on the user’s identity.

This section covers Objective 5.4 of the Identity and Access Management (IAM) domain in the CISSP Exam Outline (May 1, 2021).

Authorization (also referred to as establishment) defines the rights and permissions granted to a user account or process (what the user can do and/or what data the user can access). After a system or application authenticates a user, authorization determines what that user (subject) can do with a system or resource (object).

Data access controls protect systems and information by restricting access to system files and user data based on user identity. Data access controls also provide authorization and accountability, relying on system access controls to provide identification and authentication.

Role-based access control

Role-based access control (RBAC) is a method of managing user access controls. RBAC assigns group membership according to organizational or functional roles. People may belong to one or many groups (either acquiring cumulative permissions or limited to the most restrictive set of permissions for all assigned groups); a group may contain only a single person (corresponding to a specific organizational role assigned to that person). Access rights and permissions for objects are assigned to groups rather than (or in addition to) people. RBAC greatly simplifies the management of access rights and permissions, particularly in organizations that have large functional groups or departments or that routinely rotate personnel through various positions or otherwise experience high turnover.

The advantages of role-based access control include

· User access tends to be more uniform.

· Changing many users’ access often involves changing the access rights for one or more roles.

Many systems that employ RBAC still permit access rights to be granted to individual end users. Still, many organizations tend to stick with the use of roles, even if in some instances only one person is a member of a role.

Figure 7-3 depicts the concept of RBAC.

© John Wiley & Sons, Inc.

FIGURE 7-3: Role-based access control.

Rule-based access control

Rule-based access control (not to be confused with RBAC) is one method of applying mandatory access control. All MAC-based systems (discussed next) implement a simple form of rule-based access control by matching an object’s sensitivity label and a subject’s sensitivity label to determine whether the system should grant or deny access. You can apply additional rules by using rule-based access control to further define specific conditions for access to a requested object. Other types of rules that govern access include

· Time of day

· Workstation or terminal in use

· User geographical location

· Contents of data being accessed

Mandatory access control

A mandatory access control (MAC) is an access policy determined by the system rather than by the owner. Organizations use MAC in multilevel systems that process highly sensitive data, such as classified government and military information. A multilevel system is a single computer system that handles multiple classification levels between subjects and objects. Two important concepts in MAC are

· Sensitivity labels: In a MAC-based system, all subjects and objects must have assigned labels. A subject’s sensitivity label specifies its level of trust. An object’s sensitivity label specifies the level of trust required for access. To access a given object, the subject must have a sensitivity level equal to or higher than the requested object. A user (subject) with a Top Secret clearance (sensitivity label) is permitted to access a file (object) that has a Secret classification level (sensitivity label) because their clearance level exceeds the minimum required for access. We discuss classification systems in Chapter 4.

· Data import and export: Controlling the import of information from other systems and the export to other systems (including printers) is a critical function of MAC-based systems, which must ensure that the system properly maintains and implements sensitivity labels so that sensitive information is appropriately protected at all times.

Lattice-based access controls are another method of implementing mandatory access controls. A lattice model is a mathematical structure that defines greatest lower-bound and least upper-bound values for a pair of elements, such as a subject and an object. Organizations can use this model for complex access control decisions involving multiple objects and/or subjects. Given a set of files that have multiple classification levels, for example, the lattice model determines the minimum clearance level that a user requires to access all the files.

Major disadvantages of mandatory access control techniques include

· Lack of flexibility

· Difficulty in implementation and programming

· User frustration

In MAC, the system determines the access policy.

Discretionary access control

A discretionary access control (DAC) is an access policy determined by the owner of a file (or other resource). The owner decides who’s allowed access to the file and what privileges they have.

In DAC, the owner determines the access policy.

Two important concepts in DAC are

· File and data ownership: Because the owner of the resource (which may consist of files, directories, data, system resources, and devices) determines the access policy, every object in a system must have an owner. Theoretically, an object without an owner is left unprotected or without a user who can determine who or what can access it. Normally, the owner of a resource is the person who created the resource (such as a file or directory), but in certain cases, you may need to identify the owner explicitly.

· Access rights and permissions: These rights and permissions are the controls that an owner can assign to individual users or groups for specific resources. Various systems (Windows-based or Unix-based) define different sets of permissions that are essentially variations or extensions of three basic types of access:

· Read (R): The subject can read the contents of a file or list the contents of a directory.

· Write (W): The subject can change the contents of a file or directory (including add, rename, create, and delete).

· Execute (X): If the file is a program, the subject can execute the program.

Access control lists (ACLs) provide a flexible method for applying discretionary access controls. An ACL lists the specific rights and permissions that are assigned to a subject for a given object.

Major disadvantages of discretionary access control techniques such as ACLs and RBAC include the following:

· They lack centralized administration.

· They depend on security-conscious resource owners.

· Many popular operating systems default to full access for everyone if the owner doesn’t set permissions explicitly.

· Auditing is difficult, if not impossible, because of the large volume of individual permissions, as well as the log entries that can be generated.

Various operating systems implement ACLs differently. Although the CISSP exam doesn’t directly test your knowledge of specific operating systems or products, you should be aware of this fact. Also, understand that ACLs in this context are different from ACLs used on routers (see Chapter 5), which have nothing to do with DAC.

Attribute-based access control

Attribute-based access control (ABAC) is an access policy determined by the attributes of a subject and object, as well as environmental factors. In an ABAC-based system, the ability of a subject to access an object is based on one or more attributes of the subject (such as position title, department, or project assignment), as well as attributes of the object itself (such as name, project name, owner, or location). Further, environmental factors are used to determine whether access will be granted. Example environmental factors include the location of the subject and the time of day.

In an ABAC-based system, the access decision is made by the Policy Decision Point (PDP) and enforced by the Policy Enforcement Point (PEP).

ABAC is defined in NIST SP-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, which is available at https://www.nist.gov.

Risk-based access control

Risk-based access controls are policy-based access controls that dynamically assess risk to determine whether access should be granted, under what conditions, and at what level. A user may only need a username and password if they are logging in from a known or trusted IP address during normal working hours, for example, but they may be prompted to use MFA if they are logging in from a different location (such as while traveling) or an unknown device (such as a desktop PC in a hotel kiosk).

Manage the Identity and Access Provisioning Life Cycle

Organizations must adopt formal policies and procedures to address account provisioning, review, and revocation. IAM is a key requirement of a zero trust strategy (discussed in Chapter 5) that requires organizations to always verify who (users) and what (devices) is connecting to their network and what they are allowed to do on the network.

This section covers Objective 5.5 of the Identity and Access Management (IAM) domain in the CISSP Exam Outline (May 1, 2021).

The phases in the IAM provisioning life cycle are

· Role design, creation, and review: During development, customization, or configuration of a system, each of the user roles is designed. These designs are subjected to a review process to ensure that they are appropriate.

· Access provisioning: When new or temporary employees, contractors, partners, auditors, and third parties require access to an organization’s systems and networks, the organization must have a formal methodology for requesting access. The steps in access provisioning are

1. Access request: A requester, typically but not always the end user, makes a formal request to access specific data or a specific role in a system.

2. Review request: The request is reviewed by a designated person or group for appropriateness. Sometimes, the reviewer asks the requester questions to better understand the reason for the request.

3. Access approval: The request is approved by a designated person or group.

4. Access provisioning: The requested and approved access is provisioned in the system.

New accounts must be provisioned correctly and in a timely manner to ensure that access is ready and available when the user needs it, but not too soon (to ensure that new accounts not yet in active use are not compromised by an attacker).

· Privilege escalation: User and system accounts may temporarily require a privileged access level to perform a specific task or function. Privilege escalation helps enforce the principle of least privilege (discussed in chapters 5 and 9) and may be implemented via a PAM solution or JIT access (discussed earlier in this chapter).

· Account access review: User and system accounts, along with their assigned privileges, should be reviewed on a regular basis to ensure that they are still appropriate. An employee may no longer require the same privilege levels due to rotation of duties (see Chapter 9) or a transfer or promotion, for example.

· Role review: Periodically, designated personnel examine the roles in a system to determine whether the access rights defined in each role are appropriate.

· Inactivity review: Periodically, designated personnel examine a system to see whether users are accessing it. Users who have not accessed a system (or had a role in the system) for a given period (such as 90 days) may have their access revoked.

· Access termination: Finally, when access is no longer required, accounts must be promptly disabled and deprovisioned. Deprovisioning should be automated when possible and should include moving the disabled account to a protected organizational unit (in Active Directory) or other restricted group, as well as removing the disabled account from all group memberships.

User accounts are typically locked within 24 hours of termination. In the case of dismissal, user accounts are typically locked immediately before the employee is notified.

Implement Authentication Systems

Commonly used authentication systems include OpenID Connect (OIDC)/Open Authorization (Oauth), Security Assertion Markup Language (SAML), Kerberos, and Remote Authentication Dial-In User Service (RADIUS)/Terminal Access Controller Access Control System Plus (TACACS+).

This section covers Objective 5.6 of the Identity and Access Management (IAM) domain in the CISSP Exam Outline (May 1, 2021).

OpenID Connect/Open Authorization

OIDC is a standards-based authentication protocol built on the OAuth (specifically, OAuth 2.0) framework. OAuth 2.0 is used to grant an application access to another application’s data. Typically, four entities are involved in an OIDC/OAuth exchange:

· Authorization server (identity platform)

· OAuth client (native or web app)

· Resource server (Representational State Transfer [REST] API)

· Resource owner (end user)

Security Assertion Markup Language

The de facto protocol for authentication, SAML is used to facilitate user authentication across systems and among organizations, through the exchange of authentication and authorization information among organizations. SAML is the glue that is used to make most SSO systems work.

As its full name suggests, SAML is an extensible markup language (SML) based standard. XML is becoming a standard method for exchanging information between dissimilar systems.

OIDC allows users to sign-in to an identity provider (IdP) to access third-party websites and apps. OAuth 2.0 allows the IdP to issue tokens to third-party applications and services on the user’s behalf. SAML allows different organizations to exchange authentication and authorization data between IdPs and service providers.

Kerberos

Kerberos, commonly used in the Sun Network File System and Microsoft Windows, is perhaps the most popular ticket-based symmetric key authentication protocol in use today.

Kerberos is named for the fierce three-headed dog that guards the gates of Hades in Greek mythology (not to be confused with Ker-beer-os, the fuzzy, six-headed dog sitting at the bar that keeps looking better and better!). Researchers at the Massachusetts Institute of Technology (MIT, also known as Millionaires in Training) developed this open-systems protocol in the mid-1980s.

The CISSP exam requires a general understanding of Kerberos operation. Unfortunately, Kerberos is a complex protocol that has many implementations and no simple explanation. The following step-by-step discussion is a basic description of Kerberos operation:

1. The client prompts the subject (such as a user) for an identifier and a credential (such as username and password). Using the authentication information (password), the client temporarily generates and stores a secret key for the subject by using a one-way hash function and then sends only the subject’s identification (username) to the Key Distribution Center’s (KDC) Authentication Server (AS). The password/secret key isn’t sent to the KDC. See Figure 7-4.

© John Wiley & Sons, Inc.

FIGURE 7-4: Kerberos: Login initiation (step 1).

2. The AS on the KDC verifies that the subject (known as a principal) exists in the KDC database. The KDC Ticket Granting Service (TGS) generates a Client/TGS Session Key encrypted with the subject’s secret key, which only the TGS and the client know. The TGS also generates a Ticket Granting Ticket (TGT) consisting of the subject’s identification, the client network address, the valid period of the ticket, and the Client/TGS Session Key. The TGS encrypts the TGT by using its secret key, which only the TGS knows, and then sends the Client/TGS Session Key and TGT back to the client. See Figure 7-5.

© John Wiley & Sons, Inc.

FIGURE 7-5: Kerberos: Client/TGS session key and TGT generation (step 2).

3. The client decrypts the Client/TGS session key, using the stored secret key that it generated by using the subject’s password; authenticates the subject (user); and then erases the stored secret key to avoid possible compromise. The client can’t decrypt the TGT, which the TGS encrypted by using the TGS secret key. See Figure 7-6.

© John Wiley & Sons, Inc.

FIGURE 7-6: Kerberos: Login completion (step 3).

4. When the subject requests access to a specific object (such as a server, also known as a principal), it sends the TGT, the object identifier (such as a server name), and an authenticator to the TGS on the KDC. (The authenticator is a separate message that contains the client ID and a time stamp, and uses the Client/TGS session key to encrypt itself.) See Figure 7-7.

© John Wiley & Sons, Inc.

FIGURE 7-7: Kerberos: Requesting services (step 4).

5. The TGS on the KDC generates both a Client/Server session key (which it encrypts by using the Client/TGS session key) and a service ticket (which consists of the subject’s identification, the client network address, the valid period of the ticket, and the Client/Server session key). The TGS encrypts the service ticket by using the secret key of the requested object (server), which only the TGS and the object know. Then the TGS sends the Client/Server session key and service ticket back to the client. See Figure 7-8.

© John Wiley & Sons, Inc.

FIGURE 7-8: Kerberos: Client/Server session key and service ticket generation (step 5).

6. The client decrypts the Client/Server session key by using the Client/TGS session key. The client can’t decrypt the service ticket, which the TGS encrypted by using the secret key of the requested object. See Figure 7-9.

7. The client can communicate directly with the requested object (server). The client sends the service ticket and an authenticator to the requested object (server). The client encrypts the authenticator (comprising the subject’s identification and a time stamp) by using the Client/Server session key that the TGS generated. The object (server) decrypts the service ticket by using its secret key. The service ticket contains the Client/Server session key, which allows the object (server) to decrypt the authenticator. If the subject identification and time stamp are valid (according to the subject identification, client network address, and valid period specified in the service ticket), communication between the client and server is established. Then the Client/Server session key is used for secure communications between the subject and object. See Figure 7-10.

© John Wiley & Sons, Inc.

FIGURE 7-9: Kerberos: Decrypt Client/Server session key (step 6).

© John Wiley & Sons, Inc.

FIGURE 7-10: Kerberos: Client/server communications (step 7).

See Chapter 5 for more information about symmetric key cryptography.

In Kerberos, a session key is a dynamic key that is generated when needed, shared between two principals, and destroyed when it is no longer needed. A secret key is a static key that is used to encrypt a session key.

RADIUS and TACACS+

The Remote Authentication Dial-In User Service (RADIUS) protocol is an open-source, client-server networking protocol — defined in more than 25 current IETF RFCs — that provides AAA services. RADIUS is an Application Layer protocol that uses User Datagram Protocol (UDP) packets for transport. UDP is a connectionless protocol, which means that it’s fast but not as reliable as other transport protocols.

RADIUS is commonly implemented in network service provider networks, as well as corporate VPNs. RADIUS is also becoming increasingly popular in corporate wireless networks. A user provides username/password information to a RADIUS client by using PAP or CHAP. The RADIUS client encrypts the password and sends the username and encrypted password to the RADIUS server for authentication.

Note: Passwords exchanged between the RADIUS client and RADIUS server are encrypted, but passwords exchanged between the workstation client and the RADIUS client are not necessarily encrypted — when PAP authentication is used, for example. If the workstation client happens also to be a RADIUS client, all password exchanges are encrypted regardless of the authentication protocol used.

Diameter is the successor protocol to RADIUS. Diameter is an Application Layer protocol that uses Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) instead of UDP for transport and uses either IP Security (IPSec) or Transport Layer Security (TLS). It supports both roaming and local AAA services and stateful or stateless modes.

The Terminal Access Controller Access Control System (TACACS) is a remote authentication control protocol, originally developed for the MILNET (U.S. Military Network), which provides AAA services. The original TACACS protocol has been significantly enhanced, as XTACACS (no longer used) and TACACS+ (which is the most common implementation of TACACS). But TACACS+ is a new protocol and therefore isn’t backward-compatible with either TACACS or XTACACS. TACACS+ is TCP based on (port 49) and supports practically any authentication mechanism (PAP, CHAP, MS-CHAP, EAP, token cards, Kerberos, and so on). The major advantages of TACACS+ are its wide support of various authentication mechanisms and granular control of authorization parameters. TACACS+ can also use dynamic passwords; TACACS uses static passwords only.

The original TACACS protocol is often used in organizations to simplify administrative access to network devices such as firewalls and routers. TACACS facilitates the use of centralized authentication credentials that are managed centrally so that organizations don’t need to manage user accounts on every device.