8.2: 1. All users are assigned a unique ID before access to system components or cardholder data is allowed.
  • Interview responsible personnel to verify that all users are assigned a unique ID for access to system components and cardholder data.
  • Examine audit logs and other evidence to verify that access to system components and cardholder data can be uniquely identified and associated with individuals.

Description

Purpose

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 IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: (a) ID use is prevented unless needed for an exceptional circumstance, (b) Use is limited to the time needed for the exceptional circumstance, (c) Business justification for use is documented, (d) Use is explicitly approved by management, (e) Individual user identity is confirmed before access to an account is granted, (f) Every action taken is attributable to an individual user.
  • Examine user account lists on system components and applicable documentation to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement.
  • Examine authentication policies and procedures to verify processes are defined for shared authentication credentials such that they are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement.
  • Interview system administrators to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement.

Description

Purpose

Group, shared, or generic (or default) IDs are typically delivered with software or operating systems—for example, root or with privileges associated with a specific function, such as an administrator.

If multiple users share the same authentication credentials (for example, user ID and password), it becomes impossible to trace system access and activities to an individual. In turn, this 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 with knowledge of the user ID and associated authentication factors.

The ability to associate individuals to the actions performed with an ID is essential to provide individual accountability and traceability regarding who performed an action, what action was performed, and when that action occurred.

Good Practice

If shared IDs are used for any reason, strong management controls need to be established to maintain individual accountability and traceability.#### Examples Tools and techniques can facilitate both management and security of these types of accounts and confirm individual user identity before access to an account is granted. Entities can consider password vaults or other system- managed controls such as the sudo command.

An example of an exceptional circumstance is where all other authentication methods have failed, and a shared ID is needed for emergency use or “break the glass” administrator access.

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.
  • Additional testing procedure for service provider assessments only: Examine authentication policies and procedures and interview personnel to verify that service providers with remote access to customer premises use unique authentication factors for remote access to each customer premises.

Description

Purpose

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.#### Examples Technologies such as multi-factor mechanisms that provide a unique credential for each connection (such as a single-use password) could also meet the intent of this requirement.

8.2: 4. Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: (a) Authorized with the appropriate approval, (b) Implemented with only the privileges specified on the documented approval.
  • Examine documented authorizations across various phases of the account lifecycle (additions, modifications, and deletions) and examine system settings to verify the activity has been managed in accordance with all elements specified in this requirement.

Description

Purpose

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 IDs are created or changed outside the normal change process or without corresponding authorization.

8.2: 5. Access for terminated users is immediately revoked.
  • Examine information sources for terminated users and review current user access lists—for both local and remote access—to verify that terminated user IDs have been deactivated or removed from the access lists.
  • Interview responsible personnel to verify that all physical authentication factors—such as, smart cards, tokens, etc.—have been returned or deactivated for terminated users.

Description

Purpose

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.
  • Examine user accounts and last logon information, and interview personnel to verify that any inactive user accounts are removed or disabled within 90 days of inactivity.

Description

Purpose

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.

Good Practice

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: (a) Enabled only during the time period needed and disabled when not in use, (b) Use is monitored for unexpected activity.
  • Interview personnel, examine documentation for managing accounts, and examine evidence to verify that accounts used by third parties for remote access are managed according to all elements specified in this requirement.

Description

Purpose

Allowing third parties to have 24/7 access into an entity’s systems and networks in case they need to provide support increases the chances of unauthorized access. This access could result in an unauthorized user in the third party’s environment or a malicious individual using the always-available external entry point into an entity’s network. Where third parties do need access 24/7, it should be documented, justified, monitored, and tied to specific service reasons.#### Good Practice 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.
  • Examine system configuration settings to verify that system/session idle timeout features for user sessions have been set to 15 minutes or less.

Description

Purpose

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

Good Practice

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.

Examples

One way to meet this requirement is to configure an automated screensaver to launch whenever the console is idle for 15 minutes and requiring the logged-in user to enter their password to unlock the screen.