Chapter 7

Identity and Access Management

IN THIS CHAPTER

Controlling access to information, systems, devices, and facilities

Managing identification and authentication techniques

Integrating identity and access management in the cloud and on-premises

Understanding data access control mechanisms

Defending against access control attacks

Managing the identity and access provisioning lifecycle

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.

Identity and access management is a collection of processes and technologies that are used to control the access to critical assets. Together with other critical controls, IAM is a part of the core of information security: When implemented correctly, unauthorized persons are not permitted to access critical assets. Breaches and other abuses of information and assets are less likely to occur.

Security professionals must fully understand identity and access management concepts (including control types and authentication, authorization, and accounting), system access controls (including identification and authentication techniques, methodologies and implementation, and methods of attack), and data access controls (including access control techniques and models) within centralized, decentralized, and cloud-based computing environments. We must also understand the techniques that attackers use to compromise or bypass access management controls, and know how to strengthen those controls.

Control Physical and Logical Access to Assets

The purpose of identity and access management 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.

Information

Controlling access to information assets is primarily achieved through logical controls that determine which persons 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. This is 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 upon 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 upon the proven identity of the subject who wishes to connect.
• Application programming interfaces (APIs). A system or application can be accessed programmatically through an API that typically is used by an application that needs to access data or functions.

Systems and devices are 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 includes remote monitoring and control of utility infrastructure including electric power and distribution, water supplies, and sewage treatment. And don’t forget automated manufacturing, 3-D printing, building environmental systems, and voting machines.
• Medical devices: Equipment 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 consists of watches, fitness devices, video glasses, and the like.
• Transportation: Automobiles, self-driving cars, drones, and satellites. Also, GPS navigation, auto-pilots, air traffic control, and more.

Facilities

The purpose of controlling access to facilities is to ensure the safety of personnel who work in those facilities, as well as the protection of 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 PIN pads, these systems control which persons are 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 their optional canine assistants ensure that only authorized personnel and properly escorted personnel are able to 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 by examining a government-issued photo identification.
• Fences, walls, and gates. These help to establish a secure physical perimeter and controlled entry/exit points around a building or facility.
• Mantraps and sally ports. Combinations of passageways and entryways that 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 control vehicle flow approaching and near facilities.

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

Life safety

We are all witness to a staggering variety of devices that are now embedded with TCP/IP, complete with the addition of “smart” to the device itself. We now have “smart” automobiles, “smart” televisions, and “smart” appliances. This revolution has progressed into wearable and life safety products, such as vital signs (heart rate, respiration, and so on) monitoring, as well as insulin pumps, IV pumps, patient monitoring, pacemakers, as well as automobiles and aircraft navigation and control.

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

Manage Identification and Authentication of People, Devices, and Services

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

Identity management implementation

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

An IAM system probably is the most important function that an organization will ever implement. Next to the network itself, the IAM system typically is the most critical in an environment, because the IAM system controls access to all systems and applications.

Single sign-on (SSO)

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 leads to shortcuts in creating and recalling passwords. Left to their own devices, users create weak passwords that have only slight variations, or worse yet, they’ll use the same passwords everywhere they can. When they have multiple sets of credentials to manage, users are more likely to write them down. It 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 userids and passwords.

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

• Woo-hoo!: After you’re authenticated, you have the keys to the kingdom. Read that as access to all authorized resources! It’s the security professional’s nightmare. If login credentials for a user’s accounts are compromised, an intruder can access everything the end user was authorized to access.
• Complexity: Implementing SSO can be difficult and time-consuming. You have to address interoperability issues between different systems and applications. But, hey — that’s why you get paid (or should get paid) the big bucks!

SSO is commonly implemented by various protocols and solutions, including the following.

SECURITY ASSERTION MARKUP LANGUAGE (SAML)

The de facto protocol for authentication, SAML is used for facilitating user authentication across systems and among organizations, through the exchange of authentication and authorization information between organizations. SAML is the glue that is used to make most single sign-on (SSO) systems work.

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

KERBEROS

