Legacy Java Data Risk

By October 14, 2014 August 1st, 2018 Blog

Java is one of the longest standing and widely deployed enterprise programming languages in the world. It is also one of the most frequently attacked platforms due to its many and well documented security vulnerabilities (CVE), many of which have a very high CVSS (Common Vulnerability Scoring System).

While Java version 6 is especially buggy, vulnerabilities exist in all versions. As a result, data accessed and processed by enterprise apps running on Java is at a high risk of compromise.

This problem is amplified by the fact that countless data center applications are still running on older, legacy versions of the platform. Although the original promise of Java was application portability, in reality most core enterprise applications were written for execution on a specific version of Java, and that’s where they’ve stayed.

Vulnerability Mitigation Road Blocks

The two primary reasons that legacy Java security risks persist are cost of mitigation and operational impacts.  The obvious way to deal with legacy Java issues is to just update the Java runtime.  But this process is costly since it requires extensive application modifications, testing and re-qualification. Often, this type of financial investment is hard to justify based on ambiguous estimates of the security risk.

Risk of downtime is an even bigger problem.  No matter how much testing is done, it’s impossible to guarantee that changes to the application will not break it. “If it ain’t broke don’t fix it!” isn’t a recipe for good security, but it has a certain logic with respect to downtime.

As a work around, network based tool solutions like WAFs are inserted, but these are typically unable to protect against sophisticated attacks, or ones that are launched internally.  Static or dynamic code analysis tools may be in use for application security, but these cannot mitigate attacks that exploit issues lower in the stack, at the Java runtime level.  They also usually produce reams of information on potential vulnerabilities, which take a long time to deal with. In summary, addressing the risk from legacy Java falls through the cracks in typical enterprise environments.

Alternative Measures

Fortunately a new approach has emerged for mitigating the legacy Java risk: Java containerization. Containerization involves wrapping an application and all required ancillary software in a single, portable package.  While not a new concept, containerization is enjoying renewed popularity thanks to technologies such as Docker.

In the Java security context, Waratek wraps a Java application and the underlying legacy Java platform within an up-to-date runtime container. Using this method, external threats are intercepted by the new, more secure Java Virtual Machine (JVM), instead of having direct access to the older version.

Furthermore, since the application is still executing in the original, legacy Java environment, this model does not require modifications to existing code. This eliminates the risk to application stability associated with upgrading the JVM, while still protecting it from exploits.

Waratek’s approach allows you to securely deploy legacy Java applications indefinitely since containerization provides a virtual patch against known and unknown vulnerabilities, without the need to make any code changes.

Waratek

Author Waratek

Some of the world’s leading companies use Waratek to patch, secure and upgrade their mission critical web applications using our next generation technology. Waratek makes it easy for security teams to instantly patch known Java and .NET flaws with no downtime, protect their applications from known and Zero Day attacks, and virtually upgrade out-of-support Java applications – all without time consuming and expensive source code changes or unacceptable performance overhead.

More posts by Waratek

Leave a Reply

X