PCI DSS: SSL Certificate Management Requirements | Keyfactor - Security Boulevard

PCI DSS: SSL Certificate Management Requirements | Keyfactor

For IT and security teams, compliance ranks at the top of the priority list. If you’re responsible for handling key and certificate management in your organization, you know this all too well. 

PCI DSS is one of the most common and widely adopted compliance mandates. Basically, if your organization accepts credit or debit as a form of payment, then PCI DSS applies to you. The good news is that most of the 12 PCI DSS requirements are just common sense security controls you should already have in place. 

In this blog, we’ll cover PCI DSS, how it has changed, and how to map PCI DSS SSL certificate requirements against your key and certificate management practices.


PCI DSS: What it is, why it matters

The Payment Card Industry Data Security Standard (PCI DSS) is a set of rules and requirements to protect sensitive cardholder data credit and transactions and facilitates the broad adoption of consistent data security measures. 

The standard provides a baseline of technical and operational requirements designed to protect financial data. The goal of the PCI DSS is to protect cardholder data and sensitive authentication data wherever it is processed, stored, or transmitted.

PCI DSS applies to all organizations involved in credit card processing, including merchants, processors, acquirers, issuers, and service providers. The standard is managed by an independent body, known as the PCI Security Standards Council (SSC), created by Visa, MasterCard, American Express, Discover, and JCB.

Here is a quick overview of the 12 core compliance requirements outlined in PCI DSS:

PCI DSS Requirements


Where SSL/TLS Certificates & Keys Fit Into PCI DSS

The purpose of the PCI DSS is to strengthen controls on cardholder data to reduce credit card fraud. PCI DSS provides a layer of protection for card issuers by requiring merchants to comply with minimal security levels when storing, processing, and transmitting cardholder data. 

Keys and digital certificates play a vital role in achieving and maintaining compliance with PCI DSS. These cryptographic assets are used to secure data, keep communications safe and private, and establish trust between communicating parties – but they too must be secured and managed appropriately to ensure PCI compliance.

Let’s break down some of the core PCI DSS requirements for managing SSL/TLS certificates in your environment.

Requirement 2.3: Encrypt all non-console administrative access

If strong authentication and encrypted communications are not implemented, sensitive operational or privileged account information could be intercepted, for example, by a man-in-the-middle attack. A malicious actor could then use this information to access the corporate network and steal or compromise financial data. To establish “strong cryptography,” PCI DSS requires the use of industry-recognized protocols with appropriate key strengths and key management (see NIST SP 800-52 and SP 800-57). 

Core capabilities:

  • Centralized visibility of key strengths, algorithms, and protocols in use
  • Policy-based workflows to issue, provision, renew, and revoke keys and certificates
  • Automated key and certificate lifecycle handling

Requirement 2.4: Maintain an inventory of system components

This provision stresses visibility across all system components, including keys and certificates. Maintaining a current list of all keys and certificates enables an organization to accurately and efficiently define the scope of its environment. Failure to maintain an inventory will result in rogue, expired, and untracked certificates. This causes significant outages, or worse, security breaches. However, most organizations are unaware of how many keys and certificates are actively used across their network, often relying on manual, error-prone internal scripts or manual spreadsheets.

Core capabilities:

  • Discovery of certificates across all network endpoints, applications, certificate authorities (CAs), key and certificate stores
  • Reporting and alerting on rogue, expired, or non-compliant certificates

Requirement 5: Protect all systems against malware

While this requirement is focused on network-based protection (i.e. anti-virus, anti-malware) to protect machines against malware, modern malware campaigns have increasingly targeted sensitive machine identities, such as SSH keys, SSL/TLS and code-signing certificates. Cybercriminals and advanced persistent threat (APT) groups leverage these keys and certificates to impersonate trust and bypass defenses

Core capabilities:

  • Continuous monitoring of key and certificate inventory for anomalies
  • Adequate private key generation and storage policies
  • Strong access controls and hardware-based protection of code-signing keys
  • Policy-based workflows for SSH key creation, deployment, and rotation

Requirement 7.1: Limit access to system components

PCI DSS requires that organizations restrict access to systems and cardholder data, which includes limiting access to privileged user IDs and credentials, including keys and certificates. Enforcing least-privilege restrictions on the use and access to your cryptographic assets will limit the scope of damage caused by unauthorized access. Without adequate protection, attackers can leverage trusted keys and certificates to elevate privileges and move laterally between machines.

Core capabilities:

  • Role-based permissions for the issuance and use of keys and certificates
  • Automated monitoring and remediation of unauthorized keys and certificates

Requirement 8.6: Identify and authenticate access to system components

