The PCI-SSC released the PCI DSS 4.0 standard on March 31, 2022. After March 31, 2024, the new standard—which contains several of the earlier restrictions as well as 11 new controls—will be mandated. Several of these are related to controlling machine identities and managing keys and certificates.
The new PCI DSS 4.0 standard underscores the vital role that machine identities play in securing data, keeping communications safe and private, and establishing trust between communicating parties. In fact, PCI DSS 4.0 mandates stronger authentication requirements for payment and control access logins. These requirements reflect the core certificate and key management best practices shown in publications such as NIST SP 1800-16.
While businesses may have a variety of reasons for not meeting the compliance requirements pertaining to keys and certificates, it certainly isn’t because the dangers have subsided. In fact, they’re on the rise. In response to these growing threats, the PCI DSS has also introduced best practices for governing the security and management of keys and certificates.
What is PCI DSS and PCI Compliance?
Enterprises that store, process, or transfer payment card data are required to secure cardholder data under the Payment Card Industry Data Security Standard (PCI DSS). This set of rules and requirements is designed to protect sensitive cardholder data credit and transactions and facilitates the broad adoption of consistent data security measures.
PCI DSS 4.0 Best Practices
In addition to 11 new controls, PCI DSS 4.0 outlines approximately 47 "Best Practices,” or new and updated controls, that are required to be in place by March 31, 2025.
It is important to note that all PCI DSS v3.2.1 requirements will remain active until v3.2.1 is retired, on March 31st, 2024.
Why Do You Need a Control Plane for Machine Identities?
Major reasons (via Dark Reading) for the changes in the new standard:
- Promote security as a continuous process
- Enhance validation methods and procedures
- Add flexibility and support of additional methodologies to achieve security
“Introducing the customized implementation approach to PCI DSS 4.0 gives businesses more flexibility,” as pointed out by Dark Reading. “Organizations are no longer forced to follow the methods prescribed by the standard or implement a burdensome compensating control…Effective IAM and MFA combined with encryption is the overarching principle behind zero-trust security for protecting sensitive cardholder data and online payments.”
Figure 1: PCI DSS 4.0 Implementation Timeline. Source: PCI Security Standards Council / Dark Reading
PCI DSS 4.0 requirements and priorities for compliance
Organizations will need to complete several tasks ahead of implementing new controls. This will require a focus on analysis, documentation, and meetings with stakeholders to obtain necessary information and update policies, standards, procedures, and supplemental information required by the PCI DSS 4.0 standard.
Controls identified as best practices are all relatively new or clarify updates to prior controls. Organizations will need to prioritize the implementation of these controls based on the business needs and risk environment. However, any prioritization plan should not omit any of the following requirements:
- Requirements 8.4.2 and 8.5.1: Multi-Factor Authentication (MFA) required for all access to the cardholder data environment (CDE)
- Requirements 3.5.1.1 and 3.5.1.2: Hashing and disk encryption
- Requirement 11.3.1.1: Authenticated scanning
- Requirement 12.3.1: Targeted risk analysis
- Requirement 6.4.2: Web Application Firewall (WAF) implementation
- Requirement 6.3.2: Software component management
- Requirements 6.4.3 and 11.6.1: Ensure payment page integrity
- Requirement 12.3.3: Cryptographic cipher management
- Requirement 5.4.1: Automated phishing prevention
- Requirement 7.2.4: Access control review
- Requirements 12.6.2, 12.6.3.1, and 12.6.3.2: Security awareness training
PCI DSS 4.0 requirements include key and certificate management and validation as a top priority
When transmitting cardholder information over open networks, strong cryptography and security protocols must be implemented to safeguard the Primary Account Number (PAN). PAN refers to the unique payment card number that identifies the issuer and the cardholder account. “Open and public” refers not only to the Internet but also wireless technologies such as Wi-Fi, Bluetooth, cellular, and satellite communications.
However, data encryption is only as strong as the underlying key and certificate management processes. PCI DSS 4.0 focuses on effectively managing and validating cryptographic keys and certificates. More specifically:
PCI DSS 4.0 Requirement 4.2.1
Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked.
Strong cryptography and security protocols should be implemented as follows to safeguard PAN during transmission over open, public networks:
- Only trusted keys and certificates are accepted.
- Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked.
- The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
- The encryption strength is appropriate for the encryption methodology in use.
PCI DSS 4.0 Requirement 4.2.1.1
An inventory of the entity’s trusted keys and certificates is maintained.
This new requirement mandates keeping an inventory of trusted keys and certificates used to protect PAN during transmission and that the inventory of trusted keys and certificates is examined to verify it is kept up to date.
“The inventory of trusted keys helps the entity keep track of the algorithms, protocols, key strength, key custodians, and key expiry dates. This enables the entity to respond quickly to vulnerabilities discovered in encryption software, certificates, and cryptographic algorithms,” according to the guidance in 4.2.1.1.
PCI DSS 4.0 Requirement 12.3.3
Cryptographic cipher suites and protocols in use are documented and reviewed.
Organizations should document and review cryptographic cipher suites and protocols once a year in the following ways:
- Maintain a current inventory of all cryptographic cipher suites and protocols that you are using, where you are using them and for what purpose.
- Actively track market trends to validate that the cryptographic cipher suites you are using continue to be viable.
- Document a response plan for remediating new or emerging cryptographic vulnerabilities.
Automation is important when managing certificate lifecycles and machine identities
Certificates are not a “fire and forget” solution. Once a certificate is installed, it must be continuously monitored for security issues breaking its validity, renewed when it expires, and replaced with a new one when necessary. Using manual processes to manage the certificate lifecycle is an error-prone, unreliable, and time-consuming approach, especially if we consider the thousands of certificates an organization might need to handle on a regular basis.
Businesses can avoid certificate management problems and ensure compliance with PCI DSS 4.0 by establishing centralized, well-structured certificate lifecycle management processes. These processes should be automated to remove the margin of error and implement a security infrastructure to handle your encryption needs.
Organizations should ensure that they adhere to the PCI DSS recommendations. Better safe than sorry—it takes just one untracked certificate to break an otherwise solid machine identity security program. Preventing certificate outages is a lot simpler than dealing with their impact afterward.
The Venafi TLS Protect solution can help discover all your TLS certificates and corresponding private keys so you can protect these machine identities across your infrastructure. By automating the replacement of expiring certificates, you can eliminate outages and quickly respond to vulnerabilities, CA compromise, or other errors.
(This post has been updated. It was originally published on September 27, 2022.)