Decrypting the New Cryptographic Requirements in PCI DSS v4.0

A fun fact about Egyptian hieroglyphics is that you don’t necessarily read them as we read English—from left to right. They could be written what we consider backward, or even vertically.

Not only that, but hieroglyphic writing doesn't contain punctuation, nor are there spaces between words. If you were to attempt to read some, you’d need a good grasp of ancient Egyptian grammar (and who has that these days?). You’d probably also need to understand at least a little context of the message if you wanted to tell everything apart.

It might feel as complicated to try and understand the new cryptographic requirements in PCI DSS v4.0.

And while we are not at all equipped with the context or grammar to read ancient, pictographic writings, we can offer something similar when it comes to helping you decrypt these changes in the standard.

Just like hieroglyphics, cryptography is complex and often requires more planning than other controls. Schellman has been on top of this latest version of the flagship payment card standard since even before its release, and now we want to share some of our insight on this particular subject with you.

Changes to encryption are not a surprise in the broader context of the new PCI-DSS version. These new control requirements are just meant to further safeguard account data, and in this article, we’ll get more granular as to how they’ll do that.

We’ll highlight several new requirements, evolving requirements (expansion), as well as how to prepare for these changes. Though it will likely take more than just one blog post to ease your anxiety about the transition that lies ahead, after reading you’ll feel that much more comfortable with one of the more complicated components of PCI DSS v4.0.

Understanding the General New Cryptographic Requirements in PCI DSS v4.0

What These Affect: Encryption During Transmission

Overall, the changes expand the scope of protecting cardholder data during transmission of any kind on trusted or untrusted networks.  Of course, strong encryption on untrusted networks is already widely accepted, but you might be wondering what risk there would be for unencrypted cardholder data on a trusted network.

Consider these particular risks and how strong encryption can help:

• The Threat of Malicious Code Within a Network: An adversary may embed malicious code using many methods in an attempt to capture sensitive data.  If encryption is not implemented during transmission, a malicious actor who succeeds in gaining access to primary or adjacent systems may be able to view, record, and exfiltrate sensitive data. The expanded scope for encryption will help prevent this.
  
  
• Insider Threat: You may have a situation where a trusted party has substantial access to network traffic.  But in some instances of unencrypted data transmission, an attacker may collect and observe cardholder data without activating security controls.  Encryption of cardholder data in transmission reduces this risk.
  
  
• Misconfiguration: Before this new version, weak encryption was allowed—i.e., WEP, TLS 1.1, standalone SSL, etc.—though it left you susceptible to simple downgrade attacks.  A downgrade attack is where a bad actor “convinces” a system to abandon a secure method of communication by using less secure, but still available encryption.  Strong, and only strong encryption prevents the loss of sensitive data by this method, hence this update to PCI DSS v4.0.

Understanding PCI DSS v4.0 Requirement 12.3.3 – New*

What This Affects: Cipher Review

Under this new requirement, you are now obligated to document and review cryptographic cipher suites and protocols at least annually.

Your reviews should include information such as:

• The categorization of information/information system the cryptographic cipher protects;
• An assessment of cryptographic cipher effectiveness;
• A determination if the cipher is necessary for the operational function of information system(s); and
• Confirmation that information security requirements are being met and integrated into your enterprise architecture and system development life cycle process. They should also align with business and risk strategies as established by senior leadership.

Understanding PCI DSS v4 Requirement 4.2.1.1 – New*

What This Affects: Inventory

Among all the changes, PCI DSS v4.0 also includes requirements to maintain an inventory of trusted keys and certificates. This one in particular ties into strong encryption.

Similar to current requirements regarding change control, keys and certificates will also require documentation and knowledge management. 

Documenting a process for issuing, retaining, and storing cryptographic keys and certificates in a repeatable process may assist with this requirement.

Understanding PCI DSS v4.0 Requirement 3.6.1.1 - New*

What This Affects: Cryptographic Architecture (Service Providers Only)

Service providers must now include a documented description of the cryptographic architecture for production and test environments. 

Why? To prevent the use of duplicate cryptographic keys across environments.

Because test environments are potentially less secure than production, there is greater potential for cryptographic keys to be intercepted and decrypted. This requirement will help curb that.

Understanding PCI DSS v4.0 Requirement 4.2.1 - *Evolved

What This Affects: Primary Account Numbers (PAN)

Certificates used to safeguard PAN during transmission over open, public networks must be confirmed as valid and are not expired or revoked. 

Internally issued certificates will need to be logged as inventory (as we mentioned above under Requirement 4.2.1.1). Internal certificates issued and managed by an internal certificate authority may still be used if managed properly.

How to Prepare for the New Cryptographic Requirements in PCI DSS 4.0

The big question now becomes how to deal properly with all these updates. Here are three tips:

• Stay Cognizant of the PCI-DSS v4.0 Timeline for Transition. 
  • Encryption methods and requirements may be subject to change, so to boost your adaptability, preparation in the meantime will be key. 
  • Future dated requirements are considered to be a best practice until Q1 2025.
• Ensure Review of Internal Applications That Rely on Unencrypted or Explicit Encryption.
  • Now under these new requirements, internal applications used to store and transmit sensitive data may require substantial re-development or re-tooling. 
  • Although PCI-DSS v3.2.1 is not expected to be retired until Q1 2024, making changes to internal software/hardware may require considerable time and effort, so starting your review as soon as possible is recommended.
• Consider the “Bigger Picture.” 
  • It may be that your organization also uses information systems that are incapable of cryptographically secure communication. But these are facing deprecation.  
  • Though those systems may be spared the scrutiny of the above requirements, major organizations are adopting other approaches to ensure they don’t fall victim to any surprises:
    • For example,  Federal (FISMA) compliance, given its underlying system requirements derived from NIST 800-53, is generally proactive in developing security controls and is closely mapped with current PCI-DSS standards. That standard has also now implemented similar cryptographic requirements that may be worth looking into for you. 
  • Whether you opt for FISMA or not, as attackers become more advanced, you must put the tools in place to secure all your systems as you adapt to increasing requirements. If you don’t, you leave the door open to substantial risk.

Moving Forward With PCI DSS v4.0

Comprehension of the entire new PCI DSS standard may feel like looking at hieroglyphics now, but it won’t always. And now you at least understand more about what will be asked of you on the cryptography side, so you’re getting there.

As we all continue to get acquainted with the new version, read our other content on PCI DSS v4.0 for breakdowns of some of the most important updates:

• What Service Providers Should Know About PCI DSS 4.0
• How to Define Time in PCI DSS v4.0
• Multi-Factor Authentication in PCI DSS v4.0

But if you find that you have questions more specific to your organization and the impact of PCI DSS v4.0, please contact our team at pci@schellman.com or through our contact us page. Whether by setting up a call or through an email conversation, we’ll do what we can to set your mind at ease.