With the Oracle CPU fresh in our minds I thought this would be a good time to discuss a well-known issue for IT Admins around the world; updating Java only to find it breaks something in your users environment. More importantly updating Java only to find that a mission critical app is broken. Java is running everywhere. It is one of the most popular development languages and responsible for a significant chunk of cool web development that has occurred over the past decade. The Jave Runtime Environment (JRE), which renders all of the awesomeness that is Java, quickly turned into the bane of many an IT Department.
According to Cisco’s 2014 Annual Security Report, Java was involved in 91% of web exploits and the majority of those exploits were for versions of Java that were outdated and vulnerabilities that the vendor had already plugged. That is a pretty staggering number and makes one wonder why you would choose to utilize a product that relies on Java. So where does the fault lay? Is it Oracle and prior to them, Sun to blame for the vulnerability of their development toolkit? To a point, yes, you can say they are responsible, but they also resolve MOST of the known vulnerabilities that are identified in a timely manner (and have improved significantly over time). There is still a bit more blame to go around however.
You can google ‘java upgrade issues,’ and you will find ample evidence as to why an IT Admin would be a little gun shy around a Java update. FireFox, Netscaler, printing issues, and especially Minecraft (heaven forbid!) can all be found in the first page of recent Java upgrade issues. Some others that typically occur are those back office applications that make the business run. ERP solutions or other critical apps that help you ship product, process orders, etc., could all rely on Java. Break those and you may be talking about an RGE (Resume Generating Event). So, no one party really is to blame here. We have Oracle trying to resolve vulnerabilities in a timely manner and improving on that front. How about the vendors and the companies who are running Java? You may need to evaluate a little closer to home and see why you are not upgrading.
Ask your venders:
- If the latest version of their product supports the most recent Java updates?
- Do they support updating Java as new versions are released?
- How do they communicate whether the latest Java update will be compatible with the version you are running?
- Are we running the latest version of the vendors software?
- What are the limitations to upgrading? Customization that would not be supported if you upgrade, cost of upgrading, etc.
- What is your exposure by not upgrading?
The IT world is full of exceptions to the rule. For every exception there is some risk. Have you evaluated that risk and have you mitigated your exposure?
Things you can evaluate if you know you have a dependency on an outdated version of Java:
- Are only required users able to access the outdated versions of Java?
- Can the privilege level of the users who need to run on the at risk machine be reduced to mitigate exposure if certain vulnerabilities are exploited?
- Are the machines running Java able to be virtualized and segmented from parts of the network that have direct Internet access?
- Can you lock down the machine in question to only allow access to the one application Java is needed for and all other web browsing, email, etc. be locked down?