[author: Ty Shipman]
The Payment Card Industry Data Security Standard (PCI DSS) includes nearly 400 individual controls. We find that companies considering PCI are often caught off guard by the completeness of PCI DSS. So, we thought we would help!
CompliancePoint’s PCI blog series will analyze each of the 12 requirement families. We’ll outline the common challenges our customers face with each requirement, answer a few frequently asked questions, and finally, provide some pro tips.
This week we will tackle Requirement 4: Encrypt transmission of cardholder data over open public networks.
Requirement 4: Encrypt transmission of cardholder data over open public networks.
What does this requirement require at a high level?
Essentially, this requirement concerns the protection of the following data as it circulates on open public networks:
- Cardholder data (CHD)
- Card number
- Sensitive Authentication Data (SAD)
- 3 or 4 digit card verification code
- Authentication PIN
- Dragged track data
- Pin-Blocks for cards
So what is an open public network? Examples include:
- The Internet
- Wi-Fi hotspot in a favorite home, office or cafe
- Mobile phone system
- Mobile payment technology (Apple Pay, Google Pay, Samsung Pay)
- Other communication technology based on radio waves
However, the following are not Open public networks:
- Point-to-point or site-to-site VPN connections 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 in accordance with 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 in progress.
To secure CHD and SAD over open public networks, PCI DSS v3.2.1 specifies that you must use strongly encrypted network protocols (like TLS 1.1 or newer, no SSL) and powerful cryptographic algorithms. In addition, DSS requires that strong encryption be used during authentication when wireless devices are part of the CHD and SAD data path (for example, wireless payment terminals used in restaurants, bars and Apple Stores).
Finally, DSS prohibits sending CHD and SAD through any messaging system – email, SMS, chat, etc. Why ? These services capture, store, or log the data sent, and DSS prohibits CHD from being stored in clear text. And SAD should never be stored in a registered form unless you are a bank.
Why is meeting this requirement important (beyond certification)?
It’s all about trust. Card associations (Visa, Mastercard, American Express, Discover, JCB) and their member banks have spent billions of dollars promoting the use of credit cards as a secure way to shop online and in stores. physical stores. To protect their customers, cardholders and the revenue they generate, card associations have adopted PCI controls that require online merchants (e.g. Amazon) and online service providers (e.g. PayPal ) to participate in the protection of 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.
Since the first version of PCI DSS, circa 2004, there have been requirements and controls that address the need to encrypt CHDs and SADs on open public networks. Requirements and controls have evolved as threats have evolved, and version 3.2.1 specifies that Transport Layer Security (TLS) version 1.1, 1.2, or 1.3 should be used with powerful cryptographic algorithms like AES 256 to protect CHD and SAD. And this is where part of the challenge lies.
Common challenges and tips for success:
- Avoid weak network security protocols.
- Configure all APIs, load balancers, and web servers to redirect all unencrypted traffic, for example, HTTP to HTTPS, FTP to SFTP. This is a requirement for all services that manage CHD and SAD, but today it should be done for every page and API in order to prevent attacks on a website and damage the reputation of the business.
- Configure the server to only allow TLS 1.2 and 1.3. Why drop 1.1? TLS 1.1 has a few security holes, when combined with weaker ciphers it allows attackers to decrypt traffic. You can use 1.1 through DSS v3.2.1, but this QSA advises you to deprecate its use in the future.
- Avoid weak or compromised cryptographic algorithms.
- All crypto algorithms are not created equal and do not stand the test of time. Over the years, many cryptographic algorithms have been attacked and deemed too weak to protect CHDs and SADs. You must configure the server to support only strong cryptographic algorithms.
- I am not an expert in cryptography. How do I determine if my server is configured correctly?
- Truth be told, many valuers and QSA are not crypto experts. We rely on tool sites such as HTTPS://sslabs.com/ssltest and HTTPS://testtls.com to help us determine if a server is properly configured and meets monitoring 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 local host. But I won’t be referring to these scripts here as you need to inspect them before use to avoid loading and running a Trojan on your local machine. If you are able to inspect, you can easily find the scripts.
- Each of the sites referenced above describes something different about how to configure a server for security. Use them both. Pay special attention to the HTTP redirect section, protocols offered, and cipher suites offered by a server. Disable all weak, faulty, or compromised SSL, TSL 1.0, 1.1 and cipher suites. Run the test again to make sure that the new configuration is in place on all servers and load balancers.
- Do the remediation carefully. Disabling certain cipher suites and TLS 1.1 may result in relocation of clients due to browser compatibility limitations. Check the compatibility of the browsers listed in the security report against the server visitor log before making any changes.
- Citing evidence
- Tell the QSA a story about how CHD and SAD are secure 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 display the “padlock” symbol in the browser bar and the certificate issued by the chosen user honorable Certification authority. Provide a drawing showing where the public TLS termination occurs (load balancer, web server, application server), so the QSA knows which configuration (s) to examine.
Your site, your company’s reliability and reputation are at stake. Protecting CHDs and DASs helps build trust and shows that you care about your customers’ data, their CHDs, and personal account data ( PAD). The best way to do this is to test your configurations against the PCI DSS controls in Requirement 4.