Every month, the National Institute of Standards and Technology (NIST) releases a list of recently identified IT vulnerabilities. In the month of September 2023 alone, a total of 2,825 software-related issues were reported by NIST.
To address these problems, software developers are required to develop patches and distribute them to their customers for installation. However, due to the constant influx of vulnerabilities, many companies are finding themselves overwhelmed and struggling to keep up.
This overwhelming situation often leads to what is referred to as “patching paralysis,” where businesses face difficulties in staying updated with software fixes and upgrades. This phenomenon poses a significant threat to the operations of these companies.
According to the National Cyber Security Centre of the UK government, ensuring that you regularly apply patches is crucial for safeguarding your technology. Neglecting to update your software leaves a vulnerable entry point for cybercriminals to exploit.
But why does patching paralysis occur, and how can it be addressed?
What Is Patching Paralysis
Patching paralysis occurs when organizations struggle to effectively implement software updates due to the overwhelming quantity and constant changes of patches they need to install.
Although patching is considered a fundamental security procedure, it is far from a straightforward task. Various factors hinder IT teams’ progress in patching, leading to a sense of being “paralyzed.”
Is Patching Paralysis That Big of a Problem?
Patching paralysis is a widespread issue that is prevalent in many organizations, as indicated by research. Recent data from Statista in 2022 reveals that companies usually require an average of 180 to 290 days to address cyber vulnerabilities through patching. This raises the question of whether this is truly a problem. In short, the answer is yes.
The primary reason for the concern surrounding patching paralysis is its role in preventing security breaches. A staggering 60% of organizations that experienced system breaches could have avoided them if they had implemented an available patch.
This finding serves as a stark reminder for IT professionals. When software publishers release patches, they face the dilemma of disclosing to both the public and potential hackers that there are vulnerabilities in their products. Cyber criminals don’t like to waste time exploiting these vulnerabilities, often launching their initial attacks within 15 days of discovery.
Consequently, if patching paralysis leads to delays of weeks or even months in the installation of patches, organizations leave themselves vulnerable to attacks. It is crucial for organizations to address this issue promptly and prioritize the timely implementation of patches to enhance their overall security.
Reasons Why Patching Paralysis Happens?
The reasons patching paralysis happens in the first place may differ from one organization to the other, but there are common factors that contribute to the issue no matter the company. Some examples are…
Nowadays, numerous businesses rely on a multitude of apps, widgets, and other software components. On average, a large organization currently has 367 apps and systems in use.
A significant portion of these software components undergo regular patching and upgrades, frequently occurring on a monthly basis. While certain software can be automatically patched by the publisher through the internet, many still necessitate manual installation by an individual.
If the process of installing patches on company systems were as simple as downloading the patch and clicking “run,” then patching would be a relatively effortless task. Unfortunately, patching is typically a time-consuming endeavor. According to a study conducted by Edgescan, a penetration testing company, the average organization takes approximately 60 days to complete the patch installation process.
One of the primary reasons for the lengthy duration of patching is that organizations often make modifications to their software. Consequently, installing a patch without first evaluating how it may interact with these modifications could potentially disrupt the system. Therefore, companies must allocate time to test the patch in a controlled environment, commonly known as a “sandbox,” prior to implementing it on a system-wide scale.
The installation of patches usually necessitates rebooting the organization’s devices. As a result, patching can disrupt the normal workflow of a business. To minimize this disruption, many companies choose to schedule patch installations during weekends or nighttime hours when fewer employees require access to their technology. However, this scheduling adjustment further slows down the overall patching process.
Another reason that makes the patching process
take so long is the approvals the IT team must obtain before deploying the
patching. Mostly seen happening in larger organizations, several senior
employees may need to give their approval, that causing additional delays.
According to a study conducted by the Ponemon Institute, nearly 80% of businesses expressed that they lack sufficient resources to keep up with the volume of patches required for installation.
The process of patching involves IT staff testing each update, sanitizing them, and then deploying them across various systems while checking for any potential issues.
Although patching is a skilled task, it is also a repetitive and laborious job that often goes unnoticed and requires employees to work during nights or weekends. Additionally, it is not always easy to convince employees to install major upgrades on short notice.
The resource problem associated with patching varies depending on the size of the company. In smaller firms, there may only be one or two technical staff members who feel overwhelmed by the multitude of patches they need to install. On the other hand, larger companies face the challenge of upgrading dozens of applications every week, along with communication hurdles and approval processes to navigate through.
One of the primary factors that leads to patching paralysis is the constant fluctuation in the order of upgrades. Many organizations follow a predetermined schedule for implementing patches.
However, if a critical vulnerability is found in a crucial operating system, it becomes necessary to prioritize that patch and address it immediately. This can disrupt the sequence of other upgrades and create general chaos in the patching schedule.
Patches are often classified as low, medium, or high risk. A high-risk patch may refer to a critical vulnerability in an operating system, such as Windows 10.
On the other hand, a “low-risk” patch could pertain to a configuration issue in a project management application that is only utilized by a small number of employees.
However, it is crucial to recognize that all vulnerabilities have the potential to be exploited by cybercriminals. Even if a particular software is labeled as “low risk,” it does not mean that cybercriminals cannot exploit its known vulnerabilities as a means to infiltrate your system.
Determining which patches to prioritize and how much time should be allocated to each one can be a challenging and decision-inducing task.
There are numerous additional factors that contribute to organizations’ inability to promptly implement software patches. Some common challenges include:
- Fragmentation within IT departments results in a lack of communication regarding patch information and installation responsibilities, leading to misunderstandings.
- Insufficient awareness about all endpoints, especially in cases where “bring your own device” policies are in place, and the presence of “shadow IT”.
- Ineffective procedures for monitoring and keeping track of patch releases from software publishers.
- Dependence on outdated software that no longer receives updates from the publishers.
- Certain systems and devices, such as medical equipment, cannot be patched due to various reasons.
How to Spot Patching Paralysis in an Organization
So, how can you determine if your organization is experiencing patching paralysis? Here are some of the unmistakable indicators that we frequently observe:
The most evident sign of patching paralysis is when it takes an organization an excessive amount of time to install updates. In an ideal scenario, patches would be promptly installed on the day of their release or at least within a couple of weeks.
Is there a designated individual who has direct responsibility for staying updated with all the patches in your organization?
Surprisingly, many companies lack a single point of contact for patch management. This is particularly common in organizations that utilize a combination of on-premises and cloud software, where different individuals often handle different systems. Consequently, this sometimes leads to patches being overlooked or neglected.
Another issue that arises is the lack of knowledge regarding which patches are being applied and who is responsible for their implementation.
This problem is particularly prevalent when different departments within the IT division operate in silos, resulting in uncertainty about who should be accountable for patching specific areas.
Frequently, IT teams face obstacles when it comes to implementing patches because the rest of the organization is resistant to updates and cannot tolerate any downtime.
The IT team is compelled to wait for opportune moments, such as weekends, holidays, or nights when other employees are not present, before they can proceed with installing significant upgrades.
As previously mentioned, determining which patches should be installed and in what order can be challenging. However, it becomes even more difficult when IT teams do not have a consistent policy for patch management to guide their decision-making process.
What qualifies as a “high-risk” patch for your organization? Which software is so critical to your business that new patches must be installed immediately? What types of upgrades can be postponed while more pressing tasks are addressed, and what is the rationale behind these decisions?
