The latest version of the PCI Data Security Standard (PCI DSS) v4.0 was released by the PCI Security Standards Council (PCI SSC) on March 31, 2022. In order to protect account data, PCI DSS defines a baseline of technological and operational criteria. To better address new threats and technologies, PCI DSS v4.0 supersedes PCI DSS v3.2.1 and offers creative solutions to counter new threats. The PCI DSS standard has undergone numerous updates as a result of feedback from the international payments sector. The objective is to maintain the standard’s applicability in the intricate and dynamic context of payment security.
The PCI DSS v4.0 standard was created on a zero-trust premise, enabling businesses to design unique, pluggable authentication solutions to meet the legal requirements for data security. Another instance is how the current version re-focuses on certain elements of component-level design, such as software security.
Important improvements to the user and system access authorization and authentication across an environment are also included in PCI DSS v4.0. The guiding premise of zero-trust security is to protect sensitive cardholder data and safeguard online payments by combining effective Identity and Access Management (IAM) and Multi-factor Authentication (MFA) with encryption. The foundation of PCI DSS v4.0 is the “zero trust” strategy, a cybersecurity approach that many organizations are implementing today.
What is new in PCI DSS v4.0?
The NIST recommendations on digital identities for authentication and lifecycle management are aligned with PCI DSS 4.0. Stronger authentication requirements for payment and control access logins are essential as the payments sector has rapidly migrated to the cloud.
The 12 fundamental PCI DSS requirements, which remain the cornerstone for protecting payment card data, have not changed significantly with PCI DSS v4.0. To guide the implementation of security measures, the requirements have been modified to place more emphasis on security objectives.
The main objectives for PCI DSS v4.0 are:
- Ensure that the standard remains compliant with the payment industry’s requirements for security.
- Increase adaptability and support for alternative security approaches.
- Promote the idea of security as an ongoing activity.
- Improve validation processes and methods.
Although PCI DSS v4.0 maintains the current prescriptive way of compliance, it also adds a new alternative method: customized validation. In order to generate documentation and risk assessment data for a Qualified Security Assessor (QSA) to review, this new validation approach will most likely require the business to perform additional initial assessment work. The business will then need to agree to specialized testing protocols developed by the QSA.
The tailored strategy won’t work for everyone and is best suited for businesses with established security and risk assessment procedures. The major benefit of having developed a more long-term solution for compliance validation of specialized security controls is that it will be more reliable. In prior iterations of the standard, compensating measures were considered “temporary,” and you had to provide documentation to support the control’s necessity by citing a business or technological restriction.
As PCI Council stated, “Unlike compensating controls, customized validation will not require a business or technical justification for meeting the requirements using alternative methods, as the requirements will now be outcome-based.”
Transition Timeline of PCI DSS v4.0
PCI DSS v3.2.1 will be in effect for another two years, until March 2024, according to the PCI SSC’s release of version 4.0 at the end of March 2022. And the transitional phase leading up to the full implementation of PCI DSS v4.0 in March 2025 has already commenced!
Organizations will have time during the transition period, which runs from 2022 to 2024, to familiarize themselves with the new version, update their reporting systems, and plan and put into action adjustments necessary to comply with the enhanced requirements. In the middle of 2022, training for Qualified Security Assessors (QSAs) and Internal Security Assessors (ISAs) to conduct PCI DSS v4.0 exams was held. Practitioners of PCI audits are currently collaborating with enterprises to create a transition strategy for compliance.
The 2023 CISO’s Guide to Certificate Lifecycle Management (CLM)
Important Cryptographic Requirements for PCI DSS v4.0 Compliance
Requirement 4.2.1/4.2.1.1: Key and Certificate Management and Validation– An inventory of trusted keys and certificates must be kept up to date according to PCI DSS v4.0. Strong encryption is specifically related to this one. You need to carefully document, track, and inventory the SSL /TLS certificates that are used for the transmission of sensitive data across public networks. Increased tracking will help ensure the certificates’ continued strength and validity. Keys and certificates will require documentation and knowledge management, similar to current requirements for change control. To meet this criterion, a repeatable procedure for issuing, maintaining, and storing cryptographic keys and certificates should be documented. Strong cryptography and security procedures must be implemented to protect private account numbers (PAN) when it is transmitted across open, public networks. Only trusted certificates and keys are recognized.
Requirement 4.2.1: Certificates being used to protect PAN while it is being transmitted over open, public networks must be confirmed as valid and not expired or revoked. Until March 31, 2025, this bulletin is a best practice, but starting April 1, 2025, it will be mandated as part of Requirement 4.2.1 and must be carefully taken into account when a PCI DSS assessment is conducted. This requirement also specifies:
- The protocols in use do not allow for fallback to, or usage of, insecure versions, algorithms, key sizes, or implementations.
- It only supports secure versions or configurations.
- The encryption strength is suitable for the employed encryption technique.
Requirement 4.2.1.1: Organizations must keep an inventory of their current keys and certificates in order to comply with Requirement 4.2.1.1, and track all certificates and keys used to protect data over open public networks, confirm their validity, and have procedures in place to check certificates for expiration or revocation. The maximum validity period for certificates that are publicly trusted by browsers is now 13 months, so certificates must be renewed annually in order to be trusted. Companies will need to add code to their custom applications that will break the connection if a presumably PCI-compliant partner or processor presents an untrusted certificate.
Requirement 3.5.1.1/3.5.1.2: Hashing and Disk Encryption– All hashing methods must be updated to use the key specified by Requirement 3.5.1.1. The mandates include:
- Businesses that now employ SHA256 will need to upgrade their internal code to use HMAC SHA256 (or something similar) with a key size of 128 bits or higher.
- The key lifecycle management controls outlined in requirements 3.6 and 3.7 will also apply to every key that is used.
- Organizations will need to coordinate this modification with a procedure to update all of the current data in their data storage in addition to upgrading all internal code that uses hashing.
Full Disk Encryption (FDE) will aid in data protection in the event of physical loss of a disk, according to PCI DSS Requirement 3.5.1.2. The goal of this requirement is to establish a barrier so that the decrypted data set will not instantly grant access to anyone in case the user’s authentication credentials are compromised. The mandates include:
- Technologies for full disk encryption can be used with portable devices that store cardholder data.
- The keys used to unlock the drive and access the operating system must be separate.
- Companies that use disk encryption to store and/or share files must use file-level encryption to safeguard their data.
Requirement 8.4.2/8.5.1: Need for MFA to access all CDE– Multi-Factor Authentication (MFA) is a requirement of PCI DSS v4.0 for any access to cardholder data environment (CDE). The goal of MFA is to boost the level of confidence in a user’s identification when they access a resource. This implies that in order to access CDE:
- All users must first authenticate via MFA.
- Enterprises must ensure that with single-factor authentication (SFA) access to the CDE is restricted.
- MFA employs a multi-layered approach to authentication that mandates a user to successfully validate at least two out of three authentication factors in order to access a resource.
- All remote network access from outside the entity’s network that might access or have an influence on the CDE must have MFA enabled.
Remote network access applications include Secure Shell (SSH), Remote Desktop Protocol (RDP), Virtual Desktop Infrastructure (VDI), and Virtual Private Network (VPN). Users, even administrative personnel, are prohibited from circumventing MFA systems unless a special exemption has been documented and approved by management for a limited period of time.
2023 EMA Report: SSL/TLS Certificate Security-Management and Expiration Challenges
Requirement 12.3.3: Cryptographic Cipher Management– As per this new requirement, you have to document and review cryptographic cipher suites and protocols once a year. Up until March 31, 2025, this criterion is a best practice. The following cryptographic cipher suites and protocols are to be considered:
- A current list of all cryptographic cipher suites and protocols in existence, along with information about their use cases and locations.
- Actively tracking market trends to ensure that all currently used cryptographic cipher suites and protocols remain viable.
- A plan for dealing with any modifications in cryptographic vulnerabilities.
Finding out which cipher suites and protocols are in use throughout the enterprise will require many firms to reverse engineer numerous application implementations. This requirement is applicable to security and management tools in addition to applications, as they might not be able to clearly indicate which cipher suites are being used. TLS 1.2 and 1.3 include the ability to employ a number of (up to 40+) cipher suites, many of which are out-of-date and shouldn’t be used, even though they are correctly implemented.
Requirement 3.6.1.1: Cryptographic Architecture (Service Providers only)–This requirement focuses exclusively on the adoption of cryptographic techniques for storing cardholder information and primary account numbers (PANs). Important elements of account data protection include encryption, truncation, masking, and hashing. Even if a hacker manages to get through other security measures and obtain encrypted account data, the hacker cannot use the data because it is unusable without the right cryptographic keys.
As potential prospects for risk minimization, additional efficient techniques of protecting stored data must also be taken into account. To avoid the usage of duplicate cryptographic keys across environments, service providers must now provide a documented description of the cryptographic architecture for production and test environments. Cryptographic keys have a higher chance of being intercepted and decoded in test environments since they may be less secure than production ones. This requirement will aid in reducing that.
How AppViewX Can Help You Move Forward with PCI DSS v4.0
AppViewX CERT+, a centralized certificate lifecycle management solution, automates discovery and manages certificates, keys, IoT security, device identities, and SSH access management across multi-cloud environments. The solution enables zero trust with an identity-first security approach, making the entire system more flexible, adaptable, efficient, and agile. AppViewX CERT+ together with its PKI-as-a-service solution, AppViewX PKI+, provides a comprehensive approach for enterprises to scale their public key infrastructure for users, applications, and machines and establish enterprise-wide crypto standards.
AppViewX PKI+, which is a turnkey, scalable, and compliant PKI-as-a-Service, allows you to simplify and centralize your private PKI architecture and set up tailored custom CAs in minutes while meeting the highest standards of security and compliance.
AppViewX CERT+ is a ready-to-consume, scalable, and efficient certificate lifecycle management (CLM) solution to effectively automate and manage machine and application identities as an integral part of your cybersecurity strategy. With AppViewX CERT+, you can scan and discover all certificates across hybrid multi-cloud infrastructures and reduce the risk of unmanaged, rogue, and non-compliant certificates, and ensure compliance with internal policies as well as industry and regulatory mandates, such as PCI DSS.
The essential CERT+ features for meeting PCI DSS certificate management requirements include:
Discovery & Inventory: AppViewX CERT+ enables on-demand and scheduled discovery of certificates from servers, clients, and ADC devices through a variety of modes, such as IPs, subnets, URLs, and managed device (ADC) logins. The discovered certificates are then automatically inventoried with the required information included. This central inventory provides insights into certificate expiry timelines as well as crypto standards (e.g. cipher strength, key size, TLS protocol version, etc.) being used for PKI. Having this insight readily available in a consolidated inventory helps organizations renew certificates on time and avoid application outages as well as regularly monitor crypto standards to prevent security weaknesses.
Policy Enforcement: AppViewX CERT+ allows administrators to define and enforce enterprise-wide cryptographic policies and protocols for keys and certificates, including enforcing strong cipher strengths, which is a best practice and a requirement for PCI DSS v4.0 compliance. These policies help enhance and strengthen the overall security posture of an organization. Other policies (e.g. what type of certificate should be issued from which CA) help teams adhere to the security strategies laid out by the organization. Additionally, all important activities related to the certificate lifecycle or configuration changes are logged. These logs can be transported into enterprise log storage systems for long-term storage as per enterprise policies.
Crypto-agility and Automation: As stated in Requirement 12.3.3, it is important to determine which cipher suites are used and where, and ensure that strong cipher mechanisms are in place. With AppViewX CERT+, changing or upgrading crypto standards can be streamlined through configuring new certificate policies and then automating the reissue/ renewal and re-provisioning of the certificate. CERT+ can automate end-to-end – generating a new certificate signing request (CSR), submitting CSR to CA, getting a certificate from CA, and provisioning the certificate in the application. These powerful automation capabilities promote crypto-agility and prevent time-consuming coordination between teams, and error-prone manual processes.
Reporting & Auditing: To help meet the crucial requirement for Key and Certificate Management and Validation (Requirement 4.2.1/4.2.1.1), AppViewX CERT+ reporting allows you to easily audit certificate validity, configurations, and cryptographic versions, including the algorithms, key sizes, and implementations, for your entire certificate inventory, as shown in the screenshots below. Additionally, you can track and audit every single event related to a certificate’s lifecycle in audit logs to prevent unauthorized actions. To enhance reporting capabilities, the centralized dashboard helps you gain necessary insights like Certificate Expiry by Month, Certificate Expiry by Certificate Authority, Certificate Compliance, and more to manage your certificate infrastructure efficiently. This dashboard is dynamic and can be customized based on the data most important to you. The information on the dashboard can also be converted into reports and can be sent to anyone as frequently as you choose, automatically.
Access & Workflows: AppViewX CERT+ helps you administer policies – such as recommended CAs and workflows – consistently across the infrastructure to validate and eliminate non-compliant certificates. You can delegate access, design requester/approver workflows, and apply granular visibility to individual certificates or certificate groups to enable efficient management. Integration with external directory systems like AD, LDAP, and RADIUS makes it even easier to assign access to appropriate stakeholders, improving operational efficiency and cross-team collaboration.
Certificate Lifecycle Management: AppViewX CERT+ offers two inventory tracking modes – Manage and Monitor. Monitor mode allows you to view reports and receive alerts on the expiry status and validity of certificates. While in Manage mode, you can perform a variety of certificate lifecycle actions, such as pushing, revoking, renewing, and more, in addition to the alerting and reporting capabilities of the Monitor mode. The automated solution can also represent necessary certificate-related information graphically, in one holistic view. This view provides you with the certificate’s chain of trust and all connected devices with intuitive single-click actions that trigger all lifecycle automation workflows (like renewing and pushing).
Conclusion
PCI DSS v4.0 stipulates the need for strong cryptography and security protocols, which ties back to efficient certificate lifecycle management. To ensure your organization maintains compliance and avoids security risks, it is important to streamline and standardize your certificate lifecycle management practices. Talk to an expert today to learn how AppViewX CERT+ can help you automate your certificate lifecycle management, maintain PCI DSS compliance, and strengthen your security posture.