Analysis of PCI DSS v4.0 – Part III: Requirements 3 and 4

Continuing with the analysis to version 4.0 of the PCI DSS standard, this third part of the series will analyse requirements 3 and 4 that are part of the group “Protect Account Data”, aimed at protecting the confidentiality and integrity of payment card data during storage and transmission over open and public networks.

Like most PCI DSS 4.0 requirements, requirements 3 and 4 were renamed to extend their scope, as well as to align these controls with the applicability of the standard, as specified in section 2 ‘PCI DSS Applicability Information’: PCI DSS requirements apply to entities with environments in which account data is stored, processed, or transmitted (cardholder data and/or sensitive authentication data), and entities with environments that may affect CDE security (PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or measured, and entities with that environments can impact the security of the CDE).

While in version 3.2.1 of the PCI DSS standard the names of the group and requirements 3 and 4 mentioned only the protection of cardholder data (Cardholder Data), in version 4.0 this term is extended not only to cardholder data, but also to confidential authentication data (Sensitive Authentication Data), in accordance with the definitions of these concepts included in the standard:

Components of the "Account Data" concept in PCI DSS

Requirement 3: Protect Stored Account Data

As in previous versions of the PCI DSS standard, this requirement is focused on protecting card data during storage.

Although this requirement has always included specific controls aimed at protecting the complete data of the magnetic stripe, the PIN/PIN Block and the verification code of the card (Card Verification Code), the name of the request (Protect Stored Cardholder Data) only referred to the cardholder's details (Cardholder Data), which added a certain point of inconsistency between the controls contained in this requirement and the name of the requirement itself, by not including confidential authentication data (Sensitive Authentication Data) explicitly.  In version 4.0 of the PCI DSS standard, this has been solved and now the name of the requirement (Protect Stored Account Data) is aligned with the types of data it protects (cardholder data (Cardholder Data) and confidential authentication data (Sensitive Authentication Data), as part of the account data (Account Data)).

Some of the most significant changes to this requirement are:

Clarification of card storage types

In version 4.0, a series of clarifications have been added to this requirement that have been waiting for a long time. In the first instance, there is an explicit separation of the card data storage types, including restrictions and applicability of controls for each:

• Persistent storage (persistent storage) or non-volatile: This type of storage is applied when the card data is retained after the completion of its business purpose (for example, an associated transaction). Within this type of storage is intentional or unintentional storage on storage media such as hard drives, backup drives, removable storage media, etc. in the form of event log files (logs), historical archives (history files), traceability files (trace files), contents of databases, memory/crash dump files, etc.For this type of storage, all checks of requirement 3 are applicable.
• Non-persistent storage (non-persistent storage) or volatile: This type of temporary storage is used when the card data is processed during its business purpose only. Within this type of storage is RAM and other types of volatile memory, where information is lost when the electrical flow is interrupted. For this type of storage, the data must be removed as soon as its commercial purpose has been finalised. However, Additional controls such as data encryption are not required as long as the data is not moved to persistent storage, as specified in the FAQ 1042.

Applicability of PCI DSS depending on storage medium

Controls for the protection of confidential authentication data

On the other hand, additional clarifications and controls have been added for the protection of confidential authentication data (Sensitive Authentication Data) stored prior to the completion of the authorisation process, including:

• Inclusion in the retention and secure deletion policy, to limit the storage of this data to the minimum necessary (req. 3.2.1),
• Encryption of this data using robust cryptography, even if PAN data is not present in the environment (req. 3.3.2 and 3.3.3).

These controls shall enter into force from 31 March 2025.

Masking and 8-digit BIN controls

Probably one of the controls that generated the most expectation in this new version of the PCI DSS standard was the control related to the masking of the PAN data during its visualization, given the continuous changes in the criteria of the payment marks related to the entry into force of the BIN / IIN of eight (8) digits. In this regard – and in order not to conflict with payment marks – the standard maintained its neutral position by clarifying that, when the NAP is displayed, only the BIN/IIN (outside its length) and the last four digits can be displayed. If the display of additional digits is required, it is necessary to maintain a list of roles with this privilege, as well as their business justification.

This control is aligned with the FAQ 1492 February 2021.

PAN copy/relocation when using remote access technologies

In PCI DSS v.3.2.1, control 12.3.10 prohibited the copying, relocation and storage of card data on local hard drives and removable storage media when accessing this data through remote access technologies, unless there was an authorized business need. This control has been moved from requirement 12 to requirement 3 in PCI DSS v4.0, clarifying that its applicability is only to the PAN data.

This control shall enter into force from 31 March 2025.

Safe PAN storage

One of the star controls of PCI DSS is the control where the authorized methods for the storage of PAN data are identified. Although these methods have not changed between version 3.2.1 (req. 3.4) and version 4.0 (req. 3.5.1), several clarifications have been added:

