As most Cyber Security professional will tell you, you should avoid installing Java unless you really have to have it, as the exploitation of Java vulnerabilities is a typical culprit behind web-based desktop compromises. Recent data from Sourcefire shows that Java exploits make up a staggering 91% indicators of compromise.
The Java Applet Risk
Why old versions of Java are still Present in the Enterprise
The reasons why unsupported versions of Java are still present in the enterprise, can be often attributed to internal business applications and custom written Java apps, which simply do not work with the latest versions of Java. In other cases it is a lack of desktop application patch management and desktop application control which is to blame, this is often coupled with low awareness and understanding.
Managing and Mitigating the Enterprise Java Risk
The first course of action is to understand the extent of Java installations within the enterprise, this can be achieved by using application auditing tools to ascertain Java installations, including version numbers and patch level. Next is to review the business reason for each Java installation, ensuring there is a valid reason for its presence, namely to run a specific business application. Sometimes Java is a legacy presence for applications which are no longer used or exist. If there is no reason for Java to be there, remove it and then prevent users from installing it. It is surprising how many users are duped into installing Java on their desktops when visiting websites, when they don’t actually require it.
Where Java is required for an application, verify if the application is web browser based. If not, disable Java from running within the web browser, preferably by enforcing it using enterprise management tools. This significantly reduces the risk, as it is the potential of users executing untrusted Java applets while visiting dodgy websites online which poses the greatest risk with unsupported Java versions.
Where applications are reliant on old Java versions, it can be just a question of raising the issue with developers and suppliers, and pushing them into making their applications and applets compatible with the latest versions of Java. Sometimes there are cost issues here, as developers tend to charge for software upgrades, however there really shouldn't be any excuse for applications not to be continually supported to be secure of vulnerabilities as part of their life-cycle of use. An application that doesn't work with any of Oracle's supported versions of Java, can be regarded as having its own security vulnerability. Continued patching of systems and applications is a fundamental enterprise security best practice, neglecting patching leaves doors of vulnerabilities open for cyber attackers to exploit.