choose sub requirement:

Requirement 8.1

Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows:

Testing Procedure

8.1.a
Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows: (See 8.1.1 through 8.1.8)

8.1.b
Verify that procedures are implemented for user identification management, by performing the following: (See 8.1.1 through 8.1.8)

Guidance for 8.1 and 8.1.1

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 audit trail per employee. This will help speed issue resolution and containment when misuse or malicious intent occurs.

Requirement 8.1.1

Assign all users a unique ID before allowing them to access system components or cardholder data.

Testing Procedure

8.1.1
Interview administrative personnel to confirm that all users are assigned a unique ID for access to system components or cardholder data.

Guidance for 8.1 and 8.1.1

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 audit trail per employee. This will help speed issue resolution and containment when misuse or malicious intent occurs.

Requirement 8.1.2

Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

Testing Procedure

8.1.2
For a sample of privileged user IDs and general user IDs, examine associated authorizations and observe system settings to verify each user ID and privileged user ID has been implemented with only the privileges specified on the documented approval.

Guidance

To ensure that user accounts granted access to systems are all valid and recognized users, strong processes must manage all changes to user IDs and other authentication credentials, including adding new ones and modifying or deleting existing ones.

Requirement 8.1.3

Immediately revoke access for any terminated users.

Testing Procedure

8.1.3.a
Select a sample of users terminated in the past six months, and review current user access lists—for both local and remote access—to verify that their IDs have been deactivated or removed from the access lists.

8.1.3.b
Verify all physical authentication methods—such as, smart cards, tokens, etc.—have been returned or deactivated.

Guidance

If an employee 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. To prevent unauthorized access, user credentials and other authentication methods therefore need to be revoked promptly (as soon as possible) upon the employee’s departure.

Requirement 8.1.4

Remove/disable inactive user accounts within 90 days.

Testing Procedure

8.1.4
Observe user accounts to verify that any inactive accounts over 90 days old are either removed or disabled.

Guidance

Accounts that are not used regularly are often targets of attack since it is less likely that any changes (such as a changed password) will be noticed. As such, these accounts may be more easily exploited and used to access cardholder data.

Requirement 8.1.5

Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:

  • Enabled only during the time period needed and disabled when not in use.
  • Monitored when in use.

Testing Procedure

8.1.5.a
Interview personnel and observe processes for managing accounts used by vendors to access, support, or maintain system components to verify that accounts used by vendors for remote access are:

8.1.5.b
Interview personnel and observe processes to verify that vendor remote access accounts are monitored while being used.

Guidance

Allowing vendors to have 24/7 access into your network in case they need to support your systems increases the chances of unauthorized access, either from a user in the vendor’s environment or from a malicious individual who finds and uses this always-available external entry point into your network. Enabling access only for the time periods needed, and disabling it as soon as it is no longer needed, helps prevent misuse of these connections.

Monitoring of vendor access provides assurance that vendors are accessing only the systems necessary and only during approved time frames.

Requirement 8.1.6

Limit repeated access attempts by locking out the user ID after not more than six attempts.

Testing Procedure

8.1.6.a
For a sample of system components, inspect system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than six invalid logon attempts.

8.1.6.b
Additional testing procedure for service provider assessments only:
Review internal processes and customer/user documentation, and observe implemented processes to verify that non-consumer customer user accounts are temporarily locked-out after not more than six invalid access attempts.

Guidance

Without account-lockout mechanisms in place, an attacker can continually attempt to guess a password through manual or automated tools (for example, password cracking), until they achieve success and gain access to a user’s account.

Note: Testing Procedure 8.1.6.b is an additional procedure that only applies if the entity being assessed is a service provider.

Requirement 8.1.7

Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

Testing Procedure

8.1.7
For a sample of system components, inspect system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until a system administrator resets the account.

Guidance

If an account is locked out due to someone continually trying to guess a password, controls to delay reactivation of these locked accounts stops the malicious individual from continually guessing the password (they will have to stop for a minimum of 30 minutes until the account is reactivated). Additionally, if reactivation must be requested, the admin or help desk can validate that it is the actual account owner requesting reactivation.

Requirement 8.1.8

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

Testing Procedure

8.1.8
For a sample of system components, inspect system configuration settings to verify that system/session idle time out features have been set to 15 minutes or less.

Guidance

When users walk away from an open machine with access to critical system components or cardholder data, that machine may be used by others in the user’s absence, resulting in unauthorized account access and/or misuse.

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

Requirement 8.2

In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:

  • 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.

Testing Procedure

8.2
To verify that users are authenticated using unique ID and additional authentication (for example, a password/phrase) for access to the cardholder data environment, perform the following:

  • Examine documentation describing the authentication method(s) used.
  • For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).

Guidance

These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used). Note that a digital certificate is a valid option for “something you have” as long as it is unique for a particular user.