• If you make use of a hash, the function should be applied to the entire NAP using robust cryptography (Req. 3.5.1.1). Likewise, the use of a simple hash function will no longer be allowed. As of 31 March 2025, cryptographic hash algorithms with a key (keyed cryptographic hashing algorithms) such as HMAC, CMAC or GMAC. Obviously, such a key will have to meet the requirements of cryptographic key management (reqs. 3.6 and 3.7).
• If the truncation, a hash cannot be used to replace the truncated part of the PAN. Additionally, if in the same environment there are truncated and hash versions of the same PAN or different truncation formats of the same PAN based on the criteria of the payment marks (FAQ 1091), additional controls should be applied (FAQ 2014).
• If used encryption, key management controls should be taken into account and robust cryptography should be used.
• If tokenization is used (index tokens), the use of the criteria described in the document is recommended Tokenization Product Security Guidelines the PCI SSC and Standard ANSI X9.119-2-2017: Retail Financial Services – Requirements For Protection Of Sensitive Payment Card Data – Part 2: Implementing Post-Authorization Tokenization Systems.

Using disk-level or partition-level encryption

Another control that had problems in its interpretation was the control related to the use of disk-level or partition-level encryption. By using this mechanism, the data is encrypted during storage, but is automatically decrypted once the system runs or after a correct authentication of a user, so its effectiveness is valid only while the storage medium is offline (offline) protecting the entity if the medium is removed physically in an unauthorised manner.

Transparent data encryption (TDE)

Although it was well known that the use of this type of encryption is only applicable when the PAN is stored in a removable electronic medium, since this restriction was not explicit in control 3.4.1 of PCI DSS v3.2.1, many entities used this mechanism for the protection of the PAN when it was stored in databases without any other additional control (Transparent Data Encryption – TDE is a good example of this), being exposed to unnecessary risk.

To avoid this ambiguity in the interpretation of the control, in version 4.0 the requirement 3.5.1.2 clarifies that the use of disk or partition level encryption can only be applied on removable storage media or, if used on other media (including server hard drives, hot swappable drives (hot-swappable drives), bulk tape-backups, etc., must be made use of an additional protection mechanism included in control 3.5.1 (hash, encryption, truncation or tokenization).

Improvements in encryption key management processes

Finally, cryptographic key management controls (req. 3.6 and 3.7) have been updated to include cryptographic services in the cloud, avoiding the use of the same cryptographic key in production and testing environments (req. 3.6.1.1, applicable only to service providers and as of 31 March 2025), use of approved random number generators within a secure cryptographic device (Secure Cryptographic Device – SCD) or other standards (such as ISO 19592) for the generation of keys or key components (req. 3.6.1.2 and 3.7.6) and additional responsibilities in the event that a service provider shares encryption keys with its customers (req. 3.7.9).

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

For PCI DSS version 4.0, requirement 4 was simplified and several clarifications were added regarding the use of robust cryptography, mainly to avoid situations such as the obsolescence of SSL and the use of early versions of TLS in the future. Likewise, many concepts were incorporated that had already been discussed in the Information Supplement – Best Practices for Securing E-commerce, especially those related to the management of digital certificates.

In this sense, the following were the main changes in this requirement:

• Its applicability is limited exclusively to the transmission of the NAP on open public networks, within which are Internet, wireless technologies (Wi-FI and Bluetooth), mobile communications technologies (cellular) and satellite. According to this, PAN encryption during transmission within internal networks is not mandatory, but it is good practice.
• In the event that the PAN is transmitted over open public networks, it can be protected by encrypting this data before it is transmitted, encrypting the session over which the data is transmitted or both.

Using Data Encryption and Channel Encryption in PCI DSS

Depending on the option implemented, the following should be taken into account:

• If data is encrypted prior to transmission, the keys used for this purpose shall be covered by controls 3.6 and 3.7.
• If channel encryption is used, it must be validated that:
  • If certificates are used, they must be reliable and must not be expired or revoked (this control will take effect from 31 March 2025).
  • If self-signed certificates are used, they will be valid if they are issued by a certification body (Certificate Authority) internal, if the author of the certificate is confirmed and if the certificate is verified and not expired.
  • The protocols used must only support secure versions.
  • The strength of the cryptography employed should be appropriate to the encryption methodology in use.
  • A list of the keys and certificates used to protect the PAN during its transmission must be maintained (this control will take effect from 31 March 2025).
• In the event that the organization may receive unsolicited payment card data through insecure communication channels, there are two options to protect it:
  • Include the affected channel within the CDE and protect it according to standard controls; or
  • Implement measures to prevent that channel from being used for card data transmission.

Other controls, such as transmitting the PAN over wireless networks or using end-user messaging technologies, remain valid as long as robust cryptography is used for this.

The following article in this series will discuss requirements 4 and 5 of PCI DSS, aimed at protection against malicious code, security updates, change management and secure development.

References

• Information Supplement – Best Practices for Securing E-commerce https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf
• Use of SSL/Early TLS and Impact on ASV Scans https://www.pcisecuritystandards.org/documents/Use-of-SSL-Early-TLS-and-ASV-Scans.pdf
• Use of SSL/Early TLS for POS POI Terminal https://www.pcisecuritystandards.org/documents/Use-of-SSL-Early-TLS-for-POS-POI-Connections.pdf
• Tokenization Product Security Guidelines https://www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf
• PCI DSS Wireless Guidelines https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Wireless_Guidelines.pdf