Kerberos, commonly used in the Sun Network File System (NFS) 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 different 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 (for example, 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-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) then 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, then sends the Client/TGS Session Key and TGT back to the client. See Figure 7-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-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 timestamp, and uses the Client/TGS Session Key to encrypt itself.) See Figure 7-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. The TGS then sends the Client/Server Session Key and Service Ticket back to the client. See Figure 7-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-6.
7. The client can then 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 timestamp) 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 then decrypt the authenticator. If the subject identification and timestamp are valid (according to the subject identification, client network address, and valid period specified in the Service Ticket), then communication between the client and server is established. The Client/Server Session Key is then used for secure communications between the subject and object. See Figure 7-7.

FIGURE 7-1: Kerberos: Logon initiation (Step 1).

FIGURE 7-2: Kerberos: Client/TGS Session Key and TGT generation (Step 2).

FIGURE 7-3: Kerberos: Logon completion (Step 3).

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

FIGURE 7-5: Kerberos: Client/Server Session Key and Service Ticket generation (Step 5).

FIGURE 7-6: Kerberos: Decrypt Client/Server Session Key (Step 6).

FIGURE 7-7: 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, then destroyed when it is no longer needed. A secret key is a static key that is used to encrypt a session key.

LDAP

Lightweight Directory Access Protocol (LDAP) is both an IP protocol and a data model. LDAP (pronounced EL-dap) is used to support authentication and directory functions for both people and resources. Several vendors have implemented LDAP, including:

• Apache Directory Server
• CA eTrust Directory
• IBM SecureWay and Tivoli Directory Server
• Microsoft Active Directory
• Novell eDirectory
• Sun Directory Server

You can also find several open-source versions of LDAP available, including OpenLDAP and tinyldap.

RADIUS

The Remote Authentication Dial-In User Service (RADIUS) protocol is an open-source, client-server networking protocol — defined in more than 25 current IETF (Internet Engineering Task Force) RFCs (Request For Comments) — that provides authentication, authorization, and accounting (AAA) services. RADIUS is an Application Layer protocol that utilizes User Datagram Protocol (UDP) packets for transport. UDP is a connection-less protocol, which means it’s fast but not as reliable as other transport protocols.

RADIUS is commonly implemented in network service provider (NSP) networks, as well as corporate remote access service (RAS) and virtual private networks (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 — if using PAP authentication, for example. If the workstation client happens to also be a RADIUS client, all password exchanges are encrypted, regardless of the authentication protocol used.

RAS

Remote Access Service (RAS) servers utilize the Point-to-Point Protocol (PPP) to encapsulate IP packets and establish dial-in connections over serial and ISDN links. PPP incorporates the following three authentication protocols:

• PAP: The Password Authentication Protocol (PAP) uses a two-way handshake to authenticate a peer to a server when a link is initially established. PAP transmits passwords in clear text and provides no protection from replay attacks (in which part of a session is captured or recorded, then played back to the system) or brute force attacks.

  A two-way handshake refers to a communications session in which the communicating devices, for example a remote workstation and a remote access server. The connection is established whereby one device sends an initial TCP SYN (Synchronize) packet to the other, and the other responds by sending an ACK (Acknowledgment) packet to indicate that the connection has been accepted.

• CHAP: The Challenge Handshake Authentication Protocol (CHAP) uses a three-way handshake to authenticate both a peer and server when a link is initially established and, optionally, at regular intervals throughout the session. CHAP requires both the peer and server to be preconfigured with a shared secret that must be stored in plain text. The peer uses the secret to calculate the response to a server challenge by using an MD5 one-way hash function. MS-CHAP, a Microsoft enhancement to CHAP, allows the shared secret to be stored in an encrypted form.
• EAP: The Extensible Authentication Protocol (EAP) adds flexibility to PPP authentication by implementing various authentication mechanisms, including MD5-challenge, S/Key, generic token card, digital certificates, and so on. Many wireless networks implement EAP.

TACACS

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). However, TACACS+ is a completely 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 for simplifying 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.

DIAMETER

This next-generation RADIUS protocol was developed to overcome some of RADIUS’s deficiencies, but it has yet to overcome RADIUS’s popularity, so it’s not yet widely implemented.

Like RADIUS, Diameter provides AAA services and is an open protocol standard defined in 11 current RFCs.

Unlike RADIUS, Diameter utilizes Transmission Control Protocol (TCP) and Stream Control Transmission Protocol (SCTP) packets to provide a more reliable, connection-oriented transport mechanism. Also, Diameter uses Internet Protocol Security (IPsec) or Transport Layer Security (TLS) to provide network security or transport layer security (respectively) — rather than PAP or CHAP (used in RADIUS) — to provide a more secure connection. See Chapter 6 for a complete discussion of TCP and SCTP, IPsec and TLS, and the OSI model.

