Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
Continuing with the analysis of PCI DSS version 4.0, in this third part of the series we will analyze requirements 3 and 4, which are part of the "Protect Account Data" group, focused on protecting the confidentiality and integrity of payment card data during its storage and transmission through open and public networks.
As with most of the requirements in PCI DSS 4.0, requirements 3 and 4 were renamed to broaden 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 where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE.
Whereas in PCI DSS version 3.2.1 the group names and requirements 3 and 4 referred only to the protection of Cardholder Data, in version 4.0 this term is extended to include not only Cardholder Data but also Sensitive Authentication Data, in accordance with the definitions of these terms in the standard:
Requirement 3: Protect Stored Account Data
As in previous versions of the PCI DSS, this requirement is focused on the protection of card data during storage.
Although this requirement has always included specific controls aimed at protecting the full magnetic stripe data, the PIN/PIN Block and the Card Verification Code, the name of the requirement (Protect stored cardholder data) in past versions of the PCI DSS standard only mentioned cardholder data, which added a point of inconsistency between the controls contained in this requirement and the name of the requirement itself, as it did not explicitly include Sensitive Authentication Data. In version 4.0 of the PCI DSS, this has been resolved and now the name of the requirement (Protect stored account data) is aligned with the types of data it protects (cardholder data and sensitive authentication data, as part of account data).
Some of the most significant changes in this requirement are:
Clarification of card storage types
In version 4.0, a number of long-overdue clarifications have been added to this requirement. In the first instance, an explicit separation of card data storage types is made, including the restrictions and applicability of controls for each:
For this type of storage, all the controls of requirement 3 are applicable.
For this type of storage, the data must be removed as soon as its business purpose has been completed. However, additional controls such as data encryption are not required as long as the data is not moved to persistent storage, as specified in FAQ 1042.
Controls for the protection of sensitive authentication data
On the other hand, additional clarifications and controls have been added for the protection of Sensitive Authentication Data stored prior to the completion of the authorization process, including:
These controls will be effective as of March 31, 2025.
Masking controls and 8-digits BINs
Probably one of the controls that generated the most expectations in this new version of the PCI DSS standard was the control related to the masking of PAN data during its display, given the continuous changes in the payment tag criteria related to the entry into force of the eight (8) digit BIN/IIN. In this regard - and in order not to conflict with the payment brands’ criteria - the standard maintained its neutral position by clarifying that, when the PAN is displayed, only the BIN/IIN (regardless of its length) and the last four digits may 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 FAQ 1492 of February 2021.
PAN copy/relocation when using remote access technology
In PCI DSS v.3.2.1, control 12.3.10 prohibited the copying, moving and storage of card data on local hard drives and removable storage media when accessing this data via 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 to PAN data only.
This control will be effective as of March 31, 2025.
Secure PAN storage
One of the flagship PCI DSS controls is the control identifying the authorized methods for storing PAN data. While 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:
Use of disk- or partition-level encryption
Another control that had problems in its interpretation/implementation was the control related to the use of disk- or partition-level encryption. By using this mechanism, data is encrypted during storage but is automatically decrypted once the system is running or after successful authentication of a user, so its effectiveness is valid only while the storage medium is offline, protecting the entity if the media is physically removed in an unauthorized manner.
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 is not explicitly stated in control 3.4.1 of PCI DSS v3.2.1, many entities used this mechanism to protect the PAN when it was stored in databases without any additional control (Transparent Data Encryption - TDE is a good example of this), exposing them to unnecessary risk.
To avoid this ambiguity in the interpretation of the control, in version 4.0 requirement 3.5.1.2 clarifies that the use of disk or partition level encryption can only be applied to removable storage media or, if used on other types of media (including server hard disks, hot-swappable drives, bulk tape-backups, etc.), an additional protection mechanism included in control 3.5.1 (hashing, encryption, truncation or tokenization) must be used.
Improved encryption key management processes
Finally, the cryptographic key management controls (req. 3.6 and 3.7) have been updated to include cryptographic services in the cloud, avoid using the same cryptographic key in production and test environments (req. 3.6.1.1, applicable only for service providers, and as of March 31, 2025), use of approved random number generators within a Secure Cryptographic Device (SCD) or other standards (such as ISO 19592) for key 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
In PCI DSS version 4.0, requirement 4 was simplified and several clarifications were added regarding the use of strong cryptography, mainly to avoid issues such as the obsolescence of SSL and the use of early versions of TLS years ago. Many concepts that had already been discussed in the Information Supplement - Best Practices for Securing E-commerce were also incorporated, especially those related to the management of digital certificates.
In this regard, the following were the main changes in this requirement:
Accordingly, encryption of the PAN during transmission within internal networks is not mandatory, but it is a good practice.
Depending on the option implemented, the following must be taken into account:
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 purpose.
The next article in this series will discuss PCI DSS requirements 4 and 5, which address protection against malicious code, security updates, change management, and secure development.
Is this your first time reading the Analysis of PCI DSS v4.0 series? Follow the links below to catch up on the previous articles:
References
Column Header Text | Column Header Text | Column Header Text |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
|
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection. |
Performing a review of the media inventories at least annually |
Performing a review of the media inventories at least annually |
Performing a review of the media inventories at least annually |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
Row Header Text |
Lorem ipsum dolor sit |
Lorem ipsum dolor sit |
23 |
I am the Senior Security Consultant in Advantio. I have more than 15 years of experience, working both in South America and Europe. My information security background includes consultancy and audit, training, implementation of security technologies and design and policy development among others.
Certifications: CISSP, CISM, CISA, CRISC, CEH, CHFI, PCI QSA, QSA (P2PE), 3DS Assessor
Comments