The Payment Card Industry Data Security Standard (PCI DSS) version 3.1 was released in April 2015. Yet, many organizations are still not compliant with the PCI DSS version 3.0, which went into effect on January 1, 2015. Both versions introduced new requirements for cryptographic keys and digital certificates. While businesses may have a variety of reasons for not meeting the compliance requirements pertaining to keys and certificates, it certainly isn’t because the dangers have subsided. In fact, they’re on the rise.
In a recent Poneman Institute report, 100% of the organizations surveyed said they responded to attacks using keys and certificates within the last 2 years. In response to the growing threat, the Payment Card Industry Security Standards Council (PCI SSC) has introduced stringent rules governing the security and management of keys and certificates.
PCI DSS v. 3.1
Just months after PCI DSS v3.0 went into effect, the new PCI DSS v3.1 was released requiring that SSL and early versions of TLS be replaced to prevent man-in-the-attacks like POODLE. Organizations are no longer allowed to use SSL or early TLS with new systems, but have until June 30, 2016 to transition existing ones. This new mandate impacts the PCI DSS requirements that address encryption used to protect card holder data and requires an enterprise-wide transition to TLS version 1.1 and higher on in-scope systems. The process for migration to TLS 1.1 and higher can be summarized in two steps:
Step 1: Search and Triage
Find online applications. Can be performed by scanning network ranges on known ports.
Find applications that operate intermittingly. Can require searching systems for cryptographic keys and digital certificates and mapping back to applications.
Once applications and how cardholder data is processed are known, risk can be established and migration for specific applications can be prioritized.
Step 2: Migration
Migrating to TLS 1.1 and higher will require at least updating the configuration of affected applications. It may also require updating the application to a version that operates only with TLS 1.1 and 1.2.
As migration proceeds, teams should update scans to validate migration. These scans demonstrate progress and compliance, showing SSL, early TLS, and TLS 1.1 and higher usage.
PCI DSS v. 3.0
However, most organizations still need to address the new key and certificate requirements in PCI DSS v3.0 as well. Here are the top regulations with a description of the impact to your organization’s security resources:
New requirement 2.4: Maintain an inventory of all in-scope system components.
This includes all in-scope keys and certificates. But research by the Ponemon Institute shows that 54% of organizations don’t know where all of their keys and certificates are located, who owns them, or how they are used. On average, an enterprise has over 23,000 certificates floating around their network. Hunting down lost keys and certificates can be a long, painful, manual process.
Revised requirement 5 and new requirement 5.1.2: Protect all systems against malware and review periodically to see if protection has become necessary.
PCI SSC wants to stress that even systems not commonly impacted by malware should be periodically assessed to determine if protection has become necessary. Organizations may view keys and certificates as uncommonly impacted by malware, but in truth, keys and certificates have become the attack method of choice. There has been a 700% growth in certificate-enabled malware from 2012 to 2015 according to Intel Security. Without first knowing where your certificates are located, it becomes impossible to protect them from misuse. A centralized platform, inventory, policy enforcement, continuous monitoring, and automated management are needed to keep keys and certificates secure.
New requirement 8.6: Certificates for authentication must be assigned to an individual account, not shared.
Certificates enable strong authentication and PCI SSC wants to ensure their use and access are restricted. This regulation requires that organizations have strict usage policies in place to prevent the ambiguity of overlapping ownership and use.
Business as Usual (BaU) Processes: Security controls for compliance should also be part of the BAU security strategy.
This is the PCI SSC’s way of ensuring that organizations maintain compliance on an ongoing basis. For keys and certificates, this requires that organizations adopt a centralized management and security platform with automated, ongoing monitoring and policy enforcement. Unfortunately, many organizations use legacy, error-prone, manual approaches or home grown scripts that make it difficult, if not impossible, to meet the new PCI DSS requirements governing visibility and security over keys and certificates—at best eating up weeks of time and taking significant resources.
Learn how Venafi is designed to make meeting the new PCI DSS requirements for keys and certificates easy at Venafi.com/PCI.
Last year, Securing Cryptographic Keys and Digital Certificates was a PCI SSC 2015 Special Interest Group (SIG) Finalist. This topic was not selected for 2015, but has been resubmitted for consideration as a 2016 PCI SSC SIG. Want key and certificate security as a PCI SIG? Let the PCI SSC know you’re interested! And drop me a comment if you’d like to participate.