Chapter 08 - Identity and Access Management.pdf

Chapter 8 Identity and Access Management THE COMPTIA SECURITY+ EXAM OBJECTIVES COVERED IN THIS CHAPTER INCLUDE: Domain 1.0: General Security Concepts 1.2. Summarize fundamental security concepts. Authentication, Authorization, and Accounting (AAA) (Authenticating people, Aut...

Chapter 8 Identity and Access Management THE COMPTIA SECURITY+ EXAM OBJECTIVES COVERED IN THIS CHAPTER INCLUDE: Domain 1.0: General Security Concepts 1.2. Summarize fundamental security concepts. Authentication, Authorization, and Accounting (AAA) (Authenticating people, Authenticating systems, Authorization models) Domain 2.0: Threats, Vulnerabilities, and Mitigations 2.5. Explain the purpose of mitigation techniques used to secure the enterprise. Access control (Access control list (ACL), Permissions) Domain 4.0: Security Operations 4.6. Given a scenario, implement and maintain identity and access management. Provisioning/de-provisioning user accounts Permission assignments and implications Identity proofing Federation Single sign-on (SSO) (Lightweight Directory Access Protocol (LDAP)), Open authorization (OAuth), Security Assertions Markup Language (SAML) Interoperability Attestation Access controls (Mandatory, Discretionary, Role-based, Rule-based, Attribute-based, Time-of-day restrictions, Least privilege) Multifactor authentication (Implementations (Biometrics, Hard/soft authentication tokens, Security keys), Factors (Something you know, Something you have, Something you are, Somewhere you are)) Password concepts (Password best practices (length, complexity, reuse, expiration, age), Password managers, Passwordless) Privileged access management tools (Just-in-time permissions, password vaulting, ephemeral credentials) Identities are one of the most important security layers in modern organizations. Identities and the accounts they are connected to allow organizations to control who has access to their systems and services; to identify the actions that users, systems, and services are performing; and to control the rights that those accounts have and don't have. All of that means that a well-designed identity and access management architecture and implementation is critical to how organizations work. This chapter begins by introducing you to the concept of identity, the set of claims made about a subject. Identities are claimed through an authentication process that proves that the identity belongs to the user who is claiming it. That user is then authorized to perform actions based on the rights and privileges associated with their user account. You will learn how privileged access management ensures that superusers and other privileged accounts have proper controls and monitoring in place. Along the way, you will learn about authentication methods, frameworks, and technologies, as well as key details about their implementation and how to secure them. Once you have explored identity and authentication, authorization, and accounting (AAA), you will learn about identity life cycles, including provisioning, identity proofing, federation, single sign-on, and multifactor authentication. You will also explore the concept of interoperability between authentication and authorization services. Finally, you will look at how filesystem permissions work with accounts to control which files users can read, write, and execute. Identity Identities are the sets of claims made about a subject. Subjects are typically people, applications, devices, systems, or organizations, but the most common application of identity is to individuals. Identities are typically linked to information about the subject, including details that are important to the use of their identity. This information includes attributes or information about the subject. Attributes can include a broad range of information, from name, age, location, or job title, to physical attributes like hair and eye color or height. Attributes are sometimes differentiated from traits. When used this way, attributes are changeable things, like the subject's title or address, whereas traits are inherent to the subject, such as height, eye color, or place of birth. When a subject wants to use their identity, they need to use one of a number of common ways to assert or claim an identity: Usernames, the most commonly used means of claiming an identity. It is important to remember that usernames are associated with an identity and are not an authentication factor themselves. Certificates, which can be stored on a system or paired with a storage device or  security token and are often used to identify systems or devices as well as individuals. Tokens, a physical device that may generate a code, plug in via USB, or connect via Bluetooth or other means to present a certificate or other information. SSH keys, which are cryptographic representations of identity that replace a username and password. Smartcards use an embedded chip. Both contactless and physical chip reader– capable cards as well as hybrid cards are broadly deployed, and cryptographic smartcards often have the ability to generate key pairs on the card itself. Lost Key Pairs Exposed or lost key pairs can be a major security hassle. Uploading private keys to public code repositories is a relatively common issue, and poor practices around passphrase management for the key pairs or even using a blank password or passphrase for SSH keys is unfortunately common. Although cloud service providers actively monitor for both key pair uploads to common third-party hosting services and for the exploits that quickly follow such exposures, ensuring that your organization trains developers and administrators on proper handling and management practices is an important security layer. If you're wondering about smartcards and their use of key pairs, well-designed smartcards typically generate key pairs on the card to prevent copies of the key pair from being stored in another location. This means that the security of the card and its key generation and storage are critical to keeping the key pairs safe. Authentication and Authorization When a subject wants to claim an identity, they need to prove that the identity is theirs. That means they need to authenticate. Authentication technologies like authentication protocols, servers, and standards all serve to ensure that the subject is who they claim that they are, that the authentication process remains safe and secure, and that capabilities like the ability to use single sign-on (SSO) work. Authorization verifies what you have access to. When combined, authentication and authorization first verify who you are, and then allow you to access resources, systems, or other objects based on what you are authorized to use. Authentication and Authorization Technologies A broad range of authentication and authorization technologies are in current use for authentication and authorization. While the Security+ exam doesn't require you to know these specifically, the exam expects you to understand how identity and access management works, which means you'll need to understand that there are many authentication frameworks and that they have different uses, features, and challenges. Exam Note The current version of the Security+ exam outline focuses on SSO-related technologies—LDAP, OAuth, and SAML—as well as 802.1x and EAP, which will be covered in Chapter 12, “Network Security.” The Extensible Authentication Protocol (EAP) is an authentication framework that is commonly used for wireless networks. Many different implementations exist that use the EAP framework, including vendor-specific and open methods like EAP-TLS, LEAP, and EAP-TTLS. Each of these protocols implements EAP messages using that protocol's messaging standards. EAP is commonly used for wireless network authentication. We'll cover EAP in more depth in Chapter 12 as part of network security as well. Challenge Handshake Authentication Protocol (CHAP) is an authentication protocol designed to provide more security than earlier protocols like PAP. CHAP uses an encrypted challenge and three-way handshake to send credentials, as shown in Figure 8.1. 802.1X is an IEEE standard for network access control (NAC), and it is used for authentication for devices that want to connect to a network. In 802.1X systems, supplicants send authentication requests to authenticators such as network switches, access points, or wireless controllers. Those controllers connect to an authentication server, typically via RADIUS. The RADIUS servers may then rely on a backend directory using LDAP or Active Directory as a source of identity information. Figure 8.2 shows an example of a common 802.1X architecture design using EAP, RADIUS, and LDAP. Remote Authentication Dial-In User Service (RADIUS) is one of the most common authentication, authorization, and accounting (AAA) systems for network devices, wireless networks, and other services. RADIUS can operate via TCP or UDP and operates in a client-server model. RADIUS sends passwords that are obfuscated by a shared secret and MD5 hash, meaning that its password security is not very strong. RADIUS traffic between the RADIUS network access server and the RADIUS server is typically encrypted using IPSec tunnels or other protections to protect the traffic.  FIGURE 8.1 CHAP challenge and response sequence FIGURE 8.2 802.1X authentication architecture with EAP, RADIUS, and LDAP RADIUS is often associated with AAA (authentication, authorization, and accounting) systems. In an AAA system, users must first authenticate, typically with a username and password. The system then allows them to perform actions they are authorized to by policies or permission settings. Accounting tracks resource utilization like time, bandwidth, or CPU utilization. Terminal Access Controller Access Control System Plus (TACACS+) is a Cisco-designed extension to TACACS, the Terminal Access Controller Access Control System. TACACS+ uses TCP traffic to provide authentication, authorization, and accounting services. It provides full-packet encryption as well as granular command controls, allowing individual commands to be secured as needed. Kerberos is a protocol for authenticating service requests between trusted hosts across an untrusted network like the Internet. Kerberos is designed to operate on untrusted networks and uses authentication to shield its authentication traffic. Kerberos users are composed of three main elements: the primary, which is typically the username; the instance, which helps to differentiate similar primaries; and realms, which consist of groups of users. Realms are typically separated by trust boundaries and have distinct Kerberos key distribution centers (KDCs). Figure 8.3 demonstrates a basic Kerberos authentication flow. FIGURE 8.3 Kerberos authentication process When a client wants to use Kerberos to access a service, the client requests an authentication ticket, or ticket-granting ticket (TGT). An authentication server checks the client's credentials and responds with the TGT, which is encrypted using the secret key of the ticket-granting service (TGS). When the client wants to use a service, the client sends the TGT to the TGS (which is usually also the KDC) and includes the name of the resource it wants to use. The TGS sends back a valid session key for the service, and the client presents the key to the service to access it. As you can see, authentication systems and processes can be complex, with a focus on ensuring that account holders are properly authenticated and that they are then given access to the specific resources or privileges that they should have. In modern zero-trust environments where continuous authorization checks are normal, this places an even heavier load on identity and authorization infrastructure. Single Sign-On Single sign-on (SSO) systems allow a user to log in with a single identity and then use multiple systems or services without reauthenticating. SSO systems provide significant advantages because they simplify user interactions with authentication and authorization systems, but they require a trade-off in the number of identity-based security boundaries that are in place. This means that many organizations end up implementing SSO for many systems but may require additional authentication steps or use of an additional privileged account for high-security environments. You're likely using SSO every day. If you log into a Google service like Gmail, you're also automatically authenticated to YouTube and other Google-owned applications. You're also likely to encounter it in enterprise environments where it is commonly enabled to smooth out work processes. Directory services like the Lightweight Directory Access Protocol (LDAP) are commonly deployed as part of an identity management infrastructure and offer hierarchically organized information about the organization. They are frequently used to make available an organizational directory for email and other contact information. Figure 8.4 shows an example of an LDAP directory hierarchy for Inc.com, where there are two organizational units (Ous): security and human resources. Each of those units includes a number of entries labeled with a common name (CN). In addition to the structure shown in the diagram, each entry would have additional information not shown in this simplified diagram, including a distinguished name, an email address, phone numbers, office location, and other details.  FIGURE 8.4 LDAP organizational hierarchy Since directories contain significant amounts of organizational data and may be used to support a range of services, including directory-based authentication, they must be well protected. The same set of needs often means that directory servers must be publicly exposed to provide services to systems or business partners who need to access the directory information. In those cases, additional security, tighter access controls, or even an entirely separate public directory service may be required. The Security+ exam outline doesn't focus on directory services like LDAP as directory services. Instead, it lists LDAP under the heading of single sign- on. While LDAP is commonly used as part of SSO infrastructures, it's important to remember that it is a directory service as well. Internet-based systems and architectures often rely on a number of core technologies to accomplish authentication and authorization that can also be used for single sign-on. These include the following: Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization information. SAML is often used between identity providers and service providers for web-based applications. Using SAML means that service providers can accept SAML assertions from a range of identity providers, making it a common solution for federated environments like those we will discuss later in this chapter. OpenID is an open standard for decentralized authentication. OpenID identity providers can be leveraged for third-party sites using established identities. A common example of this is the “Log in with Google” functionality that many websites provide, but Google is not the only example of a major OpenID identity provider. Microsoft, Amazon, and many other organizations are OpenID identity providers (IdPs). Relying parties (RPs) redirect authentication requests to the IdP and then receive a response with an assertion that the user is who they claim to be  due to successful authentication, and the user is logged in using the OpenID for that user. OAuth is an open standard for authorization used by many websites. OAuth provides a method for users to determine what information to provide to third-party applications and sites without sharing credentials. You may have experienced this with tools like Google Drive plug-ins that request access to your files or folders, or when you use a web conferencing tool that requests access to a Google calendar with a list of permissions it needs or wants to perform the requested function. The Security+ exam outline does not include OpenID, but it is a commonly deployed technology. We've included it here so you'll be aware of it if you run into it outside of the exam. These technologies are a major part of the foundation for many web-based SSO and federation implementations. Outside of web-based environments, single sign-on is commonly implemented using LDAP and Kerberos, such as in Windows domains and Linux infrastructures. Federation In many organizations, identity information is handled by an identity provider (IdP). Identity providers manage the life cycle of digital identities from creation through maintenance to eventual retirement of the identity in the systems and services it supports. Identity providers are often part of federated identity deployments, where they are paired with relying parties, which trust the identity provider to handle authentication and then rely on that authentication to grant access to services. Federation is commonly used for many web services, but other uses are also possible. Here are a number of terms commonly used in federated environments that you should be aware of: The principal, typically a user Identity providers (IdPs), who provide identity and authentication services via an attestation process in which the IdP validates that the user is who they claim to be Service providers (SPs), who provide services to users whose identities have been attested to by an identity provider and then perform the requested function Attestation is a formal verification that something is true—thus, an IdP can attest that a user is who they say they are because they have presented an identifier and have been authorized by the IdP, which then provides the attestation. In addition, the term relying party (RP) is sometimes used, with a similar meaning to a service party. An RP will require authentication and identity claims from an IdP. As you might expect, given the broad range of identity management and authentication and authorization systems we have looked at thus far in the chapter, interoperability is a key concern when connecting different organizations together. Fortunately, SAML, OAuth, OpenID, and similar technologies help to ensure that standards-based interoperability is possible. In those scenarios, OpenID Connect and SAML are both used for federated authentication, whereas OAuth is used to handle authorization of access to protected resources. Many cloud service providers support some form of identity federation to allow easier onboarding to their service. In addition, cloud services typically have some form of internal identity and authorization management capability that allows organizations that adopt their tools to manage users. Since organizations often use multiple cloud services, using federated identity management is common to allow management of users across multiple services. Authentication Methods Once you've claimed an identity by providing a username, a certificate, or some other means, your next step is to prove that the identity belongs to you. That process is the core of the authentication process. Using a password remains the most common means of authentication, but passwords have a number of flaws. The first, and most important, is that passwords can be stolen and used by third parties with relative ease. Unless the owner of the password changes it, the password will remain usable by attackers. Passwords are also susceptible to brute- force attacks, allowing a determined attacker, who can spend enough time freely using them to eventually break into a system. This has led to the use of multiple factors, preventing a lost or stolen password from allowing easy account compromise. Passwords The Security+ exam outline focuses on a number of password best practices and configuration settings. Password best practices vary. NIST provides a set of recommendations that are broadly adopted as part of NIST SP 800-63B as part of their Digital Identity Guidelines. Their best practices include using Show Password to prevent typos, using password managers, ensuring secrets are stored securely using salting and secure hashing methods, locking accounts after multiple attempts, and employing multifactor authentication. You can read NIST 800-63A, B, and C at https://pages.nist.gov/800-63-3. 63A includes information on enrollment and identity proofing, 63B focuses on authentication and life cycle management, and  63C tackles federation and assertions. In addition to those broad recommendations, NIST specifically suggests that modern password practices follow a few guidelines: Reducing password complexity requirements and instead emphasizing length Not requiring special characters Allowing ASCII and Unicode characters in passwords Allowing pasting into password fields to allow password managers to work properly Monitoring new passwords to ensure that easily compromised passwords are not used Eliminating password hints NIST also recommends that organizations and security practitioners understand threats to authentication, since defenses and controls need to address the risks that the organization itself faces and that may change over time. Setting password requirements was historically one of the few controls available to help protect passwords from brute-force attacks and to help handle the issue of stolen, reused, or otherwise exposed passwords. Common password settings found in most operating systems and many services support configuration options for passwords, including: Length, which has typically been one of the best controls to prevent passwords brute forcing. Complexity, which influences password attacks by ensuring that larger character sets are required for brute-force attacks and in many implementations, also prevents the use of common words or a series of repeated characters. Reuse limitations are set to ensure that users don't simply set their password to a previous password, which may have been exposed, reused, or compromised. Expiration dates are set to ensure that passwords are not used for extended periods of time. Expiration dates often create additional support work for help desks, which means many organizations have moved to not requiring password changes as frequently—or ever—if they have multifactor authentication (MFA) in place. Age settings for passwords are used to ensure that users do not simply reset their passwords over and over until they bypass reuse limitations, allowing them to return to their former password. Figure 8.5 shows Windows local password setting options that support these configuration options.  FIGURE 8.5 Windows local password policy options Some of these settings conflict with NIST's current recommendations, and you may encounter organizational policies, practices, or technical implementations that limit the options you can use in each scenario. That means that you'll have to determine the best balance of password requirements based on the technical capabilities and policies your organization has in place. Since Microsoft has gone to great lengths to ensure backward compatibility for Windows systems and servers, insecure password options have existed for years. One of the most common password length setting requirements for many organizations was driven by the LAN Manager (LM) hash. This short hash was generated if passwords had less than 15 characters in them, resulting in many organizations setting their password requirement to 15 or more characters to prevent insecure hash storage and usage. You can read more about this at https://learn.microsoft.com/en- us/troubleshoot/windows-server/windows-security/prevent-windows-store-lm- hash-password. Password Managers Password managers like 1Password and Bitwarden are designed to help users create secure passwords, then store and manage them along with related data like notes, URLs, or other important information associated along with the secrets they're used to store. Windows, macOS, and even browsers also provide password managers. Windows Credential Manager can store and manage both web and Windows credentials, as shown in Figure 8.6. Apple's Keychain syncs to Apple's iCloud and synchronizes passwords and other secure information across Apple devices. FIGURE 8.6 Windows Credential Manager Use of password managers for both individuals and organizations is common, and using a password manager is a common recommendation due to reduction in password reuse and the greater likelihood of using complex and long passwords when password managers are available and easy to use. What Happens When Your Password Manager Is Breached? In December 2022, LastPass, one of the most commonly used password managers, announced that they had suffered two security incidents. LastPass noted in a post in March 2023 that the first incident led to a second incident in which software repositories, backups of customer vault data, and MFA authenticator seeds as well as phone numbers used for MFA backup options were exposed along with other data. The exposure resulted in recommendations for customers to take actions like resetting master passwords in some scenarios, regenerating MFA shared secrets in some cases, and various other actions. Since LastPass had customer secrets in databases that were exposed, and there were concerns about how those secrets were protected, organizations and individuals faced concerns about the ongoing security of the passwords stored by the tool. You can read the post with information about the breaches and recommendations for customer action for both individuals and enterprise customers at https://blog.lastpass.com/2023/03/security-incident-update-recommended- actions. Passwordless Passwordless authentication is becoming increasingly common, with authentication relying on something you have—security tokens, one-time password applications, or certificates—or something that you are, like biometric factors. For individuals, one option that provides a high level of security is a security key. These are hardware devices that support things like one-time passwords, public key cryptography for security certificates, and various security protocols like FIDO and Universal 2nd Factor (U2F). They're available in a variety of form factors and with different types of connectivity; most provide USB and/or Bluetooth. We cover biometric factors a few pages from now—for now, just keep in mind that they're factors that rely on your body like your fingerprint, the sound of your voice, or even vein patterns under your skin! In a typical passwordless authentication scenario, a user might present a USB FIDO2- enabled security key. The key has previously been provisioned as part of the user's enterprise environment and is plugged into the system the user wants to log in with. The key interacts with the authentication system as part of the login and will require a user to enter a PIN or use a fingerprint to unlock the key, and the user is logged in without typing in a password or other factor. Passwordless authentication is intended to reduce the friction and risks that are associated with passwords. The Security+ exam outline doesn't mention FIDO2, but it's a standard you're likely to run into in this context. FIDO2 is an open authentication standard that supports both the W3C Web Authentication specification and the Client to Authenticator Protocol (CTAP), which is used to communicate between browsers, operating systems, and similar clients and the FIDO2 device. FIDO2 authentication relies on key pairs, with a public key sent to services and private keys that remain on the device. Multifactor Authentication One way to ensure that a single compromised factor like a password does not create undue risk is to use multifactor authentication (MFA). Multifactor authentication is becoming broadly available and in fact is increasingly a default option for more security- conscious organizations. Now, a phished account and password will not expose an individual or an organization to a potential data breach in most cases. The Security+ exam outline defines four factors: Something you know, including passwords, PINs, or the answer to a security question. Something you have like a smartcard, USB or Bluetooth token, or another object or item that is in your possession, like the Titan security key shown in Figure 8.7. FIGURE 8.7 A Titan USB security key  The Fast IDentity Online (FIDO) protocols provided by the FIDO Alliance use cryptographic techniques to provide strong authentication. If you're interested in using tokens or want to know more about how they are implemented for secure authentication using key pairs, you can read more at https://fidoalliance.org/how-fido-works. Something you are, which relies on a physical characteristic of the person who is authenticating themselves. Fingerprints, retina scans, voice prints, and even your typing speed and patterns are all included as options for this type of factor. Somewhere you are, sometimes called a location factor, is based on your current location. GPS, network location, and other data can be used to ensure that only users who are in the location they should be can authenticate. As with all security technologies, it is only a matter of time until new attacks against multifactor authentication compromise our MFA systems. Current attacks already focus on weak points in systems that use text messages for a second factor by cloning cellphones or redirecting SMS messages sent via VoIP systems. Targeted attacks that can steal and quickly use a second factor by infecting mobile phones and other similar techniques will continue to be increasingly necessary for attackers to succeed in compromising accounts, and thus will appear far more frequently in the near future. One-Time Passwords A common implementation of a second factor is the use of one-time passwords (OTP). One-time passwords are an important way to combat password theft and other password-based attacks. As its name implies, a one-time password is usable only once. An attacker can obtain a one-time password but cannot continue using it, and it means that brute-force attacks will be constantly attempting to identify a constantly changing target. Though it is possible that a brute-force attack could randomly match a one-time password during the time that it is valid, the likelihood of an attack like that succeeding is incredibly small, and common controls that prevent brute-force attacks will make that type of success essentially impossible. There are two primary models for generation of one-time passwords. The first is time- based one-time passwords (TOTP), which use an algorithm to derive a one-time password using the current time as part of the code-generation process. Authentication applications like Google Authenticator use TOTP, as shown in Figure 8.8. The code is valid for a set period of time and then moves on to the next time-based code, meaning that even if a code is compromised it will be valid for only a relatively short period of time. The codes shown are valid for a set period of time, shown by the animation of a pie chart in the bottom-right corner, and in the application they turn red as they are about to expire and be replaced with a new code. The other one-time password generation model is HMAC-based one-time password (HOTP). HMAC stands for hash-based message authentication codes. HOTP uses a seed value that both the token or HOTP code-generation application and the validation server use, as well as a moving factor. For HOTP tokens that work when you press a button, the moving factor is a counter, which is also stored on the token and the server. HOTP password generators, like the PayPal token shown in Figure 8.9 rely on an event, such as pressing a button, to cause them to generate a code. Since the codes are iterative, they can be checked from the last known use of the token, with iterations forward until the current press is found. Like TOTP solutions, authentication applications can also implement HOTP and work the same way that a hardware token implementation does. FIGURE 8.8 Google authenticator showing TOTP code generation  FIGURE 8.9 An HOTP PayPal token In addition to application and hardware tokens, a third common implementation of a one-time password system is the use of codes based on the short message service (SMS), or text message. In this model, when a user attempts to authenticate, an SMS message is sent to their phone, and they then input that code as an additional factor for the authentication process. Attacking One-Time Passwords One-time passwords aren't immune to attack, although they can make traditional attacks on accounts that rely on acquiring passwords fail. TOTP passwords can be stolen by either tricking a user into providing them, gaining access to a device like a phone, where they are generated, or otherwise having near real-time access to them. This means that attackers must use a stolen TOTP password immediately. One-time passwords sent via SMS can be redirected using a cloned SIM, or if the phone is part of a VoIP network, by compromising the VoIP system or account and redirecting the SMS factor. Attacks against SMS OTP as well as application-based OTP are on the rise as malicious actors recognize the need to overcome multifactor authentication. For now, however, one of the most successful attacks is simply overwhelming end users with repeated validation requests so that they enter an OTP value to make the requests stop! In situations where hardware and software tokens as well as SMS aren't suitable, some organizations will implement a phone call–based push notification. Push notifications are messages sent to a user to inform them of an event, in this case an authentication attempt. If users respond to the phone call with the requested validation—typically by pushing a specific button on the keypad—the authentication can proceed. Phone calls suffer from a number of issues as an authentication factor, including lower speed, which can cause issues with login timeouts; the potential for hijacking of calls via a variety of means; and additional costs for the implementing organization due to phone call costs. Although one-time passwords that are dynamically generated as they are needed are more common, at times, there is a need for a one-time password that does not require a device or connectivity. In those cases, static codes remain a useful option. Static codes are also algorithmically generated like other one-time passwords but are pre-generated and often printed or stored in a secure location. This creates a new risk model, which is that the paper they are printed on could be stolen, or if they are stored electronically, the file they're stored in could be lost or accessed. This would be equivalent to losing a button-press activated token or an unlocked smartphone, so static codes can be dangerous if they are not secured properly. Biometrics Biometric factors are an example of the “something you are” factor, and they rely on the unique physiology of the user to validate their identity. Some biometric technologies also count as one of the factors that the Security+ exam outline describes, because they are something you are, like a voice print or gait. Some of the most common biometric technologies include the following: Fingerprints, which check the unique patterns of ridges and valleys on your fingertips using either optical, ultrasonic, or capacitive scanners. Fingerprint scanning has been broadly deployed within both Windows, using fingerprint scanners on laptops, and Android and Apple devices that use fingerprint readers. Retina scanning uses the unique patterns of blood vessels in the retina to tell users apart. Iris recognition systems use pattern recognition and infrared imaging to uniquely identify an individual's eyes. Iris recognition can be accomplished from farther away than retina scans, making it preferable in many circumstances. Facial recognition techniques match specific features to an original image in a database. Facial recognition is widely used in Apple iPhone for Face ID, making it a broadly deployed biometric technology. Voice recognition systems rely on patterns, rhythms, and the sounds of a user's voice itself to recognize the user. Vein recognition, sometimes called vein matching or vascular technology, uses scanners that can see the pattern of veins, often in a user's finger or arm. Vein scanners do not need to touch the user, unlike fingerprint scanners, making them less likely to be influenced by things like dirt or skin conditions. Gait analysis measures how a person walks to identify them. Biometric technologies are assessed based on four major measures. The first is Type I errors, or the false rejection rate (FRR). False rejection errors mean that a legitimate biometric measure was presented and the system rejected it. Type II errors, or false acceptance errors, are measured as the false acceptance rate (FAR). These occur when a biometric factor is presented and is accepted when it shouldn't be. These are compared using a measure called the receiver operating characteristic (ROC). The ROC compares the FRR against the FAR of a system, typically as a graph. For most systems, as you decrease the likelihood of false rejection, you will increase the rate of false acceptance, and determining where the accuracy of a system should be set to minimize false acceptance and prevent false rejection is an important element in the configuration of biometric systems. Evaluating Biometrics When you assess biometrics systems, knowing their FAR and FRR will help you determine their efficacy rates, or how effective they are at performing their desired function. The FIDO Alliance sets their FRR threshold for acceptance for certification for biometric factors at 3 percent of attempts and at.01 percent for FAR for their basic BioLevel1 requirement. They also add another metric that the Security+ exam outline doesn't: the Imposter Attack Presentation Match Rate (IAPMR), a measure that tackles the question of how often an attack will succeed. IAPMR is a challenging measure because it requires attacks that are designed to specifically take advantage of the weaknesses of any given biometric system. In addition to measures like these, in the real world you have to assess the user acceptance of the biometric system. Retina scanners failed to take off because most people don't want to bend over and peer into a retina scanner. At the same time, early generations of fingerprint scanners had a tough time scanning many fingerprints, and even now people who have worn their fingerprints off through manual labor or due to chemical or other exposure can't use many fingerprint readers. That means that biometric systems must often be deployed with a backup method available for some percentage of the user population, even if they will consent to use the system. Thus, deploying biometrics isn't as easy of a solution as it may sound up front. That doesn't mean they're not useful; the broad usage of Apple's Face ID and Touch ID, as well as Android's wide adoption of fingerprint readers, show that a biometric factor can be implemented successfully for many users in a reasonable way. If you'd like to read more about this topic, Duo has an extensive and well-written explanation of multiple biometric technologies that you can check out at https://duo.com/labs/research/the-good-and-bad-of-biometrics. Accounts Claiming an identity and being authorized to access a system or service requires an account. Accounts contain the information about a user, including things like rights and permissions that are associated with the account. Account Types There are many types of accounts, and they can almost all be described as one of a few basic account types: User accounts, which can run the gamut from basic access to systems, devices, or applications to power users with broad rights and privileges. A common example of a user account is a Windows Standard User account, which relies on User Account Control and an administrator password to be entered when installing applications, editing the Registry, or other privileged actions. Privileged or administrative accounts, like the root account or members of the wheel group on Linux and Unix systems, and the Windows default Administrator account. Shared and generic accounts or credentials, which are often prohibited by security policies. Although shared accounts can be useful, many organizations build delegation capabilities to allow multiple users to act in the same way or with the same rights to avoid shared account issues such as the inability to determine who was logged into the shared account or what actions each user who shares the account took. Guest accounts, which are provided to temporary users and which typically have very limited privileges, but are also likely to have far less information about the user who uses them, if any. Service accounts associated with applications and services. Service accounts should not be used for interactive logins, and many organizations have specific security policies in place to ensure service account security. Provisioning and Deprovisioning Accounts The user account life cycle includes many phases, but two of the most important are when accounts are provisioned, or created, and when they are deprovisioned, or terminated. When an account is provisioned, it is created and resources, permissions, and other attributes are set for it. In many instances, provisioning an account may also involve identity proofing, which is the process of ensuring that the person who the account is being created for is the person who is claiming the account. Common examples include providing government-issued credentials to open bank accounts or to create an account for government-sponsored sites to pay taxes. Organizations often identity-proof using government IDs as well as personal information that is unlikely another individual would possess. Account creation and identity proofing are commonly done during employee onboarding. Onboarding processes related to account creation include adding employees to groups and ensuring they have the right permissions to accomplish their role, as well as providing appropriate training to the employee. Creating an account and ensuring the right individual gains access to it is important, but providing the account with appropriate rights and permissions is what allows the account to be useful. This permissions assignment and permission management is a critical task in organizations. The concept of least privilege is at the core of permission management, and organizations seek to ensure that roles are associated with privileges to make privilege management easier. Managing specific rights for every user in an organization is a complex and error-prone task even in relatively small organizations and is impossible at scale. A key concern for organizations that manage permissions for users, groups, and roles over time is permission creep. Permission creep occurs when users take on new roles or are granted new permissions based on tasks they are doing. Over time, this tends to result in users accruing a broader set of permissions that may not match their current role. A common associated issue is that managers and others may request roles based on an individual with requests often phrased as “Give the new staff member permission that match the person who they are replacing.” If permission creep has occurred, that means the new individual will have the same overly broad permissions. Long-term permission management is a critical part of identity and access management systems and processes, and permission management with a least privilege approach is a key security control. In addition to this discussion of privileges at the conceptual level, we'll talk more about filesystem permissions a bit later in this chapter. For now, keep in mind the implication of permission assignment and long-term maintenance of permissions as employees and roles change in an organization. When an account is terminated, a process known as deprovisioning occurs. This removes the account, permissions, and related data, files, or other artifacts as required by the organization's processes and procedures. Deprovisioning is an important step because it helps to ensure that dormant accounts are not available for attackers to compromise or co-opt. Limited deprovisioning tasks may also be associated with role changes where an account or group of accounts have rights and privileges removed when a change is made. It may be tempting to simply disable an account in case it is needed again in the future. While disabling accounts may be done in specific circumstances, completely removing accounts removes the opportunity for attacks that reenable them or that use improperly disabled or improperly reenabled accounts. Thus, deletion of accounts is typically a preferred process in the deprovisioning process. Privileged Access Management Privileged access management (PAM) tools can be used to handle the administrative and privileged accounts you read about earlier in this section. PAM tools focus on ensuring that the concept of least privilege is maintained by helping administrators specify only the minimum set of privileges needed for a role or task. PAM tools often provide more detailed, granular controls; increased audit capabilities; and additional visibility and reporting on the state of privileged accounts. The Security+ exam outline addresses three specific features of PAM tools that you'll want to be aware of for the exam: Just-in-time (JIT) permissions are permissions that are granted and revoked only when needed. This is intended to prevent users from having ongoing access when they don't need that access on an ongoing basis. Users will typically use a console to “check out” permissions, which are then removed when the task is completed or a set time period expires. This helps to prevent privilege creep but does add an additional step for use of privileges. Password vaulting is commonly used as part of PAM environments to allow users to access privileged accounts without needing to know a password. Much like JIT permissions, password vaulting often allows privileged credentials to be checked out as needed while creating a logged, auditable event related to the use of the credentials. Password vaults are also commonly used to ensure that passwords are available for emergencies and outages. Ephemeral accounts are temporary accounts with limited lifespans. They may be used for guests or for specific purposes in an organization when a user needs access but should not have an account on an ongoing basis. Setting an appropriate lifespan and ensuring that the account is deprovisioned is key to the successful implementation of ephemeral accounts. Access Control Schemes User accounts and account controls are important, but systems also implement access control schemes to determine which users, services, and programs can access various files or other objects that they host. The Security+ exam covers a number of common access control schemes, which we'll look at next. Mandatory access control (MAC) systems rely on the operating system to enforce control as set by a security policy administrator. In a MAC implementation, users do not have the ability to grant access to files or otherwise change the security policies that are set centrally. MAC implementations were once only found in government and military systems, but now they can be found in specific high-security systems like SELinux and in Windows as Mandatory Integrity Control (MIC). MAC implementations remain relatively rare overall compared to discretionary access control. Discretionary access control (DAC) is an access control scheme that many people are used to from their own home PCs. The most common type of discretionary access control assigns owners for objects like files and directories, and then allows the owner to delegate rights and permissions to those objects as they desire. Linux file permissions provide an easy example of this. The owner of a file (or directory) can set permissions that apply to the owner, the group, or the world, and they can choose to allow the file to be read, modified, or executed. Role-based access control (RBAC) systems rely on roles that are then matched with privileges that are assigned to those roles. This makes RBAC a popular option for enterprises that can quickly categorize employees with roles like “cashier” or “database administrator” and provide users with the appropriate access to systems and data based on those roles. RBAC systems boil down to three primary rules: Role assignment, which states that subjects can use only permissions that match a role they have been assigned. Role authorization, which states that the subject's active role must be authorized for the subject. This prevents subjects from taking on roles they shouldn't be able to. Permission authorization, which states that subjects can use only permissions that their active role is allowed to use. Together, these three rules describe how permissions can be applied in an RBAC system. With these three rules, role hierarchies can be built that allow specific permissions to be available at the right levels based on roles in any given environment. An important detail for RBAC systems is that many support multiple roles for subjects. That means that you may have an active role, as well as other roles you could use. A familiar example of this might be the ability to use the sudo command on a Linux system. Users have a role as themselves (a user role), and they can also assume a superuser (root) role. When the root, or superuser, role is active, they can perform actions that root is authorized to perform. When it is not, they cannot perform those actions or access objects that are restricted to access by the root role. Rule-based access control, also sometimes called RBAC (and sometimes RuBAC to help differentiate it from role-based access control) is applied using a set of rules, or access control lists (ACLs), that apply to various objects or resources. When an attempt is made to access an object, the rule is checked to see if the access is allowed. A common example of a rule-based access control is a firewall ruleset. Attribute-based access control (ABAC) relies on policies that are driven by attributes of the users. This allows for complex rulesets based on combinations of attributes that provide users with specific rights that match the attributes they have. Since attributes can be set in specific contexts, this also means that ABAC schemes can be very flexible. The downside of ABAC policies is that they can also be complex to manage well due to their flexibility. Attribute-based access control schemes are useful for application security, where they are often used for enterprise systems that have complex user roles and rights that vary depending on the way and role that users interact with a system. They're also used with databases and content management systems, microservices, and APIs for similar reasons. In addition to these common access control schemes, the Security+ exam outline groups in two additional concepts under access controls: Time-of-day restrictions, which limit when activities can occur. An example in Windows is where logon hours can be set via Active Directory, defining the hours that a user or group of users can be logged onto a system. This can help prevent abuse of user accounts or system access when users have well-defined work hours. Least privilege, the concept that accounts and users should only be given the minimum set of permissions and capabilities necessary to perform their role or job function. Least privilege is a common concept throughout information security practices and should be designed into any permissions or access scheme. Filesystem Permissions The final type of access controls that you will need to know for this section of the Security+ exam is filesystem controls. Filesystem controls determine which accounts, users, groups, or services can perform actions like reading, writing, and executing (running) files. Each operating system has its own set of filesystem permissions and capabilities for control, and you should make sure you are familiar with both Linux and Windows permissions for the exam. Linux filesystem permissions are shown in file listings with the letters drwxrwxrwx, indicating whether a file is a directory, and then displaying user, group, and world (sometimes called other) permissions. Figure 8.10 shows how this is displayed and a chart describing the numeric representation of these settings that is frequently used for shorthand when using the chmod Linux command used to change permissions. If you aren't familiar with Linux permissions and the chmod command, you should spend some time familiarizing yourself with both. You should know how to set and read permissions using both character and numeric representations; the order of user, group, and others rights; and what those rights mean for a given user based on their account's rights and group membership.  FIGURE 8.10 Linux/Unix file permissions Windows file permissions can be set using the command line or the GUI. Figure 8.11 shows the properties of a file using the GUI with administrators allowed full control including Modify, Read & Execute, Read, and Write with no permissions denied. Note that the permissions are similar but not quite the same as those set in Linux. Windows provides full control (like rwx or 7 in Linux). FIGURE 8.11 Windows file permissions The modify permission allows viewing as well as changing files or folders. Read and execute does not allow modification or changes but does allow the files to be run, whereas read and write work as you'd expect them to. Filesystem permissions are an important control layer for systems, and improperly set or insecure permissions are often leveraged by attackers to acquire data and to run applications that they should not be able to. In fact, attacks we explore in other chapters like directory traversal attacks on web servers rely on weak filesystem permissions to allow attackers to access files outside of those that should be available to web servers on a properly secured system. Summary Identity and access management is a key element in organizational security. Authentication is the process of proving your claim to an identity by providing one or more factors that include something you know, something you have, something you are, or somewhere you are. Authorization provides authenticated users with the privileges and rights they need to accomplish their roles. User accounts range from guest and normal users to service accounts and privileged administrative accounts. Account policies shape details and requirements for each account, including when accounts should be locked out or disabled. There are a wide range of authentication methods and technologies deployed throughout organizations. In addition, technologies like RADIUS, LDAP, EAP and CHAP, OAuth, OpenID, and SAML are commonly used as part of single sign-on infrastructure. Single sign-on (SSO) allows users to log in once and use their identities throughout many systems, whereas federation uses identity providers to authenticate users, who can then use those identities at various service providers and relying party locations without having to have a distinct identity there. Interoperability between identity and authorization systems is enabled by standards and shared protocols, making federation possible. Attestation provides validation that a user or identity belongs to the user claiming it. Multifactor authentication has helped limit the problems with passwords such as password theft, reuse, and brute-force attacks. Biometric authentication, which uses physical traits such as your fingerprint, retina print, or facial recognition, have become commonplace, but knowing how often they will incorrectly allow the wrong person in or reject a legitimate user is critical. Both hardware- and software-based authentication tokens are commonly used, with hardware security keys becoming increasingly common. Password vaults (or safes) provide cryptographically secured storage to keep passwords secure, and enterprise deployments support multiple users and controlled access schemes. Password best practices have changed as multifactor authentication has become more common. While configurations still often allow settings for length, complexity, reuse, expiration, and age, NIST and other organizations have begun to focus on length as the primary control to avoid brute forcing. Passwordless authentication is becoming more common, replacing passwords with secure tokens or applications. Access control schemes like attribute-based access control, discretionary access control, mandatory access control, and role-based access control all provide ways to determine which subjects can perform actions on objects. Privileged access management ensures that administrative users are well managed. Just-in-time permissions and ephemeral accounts are two of the many techniques that PAM systems employ to enable better control of privileged accounts.