Java, the popular OS-independent platform and programming language, runs on just about every kind of electronic device imaginable, including computers, cell phones, printers, TVs, DVDs, home security systems, automated teller machines, navigation systems, games and medical devices.
In response to successful Java-based exploits against companies like Twitter, Facebook, Apple and Microsoft, and continued concern over “zero-day” security flaws that could allow an attacker to remotely execute malicious code that could compromise vulnerable systems., the U.S. Department of Homeland Security’s Computer Emergency Readiness Team (CERT) has issued multiple security advisories concerning Java.
In the advisories issued to date, DHS recommends disabling Java in web browsers. In response, Oracle, which took over Java when it bought Sun, has released a number of patches, some out-of-band (earlier than scheduled), and in a recent patch made changes to how Java applets are handled within web browsers.
In general, warnings potential security threats are nothing new and most network security managers consider them to be part of the daily IT landscape. The usual solution is to patch systems with vendor-supplied updates and follow vendor recommendations for best practices. However in this case, the advice to disable or uninstall the product, issued not by the vendor, but instead by governmental authorities and other third parties, creates an unusual set of challenges for organizations.
So, here are seven steps you can take to protect your network against Java-based exploits. Given its ubiquity, completely removing Java is probably out of the question for most organizations. But here’s a seven-step action plan that won’t necessarily guarantee security, but will help mitigate threats by creating awareness, hardening systems and reducing attack vectors.
1. Perform an impact analysis
A good starting point is to identify where and how Java is used both inside and outside the organization. Does your organization provide Java-dependent applications that are accessed by vendors, clients and/or the general public? Unless you have already taken steps to limit the use of Java, you most likely will find it present in most Internet browsers, as part of the OS (especially certain versions of Mac OS) and in any number of popular applications. The latter is probably going to be the biggest unknown as a vast number of commercial and open source software applications are built on the Java platform. Start by ferreting out which applications use Java. Is the app business-critical? Knowing the full scope of your organization’s dependence upon Java-based apps and platforms is a necessary prerequisite to controlling risks.
2. Keep Java updated and patched at all times
It is of paramount importance to keep all computers and devices up to date with the latest version of Java. Oracle supports only the latest version – no security patches are available for previous versions. Obtain updates directly from Oracle to reduce the risk of code injection. Another important step is to uninstall older versions of Java manually, as simply installing the latest version does not necessarily ensure that older versions are removed. Consider limiting the use of Java-based apps to virtual machines that can be started up when needed and left unpowered when not.
Also keep in mind that some applications may use earlier versions of Java, and these could break after updating to the latest version. If your app relies on an outdated version of Java, this poses a much greater security risk and any outdated apps should be be updated or replaced.
3. Manage Java Control Panel settings
There are numerous settings available from the Java Control Panel (available on both Windows and Mac clients). These provide fairly granular control of how Java is configured on client computers from automating updates to managing security settings. Automatic updates can be configured to notify or download the latest update, but regrettably there is no current enterprise-wide capability to automatically install updates. This means manual steps are needed to ensure the latest updates are applied.
As for security settings, the last few updates of Java version 7 have been automatically set to use the ‘high’ security setting, which is designed to prompt users before running unsigned or self-signed applets. This is a change from recent versions of Java where the default was ‘medium’. From the Java Control Panel, you can also disable Java when you’re not using it, but there are some reports of unsigned and self-signed applets being allowed without prompting when you re-enable Java.
4. Harden web browsers
Wherever possible, disable Java in web browsers. If for some reason this is not an option, at least consider disabling remote access to Java applets. One solution is to use a proxy server that restricts remote Java requests, but allows them locally.
Another approach recommended by some IT administrators is to use two different browsers, one that has Java enabled for use when you absolutely need to access sites requiring Java and one for all other browsing. Enforcing this is in the enterprise might be challenging, but you could set up proxy rules that only allow one type of browser to access Java sites, while blocking others.
5. BYOD endpoint control
In this age of BYOD, grappling with the many personal devices employees use to connect to the corporate network presents its own set of challenges. Java is widely used in mobile applications so you may want to develop corporate policies to govern how BYOD access is provided. Several of the newer ‘smart devices’ running Android, iOS, Windows Phone and Blackberry 10 operating systems do not embed Java. However, the Nokia 40 series and the Bada operating system developed by Samsung, an OS that is becoming more popular, are both Java-based. Also, it should be noted that since Java ME (Micro Edition) is restricted to JRE 1.3, it is somewhat unclear if any of the latest vulnerabilities are present in Java ME. However, by implementing endpoint control policies you can ensure that access to the enterprise network is restricted to only certain types of devices with the latest updates applied.
As mentioned in the introduction, Java is also used in a variety of other devices such as printers, security systems, payment terminals, etc. Try to identify all devices used in your organization that rely on Java and work closely with vendors to manage risks. Depending on the size of your organization, this may require a task force.
6. Review Java impacts on corporate websites and customer portals
7. If you are developing in Java, do so responsibly
If you are developing in Java, don’t add to the industry-wide problems by producing unsigned or self-signed apps. Sign all apps using a trusted certificate authority and adhere to other industry best practices for Java development. In an effort to encourage developers to use trusted certificate authorities, Oracle’s Java 7 Update 21 raises more red flags to users about the security risk of running unsigned applets.
Some third-party solutions such as the Entrust Authority Security Toolkit for the Java Platform allow Java developers to add security-related features like encryption and digital signatures to their applications.
Of late, Oracle has significantly stepped up its efforts to correct flaws and vulnerabilities in its Java platforms. However this is playing out as a game of cat and mouse, as new exploits are discovered sometimes within hours of the latest patch. The rapid change cycle is also causing other collateral consequences. Some users report being able to run unsigned applets in IE9 on Windows 7 even if the settings are ‘high’ or ‘super high’. Others are reporting issues with legacy applications not running properly under the latest releases of Java 7. Suffice it to say that many Java platforms and applications are in a state of flux, with security concerns remaining. Hence the need to keep a watchful eye. Oracle declined comment on the topics in this article.