By John Matthew Holt
About half of all enterprise applications written in the last 15 years were written in Java (or one of its derivations). Many control access to sensitive data, so it’s no wonder that they are popular targets for attackers. However, current mitigation methods are clumsy and tend to generate false positives. Fortunately, there is a new method that embeds security functions inside the Java execution platform itself — or more specifically, inside the Java Virtual Machine — avoiding many long-standing problems.
Ensuring security for Java apps is not a straightforward task because, in today’s software development world, Java programmers routinely import thousands of lines of code from third-party code libraries. The imported code is typically used to perform common, generic tasks, such as database access, XML processing, logging, and the like. But when code is open-sourced, there is no single party who warrants its security or undertakes rigorous penetration testing. Therefore, vulnerabilities can be repeatedly introduced into in-house code through this “imported code backdoor.” These vulnerabilities may be unknown to the enterprise, but well-known to attackers.
When flawed code is present, attackers may be able to attack a server or access data at the back end using SQL injection attacks or other exploits. Developer training and static software analysis tools can reduce the danger, but neither of these safeguards can mitigate vulnerabilities discovered after an application goes into production. A security approach that does not require developer intervention is a better option.
While it didn’t affect Java, the poster child of a vulnerability resulting from the use of third-party code libraries is doubtless the Heartbleed incident of early 2014. Basically, a security bug was found in the OpenSSL cryptography library that affected an estimated two-thirds of Web servers on the Internet.
Traditional Java defenses
Security for Java apps has typically been either network-based or testing-based. Neither approach has proven adequate.
Network-based defense involves Web application firewalls and intrusion prevention systems operating at runtime to shield production systems from external threats. To avoid blocking legitimate traffic, such systems must be tuned quite loosely, making them less effective. Otherwise months must be spent tuning them to admit only authorized traffic. After all, if authorized traffic is blocked, users are blocked. Meanwhile, when network-level defense mechanisms (such as IP firewalls) do block traffic, they use clumsy methods that terminate the network connection.
Application testing tools analyze software for the presence of vulnerabilities. The results generated by application testing tools may be highly educational for the app’s developers, but they can also be overwhelmingly numerous, making it difficult to prioritize the critical problems versus minor issues and false positives. When vulnerabilities inevitably slip through, such tools do nothing to protect the system during runtime.
New approach: RASP with JVM
A new approach to securing Java applications is Runtime Application Self-Protection (RASP). Implemented by the application runtime itself (or tightly coupled to it), RASP combines real-time analysis of application behavior (what the application is doing right now) with real-time contextual awareness (what has led up to the application doing what it is doing right now). Thus, continuous security analysis becomes a native function of the runtime environment, with the system responding immediately to any recognized attacks. Because security functions are applied from within the application, with instruction-by-instruction awareness of what the application is precisely doing, RASP avoids the false positives that plague other mitigation methods.
Waratek believes the best way to achieve RASP is to leverage the power of the Java Virtual Machine. Sitting above a server’s operating system or hypervisor but below the application, the JVM is a complete runtime environment that can modify an application’s behavior on the fly — without requiring any changes to the application’s code. Because the JVM also controls all of the I/O of a Java app, it can block unauthorized actions. Most important, it can gracefully block the execution of compromised code, using an application’s existing error-handling routines.
The Waratek implementation of RASP is called Waratek Application Security for Java. Based on the standard Oracle Hotspot JVM, it adds a security rules engine to protect Java code, without any need to change the application code itself. The rules engine supports fine-grained monitoring and control of virtually all application behaviors, including file and network access, class loading, reflection, method invocation, SQL queries, scripted functions, and much more, automatically providing attack mitigation.
Policing user input
Bringing the security protection of the application into the JVM also means that user input can be tracked throughout program execution. This feature, called “variable taint tracking,” can prevent the use of untrusted user input for data access (such as SQL queries) or sensitive operations (reflection) without proper validation. Taint tracking prevents code injection attacks (like SQL injection) by stopping malicious or malformed user input from being passed from an untrusted source to a trusted resource (as from an HTTP query string to a SQL database).
By blocking the execution of malicious code regardless of where it originates — in the application code, imported third-party libraries, or the network — a RASP-enabled JVM can defeat zero-day exploits. Furthermore, security administrators can add new rules to a running appwithout restarting or interrupting application service, allowing them to thwart a new exploit as soon as it is understood and without waiting for vendor-supplied patches.
Waratek Application Security for Java also provides application protection for legacy Java security issues — namely, vulnerabilities in older and unsupported versions of Java. Because Waratek creates a virtualexecution environment (or “wrapper”) for the application as well as for the JRE (Java Runtime Environment) that the app uses, legacy apps with a legacy version of Java (such as Java SE 5) can run on top of a Java SE 7 version of the Waratek JVM. Without any modifications to the app, Waratek will protect against all of the old — and new — exploits that would otherwise succeed.
The Waratek JVM can also pass data to a centralized security event system for correlation with other suspicious activity, or to developers for use in the coding or testing stage.
RASP in action
Two examples of the protection provided by Waratek Application Security for Java include SQL injection attack mitigation using “variable taint tracking,” and mitigation of the Apache Struts 2 vulnerability.
As mentioned, SQL injection attacks are a high-priority security risk. Waratek counters this risk by adding metadata to untrusted user input as it enters the JVM. It then tracks what happens to that data as it is used to construct a complete SQL statement to query a database. It can then tell with certainty and act appropriately if the resulting query contains code that will change the meaning of the request, since that means that an attack is being attempted.
Waratek can detect SQL injection attacks with certainty because it is able to examine each and every SQL statement with complete contextual awareness, rather than try to guess based on partial statements, as Web firewalls must do. Again, this mitigation does not require any changes to the application code.
Apache Struts 2 is an open source Web application framework for developing Java Web applications. In the last several years, we’ve learned of many critical vulnerabilities in the Struts framework that would allow an attacker to execute remote exploits on a vulnerable server.
To remediate these vulnerabilities, users had to wait for an official patch (in some cases for weeks or months), test the patch, then deploy it. Alternatively, they could rewrite their code, again retesting and redeploying the application.
With Waratek, however, applying a single security rule, at runtime and without restarting or interrupting the application, blocks the execution of the compromised function and prevents exploitation.
False positives are always a concern with any security solution, especially for mission critical applications. RASP generally — and Waratek Application Security for Java specifically — reduces this risk to an absolute minimum because it is able to monitor the application’s behavior and context at a very granular level by watching execution within the runtime environment. This approach is much finer-grained than detection at the network level; therefore, modeling the app behavior for pre-deployment tuning is relatively straightforward.
Finally, while no security process is completely free of processing overhead, placing the security operations inside the JVM where they can be optimized by the JIT (Just-In-Time) compiler ensures that the performance impact is as small as it can be. The performance benefit of native “in-JVM” security is especially pronounced when compared to other application security approaches that use remote procedure calls (like REST API calls) to services outside of the application or “instrumentation agents” to insert debugging-like hooks into application code.
Clearly, an inside-out approach to securing Java applications offers many advantages. By bringing security into the JVM, we can secure an enterprise’s most critical code in a way that is always available, does not impact performance in any discernible way, can protect multiple apps, does not require software changes, and is faster and more flexible than patching. Going forward, the same concept can be extended to any application platform with a runtime execution environment, such as client-side Java.
John Matthew Holt is the founder and chief technology officer of Waratek.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to firstname.lastname@example.org.
This article was originally published at InfoWorld.com.