Chapter 8
Identity and Access Management Security

---

THE COMPTIA CYBERSECURITY ANALYST (CYSA+) EXAM OBJECTIVES COVERED IN THIS CHAPTER INCLUDE:

• Domain 2.0: Software and Systems Security
  • 2.1 Given a scenario, apply security solutions for infrastructure management.

---

Identities—the collection of user information, credentials, rights, roles, group memberships, and other attributes and information about individuals and accounts—are among the most critical assets that an organization owns. Identities, and the access and rights that we grant to them, provide the keys to systems, services, and data, making them targets for both internal and external attackers.

As organizational security has improved, the ability of attackers to simply target unpatched or unprotected systems exposed to the Internet has decreased, making it increasingly necessary for them to obtain accounts to gain and maintain access to their targets. Now, attackers frequently need to have valid user credentials to compromise systems, networks, or services. This means you need to understand both the threats that identity and access systems and technologies face and how to defend against them.

In this chapter, we will explore the major threats to identities, credentials, and the authentication, authorization, and accounting systems behind them. We will look at the ways in which identity can be used as a security layer to provide an important part of a defense-in-depth plan and will review how identity management integrates into a security operations design. Finally, we will discuss federated identities and single sign-on security, an increasingly important element of both cloud services and many organizational support strategies.

Understanding Identity

Identities, or the set of claims made about an individual or account holder that are made about one party to another party (such as a service provider, application, or system), are a key part of authentication, authorization, and accounting. The user accounts we use to log in require the ability to uniquely identify individuals and other subjects such as services to allow for permissions, rights, group memberships, and attributes to be associated with them.

The attributes associated with an identity include information about a subject and often include their name, address, title, contact information, and other details about the individual. These attributes may be used as part of authentication processes, may be used to populate directory information, or could be collected to help meet other organizational needs or business purposes.

---

Some schemes call out traits and preferences separately from attributes. In those designs, traits are inherent parts of the subject like their hair color, nationality, or birthday. Preferences are based on a person's choices like their favorite color or band.

---

Identities are used as part of the authentication, authorization, and accounting (AAA) framework that is used to control access to computers, networks, and services. AAA systems authenticate users by requiring credentials like a username, a password, and possibly a biometric or token-based authenticator. Once individuals have proven who they are, they are then authorized to access or use resources or systems. Authorization applies policies based on the user's identity information and rules or settings, allowing the owner of the identity to perform actions or to gain access to systems. The ongoing management of these rights is known as privilege management. The accounting element of the AAA process is the logging and monitoring that goes with the authentication and authorization. Accounting monitors usage and provides information about how and what users are doing.

---

Exam Note

Pay particular attention to the concept of privilege management—it shows up in the exam objectives, and we discuss it throughout the chapter.

---

Central management of identities normally occurs in identity and access management (IAM) systems. IAM systems are built to create, store, and manage identity information as well as the permissions, groups, and other information needed to support the use of identities. Figure 8.1 shows a high-level view of identity management for an organization. The data to create identities comes from systems of record like the organization's ERP, HR systems, or customer databases. The data is supplied to the identity management systems and services, which provide account creation, provisioning, management, and oversight for the organization. Those systems then offer authentication and authorization services to identity consumers like servers, workstations, services, and third-party service providers.

Identity Systems and Security Design

Identity systems provide a number of common functions: identity creation and management, authentication and authorization, and in some cases, federation of identity information to allow use of identities outside of their home organization. To enable this, a number of common technologies are used: directories, authentication services, identity management platforms, and federated identity tools.

FIGURE 8.1 A high-level logical view of identity management infrastructure

---

Exam Note

The CySA+ exam objectives for the CS-002 version of the exam removed many of the IAM-related topics found in the CS-001 first exam edition, and in fact reduced identity down to a sub-bullet. So why is there a whole chapter on identity management? After a lot of discussion, we wanted to make sure that we provided context for the elements that remain. Identity is a critical security layer for most organizations. To help you with the exam, we'll call out the specific areas that are in the exam objectives throughout the chapter.

---

Directories

Directory services are used in networks to provide information about systems, users, and other information about an organization. Directory services like LDAP (the Lightweight Directory Access Protocol) 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.2 shows an example LDAP directory hierarchy for example.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.2 LDAP directory structure

There are a number of open source LDAP server implementations, including OpenLDAP, 389 Directory Server, ApacheDS, and OpenDJ, as well as commercial software like Oracle's Internet Directory, Microsoft's Active Directory, IBM's Security Directory Server, and CA Directory. Thus, steps required to implement a secure LDAP server will vary, but some of the common considerations remain the same. These include the following:

• Enabling and requiring TLS to keep LDAP queries and authentication secure.
• Setting password storage to use a secure method. LDAP passwords are often stored in plain text, but additional methods are supported and should be used if possible.

---

While LDAP implementations vary, OpenLDAP has historically been one of the most common choices. When using OpenLDAP, the SSHA password storage scheme uses a salted SHA (Secure Hash Algorithm) hash for password storage. This is stronger than the CRYPT, MD5, SHA, and Simple Authentication and Security Layer (SASL) schemes that OpenLDAP supports. Understanding details of how your specific LDAP server works can make a major difference in how secure it is in practice.

---

• Using password-based authentication and requiring TLS. LDAP provides three modes of operation: anonymous, unauthenticated, and username/password authenticated. When authenticated sessions are turned on, unauthenticated mode should be disabled to prevent issues with unsecured connections.
• Replication of LDAP servers, which can help to prevent denial-of-service attacks and other service outages.
• Access control lists for LDAP, which offer the ability to limit access to specific objects in the directory as well as overall rules for how entries are created, modified, and deleted.

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 should 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 needed.

---

One of the most common attacks on web services that use LDAP is LDAP injection, which uses improperly filtered user input via web applications to send arbitrary LDAP queries. Details, and a cheat sheet on how to avoid it, can be found at cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html.

---

Authentication Protocols

Centralized authentication services allow clients to authenticate to a central authentication service, which then supplies verification of the user's identity to the relying system. Central authentication services may also provide authorization information for the user to the relying party, or they may match the identity with their own authorization and rules.

Common authentication protocols include

• TACACS+, a Cisco-designed extension to TACAS, the Terminal Access Controller Access Control System. It uses TCP traffic to provide authentication, authorization, and accounting services. TACACS+ suffers from a number of flaws, including a lack of integrity checking for the data it sends, allowing an attacker with access to the traffic it sends to make arbitrary changes or to use replay attacks against the TACACS+ service. TACACS+ also has encryption flaws that can lead to compromise of the encryption key. This means TACACS+ systems that provide AAA services for network devices should operate on an isolated administrative network if possible.
• RADIUS, the Remote Authentication Dial-in User Service, is one of the most common 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.
• Kerberos, which unlike TACACS+ and RADIUS, is designed to operate on untrusted networks and uses encryption to protect its authentication traffic. Users in Kerberos, called principals, are composed of three elements: the primary (frequently the username), the instance (used to differentiate similar primaries), and the realm, which consists of groups of principals. Realms are often separated on trust boundaries and have distinct key distribution centers (KDCs). Figure 8.3 shows the basic Kerberos authentication flow.

FIGURE 8.3 Kerberos authentication flow

---

Active Directory (AD) uses the Kerberos protocol for authentication. Older versions of Windows relied on NTLM authentication; however, NTLM is outdated and you are unlikely to encounter it in modern environments. If you do, you'll likely have a lot of other major security worries too!

---

Single Sign-On and Shared Authentication Schemes

Many web applications rely on single sign-on (SSO) systems to allow users to authenticate once and then to use multiple systems or services without having to use different usernames or passwords. Shared authentication schemes are somewhat similar to single sign-on and allow an identity to be reused on multiple sites while relying on authentication via a single identity provider. Shared authentication systems require users to enter credentials when authenticating to each site, unlike SSO systems.

---

Exam Note

The CySA+ exam objectives mention SSO but don't list specific technologies. As you prepare for the exam, make sure you understand the general concept of SSO, why your organization might want to use it, and what security issues it can bring with it.

---

Common SSO technologies include LDAP and the Central Authentication Service (CAS). Shared authentication technologies include the following:

