Feds Can Counter Java Headaches with Virtualization

John Breeden II is an award-winning journalist and reviewer with over 20 years of experience covering technology. He is the CEO of the Tech Writers Bureau, a group that creates technological thought leadership content for organizations of all sizes. Twitter: @LabGuys

Java is one of the most useful programming languages within government but it’s also one of the most vulnerable.

Many of the highest profile, successful attacks had a Java vulnerability as their launching point—not just in government but across organizations of all sizes. By comparison, Flash had similar problems but had such a light footprint in government that the solution was simply to purge it from federal computers. You can’t do that with Java, as it’s far too entrenched at agencies and makes up the lifeblood of many critical systems and applications.

» Get the best federal technology news and ideas delivered right to your inbox. Sign up here.

So how do you solve a problem like Java? First off, you need to understand how Java is configured. Java applications are divided up into two components. You have the baseline Java 8 or 9 stack that hosts the application and provides the garbage collector process. It’s extremely simple, can’t really be successfully attacked, and considered completely secure by most experts. But you can’t do very much with just the baseline.

Running programs in Java require the upper application layer. That is where you end up pulling in millions of lines of code—and it’s where the exploits happen. It’s also not so well-known that the upper layer is often based on older versions of Java. For example, a baseline running Java 9 could be supporting an upper layer as old as Java 4. In other words, the vulnerabilities hackers discovered in Java four years ago could potentially be used to exploit a program running in a federal data center that on the surface looks to be supported by Java 8 or 9 but maintains a vulnerable upper stack. And no, you simply can’t upgrade most applications to allow them to run under Java 9. Most likely, too many of the millions of lines of code will not be compatible. It would need to be rewritten from scratch.

Such is the curse of using Java: deficits outweighed by the fact that it can be employed to work with nearly any type of device to perform nearly any application. But the security risks are still there, and I have not seen too many ways to completely lock it down, until now.

One of my many projects over this long, hot summer, is conducting a series of 15 in-depth cybersecurity reviews for Network World and CSO magazine, examining products that fit into categories that Gartner has identified as being the most important in cybersecurity for the foreseeable future. Not surprisingly, locking down Java and other application exploits made the list.

Called the Waratek Application Security Platform, it leaves the baseline, secure part of Java alone, and concentrates on creating a virtualized container to support the upper part of the Java stack. Beyond just a containerization security program, Waratek uses the science of runtime application self-protection (RASP), to defeat and prevent real-time attacks made against the upper Java stack. Once installed, Waratek creates a RASP container that virtualizes the entire application portion of the stack, separating it from the host Java virtual machine and the system OS. The virtualized application stack sits on top of the Waratek security controls, enabling users to direct how applications can be used, and what exploits to block from ever leaving the container.

In a lot of ways, Waratek does for Java what I wrote about segmentation doing for the rest of the data center previously for Nextgov. Administrators can define exactly what actions are allowed within their virtualized Java container, blocking literally everything else. Even if an attacker tries to trigger a valid, unpatched exploit, it won’t be allowed to run within the virtualized container, much less escape out into the rest of the network.

I tested this out by sending many attacks including SQL injection techniques like Network:Bind, Path:Traversal, Redirect:Servlet and others at an extremely vulnerable application running on Java 4 in the upper stack but inside a protected Waratek container. I got nothing but error messages back on my end. It was as if I was trying to trigger an exploit that had already been patched or otherwise eliminated from the code.

At the Waratek console, all my probing was detected and recorded, so federal admins will know if they are falling under attack, even if the attempts are harmlessly bouncing off their new armor. The threat feed can be linked to a SIEM or monitored on the local console.

As a final advantage, especially for feds, the virtualized RASP containers completely separate the app from the core of Java and the operating system. That means that older Java apps that are incompatible with newer versions of Java can still operate, using the Waratek containerization technology to bridge the gap. Feds could thus upgrade to Java 9 without their older programs suddenly failing due to incompatibility.

Unfortunately, Waratek only works with Java right now, though .NET architectures are being worked on. Pricing is reasonable, based on the number of RASP containers agencies need the program to create, so it fits into the new federal trend of pay as you go.

Java itself, despite being a real federal workhorse, may never be completely secure. But at least with the Waratek Application Security Platform, for all intents and purposes, it will act like it is.