Managing vendor and MSP remote access

The Canadian Centre for Cyber Security's assessment of the cyber threat from supply chains notes that managed service providers (MSPs) have enhanced access to the networks of many clients, so a single compromise of a provider can reach many targets. Remote management and remote support tools are a favourite path, both through compromised vendors and through criminals who install the same legitimate tools themselves.

The Cyber Centre's guidance for small and medium organizations on cyber supply chain security (ITSAP.00.070) and its document for consumers of managed services (ITSM.50.030) both stress knowing who has access to what, and asking providers how they control it. NIST's Cybersecurity Framework 2.0 adds a Govern function that includes cybersecurity supply chain risk management.

Most organizations underestimate how many ways in exist. Build the list, then cut it down.

• Remote monitoring and management (RMM) agents installed by your IT provider, current or former.
• Remote support tools (screen-sharing and unattended access software) installed by vendors.
• VPN accounts and firewall rules opened for a vendor.
• Vendor accounts in Microsoft 365 or Google Workspace, including delegated admin relationships for partners.
• Cloud-to-cloud connections: apps with API access to mail, files or accounting.
• Manufacturer cloud portals for cameras, door access, HVAC, phones and printers.

• Each vendor technician uses a named account, never a shared "vendor" or "support" login.
• MFA is required for every vendor account and for the remote-access tool itself.
• Vendor accounts get only the rights needed for the systems they support.
• Partner admin relationships in Microsoft 365 use granular delegated admin privileges with limited roles and an end date, rather than broad permanent rights.
• Former providers' accounts, agents and admin relationships are removed when the contract ends.

Standing, always-on access is the riskiest model. Prefer access that is switched on when needed and off afterwards: the vendor requests a session, someone in your organization approves it, and the access expires at a set time.

Many remote support tools can require a user on site to accept the connection. For unattended access, which IT providers often need for overnight patching, require that it go through the provider's own MFA-protected platform, and ask how they protect that platform.

If an incident happens, these logs are often the first evidence an investigator needs to establish whether a vendor path was used.

• Session logs (who connected, to which machine, when, for how long) are kept and available to you, not just the vendor.
• Sign-ins by vendor accounts to your cloud tenant are reviewed monthly.
• Alerts fire on new remote-access software being installed, or on remote sessions outside agreed windows.
• Logs are retained long enough to support an investigation; ask how long the vendor keeps them.

Put the controls in writing. ITSM.50.030 lists the questions to ask a provider on access control, logging, incident response and data handling. At a minimum, contracts should cover:

• MFA and named accounts for all staff accessing your systems.
• Notification to you when the vendor suffers a security incident that could affect you, within a stated period.
• Your right to receive access and session logs.
• Restrictions on subcontractors and offshore access.
• Return or destruction of your data and removal of all access at the end of the contract.

1. 01

   At contract end

   Uninstall agents, delete accounts, remove admin relationships, close firewall rules, and confirm in writing.

2. 02

   At technician departure

   The vendor tells you when staff with access leave; their named accounts are disabled.

3. 03

   After a vendor breach

   Suspend the vendor's access until you understand the scope, and check your own logs for activity from their accounts or tools.