Securing Card Data in Transit: PCI DSS Requirement 4

Confidential data becomes very vulnerable when transmitted over open networks, including the internet, public or otherwise untrusted wireless networks, and cellular networks. Using trusted keys/certificates, secure transmission protocols, and strong encryption is mandated by the PCI Security Standards Council. The PCI Council also gives you the task of updating security procedures to ensure compliance with industry best communications practices.

What do you do after receiving your card data? How is it transmitted to other regions? Are you protecting these areas? These are all issues that may be related to PCI DSS Requirement 4.

This requirement relates to the secure transmission of data, mostly when done over public networks. Companies must be aware of how and on which networks card data is distributed.

How is Transmission Security Provided?

It would be better to use security protocols that you know about, such as HTTPS, SSH, SFTP, TLS, VPN, IPSec, and more while protecting sensitive transit data, but it’s not enough to use just those protocols.

When sending or receiving data, you need to follow and implement methodologies like “defense-in-depth,” where you need more security layers to overcome most of the threats and risks associated with data exposure.

Remember that sensitive data is not just credit card data but can be personal data, financial information, health information, or information that makes your company or organization strong against your competitors or your customers trust you.

See Also: What are the Effects of Using MPLS on PCI Compliance?

PCI-DSS requirement four may be one of the most straightforward requirements to comply with, but it depends on the infrastructure you have. The most commonly used protocols for this purpose are TLS, SSH, and VPN. Almost any transmission protocol can be tunneled through one of these three methods.

You can use FTP over a TLS channel, SMTP over TLS, or of course, HTTP (HTTPS) over TLS. Therefore, if you use HTTPS, FTP/S, or SMTP/S on all your networks with the right TLS protocol configuration, you will be compliant with PCI DSS requirements.

See Also: What You Should Know About PCI Compliant File Transfer

When using TLS to secure communication, here are some things to consider:

• Use an acceptable TLS version.
• Allow only secure password packets.
• Accept x.509 certificates issued by a Certified Certificate Authority (CA) within its validity period.
• Avoid using TLS 1.0, RC4, DES or 3DES, SHA-1, DH, or RSA with 1024 bit key length in encryption packets and versions.
• Try not to use self-signed certificates either.

However, because TLS is widely adopted, there are some environments where companies set up networks to open TLS tunnels and control traffic. Companies can achieve this using root certificates installed on corporate machines and an exemplary proxy configuration.

To protect traffic against these media types, you must encrypt information on a different layer before transmission. Encryption is usually carried out at the application layer, securing the data throughout the tunnel.

In this way, two layers of protection will be created, one on the transport layer and one on the application layer. If an attacker decides to open the TLS tunnel, they will face an application layer encryption.

Of course, this technique will need to have good key management to be useful. If you encrypt or decrypt an asset beyond your control, such as client-side, mobile applications, client/desktop applications, never use a symmetric algorithm for encryption.

See Also: What You Need to Know About Encrypted Communication

It would be best if you used asymmetric techniques and algorithms. You can use symmetric encryption if you have control over the encryption and decryption environment. It would be best to consider key rotation, key generation, distribution, and more details, especially symmetric encryption.

Once you follow all these suggestions, you will have no trouble meeting the PCI DSS 4.1 requirement.

When transmitting, don’t assume that public networks mean the internet. Other networks such as WiFi, Bluetooth, GPRS, GSM, 3G, 4G, Satellite, and more are also considered public. When using any of these networks, you must encrypt the message at the application layer.

First of all, you should never forget that WiFi uses air to transport packets. Most WiFi adapters send and receive packages in omnidirectional waves, so basically, we are all surrounded by WiFi packets.

Anyone with the right tools can capture these packets, and if the traffic is in clear text, they see all the data in transit without any restrictions. This is a type of passive attack, also known as an eavesdropper attack, where one can examine traffic without warning to either party.

See Also: Public Key Cryptography and PGP Fundamentals

Also, the “WiFi password” is not a password to “connect” to the WiFi network. It is a password or text used to encrypt and decrypt all packets that your computer or mobile device will broadcast to communicate with the WiFi access point you want to connect to. So if everyone in the public domain knows the password, basically anyone can access the same encryption key and decipher your information and anyone else connected to the same WiFi network.

For all these reasons, it is highly recommended that you encrypt the information you want to transmit at the application layer again before touching any transmission mechanism.

Suppose you are not skilled in encryption methods or protocols. In that case, consulting a security expert to apply these techniques and better practices while protecting data will prevent a potential security breach from any misstep.