• OpenID, an open source standard for decentralized authentication. OpenID is broadly used by major websites like Google, Amazon, and Microsoft. Users create credentials with an identity provider like Google; then sites (relying parties) use that identity.
• OAuth, an open authorization standard. OAuth is used by Google, Microsoft, Facebook, and other sites to allow users to share elements of their identity or account information while authenticating via the original identity provider. OAuth relies on access tokens, which are issued by an authorization server and then presented to resource servers like third-party web applications by clients.
• OpenID Connect is an authentication layer built using the OAuth protocol.
• Facebook Connect, also known as Login with Facebook, is a shared authentication system that relies on Facebook credentials for authentication.

One of SSO's most significant security benefits is the potential to reduce the occurrence of password reuse. This may also reduce the likelihood of credential exposure via third-party sites when users reuse credential sets. In addition, SSO is popular due to the potential cost savings from fewer password resets and support calls.

Shared authentication systems share some of the same benefits, allowing users to use their credentials without having to create new accounts on each site, thus reducing password fatigue. In addition, users are typically informed about the types of data that will be released to the relying party, such as email account, contact information, gender, or other personal information. Shared authentication systems do not necessarily provide a single sign-on experience.

Of course, SSO systems create risks as well—since SSO makes it easier to access multiple systems and services, it makes it easier for attackers who obtain credentials to access them. SSO may also make it easier for an attacker to exploit additional systems once they control a user's browser or system, as the user will not be required to log in again. This can be partially countered by requiring reauthentication and the use of two-factor authentication for critical systems. Although SSO does create dangers, it is the most common solution for most organizations because of the ease of use it creates.

Access Control Models

In addition to authenticating and authorizing subjects, managing who can access or use resources is a critical part of IAM systems and privilege management. Organizations typically choose an access control model based on such factors as the level of control they need, their security and compliance requirements, and their technical and administrative capability to implement and maintain them.

---

Exam Note

The updated CySA+ exam objectives removed many of the identity and access control items contained in the first version of the exam but specifically added role-based, attribute-based, and mandatory access control models. If you're focusing solely on what the exam objectives cover, you may want to spend a little extra time right here in the chapter. The outline does not mention rule-based or discretionary access control, although both models are in common use.

You may have noticed that this chapter covers identity in far more depth than the exam objectives give it. That is for two reasons: First, identity and access management is a complex subject both from a security and a technology perspective, and a useful understanding of the topic needs deeper coverage for you to have all the context you need. Second, we cover the topic in more depth because you will likely encounter many of these issues in your security career.

---

Role-Based Access Control

Often called RBAC (and thus, sometimes confused with rule-based access control which can also sometimes be called RBAC), role-based access control uses roles associated with job functions or other criteria. Roles are matched to permission sets appropriate to those roles, and then users or other objects like a system or software package are assigned roles.

A subject can have more than one role and may even have more than one active role. On top of this, three common constraints are frequently implemented within role-based access control systems:

• Subjects can only use permissions if they have a role.
• The subject's active role must be one it is authorized to have.
• Subjects can use permissions only if the subject's active role is authorized to use it.

Role-based access control systems can implement both discretionary access control and mandatory access control.

Attribute-Based Access Control

Attribute-based access control (ABAC) gives users rights based on policies. Policies use collections of attributes to determine which access rights to grant, thus building logic-based collections of rights.

ABAC tends to be used when a flexible, context-sensitive access control model is required. Combining attributes that describe the subject (like their role, division, or other personal attributes), the action they are trying to perform, attributes of the object that they are attempting to access or use, and environmental attributes like time of day or location allows complex access control logic with fine-grained control.

Mandatory Access Control

Mandatory access control (MAC) systems rely on the operating system to control what subjects can access and what actions they can perform. Due to this design, MAC usually relies on a system administrator to implement access control policies. Since it is relatively rigid, MAC implementations have typically been associated with military systems, although an increasing number of operating systems and security packages implement MAC capabilities.

Rule-Based Access Control

Rule-based access control systems use a set of rules implemented by an administrator. Access control lists (ACLs) are typically associated with each object, and rules are checked against that ACL when access is requested.

---

While rule-based access control is sometimes also called RBAC, in most cases it is safe to assume that RBAC means role-based access control unless otherwise specified.

---

Discretionary Access Control

Discretionary access control (DAC) systems delegate control to the administrators or owners of protected resources like systems or data. This allows delegated control but requires trust in the choices that owners and administrators make, and it can also cause issues due to a lack of central access control.

Validating Access

Ensuring that users don't have more rights than they should is an important part of identity management. In many cases, organizations use manual review processes to validate roles and rights, particularly when staff members change jobs or take on a new role. Staff who are charged with permissions management cringe when they hear a request for rights like “Just make my new employee's rights match the person currently in the role” because that person may have other rights that are not appropriate to the role.

The process of manual review can be time consuming and, like any other manual process, can be error prone. Those issues, as well as the use of identity as an effective security layer for organizations, has driven a significant growth in capabilities of identity management solutions that have built-in validation and monitoring tools. Automated tools can remove much of the burden that manual validation creates, especially when paired with tools that look for out-of-the-ordinary user behavior, overly broad privileges, and role grants that do not match the organizational structure.

---

Exam Note

Manual review is specifically called out in the CySA+ exam objectives, but automated review isn't! Here, it is important to understand that manual reviews are useful and sometimes necessary as part of access control schemes but can require significant effort and time and may be error prone. In most organizations, a combination of manual and automated review processes is likely the best bet to ensure that access control is properly managed.

---

Threats to Identity and Access

Identity threats can be broadly classified into a handful of major areas. First, threats to the underlying authentication and authorization systems seek to exploit vulnerabilities in the way that users log in, how their credentials are handled, or how they are authorized. Second, attackers may also target the account life cycle by creating credentials, preventing them from being removed, or causing them to have greater privileges associated with them. Third, attackers may focus on accounts themselves, either via phishing or compromising systems where credentials may be stored. Over the next few pages, we will explore attacks on identity repositories and supporting systems, targeting identity management process flaws via the account creation, provisioning, and maintenance process; exploits against identity and authorization systems; how credentials are acquired by attackers; and defenses against these attacks.

Understanding Security Issues with Identities

Identities, including credentials, roles, rights, and permissions, and related data, can face a multitude of security issues. As you consider them, it can help to divide them into a few categories:

• Personnel-based identity security, which includes training and awareness, as well as threats like insider attacks, phishing, and social engineering
• Endpoints and their role in attacks on identity, including capturing credentials via local exploits; screen capture and keyboard capture applications; local administrative rights; and how password stores, tokens, and other credentials are stored on local systems and devices like phones and tablets
• Server-based exploits, which can target the systems that run identity services, or which can attack the servers and send identity and authentication data to AAA services
• Applications and services that provide, consume, and interact with identity systems
• Roles, rights, and permissions that are associated with users or groups

---

Exam Note

As you prepare for the exam, remember to consider identity security issues from each of these viewpoints. If you are answering questions about a topic like phishing, you may want to consider multiple controls like a training and awareness program and technical measures, including two-factor authentication, email filtering, and reputation-based sender rules.

---

Attacking AAA Systems and Protocols

Identity repositories like directory systems, authentication systems, and single sign-on services are all attractive targets for attackers. Attacks against identity repositories and systems may target the specific software via vulnerabilities or misconfigurations; they can be aimed at the protocol itself or at how the protocol is implemented.

Attacks at the underlying systems, such as denial-of-service attacks and system compromises, are also common, since taking over the host system can provide full control over an authorization system, giving attackers the keys to the entire kingdom. Since there are a multitude of potential attacks against the many types of identity repositories and authorization systems, we will take a brief look at some of the most common protocols and services to gain an understanding of common threats.

LDAP Attacks

LDAP services are used in many organizations for authentication and directory information. This makes them targets for attackers who want to obtain organizational information or to access systems or applications that rely on LDAP-based authentication.

Attacks against LDAP directory servers typically focus on

• Attacks against insecure binding (connection) methods that target unencrypted LDAP traffic, either to capture the traffic or to exploit LDAP as an authentication service
• Improper LDAP access controls that allow attackers to harvest directory information or to make modifications to directory entries that they should not be able to change
• LDAP injection, which exploits web applications that build LDAP queries using user input, allowing attackers to gather additional information or to make changes they should not be authorized to make by operating as the web service
• Denial-of-service (DsoS) attacks, which can disrupt authentication services that rely on LDAP or cause applications and services that rely on LDAP to fail

Each of these attacks can be prevented or mitigated through careful design and implementation of LDAP services and access methods. Requiring secure binding methods, setting appropriate access controls (and verifying them!), using good web application development practices, and designing a scalable LDAP directory service can all reduce the likelihood of LDAP-related security issues.

