For environments currently using SSL/early TLS protocols, the implementation and continued use of risk-mitigation controls helps protect the vulnerable environment until migration to a secure alternative is complete.
What are examples of risk-mitigation controls that organizations can put in place?
Some controls that may help with risk reduction include, but are not limited to:
- Minimizing the attack surface as much as possible, by consolidating functions that use vulnerable protocols onto fewer systems, and reducing the number of systems supporting the protocols.
- Removing or disabling use of web browsers, JavaScript, and security-impacting session cookies where they are not needed.
- Restricting the number of communications using the vulnerable protocols by detecting and blocking requests to downgrade to a lesser protocol version.
- Restricting use of the vulnerable protocols to specific entities; for example, by configuring firewalls to permit SSL/early TLS only to known IP addresses (such as business partners requiring use of the protocols), and blocking such traffic for all other IP addresses.
- Enhancing detection/prevention capabilities by expanding coverage of intrusion-protection systems, updating signatures, and blocking network activity that indicates malicious behavior.
- Actively monitoring for suspicious activity – for example, identifying unusual increases in requests for fallback to vulnerable protocols – and responding appropriately.
Additionally, entities should ensure all applicable PCI DSS requirements are also in place, including:
- Proactively keeping informed about new vulnerabilities; for example, subscribing to vulnerability notification services and vendor support sites to receive updates about new vulnerabilities as they emerge.
- Applying vendor recommendations for configuring their technologies securely.
What are some SSL/early TLS migration options?
Examples of additional cryptographic measures that may be implemented and used as a security control to replace SSL/early TLS may include:
- Upgrading to a current, secure version of TLS that is implemented securely and configured to not accept fallback to SSL or early TLS.
- Encrypting data with strong cryptography before sending over SSL/early TLS (for example, using field-level or application-level encryption to encrypt the data prior to transmission).
- Setting up a strongly-encrypted session first (e.g. IPsec tunnel), then sending data over SSL within secure tunnel.
Additionally, the use of two-factor authentication may be combined with the above controls to provide authentication assurance. At least one of the factors must not rely on transmission over the legacy SSL/early TLS connection.
The choice of an alternative cryptographic control will depend on the technical and business needs for a particular environment.
While 30 June 2018 is still a year away, it takes time to migrate to more secure protocols and organizations should not delay in starting this process.
