Rethinking Patch-First Approach: Effective Strategies for Securing Your Business Technology
April 14, 2023
6 min read
April 14, 2023
6 min read
When it comes to software patches, expectations and reality are often two different things.
The misconception starts with the very terminology businesses use to describe the practice and the expectations they attach to it.
TechTarget calls a patch a “a quick-repair job for a piece of programming designed to resolve functionality issues, improve security, or add new features.” But beyond the 30,000-foot overview, there is no one accepted definition of what a patch is.
That’s a real problem in the business tech world, where stakeholders tend to regard patching as the end-all-be-all solution to emergent performance and security problems. Getting no results from the solution a company expected to be a silver bullet is one thing; making the situation worse when the dust clears is another, much larger, concern.
Understanding the problem with patch-first thinking requires a grasp of the landscape modern IT leaders must navigate.
Every company’s situation is different, but two factors sit at the foundation of many serious technology blockers.
First, supply chain attacks have become a weapon of choice for cybercriminals. They effectively negate the primary victim’s ability to directly defend itself and can come from components that make up some of the company’s most important systems. An affected business can do everything right, tick every box, and apply every patch, and still end up with huge risk and liability due to cybercrime.
Second, with software playing a central role in nearly every business activity imaginable, even minor performance issues or outages can create negative experiences with customers on one side of the counter and poor productivity for staff on the other.
Moreover, these concerns can express themselves in an endless array of negative business outcomes, such as lengthy, resource-intensive migrations and security issues. Having to work in a scene like that, where any number of things inside or outside the company’s control can turn sour, it’s hardly any wonder IT stakeholders are losing sleep and breaking out the Tums.
Now pair the notion above with a simple, but highly telling statistic: As many as 82% of reported breaches occur as the result of human error or oversight, such as misconfiguration.
A substantially high percentage of potential issues that can be addressed to an acceptable level are fixable before patching becomes necessary.
Due to no international definition of a patch, a patch may be used to automate configuration to address an oversight that could leave a product vulnerable on initial deployment. However, often this vulnerability will not be obvious to the user. Additionally, self-configuration allows the technology owner to ensure no unintended impact on operations. If the required skills are not available, this can be done with the help of a non-OEM entity, such as a third-party software maintenance (TPSM) provider.
Instead of considering every possible variable when problems arise, a software megavendor’s default goal is volume. After all, remediating the issue for the broadest number of users possible (with the least amount of impact) makes business sense when a software vendor serves huge tracts of customers.
In other words, the standard patching process inherently leaves customers’ unique deployments and situations by the wayside.
A one-size-fits-all fix such as a patch can never consider a company’s unique context, but technological context is a core differentiator and driver of growth for most companies. An OEM patch developed exclusively for a mass-market idealized audience must by its very nature avoid deployment wrinkles that companies include as a basic function of business.
All these factors point to an environment in which an OEM’s fundamental goals for patching a given product might not dovetail with the customer’s needs or growth plan at all. But patches are presented as the primary vehicle to fix problems, even if a patch isn’t needed. That can lead to misconceptions and issues that could be completely avoided with a different outlook.
A patch, if available, is only a part of an effective vulnerability management and cybersecurity program.
Now let’s return for a moment to the problem of attacks on third-party components within an enterprise. Of these, breaches involving open-source libraries and components rose 650% in 2021 alone, indicating a huge source of opportunity for cyberattackers.
A perfectly secure digital environment is impossible to achieve. But even if a company did somehow build an impenetrable product based on 100% secure proprietary code, the moment they introduce an outside component, such as an API or open-source library, their overall ability to secure the product is diminished.
In 2021, for instance, researchers rang the bell on a 10/10 “worst of the worst” security vulnerability within Log4j, a ubiquitous open-source library utilized in countless solutions at the enterprise level and below. The exploit that arose from this vulnerability, known as Log4Shell, sent shockwaves through the cybersecurity, technology, and business communities when discovered.
In many situations, software megavendors only check the interoperability of the open-source components they utilize. When a security issue within one of those components arises, OEMs might not possess the required technical skills ‘in-house,’ so the responsibility for that fix can shift to the person or entity maintaining the component.
And in other cases, a vendor might have to – or choose to – drag its feet on deploying a proper patch as it waits for more information or for the situation to develop. If that product has reached end of life, it might make little to no business sense for the vendor to address the issues within their third-party components.
That means a business might not know when a fix is coming, and who is ultimately responsible for its development. And as famously covered by beloved webcomic XKCD, that results in situations where niche component breakdowns can lead to large technological consequences.
It can even create situations in which customers aren’t certain whether the systems they rely on are vulnerable, or what they should do next. Instructions and documentation relating to open-source components are famously sparse; combined with the problems above, there are no shortage of ways in which the standard patching process can leave valid customers behind.
Now let’s return for a moment to the problem of attacks on third-party components within an enterprise. Of these, breaches involving open-source libraries and components rose 650% in 2021 alone, indicating a huge source of opportunity for cyberattackers.
A perfectly secure digital environment is impossible to achieve. But even if a company did somehow build an impenetrable product based on 100% secure proprietary code, the moment they introduce an outside component, such as an API or open-source library, their overall ability to secure the product is diminished.
In 2021, for instance, researchers rang the bell on a 10/10 “worst of the worst” security vulnerability within Log4j, a ubiquitous open-source library utilized in countless solutions at the enterprise level and below. The exploit that arose from this vulnerability, known as Log4Shell, sent shockwaves through the cybersecurity, technology, and business communities when discovered.
In many situations, megavendors only check the interoperability of the open-source components they utilize. When a security issue within one of those components arises, the OEM might not possess the required technical skills in-house, the responsibility for a fix can shift to the person or entity maintaining the component.
And in other cases, a vendor might have to – or choose to – drag its feet on deploying a proper patch as it waits for more information or for the situation to develop. If that product has reached end of life, it might make little to no business sense for the vendor to address the issues within their third-party components.
That means a business might not know when where a fix is coming, and who is ultimately be responsible for its development, And , that results in situations where niche component breakdowns can lead to large technological consequences.
It can even create situations in which customers aren’t certain whether the systems they rely on are vulnerable, or what they should do next. Instructions and documentation relating to open-source components are famously sparse; combined with the problems above, there are no shortage of ways in which the standard patching process can leave valid customers behind.
By contrast, TPSM providers make sure things work, no matter what goes wrong.
In some cases, the solution rendered might be an actual patch. When issues arise within the code of open-source components, for example, code changes can be implemented.
In others, the TPSM provider might partner with outside security services to obtain a fuller view of system health. By keeping a list of constantly updated definitions and checking against the customer’s software estate, the company can provide an overview that primarily focuses on the estate’s security by going beyond sharply defined OEM walls.
Practices that actively consider and shore up the entire system’s security, broadly defined as “hardening,” should be considered rather than patching alone in terms of overall security outlook. They enhance the business’s ability to work in its own interest, because they consider the business’s unique context. And perhaps most importantly, they give the business the ability to stay technologically proactive, freeing them from the reactivity inherent to only utilizing the latest product version.
Software is ubiquitous in business. When attempting to fix issues that touch some of the most crucial systems a company has, what’s more important — ticking a box that says you’re secure or actually achieving the desired level of security?
As the average tech stack evolves away from harmful conventional thinking, it’s high time the industry at large reconsiders what patches are, what they do, and their dubious role as the best way to fix software problems.
Gain insight into industry-only news, access to webinars, tips and tricks, blog posts, podcasts, and guides, surrounding topics like cybersecurity, reducing software support and maintenance costs and much more, all delivered to your inbox each month.
LEARN MORE