Security vendor Sourcefire said that Java is responsible for 91% of attacker entries into networks, with the possibilities...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
A proposed cyberattack information database in the U.K. aims to improve cyberinsurance. Expert Mike Chapple explains what collecting data breach ...continue reading
The proposed CFTC regulations on cybersecurity testing are set to finalize in 2016. Expert Mike Chapple discusses the effects these regulations have ...continue reading
Whether Apple is a HIPAA covered entity was called into question when it advertised for a health regulations lawyer. Expert Mike Chapple discusses ...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.