PCI DSS Blog Series – Requirement 4

The Payment Card Industry Data Security Standard (PCI DSS) consists of nearly 400 individual controls, and is a critical part of staying in business for any merchant, service provider, or subservice provider who is involved in handling cardholder data. We find that companies considering PCI are often caught off guard by how comprehensive the PCI DSS is. So, we thought we would help!

CompliancePoint’s PCI blog series will analyze each of the 12 Requirement families. We will outline common challenges our customers face with each requirement, answer some frequently asked questions, and finally, we will provide some pro tips on becoming PCI DSS Certified.

This week we will address Requirement 4: Encrypt transmission of cardholder data across open, public networks.

Requirement 4: Encrypt transmission of cardholder data across open, public networks.

What does this requirement require at a high level? 

In essence, this requirement is about protecting the following data as it travels across Open Public Networks:

• Card Holder Data (CHD)
• Card Number
• Sensitive Authentication Data (SAD)
• 3- or 4-digit Card Verification Code
• Authentication PINs
• Swiped Track Data
• Dipped Card Pin-Blocks

So, what is an Open Public Network? Examples include:

• The Internet
• Wi-Fi Access Point in a home, office, or favorite coffee shop
• Mobile Phone System
• Mobile Payments Technology (Apple Pay, Google Pay, Samsung Pay)
• Other radio wave-based communications technology

In contrast, the following are not Open Public Networks:

• Point-to-Point or Site-to-Site VPN connections being transited over the Internet
• Private data links from a cloud service provider to a colocation
• HTTPS connections between a consumer’s browser and a server configured according to the PCI Data Security Standard(DSS) 3.2.1.

It is important to protect CHD and SAD to prevent bad actors from eavesdropping and capturing credit card data while an online purchase is being completed.

To secure the CHD and SAD over Open Public Networks, PCI DSS v3.2.1 specifies that you must use strong encryption network protocols (like TLS 1.1 or newer, no SSL) and strong cryptographic algorithms. In addition, the DSS requires that strong encryption be used during authentication when wireless devices are part of the CHD and SAD data path (e.g., wireless payment terminals used in restaurants, bars, and Apple Stores). 

Lastly, the DSS forbids CHD and SAD from being sent over any messaging systems – email, SMS, chat, etc. Why? Those services capture, store, or log the data sent, and the DSS forbids CHD from being stored in clear text. And SAD is never to be stored in any recorded form unless you are a Bank.

Why is compliance with this requirement important (beyond getting certified)? 

It is all about trust. The Card Associations (Visa, Mastercard, American Express, Discover, JCB) and their members’ banks have spent billions of dollars promoting credit card use as a safe way to make purchases online and in brick-and-mortar stores. To protect their customers, the cardholders, and the revenues they generate, Card Associations adopted PCI controls that mandate online merchants (e.g., Amazon) and online service providers (e.g., PayPal) to participate in protecting CHD and SAD by encrypting them with strong cryptography and modern network security protocols when these types of data are sent over Open Public Networks.

Beginning with the first release of PCI DSS, circa 2004, there have been requirements and controls that address the need for encrypting CHD and SAD over Open Public Networks. The requirements and controls have evolved as the threats have evolved, and version 3.2.1 specifies that Transport Layer Security (TLS) version 1.1, 1.2, or 1.3 must be used along with strong cryptographic algorithms like AES 256 to protect CHD and SAD. And therein lies some of the challenge.

Common Challenges & Tips for Success:

1. Avoid weak network security Protocols.
   • Configure all API, load balancers, and web servers to redirect all non-encrypted traffic, e.g., HTTP to HTTPS, FTP to SFTP. This is a requirement for all services that handle CHD and SAD, but today it should be done for every page and API to prevent attacks against a website and damage the company’s reputation.
   • Configure the server to only allow TLS 1.2 and 1.3. Why drop 1.1? TLS 1.1 has some security flaws, when combined with weaker cyphers allow attackers to decrypt the traffic. You can use 1.1 per DSS v3.2.1 but this QSA advises that you deprecate its use going forward.
2. Avoid weak or compromised cryptographic Algorithms.
   • Not all cryptographic algorithms are created equal, nor do they withstand the test of time. Over the years, many cryptographic algorithms have fallen victim to attacks and have been determined to be too weak to protect CHD and SAD. You must configure the server to support only strong cryptographic algorithms.

Common Questions:

1. I am not a cryptographic expert. How do I determine if my server is configured correctly?
   • Truth be told, many assessors and QSAs are not cryptographic experts. We rely on tool sites such as HTTPS://sslabs.com/ssltest and HTTPS://testtls.com to help us determine if a server is configured correctly and meets the controls requirements. This is especially true when it comes to detecting poisoned or broken certificate chains and weak or compromised cryptographic algorithms. There are also various downloadable scripts that will test a site and internal servers from a locally owned host. But I will not reference those scripts here because you must inspect them before use to avoid loading and running a trojan on your local computer. If you are able to do the inspection, you can find the scripts easily.
   • Each of the sites referenced above describes something different about the security configuration of a server. Use them both. Pay close attention to the HTTP redirect section, protocols offered, and cipher suites offered by a server. Disable all SSL, TSL 1.0, 1.1, and weak, flawed, or compromised cipher suites. Run the test again to make sure the new configuration is in place on all servers and load balancers.
   • Do the remediation with care. Disabling some cipher suites and TLS 1.1 may cause customers to be displaced due to browser compatibility limits. Check the browser compatibilities listed in the security report against the server’s visitor log before making changes.
2. Citing evidence
   • Tell the QSA a story about how CHD and SAD are secured in transit over Open Public Networks. Show how the server(s) are configured. Provide the output from ssllabs.com and testtls.com. Take screenshots of a browser visiting the site(s) that show the ‘lock’ symbol in the browser bar and the certificate issued by the chosen reputable Certificate Authority. Provide a drawing showing where the public TLS termination happens (load balancer, web server, application server), so the QSA knows what configuration(s) to examine.

Conclusion

Your site and your company’s trustworthiness and reputation are on the line. Protecting CHD and SAD helps to build trust and show that you care about your customers’ data, their CHD, and Personal Account Data (PAD). The best way to do that is to test your configurations against the PCI DSS controls in Requirement 4.

Check Out Other Posts in this Series

• PCI DSS Requirement 1: Install and maintain a firewall configuration to protect cardholder data
• PCI DSS Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• PCI DSS Requirement 3: Protect stored cardholder data
• PCI DSS Requirement 4: Encrypt transmission of cardholder data across open, public networks
• PCI DSS Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
• PCI DSS Requirement 6: Develop and maintain secure systems and applications
• PCI DSS Requirement 7: Restrict access to cardholder data by business need to know
• PCI DSS Requirement 8: Identify and authenticate access to system components
• PCI DSS Requirement 9: Restrict physical access to cardholder data
• PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data
• PCI DSS Requirement 11: Regularly test security systems and processes
• PCI DSS Requirement 12: Maintain a policy that addresses information security for all personnel

CompliancePoint is a Qualified Security Assessor Company (QSAC). Our consultants have decades of experience as practitioners and auditors. Please reach out to us at connect@compliancepoint.com if you have any questions about this requirement or how CompliancePoint can assist your organization with preparing for your PCI DSS Certification.