---

Real World Scenario

LDAP as an Attack Tool

In 2016, the Connectionless LDAP service (CLDAP) was found to be a potential attack vector allowing amplification attacks because it would respond to spoofed addresses, resulting in amplification rates up to 55 times higher than the source traffic. That means that your otherwise innocent-appearing LDAP service could issue a DoS attack on your critical infrastructure without an attacker even making it through other network defenses! You can read more about it at www.securityweek.com/ldap-attack-vector-makes-terabit-scale-ddos-attacks-possible.

---

OAuth, OpenID, and OpenID Connect

OAuth and OpenID are implemented on a per-provider basis, resulting in flaws unique to each party. One of the most common attacks based on this is the use of open redirects. When redirects and forwards are not validated, untrusted user input can be sent to the relying web application, resulting in users being redirected to untrusted sites, allowing phishing scams or permitting attackers to bypass security layers.

---

The OpenID Connect implementer's guide can be found at openid.net/connect and OAuth 2.0 guides can be found at oauth.net/getting-started.

---

Figure 8.4 shows where this occurs in an OAuth flow. If a user accesses a website that is an open redirect endpoint, it will allow URLs at point A to be any redirect URL, instead of a specific URL associated with that site, and if the site also passes that URL forward at point B, attackers can exploit the authorization flow. Fortunately, this won't cause the account associated with the service provider to be compromised—it only causes issues for the site with the open redirect endpoint, since the redirect can result in the phishing scams and similar issues related to untrusted redirects mentioned earlier occurring.

In addition to individual implementation issues, OAuth's broad adoption for cloud services and mobile applications makes it a particularly tempting target for attackers. Poor session management, reliance on a central shared secrets file for OAuth servers, and inadvertent use of plain-text OAuth sessions are all potential issues for OAuth providers.

FIGURE 8.4 OAuth covert redirects

---

Real World Scenario

OAuth Security and Threat Models

OAuth does not set specific requirements for how the backend of OAuth authentication applications interact with third-party applications, leading to issues with single sign-on applications. To read more about recent exposures, visit threatpost.com/oauth-2-0-hack-exposes-1-billion-mobile-apps-to-account-hijacking/121889/. An in-depth discussion of the OAuth 2.0 threat model can be found in RFC 6819, “OAuth 2.0 Threat Model and Security Considerations,” at tools.ietf.org/html/rfc6819.

---

Many attacks against OpenID have been aimed at protocol vulnerabilities, including a 2012 discovery related to the ability of attackers to forge OpenID requests in a way that resulted in relying parties allowing arbitrary logins to their services. In addition to protocol attacks, OAuth2 can be vulnerable to cross-site request forgery (CSRF) attacks, which focus on getting a user to click a link that causes that user's browser to perform an action at that user. OpenID Connect offers additional protections for encryption and signing, which, if properly implemented, can help prevent many of the exploits conducted against OpenID services.

Kerberos

Kerberos relies on a central key distribution center (KDC). Compromise of the KDC would allow an attacker to impersonate any user. Kerberos attacks have received significant attention over the past few years due to local attacks against compromised KDCs resulting in complete compromise of Kerberos authenticated systems. Common Kerberos attacks include the following:

• Administrator account attacks.
• Kerberos ticket reuse, including pass-the-ticket attacks, which allows impersonation of legitimate users for the lifespan of the ticket, and pass-the-key attacks, which reuse a secret key to acquire tickets.
• Ticket-granting ticket (TGT)-focused attacks. TGTs are incredibly valuable and can be created with extended lifespans. When attackers succeed in acquiring TGTs, the TGTs are often called “golden tickets” because they allow complete access to the Kerberos-connected systems, including creation of new tickets, account changes, and even falsification of accounts or services.

---

Automated monitoring of authentication and authorization systems can help detect anomalous behaviors like the creation of a golden ticket—a normal ticket-generating ticket wouldn't have a lifespan of months or years, making behavior-based monitoring an important part of defense against advanced attackers. Details of this attack can be found here: www.blackhat.com/docs/us-15/materials/us-15-Metcalf-Red-Vs-Blue-Modern-Active-Directory-Attacks-Detection-And-Protection-wp.pdf.

---

RADIUS

RADIUS is commonly used for authentication of network devices, including VPNs, network hardware, and similar services. This makes it a tempting target for attackers who want to penetrate the network infrastructure of their targets. RADIUS attacks often focus on the following:

• Session replay of server responses by matching known traffic and replaying previous responses or replaying server responses to authenticate client without valid credentials
• Targeting the RADIUS shared secret, since RADIUS uses a fixed shared secret that can be compromised at the client level
• DoS attacks aimed to preventing users from authenticating
• Credential-based attacks that rely on the use of a RADIUS-shared secret to brute-force the shared secret given a known password

Using TLS to protect RADIUS authentication instead of relying on the protections built into RADIUS can help mitigate many of these attacks; however, doing so requires consistent implementation throughout an organization.

Active Directory

Active Directory (AD) is the core identity store and AAA service for many Windows-centric organizations. That makes AD a popular target for attackers, and the prevalence of Windows workstations in corporate environments means that many exploit tools are built to target both Windows and Active Directory.

Common Active Directory attacks include the following:

• Malware-focused attacks that seek to place credential capturing or exploit-based malware onto Windows systems or AD servers
• Credential theft via phishing or other techniques
• Privilege escalation attacks using known or new Windows exploits
• Service accounts that are an often forgotten element of Active Directory environments and may suffer from both privilege creep and overly permissive rights
• Domain administrator rights that exist for more staff than is necessary, creating more targets for attackers and a greater likelihood that an AD admin account will not be properly maintained or that its password will be exposed
• The use of down-level versions of protocols used in Windows domains like NTLM v1 and LANMAN, NetBIOS, and unsigned LDAP and SMB to capture credentials or to conduct other attacks

Windows domains often include older systems or have settings configured to support them. Combined with the many exploit tools that are aimed at Windows systems, these make Windows domains a tempting target for attackers.

---

Handling Active Directory GPO Credential Storage

Some specific behaviors of AD and Group Policy are targeted by attackers. Group Policy Preferences can be used to perform a number of actions, but unfortunately, they also store the credentials they use in XML files in the SYSVOL share of every domain controller in the domain. The password storage method used can be easily reversed, making this a significant flaw. The issue is so common that Microsoft provided remediation tools here: support.microsoft.com/en-us/kb/2962486.

---

Targeting Account Creation, Provisioning, and Deprovisioning

The steps from account request to creation, provisioning of accounts, maintenance during the life cycle of the account, and the eventual deprovisioning and deletion of the account are known as the account life cycle. Figure 8.5 shows a typical account life cycle, from start to finish.

FIGURE 8.5 A sample account life cycle

Both internal and external threats target the systems, services, and procedures that make up the account life cycle in order to gain access to accounts, or to gain privileges for the accounts that they already have access to.

The account creation process is an important target for attackers who have either gained access to systems in a trusted environment or are able to use social engineering attacks to persuade someone with appropriate rights to create an account for them. Internal threats may also seek to create accounts for their use to avoid detection.

Once an account exists, attackers will focus on gaining access to it. Social engineering, phishing, and attacks against credential stores and locations where credentials are used and could be compromised in transit or in use are all frequent methods of attack. Compromising credentials can provide the rights and access that the account is provisioned with and may allow attackers to operate in trusted areas where they can attempt attacks that are unlikely to succeed in more protected areas.

Attackers may also focus on accounts that have fallen through the cracks in an identity management system. Major threats from unused or improperly maintained accounts include

• Unused accounts, which attackers can compromise and use without the owner noticing something is amiss.
• Accounts that were not properly deprovisioned and abandoned on systems because they were missed during normal account removal or end-of-life processes. Accounts that are not properly deleted can often indicate an issue with management of the system, and may not be logged or monitored.
• Permissions, group memberships, and other privileges often accrue to accounts during a staff member's employment with an organization and may not be updated properly. Attackers, particularly insider threats, may be able to leverage rights that they, or others, have accrued over time without knowing that they still have them.

Rights and Roles

Maintaining rights, roles, and group memberships is another key element in identity management, and an important feature in identity management systems. User accounts are normally managed using the principle of least privilege, which states that users should be provided only with the least set of privileges or permissions required to perform their job function. This helps prevent users (or attackers who acquire their credentials) from performing actions that they should not and limits the exposure that they can cause.

