Requirement 8: Identify Users And Authenticate Access

Two fundamental principles of identifying and authenticating users are to 1) establish the identity of an individual or process on a computer system, and 2) prove or verify the user associated with the identity is who the user claims to be. These requirements for identity and authentication are based on industry-accepted security principles and best practices to support the payment ecosystem. NIST Special Publication 800-63, Digital Identity Guidelines provides additional information on acceptable frameworks for digital identity and authentication factors.

Requirement 8: Identify Users And Authenticate Access

8.1 Processes And Mechanisms For Identifying Users And Authenticating Access To System Components Are Defined And Understood

8.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

8.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed

The ability to trace actions performed on a computer system to an individual establishes accountability and traceability and is fundamental to establishing effective access controls.

By ensuring each user is uniquely identified, instead of using one ID for several employees, an organization can maintain individual responsibility for actions and an effective record in the audit log per employee. In addition, this will assist with issue resolution and containment when misuse or malicious intent occurs.

8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: • Account use is prevented unless needed for an exceptional circumstance • Use is limited to the time needed for the exceptional circumstance • Business justification for use is documented • Use is explicitly approved by management • Individual user identity is confirmed before access to an account is granted • Every action taken is attributable to an individual user

If shared accounts are used for any reason, strong management controls need to be established to maintain individual accountability and traceability.

8.2.3 Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises

Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services.

If a service provider uses the same authentication factors to access multiple customers, all the service provider’s customers can easily be compromised if an attacker compromises that one factor.

Criminals know this and deliberately target service providers looking for a shared authentication factor that gives them remote access to many merchants via that single factor.

8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: • Authorized with the appropriate approval • Implemented with only the privileges specified on the documented approval

It is imperative that the lifecycle of a user ID (additions, deletions, and modifications) is controlled so that only authorized accounts can perform functions, actions are auditable, and privileges are limited to only what is required.

Attackers often compromise an existing account and then escalate the privileges of that account to perform unauthorized acts, or they may create new IDs to continue their activity in the background. It is essential to detect and respond when user accounts are created or changed outside the normal change process or without corresponding authorization.

8.2.5 Access for terminated users is immediately revoked

If an employee or third party/vendor has left the company and still has access to the network via their user account, unnecessary or malicious access to cardholder data could occur either by the former employee or by a malicious user who exploits the old and/or unused account.

8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity

Where it may be reasonably anticipated that an account will not be used for an extended period of time, such as an extended leave of absence, the account should be disabled as soon as the leave begins, rather than waiting 90 days.

8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows: • Enabled only during the time period needed and disabled when not in use • Use is monitored for unexpected activity

Enabling access only for the time periods needed and disabling it as soon as it is no longer required helps prevent misuse of these connections. Additionally, consider assigning third parties a start and stop date for their access in accordance with their service contract.

Monitoring third-party access helps ensure that third parties are accessing only the systems necessary and only during approved time frames. Any unusual activity using third-party accounts should be followed up and resolved.

8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session

The re-authentication can be applied either at the system level to protect all sessions running on that machine or at the application level.

Entities may also want to consider staging controls in succession to further restrict the access of an unattended session as time passes. For example, the screensaver may activate after 15 minutes and log off the user after an hour.

However, timeout controls must balance the risk of access and exposure with the impact to the user and purpose of the access.

If a user needs to run a program from an unattended computer, the user can log in to the computer to initiate the program, and then “lock” the computer so that no one else can use the user’s login while the computer is unattended.

8.3 Strong Authentication For Users And Administrators Is Established And Managed

8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: • Something you know, such as a password or passphrase • Something you have, such as a token device or smart card • Something you are, such as a biometric element

A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack.

8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components

Network devices and applications have been known to transmit unencrypted, readable authentication factors (such as passwords and passphrases) across the network and/or store these values without encryption. As a result, a malicious individual can easily intercept this information during transmission using a “sniffer,” or directly access unencrypted authentication factors in files where they are stored, and then use this data to gain unauthorized access.

8.3.3 User identity is verified before modifying any authentication factor

Modifications to authentication factors for which user identity should be verified include but are not limited to performing password resets, provisioning new hardware or software tokens, and generating new keys.

8.3.4 Invalid authentication attempts are limited by: • Locking out the user ID after not more than 10 attempts • Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed

Before reactivating a locked account, the user’s identity should be confirmed. For example, the administrator or help desk personnel can validate that the actual account owner is requesting reactivation, or there may be password reset self-service mechanisms that the account owner uses to verify their identity.

8.3.5 If passwords/passphrases are used as authentication factors, they are set and reset for each user as follows: • Set to a unique value for first-time use and upon reset • Forced to be changed immediately after the first use

If the same password/passphrase is used for every new user, an internal user, former employee, or malicious individual may know or easily discover the value and use it to gain access to accounts before the authorized user attempts to use the password.

8.3.6 If passwords/passphrases are used as authentication factors, they meet the following minimum level of complexity: • A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters) • Contain both numeric and alphabetic characters

Password/passphrase strength is dependent on password/passphrase complexity, length, and randomness. Passwords/passphrases should be sufficiently complex, so they are impractical for an attacker to guess or otherwise discover its value. Entities can consider adding increased complexity by requiring the use of special characters and upper- and lower-case characters, in addition to the minimum standards outlined by this requirement. Additional complexity increases the time required for offline brute force attacks of hashed passwords/passphrases.

