In 2015, the Payment Card Industry Security Standards Council (PCI SSC) has extended the migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS. Many enterprises, in response to public exploits such as POODLE, have already started and completed this migration. For others, the June 30, 2018 deadline will be the event that drives completion of the migration across all solution components.
For PCI compliant customers, visibility of this requirement will be primarily evident through vulnerability scanning of their cardholder data environment.
Although TLS 1.2 has been used throughout Deep Security for many years, we began to standardize the adoption of TLS 1.2 in Deep Security 10.0. Backward compatibility with SSL and early TLS was maintained in specific cases to support customers using older agents and relays that did not support TLS 1.2. This ensured minimal impact to upgrades and the ability to continue using older versions of Deep Security components in specific customer environments.
Deep Security Software Deployments
The following table provides guidance for customers who will be addressing requirements and planning a migration from SSL and early TLS for June 2018.
| Customers Using | Action | Why? |
|---|---|---|
| Deep Security 9.6 or earlier agents | Upgrade to Deep Security 10.0 or later agents | Deep Security 10.0 or later agents are required to negotiate TLS 1.2 for agent-manager communication. Note: Deep Security 10.0 or later agents require a Deep Security 10.0 or later manager. |
| Deep Security 9.6, 10.0 Deep Security Manager and Relays | Upgrade the manager and relays to Deep Security 10.0 Software Update 8 that will be published in February | Deep Security 10.0 Software Update 8 contains the ability to disable support for early TLS on the manager and relays. Disabling support for early TLS will ensure that vulnerability scanning in PCI compliant environments will not report any instances of TLS servers advertising support for SSL or early TLS. |
| Deep Security Feature Releases (10.1, 10.2, 10.3) | Upgrade the Deep Security Manager and Relays to Deep Security 11.0 | The next major update for customers who have chosen to use a Deep Security Feature release is Deep Security 11.0. A 'downgrade' to Deep Security 10.0 Software Update 8 is not supported. A configuration option to specify the minimum TLS version used by Deep Security will be provided. Customers may optionally enable TLS 1.0 to support backward compatibility with 9.6 or earlier agents. |
Deep Security Virtual Appliance
Customers with deployed versions of Deep Security (ie, 9.5, 9.6 and 10.0 LTS) will be using the 9.5 SP1 OVF file. When a new DSVA is deployed using this OVF (either with a new deployment or if a new ESX host is brought online), the agent within it only accepts TLS 1.0 and cannot be activated by a DSM that only supports TLS 1.2. In this case, Deep Security can be configured to temporarily to accept TLS 1.0 connections for the purposes of activating and upgrading the DSVA. Once the DSVA has had its agent upgraded successfully to Deep Security 10.0 or later, all DSVA-Manager communication can utilize TLS 1.2.
The net result is that after the upgrade, and once a minimum of TLS 1.2 is restored, the resultant environment can be used to meet your PCI compliance obligation.
A new OVF for Deep Security 11.0 will be made available in 1H 2018 that uses TLS 1.2 for its initial communication to DSM. Shortly after 11.0 GA, we will also make available a 10.0 LTS OVF that has the same support. Once these updated OVF's have been made available and TLS 1.0 is not used as part of the initial connectivity to Deep Security Manager, there is no need to enable support for TLS 1.0 prior to the upgrade of the DSVA (as was necessary to work around the limitations of the 9.5 SP1 OVF).
Detailed instructions to deploy the Deep Security Virtual Appliance in this configuration will be provided at https://help.deepsecurity.trendmicro.com/. Links will be provided in the readme along with each release to articles that support this deployment process.