Many accounts experience privilege creep, or the steady accrual of additional rights over time as account owners change roles, positions, or responsibilities. Privilege creep directly conflicts with the concept of least privilege since accounts should not have rights that aren't required for their current role. Unfortunately, this can be hard to track—new managers may not be aware of the user's old rights, or the user may even be asked to continue to perform their old duties on occasion.

Fortunately, centralized identity management suites provide monitoring and privilege management tools designed to monitor for privilege creep and can be set to identify accounts that end up with excessive privileges or which have privileges beyond what their role requires. Identity management systems like Centrify, Okta, SailPoint, and Ping Identity have account life cycle maintenance and monitoring features designed to fight this type of issue.

Preventing Common Exploits of Identity and Authorization

There are a few common methods of targeting identity and access management systems as well as the use of identity information, each with common protection methods that can help to remediate them. These include the following:

• Impersonation attacks occur when an attacker takes on the identity of a legitimate user. Security issues like OAuth open redirects discussed earlier in this chapter can allow impersonation to occur. Preventing impersonation may require stronger session handling techniques like those found in the OWASP session management cheat sheet at www.owasp.org/index.php/Session_Management_Cheat_Sheet. Other types of impersonation may be prevented by securing session identifiers that attackers might otherwise acquire, either on the local workstation or via the network.
• Man-in-the-middle (MitM) attacks rely on accessing information flow between systems or services. End-to-end encryption of sessions or network links can help reduce the chance of a successful MitM attack, unless attackers control endpoints or have the encryption keys.
• Session hijacking focuses on taking over an already existing session, either by acquiring the session key or cookies used by the remote server to validate the session or by causing the session to pass through a system the attacker controls, allowing them to participate in the session. Much like impersonation and MitM attacks, securing the data that an attacker needs to acquire to hijack the session, either via encrypting network sessions or links or on the local system, can help limit opportunities for session hijacking.
• Privilege escalation attacks focus on exploiting flaws to gain elevated permissions or access. A successful privilege escalation attack can allow a normal or an untrusted user to use administrator or other privileged access. Privilege escalation frequently relies on software vulnerabilities, requiring administrators to ensure that local applications, services, and utilities are not vulnerable.
• Rootkits combine multiple malicious software tools to provide continued access to a computer while hiding their own existence. Fighting rootkits requires a full suite of system security practices, ranging from proper patching and layered security design to antimalware techniques like whitelisting, heuristic detection techniques, and malicious software detection tools.

---

Exam Note

Privilege escalation, impersonation, man-in-the-middle attacks, session hijacking, and rootkits all appear in Domain 1.0 under Objective 1.7. As you review them, think about how you would implement controls to prevent these attacks against identity management systems as well as in other scenarios.

---

Acquiring Credentials

In addition to attacks against AAA and identity management infrastructure, attacks designed to acquire identities and credentials are common, and they can be easier to accomplish from outside an organization. Attacks against credentials commonly occur in the form of phishing attacks, compromises of other services, and brute-force attacks.

Phishing

Phishing attacks aimed at credentials often use replicas of legitimate authentication portals to trick their victims into entering their username and password. More advanced versions will even replay those entries into the legitimate site to prevent their targets from noticing that their login did not work.

Figure 8.6 shows an example of a phishing email that targets a recipient's PayPal ID. If the potential victim did not notice that the URL was wrong or that the site was not exactly the same as the site they normally log into, they could send their credentials to the attacker.

FIGURE 8.6 Phishing for a PayPal ID

---

Multifactor authentication can help limit the impact of a successful phishing attack by requiring users to take an additional action and by providing an authenticator with a limited lifespan. User education and training including how to detect phishing and avoiding password reuse are also an important part of anti-phishing defenses.

---

Compromise of Other Services

Attacking third-party services to obtain passwords that may have been reused is another common threat vector. Attackers who obtain plain-text or recoverable passwords can then reuse those passwords on other accounts the users may have had. Unfortunately, many sites do not use strong password hashing algorithms, allowing attackers to easily crack the hashes for passwords stored using MD5 and other weak mechanisms.

---

Sites like haveibeenpwned.com now track major breaches and allow users to check if an email address or username has been exposed in public breaches.

---

This type of attack means that password reuse is a significant danger, particularly when passwords are used as the only factor for authentication. Breaches of major sites, like the two major Yahoo breaches from 2013 (announced in 2016), have resulted in passwords only minimally protected by MD5 hashes being available for almost a billion potential users. This makes a potential target for exploit any other services those users used that can be matched with their email or other identifiers.

Preventing other sites from being compromised isn't a reasonable expectation for a security professional. That's where technologies like multifactor authentication can provide a useful security layer. Even if users use the same password on multiple sites, their additional factors should remain secure, preventing lost passwords from causing an immediate problem. Training and awareness are still important, since password reuse remains a bad idea.

Brute-Force Attacks

Although having passwords available is preferable for attackers, sites that do not prevent repeated login attempts can still be attacked using brute-force methods by simply attempting to log in using password dictionaries or other brute-force methods. Preventing brute-force attacks requires building in back-off algorithms that prevent repeated logins after failure or other similar solutions like the use of CAPTCHA-style methods to verify that the logins are not being attempted by a script or bot. Some organizations choose to implement account lockout techniques to help with brute-force attacks, although lockouts can increase the workload for support teams unless users have an easy method of unlocking their accounts.

As you might expect, connecting authentication events to your security management and logging tools can help detect brute-force attacks, allowing you to take action to prevent the system or systems that are conducting the brute-force attack from attempting to authenticate. If you are considering this option, be sure to identify appropriate thresholds for what you consider brute force—otherwise you may lock out legitimate but forgetful users!

---

CAPTCHA is an acronym for Completely Automated Public Turing test to tell Computers and Humans Apart. CAPTCHAs use a variety of methods to try to prevent bots from performing actions, including requiring users to identify numbers, or to differentiate pictures of kittens from pictures of puppies. If you're looking to prevent brute-force web activity, OWASP's “Blocking Brute Force Attacks” guide can offer useful advice: www.owasp.org/index.php/Blocking_Brute_Force_Attacks.

---

Identity as a Security Layer

Identity is a critical part of most defense-in-depth designs. User and service accounts are crucial to controlling access to systems and services and also allow detailed monitoring and auditing of usage. Since rights and permissions are assigned either to roles that accounts are associated with or to individual users, identity is also critical to ensuring that rights management is handled properly.

Identity and Defense-in-Depth

The account lifecycle offers a number of opportunities for defense-in-depth designs. Although identity management processes will vary from organization to organization, a few critical parts of the identity management life cycle are consistent from a defense-in-depth design perspective. These process requirements occur at the major phases of an account's life cycle:

• Identity creation must ensure that only valid accounts are created and that the correct owner receives the account. At this phase in the account life cycle, it is important to avoid duplicate account creation, to ensure that initial authentication factors are delivered or set securely, and that accounts are added to a central identity management system for monitoring and auditing.
• Account provisioning and rights management needs to be consistent—pockets of unmanaged systems or systems that do not integrate can result in unmanaged accounts. Rights management is typically role-based, preventing individual accounts from accruing specialized permissions.
• Account modification and maintenance should track the individual's changing roles and group memberships to prevent privilege creep.
• Account termination needs to ensure that accounts are terminated properly and that they are removed from all systems that they were provisioned to.

---

Exam Note

Defense-in-depth for identity should address all three elements of the CIA Triad. That means ensuring that credentials and credential stores remain confidential in motion and at rest and that their integrity is monitored to ensure that unauthorized changes do not occur. Availability is also a critical concern—centralized identity and authorization services are wonderful until they allow an entire organization's ability to log in to fail due to a failed service or DoS attack!

---

Securing Authentication and Authorization

Securing the authentication process requires a combination of technical and procedural elements. Technological controls focus on protecting both the systems that provide authentication services and the traffic between clients and those servers. Providing a secure means of validating the identity of users is also critical, since attackers are more likely to have advanced capabilities that result in them successfully obtaining valid usernames and passwords via phishing, malware, or other means. Figure 8.7 shows a sample authentication flow with security considerations at each point in the flow, including use of TLS, multifactor authentication, and redundant authentication servers. Note that authentication security requires design or process security considerations throughout the flow.

FIGURE 8.7 Authentication security model

