N‑sight PME Update—Exploring Granular Patch & Best Practices
By Joe Ferla
The Patch Management Engine (PME) in N‑able N‑sight RMM has been updated! I cannot stress how excited I am for granular patching. With the ever-changing security landscape in today’s world, we need more control over patching than ever. In this blog, I will quickly review the PME updates and give some quick-hit best practices that have served me well in the real world.
The Latest 2023 PME Update
Patch Management in N‑sight has received a critical upgrade in terms of how we handle Microsoft and third-party patches. We now patch Microsoft by classification and third-party applications by Vendor/Application. Gone are the days of the generalized severity patching and, personally, I could not be happier. That being said it does add some steps to our patching workflow. Before we get into those new steps let’s take a look at where the updates live in the Patch Management Policies.
Microsoft Approvals: moving away from the severity patch settings, we have broken Microsoft patching into categories that correspond with the Microsoft nomenclature.
Other Vendor Approvals (third-party patching): we are moving away from severity-based patching here as well, and we are instead breaking out patch approvals by application. Also added are:
- The ability to set a default action for all new products (the “Default approval for all new products” setting).
- A policy-wide setting (Auto Approval > “Set All Products” setting) that will allow us to streamline updates that may need to be made to the policies when apps get added to the third-party patch list, or happen to slip through the cracks when setting up/reviewing the new policies.
The available action options are:
- Approve: prevents the patch from entering the “Missing” container and puts it straight into the “Pending” container to be installed at your policy’s scheduled installation time.
- Ignore: prevents the patch from entering the “Missing” container and puts it straight into the “Ignored” container
- Manual: puts the patch in the “Missing” container for later review and classification actions
These updates mean that we will have to amend our patching workflows in the N‑sight world. However, this is a good thing as it means that we will be putting a little more time into one of the frontline security tools we have.
This leads us to best practices.
New Patch Management Best Practices for N‑sight RMM
While we used to be able to pretty much set and forget patching, to a point, in N‑sight, I was never quite happy with that. I am a huge proponent of installing patches ASAP but, they need to be vetted and researched before being pushed into a production environment to avoid any downtime that may be caused by broken patches.
The new configuration leads itself to that motion. We can look at certain Microsoft classifications—like Security and Critical Updates—and understand quickly whether they need to be auto-approved. Definition Updates should more than likely be on this list as well. For the rest of the Microsoft classifications, it boils down to what individual organizations’ SOWs and contracts state. We can see an example of the default settings in the image above and I tend to agree with the denotations. It makes sense to me that we are setting Applications and Upgrades to “ignore” since I do not need to be notified that they are missing, I am delaying major changes to an environment like those until I can plan something out with my clients. Having the rest of the items set to “Manual,” also makes sense as I need to know if any devices are missing for security purposes, but I am not installing without researching them.
To accomplish the best practice of installing patches that have been vetted, what I do is push the install date to Friday/Saturday/Sunday of every week. This allows me to check in on Mondays and see what has been released in the past seven days using the Management Workflow filtered to “missing” patches. I can than spend my downtime on Tuesday/Wednesday/Thursday reviewing the patches and expected behaviors, and install those that I am confident in outside of normal working hours on Friday and the weekend. This ensures I accomplish the endgame of no unresearched patches installing themselves and getting patches installed ASAP after release.
Note, about once every two weeks I will look into the “ignored” patches, and determine what should be installed on a normal cycle and what items require a conversation with the end users regarding Upgrades and the like.
Installation Schedule Best Practices
We can be quite short and succinct here. I do not know your end users, their schedules, or their contracts. I understand that my schedule of patching Friday, Saturday, and Sunday may not meet your organization’s needs, so feel free to take that suggestion with a grain of salt. However, there is one item in the Installation Schedule portion of the policy that I always stress, it’s that we need to reboot after patching. On servers I would typically script a reboot as part of weekly maintenance that would run after my patch window on Saturday morning and workstations would be handled by the Patch Policy.
Failed Patches
For Failed Patches inside N‑sight, I would automatically reprocess the patches three times (like three strikes and you’re out). I chose this number to get around applications being open and preventing those applications from patching (Google Chrome used to be a major offender here, but has improved), because what we are truly trying to do here is identify machines that cannot patch due to a more critical failure, and then target our techs properly.
Patch Status
Finally, the last item on the list. I much prefer the Report mode to the Alert Mode for the PME’s Patch Status Scan. My theory here is I know there are missing or ignored patches, I know I have to review them, and I know I have a good process in place to deal with patches, why would I want to get an email per device telling me that I have missing patches? In the real world, I would much rather have set aside time or downtime to be the period where I reviewed what was missing from what devices and whether I should install those patches than sift through missing patch emails every morning. Schedule and create an SOP around researching and reviewing patches. Please note, there have always been exceptions to this, and more often than not these exceptions were servers for high-security risk clients, those devices got alerts for missing patches.
Hopefully, this has given you some good information on the updates to the tool and food for thought around your patching motion. I do not expect that your organization’s best practices are the same as mine but, hopefully, in reading this blog, you were able to pull some theory/philosophy that will improve your patch stance and standard operating procedures (SOPs).
Joseph Ferla is one of our Head Nerds. You can follow him on Twitter @headnerdjoe or on LinkedIn.
© N‑able Solutions ULC e N‑able Technologies Ltd. Todos os direitos reservados.
Este documento é fornecido apenas para fins informativos e não deve servir de base para aconselhamento jurídico. A N‑able não oferece nenhuma garantia, expressa ou implícita, nem assume qualquer responsabilidade legal ou responsabilidade pela precisão, integralidade ou utilidade de qualquer informação nele contido.
As marcas N-ABLE, N-CENTRAL e outras marcas registradas e logotipos N‑able são de propriedade exclusiva da N‑able Solutions ULC e da N‑able Technologies Ltd e podem ser marcas legais comuns, registradas ou de registro pendente com o Escritório de Marcas e Patentes dos EUA e com outros países. Todas as outras marcas comerciais mencionadas neste documento são usadas apenas para fins de identificação e são marcas comerciais (e poderão ser marcas registradas) de suas respectivas empresas.