Our Thinking

SSL/TLS Migration Time - Don’t get caught SSLeeping

Posted by Steve Levinson on Feb 12, 2016 12:46:59 PM

The PCI Data Security Standard continues to evolve gracefully to address the ever-changing threat landscape. In April 2015, the Payment Card Industry (“PCI”) Security Standards Council issued the “Migrating from SSL and Early TLS” Information Supplement which serves as a guideline pertaining to deprecated SSL/TLS protocols. The document served as basis of the changes to the PCI standard from version 3.0 to 3.1. In December 2015, the PCI Council released a blog post providing an update and further clarification. Our team has participated in dozens of discussions with our clients and peers pertaining to this change. In short, SSL and early TLS (version 1.0) can no longer be used as a mechanism to protect data in transit because the protocol is now considered cryptographically unsound. These compromised protocols allow attackers to potentially launch man-in-the-middle attacks to decrypt the supposedly encrypted message. The deadline to eradicate old SSL/TLS versions is June 30, 2016, with some flexibility to extend as late as June 30, 2018, with compensating controls.

What does this mean in PCI world?

In the ideal world, you could just make a seamless transition from SSL3.0 or TLS1.0 to TLS version 1.2 (note that not all versions of TLS version 1.1 are considered secure). In our numerous team and client discussions, we’ve learned that several organizations felt that they would be hard-pressed to meet the June 30, 2016 deadline for a number of reasons, including:

  • Using an operating system or firmware that can’t be upgraded, hence being forced to use the deprecated version of SSL/TLS.
  • Using a third party application that requires a code re-write and currently can’t be upgraded (relies on the third party to fix the application).
  • Connectivity to a partner whose own infrastructure will not support the newer protocol. Surprisingly (or maybe not so), there is at least one financial institution on that list!
  • Company has a client base who may use old browsers/Operating Systems and hence, they would stand to lose business/revenue by upgrading to newer TLS version.

So, what happens now?

Pre-plan: inventory of all data flows that use SSL/TLS

As companies have been able to evolve the level of detail of their critical (in this case, cardholder) data flows, it is time to get more granular to understand exactly which version of SSL/TLS is used for these data flows. Essentially, you should create an inventory of all instances of SSL and TLS, including a description of the payload (e.g., credit card, CVV, etc.). For PCI purposes, this should address all cardholder data flows although a good holistic approach would have you apply this task to ALL data flows using SSL and TLS.

Best case scenarios: 

You’ve made the migration to TLS1.2 and there are no instances of SSL3.0 or older versions of TLS. Almost as good is if you are actively working towards this migration (upgrades, hardware replacement, etc.), and if you do this before June 30, 2016, there are no worries pertaining to this element of PCI compliance. One thing to consider if you are in the process of migrating or about to migrate – things can break when you do this! Have a fallback plan (should be normal part of change management) and, to the extent that you can, gain a clear understanding of what traffic is transmitted via SSL3.0 or older TLS versions (a packet sniffer can help).

Reminder – just because you are using TLS1.2 does not mean that all is secure. You should also verify that the TLS implementation is securely configured, including secure TLS cipher suites and key sizes, and disabling support for other cipher suites that are not necessary.

Another possible solution, where applicable, is to migrate to a different transport protocol such as SSHv2 or IPSEC. Not all systems or applications are capable of using these protocols, but for those that are capable, this could be a great solution.

Plan B: This is where most of us will fit in

If you have not made the migration from the deprecated protocols, you should have a clear understanding of the risk associated with using those protocols as described in the PCI DSS Information Supplement. This exercise should be one of the tasks associated with your ongoing risk assessment. Not only does this demonstrate good security hygiene, but your QSA will expect to see this documentation. Frankly, this assessment should have taken place at the time it was announced that SSL3.0 and TLS 1.0 were unsound. On top of that, if you will not be able to eradicate the old protocols from your environment by June 30, 2016, you will need to create compensating controls to address the risk associated with using these protocols.

Assess the risk:

Here are some factors to consider when determining risk – I’m sure that there are others and am open to adding them to this list:

  • What data is transmitted via the protocol? If it’s cardholder data or credentials, there are exposure issues and, therefore, this issue should be examined further.
  • Is the payload already encrypted? If the data itself was encrypted (e.g., AES256, PGP key, etc.) and there is no means of an attacker who intercepts the traffic to be able to decrypt the payload, then there is little risk associated with this transmission (think belt AND suspenders).
  • How trusted is the network over which the traffic passes? If it’s over an untrusted network (i.e., the Internet), there is much greater potential exposure than if over an internal or trusted network. If it’s over an internal network, then the risk assessment would include any entities that lie in the path (or on the same network).
  • The type of environment where the protocols are used – e.g., the type of payment channel and functions for which the protocols are used.
  • Number and types of systems using and/or supporting the protocols – e.g., POS POI terminals, payment switches, etc.
  • You must keep your ear close to the track to keep abreast of new threats and attack vectors against the deprecated protocols since technology and threats are constantly evolving. As the threat landscape evolves, you may need to reassess the risk associated with using these protocols.

Create a risk mitigation plan: A risk mitigation and migration plan will document how you will address the migration to a secure protocol, including the controls in place to reduce risk associated with SSL and early TLS, until they’ve been eradicated from your environment. Note that the PCI Council released a FAQ in January that states that these elements must be documented through a Compensating Control Worksheet (“CCW”) that outlines how the risk is reduced to an acceptable level based on other controls above and beyond the PCI Standard. If you expect to be using these deprecated protocols after June 30, 2016, be prepared to present your risk mitigation plan to your QSA who in turn can document the element “in place with CCW” if you’ve done your homework.

Consider possible compensating controls:

Obviously mileage varies widely from company to company and architecture to architecture. These suggestions should be applicable to a great number of circumstances – would they work for you?

  • Encrypt payload: Is it possible to encrypt the data that is being transmitted via the deprecated protocol (e.g., AES256, PGP, etc.)? This may greatly reduce the risk pertaining to the possible interception of sensitive data (e.g., cardholder data) in transit. Keep in mind that if clear-text credentials are used in this stream, they may still be exposed.
  • Limit network exposure: If applicable, try to isolate the entities that talk to each other through network-based access control lists, etc. This will only apply if it is feasible.
  • Bastion host: This is one of my favorites, and it’s not terribly different than the telnet compensating controls that we’ve seen in years past. Basically, you would “fence off” the offending host that uses the deprecated protocol. Then you could set up a bastion host or jump box that is only allowed to communicate to that (using the deprecated protocol). All authorized users and entities would access the jump box using secure protocols, so that the only “exposure” to non-secure network traffic would be between the jump box and the host running the deprecated protocol.

The Blasphemous Solution:

This solution applies to service providers who are at the mercy of a handful of their partners/clients who, for whatever reasons, have been unable to apply updates and still use the deprecated protocols, thus putting these service providers at risk. One possible option, assuming that the data flows and ecosystems associated with these transactions/processes can be isolated from the in- scope ones, is to create a separate "non-compliant" environment for processing the offending partners’ data. This "non-compliant" environment can be de-scoped from the PCI environment if it has been properly isolated. Once the non-compliant partners upgrade their ecosystems/platforms, they can be migrated to the compliant environment.

Undoubtedly more scenarios and potential compensating controls will be popping up as we continue to traverse down the path to PCI nirvana – please feel free to share this information and to provide additional thoughts and feedback.

 

Topics: Security

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates

Recent Posts