This article can also be found in the Premium Editorial Download "Information Security magazine: Security Readers' Choice Awards 2012: Your picks for the best security products."
Download it now to read this article plus other related content.
Vulnerability management is a time consuming, complex process and the recent onslaught of attacks on Java hasn't made it any easier. To recap: In August, security researchers reported that
All the Java security problems – and a growing track record of security snafus with the popular programming language -- led to calls from a number of security experts to disable Java. Tod Beardsley, Metasploit engineering manager at Rapid7, says that's simply sound advice.
"For the Java browser plug-ins, users should disable Java. Unlike Flash, HTML5 or even PDF, it's not ubiquitous technology on the Web…Disabling unnecessary functionality is always good advice – doing so reduces your attack surface," he says.
In the enterprise, however, shutting off Java is easier said than done. A number of common business applications such as conferencing and collaboration rely on the Java runtime, and some data center applications run on Java, says Scott Crawford, managing research director at industry analyst firm Enterprise Management Associates.
"Pulling the plug on Java in a business is not going to be a slam dunk by any means," he says.
With Java interfaces developed for a wide array of enterprise systems, the popular platform-independent programming language "tends to be used everywhere," says Paul Hill, senior consultant at SystemExperts.
And its pervasive nature is what's making Java attractive to attackers. That wasn't the case a few years ago. Wolfgang Kandek, CTO of Qualys, says Web browsers used to be a prime target for attackers until browser makers developed better security defenses. Attackers shifted their attention to other software such as Flash and PDF, but now Adobe has put a lot of resources into hardening its products. Now it appears Java is in the crosshairs.
So what's a company to do? While organizations can apply extensive protections in the data center, it's more problematic on the endpoints, Crawford says. Kandek acknowledges that controlling use of Java in the enterprise is complicated: "There's no simple answer." Organizations need to take stock of applications they use that require Java and find workarounds or use whitelisting, he says.
Microsoft Internet Explorer provides the ability for companies to whitelist by implementing the security zone mechanism, Kandek says. He recommends banning Java in the Internet Zone and only allowing websites where it's needed in the Trusted Sites Zone. Beardsley says Firefox's NoScript plug-in is a fairly easy solution that IT can either train users on or deploy for them.
Kandek says a workaround for some applications that use Java might be a native client; for example, if a user has the WebEx client, then the conferencing program won't need Java on the user's machine to run.
SystemsExperts' Hill recommends that organizations take a defense -in-depth approach by keeping Java patched, maintaining updated antivirus, and using network security devices such as IDS/IPS and SIEM. Beardsley says proxy and egress IPS devices could help a network manager who can't control all desktops directly by blocking Java applets over HTTP. "With a combination of desktop configuration and network management, I don't think it's unreasonable to pursue a block-and-whitelist strategy," he says.
However, companies are finding other ways to avoid Java. Hill sees many organizations that are phasing out dependencies on Java applets. "Now people are developing rich Web applications using Ajax techniques so Java is on the server and not executing on the client," he says.
And of course, Oracle could do a better at correcting Java vulnerabilities. With attackers targeting Java, there's "all the more reason why Oracle needs to step up" the same way "Microsoft was compelled to deliver on vulnerability remediation in the past," Crawford says.
About the author:
Marcia Savage is editor of Information Security. Send comments on this column to firstname.lastname@example.org.
This was first published in September 2012