I just reviewed the details of the severe hacking incident that Microsoft is referring to as “Solarigate.”  It makes me appreciate why our product, TrueDEM®, is really the only choice for remote user monitoring. We don’t need special access or permissions. When a product requires admin access, that possibility for widespread damage is always going to be there.

That security weakness is the reason for the “valet key” concept in the auto industry. It allows a parking valet to park the car, but that’s all it does. The valet key only works on the doors and the ignition. It can’t be used open the glove box or the trunk. It only has the access needed to do the job.

Ironically, I had just recently installed a local copy of the “Solarigated” product on Server 2016, to see its complexity. . The company suggests that local administrator privileges are needed to “ensure the full functionality” of their tools. For a production on-premises installation, Windows Server was recommended. In addition, a SQL product was required,, as well as NET framework 4.8. The installation engine attempted to install and download those missing requirements. (Windows Server 2016 does not include .NET 4.8). It got me thinking. Could I be sure that the installer was downloading an unadulterated copy of SQL Express, or NET 4.8 for that matter?  How often do we blindly let installers “help” us by downloading any missing requirements? What admin powers are also granted on our behalf? This product, for example, assigns the SQL “dbcreator”, “public”, and” securityadmin” server roles.

And then there's opening the firewalls. The server and application monitoring product under discussion requires more than thirteen ports to be exposed.

Every required component expands the security footprint when a breach occurs. If an account can open many doors, then you must check all of those doors. These days, you must have eyes on every component.

How does that work if you want to monitor the Office 365 experience for all those remote users that you now have? In this case, each one would have needed the compromised software installed on it locally so it could become a “node”. How do you do that remotely and securely with software requiring local admin access? You wouldn’t.

This incident was difficult to track in a corporate network. Microsoft’s remediation suggestions include:
  • Immediately isolate the affected device. If malicious code has been launched, it is likely that the device is under complete attacker control.
  • Identify the accounts that have been used on the affected device and consider these accounts compromised. Reset passwords or decommission the accounts.

This would have been exponentially worse if the software were installed on remote users’ machines. If you would even somehow risk that.

Yet, that’s a major problem with most monitoring software. To truly monitor the real-user experience, you need to be where the users are, on their machines. Using their accounts, not special privileged accounts. Synthetic monitoring has some adjunct value, but not here. Call them agents, or robots, or nodes…you still need software on each device. TrueDEM can be deployed worldwide in about 15 minutes, with no special privileges.

According to Microsoft, "Solarigate" involved a DLL that was compromised during the build. I pondered what would happen if such a “hack” somehow occurred with our product. We have so many GPDR-compliant safeguards, it’s unlikely. But I admit that nothing is impossible. So, let’s pretend for a minute. What would be gained? Not much. TrueDEM does not run as any level of privilege. (It would be even weaker power than a valet key. You could start the engine, but you couldn’t go anywhere!) It is not possible to jump out of our application into another. TrueDEM runs in a tightly-controlled bubble. On Windows 10. No servers or SQL needed to monitor Teams, Exchange, SharePoint, OneDrive and more. Securely.