Patch management: Why firms ignore vulnerabilities at their own risk

Attackers are increasingly taking advantage of software vulnerabilities to breach organizations – and it’s no surprise. New bugs are being discovered all the time, making it a constant struggle for firms to keep their patch management in line with security announcements from vendors in a timely manner.

While some firms are unable to apply the relevant fixes even years after they have been issued, others fall prey to attacks due to poor patch management. Many organizations are still exposed to critical vulnerabilities in open source utility Log4J, two years after a maximum severity bug was found in the popular Java-based logging library. In December, Veracode analysis revealed nearly 4,000 organizations are still vulnerable to the Log4Shell vulnerability.

These failures come at a time when patching is more important than ever, with experts warning that a failure to fix vulnerabilities is leading to a growing number of successful attacks. What can you do to ensure you are keeping up with the latest issues, prioritizing the right fixes, and applying them before adversaries can take advantage?

Patch management: Why are flaws ignored?

One problem preventing companies from quickly fixing known security issues is the sheer volume of vulnerabilities being publicized and patched by vendors. “The number of vulnerabilities being discovered and fixed is growing annually, so it is a constant challenge to make sure you are patching appropriately,” says Sean Wright, head of application security at Featurespace.

Some firms aren’t patching on time due to a lack of resources – and not just in the security team. Proper patch management often involves numerous teams, says Wright. “The security team is responsible for identifying the vulnerability, prioritizing it, and pushing the relevant teams to implement the fix. Then you have the teams who need to roll out or implement it. This often has to be done with competing priorities or with the least amount of disruption as possible.”

Adding to the pressure, there can be a conflict of interest between up-time for the business and security, says Matt Middleton-Leal, managing director EMEA at Qualys. “If you suggest downtime for the systems that make the business money, you have to be certain it will work.”

Another reason for failing to patch is a lack of appropriate vulnerability management programs and tooling, Wright says. “You need to have the right tooling to identify the vulnerabilities you have, including asset management. So many organizations have been breached because of that one box no one knew about running an old vulnerable software version.”

Patch management: The legacy tech effect

Making things worse, many small enterprises – especially in the manufacturing sector – are using unsupported technology running on legacy hardware and software and outdated operating systems, says Ian Thornton-Trump, CISO at Cyjax. “These solutions can date back as far as the 1990s, and any upgrade path will be cost or technology-prohibitive.”

Major version upgrades can be expensive due to the difficulty in maintaining backward compatibility, says Lorenzo Grillo, managing director at management consultancy Alvarez & Marsal. Alternatively, he adds, organizations may simply not know which patches need to be applied.

This challenge persists despite the consequences of failing to patch known vulnerabilities, including regulatory repercussions, downtime, and loss of revenue and data.. The flaw in Log4J, for example, is attractive to attackers partly due to how easily it can be exploited. So much so that the bug has been used by ransomware operators, cryptocurrency miners, and nation-state adversaries. State-backed groups linked to Log4Shell exploits include China-based APT41, which compromised US government networks using the unpatched vulnerability, as well as Iranian state-backed hackers.

The vulnerability is particularly troublesome because it requires firms to work out exactly which solutions are affected before they can fix them. Kapil Tandon, VP of product management, IT operations at Perforce explains how the Log4J issue was disruptive due to the way Java apps are packaged. “They bundle all the libraries they use into one package. This meant correcting the problem wasn’t a matter of just updating a system package; we had to root through all our Java apps to assess and remediate the vulnerability – and so did all their vendors.”

Aside from Log4J, other notable recent flaws include the MoveIT vulnerabilities, which were utilized by ransomware gang CL0P to breach thousands of organizations. The group’s subsequent demands for victims to make first contact for negotiations sparked speculation that Cl0p lost control of the hack due to its sheer size.

Patch management best practices

It’s not an easy task, so how and when should firms patch for best results? Patch management needs to be embedded into a wider vulnerability management program, says Grillo. He advises ensuring asset management is in place with “the right understanding of assets and their vulnerabilities” – including applications and their dependencies. 

Grillo also advocates implementing a strategy and plan for patch management. “Many organizations will set a monthly routine to match the updates from key vendors, sometimes in one go or staggered to view the effects.”

Setting up patching alerts from solution vendors is good practice. “The reporting functions within software management solutions allow system administrators to monitor the rollout of patches to the organization’s systems,” says Ross Higgins, senior penetration tester at consultancy IT Governance.

Prioritization and testing will ensure critical assets are patched first and the fixes are tested to ensure they will not cause issues in production, says Grillo. He advises “automated patching to save time and reduce human error mistakes”, as well as “the odd manual check”.

The best time to patch is before deploying new code into production, says John Allison, director of public sector at Checkmarx. “Catch and fix the vulnerabilities before they get exposed to the adversary – this is the goal of any mature application security program. It reduces the vulnerabilities in production to those just identified and while those will still need remediation, the number is more manageable.”

Wright thinks firms need a pragmatic approach focused on the most-exploited vulnerabilities. “Instead of treating all critical and high vulnerabilities as, ‘fix right away’, leveraging things such as CISA Known Exploited Vulnerabilities Catalog, (KEV) and vulnerabilities with publicly available exploits is far more efficient. Using this method you can focus on the highest risk items first, then include the other vulnerabilities in a periodic patch cycle.”

Some vulnerability scanning tools will include links to sources that continually update known vulnerabilities. “These could in turn rely on resources such as CISA’s KEV,” Grillo says. He identifies other free resources as helpful, such as common vulnerabilities and exposures (CVE) databases such as the National Vulnerability Database, Vulnerability Database (VULDB), and CVE Details..

Overall, Wright recommends focusing on the vulnerabilities that matter the most. “These are the issues that will represent the biggest risk – such as publicly available exploits, as well as the ones actively being exploited.”