Skip to main content

PCI Compliance Every Day – Requirement 4

March 07, 2018

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.


    Jeff Hall

By: Jeff Hall

Principal Security Consultant

See More

Related Blogs

June 08, 2018

The Business Trusts the Third Party – Should You?

In this day and age we are faced with some hard facts within information security. One of those facts is that breaches are imminent and we must be pre...

See Details

February 06, 2018

What Is SSL Web Inspection and Where Should It Occur? (Part 3)

In parts one and two of this blog series, I provided an overview of SSL web inspection, and dove deeper into how SSL inspection solutions work and met...

See Details

January 29, 2018

What Is SSL Web Inspection and Where Should It Occur? (Part 2)

Hardware will vary between vendors and even different models within a vendor’s catalog. Some models/vendors will offload complex CPU tasks (decryption...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.


Privacy Policy

RELATED INSIGHTS

September 19, 2017

Governance Risk and Compliance Services

Optiv works with your organization to optimize its investment in RSA Archer.

See Details

February 24, 2015

Encryption: The Solution to Corporate Breaches?

In the aftermath of recent breaches, the discussion has centered around encryption of data, more specifically, data at rest, when data resides in the ...

See Details

July 25, 2017

Identity and Access Management Program Primer

Learn how to create an identity and access management maturity roadmap tailored for your organization.

See Details

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.

Subscribe

Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cybersecurity Events in your area.