Today, let’s look at some changes made to Requirement 3 for PCI DSS 4.0. I am also adding “Why does this matter?” sections at the end of each control change to hopefully shed light on why it’s important.
Requirement 3 Changes
In Requirement 3, we will find an interesting new control for 4.0:
Why does this Change Matter?
Key here is understanding that all SAD, prior to order completion, if stored, should be stored in an encrypted form. The council also explains that a good practice would be to use different cryptographic keys than those used to encrypt PAN data, but this is not a requirement. In 3.2.1, no requirements existed concerning encryption of SAD before authorization and all requirements as to the storage of SAD after encryption is still retained in 3.3.1. Any SAD that is entered in a checkout page, before order completion, could be compromised through various means and therefore must be protected from bad actors who would want to try to scrape cardholder data from a website before transaction completion. Properly encrypting SAD before completion of a transaction is one way to prevent card-not-present transactions through stolen card data.
This requirement is considered a best practice until 3/31/2025, when it will be a fully enforceable requirement.
New Control from 12.3.10 now in 3.4.2
Why does this Change Matter?
In 3.2.1, this used to be a general usage policy in 12.3.10, but now is being codified in its own requirement in storage controls for 3.4.2. This is helpful because most of 12.x controls are concerned with policies and this control always seemed out-of-place in the 12.x environment as it had no practical teeth anywhere else in the DSS.
New Controls for 3.5.1: 3.5.1.1 and 3.5.1.2
Why does this Change Matter?
The first requirement stems from protecting stored PAN data using keyed cryptographic hashes of the entire PAN and backing it with proper key management. PAN needs to always be encrypted as a second layer of protection given a compromise. While this was considered a control in 3.2.1 by proxy of other controls, it is now codified into its own control.
In addition, where disk-level encryption is used, there are restrictions put on it’s use. I.E. – it can only be on removable drives, or if on internal storage, it must have another layer of protection making it unreadable. Basically, since disk-encryption can be decrypted when a system runs, it is trivial to get around, so only removable drives with a key would prevent this, or a second layer of protection implemented.
If you have further questions or are interested to see how your company fares against 4.0 today, reach out and we would be happy to discuss with you further.
Recent Comments