Tactical RMM is an open-source remote management and monitoring solution that is a disruptor for the RMM sector and a fast-favorite among system administrators, system engineers, and information technology managers. The fandom surely has many individual reasons all linked to a shared thought: the RMM market is a minefield of options that are surprisingly terrible in one way or another.
I have personally been comparing RMMs for years and found the topic so exhausting and frustrating that I never felt I could articulate it. The more time I spent digging into the various options the more I felt overwhelmed, ignorant, and resigned myself to choosing the lesser of all evils when making recommendations or implementing my own solutions. This torrent of negative associations has forced me to reconsider my position annually and after nearly a decade of doing the same thing I have little to show for.
I recently forced myself to rethink and start fresh. Just as I did, serendipity brought Tactical RMM into my crosshairs. In this recompile of ideas I distilled RMM’s into three principles: security, functionality, and customization.
Security.
While the SolarWinds hack continues to mutilate systems the reality here is that RMM vendors are a hot target. Most do not have SOC2 certifications, and many have jaw-dropping responses to security questions. Take Atera, for example, as you are likely to see ads for it the moment you search for RMM alternatives. Reviewing their security disclosure should be enough to make anyone run. Why? Because about half of that page is dedicated to a copy and paste they took from Microsoft Azure. Of course Azure data centers are physically/environmentally/power/fire/etc controlled, we all know that. The point of a security disclosure is to show how a vendor mitigates risks their operating process, production, and development environments. Atera, like many others, dodges all of that and is a poster child for loss-of-trust.
It may seem naive to think that you can do better with a self-hosted solution when other products seemingly offer a better understanding and disclosure of security management. Most certainly, if you simply install the solution without a strategy, experience, and proper policy you most certainly will create risks. However, that’s not an argument for not doing it, because secure self-hosted implementations are possible. I believe that a self-hosted open-source solution has the potential to materially decrease security risks when implemented properly.
Functionality.
System administrators most often prefer RMM’s for remote access. In most cases that means remote control over a desktop, but that’s a shallow understanding of what RMM is about. Remote management really means inventory, scripting, automation, compliance, and reporting.
It may seem pretty logical to say that complexity grows with functionality, the trend I have observed is that complexity grows exponentially while functionality is fairly linear. Take BarracudaMSP’s patch management — a task that today can be accomplished with a one-line PowerShell script is somehow a beast that is so convoluted that the alternative — simple patch management- has become a sales-pitch for products like NinjaRMM. At the same time, while both products offer automation, they are dwarfed by capabilities within AutoTask or even Kaseya. I am willing to believe that many MSPs make the choice based more on answering the question of “what can we manage” [to use effectively] rather than “what can we manage with?”
All of the products offer inventory, scripting, automation, compliance, and reporting to some degree, but I have yet to find a solution that actually works to meet any one of these well. For many of the larger products, they feel archaic and are in desperate need of a rewrite that may never happen. For newer products, the often seem bare and impossible to compare. That is not to say that Tactical RMM is better at any of these, but it has the potential. The foundation is clean and the roadmap is promising.
Customization.
Like security and functionality, there are the typical things we all care about: logos, dashboards, layouts, etc and often refer to that as customization. That’s all very superficial. Real customization is adapting tools and products to the way you work. Customer service is the differentiator among MSPs and the key to IT success when it is an internal unit.
Tactical RMM gives us the opportunity to fork the code-base and begin developing internal solutions. This includes adapting the product to your functional and operational needs at the source, literally! I really do mean the source code. Personally, I believe that if your MSP/MSSP/IT department has no system engineers and software engineers on staff than you are severely behind the curve. I guarantee that your services will be replaced by someone else’s better adaptation to changing times in the next five years. Good news is that there is still time to pivot and adjust. Since the RMM component is so integral to customer service success and your differentiation, why not make it the product you truly customize to fit your business.
Try it.
The roadmap for running Tactical RMM internally should be to leverage Microsoft Azure or AWS. Either option will offer container services that can be coupled with scalability and security. While architecting a secure cloud environment for Tactical RMM is a major challenge, my personal roadmap starts with a single Ubuntu 20.04 instance, then moves to securing it with load-balancing and application firewall, and finally moving the entire setup to AWS Fargate.
To help you start your journey, I used AWS EC2 Ubuntu 20.04 AMI (099720109477/ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-20210223) and have re-written the Tactical RMM installation steps into an automation script for fast deployment.
Don’t go into production just yet.
We like this software. We like this approach. Unfortunately, it’s not a product you can deploy to any production system, and not even internal dev systems. While this is open-source software there is no known oversight. More importantly, during the deployment it sends pre-compiled agent signed by “AmidaWare LLC”. Even though source for this agent is also published, there is simply no guarantee that the pre-compiled package and the source are the same. While you can compile your own kit and use that, there are other red flags too.
Before explaining them, it’s important you conduct your own risk assessment. At the moment, the information we compiled on the software, the capabilities, and the authors has made us step back from further review until we can get good answers to basic questions. While we won’t publish our research at this time, I will leave this with two questions you should ask yourself open for your consideration.
What are the risks? Well, for starters it’s a legitimate remote control and management tool. All pieces of it align with production software, and it’s behavior is consistent with it’s purpose, so the risk is good software used for malicious acts. Since the console requires public internet access to be useful, and the agent does too, the biggest risk is that this RAT (remote administration tool) allows malicious actors to do what you do with it.
How could you know? One way is to review all the code, but with third-party libraries and integration this is inefficient to start. We never start risk assessment with the tools — we always begin with company culture. Because there is not much of a company here, we look at the fundamentals and the author of the software. In this case, it’s allegedly Daniel Parsi, a system administrator at Nasa JPL (at least according to the GitHub). I encourage you to do your own research and make your judgement.
