We beg to differ
Op-Ed: Replacing legacy Java applets can’t happen overnight
“The facts are too startling to ignore. It's time to get rid of Java on clients.” That’s the advice of Roger Grimes, InfoWorld security columnist, in response to news that 91% of all web exploits in 2013 used Java.
“It's time for computer security to win out,” rallies Grimes. “I'm not naïve. I realize this will result in all kinds of pushback from those who say it's too difficult to retire Java applications or rewrite or replace them. But it must be done.”
Grimes’ attitude is a bad stereotype of internal IT security – like the Dilbert character who declares that “security is more important than usability; in a perfect world no one would be able to use anything”.
The world is, for better or worse, still heavily dependent on Java applets, a fact which came to light in a dramatic fashion when headstrong Firefox developers decided to block it by default.
Thanks to a poorly-designed UI, thousands of Firefox users found themselves unable to activate Java applets – not just old internal systems either, but essential services such as Denmark’s national login, which still relies on Java. Overwhelmed by angry messages, they quickly changed it back.
As Grimes correctly points out, the biggest security issue is that many companies are afraid to upgrade Java on their systems, scared of incompatibilities between their ancient software and the latest patches (which, despite being more secure, are not without their problems). But his proposed solution – to replace the offending Java applications, whatever the cost – is hardly a realistic option.
If these security risks are likely to cause financial harm, only then is it likely that a portion of an organisation’s recession-squeezed budget will be allocated to the redevelopment. And even then, your new, expensive project is likely to fail. No wonder organisations are loathe to replacing these exploit-assisting legacy systems.
Limiting the damage: a quick guide
So if replacing your out-of-date, Java 6-based application is out of the question, what’s the solution? Well, assuming that admins have control over employee’s computers, Java should be blacklisted on every site apart from those internal systems that need it. This is even possible with Internet Explorer 6 on Windows XP, so there’s no excuse not to.
Another method is to simply ensure that all employees are running a modern browser. The latest versions of Chrome and Firefox (and presumably most other browsers) automatically block all versions of Java without user interaction, preventing drive-by attacks. Combined with a whitelist, this could be very effective at keeping users safe.
The weak link is where users’ browsers are beyond the control of admins, such as in the case of Denmark’s national login. Only in this situation is there an ethical imperative replace Java – but hey, we all know how government IT projects tend to go.
As always, JAXenter’s recommendation for users and companies with no need for Java applets is to disable Java in the browser or uninstall it altogether.