Another option for increasing the resistance of passwords to guessing attacks is by comparing proposed password/passphrases to a bad password list and having users provide new passwords for any passwords found on the list.

8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used

If password history is not maintained, the effectiveness of changing passwords is reduced, as previous passwords can be reused over and over. Requiring that passwords cannot be reused for a period reduces the likelihood that passwords that have been guessed or brute-forced will be re-used in the future.

Passwords or passphrases may have previously been changed due to suspicion of compromise or because the password or passphrase exceeded its effective use period, both of which are reasons why previously used passwords should not be reused.

8.3.8 Authentication policies and procedures are documented and communicated to all users including: • Guidance on selecting strong authentication factors • Guidance for how users should protect their authentication factors • Instructions not to reuse previously used passwords/passphrases • Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident

Guidance on selecting strong passwords may include suggestions to help personnel select hard-to-guess passwords that do not contain dictionary words or information about the user, such as the user ID, names of family members, date of birth, etc.

Guidance for protecting authentication factors may include not writing down passwords or not saving them in insecure files, and being alert to malicious individuals who may try to exploit their passwords (for example, by calling an employee and asking for their password so the caller can “troubleshoot a problem”).

Alternatively, entities can implement processes to confirm passwords meet password policy, for example, by comparing password choices to a list of unacceptable passwords and having users choose a new password for any that match with one on the list. Instructing users to change passwords if there is a chance the password is no longer secure can prevent malicious users from using a legitimate password to gain unauthorized access.

8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either: • Passwords/passphrases are changed at least once every 90 days, OR • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly

Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.

Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase.

Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points, which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that authentication credentials have been compromised.

8.3.10 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users including: • Guidance for customers to change their user passwords/passphrases periodically • Guidance as to when, and under what circumstances, passwords/passphrases are to be changed

Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.

8.3.10.1 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either: • Passwords/passphrases are changed at least once every 90 days, OR • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly

Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.

Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that account credentials have been compromised.

8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used: • Factors are assigned to an individual user and not shared among multiple users • Physical and/or logical controls ensure only the intended user can use that factor to gain access

Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely authenticate the user of the account will prevent unauthorized users from gaining access to the user account through use of a shared authentication factor.

8.4 Multi-Factor Authentication (MFA) Is Implemented To Secure Access Into The CDE

8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access

Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase.

8.4.2 MFA is implemented for all access into the CDE

Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication actors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase.

8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows: • All remote access by all personnel, both users and administrators, originating from outside the entity’s network • All remote access by third parties and vendors

Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows, such as a password or passphrase.

8.5 Multi-Factor Authentication (MFA) Systems Are Configured To Prevent Misuse

8.5.1 MFA systems are implemented as follows: • The MFA system is not susceptible to replay attacks • MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period • At least two different types of authentication factors are used • Success of all authentication factors is required before access is granted

Poorly configured MFA systems can be bypassed by attackers. This requirement therefore addresses configuration of MFA system(s) that provide MFA for users accessing system components in the CDE.

8.6 Use Of Application And System Accounts And Associated Authentication Factors Is Strictly Managed

8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed as follows: • Interactive use is prevented unless needed for an exceptional circumstance • Interactive use is limited to the time needed for the exceptional circumstance • Business justification for interactive use is documented • Interactive use is explicitly approved by management • Individual user identity is confirmed before access to account is granted • Every action taken is attributable to an individual user

Where possible, configure system and application accounts to disallow interactive login to prevent unauthorized individuals from logging in and using the account with its associated system privileges, and to limit the machines and devices on which the account can be used.

8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code

Changing these values due to suspected or confirmed disclosure can be particularly difficult to implement.

Tools can facilitate both management and security of authentication factors for application and system accounts. For example, consider password vaults or other system-managed controls.

8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows: • Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis) and upon suspicion or confirmation of compromise • Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases

Entities should consider the following risk factors when determining how to protect application and system passwords/passphrases against misuse:

How securely the passwords/passphrases are stored (for example, whether they are stored in a password vault).

Staff turnover.

The number of people with access to the authentication factor.

Whether the account can be used for interactive login.

Whether the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

All these elements affect the level of risk for application and system accounts and might impact the security of systems accessed by the system and application accounts.

Entities should correlate their selected change frequency for application and system passwords/passwords with their selected complexity for those passwords/passphrases i.e., the complexity should be more rigorous when passwords/passphrases are changed infrequently and can be less rigorous when changed more frequently. For example, a longer change frequency is more justifiable when passwords/passphrases complexity is set to 36 alphanumeric characters with upper- and lower-case letters, numbers, and special characters.

Best practices are to consider password changes at least once a year, a password/passphrase length of at least 15 characters, and complexity for the passwords/passphrase of alphanumeric characters, with upper- and lower-case letters, and special characters.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your work environment and cardholder data is sitting on the server dz-win10.

Requirement 8.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirement 8.2, 8.3 And 8.6

It suggests that inactive user accounts should be removed or disabled within 90 days of inactivity. Also, if a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session. We can manage most of the requirements with the Identity and Access Management (IAM) software. IAM software can help in identity and authentication and password policy as well.

Requirements 8.4 And 8.5

Multi-factor authentication (MFA) is a common practice now. It should be implemented for all access to the CDE. It should also be implemented for remote access to CDE. The servers dz-win10, dsin-dangerzone and jump-server are major components of CDE in our example.