PCI DSS V4: What’s new and what’s new in this version!
As most of you know, this week the long-awaited fourth edition of the PCI DSS security standard was published by the PCI Council. PCI is the bible for businesses that need to protect credit card data, including merchants and service providers . Any business that handles card data in any way must comply with the mandatory PCI DSS standard.
The new PCI V4 version maintains this principle, namely that the entire transaction chain, from the smallest online store to the bank itself, requires compliance, but moves to a different model that gives greater weight to the outcome.
It is important to remember that the new version comes after a 2-year period, when due to the coronavirus, online purchases with credit cards in the period 2019-2021 showed a 150% increase, correspondingly attracting the interest of cybercrime.
Key goals in PCI version 4.0
The 12 core categories of PCI DSS requirements remain the same, but:
- It modernizes standards to keep up with modern technological needs such as cloud computing, MFA, etc.
- Promotes safety as an ongoing process in the business.
- It becomes more flexible, now officially giving the possibility of selecting Remediation Actions, which until V3 was practically only done in on-site audits by QSAs.
- Guiding businesses to implement multiple security procedures to increase the overall security of the business.
3DS gets its own PCI V4 requirements
This new version creates a new security standard for EMV® 3DS solution providers. This new standard provides software vendors and managed providers with guidelines for implementing appropriate security procedures – safeguards, in order to protect the transaction as much as possible.
Encryption: Upgraded encryption specifications in PCI DSS v4.0
A significant upgrade to the standard also comes in the area of credit card data encryption. As expected, the standard now extends the requirement to use encryption to the internal network as well. It should be recalled that until v3, the obligation only included public networks, although many companies have already started to adopt the new practice.
Until version 3, businesses could use hashing to keep an unreadable copy of the card number without further security measures. Now the hash itself must be encrypted and protected (req 3.5.1.1). Additionally, SAD (Sensitive Authentication Data) must now also be protected with strong encryption according to requirement 3.2.2.
In the new version, simple disk encryption (e.g. bitlocker) is not acceptable for storing card data with the exception of removable media. Also, the creation of a certificate inventory (12.3.3) is mandatory for monitoring certificates and which should be included in the annual Risk Assessment (12.3.3). Finally, three key triple DES (TDES/TDEA) is no longer considered secure after 31/12/2023.
The new requirement aims to combat known risks, such as:
- Malicious software inside the network: Network sniffer-type software that aims to intercept unencrypted data.
- Internal risks : Personnel or contractors who, within the scope of their contract, have network access to the cardholder environment and can easily collect card data (e.g. network administrators).
- Misconfiguration : Protection against misuse/configuration of systems, such as the use of older generation WiFi protocols in which all traffic can be stolen and decrypted.
E-Commerce
Significant changes are coming to the e-commerce channel, based on tampering & skimming attacks, where essentially hacked e-shops present a form during checkout using javascript to collect credit card details, with the aim of deceiving the customer into entering their details there.
Thus, requirement 6.4.3 requires that only the necessary javascript be loaded on the payment page and that it must go through an approval process before being used. In practice, analytic scripts, ads scripts, etc. are prohibited on the payment page. In addition, the integrity of the scripts used must be checked according to the corresponding Content Security Policy. The use of WAF (Web Application Firewall) is now officially mandatory according to requirement 6.4.1.
Authentication & Multi Factor Authentication
Starting with v3.2.1, when the MFA requirement first appeared, the new version further strengthens the use of multiple authentication methods. Now, the use of MFA is extended from administrators to all users who have access to credit card data. Requirement 8.4.2 extends the scope of MFA beyond non-console connections, namely:
- Cloud environments
- Hosted systems
- On-premises applications
- Network security devices
- Workstations, Servers and Endpoints
The standard specifies that Multi Factor Authentication should be implemented in such a way that:
- Don’t be vulnerable to Replay attacks.
- There should be no possibility of bypassing or excluding without the approval of management.
- It uses at least two ways of identification (Something you know – Something you have – Something you are).
- Denies access if all user identification methods are not met.
The minimum password length is now set at 12 characters, with the exception of legacy systems of 8 and only if it is not technically feasible to upgrade them.
Logging and Internal Vulnerability Scanning
As is well known, PCI requires extensive event logging to record and track actions in the PCI environment. Now logging is required for both Post Forensic Investigation and real-time detection. Thus, the existence of an automated logfile analysis mechanism becomes mandatory to prevent malicious actions (10.4.1.1).
Additionally, internal vulnerability scanning should be able to authenticate. The reason is obvious and has to do with the fact that in practice, attackers usually gain access to the system in some way and try to exploit vulnerabilities in order to perform privilege escalation.
Legacy systems
PCI-DSS v.4 significantly impacts Legacy systems, which will need to be upgraded to keep up with the new specifications that define the data of the time. This results in new requirements regarding:
- Technical specifications : Systems should be upgraded to the latest versions and meet new standards, such as multi-factor authentication.
- Risk Management Procedures : PCI DSS now requires businesses to conduct extensive Risk Assessments, where legacy systems will begin to generate increased risk indicators
- Architectural requirements : As with technical specifications, it will likely require redesign to support new requirements such as customer segmentation.
Requirements v4
The new version also comes with significant changes to the number of specifications, which increase by 64 in total, with merchants having to meet an additional 53 requirements and service providers an additional 11.
Deadline
The new PCI DSS version 4 has been published on the PCI Council website since 30/3/2022 and is considered immediately applicable by any business wishing to comply. The transition period to version 4.0 ends on 31/3/2024, meaning that all businesses and organizations should be fully compliant by then.
This implies that businesses must immediately begin interacting with the new standard to effectively prepare for this new challenge!
