Container security: How Waratek blocks Java exploits

In general, container cybersecurity works by creating a virtual machine to host a protected application and then restricting what it can do to reach out of that container. Because of its reliance on virtual machines, containerization only recently became popular because of cloud computing, which also relies heavily on virtualization.

Waratek is entering this space from a completely different angle compared to other container security firms, relying on just-in-time compiling and focusing exclusively on one of the biggest security risks within most organizations, applications running Java. Coming to the security space from the prospect of compiler engineers gives the Waratek software a unique flavor and approach that has been overlooked and unexplored by most other companies.

Java applications are divided into two components: You have the baseline Java 8 or 9 stack, which hosts the app and provides the garbage collector process. For the most part, that section is fairly simplistic and completely secure. And then you have the upper layer, which is comprised of the actual code of the running application, plus all the support programming to give it interactivity. The upper layer can consist of millions of lines of code and can be based on any version of Java going all the way back to Java 4. It’s potentially very insecure and os often the focal point for common attacks like SQL injections used to steal information inside protected databases.

The Waratek Application Security Platform leaves the baseline, secure part of Java alone and concentrates on containerization of the upper part of the stack. It uses runtime application self-protection (RASP), to defeat and prevent real-time attacks. 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.

Installing the Waratek platform on our test network was extremely easy. First, the main Waratek console needs to be installed. It can run on-premises or in the cloud, though according to Waratek engineers, most of their clients prefer it installed on site so they can keep all of their security tools together. Once that is ready, several lines of code need to be added to the default configuration file to affect all Java apps. The new code basically pushes an agent out to each application, instructing the apps to link up with the console, and to create the container around the application stack.

Waratek 1 deployed John Breeden/Waratek

This shows the simplicity of deploying the Waratek agents. It’s only a few lines of code, basically telling apps to check in with the Waratek console before spinning up.

Back at the console, a list of the apps that have checked in can be examined. The final step is to authorize the connection and program the security. This is all done with a nice graphical interface in only a few clicks.

Waratek 2 main console John Breeden/Waratek

The main console of the Waratek platform is mostly used to configure app containers. It also records attempted attacks against apps, but there is no need to respond given that all attacks against a protected container will fail.

To test the Waratek platform, we first conducted a SQL code injection attack against an unprotected app, trying to get it to spit out the fields of a protected Oracle database. This was extremely easy, and in no time we were looking at lots of simulated, protected PII.