kentoh - Fotolia
Get ready, everyone -- the next version of PCI DSS is on the books. If it seems like you're hearing that news fairly often, you're not alone. In April 2015, the Payment Card Industry Security Standards Council (PCI SSC) officially released version 3.1 of PCI DSS with an immediate effective date. This was actually a few months before the final phase-in date for the PCI DSS 3.0 requirements on June 30, 2015.
The most significant change found in PCI DSS 3.1 is the removal of SSL and early versions of TLS (version 1.0 and some implementations of version 1.1) from the list of approved encryption standards. This is a direct response to last October's discovery of the Padding Oracle On Downgraded Legacy Encryption (POODLE) vulnerability in SSL. Following industry best practices, PCI SSC is now dramatically curtailing the use of outdated encryption technology with an eye toward a complete ban in the future. Other changes in the new version of the standard are minor updates to clarify language and testing procedures for existing requirements.
SSLs days are numbered
SSL and early versions of TLS are clearly on the chopping block, and PCI SSC would prefer if everyone stopped using them immediately. However, the standards body recognizes the cost and time involved in migrating to a new encryption technology and, therefore, is adopting a two-phase approach to the implementation of this requirement.
The first phase, effective immediately, of the PCI DSS 3.1 SSL mandate requires that new implementations of systems, applications and networks must not use SSL or early versions of TLS unless it is necessary to support a pre-existing use of the protocol. Organizations building new card processing systems must use an alternative encryption protocol, such as TLS 1.2, SSH, IPsec or S-FTP.
The second phase takes effect on June 30, 2016, when most users of SSL and early versions of TLS must complete their migration to an alternate, secure protocol. In addition, organizations subject to this provision must create a Risk Mitigation and Migration Plan that documents their approach to mitigating security vulnerabilities related to the use of insecure protocols and outlines the process they will follow to complete migrations before the June 30, 2016 deadline.
There is one exception to the new requirements: point-of-sale (POS) systems that rely upon SSL and/or early TLS may continue using these technologies beyond the deadline, provided the merchant certifies it is not susceptible to known exploits. Assessors who discover the use of these protocols in a POS environment must verify the merchant maintains documentation demonstrating the devices are not susceptible to known exploits. Merchants planning to continue running the deprecated protocols under this provision should contact their POS vendor and obtain documentation, certifying the version of POS software in use is not susceptible to POODLE or other SSL vulnerabilities.
Building a Risk Mitigation and Migration Plan
Organizations subject to the second phase of the PCI DSS 3.1 SSL requirements must immediately create a Risk Mitigation and Migration Plan that documents their strategy for implementing the new requirement. The new standard does not offer a future deadline for creating this plan, so merchants must assume assessors will expect these plans to exist, effective immediately. Therefore, it is in a merchant's best interest to quickly create a formal plan that meets the basic requirements of the new standard and then iteratively work to improve the plan until the assessors are satisfied with it.
The core of the plan includes a risk assessment of the use of SSL and early TLS in the merchant's environment. This must include a description of current use of the protocol, including the type of environment, the data transmitted with the outdated technology, and the number and type of systems using SSL and early TLS. The assessment must also include a thorough review of the risks associated with SSL/TLS use and controls that the merchant put in place to lower those risks. For example, a merchant relying upon SSL might choose to rotate keys more frequently than required, or tunnel SSL traffic through an IPsec VPN.
The Risk Mitigation Plan must also include elements that prevent against the use of vulnerable technology. Merchants must document a vulnerability monitoring process that will alert them to vulnerabilities that require immediate discontinuation of the use of insecure protocols. If a new POODLE-like vulnerability hits the streets, merchants must react immediately. The plan requires merchants to update change control processes to prevent the use of insecure protocols in new environments.
Finally, the documentation must include a project plan for completing the migration to new technology before the June 30, 2016 deadline. This plan should include the process and target dates for migrating each system using SSL or early TLS to newer encryption technology.
The good news about PCI DSS 3.1 is that there isn't a lot of new text to wade through. Merchants and service providers should carefully review the Summary of Changes document, but they will likely find the most important change on the horizon is the deprecation of SSL, and that they must immediately begin planning to move to more secure technology, as described in the PCI SSC information supplement titled, "Migrating from SSL and Early TLS."
About the author:
Mike Chapple, Ph. D., CISA, CISSP, is a senior director of IT with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Chapple is a frequent contributor to SearchSecurity.com, and serves as its resident expert on enterprise compliance, frameworks and standards for its Ask the Experts panel. He is a technical editor for SearchSecurity.com and Information Security magazine and the author of several information security books, including the CISSP Prep Guide and Information Security Illuminated.
Check out some more info about PCI DSS 3.1 and the new SSL plan it requires