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:

• At Rest: Stored in a server, device, or removable media (USB stick, hard drive, etc.). 
• In Transit: Moving between a sender and recipient as IP packets or traveling between locations on a physical medium.
• In Use: Displayed, manipulated, or present in an application or workstation.

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

• Man-in-the-Middle (MitM) Attacks: One of the more prominent threats to transmitted data is the potential for intercepting it before it reaches its destination. With the right tools and luck, Hackers can insert themselves between different systems and collect data as it moves between them. Following this, these hackers can either altogether remove whatever data they choose or simply eavesdrop, copying data whenever they wish. Accordingly, any unencrypted data sent over this channel is in open season for theft. 
• Internal Threats and Perimeter Control: Even if data moves through internal local area networks, ideally secured, there’s still the possibility that a hacker breaches the system undetected or that an insider is viewing unauthorized data. 
• Lost or Stolen Devices: Technically, information stored on a removable medium (hard drive, USB drive) for transportation between locations is considered “in transit” precisely because the data may be lost or stolen during its journey.

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

• Documentation and Personnel: Like previous requirements, PCI DSS standards expect you to have a policy for encrypting in-transit data. This policy must be documented, recent, and available to anyone relevant to the practices of encrypting, securing, or handling PAN. 
• Roles and Responsibilities: Roles must be assigned such that any relevant individual, who may be affected by the policy, understands their responsibilities and activities. Furthermore, a hierarchy of roles helps promote accountability throughout the organization and supports communication of policy changes and updates over time. 

4.2 – Protecting PAN with Strong Cryptography During Transmission

• Using Strong Cryptography: Your organization must implement strong cryptography and security protocols to safeguard PAN during transmission. This means only using trusted keys and certificates for encryption and decryption, all certificates are verified, all encryption protocols are secure and don’t fall back on insecure versions, and the strength of the encryption algorithm used is sufficient to protect the face. Finally, while encryption over internal networks isn’t required under this rule, it is considered a best practice.
• Key Management: Your organization must always maintain an inventory of trusted keys and certificates and immediately remove compromised or expired keys. This allows your organization to replace keys as needed and minimize security threats quickly. 
• Wireless Cryptography: Wireless cryptography must control who can connect to wireless networks that support or carry PAN. This includes strong cryptography and authentication standards. There should be no fallback to weaker versions of wireless encryption.
• End-User Applications: If PAN is sent via end-user messaging or email technologies, it must be obfuscated with strong cryptography. This practice is generally discouraged, but the information must be encrypted when it happens. 

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.