Patch Management Policies Can Put Java Users at Risk

On December 10, 2021, a vulnerability in the Log4j library was publicly revealed. Within the next week, cybersecurity company Contrast reported that about 58% of Java applications package a vulnerable version of Log4j2 (noting that the number may be slightly inflated), and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) mandated that agencies update software using Log4j to the newest version. Proper patch management policies could have kept systems worldwide a whole lot more secure. In July the Cyber Safety Review Board called the vulnerability an “endemic” problem that will pose risks for potentially more than a decade as organizations and hackers keep finding old applications that still have not been patched.

Companies are reviewing their patch management policies, which is a good thing. Senior executives are prioritizing detection and patching of common vulnerabilities and exposures (CVEs) in their Java instances to avoid all the things that come with compromised personally identifiable information. Things like hefty penalties, customer attrition, and reputation damage. The previous Equifax breach and subsequent fine were from their failure to patch an old Java library. During Log4j, the US Federal Trade Commission wrote a post reminding businesses that they issued the fine and planned to find companies who lose consumer data and fail to patch known vulnerabilities like Log4j. 

With the recent explosive growth of known vulnerabilities in third-party software components and applications, this seems like a good time to review some existing patch management policies and guidelines. 

Current cybersecurity concerns 

Vulnerabilities pose three main concerns for Java teams: 

• Additional software requirements: Most current tools need extra software to detect vulnerabilities. This places a larger burden on Java teams that have to deploy and manage this new software, its potential impacts on performance, and common additional steps in the CI/CD pipeline. Often software requirements miss applications or libraries from third parties and contractors. 

• Scanning activities: Random, limited scanning is not good enough given the sprawling, complex web of libraries and components in use by Java applications and architectures. Many instances of log4j were not web-accessible and could not be located by dynamic crawlers or defended by web-accessible firewalls (WAFs). 
• Lack of ongoing vulnerability detection: Even after companies patched the Log4j vulnerability, they often didn’t notice when it was inadvertently re-introduced because their systems of record still reflected that it was patched. 

When a new CVE is disclosed, millions of organizations are responsible for determining if the vulnerability affects them and how they should respond. Usually, patch management policies inform their actions. 

While some organizations keep lists of the software they run, few also maintain an inventory of the libraries inside each application. As a result, there are potentially unknown inventories of CVEs in their environment — especially in custom applications. Both the US (via CISA) and the EU (via enisa) are seeking to require creation and maintenance for this Software Bill of Materials. 

Common Patch Management Policies 

Here are some common patch management policies that you may have heard about: 

Australian Cyber Security Centre: “Essential Eight” 

The Essential Eight are strategies the Australian Cyber Security Centre recommends to improve cybersecurity. Currently, these are only mandatory for the government, though they are expected to apply to corporations as well within 18 months. 

These strategies are: 

• Application control
• Patching applications
• Restricting administrative privileges
• Configuring Microsoft Office macros
• Using application hardening
• Patching operating systems
• Using multi-factor authentication
• Regularly backing up systems

HSBC Bank Operational Security 

HSBC has multiple policies for mitigating operational risk. The cybersecurity section of its operational security framework sets measures in place like: 

• Regular internal threat-led testing, continuous vulnerability scanning, and an assurance regime that continuously tests the cyber control environment with the newest threats. 
• Ensuring staff is aware of cybersecurity issues and understands how to report incidents. 

U.S. Department of Homeland Security Binding Directive on Patching CVEs 

The American government published this directive in November 2021, mandating federal agencies in the country to patch many known, commonly exploited vulnerabilities.  

The directive gave agencies a timeline to review and update their vulnerability management procedures and set reporting requirements on the status of the vulnerabilities it covers. 

U.S. Cybersecurity and Infrastructure Security Agency (CISA) 

CISA manages a catalog of the vulnerabilities within the scope of the Department of Homeland Security’s Binding Operational Directive. Along with the list of vulnerabilities, it publishes thresholds and conditions for including and adding vulnerabilities to the catalog. These conditions include: 

• The vulnerability has an assigned CVE ID. 

• Reliable evidence shows that it has actively been exploited in the wild. 
• There are clear actions agencies can take to remedy the issue, such as an update from the vendor. 

CISA will also review the Directive in case there are changes to the cybersecurity landscape and may issue supplemental directions if necessary. At the end of each fiscal year, the agency must provide a status report that identifies outstanding issues with implementing the Directive. 

Executive Order on Improving the Nation’s Cybersecurity 2021 

This executive order called on federal agencies and public sector organizations to collaborate with the private sector, prioritizing data security and privacy for the country. Its main points included: 

• Removing barriers to sharing information about threats between the government and private sector. 
• Making a standardized playbook for responding to vulnerabilities. 
• Requiring federal agencies to log cybersecurity events to investigate remediation strategies better. 

Where do these policies fall short? 

The process of matching CVEs to software inventory sounds easier than it is. Here are some common challenges different teams encounter when trying to do this: 

Infrequent software inventory – Software inventory is often not done or is out of date. This is a shared problem because the engineering team needs to produce the internal software bill of materials (SBOM), and the Application Security (AppSec) team must produce or obtain SBOMs for third-party software. Even in companies where software inventory follows a stringent process, many teams conduct software inventory by periodically scanning the source code repositories from before deployment. This doesn’t guarantee that the code running in production hasn’t drifted from the code inventory – specifically it misses the situation where the vulnerability is considered “patched” from a scan but the patch is not rolled out into production. This is primarily an AppSec problem because simply having a patch or updated SBOM doesn’t imply that the secure version is in use. 

False positives – Current tools that test for CVEs generate many false positives, so independent software vendors and open-source developers receive countless requests to evaluate a constant stream of CVEs against their software. False positives stem from a failure to differentiate between code that is used versus code that is simply present. As a result, time, money, and talent go to waste patching systems that don’t need immediate patches — especially in AppSec teams. 

High costs – Rolling out updates to the entire infrastructure requires a lot of resources and exposes it to many risks. This is a shared problem, as any tool that analyzes code needs to undergo regular updates and maintenance. Java teams generally don’t want to maintain these tools, and AppSec teams can’t engage with environments they don’t own. 

Testing is slow – Testing new updates takes too long, heavily weighing on Java teams that want to test their own applications rather than simultaneously testing their application with third-party tools. Slow testing also puts the infrastructure at risk if new High-Severity or Critical-Severity CVEs get disclosed for public use since a bad actor could exploit it before teams can implement a solution.

Be careful out there 

Since CVE detection tools are imperfect, it’s more important than ever to optimize processes. Some best practices include: 

• Better patch management rules – Follow CISA’s mandate to implement application inventories with SBOMs, and update to the newest version of software as soon as it is available, especially if it uses Log4j 
• Better CVE tracking – Monitor CVE.org and the National Institute of Standards and Technologies list of CVEs to recognize known vulnerabilities in your environment 
• Better environment tracking – Catalog and always know what’s running in production so you can match known vulnerabilities in the database to your production environment 
• Run supported versions – Keep pace with the Java security baseline and don’t run unsupported versions of Java unless you run it from a trusted independent source like Azul. Be mindful of whether your version of Java still receives security updates to patch CVEs. 

Azul is the world’s largest independent Java provider. We support more versions and deliver more security updates than anyone else, including Oracle. 

Check out our pricing plans to see how we can help you.