It’s nearing a month since the Payment Card Industry Data Security Standard (PCI DSS) 3.0 as officially retired on June 30.
PCI DSS 3.1 was swiftly introduced in April 2015 as a response to major security flaws discovered in open source SSL, and the exploits – including Heartbleed, Shellshock and POODLE – that targeted the vulnerabilities. The flaws enables man-in-the-middle attacks and enabled attackers to read supposedly secure, authenticated encrypted communications. Consequently, the PCI Council branded SSL and TLS 1.0 as “vulnerable protocols” in the new version of its security standard.
Those who are required to comply with PCI DSS have a grace period of June 30 2016, but any new deployments that utilize SSL or early versions of TLS are now prohibited.
Online merchants need to develop a migration plan to move from SSL to the latest version of the Transport Layer Security protocol now, and also ensure any payment apps using SSL are updated. The US National Institute for Standards and Technology last year told all government agencies to upgrade to TLS 1.2 as standard.
Migrating from SSL and Early TLS
Your best resource for managing this upgrade can be found in the PCI SSC guide “Migrating from SSL and Early TLS.”
The guide provides detailed information on risk-mitigation controls for environments currently using vulnerable protocols:
- Minimize the attack surface as much as possible, by consolidating functions that use vulnerable protocols onto fewer systems,
- Reduce the number of systems supporting the protocols.
- Restrict the number of communications using the vulnerable protocols by detecting and blocking requests to downgrade to a lesser protocol version.
- Restrict 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.
- Enhance detection/prevention capabilities by expanding coverage of intrusion-protection systems, updating signatures, and blocking network activity that indicates malicious behavior.
- Actively monitor for suspicious activity – for example, identifying unusual increases in requests for fallback to vulnerable protocols – and responding appropriately.
Additionally, covered 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.