alphaspirit - Fotolia

Manage Learn to apply best practices and optimize your operations.

Reducing the risks of Java security updates

Installing Java updates for security can be troublesome, so should companies still do it? Mike Chapple discusses Java and compliance issues.

Security vendor Sourcefire said that Java is responsible for 91% of attacker entries into networks, with the possibilities linked to major sources like Microsoft Office, Adobe Reader and others. Adobe's software, in particular, has taken much abuse from hackers over the years, so those numbers really stand out. From a compliance perspective, will an organization run into issues with the likes of HIPAA and PCI DSS if they don't eliminate Java from their environments, or at least lock it down?

Java is indeed a top target on the radar of those seeking to undermine the security of company systems and networks. The platform has a long history of security vulnerabilities that required patching, and information security shops around the country know that staying on top of Java patches can be a nightmare. Often a necessary Java security update that exposes them to risk unless patched exists, but it deals with critical applications that will cease functioning if clients are upgraded.

From a compliance perspective, there's no specific requirement to eliminate Java from an environment. The challenge, however, is that most compliance programs require the application of vendor-supplied security patches within a reasonable period of time. Hence the security administrator's dilemma: run a vulnerable, noncompliant version of Java or upgrade and break the application. That's not a wonderful decision to be faced with!

If you have the luxury of eliminating Java from the environment, it would be a move that will surely save you some grief. If that's not possible, the other option is a compensating control. PCI DSS, for example, allows for the documentation of cases where you are unable to comply with the standard and implement a compensating control that uses additional security mechanisms to fill the gap. You'll need to demonstrate that the compensating control is sufficient in your environment, but this is feasible.

If a Java update is impossible, try isolating it. Perhaps virtualizing the Java application or running it on a tightly locked machine that has minimal exposure to Java would work as a compromise. Alternatively, there may be a way to remove cardholder data from the business processes requiring Java and pull that application out of the scope of the cardholder environment. In this situation, I suggest sitting down with the QSA and working through some scenarios before investing in technology and design work.

Ask the expert!
Got a vexing problem for Mike Chapple or any of our other experts? 
Ask your enterprise-specific questions today! (All questions are anonymous.)

Next Steps

Learn how removing Java updates could affect your systems

Advice on identifying Java security vulnerabilities

This was last published in August 2014

Dig Deeper on Web application and API security best practices

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

I haven't yet read Mike's article but when I first saw this question, I had to think: What's the business risk? You can address compliance and be "compliant" until the end of time. However, unless and until you know how a threat or vulnerability is creating actual business risk, you can't make informed decisions about what needs to be done to reasonably address the issue.