PCI DSS 4.0 Requirements – Protect Stored Account Data and Protect Cardholder Data During Transmission

Image

If someone asked you “are you protecting your data,” your initial response would probably be to clarify what they are referring to specifically, since the question is so broadly stated. You could just reply with a terse “Yes,” but that is as open-ended and nebulous as the question.  The general idea of data protection encompasses so many areas, from the amount of data that is being stored, to the methods of securing it all.

In the new Payment Card Industry Data Security Standard (PCI DSS) Requirements 3 and 4 add specificity to the question of how to protect data. In the case of PCI DSS, the focus is on cardholder data. 

Requirement 3 is very generally stated as: “Protect Stored Account Data.” The PCI Security Standards Council (SSC) recognizes that this is a very broad statement, and breaks the requirement into subsections that serve to clarify the storage and copying of the valuable information in an environment.

Funso Richard, who serves as an Information Security Officer at a healthcare company, cautions about the deceptively simple directives in this requirement. He suggests that the requirement “is intended to enhance the protection of cardholder data, making it more difficult for threat actors to compromise. However, this update makes the current process more complex. Account Data combines Cardholder Data and Sensitive Authentication Data (SAD), making it challenging to determine what should be in scope.”

This incongruity between the intent, and the required action is not insurmountable. The best approach that Funso recommends is to work with a Qualified Security Assessor (QSA) to define the new scope in accordance with the new PCI DSS version. “A proper assessment is needed of the scope to determine the amount of investment required to effectively update to the new PCI Standard.” Collaboration with a QSA can extend beyond this requirement, to include many other relevant tasks, such as access control, appropriate storage protection through strong cryptographic key management, clearly defined data collection, use, transmission, storage, and destruction guidelines, and continuous monitoring of operational compliance.

Funso draws upon his Governance, Risk, and Compliance expertise to recommend that organizations shift their mindset about how they approach the full Standard. “Treat your PCI compliance requirements as a program rather than a project. Though a program incorporates elements of a project, it is an ongoing process that must be designed to remain adaptable to changes in the Standard. An important benefit of implementing a program is the focus on continuous security and monitoring.”

Requirement 4 takes a step outside of the immediate Cardholder Data Environment, ordering that organizations “Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.” This stands among the shortest of the 12 requirements of the Standard, but its importance cannot be overstated. 

Nigel Sampson, Director of Cybersecurity as well as Global Leader of Cybersecurity for a marketing and technology company, sees a problem with the overall wording of the requirement. He notes that “organizations will not have a marker towards which they can work to ensure compliance, but also ensure secure transport of data. This weakens the Standard. Those organizations that do not have a security team will most likely keep whatever they have currently and will not be forced to update encryption. Removing the prescriptive phrase “the latest version of SSL,” or stating a minimum of TLS 1.2, means that if a new encryption standard comes out, organizations will not be required to update encryption unless the Standard is amended.”

Nigel is sensitive to how difficult it can be to write a rule that captures the spirit of a requirement. As was pointed out by Jeff Mann and Anthony Israel Davis in Part 1 of this series, the Security Standards Council has updated the language of the Standard. However, this is no mere wordsmithing; the Council has carefully selected its words to advance the Standard to meet the modern challenges of data protection.

Nigel takes a wider approach to the requirement, looking to other guiding sources to help an organization to achieve security that goes beyond any semantic weaknesses. “Organizations need to build their security program based on industry guidance and best practices. The program should follow a mix of knowledge, including cyber maturity models. This ensures compliance, as well as providing executive management and Boards a measurement of risk tolerance that the company is maintaining.”

Part of the depth that comes from Requirement 4 can be found in the abundant notes that accompany the Standard. The PCI Security Standards Council (SSC) offers strong guidance, including the recommendation that an organization looks to the NIST documentation for further best practices.

In the next part of this series, we will examine requirements 5 and 6 of PCI DSS version 4.0. To learn even more about the new Standard, as told by other experts in the field, download our eBook.

Learn more about PCI DSS 4.0 Requirements:

• PCI DSS 4.0 Requirements – Network Security Controls and Secure Configuration
• PCI DSS 4.0 Requirements – Protect from Malicious Software and Maintain Secure Systems and Software
• PCI DSS 4.0 Requirements – Restrict Access, Identify Users and Authenticate Access
• PCI DSS 4.0 Requirements – Restrict Physical Access and Log and Monitor All Access
• PCI DSS 4.0 Requirements –Test Security Regularly and Support Information Security with Organizational Policies and Programs