Save to My DOJO
To patch or not to patch, that is the question. No question about it, patch. And patch often. But wait, my application will not work with that new .net update! So, the struggle between security and operations continues.
Many engineers would say that if it’s not broken, don’t patch it. This is a very dangerous practice as more and more security breaches are designed to harvest data or resources while not disrupting the network. While in the past, the intent was to bring the network down, cyber hackers now zero in on the company’s network resources and end users with the goal of data mining.
Hackers can and will take advantage of these security flaws if patching is not done in a timely manner. As you can see, patching is extremely important and, if neglected, could put your systems and your clients’ systems at risk. This post explains the best practices so you can choose the right patch deployment method for your specific requirements.
Manual Deployment
The first method is the old-school way: manually deploying patches. Many small managed service providers continue to use this method today for many reasons. The main reason would be the ease of getting into the market. It has very little upfront cost.
This method is very labor-intensive and slow. It is the ideal patching method for a small managed services provider. Applying patches in this way requires accessing each endpoint and conducting updates as needed. However, it’s not a method that allows a larger managed service provider to scale to a larger size or market. With that said, even with a large managed services provider, those “troublesome servers” remain within this patching strategy. This is primarily due to custom applications and other dependencies that will make patching a challenge.
Another issue with this method is that it is pretty much “patch and pray.” You are relying on the vendor to release patches, and they won’t bring the network down. As a result, labor spent on testing patches is not cost-effective due to the many different system configurations and the requirement of having those resources available for said testing.
Combine the labor spent on testing with the labor spent to implement the patches, and things become cost-prohibitive for any managed services provider with more than just a handful of clients. Most of your hard cost of goods will be in labor and will increase steadily as the endpoint base increases.
Advantages
- Low to no cost for system
- Very customizable to accommodate specific client needs
Disadvantages
- Labor intensive and requires larger workforce
- Time consuming when deploying patches
- Less scalable with limited potential for growth
- More risk in applying a “bad” patch
- Decentralized management requiring additional resources
Third-Party Patching Systems
The second method would be to install a third-party patching system that would automate the installation of patches. Several third-party patching systems exist, such as Microsoft SCCM, GFI LanGuard, and Kaseya. However, this is a decentralized management method since the system’s administration is conducted in each client’s environment without a single pane of glass to manage multiple clients.
Testing is still required for the proper patches to be installed. However, this method does eliminate the labor of applying patches individually. Many vendors will have a tiered pricing structure as additional third-party patching systems are deployed. With each new client, there will be a dramatic increase in price. Many of these third-party systems are low-cost for the software. However, they require network resources and a labor force to implement, administrate, and remediate.
Advantages
- Decrease time in deploying patches with scripted patch delivery
- One-time cost of software and hardware
Disadvantages
- Decentralized management requiring additional resource
- There is no prior testing of patches before deployment
- Requires network resources as each client’s location
Cloud-Based Patch Deployment System
The last method is to deploy a cloud-based patch deployment system. Many current MSPs offer remote monitoring and management (RMM) platforms, such as Labtech, Continuum, and Kaseya, as part of their bundle of services. Some vendors, such as Kaseya, just provide the centralized delivery of the patches, while other vendors, such as Continuum, provide additional value by performing quality testing of the patches prior to implementation.
This centralized method allows an MSP to manage patch deployment policies for multiple customers. An added benefit is maximized growth with less labor since the function is driven from one pane of glass and is well-automated. The burden of testing patches on a massive scale is shifted to the cloud-based vendor and away from the managed services provider. This reduces the managed services provider’s labor force needed to maintain this service offering because only after the patches pass the quality assurance testing of the servicer are they deployed to the endpoints.
Like third-party patching systems, many cloud-based patch deployment systems are price-based, on tiers. This method normally decreases overall costs as the managed services provider enters higher tiers. In short – As the managed service provider grows and scales, the cost of this service decreases. Thus, this method will generally benefit the managed services provider with lower costs while maximizing the use of their system.
Advantages
- Centralized management of patch deployment
- Many services have patch testing prior to deployment
- Low labor cost as a smaller workforce is needed
- Less time consumed in testing and deployment
Disadvantages
- Higher cost and is normally a monthly expense
- Less customization for specific client needs.
Which Patch Deployment Method Should You Choose?
Deciding on the right patch deployment method for managed service providers is a critical choice that hinges on various factors, including cost, scale, labor intensity, and specific client needs. Here’s a brief rundown to guide your decision:
- Manual Deployment:
- Best for: Small MSPs or those just starting out due to low upfront costs and high customizability.
- Considerations: Labor-intensive and time-consuming, suitable for limited-scale operations or those with specific, troublesome servers needing careful patching.
- Third-Party Patching Systems:
- Best for: MSPs looking to automate patch installation while maintaining some control over the process.
- Considerations: Requires network resources and a labor force for administration. Decentralized management might complicate things, and there’s an inherent risk of untested patches causing issues.
- Cloud-Based Patch Deployment System:
- Best for: Larger, growing MSPs aiming for centralized management and reduced labor costs.
- Considerations: Generally has higher upfront costs but is offset by the scalability and efficiency it offers. Pre-testing of patches by the vendor adds a layer of security and reliability.
In summary, your choice should align with your MSP’s size, growth trajectory, and the specific needs of your clients. Small providers might lean towards manual deployment for its low cost and customization, but as the business grows, the scalability and reduced labor intensity of cloud-based systems might become more appealing.
Consider the trade-off between upfront costs, ongoing expenses, and the labor required for each method against your ability to manage and scale your operations effectively. Ultimately, the right choice balances cost, efficiency, and risk management to support your business’s growth and service quality.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!