Announced with a high sense of urgency earlier this year, PCI 3.1 is an unusual update occurring outside the typical three-year lifecycle for PCI DSS, but is it really that unusual for the data security world?
The threat landscape is highly dynamic, and requires continuous updating and monitoring, so why not PCI?
PCI 3.1 is a direct response to vulnerabilities that were discovered in certain implementations of the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols last year. The change was driven by a large amount of publicity around two vulnerabilities in particular: Heartbleed and POODLE, both of which affect SSL/TLS implementations and can put payment data at risk.
Security Continues To Mandate
This compliance change request sits close to the U.S. EMV (Europay, Mastercard, Visa) mandate for October 2015. While POS systems are updated, perhaps during this upgrade process organizations will also begin to implement a later version of TLS.
Compared to SSL, the TLS protocol uses stronger encryption algorithms and has the ability to work on different ports. Established in 1996, TLS is the successor to SSL, ensuring there is no eavesdropping between a server and client.
If encryption is not upgraded criminals can compromise data at the point of sale after EMV is properly deployed; they can’t use that data to make a counterfeit EMV card, but they can focus on breaching e-commerce merchants since the physical card is not required.
It must be noted that TLS is one layer of security for data in transit. Payment data will sit in the POS memory and can be pulled by scraper malware.
Is This A Realistic Deadline?
PCI DSS 3.1 was effective immediately in April. Merchants must remove insecure cryptography (SSL) by June 2016, and any new deployment must be TLS. This is a fourteen-month transition period.
Given the risk factor, these dates are very kind – it goes back to security being the priority. Our experience with customers transitioning to PCI 3.1 is that adopting TLS is not technically challenging, and there are ways to streamline this time-consuming transition.
Best Practices For PCI 3.1 Migration
Here are some considerations based on our experiences with PCI compliance projects:
- Scope the migration. Is there a sense of how much SSL is deployed in your environment? This can be achieved with some tools to find endpoints running SSL, including Tripwire Enterprise’s security configuration management, Tripwire IP360’s vulnerability management and Tripwire Log Center’s security log management.
- Upgrade and replace SSL with TLS. In some cases, this can have significant consequences if it affects other software and infrastructure. Adjustments may be needed.
- Tripwire integrates with service desk systems on the TLS builds needed to help manage the process. Tripwire can also give you on-going progress reports on the effort, and becomes the system of record for continuous compliance.
- More likely you will need to prioritize your migration efforts. The priority criteria might include the likelihood of being compromised given a system’s location or amount of transaction data.
- Start with externally facing systems. External systems are more exposed. Next would be the internal systems with direct card touches (field branch or remote store systems) followed by those systems in scope. Some in scope systems are connected to third-party systems and will require coordination of vendor changes and compliance.
- Overall, the process isn’t necessarily technically challenging as much as it is time consuming. Tripwire can streamline the transition with quick identification, integration with change management, or service systems and on-going monitoring and reporting.
Gain more insight on steps to take for PCI compliance here. How is your PCI 3.1 effort going?