Q: With the increase of cyber attacks and the growing remote workers, what are some best patch management practices to better protect my customers?
Patch management serves as a key defense against cyber threats and is also required to ensure operating systems and business-critical software are maintained. However, it is not always a simple and straight-forward task for MSPs, especially in current times. With the new remote workforce, MSPs must develop a best practice that ensure not on are the network servers are up-to-date, but that customers’ endpoints are also updated frequently to prevent any exploits.
A recent Barracuda MSP partner poll identified that some of the most common challenges with patch management include effectively testing patches before deploying to customers, patches failing deployment, and being able to confirm that customers are up-to-date with their patches.
We asked some of our resident experts here at Barracuda MSP for their thoughts on the topic. We spoke with Ken Bartlett, sales engineer manager, Mark Whiffen, senior product manager, and Shawn Saunders, a senior quality assurance analyst of MSP tools, and captured their tips for streamlining a patch management process.
It’s important to get the full picture!
There are many patch management solutions in the market, and Mark Whiffen believes that remote monitoring and management (RMM) platforms offer the most complete patch management feature for MSPs. However, RMM vendors often take different patch management approaches. Whiffen suggests that MSPs should focus on two key areas during their investigation:
- Where are the patches sourced from? The source from which the RMM pulls the patch is important. This tells you whether you can leverage it for all software comprehensive patch management. Also, some sources will research the validity of the patches prior to releasing them. This can shorten the testing cycle for MSPs and help make the process more efficient.
- Does the RMM platform offer granular control to apply patches? Different devices and users have different requirements. Having granular control when it comes to applying patches allows MSPs to create test groups within their customer sites to meet each customers’ unique needs.
Automated versus manual patch management
Some MSPs may wonder when they should invest in automated patch management. According to Ken Bartlett, this really comes down to your service model. If the majority of your customers fall under the break/fix service model, you may find that manual patch management is suitable, because you are not required to keep patches updated for your customers. You will just need to validate if your customers’ devices are up to date when an issue arise.
For MSPs who offer active monitoring and management services to their customers, automated patch management is a must. Automation will allow you to scale your technician’s time, standardize patch management service delivery, and prevent vulnerabilities from being exploited from cybercriminals.
It is worth noting that for many service providers, the managed service approach offers several benefits when compared to the break-fix model. In addition to predictable recurring revenue each month, offering managed services enables the MSP to avoid reactive emergencies to an extent, because of the proactive care they provide up front.
Patch testing best practices
Even the most trusted vendors’ patches should be tested before they are rolled out to your customers, otherwise they could cause catastrophic impact. Shawn Saunders commented that patches can create conflicts with customers’ infrastructures. This has been echoed by some partners who had scheduled minor Microsoft updates to automatically roll out. The patch conflicted with their billing software, which brought their entire finance team to a halt during year-end.
An easy way to test patches is to set up test groups within your customer sites. The test groups may consist of non-mission critical devices within each site. As new patches are released, MSPs can schedule automatic approvals to the patches and apply patches to test groups. Once patches are successfully deployed, the patches can be rolled out to rest of the site.
Ensuring successful patch deployment
To ensure a successful patch process, MSPs must ensure all devices are available and online. It is important for MSPs to set the patch timeframe and communicate the patch schedule with their customers. This will increase the success rate for patches deployed.
In addition, if patch management is deployed through an RMM platform, MSPs should also leverage the alerting and reporting feature to ensure MSPs are alerted if it was unsuccessful. In conjunction with alerting, MSPs can schedule automated reports to confirm if the patch process was complete or if there are devices that did not receive the patch.
Streamlining the patch management process can help MSPs ensure that patches are deployed efficiently and successfully in their customers’ sites; ensuring they are secured against cyber threats.
Photo: Raw Pixel / Shutterstock
This reinforces that there is value in using an external NOC for testing and deployment of patches. Also despite communicating schedules to customers, be aware that three will still be frequent deployment misses due to a variety of factors vacations, people not leaving machines, on, etc.
Do an image backup on a machine, then apply the patch, then test. In my experience having us or a customer try and test is incredibly complicated. To truly to do this you need to try each and every function of every software. I am interested in the statistics on machines that are compromised due to not patching versus the machines that are compromised do TO patching. I hear more from those compromised due to patching as opposed to those compromised from not patching. I am very curious to hear what is your experience?
One of the issues that we face is with older workstations, you want to keep them patched, and in doing so you also find that patches tend to break things. Whether its the network card that seems to be a recurring thing on Windows 7, or otherwise. With the latest RDP vulnerabilities though, it is critical that you do research the patches and implement immediately when necessary to take care of these exploits that could be detrimental to the client and your own business. To say one thing about a NOC however, there are still issues with their testing as it can’t catch everything but something we are successful with is waiting 3-4 weeks to deploy non-critical patches so by then we’d read articles or posts about broken patches. You must stay ever diligent with patching, even if it does cause some issues!
Thanks for sharing the details. ITS Infrastructure will manage the patching needs for all servers and network devices on the network,