Password management is also a design concern for organizations. Users are asked to remember a large number of passwords, and password reuse is a continuing threat. This means that organizationally sponsored adoption of password safes or password storage utilities can have a significant impact on password security. Tools like KeePass, Password Safe, Dashlane, 1Password, and LastPass, as well as enterprise-centric password storage and management tools, can provide a useful means of maintaining distinct passwords without large numbers of support calls.

---

Moving Beyond Password Complexity Requirements

Password complexity guidelines that included a requirement for specific types of characters and complexity were common until very recently, due in large part to the limited length of passwords supported by many systems. Recommendations for strong passwords have largely changed to be length-based, and users are often advised to use a passphrase instead of a password. NIST's SP 800-63-3 “Digital Identity Guidelines” (pages.nist.gov/800-63-3/) released in mid-2017 reflect major changes in digital authentication standards from previous versions.

---

Authorization and Rights Management

Matching users with their rights, roles, and group membership is the next step of identity-based security. Rights management allows access control by matching users with the access they should have. Building a rights management security layer relies on the following:

• Building a set of policies that describe what rights are allocated to each role or task
• Implementing a management system to ensure that rights are granted to accounts and groups that need them and removed from groups and users that do not hold the appropriate role
• Monitoring and reporting to ensure that rights management occurs according to policy

In addition to managing rights for normal users, organizations need to pay particular attention to privileged user management, the management of administrative and super-user rights. Privileged users often have the ability to override system policies, to make changes to logging and oversight systems, or to otherwise impact systems in very powerful ways. This means that additional oversight needs to be placed around who can use privileged accounts and how administrative rights are granted and removed. Additional monitoring and logging is also common, and separation of administrative accounts from personal accounts is considered a best practice. This ensures that administrative actions can be logged by requiring users to specifically log in to an administrative account or to activate administrative privileges before their use. Since administrative accounts shouldn't be used constantly, this also makes misuse easy to detect by looking for administrative accounts that are constantly logged in. As always, appropriate training is required to make sure that administrators understand this.

Multifactor Authentication

One of the most important security measures put in place to authenticate users is multifactor authentication (MFA). MFA relies on two or more distinct authentication factors like a password, a token or smartcard, a biometric factor, or even the location that the individual is authenticating from. A key part of this is that the factors should be different; two passwords do not make an effective MFA scheme.

---

Exam Note

Multifactor authentication is one of the identity topics that are specifically called out in the exam objectives. Make sure you have a good understanding of multifactor authentication, what factors exist, why it is useful, and what issues exist with MFA solutions.

---

MFA relies on a few common types of authentication factors or methods:

• Knowledge factors are something you know. Passwords and passphrases are the most common knowledge factors, but authentication systems also sometimes use other data that you may know. Examples include systems that build questions from personal data the organization has about you such as your current mortgage payment, your residence a decade ago, or other things that you will know but that someone else is unlikely to.
• Possession factors are something you have. The most common examples of this are authenticator applications, security tokens, and smartcards. Figure 8.8 shows an example of the Google Authenticator application, a smartphone-based onetime password generator tool. Having the application that provides the code is the possession factor when using this type of token.
• Biometric factors are something that you are. They include fingerprints, retina scans, voiceprints, and a host of other methods of measuring features of the human body.
• Location factors, which are less frequently used, rely on physical location, determined either by where a system or network is located, or by using GPS or other data to verify that you are in a place that is trusted or allowed to access a system.

---

Since the token in Figure 8.8 is a onetime token, it's safe to publish in the book with its associated email address. To access the account, you would need both the current password and the current Google Authenticator code. The authors created a throwaway account for this screenshot anyway!

---

FIGURE 8.8 Google Authenticator token

MFA helps prevent attackers from authenticating using stolen credentials by making it significantly less likely they will have both (or more!) of the factors that are required to authenticate to a user account. If an attacker manages to phish a password or conducts a successful brute-force password guessing attack, they probably won't have access to that individual's cell phone or token or have access to a biometric factor like their fingerprint.

This security advantage means that MFA is increasingly considered a necessary default security control for systems and services that require a greater level of security than a simple password. Major e-commerce, banking, social networks, and other service providers now have two-factor functionality available, and an increasing number are requiring it by default. That doesn't mean that MFA is perfect; a lost phone or token, an insecure method of delivering a second factor, or a backup access method that allows users to bypass the second factor by talking to a support person can all result in a failure of a multifactor system.

Context-Based Authentication

A key concept in authentication systems is the idea of context-based authentication. Context-based authentication allows authentication decisions to be made based on information about the user, the system the user is connecting from, or other information that is relevant to the system or organization performing the authentication.

Common data used for context-based authentication includes the following:

• User roles and group memberships related to application or service access
• IP address and/or IP reputation, providing information on whether the remote IP is known to be part of a botnet or other IP range with known bad behavior
• Time of day, often related to a job role or working hours
• Location-based information like their IP address or GPS location
• Frequency of access, which may be combined with behavioral data like keystroke patterns, browsing habits, or other details that can help uniquely identify a user
• Device-based, including information about the web browser in use and other data that can provide a device fingerprint such as its IP address, time zone, screen resolution, cookies or cookie settings, installed fonts, and language

Figure 8.9 shows an example of context-based authentication flow. A user logs in via the organization's VPN where a network access control (NAC) system profiles the user's device, identifying device-based fingerprint information. The user provides their username and password, which in this example do not match the device—the user has never logged in from it before. Due to this, the user is asked to provide a onetime password code from a security token and is then authenticated, having proven that they are who they say they are. The NAC server records the new device as a valid, trusted device and adds its unique profile to its database, and the user is connected via the VPN to the organization's internal network.

FIGURE 8.9 Context-based authentication

Organizations often use multiple types of contextual information to help to authenticate their users and may use it either in parallel with or in place of other MFA schemes.

---

Context-based authentication can be combined with multifactor authentication, allowing you to require users to provide enhanced authentication when additional verification is needed or desired.

---

---

The Problem with SMS

You have probably encountered SMS (text message)-based second factors in your daily life—Amazon, among many other major websites, uses it to verify your identity. The idea behind SMS as a second factor is that people will almost always have possession of their phone and that SMS provides a useful second factor when added to a password since it will prevent an attacker who only knows a password from logging in.

Unfortunately, SMS isn't a very secure protocol. In fact, NIST's Special Publication 800-63-3: Digital Identity Guidelines recommends that SMS be deprecated. Not only have successful attacks against SMS-based onetime passwords increased, but there are a number of ways that it can be successfully targeted with relative ease. One of the major areas in which this is prevalent is via VoIP systems, where SMS messages are relatively easily stolen, or where the password that an attacker has may have been reused for a given user's account controls, allowing attackers to see SMS messages or redirect them.

Another recent attack against SMS-based multifactor implementations is SIM swapping, which typically relies on bribed employees at cellular carriers. SIM swaps occur when attackers manage to get a new SIM card added to an account, taking over from the old SIM. This directs all activity to the attacker's phone instead of the legitimate owner's phone, allowing them to bypass SMS and other validation systems.

Fortunately, reasonable alternatives exist in the form of authenticator applications like Google Authenticator that generate onetime codes on an ongoing basis or by using hardware fobs. Does this mean that SMS will stop being used? Probably not, but it does mean that security professionals need to be aware that SMS probably isn't suitable for high-security environments.

---

Identity as a Service

Identity as a service (IDaaS) services provide authentication services, typically as a cloud-hosted service. IDaaS solutions typically provide features that include the following:

• Identity life cycle management, which consists of technologies and processes to create, provision, and manage identities for systems, services, and even other cloud services
• Directory services, using LDAP, Active Directory, or another directory technology
• Access management with both authentication and authorization capabilities
• Single sign-on support via technologies like Security Assertion Markup Language (SAML) integrations, OAuth, or other standards
• Privileged account management and monitoring
• Reporting, auditing, and other management capabilities to provide oversight and visibility into the identity life cycle

---

Identity as a service can create new security concerns for an organization due to hosting an identity store or an authorization system outside its internal network. Understanding how the IDaaS provider handles and secures identity information, what their incident response practices and notification policy is, and performing due diligence when selecting a provider are all important parts of an IDaaS implementation.

---

Implementing a cloud-hosted identity service can mean significant changes to internal AAA system designs. Major elements include

• Deciding whether the organization will centralize their directory services or whether internal and third-party hosted directories will both exist.
• Similarly, a decision must be made to centralize authentication or to federate multiple authentication and authorization systems.
• The location for the organization's authoritative credential store may be local or cloud-based.

