In a summer of big security compliance deadlines, one slipped by virtually unnoticed. While the world was fixated on meeting the strict requirements of GDPR by 25 May, there was little fanfare over 30 June – the day SSL and early TLS was officially retired after a two-year delay.
The Payment Card Industry Security Standards Council first announced the move away from SSL and early TLS versions in 2015 with an effective date in 2016. SSL was deemed obsolete and early TLS (defined as 1.0 and 1.1) was vulnerable to attack, especially “Man in the Middle” exploits like “Heartbleed.”
Compliance often required replacing hardware and upgrading software. Delays in both prompted the PCI Council to push the retirement date until 2018. With the compliance date now in the past, are there still vulnerable systems in the wild? And, can anything be done to help bring them into compliance short of costly rewrite or replace efforts?
Undoubtedly the answer to the first question is a qualified “yes.” Older servers and enterprise applications may not be able to upgrade to new encryption standards without being replaced or rewritten.
However, even large, well-established, and successful organizations have difficulty addressing legacy software with the result being an untold number of older applications running in organizations around the world. Rewriting an app or migrating to a newer platform is not possible in many cases, and it’s certainly not scalable in enterprise environments where thousands of applications are deployed on all possible versions of Java and .NET platforms
The answer to the question about achieving compliance without replacing servers and rewriting vulnerable applications is a more definitive “yes.”
Using a virtual container in an application’s runtime allows legacy applications to utilize the latest and most stable TLS protocols and cipher suites without the need to rewrite source code or migrate to a newer Java platform. Out-of-support Java versions (such as Java 5, 6, 7 and soon 8) run as guest JREs on a current version host JVM. The application no longer uses its own out-of-date TLS protocols, but rather offloads this functionality to the most current and patched host JVM.
This configuration offers several unique benefits:
- Applications that need the latest cryptographic and encryption protocols and cipher suites do not need to be rewritten, redesigned or recompiled
- Legacy applications that have been developed to specifically utilize an older, broken SSL or TLS version can be automatically upgraded to use the latest TLS version
- Enterprises do not need to change the Java version of their application nor migrate to another JVM platform
- Applications are automatically protected against common cryptographic vulnerabilities
Most importantly, organizations become instantly compliant with the latest PCI standards and improve the protection of their customer’s valuable data.
