Security

How to Secure RMMs

On Friday, a popular IT tool called Kaseya VSA was hacked.

Brian Scheewe

Tuesday, July 6, 2021

How to Secure RMMs

RMM Security: How to Protect Remote Monitoring and Management Platforms

Remote Monitoring and Management (RMM) software gives IT teams and Managed Service Providers (MSPs) powerful tools for managing endpoints remotely. Administrators can monitor device health, deploy software, execute scripts, install patches, troubleshoot systems, and remotely access endpoints from a centralized platform.

These capabilities make RMM security particularly important. If an attacker compromises an RMM platform or privileged account, the same administrative capabilities used by legitimate technicians can potentially be abused across multiple managed endpoints.

The 2021 Kaseya VSA attack demonstrated the potential impact. Attackers exploited vulnerabilities affecting the RMM platform as part of a ransomware attack that reached downstream organizations. The incident highlighted a broader security principle for the industry: RMM platforms should be treated as privileged infrastructure and protected accordingly.

There are common-sense steps to securing RMM software, such as keeping software patched, maintaining reliable backups, using strong authentication, and limiting administrative privileges. However, organizations should go further by applying multiple layers of protection around RMM access, automation, endpoints, and administrative activity.

This guide covers practical RMM security controls that IT teams and MSPs can use to reduce risk and limit the potential impact of compromised accounts, software vulnerabilities, malware, and other threats.

Why RMM Security Matters

RMM platforms typically have much more control over endpoints than ordinary business applications. Depending on the platform and permissions assigned, an administrator may be able to:

  • Remotely access endpoints
  • Execute scripts and commands
  • Install and remove software
  • Deploy patches
  • Modify configurations
  • Monitor system activity
  • Restart devices
  • Manage files and processes
  • Automate administrative tasks across multiple endpoints

For an internal IT department, compromising this level of access could expose a significant portion of the organization's infrastructure. For an MSP, the potential scope can be even greater because a single RMM environment may provide administrative access to endpoints belonging to multiple customers.

RMM security therefore needs to address more than passwords. Identity, permissions, network exposure, endpoint security, automation, logging, backups, and incident response should all be part of the security strategy.

Common RMM Security Risks

Understanding how RMM environments can be exposed helps IT teams determine where additional controls are needed.

Compromised Administrator Accounts

Administrator credentials are valuable because they can provide extensive access to managed endpoints. Stolen passwords, phishing attacks, credential reuse, or poorly controlled accounts can give attackers a path into an RMM environment.

Multi-factor authentication, individual user accounts, least privilege, and regular access reviews can reduce this risk.

Software Vulnerabilities

Like any software, RMM platforms can contain vulnerabilities.

Keeping the platform and supporting infrastructure updated reduces exposure to known vulnerabilities. Zero-day vulnerabilities present a more difficult challenge because a patch may not initially exist.

This is one reason RMM security should use defense in depth. If one control fails, other security layers can still limit what an attacker can reach or do.

Excessive Administrative Privileges

Not every technician needs unrestricted access to every endpoint, customer, script, or administrative function.

Overprivileged accounts increase the potential impact of compromised credentials and human error. Permissions should reflect actual job responsibilities.

Remote Access Abuse

Remote access is one of the most useful capabilities of RMM software, but it is also sensitive.

Organizations should control who can initiate remote sessions, which endpoints each user can access, and what technicians can do during those sessions.

Malicious or Unauthorized Scripts

RMM scripting and automation can execute actions across large groups of endpoints very quickly.

This efficiency can become a security risk if an account is compromised or an unsafe script is deployed. Controls around script creation, approval, execution, and logging can help reduce this risk.

RMM Security Best Practices

Organizations should combine several security controls rather than relying on a single defensive measure.

1. Enable Multi-Factor Authentication

Enable multi-factor authentication (MFA) for RMM user accounts, particularly accounts with administrative privileges.

MFA adds another authentication requirement when someone attempts to access an account. This can reduce the risk associated with stolen or exposed passwords.

MFA should not be treated as the only defense. It works best alongside strong passwords, individual accounts, appropriate permissions, monitoring, and other access controls.

2. Apply Least Privilege

Users should only receive the permissions required to perform their responsibilities.

A technician responsible for a particular customer, department, or endpoint group does not necessarily need unrestricted administrative access across the entire environment.

