Recently security firm Qualys warned that huge numbers of global businesses were at risk of cyber-attack because of a security flaw in Java 6. The fact that there is no patch available for Java 6, as it reached 'end-of-life' in April 2013, means that the software's vulnerability will be very tricky to fix.
This is a concern every time a software package loses support, but the Java 6 flaw is particularly worrying because of the high number of users who are still using Java 6 software, which means huge numbers of organisations are vulnerable.
Patching or upgrading is not always an option due to other software dependencies – which to be honest should never be tolerated from a software supplier, but is often a reality with legacy in-house applications. In this case the next best course of action is to minimise the potential threat by understanding the distribution of the vulnerability and the potential data exposure.
I would urge ICT teams within effected organisations to implement the following three steps to ensure they minimise their exposure:
1) Subscribe to security bulletins such as Qualys's. There are plenty reputable lists out there and not knowing that a threat existed is not going to wash when you are need deep in problems.
2) Audit your ENTIRE IT estate regularly so you understand your exposure and can make prudent decisions based on accurate data.
3) Patch wherever and whenever possible to remove threats. Minimise exposure but limiting access to data where patches cannot be applied – and then pressurise dependent software providers to upgrade their applications.
It's worth pointing out that any application that has to work across multiple platforms will be vulnerable to threats, whether it's based on Java, Flash, Adobe, Silverlight or the like.
Creating a cross platform system by definition involves compromise. App developers need to make design decisions that head off threats, but at the same time, they often struggle to implement best practice on each system because that most often will affect cross platform compliance.
As a result identifying individual flaws in an app, like the one we see with Java 6 is interesting, but incomplete. ICT teams won't get anywhere without having complete visibility of all of their devices, the apps or software installed on those devices and a way of managing them centrally.
The only way to manage an issue like the one we are seeing with Java 6 efficiently is for ICT teams to know exactly where they have a particular software or app installed; what versions their devices are running and what data will be exposed if the software is compromised.
The best way of doing that is for teams to install a centralised device management solution. A simple audit tool will only tell ICT teams where the issues are - but a remote monitoring and management tool will do that, as well as giving them the tools to enable rapid updates (or data deletion/network exclusion) should they believe the vulnerability has been exposed.