Skip to main content
All BlogsIdentity-Based SecurityZero Trust

Vendor Remote Access and Security: A Guide

By May 14, 2024 No Comments

Author: Carol Caley, PMM, Xage Security

Companies increasingly rely on external parties for essential services, including work that requires access to their network. That can mean creating user accounts for vendor personnel to connect directly to your assets to provide support and maintenance. It can also mean providing privileged access to your network directly to vendor software, hardware, or systems—which comes with the software supply chain risk inherent to connecting to or using third-party systems. Here we’ll focus primarily on providing user access, but both are important to consider for security. 

So, how do you set strong vendor remote access policies and enable access in a secure way? 

Jump to a Topic

  1. Vendor Remote Access Best Practices
  2. Build Secure Remote Access Infrastructure Yourself
  3. VPN Risks
  4. Applying Zero Trust Principles to Remote Access
  5. Pre-Built Vendor Remote Access Solutions: Why?
  6. Specific Consideration for OT and Industrial Infrastructure
Vendor Remote Access and Security

Vendor Remote Access Best Practices

Enforce Least-Privilege Access Control for Third-Party Users

Cyber attackers often compromise privileged accounts to expand their access in a target environment. This risk increases as more third parties are granted privileged access to business-critical systems. Enabling remote access for third-party vendors while still enforcing the principle of least privilege is a crucial cybersecurity control for your remote access strategy. 

Preserve Security Layers Across Cloud, IT, and OT

Be wary of any remote access solution that exposes vulnerable protocols or sensitive resources directly to the internet. Your remote access solution should preserve logical segmentation while enabling secure traversal of multiple network or security layers. This includes utilizing a multi-hop architecture that provides session and protocol termination, and multifactor authentication (MFA) challenges as an option at each layer without added complexity or friction for the remote user. 

Require MFA

This one could probably go without saying, but MFA should be required for any vendor or third party connecting to your systems. As noted, having multiple layers of MFA is a strong option to have available, especially for particularly sensitive data or systems. 

In-Depth Auditing or Session Recording

Your setup should take an identity-aware approach to activity logging, auditing, and session tracing, even if the participating workloads or devices have distinct identity providers or lack unique user accounts entirely. Ideally you have the capability for over-the-shoulder monitoring of remote sessions and instant revocation of privileges or session termination by an administrator if unacceptable behavior is observed.

Ensure a Unified System for Cloud, Datacenter, and Operational Environments

Managing access and protecting apps and workloads across public and private cloud deployments introduces new challenges. Many organizations face ballooning access management difficulties such as the use of high-risk VPNs, shared service accounts, and the inability to enforce consistent policies across multi-cloud environments. 

The challenges grow as companies adopt new software while still relying on legacy private applications and even proprietary desktop apps that now need to be used remotely for business critical tasks. For vendors (and employees) you want a unified way to enable remote access to diverse environments so you don’t end up stitching together multiple solutions.

Build Vendor Remote Access Infrastructure Yourself

First, I want to note that there are limitations to building this out yourself and a lot of great tools you can buy instead of reinventing the wheel. That said, if you want to build, not buy, there are a few possible approaches.

Connect a VPN to a Subnet

You can provide a dedicated VPN for vendors which connects to a subnet. If you have multiple vendor staff or contractors each can be assigned their own VM within the subnet. Using firewall rules, ACLs or security groups to ensure that the VM can only access the specific system that vendor will need access to and nothing more—following the zero trust principles of least privilege. 

  • Make sure routing is disabled so the subnet is actually isolated and not able to connect to other parts of the network.
  • Monitor activity using audit logs or, better yet, session recording

It’s critical that you carefully inventory ACLs, firewall configurations, and other settings to ensure that there are no vectors connecting vendor-accessible systems to other, more sensitive parts of your network to buffer against the very real risk of a third party being compromised. Depending on the complexity of your infrastructure, this can become challenging to manage and secure. 

As Target discovered back in 2013, it’s easy to make a mistake. When a hacker obtained login credentials for Target’s HVAC vendor, they were able to use them to access their payment systems. It highlights the importance (and difficulty) of carefully isolating extremely sensitive data like customer payment information from vendor access. Tools like ZTNA can enable the needed access without the manual effort of updating firewall rules or ACLs..

Jump Servers

In the industrial world, using jump servers is a common tactic to avoid direct internet connectivity to OT assets. These proxies can help strengthen security despite weak protocols and also regulate the network traffic entering OT environments, PLCs and other industrial control devices are extremely likely to be running old and potentially vulnerable software. 

