A lot of IT security professionals are trying to lower their consumption of java, and not necessarily coffee.
In the face of ever-increasing Java exploits — some 60 were discovered last year alone — some enterprises have decided it’s better to turn off end-user access to Java applets in browsers than risk the corporate network and data.
But an expert says with care you don’t have to get burned.
“The bottom line is Java is ingrained in the enterprise,” Craig Freyman, a senior security consultant at FusionX, said in an interview this week during the SC Congress security conference in Toronto. “A lot of legacy applications use Java.” IT departments may want to move away from it in the future, but not for the time being.
Freyman and colleague David Rude II, lead security researcher at FusionX, a U.S.-based risk management and penetration testing consultancy, told the conference there are ways of living with Java that won’t endanger the enterprise.
First, Freyman said, inventory the organization to find where Java is running and which business units need it. “If you don’t have a handle on where it is the remaining solutions won’t work well.”
Second, filter at the gateway for Java malware. That, he admits isn’t foolproof – there are ways of getting around a gateway.
The main weapons is a Java deployment ruleset. “It’s basically an XML file that’s turned into a JAR (Java Archive) file, which sits on the local system. It’s essentially a whitelisting solution, that says Java is allowed to run here, here and here, and if it doesn’t match any of those locations, block it. And it works” — as long as all PCs are running the latest version of Java.
Specific domains can be whitelisted and even bad certificates that are used for signing the applets.
“Its a complex problem,” Freyman said, “because the way Java is architected is somewhat broken, also the way Oracle has tried to Band-Aid the situation with excessive security prompts, because we’re training our users who likely don’t have the knowledge to know if the applet is good or bad.” As a result, many just click “I agree. Run.”
The major problem with Java, says Rude, is the attack surface is so big — APIs, code verification, the process — where exploits occur.
“The deployment ruleset is a good option because it works on all browsers, works on all operating systems and it’s scriptable — you can deploy it through policy. We haven’t seen any exploit yet that can bypass it.”
