Manage Engine Patch Manager review: Just what you needed

I’ve been evaluating Zoho Manage Engine Patch Manager, and so far I like what I see. It is a capable patch deployment tool that supports Windows, Linux, and Macintosh, and crucially, it will deploy updates for third party applications, including open source applications, both popular and obscure.

A quarter of a million patches and counting

Manage Engine Patch Manager has an impressive inventory of vendor updates. At the time I am writing this, it has more than a quarter million of them. These range from operating system updates, software from major vendors like Microsoft and Adobe, and thousands of other, and not so common applications.

They also include driver updates from major hardware manufacturers, which is nice. Those updates are not always easy to deploy from a centralized source.

But let’s talk about a subject that’s near and dear to me : security updates.

When critical doesn’t mean critical

If you look at the quarter million updates Manage Engine can deploy natively, you’ll notice they have four severities: critical, important, moderate, and low.

So then the security team tells their IT staff to just update the criticals and asks how hard can it be?

The IT staff then goes to their deployment tool. They filter the critical updates and hide the important, moderate, and low updates like they were told. Then they dutifully deploy thousands of updates.

Then the security team runs a scan and notices there are still critical vulnerabilities. After a couple of months of having the same conversation again, they say something like why don’t you patch at all? I’ve seen far too many times.

The root cause nobody told you about

Here’s why that happens. Software vendors use a scale of critical, important, moderate, and low while security vendors rate vulnerabilities using a scale of critical, high, medium, and low. It would seem like the two scales should line up neatly, but they don’t.

Various security vendors have been proposing different solutions to this problem for more than a decade now. None of their proposed solutions work because none of them solve the root problem. The root problem is that given a vulnerability, it takes somewhere between 20 and 180 minutes, depending on who’s doing the work, to find a suitable update to fix that vulnerability.

Deploying the update only takes a few minutes. But if you have 10,000 critical vulnerabilities in your environment, that’s a lot of analysis. If you have one full-time employee whose only job is to figure out what patches fix what vulnerabilities, that person can do about 100 a week. That means they can do around 5,000 a year. If you are going to fix critical vulnerabilities, you need two full-time employees who do nothing other than figuring out what patches to deploy. You still need someone else to carry out the actual deployments.

The industry has tried shifting to other models, but they’ve all failed too. You still need a full-time employee to research the patches. Nobody wants to spend $100,000 a year on a dedicated full-time employee for this task. And even if someone were, not very many people want that job.

But I don’t like bringing up problems without solutions. Here’s how Manage Engine handles the very difficult problem of patch prioritization.

Patch prioritization and sensible auto patching with Manage Engine

Manage Engine neatly solves this problem by integrating tightly with several vulnerability scanners. I tested it with Tenable scanners because that’s what I have access to. It also integrates with Rapid7, and I’m sure that integration works too. But I recommend Tenable because it finds vulnerabilities that Rapid7 misses.

If you have open source software running on Windows, Tenable will find more vulnerable open source software on those platforms then either Rapid7 or Qualys. And Manage Engine fixes nearly all of it.

The critical thing Manage Engine does that many of its competitors miss is that it integrates with your vulnerability scanner and imports your vulnerabilities, along with the details, in the language that security professionals speak. In a few minutes, you can find all of the vulnerabilities that meet whatever criteria your security team is asking for now, or will ask for in the future. Yes, it will change. But as long as IT has a tool that speaks security’s language, it’s easy to adjust. And then Manage Engine automates the process of finding the update to fix each vulnerability. That’s the hardest part. It automates the deployment too, but gives you varying degrees of control over that part, depending on your needs.

Integration with Tenable

The feature that interested me the most was its ability to integrate with Tenable scanners. I tested it with Tenable.io. All I had to do to configure the integration was enter API keys. After that, I had to enter a schedule for the two tools to synchronize, and I can also synchronize them on demand. After my first synchronization, I was ready to go.

The important thing is, after setting up the integration and synchronizing the tools, I get a tab in the user interface labeled Tenable.io threats. When I click on it, I see my findings as they appear in Tenable.io, along with an extra column that tells me if a patch is available or not. Next to each finding, there is a check box. I can tick the box, then click a button that says install patch, and it will intelligently send updates to the system. By intelligently, I mean that it deploys the best of available update for each finding. For example, I had four Firefox vulnerabilities on my system, because I installed an old version of Firefox. It deployed the newest version to resolve all of the findings, not just the critical finding.

