Encrypt cardholder data in transit. PCI-DSS Requirement 4 recommendations.

credit cards

On Internet, when protecting sensitive data, in transit you must use the security protocols you’ve heard of, like HTTPS, SSH, SFTP, FTP/S, TLS, VPN, IPSec and more, however, using only these protocols is not enough when following methodologies like “defense at depth”, where you need more security layers to tackle most of the threats and risks regarding data exposure when sending or receiving data.

In this post I will talk about recommendations you can follow to increase the level of security of critical and sensitive data while transmiting data anywhere, from internal networks to public or insecure networks.

Keep in mind that sensitive data is not only credit card data, it can be personal data, financial information, health information or any information that make your company or entity powerful against your competition or information that your customers trusted you.

Actually, the PCI-DSS requirement 4 can be one of the easiest requirements to comply with but it depends on the infrastructure you have. The most frequent protocols used for this purpose are TLS, SSH and VPNs. Almost every transmission protocol can be tunneled over one of these three methods. You can use FTP over a TLS channel, SMTP over TLS or of course HTTP over TLS (HTTPS), so if you use HTTPS, FTP/S or SMTP/S with a good TLS protocol configuration in all of your networks and you will be in compliance with this requirement.

Thing you need to consider when using TLS for securing communications:

  • An acceptable TLS version.
  • Only the secure cipher-suites are allowed.
  • x.509 certificates issued by an approved Certification Authority (CA) and within the validity period.
  • Avoid TLS 1.0, RC4, DES or 3DES, SHA-1, DH or RSA with a key length of 1024 bits in cipher-suites and versions.
  • Also try not to use self signed-certificates because you will need to justify why you didn’t use a certificate issued by a well known CA now that there are even completely free well issued certificates like Let’s encrypt or AWS Certificate Manager for cloud apps.
  • You can always check the strength of your HTTPS implementation in one of the links I recommended in another previous post.

However because TLS is widely adopted there are some environments where companies do not respect privacy of TLS and set up the networks to open TLS tunnels and inspect the traffic. They can achive this thorugh the use of root certificates installed on corporate machines and a good proxy configuration.

To protect traffic against this type of environments you need to encrypt the information at a different layer than transport, usually the application layer and the information must be encrypted before you send it thorugh the tunnel, so at the end, the information will have at lease two layers of protection: one in transport layer and one in application layer. If someone (or something) decides to open the TLS tunnel it will face with an application layer encryption.

Of course, for this technique to be useful it will need to have a good key management. You can see an example in a previous post. The basics: if you encrypt or decrypt in an entity outside your control, like in client side, mobile apps, client/desktop apps, never use a symmetric algorithm for encryption. You will need to use asymmetric techniques and algorithms. And if you have control over the encryption and decryption environment (and you only lose control over the communication channel), you can use symmetric encryption.

Also you need to think of key rotation, key generation, distribution especially in symmetric encryption and more.

Going back to PCI-DSS, with these previous recommendations you will have no troubles to accomplish requirement 4.1 of the regulation.

Keep in mind that there is special attention when using public networks during transmission and with public networks I don’t only mean Internet, other networks are also considered public like WiFi, bluetooth, GPRS, GSM, 3G, 4G, Satellite and many more. When using any of these networks I definitely recommend encrypting the message at application layer.

Now that I used the word “WiFi” let’s talk about its security a little bit.

First, you must never forget that WiFi uses the air to transport packets and most of WiFi adapters send and receive the packets in omnidirectional waves so basically we are surrounded by WiFi packets all the time. These packets can be captured by any person with the rigth tools and if the traffic is in cleartext they will see all the data in transit with no restriction. This is an eavesdrop attack, a kind of passive attack where someone can inspect the traffic with no alert to both competent parties.

Also the so called “WiFi password” is not a password to “conect to” the WiFi network. It is a passphrase or text from which it is derive a cyptographic key that will be used to encrypt and decrypt all the packets that your computer or mobile will be sending to the air to communicate with the WiFi access point you want to connect to. So if everyone in the room (or public site) knows the password, basically everyone can get to the same cryptographic key and decrypt your information and the information of anyone else connected to the same WiFi network. And if it was not enough, there are good attacks against WiFi security protocols that can obtain the cyprtographic keys going from seconds to a few hours depending on the complexity of the key and the amount of traffic on the network.

For all these reasons it is highly recommeded, to encrypt the information you want to transmit, again in application layer, before it touches any tranmission mechanism.

Before closing this article I want to mention that if you are not skilled in these encryption methods or protocols I suggest to hire a security specialist even for a few hours to implement these techniques and more best practices while protecting data because any wrong step could lead to a potential security breach.

One thought on “Encrypt cardholder data in transit. PCI-DSS Requirement 4 recommendations.”

Comments are closed.