Review privileges regularly and remove access when:

  • Employees change roles
  • Technicians no longer support particular customers
  • Temporary access expires
  • Contractors complete their work
  • Employees leave the organization

Reducing unnecessary privileges limits what a compromised account can potentially affect.

3. Use Role-Based Access Control

Role-based access control (RBAC) makes it easier to assign permissions consistently.

Instead of manually creating unique permission sets for every technician, organizations can establish roles based on responsibilities and assign appropriate access to those roles.

Sensitive functions such as account administration, scripting, security configuration, and backup deletion may warrant tighter restrictions.

4. Restrict RMM Management Access

Where practical, limit where administrators can access the RMM management interface.

Organizations may use network restrictions, approved IP addresses, VPN access, or other controls depending on their RMM architecture and operational requirements.

Reducing unnecessary exposure can eliminate potential paths into privileged management systems.

5. Consider Web Application Firewall Protection

For applicable internet-facing infrastructure, a Web Application Firewall (WAF) can add another layer of protection against certain web-based attacks.

A WAF can inspect web traffic and apply security rules intended to identify or block malicious requests.

It does not replace secure application development, vulnerability remediation, authentication, or patching. Instead, it forms another component of a layered security strategy.

6. Use Intrusion Detection and Prevention

Intrusion detection and prevention technologies can help identify suspicious network activity.

An Intrusion Prevention System (IPS), for example, may identify known malicious traffic patterns and block certain attacks before they reach protected infrastructure.

Organizations should combine these technologies with endpoint monitoring and RMM activity logging to improve visibility across different layers of the environment.

7. Keep RMM Infrastructure Patched

Apply security updates to RMM infrastructure and related systems promptly.

Organizations using self-hosted platforms should establish clear responsibility for maintaining the RMM server, operating system, database, supporting services, and other infrastructure.

Patch management reduces exposure to known vulnerabilities, although additional controls remain necessary for threats that do not yet have available patches.

Protect the Endpoints Managed by Your RMM

Securing the management platform does not eliminate the need to protect individual endpoints.

Endpoint controls can provide additional barriers if another component of the environment is compromised.

Establish an Endpoint Security Baseline

Define the minimum security configuration required for managed endpoints.

Depending on the organization and device type, this baseline can include:

  • Endpoint protection
  • Host-based firewalls
  • Disk encryption
  • Automated security updates
  • Application controls
  • Restricted local administrator privileges
  • Endpoint monitoring
  • Security logging
  • Secure Boot on supported systems

RMM monitoring can help IT teams determine whether these controls remain enabled across managed devices.

Enable Secure Boot on Supported Systems

Secure Boot is designed to help protect the startup process by allowing a system to boot using trusted software.

On compatible hardware and operating systems, Secure Boot can form part of an organization's endpoint security baseline. It may help protect against certain threats that attempt to interfere with the system before the operating system fully loads.

Secure Boot does not directly protect an RMM platform from compromise and should not be considered a replacement for endpoint protection, patching, MFA, or access controls.

Instead, it adds another security layer to supported endpoints.

IT teams managing large device fleets can establish standards for when Secure Boot should be enabled and periodically verify that endpoint security configurations remain compliant.

Secure RMM Scripting and Automation

Automation is one of the major advantages of RMM software. A technician can perform an administrative task once and deploy it across many endpoints.

That capability deserves additional safeguards.

Add Controls Around Mass Scripting

RMM platforms should provide safeguards for unusual or high-impact mass scripting activity.

For example, an organization could require additional verification when an account attempts to execute a new script across a large number of endpoints.

Alerts can also be generated when script activity differs significantly from the technician's normal behavior.

Use Script Approval Workflows

Organizations can implement approval processes for sensitive scripts.

Instead of allowing any technician to immediately create and execute new scripts across production endpoints, higher-risk automation can require review by another authorized person.

Once reviewed and approved, trusted scripts can be maintained in a controlled script library.

Separate Script Creation and Approval

For particularly sensitive environments, consider separating the ability to create automation from the ability to approve high-impact execution.

Separation of duties reduces the amount of control held by a single account.

Maintain Script Activity Logs

RMM platforms should maintain detailed records of script activity.