Since one of the first steps a malicious individual will take to compromise a system is to exploit weak or nonexistent passwords, it is important to implement good processes for authentication management.

Requirement 8.2.1

Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.

Testing Procedure

8.2.1.a
Examine vendor documentation and system configuration settings to verify that passwords are protected with strong cryptography during transmission and storage.

8.2.1.b
For a sample of system components, examine password files to verify that passwords are unreadable during storage.

8.2.1.c
For a sample of system components, examine data transmissions to verify that passwords are unreadable during transmission.

8.2.1.d
Additional testing procedure for service provider assessments only:
Observe password files to verify that non-consumer customer passwords are unreadable during storage.

8.2.1.e
Additional testing procedure for service provider assessments only:
Observe data transmissions to verify that non-consumer customer passwords are unreadable during transmission.

Guidance

Many network devices and applications transmit unencrypted, readable passwords across the network and/or store passwords without encryption. A malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer,” or directly access unencrypted passwords in files where they are stored, and use this data to gain unauthorized access.

Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures that only apply if the entity being assessed is a service provider.

Requirement 8.2.2

Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys.

Testing Procedure

8.2.2
Examine authentication procedures for modifying authentication credentials and observe security personnel to verify that, if a user requests a reset of an authentication credential by phone, e-mail, web, or other non-face-to-face method, the user’s identity is verified before the authentication credential is modified.

Guidance

Many malicious individuals use "social engineering”—for example, calling a help desk and acting as a legitimate user—to have a password changed so they can utilize a user ID. Consider use of a “secret question” that only the proper user can answer to help administrators identify the user prior to re-setting or modifying authentication credentials.

Requirement 8.2.3

Passwords/phrases must meet the following:

  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters.

Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.

Testing Procedure

8.2.3.a
For a sample of system components, inspect system configuration settings to verify that user password parameters are set to require at least the following strength/complexity:

  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters.

8.2.3.b
Additional testing procedure for service provider assessments only:
Review internal processes and customer/user documentation to verify that non-consumer customer passwords are required to meet at least the following strength/complexity:

  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters.

Guidance

Strong passwords/phrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non-existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.

This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/phrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. NIST SP 800-63-1 defines “entropy” as “a measure of the difficulty of guessing or determining a password or key.” This document and others that discuss “password entropy” can be referred to for more information on applicable entropy value and for understanding equivalent password strength variability for passwords/phrases of different formats.

Note: Testing Procedure 8.2.3.b is an additional procedure that only applies if the entity being assessed is a service provider.

Requirement 8.2.4

Change user passwords/passphrases at least once every 90 days.

Testing Procedure

8.2.4.a
For a sample of system components, inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least once every 90 days.

8.2.4.b
Additional testing procedure for service provider assessments only:
Review internal processes and customer/user documentation to verify that:

  • Non-consumer customer user passwords are required to change periodically; and
  • Non-consumer customer users are given guidance as to when, and under what circumstances, passwords must change.

Guidance

Passwords/phrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.

Note: Testing Procedure 8.2.4.b is an additional procedure that only applies if the entity being assessed is a service provider.

Requirement 8.2.5

Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.

Testing Procedure

8.2.5.a
For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be the same as the four previously used passwords.

8.2.5.b
Additional testing procedure for service provider assessments only:
Review internal processes and customer/user documentation to verify that new non-consumer customer user passwords cannot be the same as the previous four passwords.

Guidance

If password history isn’t 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 of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future.

Note: Testing Procedure 8.2.5.b is an additional procedure that only applies if the entity being assessed is a service provider.

Requirement 8.2.6

Set passwords/phrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.

Testing Procedure

8.2.6
Examine password procedures and observe security personnel to verify that first-time passwords for new users, and reset passwords for existing users, are set to a unique value for each user and changed after first use.

Guidance

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

Requirement 8.3

Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).

Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication.

Testing Procedure

8.3.a
Examine system configurations for remote access servers and systems to verify two-factor authentication is required for:

  • All remote access by personnel
  • All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).

8.3.b
Observe a sample of personnel (for example, users and administrators) connecting remotely to the network and verify that at least two of the three authentication methods are used.

Guidance

Two-factor authentication requires two forms of authentication for higher-risk accesses, such as those originating from outside the network.

This requirement is intended to apply to all personnel—including general users, administrators, and vendors (for support or maintenance) with remote access to the network—where that remote access could lead to access to the cardholder data environment.

If remote access is to an entity’s network that has appropriate segmentation, such that remote users cannot access or impact the cardholder data environment, two-factor authentication for remote access to that network would not be required. However, two-factor authentication is required for any remote access to networks with access to the cardholder data environment, and is recommended for all remote access to the entity’s networks.

Requirement 8.4

