Third party applications have become the backbone of companies across the world. Adobe, Cisco, Slack and Zoom are common third party applications that have enhanced productivity and innovation. However, these third party applications can complicate a company’s patch management landscape, expose your organization to risks, expand attack surfaces and leave network security vulnerable.
Deploying patches to endpoints for operating systems and common, high-profile applications is a routine task for enterprise IT teams. But in most IT environments, patches for third-party applications used across a business are not prioritized in those updates, or not included in provided patching tools. Thus, in many companies, third-party patch management entails additional work for IT teams, especially depending on the patch management process currently in place.
This post explores the importance of third-party patch management. It underscores the risk of neglecting third party patch management, walks through common mistakes organizations make and describes how your patch feeds and systems management solutions ensure effective patching.
Why third party patch management is important
It takes only one unpatched endpoint to make an entire network vulnerable. Any vulnerable application represents a welcome opportunity to a hacker and an extension of your attack surface. As a result, third-party patch management is just as important as patching your operating systems and high-profile applications because threat actors look for vulnerabilities in all kinds of software.
If you decide to assign a lower priority to third-party patch management, make sure you can justify it from both technical and business perspectives. Unless considerations such as resource scheduling or internal processes take precedence, it is a bad idea to relegate third-party patching to a second-class status.
Ignoring third-party patch management also damages your relationships with the vendors of third-party applications. When you fall behind in your updates, you make it more difficult for the vendor to support you and more expensive to keep you as a customer. As vendors continually improve their products with security updates and bug fixes, they progress toward supporting only the most recent versions. In fact, one of the most common first troubleshooting support questions is, “Are you using the most recent version?”
What happens when businesses neglect their third-party patch management?
Neglecting third-party patching impairs your overall security posture. Third-party applications are part of your entire attack surface, from the operating system to the user and everything in between. You’ve got to be able to see all points on that surface and make sure that anything that can be attacked is closed off. You may have impenetrable gates at your front entrance, but neglecting third-party patch management is like leaving the side window open.
Failing to maintain third party patch management leaves you with a sense of security that is, in effect, a false one. If you’re in an industry with regulatory standards and requirements, you’re putting yourself in jeopardy. Think about the long compliance checklist you’ll have to fill out eventually; what happens when you arrive at the patching section of the checklist and you can’t tick any of those boxes? That’s a difficult position to be in.
IT and security professionals should automatically and without question say, “Neglecting our third-party patching is an unacceptable situation to begin with.”
Managing third-party application patching
Typical update packages are often distributed and applied automatically by the operating system vendor, but they rarely cover third-party applications. That leaves you with the choice of installing updates manually or investing in patch management software to handle all your patching. Consider the following restraints that can have an impact on third party patch management.
Inventory
What insights can you get from your current patch management system? Are you aware of the third-party applications in your environment? What may look like neglect in some organizations could actually be simple ignorance of third-party applications on the network in the first place.
Does your product’s inventory feature let you discover which applications are installed on a machine or a device? A proper inventory should give you a complete view and full awareness of your application landscape. Without that, you have a gap in your IT team’s ability to successfully manage patching.
Patch feed/Patch catalog
If you have some type of network scanner and you’re trying to improve the view and awareness of your landscape, are you also getting a clear picture of what needs patching?
Your patch feed, or patch catalog, contains a superset of updates and patches for your applications. How many third party application products does it contain? Is it giving you the best possible picture of your environment?
The response time for your patch feed should be short, so that you’re not waiting 48 hours for protection from a zero-day exploit.
Process
Once you have a clear view of your patching needs, is it easy to deploy across your organization? What hoops do you have to go through to make sure third party patches are successfully issued?
If it’s a difficult process, then you pay the price of increased risk from delaying or protracting the rollout. Is it hard for IT to get access to the devices of certain users, like execs and remote workers? Does your organization have policies in place for obtaining permission of certain users before accessing their computers? Those policies tend to make it difficult to keep those machines up to date. It contributes to a lower score for your security posture and your threat prevention.
Automation
Is your patch management completely event-driven? Do you have to manually set up every Patch Tuesday? Or can you schedule patching updates based on pre-determined policies?
Naturally, it’s ideal when you’re allowed and empowered to use the automation in your patch management software and let it run according to broad policies you’ve put in place. That allows you to focus on other tasks or at most simply monitor how things are going and adjust when necessary. Wherever automation is available, take advantage of it.
Flexibility
Patch management should fit your IT priorities, instead of having to shape your priorities to what the system is built for.
- Timing – Do you prefer to push all updates automatically, through the management system itself? Or would you rather roll them out whenever you get around to it?
- Severity – Do you have an approach for patches that are more critical and of higher severity? Can you implement policies in different ways to address different users and devices? For example, you may want to apply high- and critical-severity vulnerabilities with infrequent, broad strokes – say, every Friday. Then you can slow-roll the patches for low- and moderate-severity vulnerabilities.
- Productivity – Beyond the general security stance there’s the productivity stance. When you keep your less critical patching up to date, you help your workforce maintain its usual levels of productivity.
- Crises – Not all vulnerabilities are created equal, and you don’t need to approach them all in the same way. Consider situations like zero-day threats and active exploits. How can you handle those without violating the processes your organization has put in place? With time, you can tune your automated patching to take into account even extraordinary circumstances when you detect them.
What are the biggest mistakes organizations make when it comes to third-party patching?
One big mistake is to run software that’s past its end of life or end of support. Suppose your organization embraces a given application because it solves an industry-specific need and keeps everyone productive. If the software vendor stops issuing updates for it, what will you do?
Some IT teams may consider it safe to simply continue running the software past the end of support, but that’s not prudent. A forward-thinking IT department will insist on replacing the product with an alternative that addresses the same need but is being actively developed. Otherwise, if use cases arise with no workaround there is a definite risk there.
So by keeping track of the applications you use and maintaining relationships with those vendors, you’ll know when support has ended.
Another big mistake is to ignore the communication component of third-party patch management. Just as patch management depends on systems communicating with one another, it also depends on people communicating with one another. If you ignore that, you’re asking for a wild-west scenario of inconsistency across an organization.
For example, how many exceptions do you have to your process? Patch management succeeds in a culture where patching can take place on an agreed schedule, yet with some provision for exceptions – say, when delays could affect business continuity. It’s necessary for department heads to accept the guidance of IT and security teams and agree to the organization’s policies around the patch management process.
The policies represent IT’s intention to perform patching with a given frequency to protect the company and maintain productivity. Policies also provide guidelines for responses when exploits arise and employees want to be treated as exceptions. It’s important to show department heads the importance of helping IT respond to threats and keep devices up to date and secure.
Third-party patch management is in everyone’s best interest and for everyone’s security. It helps you keep your doors open and your co-workers productive. When department heads and managers don’t buy in and your patching process has more exceptions than rules, you risk creating gaps and holes in your security.
The cost-benefit analysis of third-party patch management
Budget is always part of the buy-in. CISOs, CSOs, IT directors and department heads are paying attention to and trying to eliminate vulnerabilities. They know that they—just as much as the next company—could suddenly and reluctantly become front-page news. They tell leadership that security is a priority, which means that it’s worth paying for.
Patch, secure, and manage every endpoint
Suppose you’re dealing with systems management software that is included with your Microsoft licensing. It keeps your Microsoft products patched and secure, and you don’t have to pay anything additional for it. But it leaves you exposed in other areas, notably around third-party applications. It’s not a good idea for you to ignore those. So as an IT professional, should you license a second solution to fill that gap, knowing that you’ll have to maintain it? Will you still try to justify your current product because it doesn’t cost you extra? How do you assign a value to a product that will keep all of your software and devices up to date?
Conclusion
Third-party applications have become indispensable for businesses seeking efficiency and innovation. However, neglecting third-party patch management can expose your organization to significant risks by expanding your attack surface and creating coverage gaps in your network security.
A comprehensive system handles the patching for not only the applications tied to your operating system but also for the hundreds of other applications in the world of enterprise computing. It centralizes the control you exercise—and the effort you expend—in a single console, so that you avoid swivel-chair system administration. It lets you work smart by allocating budget efficiently to technology, rather than inefficiently to more manual labor.
With a unified source designed to handle patches across operating systems and third party applications, you can reduce the complexity of your IT infrastructure, eliminate the need for multiple patching solutions and shrink your operating costs by consolidating patch management.
