As a top cybersecurity provider in Sweden, we understand the evolving challenges that businesses face in securing payment card data. The release of PCI DSS 4.0 marks a significant shift in how organizations must approach security, particularly concerning APIs and user authentication. This article delves into the critical changes introduced by PCI DSS 4.0 and offers practical advice on how your organization can adapt to these new requirements.
New Requirements in PCI DSS 4.0: Key Updates for Securing Payment Data
In the latest PCI DSS 4.0, a series of new requirements have been introduced to enhance the security framework for entities handling payment card data. These updates, effective immediately, aim to reinforce roles, responsibilities, and technical controls across various aspects of payment data security. Here’s a breakdown of the most critical changes that organizations need to implement:
New Requirements of PCI DSS 4.0 for All Entities
The requirements and sub-requirements below are effective immediately for v4.0 assessments for all entities.
Requirement 1: Install and Maintain Network Security Controls
- 1.1.2 The roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.
Requirement 2: Apply Secure Configurations to All System Components
- 2.1.2 The roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.
Requirement 3: Protect Stored Account Data
- 3.1.2 The roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
- 4.1.2 The roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.
Requirement 5: Protect All Systems and Networks from Malicious Software
- 5.1.2 The roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood.
Requirement 6: Develop and Maintain Secure Systems and Software
- 6.1.2 The roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
- 7.1.2 The roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood.
Requirement 8: Identify Users and Authenticate Access to System Components
- 8.1.2 The roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.
- 8.3.4 Increased the number of invalid authentication attempts before locking out a user ID from six to ten attempts.
- 8.3.9 Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days.
Requirement 9: Restrict Physical Access to Cardholder Data
- 9.1.2 The roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.
- 9.2.4 New requirement. A sub-requirement has been added to an existing requirement to restrict access to consoles in sensitive areas via locking when not in use.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
- 10.1.2 The roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood.
Requirement 11: Test Security of Systems and Networks Regularly
- 11.1.2 The roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.
Requirement 12: Support Information Security with Organizational Policies and Programs
- 12.1.3 Added formal acknowledgment by personnel of their responsibilities.
- 12.3.2 New requirement for entities using a Customized Approach to perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach.
- 12.5.2 New requirement to document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment.
- 12.8.5 Clarified that the information about PCI DSS requirements managed by the TPSP and the entity should include any that are shared between the TPSP and the entity.
Future-Dated New Requirements for All Entities
The requirements and sub-requirements below will go into effect on March 31, 2025, for all entities. Until then, they are considered best practices.
Requirement 3: Protect Stored Account Data
- 3.1.3 New requirement to address former testing procedures that any storage of SAD by issuers is limited to that which is needed for a legitimate issuing business need and is secured.
- 3.2.1 A sub-requirement has been added to an existing requirement to address SAD stored prior to completion of authorization through the implementation of data retention and disposal policies, procedures, and processes.
- 3.3.2 New requirement to encrypt SAD that is stored electronically prior to completion of authorization.
- 3.4.2 New requirement for technical controls to prevent copying and/or relocation of PAN when using remote-access technologies. Expanded from former Requirement 12.3.10.
- 3.5.1.1 New requirement for keyed cryptographic hashes when hashing is used to render PAN unreadable.
- 3.5.1.2 New requirement that disk-level or partition-level encryption is used only to render PAN unreadable on removable electronic media or, if used on non-removable electronic media, the PAN is also rendered unreadable via a mechanism that meets Requirement 3.5.1.
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
- 4.2.1 New requirement. A sub-requirement has been added to an existing requirement to confirm certificates used for PAN transmissions over open, public networks are valid and not expired or revoked.
- 4.2.1.1 New requirement to maintain an inventory of trusted keys and certificates.
Requirement 5: Protect All Systems and Networks from Malicious Software
- 5.2.3.1 New requirement to define the frequency of periodic evaluations of system components not at risk for malware in the entity’s targeted risk analysis.
- 5.3.2.1 New requirement to define the frequency of periodic malware scans in the entity’s targeted risk analysis.
- 5.3.3 New requirement for a malware solution for removable electronic media.
- 5.4.1 New requirement to detect and protect personnel against phishing attacks.
Requirement 6: Develop and Maintain Secure Systems and Software
- 6.3.2 New requirement to maintain an inventory of bespoke and custom software.
- 6.4.2 New requirement to deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. This new requirement removes the option in Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment tools or methods.
- 6.4.3 New requirement for the management of all payment page scripts that are loaded and executed in the consumer’s browser.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
- 7.2.4 New requirement for review of all user accounts and related access privileges.
- 7.2.5 New requirement for assignment and management of all application and system accounts and related access privileges.
- 7.2.5.1 New requirement for review of all access by application and system accounts and related access privileges.
Requirement 8: Identify Users and Authenticate Access to System Components
- 8.3.6 New requirement to increase password length from a minimum length of seven characters to a minimum length of 12 characters (or if the system does not support 12 characters, a minimum length of eight characters). Clarified that until March 31, 2025, passwords must be a minimum length of at least seven characters in accordance with v3.2.1 Requirement 8.2.3. Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1. Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
- 8.4.2 New requirement to implement multi-factor authentication (MFA) for all access into the CDE.
- 8.5.1 New requirement for secure implementation of multi-factor authentication systems.
- 8.6.1 New requirement for the management of system or application accounts that can be used for interactive login.
- 8.6.2 New requirement for not hard-coding passwords/passphrases into files or scripts for any application and system accounts that can be used for interactive login.
- 8.6.3 New requirement for protecting passwords/passphrases for application and system accounts against misuse.
Requirement 9: Restrict Physical Access to Cardholder Data
- 9.5.1.2.1 New requirement to define the frequency of periodic POI device inspections based on the entity’s targeted risk analysis.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
- 10.4.1.1 New requirement for the use of automated mechanisms to perform audit log reviews.
- 10.4.2.1 New requirement for a targeted risk analysis to define the frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1).
- 10.7.2 New requirement for all entities to detect, alert, and promptly address failures of critical security control systems. This requirement applies to all entities – it includes two additional critical security controls not included in Requirement 10.7.1 for third-party service providers.
- 10.7.3 New requirement to respond promptly to failures of any critical security controls. For service providers: this is a current PCI DSS v3.2.1 requirement. For all other (non-service provider) entities: this is a new requirement.
Requirement 11: Test Security of Systems and Networks Regularly
- 11.3.1.1 New requirement to manage all other applicable vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans.
- 11.3.1.2 New requirement to perform internal vulnerability scans via authenticated scanning.
- 11.6.1 New requirement to deploy a change-and-tamper detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser.
Requirement 12: Support Information Security with Organizational Policies and Programs
- 12.3.1 New requirement to perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently it is performed.
- 12.3.3 New requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months.
- 12.3.4 New requirement to review hardware and software technologies in use at least once every 12 months.
- 12.6.2 New requirement to review and update (as needed) the security awareness program at least once every 12 months.
- 12.6.3.1 New requirement for security awareness training to include awareness of threats and vulnerabilities that could impact the security of the CDE.
- 12.6.3.2 New requirement for security awareness training to include awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1.
- 12.10.4.1 New requirement to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel.
- 12.10.5 Merged requirements and updated the security monitoring systems to be monitored and responded to as part of the incident response plan to include the following: Detection of unauthorized wireless access points (former 11.1.2). Change-detection mechanism for critical files (former 11.5.1). New requirement. A sub-requirement has been added to an existing requirement for use of a change- and tamper-detection mechanism for payment pages (relates to new requirement 11.6.1).
- 12.10.7 New requirement for incident response procedures to be in place and initiated upon detection of stored PAN anywhere it is not expected.
New Requirements for Service Providers Only
The requirements and sub-requirements below are effective immediately for v4.0 assessments for service providers only.
Requirement 12: Support Information Security with Organizational Policies and Programs
- 12.9.2 New requirement to support customers’ requests for information to meet Requirements 12.8.4 and 12.8.5.
Future-Dated New Requirements for Service Providers Only
The requirements and sub-requirements below will go into effect on March 31, 2025, for service providers only. Until then, they are considered best practices.
Requirement 3: Protect Stored Account Data
- 3.6.1.1 New requirement. A sub-requirement has been added to an existing requirement to maintain a documented description of the cryptographic architecture that includes prevention of the use of the same cryptographic keys in production and test environments.
Requirement 8: Identify Users and Authenticate Access to System Components
- 8.3.10.1 New requirement – if passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or access to resources is automatically determined by dynamically analyzing the security posture of the accounts.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
- 10.7.2 New requirement to detect, alert, and promptly address failures of critical security control systems. It will supersede Requirement 10.7.1 for service providers on March 31, 2025.
Requirement 11: Test Security of Systems and Networks Regularly
- 11.4.7 New requirement for multi-tenant service providers to support their customers for external penetration testing.
- 11.5.1.1 New requirement to use intrusion-detection and/or intrusion-prevention techniques to detect, alert on/prevent, and address covert malware communication channels.
Requirement 12: Support Information Security with Organizational Policies and Programs
- 12.5.2.1 New requirement for service providers to document and confirm PCI DSS scope at least once every six months and upon significant change to the in-scope environment.
- 12.5.3 New requirement for service providers for a documented review of the impact to PCI DSS scope and applicability of controls upon significant changes to organizational structure.
These updates in PCI DSS 4.0 are designed to strengthen the security of payment data, making it imperative for organizations to understand and implement these changes promptly. By staying informed and compliant, businesses can better protect their customers and reduce the risk of data breaches.
The Role of API Security in PCI DSS 4.0
In today’s interconnected digital environment, APIs are essential for enabling seamless communication between different software systems. However, this convenience comes with significant security risks. As organizations increasingly rely on APIs to transmit sensitive data, these interfaces have become prime targets for cyberattacks.
PCI DSS 4.0 has placed greater emphasis on securing APIs, recognizing their growing importance and vulnerability. The standard now requires more robust measures to protect APIs, including enhanced authentication protocols, continuous monitoring, and regular security testing. To comply with these new requirements, organizations need to implement a comprehensive API security strategy that includes:
- Strong Authentication: Ensure that all API endpoints are protected with strong multi-factor authentication (MFA). This reduces the risk of unauthorized access, even if credentials are compromised.
- Regular Security Testing: Conduct regular penetration tests and vulnerability assessments on your APIs. This proactive approach helps identify and mitigate vulnerabilities before they can be exploited by attackers.
- Continuous Monitoring: Implement real-time monitoring tools that can detect and respond to suspicious API activity. This enables your security team to react swiftly to potential threats, minimizing the risk of data breaches.
- Zero-Trust Architecture: Adopt a zero-trust approach to API security. This means assuming that no API request is trustworthy by default, regardless of its origin. By continuously verifying the identity and security posture of every request, you can significantly reduce the risk of unauthorized access.
By focusing on these key areas, your organization can better protect its APIs and ensure compliance with PCI DSS 4.0, safeguarding sensitive payment card data from potential threats.
Enhancing User Authentication and Access Control
One of the most notable changes in PCI DSS 4.0 is the update to Requirement 8, which deals with identifying and authenticating users accessing system components. The new standard introduces stricter requirements for multi-factor authentication (MFA), which now extends beyond administrative accounts to include all user accounts that have access to the cardholder data environment (CDE).
To align with these changes, businesses must take a more rigorous approach to user authentication and access control. Key actions include the following.
- Implementing Comprehensive MFA: Ensure that MFA is in place for all user accounts that interact with the CDE. This adds an additional layer of security, making it significantly harder for attackers to gain unauthorized access to sensitive data.
- Regular Access Reviews: Conduct periodic reviews of user access privileges to ensure that only authorized personnel have access to critical systems. This helps prevent privilege escalation and reduces the risk of insider threats.
- Strict User Account Management: Enforce strong password policies, regularly update authentication methods, and promptly revoke access for employees who no longer require it. This reduces the attack surface by limiting the number of accounts with access to sensitive data.
- Contextual Authentication: Consider implementing contextual or adaptive authentication measures that adjust security requirements based on the user’s behavior or location. For example, if a user attempts to access the system from an unusual location, they might be required to provide additional verification.
Conclusion: Adapting to the New Compliance Landscape
The introduction of PCI DSS 4.0 signals a broader shift towards more proactive and comprehensive security practices. While the new requirements may seem daunting, they represent an opportunity for organizations to strengthen their overall security posture and better protect sensitive payment data.
By focusing on robust API security, enhancing user authentication, and continuously monitoring for potential threats, businesses can not only achieve compliance with PCI DSS 4.0 but also build a more resilient security framework. As the threat landscape continues to evolve, staying ahead of these changes is crucial for safeguarding your organization against data breaches and maintaining customer trust.
At Nordic Defender, we are committed to helping businesses navigate these new challenges. Our team of experts is here to support you in implementing the necessary measures to meet PCI DSS 4.0 requirements and ensure that your organization remains secure in today’s dynamic digital environment.
For more information on how we can help you strengthen your security practices and achieve compliance, please contact us. Together, we can build a safer and more secure future for your business.