IDaaS also has significant potential security benefits for organizations that do not have a strong in-house identity management capability or that need to better integrate with third-party services. In organizations without strong internal identity practices, an IDaaS solution can provide a more secure, better managed, and more capable toolset. Automated monitoring and reporting services can also help identify security issues earlier than might occur with a noncentralized system.

Detecting Attacks and Security Operations

Security information and event management (SIEM) systems can be used to leverage identity information as well as the other types of security information we have discussed in this book. Using identity information provides the “who” when reviewing events and incidents; when paired with other SIEM data and event logs, it provides a complete view of what occurred and what the user, service, or account's behavior was. Human or automated analysis can determine whether the actions were appropriate.

Configuring a SIEM or other security monitoring device to look for the following types of events can provide significant security benefits:

• Privileged account usage
• Privilege changes and grants
• Account creation and modification
• Employee termination and terminated account usage
• Account life cycle management events
• Separation-of-duty violations

Centralizing both IAM and user authentication and authorization systems helps ensure that accounts and privileges are well understood and managed throughout an organization. Attackers who can find a system that uses distinct accounts, or that does not centrally log authentication and authorization events, can far more easily take advantage of that system's isolation without their exploits being detected.

---

Much like other security events, detecting identity attacks requires that organizations have well-defined security policies and standards for use of credentials and privileges. Once those are in place, baselines can be set, and anomaly detection can be implemented to sound the alarm when unexpected behaviors occur.

---

The final layer for any identity-based security system is active monitoring and administration by knowledgeable administrators. Having humans analyze the reports and other information provided by central monitoring and security systems will help identify events that might be missed by automated systems.

Federation and Single Sign-On

The ability to federate identity, which is the process of linking an identity and its related attributes between multiple identity management systems, has become increasingly common. You have probably already seen or used a federated identity system if you use your Microsoft, Google, Facebook, or LinkedIn accounts to access sites that aren't hosted by those service providers. Each site allows use of their credentials, as well as a set of attributes by third-party sites.

---

Exam Note

The CySA+ exam objectives specifically call out federation, but without any further detail. Make sure you pay attention to what federation is, why you might want to use it, and what security concerns it brings, and know a bit about the common technologies associated with it.

---

Federated Identity Security Considerations

Federated identities move trust boundaries outside of your own organization, resulting in new concerns when designing, implementing, or using federated identity. This leads to the need to look at federated security from three points of view:

• As an identity provider (IDP), members of a federation must provide identities, make assertions about those identities to relying parties, and release information to relying parties about identity holders. The identities and related data must be kept secure. Identities (and sometimes attributes) have to be validated to a level that fits the needs of the federation, and may have user-level controls applied to their release. In addition, service providers may be responsible for providing incident response coordination for the federation, communication between federation members, or other tasks due to their role in the federation.
• As the relying party (RP) or service provider (SP), members of a federation must provide services to members of the federation, and should handle the data from both users and identity providers securely.
• The consumer or user of federated services may be asked to make decisions about attribute release, and to provide validation information about their identity claims to the IDP.

Each of these roles appears in Figure 8.10, which shows an example of the trust relationships and authentication flow that are required for federated identities to work.

FIGURE 8.10 Federated identity high-level design

---

Real World Scenario

Hacking from Inside a Federation

Federated identities can be very useful, but federations are only as strong as their weakest member's security. In the past, one of the authors of this book was involved in the incident response process between members of a large-scale federation.

A successful hacker used compromised credentials to log in to systems at various federation member sites. There, he used the credentials to access systems used for research efforts. Although the credentials he had were not administrative credentials, they did have local system access, allowing the attacker to identify and exploit local privilege escalation flaws. Once he had exploited those flaws, he replaced the SSH Daemon running on the systems and captured credentials belonging to other federation members as well as local users. That provided him with enough new credentials to continue his exploits throughout other member sites.

The hacker was eventually tracked back through a series of systems around the world and was arrested after a massive coordinated effort between system administrators, security professionals, and law enforcement. The federation continued to operate, but the hacker's attacks led to additional security controls being put into place to ensure that future attacks of the same nature would be harder.

If you are part of a federation, you should consider how much you trust the organizational security practices and policies of the other federation members. That should drive the rights and access that you provide to holders of federated identities, as well as how you monitor their actions.

If you'd like to read more about this, the U.S. Federal Bureau of Investigation wrote a case study about the event that is available here: publish.illinois.edu/kericker/files/2013/09/NCDIR-TR-2008-01.pdf.

---

Federated Identity Design Choices

Using federated identity creates new security design concerns that you will have to plan and design around. If you are intending to leverage federated identity, the first question to answer is what trust model you want to use with the federated identity provider. Common providers of federated identity include Google, LinkedIn, and Amazon, but a broad range of commercial and private federations exist, including those operated by governments and higher education.

If you are using an existing federated identity provider such as Google, you are likely interested in allowing consumers to bring their own identity, which you will then map internally to your own privilege and rights structures. This model presumes that you do not care that a user is probably who they claim to be—instead, you only care that they own the account they are using.

In federation models that rely on verifiable identities, a greater level of assurance about the user's identity claims is needed, requiring additional trust between the federated identity providers and the relying parties. Examples of this include research federations that have identity vetting and assertion requirements between multiple identity providers within the federation.

Trust decisions will also influence organizational decisions about manual provisioning versus automatic provisioning and deprovisioning. Integration with third-party federated identity services works best when provisioning occurs when users request access with immediate account provisioning occurring once the federated identity has been validated. Manual provisioning provides greater security by allowing for additional oversight but can cause delays for user access.

Provisioning can also involve attribute release, as relying parties in a federation need some basic information for a user account to provide authorization and to contact the user. The amount of information released by an identity provider can vary, from complete attribute release with all data about the account potentially available to very limited release such as the request shown in Figure 8.11.

FIGURE 8.11 Attribute release request for LoginRadius.com

Figure 8.11 shows an example of an attribute release request for LoginRadius.com, a site that supports both LinkedIn and Google with federated identities for their users. Implementation decisions for each of these technologies will vary, but design requirements for data handling, storage, and release of attributes are all important.

---

Similar concerns exist for self-service password resets and other user-initiated account options. Allowing users to change these settings typically results in a lower support load, but it may also allow attackers to use poor security questions or other methods to change user passwords and other data without the user being involved.

---

Once you have identified the appropriate trust requirements for the identities you intend to use for your federated identities, you will either have to adopt the underlying technologies that they use or select the technology that fits your needs. This is particularly true if you are federating your own organization, rather than using a federated identity provider like LinkedIn or Google. Technologies like SAML, OAuth, OpenID Connect, and Facebook Connect are all potentially part of the solutions you may adopt.

The type of federation you intend to implement also influences the security requirements you can expect, or may require, from federation members, including both identity providers and relying parties. In a loosely bound federation like sites using Google accounts, the underlying security model for Google accounts is not as significant of a concern since any owner of a Google account can typically use services that federate with Google.

In federations that require a higher trust level, vetting of the security practices of both identity providers and relying parties is necessary. Identity providers must validate the identity of the users they support, they must secure their credential store, and they should have a strong handling and notification process in place for security issues that might impact the federation's members. Relying parties need to ensure that their credential handling is properly secured and that they are meeting any security or operational requirements that the federation presents.

Federated Identity Technologies

Four major technologies serve as the core of federated identity for current federations: SAML, ADFS, OAuth, and OpenID Connect. These technologies provide ways for identity providers to integrate with service providers in a secure manner without having to know details about how the service provider implements their service or their own use of the identity.

Table 8.1 compares SAML, OpenID, OAuth2, and ADFS, including their support for authorization and authentication, some of their most common potential security risks, and how they are often used.

TABLE 8.1 Comparison of federated identity technologies

	SAML	OpenID	OAuth2	ADFS
Authorization	Yes	No	Yes	Yes
Authentication	Yes	Yes	Partial	Yes
Potential security risks	Message confidentiality Protocol usage and processing risks Denial of service	Redirect manipulation Message confidentiality Replay attacks CSRF/XSS attacks Phishing	Redirect manipulation Message confidentiality Authorization or resource server impersonation	Token attacks (replay, capture)
Common uses	Enterprise authentication and authorization, particularly in Linux-centric environments	Authentication	API and service authorization	Enterprise authentication and authorization, particularly in Windows-centric environments

SAML

