It seems that every week brings a newly-reported Java vulnerability. Today we see a report of a new vulnerability present in current and older versions of Java 7, and “now in-the-wild” attacks against older vulnerabilities that have since been fixed on current versions.
If you think these vulnerabilities are of no concern to you, think again. According to the above-linked article, even employees of Facebook, Twitter, and Apple experienced attacks when visiting a developer website. If this vulnerability is hitting experienced technologists working for the big boys, you can probably assume your staff are at risk too. Especially if you’re not managing Java version compliance within your organization.
What’s a company to do? As with everything else IT, the answer is “that depends”…
Does your organization rely on Java? If you don’t need it, purge it. Ban it from your network. Why take unnecessary risks with Java when none of your business applications require it? Users without Admin rights won’t be able to install it, but that doesn’t mean it hasn’t found it’s way onto a machine by some Admin at some point. Appcast customers benefit from a detailed software inventory of all managed machines, so we can tell at a glance whether there are any Java installations to get rid of. And our Application Compliance service can monitor your network for future Java installations, to raise an alert or automate its removal.
But let’s say you rely on Java for a particular application. Since you can’t purge it, you have a couple of options to limit its exposure, and they’re not mutually exclusive:
- If only a portion of your users need to use the Java-based application, limit Java to those users only. To do this effectively, you’ll need a technology solution like Active Directory with Group Policy (which Appcast can help manage). This won’t make you immune to Java vulnerabilities, but it will help reduce your exposure to the risk simply by reducing the number of devices running it.
- Many security organizations, including the Department of Homeland Security in the US, recommend disabling the Java plugin in the browser. The method to do so varies between browsers, however there is a setting in the Java control panel called “Enable Java content in the browser”, which can be unchecked to disable Java across all browsers. Future deployments of Java should also be configured to disable Java browser plugin registration. Again, this doesn’t immunize you against Java vulnerabilities, however it significantly reduces your exposure to risk because your users can’t be attacked just by visiting a nefarious or compromised website.
Lastly, stay on top of Java updates. But be aware that Java’s automatic updater doesn’t actually install updates automatically, which means your users are in full control of whether or not critical updates are installed to their machines. We recommend using a software deployment service (happily offered by Appcast to our Proactive and Managed customers), to disable Java’s updater and push the latest updates to all users. Although this means that whoever is doing the pushing has to constantly monitor the Java site for new releases, it ensures Java version compliance across the board, which is far less risky than leaving it at the discretion of each user.