Security vendor Sourcefire said that Java is responsible for 91% of attacker entries into networks, with the possibilities...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.)
Learn how removing Java updates could affect your systems
Dig Deeper on Web Application Security
Related Q&A from Mike Chapple
The OWASP Top Ten list is not a compliance standard but a set of best practices for enterprises looking to boost Web app security. Here's how to get ...continue reading
A data breach notification policy is important to have, but deciding how to alert customers can be tough. Expert Mike Chapple explains some best ...continue reading
Tokenization technology can be confusing. Expert Mike Chapple explains what the difference is between two types of tokens and how tokenization can ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.