PCI Requirement 4 states, “Encrypt transmission of cardholder data across open, public networks.” We’ve covered cryptography standards, wireless networks, and end-user messaging technologies to help prepare you to meet this requirement. Complying with PCI Requirement 4 will help prevent your organization from being a target of malicious individuals who exploit the vulnerabilities in misconfigured or weakened wireless networks. But it’s not enough just to learn and talk about these things; all policies, procedures, and standards must be implemented in order to comply with PCI Requirement 4 and to securely transmit cardholder data.

Requirement 4.3 states, “Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.” This is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and procedures need to be known and in use by all relevant parties. Your personnel must be living out what the policies, procedures, and standards require of them. It is a requirement of this framework that the affected parties use the policies and procedures. It is not sufficient that you generate documentation just for the sake of the audit. Your assessor should be reading these documents, familiar with the policies and procedures, and interviewing staff to make sure that anybody who is subject to the policies and procedures understands what they are.

In Requirement 4.3, we once again come to the capstone of Requirement 4. This capstone requires that you maintain a documentation program and that all individuals who are subject to these policies are knowledgeable of them. These policies and procedures need to be actually in use. Your assessor should be reading these policies, familiar with these policies, and interviewing staff to make sure that anybody who would be subject to these policies understands what they are.

If there are situations within your organization when you need to send or receive emails that contain sensitive cardholder data information like Primary Account Numbers (PAN), that is acceptable as long as you’re in compliance with PCI Requirement 4.2. It states, “Never send unprotected PANs by end-user messaging technologies.” This includes through email, instant messaging, chat systems, SMS, etc.

The purpose of PCI Requirement 4.2 is to protect sensitive information from attackers, hoping to intercept this data during delivery across internal and public networks. There’s nothing in the PCI DSS that prohibits you from sending PAN through email or messaging, but the PCI DSS does state that the information must be protected.

Even if the cardholder data is being sent somewhere internal, it is still required that the sensitive information be securely transmitted. Even if you receive an unencrypted email containing cardholder data, you cannot re-transmit that information without protecting it. It’s best to have a policy that states you will not send cardholder data over end-user messaging technologies. But, if you need to send PAN over end-user technologies as part of your business model, then the policy needs to state how the information is protected. The PCI DSS also states, “If an entity requests PAN via end-user messaging technologies, the entity should provide a tool or method to protect these PANs using strong cryptography or render PANs unreadable before transmission.”

Your assessor should be looking in all places where you are or could transmit cardholder data, like PANs, to observe the sending and receiving process. The assessor should also, “Examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.” As always, the assessor needs to review policies and procedures to ensure that a policy regarding end-user technologies exists and that the policy is implemented.

There might be situations within your organization when you need to send or receive emails that contain cardholder data information. There’s nothing in the PCI DSS that really prohibits you from doing that, but there is a prohibition for sending that information unprotected. Even if you’re sending cardholder data internally into your own environment, it’s still required that any time you use an end-user messaging protocol, that information be transmitted securely. As part of that, your assessor, once again, should be looking for all places and all mediums where you’re transmitting this cardholder information. If there’s a call center, we often see organizations receiving emails. There’s nothing that you can do about receiving an unencrypted email. However, if you’re going to be re-transmitting that email, it would be required that you transmit it securely or that you encrypt that data prior to transmission.

Ideally, it’s best just to have a general policy that says you will not transmit cardholder information over end-user messaging protocols or solutions. However, if you do need to do that as part of your business model, it’s acceptable to do that. You just need to make sure you’re using strong encryption when it’s transmitted.

Wireless networks are a part of our everyday technology environment. It’s almost impossible to get away from it, be it your cell phone, laptop, watch, tablet, television…the list goes on and on. Wireless networks are extremely prevalent to our culture. Think about how many restaurants you go to that have table side payment. How does your payment get processed? Over a wireless network. That’s where PCI Requirement 4.1.1 comes into play. It states, “Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment use industry best practices to implement strong encryption for authentication and transmission.”

Wireless networks that use strong cryptography make it less likely for an attacker to eavesdrop on the network’s communications or to compromise the network. Industry best practices must be in use to ensure that appropriate encryption methodology and strength are implemented. An example of weak encryption would be WEP; this doesn’t mean you can’t use WEP within your environment, but you cannot use it to protect information in transit.

The best way to prepare for a PCI Requirement 4.1.1 assessment is to review all documentation related to wireless networks. Documentation should identify all wireless networks where cardholder data is transmitted, received, or connected in some way. Then compare your documentation to your system and verify that industry best practices for cryptography and strong cryptography is used in those places.

Wireless is part of our everyday technology environment. It’s almost impossible to get away from it, be it your cell phone or laptop or any other numerous devices. The Internet of things is rather prevalent. You go to a restaurant nowadays and they have the tableside payments that are transmitting cardholder data over wireless.

As part of this, we want to make sure that if you’re transmitting cardholder data over wireless technologies, that you’re using an industry-accepted protocol for doing so. To give an example, WEP has been deprecated for some time. That doesn’t mean you can’t use WEP within your environment; it’s that you cannot use WEP as a means for protecting that information over the transmission of that medium. So, when we look at 4.1.1, make sure that you’re using strong cryptography for protecting that data whenever it’s transmitted over an open or public network, specifically to this requirement, with wireless.

If your organization transmits sensitive cardholder data over an open or public network, that data must be encrypted using strong cryptography and security protocols, according to PCI Requirement 4.1. Examples of open, public networks include the Internet, Bluetooth, cell phones/GSM, wireless Internet, etc. The purpose of this requirement is to prevent attackers from obtaining data while in transit, which is a common practice.

Best practices for safeguarding sensitive cardholder data during transmission include:

• Only use trusted keys and certificates associated with the encryption. If a certificate has expired or is not issued by a trusted source, do not accept it.
• Any security protocols in use should only support secure versions or configurations; if not, the known vulnerabilities of a protocol could be exploited by an attacker. This also prevents an insecure connection. Any connection that could result in an insecure connection cannot be accepted. An example of an insecure protocol is WEP, which cannot be used for security.
• The encryption strength is appropriate for the encryption methodology in use.
• Documentation should define all places where cardholder data is transmitted or received over open, public networks.
• Documentation should outline a process for acceptance of trusted keys and certificates, how the implemented security protocols only support secure versions or configurations, and why the encryption strength is appropriate.

If you’re going to be transmitting cardholder data over an open or public network (this would be the Internet, wireless, GSM, cell phone, Bluetooth), we expect that the data be encrypted. There’s multiple ways that we look for doing that. For example, you wouldn’t be using an insecure wireless protocol such as WEP. You can use WEP, but WEP cannot be used as a means of security. We look to make sure you have the keys or the certificates that are associated with the encryption, and that they be trusted and secure.

The assessor should take time, when looking at your network documentation, to make sure that it defines all places where cardholder data is transmitted in and out of your network. As part of that, they’re going to be looking at how you’re protecting that information as it departs your environment or your control. So, Requirement 4.1 looks to make sure that you have strong cryptography or strong encryption any place that cardholder data is transmitted over open or public networks.