Blog

PCI DSS 4.0 – Key Changes Affecting Merchants and Service Providers and How They Should Respond?

While PCI DSS 4.0 standards mandate any business that stores, processes, or transmits cardholder data to make substantial changes to their security controls and policies, merchants and service providers are also required to implement stringent controls, especially around authentication, reporting of security events and intrusion-detection systems, among others.
PCI DSS 4.0 - Key Changes Affecting Merchants and Service Provider

Whether it is an increased focus on targeted risk analysis, introducing compliance as a continuous process, an additional customized approach to validation, or enhancement of organizational maturity and governance, PCI DSS 4.0 has introduced multiple transformational changes to the payment ecosystem. While the new standards require any business that stores, processes, or transmits cardholder data to make substantial changes to their security controls and policies, merchants and third-party service providers are also required to implement stringent controls, especially around authentication, reporting of security events and intrusion-detection systems, among others.

In continuation of the series of opinion pieces that we have published on the changes in the PCI DSS 4.0 (Read our earlier blog on the all-new customized approach), this article highlights their significant impact on merchants and service providers. While the PCI DSS timeline provides sufficient time to transition to new standards, the following list of high-level changes aims to help entities devise strategies to start planning and implementing the required controls at the earliest.

1. Encryption Management

Stored sensitive authentication data (SAD) can be an easy source for hackers to generate forged payment cards and create fraudulent transactions. It is now mandatory for issuers and companies that support issuing services to limit the storage of SAD only to a legitimate business need. They are also required to use strong cryptography to protect it along with a documented description of the cryptographic architecture. It is important to note that entities must prevent the use of the same cryptographic keys in production and test environments to avoid the risk of exposing the key in a lesser secure environment.

Another change has been made to the methods that must be used to secure the stored primary account number (PAN). Disk-level encryption is no longer an appropriate mechanism to protect the PAN stored in devices, servers, and other systems due to its transparent decryption upon user authentication. While it can still be used for removable electronic media, it cannot be the only mechanism to protect PAN stored in non-removable electronic media. It is now mandatory to render PAN unreadable via any other method such as truncation or data-level encryption in such cases.

2. Identity and Access Management

Another significant change in the standards for all entities has been the implementation of Multi-Factor Authentication (MFA) for all access to cardholder data environment (CDE). MFA, which was earlier mandatory only for remote access to CDE, now applies to all types of system components including cloud, on-premises applications, hosted systems, network security devices, workstations as well as servers and endpoints. MFA implementation aims to reduce the chances of an attacker gaining unauthorized access to the system as multiple factors will need to be compromised to do so.

Additionally, if a service provider uses only single-factor authentication such as passwords or passphrases for customer user access, it must be changed at least every 90 days or the account’s security posture must be dynamically analyzed. Moreover, the requirement to periodically change passwords/passphrases used for any application and system accounts with special consideration to protect them has also been added to the new standards.

3. Penetration Testing and Vulnerability Management

Multi-tenant service providers are now required to support their customers’ requests to conduct external penetration testing to imitate attacker behavior and identify vulnerabilities. Earlier, the third-party service providers (TPSPs) refused to be included in client-initiated pen testing as they were concerned about affecting other customers’ systems. Now, as per the updated standards, they either need to provide evidence of the testing performed on the shared infrastructure or allow access to customers to perform penetration testing.

In addition to that, one evolved requirement also states that internal vulnerability scans must now be performed via authenticated scanning. Authenticated scans provide greater insight into the organization’s vulnerability landscape including patch levels, missing patches, insecure protocols, etc. As certain vulnerabilities can only be detected with authenticated scans, unauthenticated scans will no longer be sufficient.

The use of intrusion-detection or intrusion-prevention techniques by service providers to address the covert malware communication channels has also been mandated in PCI DSS 4.0. To block the lateral spread of malware inside the network to exfiltrate the data, entities must consider placing these controls at critical locations across the network.

4. Risk Assessment and Documentation

Keeping in mind the complexity of a service provider’s network, PCI DSS 4.0 mandates them to document and confirm the PCI DSS scope at least once every six months (instead of 12 months) and upon any significant changes to the in-scope environment. The requirement to document and report to executive management any impact on PCI DSS compliance due to organizational changes has also been added to the new standards.

Multi-tenant service providers are also required to protect and separate all customer environments and data. This means that a logical separation must be implemented such that the provider and customer cannot access each other’s environments without authorization. Moreover, multi-tenant service providers must also implement mechanisms to securely address and remediate any security incident or vulnerability reported by the customer.

Specific to the new approach to validation added in the standards, any entity that uses a customized approach to meet the requirements must perform a targeted risk analysis at least once every 12 months for each PCI DSS requirement. The updated standards also mandate the entities to get the approval of documented evidence by senior management.

Way Forward – Next Steps for PCI DSS 4.0

While most of the newly added requirements are stated as ‘best practice’ until March 2025, some of them must be implemented immediately to seek compliance with PCI DSS 4.0. However, entities must start planning for all these changes at the earliest. They must begin evaluating their budgets, resources, and personnel against all the requirements to develop a roadmap of activities to be performed throughout the given timeline.

As a starting point, organizations must start reading the new standards to understand the requirements correctly. The entities must then check if they are compliant with PCI DSS 3.2.1 and conduct a gap analysis to understand the organizational requirements to comply with the latest standards. This will also help them determine the security controls to be set up and the structural changes that might be required for business processes, infrastructure, and required training. As per the new standards, the organizations must also stay prepared with a documented list of all the roles and responsibilities and ensure that they are understood by all the personnel.

For more detailed insights into the changes made to the PCI DSS standards, watch our Fireside Chat on PCI DSS 4.0 – A Transformational and Technology Driven Future for Payments with Dr. Rebecca Wynn – Chief Cybersecurity Strategist and Privacy & Risk Officer.

SISA’s Latest
close slider