Diameter isn’t fully backward-compatible with RADIUS, but it does provide an upgrade path for RADIUS-based environments. Diameter isn’t an acronym, but a pun on the term RADIUS. (In geometry, the diameter of a circle is twice its radius.)

SESAME

The Secure European System and Applications in a Multi-vendor Environment (SESAME) project, developed by the European Computer Manufacturers Association (ECMA), is a ticket-based system, like Kerberos, with some additional functionality. It uses both symmetric and asymmetric cryptography to distribute secret keys and securely transmit data. By using public key cryptography, SESAME can securely communicate between different organizations or security domains. It incorporates a trusted authentication server at each host (known as a Privileged Attribute Server, or PAS), employs MD5 and CRC-32 one-way hash functions, and uses two separate certificates (known as a Privileged Attribute Certificates, or PACs) to provide authentication and define access privileges. However, SESAME also has some serious security flaws in its basic implementation, including these:

• It uses an XOR function for encryption.
• It performs authentication based on a small segment of the message rather than on the entire message.
• Its key generation is not really very random.
• It’s vulnerable to password-guessing attacks. (Want to bet that somebody thought “open” was a pretty clever password?)

See Chapter 5 for more information on one-way hash functions, XOR functions, and key generation.

KryptoKnight

Developed by IBM, KryptoKnight is another example of a ticket-based SSO authentication and key distribution system that establishes peer-to-peer relationships between the Key Distribution Center (KDC) and its principals. In addition to user authentication with SSO, KryptoKnight provides two-party authentication, key distribution, and data integrity services. KryptoKnight is an extremely compact and flexible protocol that can be easily exported to other systems and applications, and it can function at any layer of the OSI model. Unlike Kerberos, KryptoKnight doesn’t require clock synchronization (it uses nonces instead).

A nonce is literally a number used once. Similar in concept to an initialization vector (see Chapter 5), a nonce is a randomly generated value (usually based on a timestamp) that can be used only once to authenticate a session.

Kerberos, SESAME, and KryptoKnight are three examples of ticket-based authentication technologies that provide SSO services.

LDAP, RAS (PAP and CHAP), RADIUS, Diameter, and TACACS are examples of centralized access control for remote access.

Cloud-based access controls

As organizations move their infrastructure and applications to cloud-based service providers, organizations are opting to employ cloud-based authentication as well.

The protocols that are used for cloud-based access management such as SAML, RADIUS, and TACACS are still used. The primary difference with cloud-based access is that the directory servers are in the cloud — either in an organization’s cloud-based infrastructure, or through a cloud-based authentication service.

Decentralized access controls

Decentralized access control systems keep user account information in separate locations, maintained by the same or different administrators, throughout an organization or enterprise. This type of system makes sense in extremely large organizations or in situations where very granular control of complex user access rights and relationships is necessary. In such a system, administrators typically have a more thorough understanding of their users’ needs and can apply the appropriate permissions — say, in a research and development lab or a manufacturing facility. However, decentralized access control systems also have various potential disadvantages. For example, organizations may apply security policies inconsistently across various systems, resulting in the wrong level of access (too much or not enough) for particular users; and if you need to disable numerous accounts for an individual user, the process becomes much more labor-intensive and error-prone.