Logs should make it possible to determine:

  • Who initiated the script
  • Which script was executed
  • When it ran
  • Which endpoints received it
  • Whether execution succeeded
  • What changes were made where possible

These records can be invaluable when investigating suspicious activity.

Protect RMM User and Administrator Accounts

Account security is fundamental because legitimate RMM credentials can provide extensive access.

Avoid Shared Administrator Accounts

Every technician should have an individual account.

Shared accounts make it difficult to determine which administrator performed an action and complicate incident investigations.

Individual identities improve accountability and allow permissions to be revoked without disrupting other technicians.

Review Accounts Regularly

Periodically review RMM users and their permissions.

Look for:

  • Former employees
  • Inactive users
  • Duplicate accounts
  • Unnecessary administrator privileges
  • Temporary accounts that were never removed
  • Third-party accounts that are no longer required

Account reviews should also be incorporated into employee offboarding procedures.

Protect New Account Creation

New administrative accounts should not appear without appropriate authorization.

RMM platforms should provide mechanisms for notifying administrators when accounts are created or when privileges change.

For particularly sensitive environments, organizations may require approval before privileged accounts become active.

Protect Backups From RMM Compromise

Backups are critical during ransomware and other destructive security incidents.

If an attacker gains administrative access to an environment, they may attempt to destroy or encrypt backups before disrupting production systems.

Restrict Backup Administration

Do not assume every RMM administrator needs permission to delete or modify backups.

Backup administration should follow least privilege.

Require Additional Verification for Destructive Actions

High-risk operations such as deleting or overwriting backups can require additional authentication or approval.

This can make it more difficult for a compromised administrative session to immediately destroy recovery options.

Maintain Protected Recovery Copies

Organizations should maintain backups according to their recovery requirements and ensure that compromise of ordinary endpoint credentials does not automatically provide unrestricted control over every backup.

Periodically test restoration procedures so the organization knows its backups can actually be used during an incident.

Monitor RMM Activity for Signs of Compromise

Preventive controls are important, but organizations also need the ability to identify suspicious activity.

Potential indicators of RMM abuse can include:

  • Unexpected scripts deployed across many endpoints
  • New administrator accounts
  • Unusual remote sessions
  • Large-scale software installations
  • Attempts to disable security tools
  • Unexpected configuration changes
  • Administrative activity outside normal working patterns
  • Sudden changes to backup settings
  • Repeated authentication failures

Not every unusual event indicates an attack. Monitoring provides the information IT teams need to investigate whether activity is legitimate.

Centralize Security Logs

RMM logs can be combined with information from endpoints, authentication systems, firewalls, and other security tools.

Centralized visibility can make it easier to identify relationships between events.

For example, an unusual administrator login followed by a new script deployment across hundreds of endpoints deserves considerably more attention than either event viewed in isolation.

What to Do if Your RMM Environment Is Compromised

Organizations should have an incident-response plan before an RMM security incident occurs.

A compromised RMM environment can affect many systems quickly, so teams need clearly defined responsibilities and escalation procedures.

Isolate Affected Infrastructure

Identify the RMM infrastructure and endpoints potentially involved in the incident.

Where appropriate, isolate affected systems to limit further malicious activity while preserving logs and evidence required for investigation.

Address Compromised Credentials

Investigate administrator accounts, active sessions, service accounts, API credentials, and other authentication mechanisms that may have been exposed.

Credentials should be handled according to the organization's incident-response procedures.

Review Administrative Activity

Analyze recent:

  • Script execution
  • Software deployment
  • Remote sessions
  • User creation
  • Permission changes
  • Security configuration changes
  • Backup operations

This can help establish the scope and timeline of the compromise.

Determine How to Remove Malware Safely

When investigating how to remove malware from RMM-managed endpoints, first determine what malware is present and how extensively the endpoint has been compromised.

Deleting a visible malicious file may not fully remediate the system. Malware can establish persistence, create additional accounts, alter security settings, steal credentials, or deploy other malicious components.

IT teams should follow established incident-response procedures, identify affected systems, contain the threat, and validate that remediation has removed malicious persistence.

For serious compromises, rebuilding affected endpoints from a known-good state may provide greater assurance than attempting to clean individual malicious components.

Restore From Trusted Backups

If systems need to be restored, confirm that the selected backups predate the compromise and have not been altered.