SAML is an XML-based language used to send authentication and authorization data between identity providers and service providers. It is frequently used to enable single sign-on for web applications and services because SAML allows identity providers to make assertions about principals to service providers so that they can make decisions about that user. SAML allows authentication, attribute, and authorization decision statements to be exchanged.

Figure 8.12 shows a very simple sample SAML authentication process. In this flow, a user attempts to use a SAML authenticated service and is referred to the identity provider to authenticate their identity. After a successful login, the browser returns to the relying party with an appropriate SAML response, which it verifies. With these steps done, the user can now use the application they initially wanted to access.

---

OWASP provides a comprehensive SAML security cheat sheet at cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html.

---

ADFS

Active Directory Federation Services (ADFS) is the Microsoft answer to federation. ADFS provides authentication and identity information as claims to third-party partner sites. Partner sites then use trust policies to match claims to claims supported by a service, and then it uses those claims to make authorization decisions.

ADFS uses a similar process to an OAuth authentication process:

1. The user attempts to access an ADFS–enabled web application hosted by a resource partner.
2. The ADFS web agent on the partner's web server checks for the ADFS cookie; if it is there, access is granted. If the cookie is not there, the user is sent to the partner's ADFS server.
3. The resource partner's ADFS checks for an SAML token from the account partner, and if it's not found, ADFS performs home realm discovery.
4. Home realm discovery identifies the federation server associated with the user and then authenticates the user via that home realm.
5. The account partner then provides a security token with identity information in the form of claims, and sends the user back to the resource partner's ADFS server.
6. Validation then occurs normally and uses its trust policy to map the account partner claims to claims the web application supports.
7. A new SAML token is created by ADFS that contains the resource partner claims, and this cookie is stored on the user's computer. The user is then redirected to the web application, where the application can read the cookie and allow access supported by the claims.

FIGURE 8.12 Simple SAML transaction

---

ADFS can be controlled using the ADFS MMC snap-in, adfs.msc. The ADFS console allows you to add resource partners and account partners, map partner claims, manage account stores, and configure web applications that support federation. Microsoft provides a useful overview of ADFS at msdn.microsoft.com/en-us/library/bb897402.aspx.

---

OAuth

The OAuth 2.0 protocol provides an authorization framework designed to allow third-party applications to access HTTP-based services. It was developed via the Internet Engineering Task Force (IETF) and supports web clients, desktops, mobile devices, and a broad range of other embedded and mobile technologies, as well as the service providers that they connect to. OAuth provides access delegation, allowing service providers to perform actions for you.

OAuth flows recognize four parties:

• Clients The applications that users want to use
• Resource Owners The end users
• Resource Servers Servers provided by a service that the resource owner wants the application to use
• Authorization Servers Servers owned by the identity provider

Figure 8.13 shows how authentication flows work with OAuth. In this chain, the client is attempting to access a third-party service. The third-party site, which is the consumer, is directed to a service provider to authenticate. To request authentication, the consumer sends a request for a request token. The service provider validates the user's identity, grants a request token, and then directs the consumer back to the service provider. There, the service provider obtains the user authorization and sends the user to the third-party site. The consumer requests an access token, the service provider grants it, and then the consumer can access resources.

FIGURE 8.13 OAuth authentication process

OpenID Connect

OpenID Connect is often paired with OAuth to provide authentication. It allows the authorization server to issue an ID token in addition to the authorization token provided by OAuth. This allows services to know that the action was authorized and that the user authenticated with the identity provider.

Federation Incident Response

Incident response with federated identities can be a complex topic. The amount of information released by identity providers, service providers, and relying parties will vary due to the contractual agreements (if any!) or the federation operating agreements between them.

Building a response plan for federated identity varies based on the role your organization holds in the federation:

• Identity providers are typically responsible for notifying account owners and may be responsible for notifying relying parties. Incident response policies need to envision compromise of the identity provider itself, as well as what events such as a required password reset for all users would entail.
• Service providers need to determine what their response would be if the identity provider was compromised, as well as a range of smaller incidents, including compromise of their own authorization systems or a limited compromise of accounts provided by the identity provider.

Consumers must consider what the impact would be if their accounts were inaccessible—if they used a Google account for many sites, and Google were compromised or unavailable, what would they do?

As with all incident response policies and procedures, a strong communications plan and testing of the response plan itself, either via practice scenarios or walk-throughs, is strongly recommended.

Summary

Identity and authorization are key elements in a security design. Authentication, authorization, and accounting (AAA) systems are part of an identity and access management (IAM) infrastructure. IAM systems manage user account life cycles, as well as rights and privileges, and provide oversight of identity to ensure that accounts and the rights they have are not misused or abused.

Common AAA systems include LDAP directory servers, Kerberos, RADIUS, and Active Directory. In addition, federated identity systems are increasingly important as organizations connect with cloud-hosted services using onsite and third-party identity and authorization services. Securing each of these systems requires careful configuration and understanding of its security models and uses in the organization.

There are a number of common access control methods. They include role-based access control (RBAC), attribute-based access control (ABAC), mandatory access control (MAC) and others. Review of the rights granted to subjects is an important part of identity and access management oversight. Both automated and manual review processes can help prevent privilege creep, overly broad privileges, and other problems associated with rights and role management.

Attackers target identity and identity systems to gain access to organizational resources and data. They target personnel to acquire their credentials via phishing attacks, malware, and social engineering. At the same time, endpoints like mobile devices and workstations, as well as servers, are targeted for compromise to acquire user IDs, passwords, or even entire identity stores. Applications and services may also be targeted, due to weaknesses in their implementation of authorization or authentication technologies or due to compromised credentials.

Despite the many attacks aimed at identity, it can also provide a useful security layer. Centralized management of authentication and authorization combined with logging and auditing can help prevent attacks, or identify attacks as they occur. Behavioral analysis, policy-based monitoring, and other techniques used in SIEM and other security technologies can be applied to identity systems to detect issues and attacks.

Federated identity adds new complexity to identity-based security design. Federated identity may be as simple as allowing users to bring their own account, thus simplifying account maintenance for the relying organization, but it can also be a complex trust-based relationship with broad attribute release and rights based on those attributes. Responding to federation-based incidents requires an understanding of the trust relationships, privileges, and reporting relationships within the federation.

Exam Essentials

Explain how identities are the core of authentication, authorization, and accounting (AAA) systems. AAA systems authenticate users by using a user ID, password, or other factors. Central management of identities is handled by identity and access management (IAM) systems. IAM systems create, store, manage, and monitor identities and authorization through organizations. Rights and roles are managed via role-based, attributed-based, mandatory, and other access control schemes. Key elements of IAM systems include directories, authentication systems and protocols, single sign-on (SSO) and shared authentication services, and federated identity systems.

Name some threats to identities. Identity threats target not only the credentials issued to users and services, but also identity management systems, the protocols and applications used to manage and consume identity data, and the account life cycle itself. Personnel are targets of phishing and social engineering attacks, and the roles and privileges they have are targeted for abuse. Malware compromises target servers, systems, and devices. Applications and services are targeted via misconfigurations, protocol vulnerabilities, design issues, and compromise.

Explain why identity is a critical security layer. The account life cycle is the core of identity-based security and relies on secure creation, provisioning, maintenance, and removal at the end of the account's life to ensure security. The rights and privileges that accounts are assigned require strong policy-based management and oversight, as well as monitoring to avoid privilege creep via privilege management. Credential and password management, and the use of multifactor authentication (MFA), are important due to increased targeting of credentials by advanced attackers.

Know how federated identity technologies are broadly used for cloud services and interorganizational authentication and authorization. Identity providers provide both identities and authentication services to federations. Relying parties and service providers use identities to authorize users to make use of their services or applications. Consumers may use social identities like Google or Facebook credentials to access a broad range of services using protocols like OpenID Connect and OAuth. Incident response in federations requires additional preparation to ensure that new models for reporting, notification, and handling are ready when needed.

Explain how identity can provide a useful control layer. Implementing defenses against privilege escalation, impersonation, man-in-the-middle attacks, and other threats can involve identity and access management techniques. Session hijacking, cross-site scripting, and even rootkits can have their impact limited by controlling the privileges, ensuring proper authentication and authorization, and logging and tracking account access and privileges account activity. Remember to consider identity as a security layer in your control plans.

Lab Exercises

Activity 8.1: Federated Security Scenario

In this exercise, you will be provided with two different federated identity scenarios. For each, you should research the technology or situation described and then write a written recommendation to handle the issue described.

• Part 1: Google OAuth integration

