How to secure Java

amid growing Java security vulnerabilities 

By Nick Lewis, Enterprise Threats 

It's no secret that attackers have moved "up the stack" in recent years. With enterprise networks and platforms now much more difficult to exploit, attackers now favor the low-hanging fruit of application-layer attacks. And there's been no shortage of juicy targets.

Oracle has added to Java's technical debt, which will result in an ever greater number of vulnerabilities.

While Flash and Adobe Reader have been popular client-side targets, one could argue that attackers' favorite application-layer target has been Java and specifically the Java Runtime Environment (JRE). Oracle, starting with Sun, has advanced the development of the Java ecosystem in several areas, including the programming language, server-side environment and the widespread client-side JRE, but attackers continue to expose serious security vulnerabilities in the JRE. Most of these vulnerabilities are limited to the more common platforms, such as MacOS and Windows, but since Java is used in a wide variety of platforms for the client software, the impact of vulnerabilities may not be well understood.
In this tip, we'll discuss the latest spate of Java security vulnerabilities and offer some measures to better secure Java in the enterprise environment.
One step forward, one step backAs of late, it seems that just as Oracle releases a patch for the most recently exposed Java vulnerability, attackers find a new one to exploit. Another serious vulnerability was identified September 2012; it allows an attacker to exploit a core security feature of the Java JRE, Type Safety, to escape the Java sandbox. An attacker can completely compromise the security of a system by exploiting this vulnerability.
Worse yet, Java security patches may be giving attackers more exploit opportunities: It is believed that the JRE vulnerability that was reported August 2012 may have been introduced by a previous patch. The bug in the AWT subcomponent of Java could also allow for code execution on the local system, which would bypass the sandbox and result in a system being compromised. When Oracle's software update process exposes new security vulnerabilities, the strength of Java's software development lifecycle comes into question. Not all bugs can be prevented, but it seems clear a stronger security development lifecycle is needed to help prevent the introduction of new Java bugs.

Listen to How to secure Java amid growing Java security vulnerabilities as an MP3 here.

The reality is that the Java security problem isn't going away. Vulnerabilities will continue to be found, exploited and patched by Oracle with varying speed and efficiency. In all fairness, the software vendor faces a difficult task as it seeks to advance Java's development while trying to keep it secure. Unfortunately, on top of what was inherited from Sun Microsystems, Oracle has added to Java's technical debt, which will result in an ever greater number of vulnerabilities.
Larry Ellison once touted that Oracle's products are "unbreakable", but this attitude toward security has not extended to the JRE. Oracle's approach to security is generally considered to be less mature than those of rival software makers Microsoftand Adobe, which affects how companies use the JRE. As Microsoft and Adobe started to change their respective security cultures, improvements were realized in the security of their applications despite similarly significant technical debt for legacy products and applications. Oracle does have a long history of selling software to customers with strict security requirements, such as the CIA, but there seems to be an increasingly striking disconnect within Oracle that has yet to foster a strong security development for Java and the JRE. To prevent the JRE from posing too great a threat to enterprises, this must change.
Methods to secure JavaMany believe that the state of Java security is so dire that it must be disabled on all enterprise client-side applications. Though there are viable alternatives for software such as Adobe Reader, no real alternatives currently exist for the Java Runtime Environment. The reality is that many enterprise applications rely on Java; for many organizations, disabling Java simply isn't an option.
From the editors: Time to disable Java?

In the wake of recent exploits, experts recommend disabling the programming language, but that can be tricky in the enterprise. In this Information Security magazine column, learn why disabling Java may be the answer.

With that said, all of the standard advice for securing any client software applies to the JRE too, including not installing (or uninstalling) the JRE if it isn't necessary, keeping the JRE up to date, removing old versions, and implementing patch management and endpoint security controls on the client side. But consider additional controls specifically for Java. For example, an enterprise could run the JRE and necessary software in its own virtual machine, run the JRE with reduced permissions (which should already be a default policy regardless) and allow whitelisted Java applets to run in the JRE with Noscript or similar software. The Enhanced Mitigation Experience Toolkit can be used to more securely configure the JRE on Windows systems.
Enterprises could also compile Java code into native executables to avoid issues with the JRE, but this action would negate the "write once, run anywhere" benefit of using Java. Given that most Java applets are run on either PCs or Macs, this might be a reasonable measure for some organizations, but it wouldn't work for all platforms that run Java. If it could be compiled, this would help reduce the number of systems in an enterprise that needs a JRE installed just for one application. All of these methods require significant effort, but could reduce the risk to an acceptable level for most enterprises.
Conclusion The Java ecosystem pioneered many new features that made developing software for multiple platforms easier. The Java Runtime Environment was the result of that need for easier cross-platform development. Sadly, the reputation of the Java ecosystem has taken a significant hit due to the significant number of security vulnerabilities exposed in the JRE and Oracle's software development lifecycle. While organizations should think long and hard about committing to Java, fortunately, there are ways for enterprises to limit the risk posed to their endpoints by the JRE if it is a business necessity; if it is not absolutely necessary, however, it should not be installed.