Users access these operational systems remotely and indirectly by connecting to a jump server via VPN. However, this setup poses substantial management challenges. Each remote user requires a dedicated account on the jump server, leading to the accumulation of hundreds or even thousands of accounts. These accounts often become obsolete quickly—especially those of temporary or former employees—but are rarely deactivated.

Additionally, valid credentials are needed to access critical operational assets like PLCs through the jump servers. These credentials should be rotated regularly, which can be an uphill task involving manual work. Note that the accumulation of dormant or infrequently used accounts makes jump servers a common target for cyber attacks. Attackers attempt to gain broad access to OT systems. Moreover, these jump servers often operate on outdated Windows software, lacking the latest security patches.

VPN Risks

I want to note here that VPNs are inherently risky and are rapidly being replaced with more secure solutions like ZTNA and solutions combining access, PAM, RPAM, and microsegmentation capabilities. VPNs provide users with legitimate credentials wide and unchecked network access. This makes them prime targets for cyber attackers who often exploit compromised credentials—one of the most common methods for initiating data breaches. According to the 2023 Verizon Cost of a Data Breach Report, stolen credentials were involved in 49% of all reported breaches.

Moreover, the underlying technology of many VPNs, often based on outdated legacy systems, contains numerous vulnerabilities. For example, in the case of the Ivanti VPN, researchers found that it was using open-source code that hadn’t been updated for over two decades.

Applying Zero Trust Principles to Remote Access

Part of the issue with VPNs is they were designed with convenience in mind, not as security tools. Now, zero trust principles are being applied both to local access and remote access. If a device or user on the network must frequently verify its validity, then a remote connection should be treated with as much or more caution. But there’s a lag in adoption because key zero trust principles like least privilege and microsegmentation aren’t built into traditional remote access tools. 

That’s changing with the growth of RPAM and universal ZTNA solutions. There are now higher expectations for solutions that provide vendor privileged access management—PAM for remote third-parties that is as secure as the means of controlling access locally.

Pre-Built Vendor Remote Access Solutions: Why?

Managing firewall rules can quickly spiral into unmanageable territory, leaving gaps in controls that can become a security risk. Solutions like RPAM and ZTNA are built for easy scalability. Further, a good solution will have built-in capabilities for MFA, just-in-time access control, and easy centralized management that might not be possible or feasible to build in-house. 

A good vendor solution will also have important monitoring features like session recording that make it easy to see exactly what a vendor has done in case of an accidental (or malicious) disruption of your systems. 

Often, the same solution your employees use for remote access will be a tempting choice for enabling vendor remote access. This can work, but there are some specific features that are extra important for a solution you’re using it to grant outsiders access:

  • Automatic timed account deactivation: When you’re granting temporary access to someone outside the organization, you don’t want to have to remember to manually deactivate the account when they’re done.
  • Automatic password rotation: Many data breaches start with the attacker logging in using a legitimate username and password that was leaked somehow. Password rotation prevents your third party vendors from leaking usernames and passwords that come back to haunt you.
  • Rapid account provisioning and deprovisioning: When you bring in a vendor to handle a problem, you probably want it to go as quickly as possible. If you have to involve multiple teams to update firewall rules and ACLs just to let a vendor in, you lose agility. The ability to quickly create and destroy accounts with zero trust policies attached is a must.

Specific Consideration for OT and Industrial Infrastructure

OT systems use protocols designed originally for closed and separated environments which aren’t secure enough for more interconnected or internet-connected networks. Many industrial protocols (like Modbus and DNP3) weren’t designed for security, leaving them at risk for exploitation by malicious users connected through a VPN. The same dangers exist due to weaknesses in remote protocols (like RDP or SMB) frequently encapsulated in VPN tunnels.

Ransomware attacks such as BlackCat, recently used against several Western European oil terminals, exploit these weak protocols as initial attack vectors into high-value, target-rich OT environments. Firewalls and other network boundaries may help mitigate this exposure. However, these cyber threats can spread unchecked once on the inside through a VPN connection. Industrial organizations must adhere to even higher security standards for their OT remote access

Secure Vendor Remote Access with Xage

Xage provides secure remote access while controlling every interaction and session to prevent credential abuse and insider threats, with MFA, least privilege, and more built in. 

Learn about Xage Zero Trust Access.