Current approaches to Java application protection place security at the application or the network layer, both of which are problematic. The first approach has proven to be too complex, too time consuming and too risky — in other words, “too hot.”
Meanwhile, network level security that consists of perimeter devices lacks the intelligence to know what’s going on inside the application in order to be effective. This approach is “too cold.”
A third alternative is to place security inside the Java virtual machine.
Application Layer Protection
Application layer protection is too time-consuming, because the only realistic defense is developer training and retraining, and repeated code testing using automated tools. There is little time for either in today’s word of rapid software development.
The automated code tests, meanwhile, are good for finding known vulnerabilities, but provide no protection against ones that do slip through — or are invented in the future.
In an ideal world, application security would be baked in at every stage of the development process. In theory, that sounds great. In practice, rushed Java programmers often import large chunks of code from third-party code libraries.
No one can say if a given line of code has been tested for vulnerabilities. To attempt true security, developers would have to track the provenance of each scrap of code.
It’s too risky, because the stakes are so high. Since enterprises often use Java apps to control access to sensitive information, and since about half of all enterprise apps developed in the past 15 years were written in Java or a Java-derived language, Java is a popular target for attackers.
SQL injection attacks are especially prevalent, and rely on the execution of intentionally malformed or corrupted input, often made possible by code vulnerabilities.
Network Level Security
Perimeter-based application security solutions, including firewalls, intrusion-detection systems, intrusion-prevention systems, or Web application firewalls, etc., lack the intelligence to know what is going on inside the app, and therefore never will be truly effective.
They must permit the passage of authorized traffic while at the same time blocking malicious traffic. However, since these tools do not operate at the application layer, they are unable to discern what authorized traffic should look like at a given moment.
Meanwhile, if they inadvertently block authorized traffic, network security products can fatally disrupt user access to an application.
In the end, administrators must choose between using loose security parameters at the risk of an intrusion, or spending months finding tight parameters that do not “break the app.” More often than not, they chose the former, creating significant risks.
Inside-Out Security
But there’s a third alternative. In terms of Java app security, that means an approach that analyst firm Gartner calls “runtime application self-protection,” or RASP. It performs ongoing security analysis — with immediate responses to detected threats — as a native function within the run-time environment, without changing a single line of application code.
One approach for implementing RASP involves leveraging the power of the Java Virtual Machine. Running above the operating system but below the app, the JVM sits between the compiled Java code and the server/OS infrastructure that the Java code runs on.
The JVM has the native ability to modify an app’s run-time behavior on the fly without needing to change its source code or binary code. That means, among other things, that it can control the I/O of a Java app and therefore block unauthorized actions and execution of compromised code without crashing the app.
Placing application security capabilities in the JVM can protect Java code without having to make any changes to the Java app itself or to impact app performance. By performing fine-grained monitoring and control of key system behaviors, JVM-based security can provide attack mitigation automatically.
It can block malware-related activity regardless of which code triggered it. This blanket coverage not only counters known vulnerabilities, but also can defeat zero-day exploits, or ones that exploit poor input validation.
In addition to protecting against illicit system behaviors, JVM security can include a rules engine for protection against an entire class of attacks, such as SQL injection or other known vulnerabilities like those recently reported in the Apache Struts 2 open source Web application framework.
Entire categories of security weaknesses and vulnerabilities can be countered with only a small number of rules, which can be applied in real-time, even while the app is running. Waiting for vendor-supplied patches is no longer an issue.
Meanwhile, legacy Java apps get blanket coverage against exploits that otherwise might succeed. A security-enabled JVM can even pass data to developers for use in coding or testing, or to security information event management (SIEM) tools.
JVM-based security that is neither too hot to implement nor too cold to recognize threats is available today.
Loading ...
