In part 1 of this blog series, we explored objective standards for evaluating application cipher suites using the National Institute of Standards and Technology (NIST) standard. Reviewing that is not required to continue here. For those of us lucky enough to apply cryptology within a Payment Card Industry (PCI) context, this part is for you.

There are considerations unique to PCI.

For your self-assessments and QSA lead assessments, are you certain that scoping and encryption are compliant? Will your QSA and/or your Approved Scanning Vendor (ASV) agree with your stance?

To start, let’s identify the relevant controls. What has the PCI Security Standards Council (PCI-SSC) said within the Data Security Standard (PCI-DSS)? Let's look at current version 3.2.1. The transport of cardholder data has controls described within requirement 4.1, and the most crucial testing of the use of secure transport is within requirement 11.2 for ASV scanning.

Requirement 4.1 requires ‘strong cryptography and security protocols’ but does not state what qualifies as strong. Official PCI-DSS guidance notes that, '...some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities...'

Great, so don’t use SSL, SSH v1, or early TLS. But what is early TLS? Related to that, if I am using ‘modern’ TLS, can I do whatever I want?

The PCI-SSC recently provided some clarity in an FAQ (January 2021, article Number 1491 https://www.pcisecuritystandards.org/faqs). It says that industry references such as NIST SP 800-52 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf) should be reviewed to meet the intent of strong cryptography. This guidance is helpful, because revision 2 is from August 2019 and is much newer than the current PCI version 3.2.1. It is also verbose and specific about acceptable cipher suites.

Let’s address the PCI-DSS scoping specific to the upcoming version 4.0. In the current version of the PCI-DSS, encryption is not needed to transport cardholder data within trusted networks. Yes, this relies on dated views of perimeter security and is not a best practice. Yes, this is highly likely to go away in the upcoming major PCI-DSS version 4.0. I highly recommend you encrypt your cardholder data within trusted networks. That said, you are compliant without encrypting it for now.

Just be sure that any encryption used for cardholder data does not expose the password (I see you, Telnet and FTP) as that is not compliant, even in trusted networks where encryption is not required at all!

With trusted network scoping understood, what about the public untrusted network? Even here, any application that is not transporting cardholder data might be removable from scope. This becomes a slightly deeper topic that takes into consideration variables such as server application dedication, encryption termination point, DMZ configuration, and network segmentation. Network segmentation is not required for PCI compliance.

If you have architected a less secure non-payment application away from being in scope with PCI applications, you may consider excluding it from the test reports required for 11.2. This is the scanning required from an ASV where an Attestation of Scan Compliance needs to be sought every 90 days. Proving that your application requires a narrower PCI scope than the entire set of public applications will typically save time and effort.

These were just two of the most commonly discussed topics when it comes to transport cryptology. Is there a different topic you'd like to discuss or learn about? Join us on Discord to share any thoughts or questions.