Single/multi-factor 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. For example, 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 a personal identification number (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. Of course, passwords are often shared, stolen, guessed, or otherwise compromised — thus, they’re also one of 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 or financial institutions. A lot of online applications such as LinkedIn and Twitter have implemented multi-factor authentication as well, Although smart cards and tokens are somewhat more expensive and complex than other, less-secure authentication mechanisms, they’re not (usually) 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 multi-factor authentication provide a significant boost to authentication security. Of course, tokens, smartcards, and smartphones are sometimes lost, stolen, or damaged.

  Because of the risks associated with text messages (such as mobile phone porting scams), the U.S. National Institute of Standards and Technology (NIST) has deprecated the use of text messages for multi-factor 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 (of course, fingers and eyes can be lost, or worse). 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 identification and authentication (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 (SSO).

The identification component is normally a relatively simple mechanism based on a username or, in the case of a system or process, based on a computer or process name, Media Access Control (MAC) address, Internet Protocol (IP) address, or Process ID (PID). Identification requirements include only that it must uniquely identify the user (or system/process) and shouldn’t identify that user’s role or relative importance in the organization (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 above (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 personal identification numbers (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 there are more advanced and secure authentication technologies 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; it 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; their corporate networks, their home PCs, their Gmail or Yahoo! email accounts, their eBay accounts, and their Amazon.com accounts, for example. So an attacker who targets a specific user may be able to gain access to his or her work account by going after a less secure system, such as his or her home PC, or by compromising an Internet account (because the user has passwords conveniently stored in that bastion of security — Internet Explorer!). Internet sites and home PCs 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 actually remember and type passphrases more easily than they can remember and type a much shorter, cryptic password that requires contorted finger acrobatics to type on a keyboard.

However, passphrases also have a downside:

• Users can find passphrases inconvenient, so you may find passphrases difficult to implement. (“You mean I need to have a 20-character password now?!”)
• Not all systems support passphrases. Such systems ignore anything longer than the system limit (for example, 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 just a password (albeit, a much longer and better one) and thus shares some of the same 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 problems include that they’re

• 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 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 (which we discuss in the section “Methods of attack,” later in this chapter) 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 them as they type them. Some organizations store their users’ passwords unencrypted, hashed without salting, or encrypted with an easily discovered key; any of these methods make 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 logons (for instance, 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 non-repudiation, which is a critical component of accountability. (For more on non-repudiation, see the section “Accountability,” earlier 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 too are longer passwords. You should configure systems to require a minimum password length of ten to fifteen characters. Of course, users can easily forget long passwords or 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, or those characters may perform special functions (for example, in terminal emulation software).
• Expiration (or maximum password aging): You should set maximum password aging to require password changes at regular intervals: 30-, 60-, or 90-day periods are common.
• Minimum password aging: This prevents a user from changing his or her password too frequently. The recommended setting is one to ten days to prevent a user from easily circumventing password history controls (for example, by changing their password five times within a few minutes, then setting it back to their original password).
• Re-use: Password re-use settings (five to ten is 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 between two or three familiar passwords when they’re required to change their passwords.
• Limited attempts: This control limits the number of unsuccessful logon attempts and consists of two components: counter threshold (for example, three or five) and counter reset (for example, 5 or 30 minutes). The counter threshold is the maximum number of consecutive unsuccessful attempts permitted before some action occurs (such as automatically disabling the account). The counter reset is the amount of time between unsuccessful attempts. For example, three unsuccessful logon attempts within a 30-minute period may result in an account lockout for a set period (for example, 24 hours); but two unsuccessful attempts in 25 minutes, and then a third unsuccessful attempt 10 minutes later, wouldn’t result in an account lockout. A successful logon attempt also resets the counter.
• Lockout duration (or intruder lockout): When a user exceeds the counter threshold that we describe in the preceding bullet, 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. Of course, an attacker can use the lockout duration as a simple means to perform a Denial of Service attack (intentionally making repeated bad logon attempts to keep the user’s account locked).
• Limited time periods: This control restricts the time of day that a user can log in. For example, you can effectively reduce the period of time that attackers can compromise your systems by limiting users’ access to business hours only. However, 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 legitimately perform work at all hours of the day.
• System messages: System messages include the following:
  • Login banner: Welcome messages literally invite criminals to access your systems. Disable any “welcome” message and replace it with a legal warning instead 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 logon. Users (who only need to type in their password) find this feature convenient — and so do attackers (who only need to crack the password without worrying about matching it to a valid user account). Disable this feature.
  • Last successful logon time: After successfully logging on to the system, this message tells the user the last time that he or she logged on. If the system shows that the last successful logon for a user was Saturday morning at 2:00 a.m. and the user knows that he couldn’t possibly have logged in at that time because he has a life, he knows that someone has compromised his account, and he can report the incident accordingly.
  • Last successful login location: After successfully logging in to the system, this message tells the user the last geographical location used when he or she logged in. If the system reports that the user last logged in from some obscure, far-away country, this can be a clue that the user’s account has been compromised.

We’re sure that you know many of the following widely available and 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 (for example, !@#$%).
• Do not include your name or other personal information (such as spouse, street address, school, birthdays, and anniversaries).
• Replace some letters with numbers (for example, replace 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 (for example, sALT&pEPPER or W3’r3-n0t-in-K4ns4s-4nym0r3).
• Create a longer password that is actually a pass phrase. For instance, “I Love Green Bananas.”
• Use a combination of all the other tips in this list (for example, “Snow White and the Seven Habits of Highly Effective People” becomes SW&t7HoH3P!).
• Do not use repeating patterns between changes (for example, 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 published 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.

ONE-TIME PASSWORDS

A one-time password is a password that’s valid for one logon session only. After a single logon 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 it changes at some regular interval or event. Conversely, a static password is a password that remains the same for each logon. 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 of time. Often, what is considered 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 (PINs)

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. For example, 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.

Multi-factor authentication

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

TOKENS

Tokens are access control devices such as key fobs, dongles, 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 (for example, 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, one minute) and only for a single logon (so, if you want to log on 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 manually enters.

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 that the owner enters a secret PIN along with the generated password. Both RADIUS and Terminal Access Controller Access Control System (TACACS+; which we discuss in the section “Centralized access controls,” earlier 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 on to! However, a soft token such as Google Authenticator and Microsoft Authenticator on a smartphone would provide adequate two-factor authentication, provided 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 on 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 then enter it into the system’s password field and complete the logon procedure.

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 if it is confirmed to be genuine, the user is permitted to log on.

Digital certificate authentication also helps to enforce users logging in using only company-provisioned 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 they implement a per-device or per-user certificate on each laptop computer, not a general company certificate.

BIOMETRICS

The only absolute method for positively identifying an individual is to base authentication on some unique physical or behavioral characteristic of that individual. Biometric identification uses physical characteristics, including 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 identification and authentication (I&A) slightly differently, depending on their use:

• Physical access controls: The individual presents the required biometric characteristic and the system attempts to identify the individual by matching the input characteristic to 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 either something you know or something you have. (Although you might argue that your hand or eye is both 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 the 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 False Reject 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 False Accept Rate (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-8.) Because you can adjust the FAR and FRR by changing a system’s sensitivity, the CER is considered the most important measure of biometric system accuracy.

  • The Crossover Error Rate 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 in 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: Reliability is an important factor in any system. The system must operate continuously and accurately without frequent maintenance outages.
• Acceptability: Getting users to accept a biometric system is 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 potentially 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.

FIGURE 7-8: 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. They 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.
• Hand geometry systems: Like finger scan systems, hand geometry systems are also nonintrusive and therefore generally more easily accepted than other biometric systems. These systems generally can more accurately uniquely identify an individual than finger scan systems, 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 three-dimensional 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 actually 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: By far the most accurate of any type of 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 individual 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-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 wearing rings	Sensor wear and tear; accuracy may be affected by swelling, injury, or wearing rings

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 his or her 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. Of course, signatures commonly exhibit some slight changes because of different factors, 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 then 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 with each other. For example, know that iris pattern systems are more accurate than retina pattern systems, and be familiar with the concepts of false reject rate, false accept rate, and crossover error rate.

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 as protective, because they not only prove what they did, but they also help to 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 non-repudiation. Non-repudiation means that a user (username Madame X) can’t deny an action because her identity is positively associated with her actions. Non-repudiation is an important legal concept. If a system permits users to log in using a generic user account, or a user account that has a widely known password, or no user account at all, then 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 AAA (authentication, authorization and accounting) services records what a subject did.

Non-repudiation means that a user can’t deny an action because you can irrefutably associate him or her 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 in order to properly distinguish one user’s actions from another’s.

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

Two primary means of session timeouts are utilized:

• 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 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 utilize an auto-locking or auto-logout feature if a user has been inactive for a specific period of time.

For example, if an authorized user leaves a computer terminal unlocked or a browser window on a workstation unattended, 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 (CRT) display from being burned into the display. While today’s monitors do not require this protection, the term “screen saver” is still in common use.

Registration and proofing 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 of the workers. This is particularly critical in 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 to 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 others 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 of time.
• Birthright access. The organization should periodically review what birthright access is 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. These are

• Geographic location. This can be derived from the IP address of the user. This is not absolutely reliable, but can be helpful to determine the user’s location. Many devices, particularly smartphones and tablet computers, utilize 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 on with a personally owned or from a public kiosk workstation.
• Elapsed time since last logon. How long it has been since the user last logged on to the system or application.
• Logon attempt after failed attempts. Whether there have been recent unsuccessful logon 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 is known as risk-based authentication.

Federated identity management

Federated identity management (FIM) enables multiple organizations to use each other’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 include

• Single sign-on (SSO)
• Security Assertion Markup Language (SAML)
• OAuth
• OpenID

Credential management systems

Credential management systems enable an organization to centrally organize and control userids and passwords for users. This 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 into 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 identity and access management system.

Integrate Identity-as-a-Service

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

• Increased convenience. Users have fewer (as few as one) sets of logon credentials for access to business systems.
• Reduced risk. Users are apt to use stronger passwords, and are less likely to handle credentials unsafely (such as using sticky notes on monitors). Many organizations employ multi-factor authentication, further reducing risk.

The manner in which organizations implement a centralized identity and access management system depends on several factors, including:

• Integration effort. Newer applications have one or more interfaces available to facilitate automated account provisioning and single sign-on. Older applications usually lack these interfaces.
• Available resources. Even for easily integrated applications, there is still some effort required to perform and maintain integrations over time.
• Efficiency tolerance. If the organization is intolerant of inefficiencies, such as users having to log on to business applications many times each day, they may be more likely to pursue an IAM solution.
• Risk tolerance. If an organization as averse to the risks associated with users possessing multiple sets of logon credentials for critical business systems, it will be more apt to implement an IAM solution.

Because most organizations’ newer business systems are cloud based, many are opting to implement cloud based identity management and/or single sign-on systems. While each IAM platform has its own unique capabilities and architecture, generally an IAM system will resemble the architecture depicted in Figure 7-9.

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

Integrate Third-Party Identity Services

Organizations with on-premises systems often purchase and integrate identity management tools into their environments in order 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 LDAP (lightweight directory access protocol) are a preferred choice. There are also several commercial on-premises identity service products that 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 either implemented on-premises or cloud-based, and a few offer solutions that employ cloud-based and on-premises working together as a single identity access solution.

Implement and Manage Authorization Mechanisms

Authorization mechanisms are the portions of operating systems and applications that determine which data and functions a user is permitted to access, based upon the user’s identity. 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.

Access control techniques

Data access control techniques are generally categorized as either discretionary or mandatory. You, as a CISSP candidate, must fully understand the concept of discretionary and mandatory access controls and be able to describe specific access control methods that fall under each category.

Role-based access control

Role-based access control (RBAC) is a method for managing user access controls. Role-based access control assigns group membership according to organizational or functional roles. Individuals 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 individual (corresponding to a specific organizational role assigned to one person). Access rights and permissions for objects are assigned to groups, rather than (or in addition to) individuals. RBAC greatly simplifies the management of access rights and permissions, particularly in organizations that have large functional groups or departments, and organizations 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 just 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 there are instances where only one member is a member of a role.

The concept of role based access control is depicted in Figure 7-10.

FIGURE 7-10: Role based access control.

Rule-based access control

Rule-based access control (not to be confused with role-based access control in the preceding section) is one method of applying mandatory access control. Actually, 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 to 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. In order to access a given object, the subject must have a sensitivity level equal to or higher than the requested object. For example, 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 his or her 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. For example, given a set of files that have multiple classification levels, 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 implementing 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 explicitly identify the owner.
• Access rights and permissions: 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 contents of a file or list 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 run 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 or role-based access control include

• Lack of centralized administration.
• Dependence on security-conscious resource owners.
• Many popular operating systems defaulting to full access for everyone if the owner doesn’t explicitly set permissions.
• Difficult, if not impossible, auditing because of the large volume of individual permissions, as well as 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 for a subject to access an object is based on one or more attributes about the subject (such as the subject’s position title, department, or project assignment), as well as attributes about the object itself (such as its 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, the time of day, and other conditions.

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 www.nist.gov.

Prevent or Mitigate Access Control Attacks

Gaining access to a system or network is often on an attacker’s list of objectives. Attackers commonly use several methods of attack against access control systems, including:

• Brute-force attack: The attacker attempts every possible combination of letters, numbers, and characters to crack a password, passphrase, or PIN.
• Dictionary attack: A dictionary attack is essentially a more focused type of brute force attack in which the attacker uses a predefined word list. You can find such word lists or dictionaries, including foreign language and special-interest dictionaries, widely available on the Internet for use in password-cracking utilities such as L0phtCrack and John the Ripper. Attackers typically run these password-cracking utilities against a copy of the target system’s (or network’s) security accounts database or password file. The utility creates hashes of passwords contained in its dictionary or word list, and then compares the resulting hash to the password file. These types of programs work very quickly and effectively (see the sidebar “How much brute force does it take to crack your passwords?” in this chapter), even when organizations use complex passwords, so the key to defending against a brute-force or dictionary attack is to protect your security accounts databases and password files.
• Rainbow table: Here, an attacker steals the file or database containing hashed passwords from a target system, and then looks up the hashes in a large database called a rainbow table. This is essentially a list of all possible hashes and the original plaintext for each hash. If an organization has not “salted” its hashes, this type of attack is relatively easy to carry out.
• Buffer or stack overflow: Buffer or stack overflows constitute the most common and successful type of computer attacks today. Although often used in Denial of Service attacks, buffer overflows in certain systems or applications may enable an attacker to bypass authentication controls and gain unauthorized access to a system or directory. An overflow occurs when an application or protocol attempts to store more information than the allotted resources will allow. This causes previously entered data to become corrupted, the protocol or application to crash, or other unexpected or erratic behavior to occur. A teardrop attack is a type of stack overflow attack that exploits vulnerabilities in the IP protocol. The best defense against buffer or stack overflow attacks is to identify and patch vulnerabilities in the system, network, and applications as quickly as possible after each vulnerability is identified (and, ideally, before the affected code or application is used in a production environment).
• Man-in-the-Middle attacks: Here, an attacker intercepts messages between two parties and forwards a modified version of the original message to the intended recipient. For example, an attacker may substitute his or her own public key during a public-key exchange between two parties. The two parties believe that they’re still communicating only with each other and unknowingly encrypt messages by using the attacker’s public key, rather than the intended recipient’s public key. The attacker can then decrypt secret messages between the two parties, modify their contents as desired, and send them on to the unwary recipient.
• Packet (or password) sniffing: An attacker uses an application or device, known as a sniffer, to capture network packets and analyze their contents, such as usernames and passwords, and shared keys.
• Session hijacking: Similar to a Man-in-the-Middle attack, except that the attacker impersonates the intended recipient, instead of modifying messages in transit.
• Social engineering: This low-tech method is one of the most effective and easily perpetrated forms of attack. Common techniques involve phishing, dumpster diving, shoulder surfing, raiding cubicles (looking for passwords on monitors, under keyboards, and under mouse pads), and plain ol’ asking. This latter brazen technique can simply involve the attacker calling a user, pretending to be a system administrator and asking for the user’s password, or calling a help desk pretending to be a user and asking to have the password reset.

Organizations should employ various tactics and processes to counter access control attacks, including:

• Threat modeling. Ensures that security is a key design consideration early in the application development lifecycle. A security specification is created and tested during the design phase to identify likely threats, vulnerabilities and countermeasures for a specific application and its uses.
• Asset valuation. The process of assigning a financial value to an organization’s information assets, thereby enabling an objective measure of the systems and data that require various levels of protection.
• Vulnerability analysis. This is the process of identifying, defining, and prioritizing a system’s vulnerabilities.
• Source code review. Developers examine the source code for an application, to see whether software defects that could permit a successful attack exist in the system.
• Access aggregation. Simplify access controls by combining all of a user’s access rights, privileges, and permissions across a single or multiple systems (for example, using reduced sign-on or single sign-on).

Manage the Identity and Access Provisioning Lifecycle

Organizations must adopt formal policies and procedures to address account provisioning, review, and revocation. The phases in the IAM provisioning lifecycle 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 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:

  • Access request. A requestor, typically but not always the end user, makes a formal request to access specific data or a specific role in a system.
  • Request review. The request is reviewed by a designated person or group for appropriateness. Sometimes the reviewer may ask questions of the requestor to better understand the reason for the request.
  • Access approval. The request is approved by a designated person or group.
  • 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 access is ready and available when the user needs it, but not too soon (so as to ensure that new accounts not yet in active use are not compromised by an attacker).

• 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. For example, an employee may no longer require the same privilege levels due to rotation of duties (see Chapter 9) or a transfer or promotion.
• 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 will examine a system to see whether users are accessing it. Users who have not accessed a system (or a role in the system) for a given period of time (for example, 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 prior to the employee being notified.