How secure is your RMM, and what can you do to better secure it?

My MSP does not use Kaseya VSA. That doesn’t mean though that I didn’t have a sleepless night this Friday 2nd July. I was ready to help, and offered my assistance to impacted MSPs for free. It felt like the right thing to do. Whenever any event like this occurs, it threatens and damages all of us. It erodes the reputation and trust of any MSP type business. The first step in solving any problem, is admitting that there is one. Our industry is now in the unfortunate position where the tools we use to support our clients are likely the biggest security threat they face. Where there is risk, we have to introduce control. Are you doing everything you could be doing to keep your RMM and related stack tools as secure as they could be? Though I am mostly targeting these tips at RMM, they actually apply to any product you have in your stack.

Area 1 – Keep your solutions updated

This is an absolutely fundamental step, and even up to today I still see many MSPs getting this wrong. I’ve lost track of how many times I have seen people come in to the MSPGeek Slack looking for help, only to find out that they are running months behind on their patches. This is further compounded by vendors not always being honest with their release notes and not letting people know that a release contains critical security fixes.

• Setup a recurring weekly task to check manually for updates to your solution stack
• Ensure that you have actually defined who is responsible for doing this
• Double check that the appropriate people are getting release notes/notifications from your vendors when they release fixes
• Where there are noted critical security fixes, patch them even if it’s the middle of the day. In certain cases people are reverse engineering these patches to see what security holes were patched, essentially putting the vulnerability in the public domain
• Always give yourself a roll back point like a snapshot/full backup
• Don’t forget to check for other updates in other parts of your stack. As an example, with ConnectWise
  • Solution Center to update Plugins
  • Ensure all integrations are up to date
  • Don’t just focus on RMM. ConnectWise Control is often over looked. That has plugins too. Whether you are on-premise or cloud, you should be periodically check they have been updated

Area 2 – Audit your Accounts

When is the last time you went in to your RMM and looked at the user accounts in there? How sure are you they are all 2FAed? Are they all even needed?

• Setup a recurring task to check manually the users who are in your tools
• Do you have a password policy for staff? Do you enforce it? For systems like RMM we enforce a totally random complex character password with a ridiculous length, stored in a password manager
• Are you utilising 2FA through text or phone call? Telephone numbers can be spoofed
• Check that all of those accounts have 2FA enabled
• Look at the level of access for each account, and apply the principle of least privilege. Users should have the absolute minimum permissions needed to perform their role. Don’t just assume they do, actually check!
• If your tool supports it, check when all users last logged in and remove accounts that are not actually used
• Review your integration/API Keys. If you’re storing these, are they secured in a secure location? If you don’t know, cycle them and generate new keys

Area 3 – Technical and Network Protection

This list is not exhaustive as technical controls can be virtually limitless. There is additional emphasis for on-premise RMM partners in this section.

• Can you lock down access to the Administrative section of your RMM via IP Address? If you can, you should absolutely enforce access only from trusted, secured locations
• Are all your agents in one country? Put geographic restrictions on your firewall to block other countries
• Even better, if all your assets are in trusted networks with fixed IP addresses then block anything else
• Is your RMM server accessible from your main internal network? Put it in an isolated network and heavily restrict its access from other parts of your network. That way, your own internal network can’t be used as a jump point to get in to it
• If you’re able to, utilise the IPS functionalities in your firewall to examine network traffic being passed to your RMM server
• If you’re on-premise, check all port forwards you have to ensure they are actually required. In ConnectWise’s case there are plenty of ports that could be opened based on advice from a couple of years ago that don’t actually need to be.
• Limit access to your RMM server to only the appropriate staff. Remember the principles of least privilege
• Ensure you are applying NIST/CIS controls against your internal assets. Your own internal MSP security should be better than any of the clients you support
• Ensure you have appropriate endpoint detection installed. This should have EDR capabilities at an absolute minimum. Hopefully you’re not rolling with a simple AV on this server
• Consider putting a last line of detection and defence in (Huntress as an example)
• Do your clients have decent AV too? Basic AV just doesn’t cut it anymore. Proper ransomware protection may well just save them.

Area 4 – People and Processes

• Run tabletop exercises to determine your readiness with your staff. Assume the worst has happened and assess your response. https://cybersecurity.wa.gov/tabletop-exercises https://redcanary.com/blog/using-tabletop-simulations-to-improve-information-security/
• Train your staff on security. Talk to them about the importance of good security. When there’s a breach like the Kaseya breach let all of your staff know about it
• Develop an Incident Response plan for both when your vendor is having a security issue and for when an attack is taking/has taken place. Your staff should have quick access to this so they can react quickly. 5 minutes could mean the difference between 2 client’s encrypted and all of them being encrypted
• Now you have a plan, practice it!
• Have a kill switch. Something you can run in that worst case emergency that turns off your RMM/stack infrastructure
• Understand how your RMM issues commands to its endpoints so you can quickly reverse anything that gets queued
• Perform regular risk assessments against your infrastructure. Actually monitor for and document your risks and the controls and processes you have in place (see and work to ISO27001)

Area 5 – Vendor Pressure

We should absolutely all band together as much as we can and apply hard pressure against vendors to better secure these tools. SOC2 just doesn’t cut it. Years of technical debt and PE takeovers have caught them napping. I discussed this a bit more in my article here https://www.gavsto.com/rmm-providers-its-time-to-pivot-or-your-product-will-die/. In my opinion, any RMM nowadays should have at a minimum:

• 2FA (with the ability to login through your own controlled SSO provider)
• Restrictive IP whitelisting
• Signed client communication
• The ability to nuke all active agent installers
• The ability to approve agent installs, and until they are approved from the Admin side they can only perform limited, or no functions
• The ability to untrust an agent
• Generous programs to reward people who report security vulnerabilities
• Verbose logs which can be sent in to modern day SIEMs and are actively analysed for anomalous behaviour
• Where your RMM provider is on the ball when it comes to security, being cloud based is better. They have the SOC/Security teams to look after the product better. Unfortunately a number of MSPs end up not securing on-premise installations properly

I am open to any other suggestions for additions. If you have one please let me know and I’ll keep this updated.

EDIT: 4th July 2021. I think it’s worth putting another angle in to this after a conversation with Dave Sobel from MSP Radio. We talked about how there may be a higher level question than how to secure your RMM, and that’s are you considering a way to back out the concept of RMM permanently from your MSPs? It may sound like a drastic angle, but as Dave points out this kind of thing keeps happening and vendors are still not doing enough. If my MSP were at the point where 100% of our clients were 365/Intune based and configuration was enforced in that way I can see RMM being a lot *less* of a requirement. There’s still a Remote control component and maybe a monitoring component needed. I wonder if Microsoft will take Intune in that direction? I know they are working on multi-tenant management in the form of Lighthouse.