by
Bookmark

Timeline for PCI DSS 4.0: The Eighth Requirement and Strong Authentication

Moving through the requirements of PCI DSS 4.0, we’re well over halfway through. During this journey, we’ve touched on cryptography, security and perimeter management, network security, authorization, and other critical security considerations. Now, we come up against the authentication and identity management problem with the eighth requirement. 

Authentication isn’t simply about passwords and CAPTCHAs, however. Regarding payment processing and protecting cardholder data, retailers and processors are expected to implement strong and effective authentication at the point of purchase and in any system that holds PAN information. 

 

What Is PCI DSS 4.0 Authentication?

Under PCI DSS 4.0, authentication is defined as a process with two principles–first, that the organization can establish and protect identities for individuals or processes (such as applications) within their system, and second, that they have reliable mechanisms by which that user or process can prove their identity. 

For anyone familiar with authentication (and that should be all of us), a few recognizable components and mechanisms play a role in the authentication. Some of these include:

  • Digital Identity Management: Authentication requires the existence of digital identities. The cornerstone of properly authenticating a user to access a system is that they have an identity within that system, including necessary information for business operations and verification.
  • Credentials: Each digital identity will have a set of associated credentials that the system will compare against user-provided credentials for authentication. This includes credentials related to any relevant authentication methods used by the system, including usernames, passwords, PINs, biometric templates, and others. Additionally, the system can include a secure way of generating One-Time Passwords (OTPs) for multifactor authentication.
  • Multi-Factor Authentication (MFA): Speaking of MFA… most security frameworks and regulations now require that organizations implement two or more forms of authentication to provide extra protection against common brute-force or phishing attacks. Proper MFA must use two or more forms of authentication, each derived from a different category (ownership, knowledge, inherence, location, etc.). 

 

What Are the Different Factors of Multi-Factor Authentication?

The eighth requirement of PCI DSS 4.0 will repeatedly refer to the implementation of MFA as a necessity for compliance under certain circumstances. An effective authentication solution must include at least two forms of credentials that span two distinct “factors.” These factors include:

  • Knowledge: What you know–usernames, passwords, PINs, etc.
  • Possession: What you own–SMS accounts, email accounts, authentication apps.
  • Inherence: What you are–biometrics like fingerprints, iris scans, and facial recognition.
  • Location: Where you are–typically geolocation information from a device.

What Is the Eighth Requirement for PCI DSS 4.0?

pci dss 4.0

The eighth requirement focuses on proper authentication for systems containing primary account numbers (PAN) and other sensitive cardholder information. Across the different subsections of the requirement, common themes and practices will include:

  • Establishing unique identities.
  • Implementing appropriate authentication measures.
  • Monitoring authentication and changes to MFA across the system.

 

8.1 – Processes and Mechanisms for Identifying and Authenticating Users

  • Documentation: All authentication methods, technologies, and policies must be documented, and this documentation must remain current.
  • Roles and Responsibilities: Roles and requirements around authentication policies and strategies must be assigned, understood, and documented. 

 

8.2 – User Identification Administration 

  • Unique IDs: Each user ID in a system must be unique, and users are only allowed a single unique ID.
  • Shared Authentication Credentials: In instances where administrators see value in shared group credentials or generic accounts, they may only be used if those accounts are prevented from use outside exceptional circumstances, their use is time-limited, and there is a clear, documented, and approved business justification.
  • Unique ID Management: User IDs may only be added, deleted, or modified with explicit approval by administrators and only with the minimum required privileges. Furthermore, any user terminated from the organization immediately has their account revoked.
  • Inactive Accounts: Any account with 90 days of inactivity must be disabled.
  • Third-Party Accounts: Accounts used to provide access to vendors or partners must be time-limited, with their use monitored for unexpected activity.
  • Idle Sessions: User sessions idle for longer than 15 minutes must automatically require re-authentication before access is granted again.

 

8.3 – Strong Authentication

  • Strong Authentication: All access to system components (data, code, network resources) must be protected by at least one factor (knowledge, ownership, inherence).
  • Cryptography: Any data used as an authentication factor must be protected with strong encryption.
  • Modifying Authentication Factors: Authentication factors for a given account may not be modified without authentication by the user.
  • Login Limits: The system must automatically lock out a user after 10 failed authentication attempted for no less than 30 minutes.
  • Password Limits: When passwords are used, they must come from a set, unique value for first-time use, and the system must require an immediate reset once the user logs in for the first time. Passwords must also be a minimum of 12 characters in length and contain both numeric and alphabetic characters. Finally, users may not reset a password to the same value as any of the previous four passwords.
  • Single-Factor Exceptions: if passwords are the only factor used in authentication, the system must require a password reset every 90 days or implement real-time risk assessments to determine account security.
  • Physical Authentication: Any physical card, security token, or other devices used for authentication must be unique to a user and protected by measures to ensure only that user has access.

 

8.4 – Multi-Factor Authentication Is Implemented in CDEs

  • Administrative Access: Any non-console access to CDE resources by administrator accounts must be protected with MFA.
  • Remaining Access: All other CDE authentication, outside of access to automated applications or POS systems, must use MFA to access cardholder data.
  • Remote Access: All remote network connections must require MFA.

 

8.5 – Multi-Factor Authentication Systems Are Configured to Prevent Misuse

  • Defense Factors: The MFA system implemented must disallow any bypass of MFA authentication by any user, including at least two different authentication factors, and require the success of all factors before granting access. 

 

8.6 – Account and Authentication Use Are Strictly Managed

  • System and App Authentication: If a user seeks authentication for applications on the system (and not direct access to system resources), then the system must prevent interactive use, time-limit any allowed use, and require individual account authentication against a unique ID.
  • Code Security: No authentication credentials should be hard coded into application code or configuration files.
  • Password Security: Application passwords must be changed periodically, be sufficiently complex, and the complexity is related to the frequency of password resets.

 

Align Your Authentication Standards with PCI DSS 4.0 with Lazarus Alliance

Authentication is a critical part of every security function, and PCI DSS has some relatively common approaches to authentication. With the onset of PCI DSS 4.0, however, some changes have been intended to boost system security, namely the requirement of MFA for almost every system component containing cardholder data. 

As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now. 

 

Are You Thinking Ahead for PCI DSS 4.0?

Call Lazarus Alliance at 1-888-896-7580 or fill in this form.

[wpforms id=”137574″]