Delinea: Limit privileged access for 3rd-party vendors without restricting their productivity

Imagine a critical system goes down, and you don’t have the internal staff or skills to fix it.

You call in a specialized vendor to troubleshoot, and they’re primed to access the system from their office. Before they can log in, however, they’ve got to jump through some security hoops: They need to be approved and added to your Active Directory; they need to set up your VPN; or perhaps they need to wait for your corporate laptop to be issued.

Each step in this process causes friction and extends your downtime.

Frustrated, a well-meaning employee shares privileged credentials with the vendor. Now, the vendor can do their work, but the security team has lost all visibility. There’s no way to monitor individual privileged behavior, and there’s no audit log for compliance. Worse, when the work is complete, the vendor still has access to the privileged credentials they were granted. They could use them in the future or store them in a place that’s easy for a cybercriminal to find. It doesn’t have to be this way.

Vendors (including contractors, consultants, partners, and other third parties) need privileged remote access to your corporate resources for all kinds of reasons—for ongoing development, IT augmentation, or immediate assistance. Business can’t wait while you sort out their access with complex policies and technical requirements.

However, you can’t maintain a strong security posture if vendor access is too broad or oversight is lax. How do you protect your critical resources without causing friction or slowing down work?

In this blog post, you'll learn how privileged remote access enables you to provide just-in-time, just-enough access to third parties who work remotely and oversee their behavior just as you would for an internal, on-site employee.

Why is vendor access usually such a pain?

You’re right to be concerned about vendor security. The way many vendors operate creates significant challenges for securing privileged access.

• Third-party vendors have more flexibility than many employees regarding how and where they work. Most vendors don’t work at one of your corporate offices, safely inside your firewall. Instead, they could be working remotely from their company office, a home office, a coffee shop, or an airport on a public Wi-Fi network.
  
  
• Some vendor organizations often change staff or perform work in shifts, meaning you typically don’t know exactly who will be accessing your systems. Because of this model, vendors may gravitate towards sharing privileged credentials and passwords among a group of users.
  
  
• Vendors typically utilize their personal laptops and mobile devices, which are not managed by your organization. Although contracts with third parties usually mandate adherence to security policies—including password protection, up-to-date software, and the implementation of anti-virus and backup systems—your IT team lacks direct control to verify compliance with these policies.
  
  
• Vendors often use their own email addresses. These email addresses aren’t in your corporate identity management systems, such as Active Directory, so you can’t easily add them to Groups or use other AD-dependent processes for Privileged Access Management (PAM).
  
  
• A non-IT security business function may engage a vendor, overseeing their onboarding and offboarding processes. However, they might not adhere to established security policies during these procedures.
  
  
• The end date for a vendor engagement isn’t always clear-cut. Vendors may retain standing privileged access if there’s an expectation of a future engagement. Once off your radar, privileged accounts may be orphaned and the vendor’s access unmanaged.

What policies should you establish for vendor privileged access?

It’s important to address use cases for vendor access in a documented Privileged Access Management policy that aligns with the regulatory requirements or cyber insurance requirements you are required to follow. Make sure any employee who hires vendors is familiar with the policy.

Also, make a version of the policy available to vendors so they know their rights and responsibilities and any consequences if they are out of compliance at any time.

As you develop policies for vendor privileged access, keep the following principles top of mind:

1. Risk-based decisions

Not all vendor relationships or access scenarios are the same. Just like how the Privileged Access Management (PAM) policies you define for your internal employees account for context, develop your vendor policies based on your risk threshold.

Consider different factors that impact vendor risk:

• How critical are systems the vendor will need to access?
• Will the vendor work on just one system, or across multiple systems?
• How confidential or protected is the data they will need to access?
• Will the vendor be working on site, within your firewall, or remotely?
• Will they be working side-by-side with your team and have ongoing oversight, or will they be executing work on their own?
• Is the vendor engagement short-term or long-term?
• Is this a new vendor relationship, or a trusted partner?
• Will the vendor be taking on responsibilities that you already have standard roles and permissions defined for, or is their work custom or dynamic?

2. Least privilege best practices

Always avoid granting excessive privileges to your vendors. Instead, provide vendors with the lowest level of access possible that will still allow them to do their job.

Consider specifying:

• The specific systems (servers, databases, applications, etc.) vendors may access.
• The specific files and data they can access within those systems.
• Times when they are permitted to access privileged resources.
• Processes for granting temporary privilege elevation when needed.
• Expiration dates for any privileged accounts or systems they have access to. Ideally, you can set up an expiration date in advance so that vendor access automatically expires without human intervention.

