PCI Compliance Every Day – Requirement 4

Encrypt Transmission of Cardholder Data Across Open, Public Networks

In this latest post of my Payment Card Industry Data Security Standard (PCI DSS) compliance blog series, we will explore Requirement 4 of the standard. People look at what this requirement entails and always ask me, “What is in here that has any sort of timing requirement?”

“Interestingly, a lot,” is always my reply.

The following requirements need to be reviewed whenever changes are made to servers or applications, not just when you acquire new certificates or during your annual PCI assessment.

• 4.1.c: Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.
• 4.1.d: Examine keys and certificates to verify that only trusted keys and/or certificates are accepted.
• 4.1.e: Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations.
• 4.1.g: For TLS implementations, examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received.

Why Do the Above?

Because of the issues we encounter with securing communications. All this truly came to a head when the PCI Security Standards Council (SSC) issued their directive a few years ago to kill off security sockets layer (SSL) v3 and Early TLS by June 30, 2018. That event really exposed certificate management issues that have been brewing since certificates were introduced more than a decade ago.

In talking amongst qualified security assessors (QSAs) for many years, we have all encountered issues with website certificates—whether it was weak cyphers, weak signatures, wrong domain, self-signed certificate, even insecure or unrecognized certificate of authority. All QSAs have seen these problems and had to get them addressed. Sometimes that is a painful process because the change can involve having to purchase a new certificate when a certificate was recently renewed or purchased. Never mind the fact that installation of a new certificate can be quite a challenge at times and can result in making a website inaccessible.

What Should You be Doing?

You should be doing the same thing your QSA does during your assessment—testing your certificates. When conducting an assessment, Optiv uses Qualys SSL Labs’ SSL Server Test (https://www.ssllabs.com/ssltest/) to test externally facing websites. While your scans from external approved scanning vendors (ASVs) should be identifying any certificate issues that would affect PCI compliance, most scanners do not provide complete feedback on your certificates in use as provided with the Qualys site.

To use the Qualys site, just enter your URL(s) into the site, click on the ‘do not show the results on the boards’ check box (unless you do want your results publicly published) and click on the submit button to start the testing. The site will go through and test your SSL certificate(s) for all sorts of issues, errors and vulnerabilities. At the end of the test (it usually takes two to three minutes) you will get a report that grades your site’s certificates and gives you a list of any issues/vulnerabilities/errors.

We highly recommend to clients that they conduct such testing of all their websites at least semi-annually, if not quarterly or when changes occur, to ensure that they stay on top of their certificates and ensure their websites’ secure communications. You should save your reports as PDFs with the date run so that you have evidence of the testing to share with your QSA.

Not Just Web Sites

But it is not just your websites that conduct e-commerce. You also need to test sites that conduct secure file transfer of cardholder data (CHD) or any website or use of TLS that is in scope for PCI compliance on which you rely for secure external and internal communications. Many system administration tools use websites to manage their environments. These sites also use certificates (sometimes self-signed) to ensure secure communications between an administrator’s workstation and the management console.

If these sites are not publicly facing, then using a tool like the one from Qualys is probably not going to be an option. Most clients rely on their vulnerability scanner application to test their internal systems. To allow a focus on results, they set up a scan to look only for issues with internal site certificates. But again, those results only flag compliance issues and do not necessarily provide a complete view of the certificates as with the Qualys results. There are some open source tools that can simulate some of the results from the Qualys site such as TestSSLServer (https://github.com/pornin/TestSSLServer/). We cannot attest to the security of and results provided by such open source tools, but in the case of TestSSLServer, it does appear to be secure and provides what seem to be accurate results.

Worst case scenario: You can manually assess your certificates. While that can sound daunting, it is not as bad as you might think. However, if using the manual approach, I would only use it when making changes to sites or certificates as the manual process is not going to disclose the amount of issues that a tool can disclose.  

Using any browser—I prefer Firefox because you can easily export the certificate for later examination—you can click on the “lock” next to the URL indicating HTTPS is invoked. From there you can drill down to a point where you can view the certificate. When viewing the certificate, you can review the security parameters being used for your session as well as some of the public aspects of the certificate such as issuer and signatures.

Now you should know what to look for on a periodic basis with your certificates.