This is important functionality, because it saves duplicative work. One of the reasons vulnerability prioritization doesn’t really work is because you’ll deploy an update that meets this month’s criteria, but then next month’s criteria change, and then you have to deploy another update to the same piece of software you updated last month. Deploying the newest available update saves that repeat work.

Filtering your data

The user interface also provides filters. You can filter out unpatchable vulnerabilities, but you can do lots of other cool stuff too. If your security team is using certain prioritization methods, you can create filters that match most of the common prioritization methods. They want you to fix high and critical severity, you say? You can make a filter for that. If you’re fixing exploitable vulnerabilities, you can’t filter on that but you can sort on it. If you’re fixing high and critical exploitable, you use a combination of the filters and sorting to do that. Last but first (ahem), if your security team is enlightened enough to use VPR, you can make a filter for that. Simply create the filter you need, then apply it, then you can click select all, and deploy your updates.

The updates also have a number of policies, the majority of which suppress the reboot, which is useful. Some of them allow the user to decline the updates, publish the updates to a self-service portal, or wake up systems to push updates and then shut them down. And if none of the included options work for you, you can create a policy that does.

Approving and disapproving updates

Anyone who has done patch management for a significant length of time knows that sometimes updates don’t work as well as they should. I think we tend to overestimate how frequently it happens, but it does happen 1-2 times a year. In Manage Engine Patch Manager, you can disapprove updates so it won’t deploy them. In the events of a problematic update, simply navigate to patches, supported patches, wait for the page to load, then search for the problematic update, and pick declined from the drop down labeled Mark as. From then on, until you come back and approve the update, Manage Engine won’t deploy it. It will deploy some other available update instead.

Caveman patching with Patch Manager

With lesser tools, I’ve fallen back on a strategy I call caveman patching, where I disapprove any updates that are known to be problematic, and just apply everything else applicable to the system. This methodology is crude, but it kept me sane when I was juggling multiple deadlines that were subject to change. It meant that when a deadline changed after my maintenance window had already passed, I didn’t have a problem because I had already deployed the update.

Of course, the main reason I could get away with this was because we tested every update in advance and I was judicious in keeping up with the approved and disapproved updates.

Of course, since I’ve used this method in the past, I wondered how it would work with Patch Manager. I found it does have the ability to select all and deploy all of the available updates.

The problem with that, of course, is that not all updates play nice with each other. The way Patch Manager handles it is to deploy as much as it can, and skip anything that can’t coexist with the majority. So when I had a system that needed 10 miscellaneous non-security updates, when I told Patch Manager to deploy all of them, it deployed six. I repeated the process after my reboot, and it deployed three. Then I repeated the process again, and got the last one.

So getting a completely up to date system is a fair bit of work, but that’s true with any other patching system. It might be nice if Patch Manager would warn you that not all of the updates that you selected can deploy together, but to its credit, it did the best it could. And it didn’t break anything.

Manage Engine Patch Manager review: in conclusion

I am a former system administrator who converted to vulnerability management. As a system administrator, I remediated 800,000 vulnerabilities and missed a deadline exactly one time. As a vulnerability management professional, I once guided a remediation team to fixing 1.2 million vulnerabilities in one epic summer.

When I look at a patch deployment tool, one of the questions I ask is whether I could do my old job with that tool. Because one of the reasons I left that system administration role that I was so good at was because they took my tools away and it was no longer possible for me to be effective.

The tools I used to use don’t exist anymore, so we have to look for alternatives. I haven’t been able to use Patch Manager at the scale of my old job, but it has all the functionality that I needed. I can easily deploy a single update or a group of updates. And I can create filters to deploy whatever I’ve been asked to deploy. Crucially, it works just fine on old and tired systems. When evaluating a patch deployment tool, it is important to test on old systems that have seen heavy use, not freshly built systems. Absolutely any tool should be able to do a good job of updating a freshly built and perfectly healthy system. You want the tool that works well on old and tired systems.

So I’m pretty impressed with Patch Manager. At $2 per system in quantities of 10,000, it costs less than many of the tools it competes with, it has all of the essential functionality, and it has very tight integration with one of the most popular vulnerability scanners on the market. That tight integration lets you get clean–as-possible vulnerability scans. And let’s be honest, that’s the main thing most of us want out of a tool like this. For 20 grand, it’s a bargain.