Track Your PAN

You must decide where and how to forward cardholder data. Data such as primary account numbers (PAN) and magnetic stripe data must be securely stored and encrypted. Some of the common places where PAN is sent are:

• Processors
• Backup servers
• Third parties that store/process PAN
• Outsourced system management
• Company offices

Stop Using Early SSL / TLS Versions

HTTPS protocol uses SSL / TLS protocols to encrypt web pages and data entered there. There are many types of SSL / TLS in use. Netscape created SSL for the transmission of private documents over the internet. Later, the Internet Engineering Task Force (IETF) created TLS to provide features similar to SSL.

In order to encrypt data, both SSL and TLS use cryptographic systems. The actual encryption scheme used is negotiated during the SSL / TLS agreement, where the cipher package is chosen, and encryption keys are produced and exchanged. Private keys use asymmetric encryption to replace website certificates with symmetric encryption.

PCI SSC has published a guide stating that you will be moving from SSL to early TLS to stable TLS versions by June 30, 2018.

If your company uses early version SSL / TLS, you can stop and upgrade at the earliest opportunity because there are some errors in these versions’ codes. You can get detailed information by contacting your terminal providers, gateways, and service providers to see if the software and computers you use to have this encryption protocol. Applications using SSL / TLS can include:

• Virtual payment terminals
• Back office servers
• Web/application servers

If you need to continue using SSL / TLS, here are a few tips for protecting your data:

• Upgrade to a new stable TLS version designed not to accept SSL or early TLS backups.
• Encrypt data with strong cryptography before sending it over SSL / early TLS.
• First, set up a strongly encrypted session such as IPsec, then send the data in the secure tunnel.
• Check firewall setups to see if SSL can be blocked.
• Check if both software and system updates have the latest version.
• Test and monitor systems to detect suspicious activity that could indicate a security issue.

The negotiation process must use strong encryption for SSL / TLS to be acceptable to encrypt cardholder data to meet PCI DSS requirement 4. This allows the server to support SSL and TLS versions without well-known vulnerabilities and use strong cryptography-based cipher suites.

The certificate introduces a server’s functionality using HTTPS and the first process of managing the key exchange.

If you have existing SSL and early TLS implementations, you need risk mitigation and migration plan. The guide you will create will help you outline your plans to transition to a secure protocol, as well as the controls you implement to reduce risk.

Block the Eavesdropper

Many potential hackers are intruders trying to exploit known vulnerabilities. PCI DSS includes specific requirements and recommendations for connecting to other systems:

• Continue once you have keys/certificates. These keys or certificates need to be verified and make sure they do not expire.
• Set your systems to use only secure protocols and do not allow network connection requests that use weaker protocols or insufficient key lengths for encryption.
• Apply strong PCI DSS encryption for authentication and wireless network transmission that transmits cardholder data or connects to the cardholder data environment.

Ensure the security of end-user messaging technologies

Most of the PCI DSS requirements are dedicated to securing PANs. PCI DSS Requirement 4 sets out some unique guidelines for the transmission of PANs over open networks. As a result, technologies commonly used by your company, such as end-user messaging technologies, may need to be changed or stopped while cardholder data is being transmitted.

See Also: Email Security Best Practices

The main points of PCI DSS Requirement 4 regarding end-user messaging technologies are as follows:

• PANs should never be sent unprotected through commercial applications such as e-mail, instant messaging, and chat.
• Before using any of the end-user technologies, you must ensure that PANs are rendered unreadable through strong cryptography.
• If a third party requests a PAN, the third party must have a means or system to secure the PAN or make the number unreadable before transmitting.
• It would be best to define appropriate security policies and operating procedures when encrypting cardholder data as part of your network communication process. You must also ensure that all people in your company keep proper documentation up-to-date, available, and tracked.

See Also: PCI Compliance and Email Security

Additional tips for meeting PCI DSS Requirement 4

While complying with PCI DSS Requirement 4, there are a few other things to remember:

• Secure wireless network: Ensure everyone is accessing your wireless network and all endpoints are secure.
• Update keys and certificates: Ensure your security certificates are up to date and your encryption keys are appropriately protected.
• Work with your service providers: Make sure your service provider follows the appropriate protocols to make sure your data is safe.
• Educate employees: Make sure your employees know what to fix and what type of web encryption will no longer be used.

Keeping your data secure while it is stored, processed, and transmitted is crucial. To protect data, make sure that web encryption is safeguarded and all potential vulnerabilities are reduced.