After restoration, validate security configurations, apply necessary updates, address compromised credentials, and monitor systems for signs of recurring malicious activity.

Building an RMM Security Checklist

A repeatable security checklist helps IT teams verify that important controls remain in place.

Review the following regularly:

  • MFA is required for privileged RMM accounts
  • Individual accounts are used instead of shared credentials
  • Administrator permissions follow least privilege
  • Inactive and former-user accounts are removed
  • RMM software and supporting infrastructure are patched
  • Management interfaces have appropriate access restrictions
  • Remote sessions are logged
  • Endpoint protection is active
  • Secure Boot is enabled where required and supported
  • High-impact scripting has appropriate safeguards
  • Script activity is logged
  • Backup deletion and modification are restricted
  • Administrative account creation is monitored
  • Security logs are retained
  • Endpoint security configurations are monitored
  • Incident-response procedures address RMM compromise
  • Backup restoration procedures are tested

The checklist should be reviewed whenever the RMM environment, security requirements, or threat landscape changes.

Why Layered RMM Security Is Necessary

Some RMM security measures can add friction for technicians and administrators. Additional authentication, restricted privileges, script approvals, and access controls can add steps to tasks that would otherwise be immediate.

The level of access provided by RMM software makes those safeguards important.

The Kaseya VSA incident demonstrated the potential consequences when vulnerabilities in privileged management infrastructure are exploited. However, RMM security should not focus on preventing a repeat of one particular attack.

Organizations need controls capable of addressing multiple failure scenarios, including compromised credentials, excessive privileges, malicious scripts, software vulnerabilities, malware, misconfiguration, and human error.

No single security measure can eliminate all of these risks.

MFA can protect authentication but cannot patch a software vulnerability. Secure Boot can protect aspects of the endpoint startup process but cannot prevent stolen RMM credentials. A firewall can restrict network access but cannot necessarily stop an authorized account from being abused.

Layering these controls creates a stronger overall security posture.

FAQ About RMM Security

What is RMM security?

RMM security refers to the controls and practices used to protect Remote Monitoring and Management platforms, administrative accounts, remote connections, automation, and managed endpoints against unauthorized access and abuse.

Because RMM software can provide extensive control over endpoints, organizations should treat it as privileged IT infrastructure.

Why are RMM platforms attractive targets?

RMM platforms provide centralized administrative capabilities. A sufficiently privileged RMM account may be able to remotely access systems, execute scripts, deploy software, or change configurations across multiple endpoints.

This makes protecting RMM accounts and administrative capabilities particularly important.

How can MSPs improve RMM security?

MSPs can strengthen RMM security by requiring MFA, applying least privilege, reviewing accounts regularly, controlling remote access, monitoring administrative activity, protecting scripts and automation, maintaining reliable backups, and securing individual endpoints.

Does Secure Boot improve RMM security?

Secure Boot primarily protects the boot process of supported endpoints rather than the RMM platform itself.

It can contribute to a layered endpoint security strategy alongside endpoint protection, patching, access controls, encryption, and monitoring.

Can MFA prevent an RMM compromise?

MFA can significantly strengthen account authentication, but it cannot prevent every type of RMM compromise.

For example, MFA does not eliminate vulnerabilities in the underlying software. Organizations should combine MFA with patching, least privilege, monitoring, network controls, and other defensive measures.

How should RMM scripts be secured?

Organizations can restrict scripting privileges, maintain approved script libraries, require additional authorization for high-impact automation, monitor mass script execution, and retain logs showing who executed scripts and where they ran.

What should you do after an RMM security incident?

Follow your incident-response process. Determine the scope of the compromise, isolate affected systems where appropriate, investigate accounts and administrative activity, address malicious access, remediate affected endpoints, and restore systems from trusted backups when necessary.

Level: Simplify IT Management

At Level, we understand the modern challenges faced by IT professionals. That's why we've crafted a robust, browser-based Remote Monitoring and Management (RMM) platform that's as flexible as it is secure. Whether your team operates on Windows, Mac, or Linux, Level equips you with the tools to manage, monitor, and control your company's devices seamlessly from anywhere.

Ready to revolutionize how your IT team works? Experience the power of managing a thousand devices as effortlessly as one. Start with Level today—sign up for a free trial or book a demo to see Level in action.