In 2015, I published an addendum to our PCI DSS 4th Ed. book that covered version 3.1. I titled it, “PCI DSS 3.1: The Standard that Killed SSL” because that version removed the ability to use old and outdated versions of the standard in favor of the improved TLS standard originally released in January 1999. Now eight years later, we’re still struggling with moving past version 1.0 of TLS, something that the Council required after June 2018. Outdated versions of these protocols still exist in certain embedded devices, and are only allowed in limited scenarios.

Freedom, by Dazzie D

Version 4 of the standard pushed the remainder of TLS version requirements to your routine vulnerability scans—prioritized by the resulting CVSS score. You will find only a single reference in the twelve requirements (it’s in the guidance section of 4.2.1) and specific guidance on outdated TLS in Appendix A2 to be used in extremely limited scenarios. Encryption is all over the standard (found on more than 40 pages), but the specifics are pushed out to a more real-time threat landscape.

PCI DSS requires that scan vendors properly scan for and identify vulnerable versions of SSL and TLS while coding them properly for remediation. Specifically1See the ASV Program Guide., ASVs must:

  • Catalog protocol versions, encryption algorithms, signature signing algorithms, and key strengths,
  • Report on certificate elements like validity, authenticity, and expiration date, and
  • Check for common name mismatches (a valid certificate installed on the wrong domain/URL).
Swiss Army Knife, by xjara69

What this means for someone complying with PCI DSS is you must be on top of your configurations, library versions, customer usage (so you don’t turn off a customer by changing an algorithm or version), internal defenses (such as proxying via TLS Peeking), and certificate validity. Small shops may be able to manage this manually, but larger shops (such as DigiCert) can benefit from a third party vendor to manage trust for them2DigiCert provides a TLS Cert for this blog..

TLS management is an IT function that is backed and checked through security policies and procedures. Operationalizing it as such will ensure you maintain high security (confidentiality/integrity) while keeping systems up and running (availability).

Enterprises who need to manage TLS should look for (at a minimum) vendors that can do the following:

  • Manage the lifecycle of certificates (issuance, production, revocation), and provide guidance on re-issue where required,
  • Discover certificates that do not meet enterprise requirements (non-internal CAs, self-signed certificates, or certificates that come from public CAs you do not use) and provide automated reporting to first responders,
  • Automate installation,
  • Ensure certificates are not on the verge of expiration which may cause an outage, and
  • Cover more than just websites, but anywhere you might want to secure communication using TLS (like with VPNs or eMail).

Following this guidance will ensure you do not run into challenges with your QSA over encryption, and elevating a rapid response team to address issues found in ASV scans will maintain your compliance with PCI DSS.

This post originally appeared on BrandenWilliams.com.

Possibly Related Posts:


0