The Java Runtime Environment (JRE) is one of the most widely installed software programs. It is seen as critical...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
to so many organizations because it provides an abstraction layer in enterprise systems, allowing software to be written in one programming language with one code base, and then run on many different operating systems and devices. Many enterprise applications are written in Java using the JRE and have the allure of multi-platform support and simplifying software development. The more practical reason that JRE is so popular is because many mission-critical applications use it, and enterprises are often locked into using these applications.
Unfortunately, a large percentage of malware targets the JRE because it is so critical to an enterprise. Along with having a large user base, the JRE is also more complex than many other pieces of software because of the significant number of devices it supports and functionality it provides, meaning there are many places where a potential attack could be harvested. A majority of this malware targets Windows and Mac systems, but mobile Java-based malware is starting to also gain steam. The JRE on other platforms, such as toasters and embedded devices, has so far steered clear of malware incidents, one of the many positive aspects of Java. However, a long line of incidents and patches illustrates that no Java implementation stays secure for long.
Constant enterprise threat from Java JRE malware
Because the JRE on Windows and Mac platforms has been such a serious problem, enterprises may want to determine the costs of disabling the JRE altogether versus the cost of a serious security incident involving the JRE. While this may prove a difficult exercise, as the cost of a JRE malware incident and the cost of disabling the JRE can be hard to quantify, it is one of the key parts of risk assessment. Estimating the cost of a security incident can be done using the Ponemon Institute's Cost of Cybercrime Study. The costs to mitigate the risk by removing the JRE or implementing sufficient additional security controls would require performing a total cost of ownership for the potential strategy. This TCO would need to include any estimates around other enterprise applications that may also require the JRE.
And how does an enterprise even know if it is at risk of becoming a victim? History has proven that organizations with mission-critical applications, such as enterprise resource planning, training or customer relationship management, that rely on the JRE are at the highest risk.
Unfortunately, as long as they profit from their endeavors, attackers will continue to find new vulnerabilities in the JRE -- especially those that will impact the largest number of systems -- by monitoring for new functionality or bug fixes or attacking the sandbox. And as long as enterprises continue to leverage Java-based applications without the proper additional security measures installed, enterprises will continue to fall victim.
What, if anything, can be done by enterprises
If disabling Java isn't a realistic option, there are numerous steps an enterprise can take to prevent falling victim to Java-based malware. First and foremost, be sure that your enterprise is using the most updated JRE. And if you haven't already secured endpoints by running an antimalware network appliance, relying on signed applets and whitelisting, you must start there.
However, due to the increasing complexity of Java and JRE vulnerabilities, new defenses must also be considered. Trying other, less traditional options -- such as running the JRE in a sandbox or in a virtual machine, using a remote display, or converting Java applets to direct executables -- might help limit the risk to the endpoint. For example, using a Linux back end with JRE support where an applet is executed in a VM or using a remote system with the display set to local can stop Windows-based malware from attacking the system. Alternately, a sandbox could run the JRE or applet in a restricted environment that limits access to the local system and monitors for potentially suspicious behavior. On the other hand, a full VM could provide similar protection in a potentially less restricted and specialized environment where multiple applets or applications could be used (however, this would require management of the VM). Another option is converting a Java applet to a regular executable -- this might remove the requirement to use the JRE while still allowing the applet to execute. Note: Each of these options would require significant testing to determine if it would work in both the environment and the application.
Also note that all JRE-based attacks that use IP for the command and control connection have one key weakness: They require connectivity to an IP network that should be monitored by security tools. While monitoring for suspicious IP connections requires significant effort, monitoring for anomalous behavior requires less, and could help identify systems that will require further investigation. This calls for establishing a relatively long baseline of standard known good behavior, but anything outside of the baseline could be investigated. If the attack uses Bluetooth or other wireless connections for connectivity rather than IP, this would be significantly more difficult to detect by monitoring IP flow data.
Enterprises should also forcefully advocate that their vendors either develop a non-JRE version of their application for enterprises with security requirements or develop a version that is not dependent on old versions of the JRE. While the costs of switching to a different mission-critical application are significant, they should be compared to the cost of a risk from a security incident solely resulting from a JRE vulnerability.
When it comes to third-party software, liability for commercial software vendors might help change the costs for vulnerabilities in the JRE. Currently, enterprises are being forced to incur these costs, but making commercial vendors share some of this liability may incentivize vendors into using programming languages other than Java in their applications. Alternately, this might include formally supporting vendor JRE applications running in an environment where the other security controls are also used.
The Java JRE has taken significant criticism because of a long history of security vulnerabilities, but remember that security incidents are not solely the fault of a JRE vulnerability. If an enterprise's security can be significantly compromised by such a vulnerability, it should re-assess its information security program to see if it has robust processes in place for managing IT security risk.
But it's worth reiterating that any enterprise that thinks the JRE is such an important application to its business that it can't be eliminated must weigh this against a potential JRE-related security incident. Note that the programming language and application server themselves are not the problem; rather, the issue lies in the JRE, primarily on Windows or Mac OSes, where an attacker can escape the JRE to run malicious code on the endpoint The JRE also has frequent updates, which is good but makes it difficult to deploy and test updates. If an enterprise is unwilling to critically evaluate itself and its environment to identify what is and isn't working to put the proper security controls in place, then it will inevitably face numerous risks from JRE and ultimately be unable to protect itself properly.
Unfortunately, there will continue to be JRE vulnerabilities, and an enterprise needs to critically evaluate its risk and what security controls it has in place to manage this risk.
About the author:
Nick Lewis, CISSP, is the information security officer at Saint Louis University. Nick received his Master of Science degree in information assurance from Norwich University in 2005 and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and at Boston Children's Hospital, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.