Example Corp.'s development team has implemented an OAuth integration with Google. The internal development team has written their own libraries for the company's OAuth endpoint and has implemented their server via HTTP between Example Corp.'s servers.

What security issues would you identify with this design, and what fixes would you recommend?

• Part 2: High security federation incident response

Example Corp. is considering using Facebook Login to allow users to bring their own identity for its customer support website. This would remove the need for Example Corp. to handle its own identity management in most cases and is seen as an attractive option to remove expensive user support for this type of account.

Answer the following questions:

1. What recommendations and advice would you provide to the implementation team?
2. What should Example Corp.'s incident response plan include to handle issues involving Facebook Login?
3. Does using Facebook Login create more or less risk for Example Corp.? Why?

• Part 3: Analyze your responses

To analyze your response to Part 1, use the OWASP Authentication cheat sheet found at cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html. You will find tips on OAuth and application communications.

To analyze your response to Part 2, review federation-aware incident response policies like doi.org/10.26869/TI.100.1 and www.btaa.org/docs/default-source/technology/federated_security_incident_response.pdf.

Activity 8.2: On-site Identity Issues Scenario

In this exercise, you will be provided with two different local identity scenarios. For each, you should research the technology or situation described, and then write a written recommendation to handle the issue described. In Part 3, you will review your answers and look for potential flaws that remain.

• Part 1: Emergency privilege escalation

At Example Corp., administrative accounts are created and managed using a central identity and access management suite. This suite, as well as the company's central AAA servers, are hosted in redundant datacenters, and site-to-site VPNs normally connect those datacenters to multiple locations around the country.

Example Corp.'s systems engineering department recently dealt with a major Internet connectivity outage, which also resulted in engineers being unable to log in to the systems at the sites where they worked. This meant that they were unable to work to fix the issues.

The engineers have requested that you identify a secure way to provide emergency, on-demand privileged access to local servers when the central AAA services are unavailable. You have been asked to provide a solution to central IT management that is both secure and flexible enough to allow authentication for network devices, servers, and workstations.

• Part 2: Managing privilege creep

A recent audit of Example Corp.'s file shares shows that many long-term employees have significantly broader rights to files and folders than their current roles should allow. In fact, in some cases employees could see sensitive data that could result in negative audit findings in a pending external audit.

How would you recommend that Example Corp. handle both the current issue of privilege creep and the ongoing problem of ensuring that it does not occur in the future without seriously disrupting the company's operations?

• Part 3: Review

Review your recommendations to ensure that confidentiality, integrity, and availability are maintained. Did you provide a solution that covers each of these three areas?

1. Does your solution cover each of these areas (if appropriate)?
   • Personnel
   • Endpoint devices
   • Servers
   • Services and applications
   • Roles and groups
2. If you were asked to conduct a penetration test of an organization that had implemented your recommendations, how would you approach attacking your solution?

Activity 8.3: Identity and Access Management Terminology

Match each of the following terms to the correct description.

TACACS+	LDAP is deployed in this role.
Identity	The practice of managing and controlling identities and rights.
ADFS	An open standard for authorization used for websites and applications.
Privilege creep	Access control based on elements like things that describe the user (role, title), what action is being attempted, or other similar data.
Directory service	This issue occurs when accounts gain more rights over time due to role changes.
OAuth 2.0	The set of claims made about an account holder.
SAML	A technical system that allows access to many different systems or services with a single authentication event.
RADIUS	A Cisco-designed authentication protocol.
Privilege management	An access control scheme where the operating system constrains the ability of the user or subject to take action.
Multifactor authentication (MFA)	An access control scheme based on an individual's job duties or other position in an organization.
Single sign-on (SSO)	A common AAA system for network devices.
Federation	Checking rights without an automated system.
Role-based	Microsoft's identity federation service.
Attribute-based	The linking of an individual's identity across multiple identity management systems.
Mandatory	An XML-based protocol used to exchange authentication and authorization data.
Manual review	The combination of multiple means of proving an identity to authenticate.

Review Questions

1. Gabby is designing a multifactor authentication system for her company. She has decided to use a passphrase, a time-based code generator, and a PIN to provide additional security. How many distinct factors will she have implemented when she is done?
   1. One
   2. Two
   3. Three
   4. Four
2. Susan wants to manage access based on the job titles of members of her organization's staff. What kind of access control is best suited to this requirement?
   1. Role-based access control
   2. Attribute-based access control
   3. Mandatory access control
   4. Discretionary access control
3. During an incident response process, Michelle discovers that the administrative credentials for her organization's Kerberos server have been compromised and that attackers have issued themselves a TGT without an expiration date. What is this type of ticket called?
   1. A master ticket
   2. A golden ticket
   3. A KDC
   4. A MGT
4. Which of the following technologies is NTLM associated with?
   1. SAML
   2. Active Directory
   3. OAuth
   4. RADIUS
5. Jim was originally hired into the helpdesk at his current employer but has since then moved into finance. During a rights audit, it is discovered that he still has the ability to change passwords for other staff members. What is this issue called?
   1. Rights mismanagement
   2. Least privilege
   3. Permission misalignment
   4. Privilege creep
6. What type of attack occurs when an attacker takes advantage of OAuth open redirects to take on the identity of a legitimate user?
   1. Impersonation
   2. Session hijacking
   3. MitM
   4. Protocol analysis
7. The 2013 Yahoo breach resulted in almost 1 billion MD5 hashed passwords being exposed. What user behavior creates the most danger when this type of breach occurs?
   1. Insecure password reset questions
   2. Use of federated credentials
   3. Password reuse
   4. Unencrypted password storage
8. Authentication that uses the IP address, geographic location, and time of day to help validate the user is known as what type of authentication?
   1. Token-based
   2. Context-based
   3. NAC
   4. System-data contextual
9. Which of the following is not a common attack against Kerberos?
   1. Administrator account attacks
   2. Ticket reuse attacks
   3. Open redirect-based attacks
   4. TGT-focused attacks
10. Which of the following technologies is not a shared authentication technology?
    1. OpenID Connect
    2. LDAP
    3. OAuth
    4. Facebook Connect
11. Angela is concerned about attackers enumerating her organization's LDAP directory. What LDAP control should she recommend to help limit the impact of this type of data gathering?
    1. LDAP replication
    2. ACLs
    3. Enable TLS
    4. Use MD5 for storage of secrets
12. What security design is best suited to protect authentication and authorization for a network that uses TACACS+?
    1. Use TACACS+ built-in encryption to protect traffic
    2. Implement TACACS++
    3. Enable accounting services to detect issues
    4. Route management traffic over a dedicated network
13. Jason has user rights on his Linux workstation, but he wants to read his department's financial reports, which he knows are stored in a directory that only administrators can access. He executes a local exploit, which gives him the ability to act as root. What type of attack is this?
    1. Privilege escalation
    2. Zero-day
    3. Rootkit
    4. Session hijacking
14. Chris is responsible for monitoring his organization's file shares and security and has discovered that employees are consistently retaining access to files after they change positions. Where should he focus his efforts if his organization's account life cycle matches the following?

    

    1. Step 1
    2. Step 2
    3. Step 3
    4. Step 5
15. Which of the following methods is not an effective method for preventing brute-force password guessing attacks via login portals?
    1. CAPTCHAs
    2. Returning an HTTP error
    3. Login throttling
    4. Failed login account lockout
16. Which party in a federated identity service model makes assertions about identities to service providers?
    1. RPs
    2. CDUs
    3. IDPs
    4. APs
17. Which of the following is not a reason to avoid using SMS as a second factor for authentication?
    1. SMS via VoIP is easy to target.
    2. SMS is insecure.
    3. SMS cannot send unique tokens.
    4. VoIP management often uses the same password as the account.
18. Ben's successful attack on an authenticated user required him to duplicate the cookies that the web application put in place to identify the legitimate user. What type of attack did Ben conduct?
    1. Impersonation
    2. MitM
    3. Session hijacking
    4. Privilege escalation
19. Gabby connects to a Linux web server and executes an attack that gives her access to the account that the Apache web server runs as. If her next attack is aimed at a script that runs with root privileges, what type of attack has she attempted?
    1. A brute-force attack
    2. A dictionary attack
    3. A pass-the-hash attack
    4. A privilege escalation attack
20. Michelle has a security token that her company issues to her. What type of authentication factor does she have?
    1. Biometric
    2. Possession
    3. Knowledge
    4. Inherence