Q

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 first published in August 2014

Dig deeper on Web Application Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close