Site icon

Timeline for PCI DSS 4.0: The Fourth Requirement and In-Transit Encryption

PCI DSS 4.0 featured

As we move through the requirements of PCI DSS 4.0, we’ve reached the point where the standard specifies what it means to protect data as it moves through and outside of private and public networks. 

Encryption seems like a no-brainer, but in many cases, organizations have no idea how to manage their encryption approach properly. Key management, minimum strength, and application points can be challenging to juggle without understanding how it fits into the bigger picture. 

Here, we’ll discuss the fourth requirement of PCI DSS 4.0 and what it says about in-transit encryption.

 

Why Is it Important to Protect Data In Transit?

In the world of cybersecurity, data is thought to have three states:

In the payment industry, the transmission of cardholder information (data in transit) is essential to support modern eCommerce. Without such communications, digital storefronts would be an impossible dream, and retailers would be stuck using card imprinters for all transactions.

The challenge here is that cardholder data is necessarily put at risk to maintain fast and efficient digital commerce. That’s why the PCI DSS standard includes strict requirements on the types of encryption used to protect that data from unauthorized disclosure, including specific requirements regarding data in transit.

 

What Are Common Threats to Transmitted Data?

Because data in transit faces unique threats, there are several unique and challenging threats that security experts face in protecting it. 

Some of these threats include

What Is the Fourth Requirement for PCI DSS 4.0?

The PCI Security Standards Council included the fourth requirement into the PCI DSS framework to implement secure in-transit protections for cardholder data. This requirement dictates that compliant companies implement specific security controls for encrypting in-transit data. 

Data must be encrypted during transmission using strong encryption on public or untrusted networks. However, it’s also critical to encrypt data whenever potential exposure exists. 

Any transmission of Primary Account Numbers (PANs) must adhere to this requirement unless specified in another requirement. 

 

4.1 – Processes and Mechanisms for Protecting Cardholder Data With Strong Cryptography During Transmission Over Open, Public Networks

 

4.2 – Protecting PAN with Strong Cryptography During Transmission

 

What Is Strong Cryptography?

Strong cryptography is a general phrase that gains context depending on the framework and industry it’s referenced in. For example, jurisdictions like the EU have laws that specify standards for solid security and encryption, while other regulations like HIPAA have vague technical definitions to support flexible upgrading. 

In the case of PCI DSS, strong cryptography is defined as such:

“Cryptography based on industry-tested and accepted algorithms, strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). At the time of publication, examples of industry-tested and accepted standards and algorithms for minimum encryption strength include AES (128 bits and higher), TDES (minimum triple-length keys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (2048 bits and higher).” 

PCI DSS 4.0 Terms and Definitions

 

Prepare for PCI DSS 4.0 with Lazarus Alliance

As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now.

 

Are You Thinking Ahead for PCI DSS 4.0?

Call Lazarus Alliance at 1-888-896-7580 or fill in this form. 

[wpforms id=”137574″]

Exit mobile version