Finally, Requirement 8.6 is related to the function of authentication provided by certificates. Certificates enable simple and powerful authentication, but they must be assigned to an individual account or user, not shared. Having controls to uniquely identify the owner of a key or certificate (and terminate or change ownership should they leave) will prevent unauthorized users from gaining access using a shared authentication mechanism.

Core capabilities:

  • Ability to assign and track ownership of keys and certificates
  • Ability to easily search and revoke certificates in your inventory

Changing SSL/TLS Protocol Requirements

Whether you’re directly involved in the management of SSL/TLS certificates or not, it’s important to understand the need for web encryption and how it affects your business. 

It’s also important to understand why the encryption protocols we rely on today will inevitably be insecure in the future. How do we know this? Because vulnerabilities in SSL and early TLS protocols have resulted in numerous exploits, such as Heartbleed and POODLE. Hackers seek to exploit these outdated protocols to infiltrate networks and compromise sensitive cardholder data.

As a result, PCI DSS requirements for SSL/TLS have changed to keep pace. Here we’ll take a look at how requirements for SSL/TLS migration have advanced from PCI DSS v3.0 to PCI DSS v3.2 today.

PCI DSS v3.0

When PCI DSS v3.0 came into effect on 1 January 2014, the document highlighted that “some protocol implementations (such as SSL v2.0, SSH v1.0 and TLS 1.) have known vulnerabilities that an attacker can use to gain control of the affected system.” However, there was no requirement to use more up-to-date protocols.

PCI DSS v3.1

Soon after PCI DSS v3.0 came into effect, the new PCI DSS v3.1 was introduced in April 2015. A key component of the new version was stricter requirements around the use of TLS.

The new version mandated organizations to disable SSL 3.0 and earlier versions of TLS (1.0) by 30 June 2016. However, the deadline was later postponed to 30 June 2018.

PCI DSS v3.2

The most recent version is PCI DSS v3.2 (as of the date this blog was published). Version 3.2 was introduced in April 2016 and officially replaced version 3.1 on 1 February 2018 as the standard that must be followed.

The new deadline of 30 June 2018 was included in PCI DSS v3.2, which required migration to TLS 1.1 or later, with the exception of some payment terminals (POIs).

What to Expect in PCI DSS v4.0

PCI SSC has begun developing PCI DSS v4.0, with a final version currently expected by mid-2021. The new version is projected to be an outcome-based document, changing the language from “must implement” to “the outcome is.” It will also place greater emphasis on security as a continuous process that integrates with an organization’s overall security and compliance posture.

Other changes will include:

  • Authentication, specifically consideration for the NIST MFA/password guidance
  • Broader applicability for encrypting cardholder data on trusted networks
  • Monitoring requirements to consider technology advancement
  • Greater frequency of testing of critical controls

The Importance of Certificate Lifecycle Automation

If even one key or certificate is compromised, digital trust in your organization is undermined. Despite the growing problem, most organizations still use internal scripts or manual spreadsheets to keep track of their keys and certificates. Security teams lack the visibility and automation needed to stay ahead of potential outages, security incidents, and most importantly. and audit requirements.

The problem is multiplied by the sheer number of keys and certificates in the enterprise today, as modern multi-cloud environments introduce thousands more into the mix. This hybrid infrastructure also creates a greater attack surface, increasing the risk of credit card data being stolen or compromised.

Traditional approaches to key and certificate management simply cannot keep pace with the rapid growth and changes in these new DevOps and multi-cloud deployments. A new approach is needed, one that allows your organization to automate and scale while maintaining full control over the lifecycle of keys and certificates – wherever they live.

An automated approach to cryptographic identities and authorizations over credit card data is a crucial step in meeting and maintaining PCI DSS compliance. PCI DSS emphasizes that compliance should be the organization’s business-as-usual security strategy. 

To provide business-as-usual security policies, fully automated key and certificate management is a must-have for end-to-end provisioning of encryption in the modern financial sector. Automation eliminates the vulnerabilities created by error-prone and time-consuming manual processes and provides at scale. It also allows for fast remediation, so that errors and oversights do not become a significant breach or outage.

Gain Control of Your Keys & Certificates

Find out why Fortune 500 leaders in banking and financial services trust Keyfactor to support their PCI compliance initiatives and provide end-to-end PKI and certificate lifecycle automation.

Learn More

*** This is a Security Bloggers Network syndicated blog from PKI Blog authored by Ryan Sanders. Read the original post at: https://blog.keyfactor.com/pci-dss-ssl-certificate-requirements

Ryan Sanders

Ryan Sanders is a Toronto-based product lead with Keyfactor, a leader in providing secure digital identity solutions for the Global 2000 Enterprises. Ryan has a passion for cybersecurity and actively analyzes the latest in compliance mandates, market trends, and industry best practices related to public key infrastructure (PKI) and digital certificates.

ryan-sanders has 18 posts and counting.See all posts by ryan-sanders