Reducing Risk and Making the Most of Java (Part II)

The number of major websites requiring Java is on the decline, while risks from Java vulnerabilities are on the rise. Some organizations look to patch management for a solution. Other companies want to simply shut down Java. But neither may be possible for a variety of reasons.

Many organizations use specific, business-critical applications that rely on Java, and many of those applications are Java version-specific. If Java is shut down for specific groups, some users will require older versions and others will need the latest update. This is where we get our first glimpse of the challenges in managing Java risks.

Patch Management: Desktop, Mobile and Automatic?

Patch management can be a complicated process for an organization, especially those with remote workers. There are a number of factors at play. A mobile workforce is hard to patch and Java has a cross-platform footprint. Java also updates independently from the vulnerable apps, such as browsers, that use it.

Interestingly, many corporations run tightly managed desktop environments. Before deployment, new patches are carefully tested for app compatibility, system stability and other critical factors. Everyone understands how a single update and a rush to patch could take down business-critical applications. It's critical that the Java patch process matches the fast paced zero-day exploits. Current security defenses may, or may not, provide organizations with the time for compatibility and other validations.

Some have suggested that automatic Java updates could help users stay current, similar to the update model Google adopted to some success with the Chrome browser. Unfortunately, that model would still not address the frequent problem of zero-day Java vulnerabilities. There is still a level of exposure between the revelation of a new vulnerability and the issuing of a patch. Earlier this year, a new Java vulnerability was widely publicized within 48 hours of a Java patch, and was in the hands of cybercriminals even sooner.

Blended Best Practices Reduce Java Risk

So what are the logical best practices when balancing the needs of the business with the need for enterprise security from Java vulnerabilities?

I believe it's a blend of tactics: patching, uninstalling Java and implementing the Alternative Browser approach. Real-time defenses are the most effective, but I will introduce those separately in the next post when we discuss where Java plays within the Seven Stages of Advanced Threats.

It is important to note that 'uninstall' is a relative term here, because of the challenges we outlined above. For most organizations this is really more of an excisional biopsy approach, where they will remove as much Java as possible. For example, you can set up a trial "disable Java" program in your organization to help identify any repercussions. Other than a few business critical applications, this shouldn't break your internet because fewer sites require Java for functionality.

For those sites or applications that require Java, you can offer designated Java workstations, properly segmented from other parts of the network. Many IT organizations have old laptops they can repurpose for this next to the shared printers. You can also take the dual browser approach, where a specific, secondary browser is used to access designated applications. Configurations on this Java-enabled browser can be tightened down to mitigate risk by only allowing these browsers to access specific sites. You can further mitigate mistakes by preconfiguring bookmarks to the necessary sites and applications. The 'primary' browser would have Java removed entirely.

Security Solutions Need to Be Zero-Day Aware

Unfortunately, zero-day Java-based exploits continue to rollout so even patch management, segregated Java machines, multiple browser configurations and other controls cannot eliminate risk exposure. Security solutions must become increasingly 'zero-day aware,' particularly for Java threats, an area where many provide very limited coverage.

We can take proactive measures by applying pressure to application vendors to ensure that their software is fully compatible with the newest version of Java. In-house developers need to learn and apply security best practices in their development. This includes programs designed to support updates by avoiding use of undocumented features or 'workarounds'. Legacy applications are often one of the items anchoring the IT department to previous Java versions. Organizations are forced to pay the price in reduced security after corners are cut in development.

But really, how much should this concern you? Even if there is a zero-day or a gap, you are only at risk for a week, right? Not so fast. In my next blog, I'll discuss Java zero-days and exploit kit adoption and review the aforementioned multistage attack model. When you look at the relationship these have with our current research, you may begin to have a different perception of the true Java challenges in today's IT infrastructure.

Read Part I of the series: I like my Java straight; no cream, no exploits… (Part I)