alphaspirit - Fotolia
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.)
Learn how removing Java updates could affect your systems
Dig Deeper on Web application and API security best practices
Related Q&A from Mike Chapple
Explore the differences between wired and wireless network security, and read up on best practices to ensure security with or without wires. Continue Reading
Choosing to encrypt confidential data with AES or DES encryption is an important cybersecurity matter. Learn about the important differences between ... Continue Reading
It's not possible to eradicate the risk of DoS attacks, but there are steps infosec pros can take to reduce their impact. Mike Chapple shares ... Continue Reading