PCI DSS Blog Series – Requirement 8

The Payment Card Industry Data Security Standard (PCI DSS) consists of nearly 400 individual controls, is a critical part of staying in business for any merchant, service provider, or subservice provider who is involved in handling cardholder data. We find that companies considering PCI are often caught off guard with how comprehensive the PCI DSS is. So, we thought we would help!

CompliancePoint’s PCI blog series will analyze each of the 12 requirement families. We will outline common challenges our customers face with each requirement, answer some frequently asked questions, and finally we will provide some pro tips on becoming PCI Certified.

This next entry of the PCI Series is Requirement 8: Identify and authenticate access to system components.

Requirement 8: Identify and authenticate access to system components

What does this requirement require at a high level?

PCI DSS Requirement 8 is all about assigning and managing individual user IDs and the necessary logical access controls to restrict access to an entity’s system components. This requirement enforces minimum password complexity settings and proper user credential handling procedures. Additionally, controls outline specifications for controlling remote access with the implementation of multi-factor authentication (MFA). Lastly, it is worth mentioning that the controls of this requirement not only apply to logical ones but also physical access credentials (i.e., don’t share your employee ID badge).

Why is compliance with this requirement important (beyond getting certified)?

To keep unauthorized people out of an information system, strong authentication methods need to be required for authorized users. While passwords are the most common form of authentication verification for personal and business uses, PCI DSS Requirement 8 also applies to other unique forms of user credentials.

Creating a user’s account with the appropriate access permissions is very important. However, it is equally important to manage accounts after they have been created. The HR and management teams must communicate with the IT/Security teams when a user’s access must be revoked. If an employee departs the organization their user IDs, logical access credentials, and physical access credentials must be disabled immediately. Whenever possible, physical access tokens like an employee ID badge should be physically retrieved in addition to being logically disabled.

Taking all these steps is good security hygiene and will assist in complying with various regulations and standards like the PCI DSS,.  

Common Challenges & Tips for Success:

1. Render authentication credentials unreadable
   • Authentication credentials such as passwords and passphrases must be protected when being used or stored. This is required not only authentication to/from public networks (i.e., remote access), but also internally within the organization’s private secured network.
   • Use methods that support strong cryptography for transmission of credentials such as HTTPS, RDP, and SSH v2.
   • Store passwords using a strong one-way cryptographically derived hash. For example, ensure local accounts on *nix hosts use SHA-512 hashes for storage of all passwords.  
2. Develop account reset and identity verification processes
   • As remote work increases, it is imperative that users can access the systems and applications they need to perform their duties. Just as important is to ensure users needing an account reset (i.e., forgot password after a long vacation) are the correct users.
   • Develop processes for users to verify their identity when they are not able to request a reset in-person/face-to-face.
   • Methods may include quizzing the remote user over topics they would know, such as information that may be on file for the employee like their street address. Other methods could include requesting the use of a second communication system the user should have access to like their phone number or email address.
3. Document and disseminate authentication procedures
   • It’s very important to provide the organization’s bare minimum requirements for authentication however, you should not stop there. The organization should provide instructions and examples for users to select a strong password/passphrase and guidance to protect them.
   • Provide examples of long passwords which can be easily remembered. An example could be a phrase like “dogs like to walk” combined into one word with numbers added, like “dogsliketowalk2” and then consider replacing a letter with a similar special character or additional numbers. The final result can look something like “dog$liket0w@lk2”
   • Users should be instructed to change passwords/passphrases if they suspect it has been compromised. Users should not reuse passwords from other accounts they may maintain in their personal life as well as those used for different systems or applications at work.
4. Restrict database access
   • Database Administrators (DBAs) should be the only individuals with direct access to query databases that store cardholder data.
   • Restrict non-DBA user access to an account that can only use a pre-determined list of stored procedures. These stored procedures will ensure the users can only perform the actions which are required for their job duties, which may involve read-only functions for reporting. This can prevent users from being able to perform write or delete functions.
   • Restrict access to database application IDs to just the intended application. DBAs and other processes should not be able to login to a database application’s ID. 

Common Questions:

1. How does this apply to third-party vendor accounts?
   • User IDs for third parties with remote access to the CDE will need to have additional controls implemented.
   • Third-party accounts must be disabled when not in use, which means they can only be enabled when needed.
   • The organization should be able to monitor the actions of a third-party account when being used. This is to make sure they only access the necessary systems and applications needed to perform their duties.
2. What’s the difference between non-console admin MFA requirements and remote access MFA requirements? Do remote admin users need two MFA prompts?
   • MFA is required for all user remote access into the CDE, regardless of if the user has administrative access or basic internal network access. (PCI DSS 8.3.2)
   • MFA is required for users with administrative access to the CDE (PCI DSS 3.2.1). This means that if the admin user is in one of the organization’s non-CDE networks and then needs to access a host in the CDE (such as SSH into a firewall or RDP to a server) then the user’s authentication flow must require MFA. The key difference between this and PCI Requirement 8.3.2 is that the user has admin privileges and is not “remote,” they may be in a regular non-CDE network of the organization.
   • While MFA is required for all user remote access and non-console admin access into the CDE this does not mean two separate MFA prompts are required if an admin user is working remotely. PCI is fine with one MFA prompt into the CDE (remote access) and will not require a second prompt once an admin user needs to directly non-console into a specific host.

Conclusion

The goal of the PCI DSS is to protect the networks and environments that store, process, or transmit cardholder data. To protect your information systems, it is important to ensure the appropriate access controls are in place and secure user ID and credential management practices are implemented. Manage user IDs by controlling additions and deletions in a very timely fashion, restrict access and actions for database accounts, and lastly implement an MFA solution for all remote access and as necessary for non-console administrative access.

Check Out Other Posts in this Series

• PCI DSS Requirement 1: Install and maintain a firewall configuration to protect cardholder data
• PCI DSS Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• PCI DSS Requirement 3: Protect stored cardholder data
• PCI DSS Requirement 4: Encrypt transmission of cardholder data across open, public networks
• PCI DSS Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
• PCI DSS Requirement 6: Develop and maintain secure systems and applications
• PCI DSS Requirement 7: Restrict access to cardholder data by business need to know
• PCI DSS Requirement 8: Identify and authenticate access to system components
• PCI DSS Requirement 9: Restrict physical access to cardholder data
• PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data
• PCI DSS Requirement 11: Regularly test security systems and processes
• PCI DSS Requirement 12: Maintain a policy that addresses information security for all personnel

CompliancePoint is a Qualified Security Assessor Company (QSAC). Our consultants have decades of experience as practitioners and auditors. Please reach out to us at connect@compliancepoint.com if you have any questions about this requirement or how CompliancePoint can assist your organization with preparing for your PCI DSS Certification.