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.