For those of you that found the previous blog posts on changes in the specific requirements for PCI v4, I have some great news. This one will be just as exciting, so get comfortable and prepare to be informed AND entertained! Requirement 3 is one of the key areas with PCI. When you talk about a security standard specifically designed around protection of credit card data, then we all need acknowledge the importance of the part of the standard focused on actually storing that data.
Overall Thoughts
Obviously, the best plan is to not store any cardholder data, if you can help it. For those that can’t (or won’t) avoid storing cardholder data in their environment, protecting it should be a top priority for you. Bury it deep in the environment. Restrict the access to as few people as possible. Encrypt the data when it is at rest. You get the idea. Worst case scenario you have unencrypted data in your environment that is accessible by numerous employees. Actually, it can get much worse than that, but I want to give you the benefit of the doubt on having some modicum of sense in this area. We have a lot to go over in requirement 3, so I am not going to go on and on here, despite it being my nature to drone on (and on).
What’s New for Req 3 in v4
Compared to our previous requirements discussed, R3 has a fair number of new changes to it in version 4. As previously mentioned, anyone reading the series won’t be surprised to learn that a new 3.1.2 has been added to further develop the needs to account for ownership of the PCI program. Of course, with requirement 3 you might want to go into a more detailed accountability matrix or RACI based on your environment. Some companies will have different management chains for different types of databases (SQL v Oracle, etc.) and may have different responsible parties handling application level data management. This needs to all be accounted for in 3.1.2.
The other net new changes for requirement 3 are:
- 3.4.2 – Technical controls to prevent copy and/or relocation of PAN when using remote-access technologies except with explicit authorization. – A policy is no longer sufficient to prevent this from happening. A technical control/tool needs to be in place to manage this potential aspect of data management.
- 3.5.1.1 – Hashes used to render PAN unreadable are keyed cryptographic hashes with associated key management.
- 3.5.1.2 – Implementation of disk-level or partition level encryption when used to render PAN unreadable.
- 3.6.1.1 – A documented description of the cryptographic architecture includes prevention of the use of cryptographic keys in production and test environments.
Changes to the existing controls
Changes to existing controls for requirement 3 are about the same amount as new controls. As previously done in this post and others, we will just touch on the items in these blog posts and save detailed discussions on the changes for you to have between yourself and your trusted subject matter experts and/or consultants. There are few that we will list below in changes that the DSS lists as “new”, but I disagree with that designation, so am placing them here under changes. I will mark them through, so you can treat them as is appropriate in your environment.
- 3 (in general) – Clarification/guidance – Updated principal requirement title to reflect the focus on account data over the term cardholder data. It is still the “credit card account” though, not the individual’s personal data. That data will be covered by privacy standards.
- 3.2.a – Clarification/guidance – Combined with 3.2.b to now be 3.3.3 and added a requirement to address former testing procedures that any storage of SAD by issuers is limited to that which is needed for a legitimate issuing business need and is secured.
- 3.2.1 – Listed as “new” – Any SAD stored prior to completion of authorization is kept to a minimum during implementation of data retention and disposal policies, procedures, and processes. (Fun Fact – 3.2.1, along with 3.2.2, 3.2.3 are the only areas in the DSS that cannot be checked as N/A)
- 3.2.2 – Listed as “new” – Encrypt SAD that is stored electronically prior to completion of authorization. (HUGE – this is usually done in VRAM, so make sure you are doing this, or are at least capable of doing so).
- 3.2.3 – Listed as “new” – SAD stored by issuers is encrypted using strong cryptography. (This one probably won’t have much, if any, impact on you.)
- 3.3 – Evolving Requirement – Previously 3.4.1 – Clarified that PAN is masked when displayed such that only personnel with a business need can see more than the BIN/last four digits of the PAN. (Note – it used to be that masked PANs referred to first 6 and last 4, but they have updated the term to be BIN/Last Four, to account for some Bank Identification Numbers being longer than 6 digits).
- 3.4 – Evolving Requirement – previously 3.5.1 – Removed pads from the “Index tokens and pads” bullet for rendering PAN unreadable.
Conclusion
As you can see running through the list, the PCI council is changing both terminology and technical control requirements for how data storage is managed. You will see this approach throughout the majority of the v4 changes. A push for updated technical capabilities and automation, when applicable, allows for a faster reaction time when attacks happen, which lowers potential impact and risk. In the case of R3 the efforts are focused on making sure that not only are we reacting faster, but if (when) we fail to protect data from being taken by some unethical actor that has access to the environment, the usability of that data is reduced (ideally eliminated).
As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge. Feel free to reach out to me directly with questions or to have a conversation via my email and/or social media information on the TBF website. Thanks for taking the time to read my thoughts on PCI v4 Requirement 3. We will continue to work through each of the PCI requirements each week.