Document and communicate authentication policies and procedures to all users including:

  • Guidance on selecting strong authentication credentials
  • Guidance for how users should protect their authentication credentials
  • Instructions not to reuse previously used passwords
  • Instructions to change passwords if there is any suspicion the password could be compromised.

Testing Procedure

8.4.a
Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users.

8.4.b
Review authentication policies and procedures that are distributed to users and verify they include:

  • Guidance on selecting strong authentication credentials
  • Guidance for how users should protect their authentication credentials.
  • Instructions for users not to reuse previously used passwords
  • Instructions to change passwords if there is any suspicion the password could be compromised.

8.4.c
Interview a sample of users to verify that they are familiar with authentication policies and procedures.

Guidance

Communicating password/authentication policies and procedures to all users helps those users understand and abide by the policies.

For example, guidance on selecting strong passwords may include suggestions to help personnel select hard-to-guess passwords that don’t contain dictionary words, and that don’t contain information about the user (such as the user ID, names of family members, date of birth, etc.). Guidance for protecting authentication credentials may include not writing down passwords or saving them in insecure files, and being alert for malicious individuals who may attempt to exploit their passwords (for example, by calling an employee and asking for their password so the caller can “troubleshoot a problem”).

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.

Requirement 8.5

Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:

  • Generic user IDs are disabled or removed.
  • Shared user IDs do not exist for system administration and other critical functions.
  • Shared and generic user IDs are not used to administer any system components.

Testing Procedure

8.5.a
For a sample of system components, examine user ID lists to verify the following:

  • Generic user IDs are disabled or removed.
  • Shared user IDs for system administration activities and other critical functions do not exist.
  • Shared and generic user IDs are not used to administer any system components.

8.5.b
Examine authentication policies and procedures to verify that use of group and shared IDs and/or passwords or other authentication methods are explicitly prohibited.

8.5.c
Interview system administrators to verify that group and shared IDs and/or passwords or other authentication methods are not distributed, even if requested.

Guidance

If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. This in turn prevents an entity from assigning accountability for, or having effective logging of, an individual’s actions, since a given action could have been performed by anyone in the group that has knowledge of the authentication credentials.

Requirement 8.5.1

Additional requirement for service providers only:
Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

Note: Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a requirement.

Testing Procedure

8.5.1
Additional testing procedure for service provider assessments only:
Examine authentication policies and procedures and interview personnel to verify that different authentication credentials are used for access to each customer.

Guidance

Note: This requirement applies only when the entity being assessed is a service provider.

To prevent the compromise of multiple customers through the use of a single set of credentials, vendors with remote access accounts to customer environments should use a different authentication credential for each customer.

Technologies, such as two-factor mechanisms, that provide a unique credential for each connection (for example, via a single-use password) could also meet the intent of this requirement.

Requirement 8.6

Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:

  • Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
  • Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

Testing Procedure

8.6.a
Examine authentication policies and procedures to verify that procedures for using authentication mechanisms such as physical security tokens, smart cards, and certificates are defined and include:

  • Authentication mechanisms are assigned to an individual account and not shared among multiple accounts.
  • Physical and/or logical controls are defined to ensure only the intended account can use that mechanism to gain access.

8.6.b
Interview security personnel to verify authentication mechanisms are assigned to an account and not shared among multiple accounts.

8.6.c
Examine system configuration settings and/or physical controls, as applicable, to verify that controls are implemented to ensure only the intended account can use that mechanism to gain access.

Guidance

If user authentication mechanisms such as tokens, smart cards, and certificates can be used by multiple accounts, it may be impossible to identify the individual using the authentication mechanism. Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely identify the user of the account will prevent unauthorized users from gaining access through use of a shared authentication mechanism.

Requirement 8.7

All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

  • All user access to, user queries of, and user actions on databases are through programmatic methods.
  • Only database administrators have the ability to directly access or query databases.
  • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

Testing Procedure

8.7.a
Review database and application configuration settings and verify that all users are authenticated prior to access.

8.7.b
Examine database and application configuration settings to verify that all user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures).

8.7.c
Examine database access control settings and database application configuration settings to verify that user direct access to or queries of databases are restricted to database administrators.

8.7.d
Examine database access control settings, database application configuration settings, and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes).

Guidance

Without user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except for DBAs, who may need direct access to the database for their administrative duties).

Requirement 8.8

Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.

Testing Procedure

8.8
Examine documentation and interview personnel to verify that security policies and operational procedures for identification and authentication are:

  • Documented,
  • In use, and
  • Known to all affected parties.

Guidance

Personnel need to be aware of and following security policies and operational procedures for managing identification and authorization on a continuous basis.

Goal: Implement Strong Access Control Measures

Requirement 8.0

Identify and authenticate access to system components

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.

The effectiveness of a password is largely determined by the design and implementation of the authentication system—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance).

However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).