3. Granular oversight of your vendors

You’ll want to make sure any access security controls you define are working as expected to contain vendors’ privileged behavior, whenever they check a secret out of your PAM vault, initiate a remote session, elevate their privileges, etc.

As part of your privileged remote access strategy, you should establish:

• Multi-factor authentication at initial access and privilege elevation for layers of identity assurance. You may require your vendors to use company-approved authentication apps, Yubikeys, etc.
• Approval workflows: You may want to require a senior-level employee to approve granting vendors initial access or elevating their privileges, as well as activities like renewing or disabling access. Ideally, you’ll want to automate these approval workflows and standardize the information shared and collected, so they operate smoothly.
• Session monitoring and recording: of all vendor behavior inside of your systems.
• Alerting: Should a vendor behave in a way that is unexpected, you may want your SOC or incident response team to receive alerts so you can investigate.
• Auditing and reporting: You’ll want to automatically track vendor privileged behavior in a way that can easily be retrieved, without the need to comb through logs. Once a vendor engagement is over, you may even want to do a post-mortem check, just to be sure no unexpected access occurred and all privileged accounts have been decommissioned and access disabled.
• Discovery: To ensure you don’t have any rogue or forgotten vendor privileges, it’s good practice to periodically—even continuously—check for unused or unknown privileged accounts. If you find them, check that they’re still needed and, if so, make sure your security team centrally manages them.

Benefits of a centralized Remote Access Service for vendors and third parties

You can manage your policies for vendor privileged remote access through the same, centralized PAM solution you use for privileged users within your organization. That way, you have one place to go to manage all PAM policies consistently, with a familiar user experience and unified monitoring and reporting tools.

Part of the Delinea Platform, Remote Access Service (RAS) provides privileged remote access for vendors. It enables streamlined management and oversight of privileged vendor activities within your IT environment.

Privileged remote access grants secure, temporary access for remote workers and vendors.

Privileged remote access allows authorized remote workers and vendors to securely connect to and manage critical IT systems and data remotely. It implements controls like Multi-factor authentication (MFA) enforcement and least privilege best practices to reduce risk. Properly implemented privileged remote access balances strong security and privilege controls with flexible remote management across remote workforces and third-party vendors.

Unlike RAS, commonly used remote access solutions invite cyber threats through the risk of overexposure and weak controls.

VPNs - With their expansive network access and complicated IT management requirements, VPNs can inadvertently expose systems to malware, challenging the principles of Zero Trust and least privilege without time-bound access controls and opening risk to threats like zero-day exploits.

Unrestricted Secure Shell (SSH) and Remote Desktop Protocol (RDP) tools like PuTTY, and OpenSSH introduce significant security risks relating to network infiltration, lateral movement, user impersonation, and session hijacking.

Virtual desktops and Cloud Access Security Brokers (CASB) face threats from service attacks and encrypted traffic that can mask malware and data breaches, necessitating strong cryptography and vigilant network defense to prevent unauthorized access and persistent threats.

Here’s how RAS works:

• VPN-less Secure Access: Vendors can initiate secure, browser-based SSH and RDP sessions without the need for a VPN, simplifying the connection process and enhancing security by avoiding direct access and open ports that could be exploited by cyber attackers.
  
  
• Centralized Access Governance: RAS provides a unified user interface for managing all aspects of the vendor access lifecycle, from access requests and approvals to revocations, through credential vaulting and role-based access controls (RBAC) for granular privileges.
  
  
• Just-in-Time Provisioning: Aligning with least privilege principles, vendors receive access only when required for their tasks, eliminating risks caused by persistent standing access. Vendor access is dynamically provisioned on-demand through an automated workflow.
  
  
• Comprehensive Audit Trails: All vendor sessions are comprehensively monitored and recorded, providing detailed audit logs for forensics, compliance verification, and accountability for all privileged actions.
  
  
• Agentless Architecture: RAS doesn’t require any additional software deployment on target servers, simplifying rollout while reducing the attack surface through an agentless architecture.
  
  
• Agentless Session Recording: RAS allows for agentless session recording, which is particularly beneficial for vendors and third parties who require remote access without the complexity of deploying agents.
  
  
• Automated Security Workflows: This automates repetitive security checks and tasks, reducing the administrative burden and improving the efficiency of managing vendor access.

Learn more about Delinea RAS here.

Privileged remote access management needn’t be overwhelming 

With Remote Access Service (RAS) on the Delinea Platform and a structured approach to managing vendor security, you can reduce the risk associated with granting third parties privileged access to critical systems, while effectively monitoring and auditing vendor behavior.