In the wake of recent attacks against MSP Automation tools, I’d like to take a moment to discuss ImmyBot’s security posture, and what our plans are to remain ahead of the curve.
- We are SOC 2 Type I compliant and intend to be SOC 2 Type II by 2022Q2
- ImmyBot instances are isolated with their own database, app services and storage accounts
- ImmyBot’s mandatory AzureAD SSO prevents unauthorized access from stale local user accounts.
- ImmyBot’s strict use of Entity Framework ORM means our codebase never generates SQL. All input is sanitized by default.
- Communication to Automate supports Google MFA so you don’t have to disable Multifactor authentication for our integration to function.
- ImmyBot Agent communication is secured through the Azure IoTHub
ImmyBot is built on .NET 5 and Vue.js hosted in Azure leveraging services like IoTHub, Service Bus, Azure SQL for Postgres. Our security posture benefits tremendously from using these modern services.
Authentication is performed by Microsoft’s App Service authentication proxy. We only allow AzureAD accounts to sign into ImmyBot. We do not have the concept of “local” users. This means that authentication to ImmyBot is limited only to active users in your AzureAD. When you terminate an employee and disable their AzureAD account, they no longer have access to ImmyBot.
Implementing Single-Sign On was as easy as flipping a switch in Azure. I’d argue it is easier to implement SSO today than it ever was to implement local user authentication. It pains me to see so many companies charging extra for SSO as I consider it to be a basic human right. (The SSO Wall of Shame | A list of vendors that treat single sign-on as a luxury feature, not a core security requirement.)
Another example is our database access is done exclusively through Microsoft’s Entity Framework ORM. This significantly reduces the likelihood of SQL injection, a common attack vector. Many legacy tools have SQL embedded directly in the application code itself, which can lead to vulnerabilities if the developers aren’t careful. (xkcd: Exploits of a Mom)
The Azure IoT Hub ensures we use best practices for device registration, and data encrypt communication both from our backend to the hub, and from the hub to our agents. It also offloads a significant amount of compute from our backend, managing connections and message brokering.
Each ImmyBot instance is separate, has its own IoT hub, Storage Account, Database, and Web Services. This was done intentionally to prevent cross-tenant data leaks. Our intention is to eventually offer ImmyBot in a Bring-You-Own-Cloud format allowing you to host it in your own Azure tenant where you control the location of the data. This is important for countries in Germany where data needs to remain within its borders.
The area that I believe we are most vulnerable is in our gratuitous use of unsigned PowerShell. If you have whitelisted your Automate, Control, or ImmyAgent exe in your Antivirus, and for example, the credentials to Automate, Control, or the IoTHub were compromised, an attacker could instruct the RMM to send scripts to your endpoints, and your Antivirus would allow it.
To mitigate this, we will begin signing the PowerShell scripts in the Global repository. In a subsequent release we will allow you to upload your own code-signing certificate to an Azure Key Vault that we will use to sign scripts in your local repository.
For this to be useful, you will need a security tool capable of only allowing execution of scripts signed by specific authors. Next generation security tools like ThreatLocker and Deep Instinct have this capability.
For legacy tools that only support path whitelisting, we will allow you to generate a folder name unique to your instance. ImmyBot will place all scripts in a folder with that name. You can then whitelist paths containing that string.
In conclusion, we take security extremely seriously and hope to build a tool that sets the standard.