By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.
Objective: Given a scenario, implement authentication and authorization solutions. Topics: - authentication management - password vault - Trusted Platform Module (TPM) - hardware security module (HSM) - knowledge-based authentication (KBA) - Extensible Authentication Protocol (EAP) - Challenge Handshake Authentication Protocol (CHAP) - Password Authentication Protocol (PAP) - 802.1X - Remote Authentication Dial-In User Service (RADIUS) - single sign-on (SSO) - Security Assertion Markup Language (SAML) - Terminal Access Controller Access Control System Plus (TACACS+) - Open Authorization (OAuth) - OpenID - Kerberos - attribute-based access control (ABAC) - role-based access control (RBAC) - rule-based access control - mandatory access control (MAC) - discretionary access control (DAC) - conditional access - privileged access management (PAM) Authentication Authentication and authorization issues such as unencrypted credentials, incorrect permissions, and access violations leave an organization vulnerable. Sometimes organizational configurations expose credentials. For example, the Starbucks iOS mobile app sent user passwords in plaintext for most of a year before the app was fixed. The vulnerability happened because of the way crash information data was produced. Because users often reuse personal passwords on their corporate and organizational accounts, a mobile app vulnerability like this could well lead to the compromise of organizational data. Many of the protocols and services discussed in this guide provide methods to help with various authentication issues, such as using strong underlying protections of the password itself and helping to ensure ease of use by allowing the user to remember one password to authenticate across multiple applications and services. Single-sign on (SSO) solutions provide this capability. Given the proliferation of applications, ensuring strong passwords while providing ease of use is especially critical for large organizations. An alternative to SSO solutions, and still often a needed supplement, is the use of a password vault. A password vault can store all of user’s credentials, protected with a single strong password. Forgetting passwords presents unique challenges. For example, a password reset process provides an avenue for an attacker to compromise an account. As a result, many organizations have implemented safety measures in the process, such as knowledge-based authentication (KBA). KBA is often also used to mitigate risk where further verification is required after initial authentication if there is any doubt. KBA is based on personal information that is known by the user or can be something easily recalled, such as questions previously answered about the first street you grew up on or your first pet’s name. KBA may also include publicly available information drawn from databases or credit reports, such as domain names registered or monthly mortgage payment. KBA should never be relied upon as the only mechanism but can be paired with other controls to mitigate risk. KBA and, in particular, the need to facilitate password resets is often a function of authentication management. Authentication management involves the management of user credentials across their life cycle, from onboarding and ongoing management to offboarding. Authentication management has grown well beyond password synchronization and self-service password resets. Organizations have deployed hundreds of applications both on premises and in the cloud. Users are mobile. Users have a lot of devices, which means they have a lot of credentials to manage. In addition to passwords, there are smart cards, hardware and software multifactor tokens, biometrics, KBA security questions, digital certificates, and more.
Trusted Platform Module (TPM) chips and hardware security modules (HSMs) provide strong hardware-based cryptographic solutions across a number of use cases, including password protection and device identification and authentication. Unencrypted Plaintext Credentials Weak passwords are often discovered when using security tools. Recall the previous Starbucks example: An organization can mitigate this type of exposure in several ways. Authentication alone is typically not sufficient when weak passwords are used. When an application or a service stores or sends passwords in plaintext, risk to the organization can be reduced by sending the credentials via an encrypted channel such as HTTPS. This prevents malicious users from capturing the plaintext passwords. Probably one of the most unintentional exposures of a password in plaintext occurs when a user logs in and types the password into the username field. In a Windows environment, failed logins record the plaintext password in the Security log. Most web applications log unsuccessful login attempts, so passwords can similarly end up being logged with web-based applications. Although an attacker would need additional information to obtain the associated username, it could be possible. For example, when users log in incorrectly, they usually immediately attempt to log in again. Chances are pretty good that the next successful login is the username associated with the previous failed login. This method of association has a greater success rate in a small environment. The best defense against this type of exposure is to educate users about the vulnerability such a failed login presents and have them change the password after it happens. Filesystem Permissions When trying to access resources such as files, you have likely seen the message “Access Denied” at some point. This notification is a sign that filesystem permissions are set to deny access to the requested resource. These common user activities tend to be associated with permission issues: - Reading, modifying, and deleting files - Accessing shared folders on the network - Using services such as remote access or remote desktop services - Using devices such as printers These activities can be restricted by design or because of misconfigured user account permissions. Keep in mind that the principle of least privilege is critical for proper security. Users should not have more permissions than they require to do their job. For example, a user could have access to employee records or customer data that should be restricted to a small group of upper management. The biggest security issue with incorrect user account permissions is that they could grant access to information that a user should not be able to access. One of the best examples of misconfigured user access involves Chelsea (formerly Bradley) Manning, who was able to exfiltrate sensitive data because of misconfigured permissions. Misconfigured permissions leave a network vulnerable and can violate regulatory compliance. Auditing user permissions is one way of identifying access violations and issues. Auditing user permissions is generally a two-step process that involves turning on auditing within the operating system and then specifying the resources to be audited. After you enable auditing, you also need to monitor the logs that are generated. Auditing should include both privilege and use. Access use and rights changes should be audited to prevent unauthorized or unintentional access or an escalation of privileges that, for example, might give a guest or restricted user account access to sensitive or protected resources. When configuring an audit policy, it is important to monitor both successful and failed access attempts. Failure events enable you to identify unauthorized access attempts. Successful events can reveal accidental or intentional escalation of access rights. In a Windows environment, user permissions are generally assigned via group policy. Group policies can get complex, leading to permission issues. The easiest way to determine what group policies have been applied is to use GPResult, a command-line utility that determines the policy for a given user or computer. Another helpful tool for troubleshooting permissions issues for users or groups is AccessChk. It shows the permissions that specific users and groups have for files, folders, registry keys, Windows services, and other objects. Using AccessChk is a quick way to determine whether the proper level of security has been applied. Permissions in Windows are relatively straightforward and self-explanatory. As shown in the figure below, these are the standard Windows permissions: Standard Microsoft Windows file permissions
- Full Control: Gives the user complete control, including the ability to modify permissions on files and folders. - Modify: Gives the user the ability to read a file, write changes, and modify permissions. - Read & Execute: Permits the user to see folder content, read files and attributes, and run programs. - List Folder Contents: Permits the user to view the contents of a folder. This permission applies only to folders and not files. - Read: Permits the user to read a file but not make changes to the file. - Write: Permits the user to change the contents of files and folders and create new files. As shown in the figure above, basic permissions are simple to apply and manage. These basic permissions can be combined into more advanced special permissions, which can be accessed by clicking the Advanced button on the Security tab (refer to Figure 24.1). Table 24.1 shows how the basic permissions are combined to form the advanced permissions.
Windows Basic and Advanced Permissions
Review this table and make sure you are familiar enough with this material that, when given a scenario, you can identify required permissions. Keep in mind that permissions are inherited from their containers, except where explicitly allowed or denied. An allowed permission will only ever override a denied permission when a member is part of multiple groups, and one group has an explicit allow while the other group has an inherited deny. Linux provides for many of the same outcomes as Windows, but file permissions are implemented quite differently.
In Linux, there are three basic permission types: - Read (represented as the letter r or the number 4): When applied to a file, allows the user to view the contents of a file. When applied to a directory, allows the user to view the names of the files within the directory. - Write (represented as the letter w or the number 2): When applied to a file, allows the user to modify and delete a file. When applied to a directory, allows the user to delete the directory; create, delete, and rename files; and modify the contents of any file that the user is allowed to read. - Execute (represented as the letter x or the number 1): When applied to a file along with the read permission, allows the user to run a file such as an executable or a script. Before we look at how these permissions are applied, you need to understand that Linux involves three different types of entities: - Owner: The owner is usually provided all permissions as the owner of the file or folder. - Group: The group is a named group to which users can belong. - Others: Others includes everyone else and cannot override permissions given by the owner or group. Permissions are represented in three groups of three, where read, write, and execute may apply across owner, group, and others. The permissions are commonly represented together, and a dash is used to denote no permission assigned. For example, the following represents a file that can be modified (and read) by everyone: -rw-rw-rw-. The first three characters are the owner, the second three are the group, and the final three characters are others. As noted earlier in this section, the permissions can also be represented by numbers rather than with r, w, and -. These numbers can be added together to set permissions. For example, 640 represents -rw-r-----. The 6 gives the user read and write (4+2=6). The 4 gives the group read, and the 0 provides no permissions. Access Violations You already know that too much access creates risk for an organization, and too little access slows productivity. Just as user access can be managed via auditing, access violations can be managed through enterprise-level software. In a Windows environment, Microsoft Operations Manager (MOM) has an Audit Collection Services (ACS) function that collects audit events in a database that can then be queried. ACS provides two preconfigured reports: - Access Violation Account Locked report - Access Violation Unsuccessful Logon Attempts report In addition to the tools available in an OS, vendors provide software to manage access violations. For example, certain software and services allow organizations to automate the recognition and notification of access permission violations so that they can then calculate the financial impact of the violations. Authentication Issues Users are likely to have experienced authentication issues at some time or other. Perhaps the most annoying problem arises when a frequently visited site makes changes, and a user’s password no longer works. When both the username and password are correct, other factors are causing the authentication issue. These are the most common authentication issues: - Incorrect username - Incorrect password - Disabled or deleted account - Restricted user rights - Computer not in the domain - Domain controller not available To resolve these authentication issues, the first item to check as you begin the troubleshooting process is that the correct username and password have been entered. Then you need to verify that the user’s password has not expired or that the account has not been disabled. Finally, check to be sure no basic connectivity issues exist between the client machine and the domain controller. Even if no local machine and network issues are present, authentication issues can occur. For example, Microsoft had authentication issues that prevented access to related applications for anyone with a cloud-based account. In such a situation, only the service provider can resolve the authentication issue. Authentication Protocols This section discusses the various identity and access services and explores how they are used. It covers services that use tickets, such as Kerberos; services that use challenge mechanisms, such as Challenge Handshake Authentication Protocol (CHAP); remote access services, such as RADIUS; and federated services, such as OAuth. Password Authentication Protocol (PAP) is a simple authentication protocol in which the username and password are sent to the remote access server in plaintext. PAP offers no protection from playback or trial-and-error attacks. The remote server is in control of the frequency and timing of the login attempts. Using PAP is strongly discouraged because user passwords are easily readable from the Point-to-Point Protocol (PPP) packets exchanged during the authentication process. PPP is a protocol for communicating between two points using a serial interface, and it provides service at Layer 2 of the OSI model (the data link layer). The default status of any PPP link is to not require authentication of the remote host. PAP is typically used only when connecting to older Unix-based remote access servers that do not support more secure authentication protocols. Challenge Handshake Authentication Protocol (CHAP) can be used to provide on-demand authentication in an ongoing data transmission. CHAP uses a one-way hashing function that first involves a service requesting a CHAP response from the client. The client creates a hashed value that is derived using the Message Digest (MD5) hashing algorithm and sends this value to the service, which also calculates the expected value. The server, referred to as the authenticator, compares these two values. If the values match, the transmission continues. This process is repeated at random intervals during a session of data transaction to help eliminate the possibility of a replay attack. The process of authenticating is called a three-way process. Actually, however, four steps are involved because the first step is establishing the connection, but the authentication process itself is a three-way process. CHAP is an improvement over PAP because it hashes the password but still sends the username in plaintext. CHAP functions over PPP connections. Microsoft CHAP (MSCHAP) is an encrypted authentication mechanism that is similar to CHAP. It comes in two versions, MSCHAPv1 and MSCHAPv2. MSCHAPv1 is a one-way authentication method in which the server requires authentication from the client. This version should not be used. MSCHAPv2 provides stronger security because it uses a new string each time the authentication is challenged. In MSCHAPv2, the client and server mutually authenticate and use two encryption keys: one for sending data and one for receiving data. PAP, CHAP, and MSCHAP are authentication protocols intended for use primarily by hosts and routers that connect to a PPP or PPP over Ethernet (PPPoE) network server via switched circuits or dial-up lines. These are all older, less secure protocols. In August 2012, Microsoft advised against using MSCHAPv2 and recommended using either MSCHAP with Protected Extensible Authentication Protocol (PEAP) or more secure alternatives, such as L2TP/IPsec. When implementing security for a legacy protocol such as MSCHAPv2, Extensible Authentication Protocol (EAP) can be used. EAP is a password-based authentication framework. In this implementation, the client doesn’t need to have a certificate, but the authentication server has one. Passwords from the clients are sent using hashes to the authentication server. If the environment allows for a stronger authentication method, PEAP can be used. PEAP acts as a TLS/SSL tunnel and protects the authentication traffic. PEAP uses a certificate on the authentication server and optionally a certificate on the client. 802.1X Devices that need to connect to a wireless network can also be controlled via the Institute of Electrical and Electronics Engineers (IEEE) 802.1X standard. (Do not confuse this with 802.11.) 802.1X provides standards for port-based access control, whereas 802.11 is specific to wireless technology. 802.1X provides a method for authenticating a device to another system via an authentication server. 802.1X specifically provides for the encapsulation of EAP over the IEEE family of standards for packet-based networks. The standard essentially facilitates the use of various authentication methods, such as RADIUS, digital certificates, and one-time password devices. AAA Protocols and Services Two prominent security protocols used to control access in networks are TACACS+ and RADIUS. Remote Authentication Dial-In User Service (RADIUS) remote access control system provides authentication and access control in an enterprise network, using UDP transport to a central network access server. In turn, this provides credentials for client access to resources in the extended enterprise. RADIUS was originally developed for use in dial-up connectivity over telephony, and you might still find RADIUS servers in larger enterprises where logons must span resources located in multiple logon realms. A protected network segment might implement a virtual private network (VPN) or remote access server (RAS) gateway connection to allow an authenticated external service request to reach a protected server by communicating with a RADIUS server. The requesting account must provide its credentials to the RADIUS server, which then authorizes the access request. A RADIUS server supports a variety of authentication methods, including PPP, PAP, CHAP, and Unix login authentication mechanisms. RADIUS provides authentication and authorization functions as well as network access accounting functions. However, it does not provide further access control. RADIUS can forward authentication and authorization requests between authentication domains (called realms) and thus can facilitate cross-enterprise authentication, often as part of a single sign-on (SSO) solution. Terminal Access Controller Access Control System Plus (TACACS+) is a protocol that was developed by Cisco and released as an open standard beginning in 1993. Although it derives from TACACS, TACACS+ is a separate protocol that handles authentication, authorization, and accounting (AAA) services. TACACS+ is similar to RADIUS but uses TCP as a transport method; it uses port 49 as the default port. TACACS+ takes a client/server model approach. The client first queries the server. The client is typically a router or a firewall that is used to determine whether the user has proper authorization to access the network. The server sends back a reply indicating whether the user passed authentication. Both TACACS+ and RADIUS have an accounting function, so if a device were intentionally compromised, an audit trail would show the originating IP address and the user account logged in to the device.
TACACS+ offers several advantages over RADIUS: - TACACS+ tends to be more reliable because it uses TCP instead of UDP. - TACACS+ encrypts the entire body of the packet in the original access request packet. RADIUS encrypts only the password, leaving information such as the username subject to the compromise. - TACACS+ uses the AAA architecture. TACACS+ can therefore be used for authorization and accounting with separate authentication methods. RADIUS combines the authentication and authorization features of AAA, making it difficult to use the functions separately. - TACACS+ provides methods to control the authorization of router commands. RADIUS is not as useful for router management or as flexible for terminal services because it does not allow users to control the commands that can be executed. Consider an example of when TACACS+ should be used instead of RADIUS: An organization requires the use of Kerberos authentication but also needs authorization and accounting functions. In this instance, the network access server (NAS) informs the TACACS+ server that it has successfully authenticated on a Kerberos server. The server then provides authorization information without requiring reauthentication. To minimize the chance of compromising the entire user/password database, a TACACS+ server should not run other applications. Proper access control lists should be implemented, and additional security steps (such as using TCP wrappers) should be taken to prevent connection to the TACACS+ server in the event that an internal device is compromised. Federated Services Technologies used for federated identity include SAML, OAuth, OpenID, Simple Web Tokens, and JSON Web Tokens. These technologies use secure tokens. Token authentication is a good approach to authentication because it is stateless. Instead of authenticating with the username and password for each resource, the user authenticates once with the username and password and then receives a secure token. The token is then used for further authentication and expires after a set amount of time. This method prevents storage of user information on the server or in a session. Using tokens provides restrictive permissions to third-party applications such as Twitter and Facebook. Security Assertion Markup Language (SAML) is an Extensible Markup Language (XML) framework for creating and exchanging security information between online partners. It is a product of the OASIS Security Services Technical Committee. Most cloud and Software as a Service (SaaS) service providers favor SAML because it provides authentication assertion, attribute assertion, and authorization assertion. Authentication assertion validates the user’s identity. Attribute assertion contains information about the user, and authorization assertion identifies what the user is authorized to do. The main purpose of SAML is to provide single sign-on for enterprise users. The SAML framework defines three main functions: - The user seeking to verify its identity is the principal. - The entity that can verify the identity of the end user is the identity provider. - The entity that uses the identity provider to verify the identity of the end user is the service provider. The following process occurs with single sign-on:
The main difference between SAML and other identity mechanisms is that SAML relies on assertions about identities. The weakness in the SAML identity chain is the integrity of users. SAML uses SAM, XML, HTTP, and SOAP protocols. To mitigate risk, SAML systems need to use timed sessions, HTTPS, and SSL/TLS. Open Authorization (OAuth) is a framework used for Internet token-based authorization. The main purpose of OAuth is API authorization between applications. Two versions are used; the most current is Version 2.0. The OAuth framework consists of the following: - The resource owner - The OAuth provider, which is the hosting resource server - The OAuth consumer, which is the resource consumer OAuth 2.0 defines four roles: resource owner, authorization server, resource server, and client.
It creates separate roles for the resource server and authorization server. OAuth 2.0 obtains authorization for the user via an access token and then uses that token to make user requests. Flows, which are called grant types in OAuth 2.0, make it possible to get access tokens. There are several grant types: - Authorization code: This grant type is used for server-side applications. The user is prompted to authorize the application, the identity provider supplies an authorization code, and the application server exchanges the authorization code for an access token. - Implicit: This grant type is used for client-side web applications. This grant type doesn’t have a server-side component. It skips the authorization code generation step. Immediately after the user authorizes the application, an access token is returned. - Password credentials: This grant type is used for first-class web applications or mobile applications. This grant type is to be used only for native web or mobile applications because it allows applications to collect the user’s username and password and exchange them for an access token. - Client credentials: This grant type is used for application code to allow an application to access its own resources. The application makes a request, using its own credentials, to receive an access token. OAuth 2.0 uses the JSON and HTTP protocols. Because it only provides authorization services, it does not support secure methods such as client verification, encryption, or channel binding. OAuth 2.0 relies on underlying technologies, implementers, and other protocols to protect the exchange of data. SSL/TLS is recommended to prevent eavesdropping during the data exchange. If a user was not logged in to the server before the OAuth initiation request, resource providers should automatically log the user out after handling the third-party OAuth authorization flow to prevent session management exploits. OAuth does not provide authentication services. It is used exclusively for authorization services, which makes it different from OpenID and SAML. OpenID Connect is an identity layer based on OAuth 2.0 specifications that is used for consumer single sign-on. OpenID Connect is similar to the open standard OpenID, sponsored by Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec, and Yahoo!. In 2015, Google recommended switching from OpenID to OpenID Connect. OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process and provides additional mechanisms for signing, encryption of identity data, and session management. The OpenID Connect protocol specifications guide states this process for validation:
OpenID Connect uses an ID token structure that contains an authorization server’s claims about the authentication of an end user via a JSON Web Token (JWT). A JWT is used to prove that the sent data was created by an authentic source. The flows determine how the ID token and access token are returned to the client. Authentication takes place through one of three flows: - The authorization code flow returns an authorization code to the client, which then exchanges it for an ID token and an access token. - The implicit flow eliminates the token endpoint. All tokens are returned from the authorization endpoint. - The hybrid flow can have some tokens returned from the authorization endpoint and some returned from the token endpoint. The OpenID Connect specification takes attacks into consideration and resolves many of the security issues with OAuth 2.0. However, if guidelines are not followed to implement it securely, broken end-user authentication can result. Shibboleth is a SAML-base, open-source federated identity solution that provides SSO capabilities and federated services and is popular in research and educational institutions. Ongoing development, support, and maintenance are performed by the Shibboleth Consortium. Shibboleth works similarly to other SSO systems, and it supports services outside organizational boundaries. Shibboleth uses the following three elements: - The identity provider (IdP), located in the home organization, authenticates the user. - The service provider (SP), located at the resource organization, performs the SSO process for the protected resource. - The discovery service (DS) is useful for finding the user’s IdP. It can be located anywhere on the Web and is not a required component. The functions that happen with Shibboleth SSO are the same as the functions described for SAML. Shibboleth is a flexible solution because it is based on standards. Some federated systems are designed to work only when the identity provider and the service provider are in the same organization, but Shibboleth works across organizations. This flexibility enlarges the attack surface. The Shibboleth Consortium maintains a current list of security advisories issued from incorrect configurations by service or identity providers. Kerberos To avoid sending the open plaintext logon information across an unsecured network, one solution is to use the symmetric key authentication protocol known as Kerberos (created by the Athena project at MIT and named for the three-headed dog Cerberus that guarded Hades). Kerberos is an authentication protocol that has been around for decades and is an open standard. Symmetric key means that the client and the server must agree to use a single key in the encryption and decryption processes. Kerberos is primarily a UDP protocol, although it falls back to TCP for large Kerberos tickets. Kerberos clients send UDP and TCP packets on port 88 and receive replies from the Kerberos servers. Port 88 is the standard port for Kerberos V5 for the KDC, and port 749 is used for the administrative server.
Access Control Access control generally refers to the process of making resources available to accounts that should have access, while limiting that access to only what is required. You need to know these forms of access control: - Mandatory access control (MAC) - Discretionary access control (DAC) - Attribute-based access control (ABAC) - Rule-based access control - Role-based access control (RBAC) The most basic form of access control involves assigning labels to resources and accounts (for example, SENSITIVE, SECRET, and PUBLIC). If the labels on an account and a resource do not match, the resource remains unavailable in a nondiscretionary manner. This type of access control, called mandatory access control (MAC, also referred to as multilevel access control), is often used within government systems, where resources and access are granted based on the categorical assignments such as classified, secret, or top secret. Mandatory access control applies to all resources within the network and does not allow users to extend access rights by proxy. A slightly more complex system of access control involves restricting access for each resource in a discretionary manner. Discretionary access control (DAC) scenarios allow individual resources to be individually made available or secured against access. Access rights are configured at the discretion of the accounts that have the authority over each resource, including the capability to extend administrative rights through the same mechanism. In DAC, a security principal (account) has complete control over the objects that it creates or otherwise owns unless this is restricted through group or role membership. The owner assigns security levels based on objects and subjects and can make his or her own data available to others as desired. A common scenario for DAC is online social network users choosing who can access their data. The Trusted Computer System Evaluation Criteria (TCSEC) specification that many government networks use explicitly specifies only the MAC and DAC forms of access control. The TCSEC specification is sometimes referred to as the Orange Book because of the original color of the printed manual’s cover (DoD 5200.28-STD). The designation RBAC is sometimes used to refer to rule-based access control in addition to role-based access control. Rule-based access control dynamically assigns roles to users based on criteria that the data custodian or system administrator defines. Rule-based access control includes controls such as the time of day, the day of the week, specific terminal access, and GPS coordinates of the requester, along with other factors that might overlay a legitimate account’s access request. Implementation of rule-based access control might require that rules be programmed using code instead of allowing traditional access control by checking a box. In a role-based access control (RBAC) scenario, access rights are first assigned to roles. Then accounts are associated with these roles, without the direct assignment of resource access rights. This solution provides the greatest level of scalability in large enterprise scenarios, where explicitly granting rights to each individual account could rapidly overwhelm administrative staff and increase the potential for accidentally granting unauthorized permissions. RBAC combines some direct access aspects of mandatory access control and varying discretionary access rights based on role membership. Delegated administration over rights granted through RBAC is itself managed by specialized administration roles instead of through ownership or direct control over the individual resources, as in strictly DAC solutions. Remember that the exam might use the RBAC acronym to refer to rule-based access control. In a rule-based access control solution, access rights can vary by account, time of day, the trusted OS, or other forms of conditional testing. Exam items that deal with conditional access (for example, time-of-day controls) are examining rule-based access control. Items that involve assigning rights to groups for inheritance by group member accounts are focusing on role-based access control. As the RBAC specification became popular and made possible central management of enterprise access control, the need for access control lists (ACLs) was reduced. RBAC does not easily support multifactor decisions and lacks the capability to associate roles with access control requirements. This makes long-term maintenance difficult. Attribute-based access control (ABAC) is a logical access control model that the Federal Identity, Credential, and Access Management (FICAM) Roadmap recommends as the preferred access control model for information sharing among diverse organizations. ABAC is based on Extensible Access Control Markup Language (XACML). The reference architecture is similar to the core components of AAA. The ABAC authorization process is determined by evaluating rules and policies against attributes associated with an entity, such as the subject, object, operation, or environment condition. Attributes are characteristics that define specific aspects of the entity. When an access request is made, the access decision is based on the evaluation of attributes and access control rules by the attribute-based access control mechanism. ABAC is a more dynamic access control method. When attribute values change, the access is changed based on the attribute changes. ABAC systems are capable of enforcing both DAC and MAC models. ABAC is well suited for large and federated enterprises, which makes it more complicated and costly to implement and maintain than simple access control models. Privileged Access Management In addition to authentication management, discussed earlier in this guide, privileged access management (PAM) addresses the notion of ensuring least privilege and preventing attackers from using elevated privileges to cause disruption. PAM helps in regard to privileged access to sensitive data and critical business functions: - Privileged account discovery: PAM identifies privileged accounts such as those that use administrative credentials to log on to workstations and even where privileged accounts are hard-coded into software and other communications. - Governing access: PAM enables management through the account life cycle, including how accounts get access and what privileges are required. - Auditing activity: PAM provides logging activity of privileged access use and attempts, as well as anomalous behavior tracking. - Automated task management: PAM helps with automation of repeatable tasks, such as software installations, scheduled tasks, and service account interaction. PAM is particularly important where access to backend systems is required. Another example is systems that communicate with each other, such as a server talking to a backend database server. Often there may be no human element involved but just one machine accessing another. The specific types of accounts for which you might consider a PAM solution include the following: - Service accounts - Administrator and root accounts - Application accounts - Network accounts Quiz questions:1. Which of the following use SAML? (Select two.) A. Secure token B. OpenID C. OAuth D. LDAP2. Which of the following is a true statement regarding role-based access control? A. Access rights are first assigned to users. Roles are then associated with those access rights. B. Access rights are first assigned to roles. User accounts are then associated with those access rights. C. Access rights are first assigned to roles. User accounts are then associated with those roles. D. Access rights are first assigned to users. Roles are then associated with those users.3. Which of the following statements are correct regarding Shibboleth SSO? (Select two.) A. The identity provider (IdP) authenticates the user. B. The service provider (SP) authenticates the user. C. The identity provider (IdP) performs the SSO process for the protected resource. D. The service provider (SP) performs the SSO process for the protected resource.4. What type of access control is often used in government systems, where resources and access are granted based on categorical assignments such as classified, secret, or top secret? A. Mandatory access control (MAC) B. Discretionary access control (DAC) C. Attribute-based access control (ABAC) D. Role-based access control (RBAC)5. Which of the following is a symmetric key–based authentication protocol that uses a key distribution center? A. TACACS+ B. Kerberos C. RADIUS D. HSM6. Based on the following permissions for a file, which one of the following statements is not true? A. The owner has read, write, and execute permissions. B. The group has read permissions. C. Those other than the owner or group have no permissions. D. Only the group has both read and write permissions. Answer 1: B and C. OpenID and OAuth are both federated services that use SAML technology. These technologies do use secure tokens for authentication, but secure tokens don’t necessarily use SAML, so Answer A is incorrect. Answer D is incorrect as this is a directory service that does not specifically use SAML. Answer 2: C. In a role-based access control (RBAC) scenario, access rights are first assigned to roles. Then user accounts are associated with those roles, without the direct assignment of resource access rights. The other choices are all incorrect statements, so Answers A, B, and D are incorrect. Answer 3: A and D. Shibboleth works similarly to other SSO systems, and it supports services outside organizational boundaries. The identity provider (IdP) authenticates the user. The service provider (SP), performs the SSO process for the protected resource. Answers B and C are incorrect. Answer 4: A. This type of access control, called MAC, is often used in government systems. Answer B is incorrect because DAC scenarios allow individual resources to be individually made available or secured against access. Access rights are configured at the discretion of the accounts that have the authority over each resource, including the capability to extend administrative rights through the same mechanism. Answer C is incorrect because ABAC is a logical access control model that the Federal Identity, Credential, and Access Management (FICAM) Roadmap recommends as the preferred access control model for information sharing among diverse organizations. ABAC is based on Extensible Access Control Markup Language (XACML). Answer D is incorrect. In a role-based access control (RBAC) scenario, access rights are first assigned to roles. Then accounts are associated with these roles, without the direct assignment of resource access rights. Answer 5: B. Kerberos is a symmetric key authentication protocol that has been around for decades and is an open standard. With Kerberos authentication, a client sends its authentication details not to the target server but to a key distribution center (KDC). Answer A is incorrect. TACACS+ is a protocol that handles authentication, authorization, and accounting (AAA) services. It is similar to RADIUS but uses TCP as a transport method; it uses port 49 as the default port. TACACS+ takes a client/server model approach. Answer C is incorrect. The Remote Authentication Dial-In User Service (RADIUS) remote access control system provides authentication and access control in an enterprise network, using UDP transport, to a central network access server. In turn, this provides credentials for client access to resources in the extended enterprise. Answer D is incorrect because the main focuses of hardware security modules (HSMs) are performance and key storage space. HSMs can also enforce separation of duties for key management by separating database and security administration. Answer 6: D. Based on the permissions shown, Answers A, B, and C are all true statements, while answer D is not. The first three permissions represent the owner, which has read, write, and execute permissions. The second three permissions represent the group, which only has read permissions. The third three permissions indicate that everyone else does not have any permissions.
Join 4M+ learners. Unlock unlimited quizzes, wrong-answer tracking, flashcards + reminders, study guides, and 1-on-1 challenges.