Solve the Java problem

Last Updated on November 25, 2016 by Dave Farquhar

I met with a client earlier this week who asked me to go over their vulnerability scans for a bit of a sanity check. He asked some important questions, but one in particular seems worth sharing. What can we do with Java? Can we solve the Java problem?

There are two things you can do with Java to significantly lower the risk of keeping it around. First, use the Deployment Ruleset to create a Java whitelist. This allows you to specify what Java apps can run and, importantly, which JRE they can run with. This solves both usability and security problems, which is important. I’ve run into environments that had apps that needed JRE 1.6.20 and 1.6.22, and that meant those apps couldn’t coexist on the same machine. But with the deployment ruleset, they can–and then you limit the use of that ancient JRE just to that particular app, which makes it much more difficult to exploit that JRE. An attacker would have to first plant the exploit in that whitelisted app. That’s doable but it requires a level of sophistication you don’t generally see, or at least hear about.

The second thing to do is install EMET.  EMET doesn’t break every exploit, but it breaks a good number of them, so it gives you an additional layer of protection.

By putting those two mitigations in place, odds are you’ve reduced the risk to a point where your IT leaders and business leaders are willing to accept it. Odds are they’d be willing to accept a great deal more than what you end up with after doing these two things, but why accept more risk than you need to?

For that matter, even in a perfect world where you replace your JRE with the newest one every time a new one is released, I would still recommend doing these two things. I’d be more comfortable with a whitelisted and EMETed 1.6.20 in my environment than an unprotected current version, regardless of what the vuln scanner says.

If you found this post informative or helpful, please share it!