For most ConfigMgr pros, third-party patching is a bear of a problem—and that’s putting it politely. In a recent Adaptiva Endpoint Security Survey, 48% of IT pros called it “especially challenging.” At the same time, they rated it as one of their top security priorities.
What Exactly is Third-party Patching?
Third-party patching is the process of updating non-Microsoft software applications and drivers.
When it comes to updating Windows itself, Microsoft has a mature process in place for companies using ConfigMgr. Administrators can rely on timely notification of updates to Windows. Microsoft also provides an organized and consistent mechanism for delivering the updates, though it’s up to each organization how quickly it rolls them out.
However, Microsoft does not include updates for other companies’ software in Windows updates. The OS updates do include hardware drivers for many manufacturers and devices, though not all.
This leaves companies on their own to update non-Microsoft:
- web browsers
- productivity applications
- vertical applications
- anti-virus and anti-malware solutions
- utilities like FTP software and PDF readers
- specialized software tools for specific job-functions
- drivers for some hardware
- much, much more
Why is it so Important?
I can explain the importance of third-party patching in one word: security. It really should be in all caps, but I don’t like to yell.
Before the Internet was a thing, PCs were not easily or commonly attacked from the outside. Many PCs didn’t connect to anything. Some used dial-up modems to connect to BBSs, and things like that. Vendors patched software infrequently, and usually to fix bugs or add features—not to improve security.
Now we live in the age of Internet everything and broadband everywhere. Productivity is through the roof, but so is danger. Everything that is cloud-enabled opens up an attack surface—even small things like Notepad++ or Evernote.
Cyberattackers are relentless, and an exploit of even the tiniest vulnerability in an application or driver can crush an enterprise. To remain as secure as possible, patches must be applied as soon after the vendor releases them as possible.
Why is it so Hard?
As technology has progressed, the sheer volume of applications is massive. A mid-sized company can easily manage hundreds of different software applications, and an enterprise may have thousands.
Adding to this, the pace of updates is extremely rapid. Some applications may be patched as often as multiple times within a week. By the time an IT department is notified of an update, tests it, gets it packaged, and deploys it, the next update may already be released!
There is no unified mechanism for keeping track of updates to all of these applications. A company has to formulate a plan for tracking updates for each package from each vendor.
Admins may consider some of the patching solutions on the market. These solutions maintain their own database that they update daily with all the metadata and patches for applications from hundreds of vendors. So a ConfigMgr admin can use one service to update hundreds of vendors’ apps.
Another challenge is the actual rollout of patches. Microsoft ConfigMgr is a strong solution for deployment of patches. However, not all ConfigMgr environments are equal. A ConfigMgr architecture with dozens or hundreds of DP servers may see high numbers of delivery failures due to problems with distribution point servers. If just 1% or 2% of DP servers fail, the result can be thousands of unpatched endpoints.
Peer-to-peer delivery technology such as Adaptiva OneSite Anywhere can make rollouts faster and easier. OneSite eliminates the need for servers, speeds delivery, and does a lot more to improve your success rates and shrink troubleshooting time and effort.
MDM solutions such as Microsoft Intune and VMware AirWatch bring cloud-based distribution to the rollout process and will see increased adoption in the years ahead.
Here is a recap of things of key challenges you need to solve:
- Tracking applications and versions across endpoints
- Knowing what patches vendors have released for which applications
- Prioritizing which patches to deliver to which endpoints first
- Having the person-hours and cycles to deal with it
- Keeping pace with the speed of updates
The One Most Important Best Practice
When I speak to people working in IT, and when I talk to vendors of third-party patching solutions I hear one thing: somebody needs to own it. Admins tell me stories of nobody knowing “whose week it is to patch.” I’ve also heard of everybody in IT sort of ducking responsibly for patching. If nobody owns third-party patching, it may get done well, or it may not.
The one best practice is:
Anoint a Patching King, Queen, Czar, etc.
This person may also do all the patching, or they may coordinate others. This may be their only responsibility, or it may be one of many. They may also be responsible for operating systems updates, or not. However you organize it, somebody in your company needs be given the responsibility—and the time—for third-party patching.
You need one person responsible for:
- Tracking all patches from vendors
- Prioritizing the patches and machines to deliver them to
- Confirming successful rollout / deployment
Ideally, you will also get executive sponsorship of patching. It is a critical security function. If it is visible at the CSO level, the people in the trenches are more likely to have the time and resources they need to get it right.
Usually, when I ask people working in IT to give me their list of best practices, they offer technical advice. In this case, they all gave me the same answer, and it wasn’t technical at all. So the solution for you isn’t terribly technical either.
Do you know who is responsible for third-party patching in your company? If not, ask your boss, maybe they know. Of course, there is a good chance nobody owns it. In that case, I’ve provided you all the ammo you need to make a case to anoint a third-party patching czar. Forward them this blog; just be prepared, they could pick you!
Learn More
Check out Adaptiva's webinar "Windows 10 OSD Best Practices with ConfigMgr".
