At a time when remote access has become a necessary part of most organizations’ operations, it’s necessary to take a look at whether the access provided actually maintains organizational security, productivity, and accessibility.
Use of remote access (of every flavor and vendor) by organizations has become a staple due to the shift to a hybrid workforce. While there are plenty of simple remote access solutions available on the market today, many organizations are still relying on the built-in Windows Remote Desktop Protocol (RDP) to access desktops and servers.
A recent study by data visibility & threat protection vendor NetSkope shows that 8.3% of *all workloads* across AWS, Azure and Google Cloud have RDP exposed to the Internet. While that number sounds low, I’ll reiterate – that’s 8.3% of every single workload in all the major clouds!!! Now add to that all of the organizations that have RDP access exposed to facilitate remote workers’ access to their in-office desktop. According to cyber insurer Hiscox, 61% of their ransomware claims last year involved an attack that started with RDP being accessible externally.
In short, there’s way too much RDP in use, it’s creating a massive attack surface, and organizations need to be looking at alternatives. But the perspective shouldn’t be one-sided – meaning that RDP is simply a risk, period. Instead, let’s take a look at what RDP provides against remote access solutions (in general) to determine what kind of solution benefits the organization most from a few perspectives:
- Accessibility – the connection used should provide the remote user with the best possible experience accessing the remote service.
- Productivity – the connection should facilitate as close to an in-person experience.
- Security – The remote connectivity should align with organizational cybersecurity goals, policies, and standards and not increase the organization’s cyberattack threat surface.
Let’s break down RDP and remote access solutions through the lens of each of the mentioned perspectives, beginning with how users access a desktop remotely. As you read through this article, consider a few use cases when some sort of remote connection is used:
- Desktop Owner – When the user of an in-office computer needs to access it remotely; whether inside the corporate network or completely externally.
- IT Support – Users still have issues, even when working remotely. So, the remote connection may be needed for IT to work interactively with the user having the issue or behind the scenes.
- Connecting to a Windows “device” – Think healthcare workstation or Windows machine managing some piece of operational hardware when being physically at the device is either impossible or undesired.
Whether the user taking advantage of a remote desktop connection is an IT support technician or a regular non-IT user, the work of accessing the remote desktop should be as easy as possible and without technical complications. Let’s look at each solution and see how they work to meet this need.
Right off the bat, RDP is built-into Windows (although it needs to be enabled in Windows 11). This means no installation of software to make a connection work. RDP does require a client app and Microsoft has created apps for Windows, Mac OS, Android, iOS, and a web client, which requires the setup and configuration of Remote Desktop Services (RDS) on a Windows Server. Most client applications support creating connection definitions that include authentication settings, display, devices, audio, and folder redirection, making connecting easy. Lastly, RDP is only accessible directly internally, unless port forwarding is setup and exposed to the Internet for users to connect remotely.
Do keep in mind that most of this really just applies when we’re talking about a company-owned desktop to be remotely accessed. Should the scenario be more a support scenario of an employee’s personal Windows device, the access experience by an IT technician trying to help may be far more difficult.
The story with remote access is far simpler – mostly because all the efforts Microsoft has put into making RDP work well (including anything made possible by RDS) is something that is already built into remote access solutions. Generally speaking, remote access solutions use either a client app (with versions for one or more client devices) as well as via a browser session. Some RA solutions have taken web access a step further by offering tools that create a just-in-time type of connection often without requiring anything actually be installed on the remote desktop itself. This means that, regardless of whether the desktop to be remotely accessed is company- or employee-owned, there’s a way to easily provide remote access to it. Some also are intelligent enough to recognize that a remote connection is being made within the corporate network and that proxying the connection isn’t necessary, creating a direct connection between the user and their remote computer.
Additionally, most remote access solutions provide access over TCP port 80, so no special port-forwarding or firewall rules are needed to make the remote computer accessible.
Users of a remote desktop have varying needs. A basic knowledge worker just needs to access a consistent desktop, while someone with a more specific set of responsibilities may need access to a mix of local and remote peripherals, while IT users may be concerned with utilizing a connection that maintains both their productivity and the actual owner of the remote desktop. The remote connection used needs to meet the needs of every user that will take advantage of it to be considered truly productive.
Microsoft’s RDP has been around for years, providing a seamless desktop experience for remote users. It supports the ability to port over sound, disks, ports, and network printers over to the remote user. It also provides the ability to be remotely shadowed by support staff when using RDS.
I should note that the access to peripherals may be limited, depending on the RA solution, as the focus may be primarily on supporting an existing user remotely instead of trying to have a seamless remote experience. Some of the differentiating features for RA include recording the session, support for attended or unattended sessions (meaning the remote session is not interactive and seen by the logged-on user), chat functionality, and system management – all in addition to remote access to the desktop itself.
All this accessibility and productivity is great – as long as it all exists within the context of maintaining the organization’s security stance. There are a lot of aspects specifically about a remote connection that increase the risk of a successful attack, including the use of encryption, how authentication is handled, whether a brute force attack is possible, what kind of privileges are provided once connected, and how it fits into your larger security architecture (which is designed to provide greater security overall).
Microsoft has taken a lot of steps to make RDP access secure from a number of perspectives:
- Authentication – Right off the bat, the user needs to authenticate with Active Directory or Azure AD. Adding multi-factor authentication (MFA) is possible but requires a separate installation and configuration (and may even require a third-party MFA solution). RDP does also support the use of smart card authentication via Remote Desktop Services.
- Encrypted Channel – RDP supports a 56-bit or 128-bit encrypted channel.
- Granular Access – It is possible to use the “Deny log on through Remote Desktop Services” group policy as a way to limit who can access RDP sessions. But, again, this means installing and configuring another solution.
- Privileges – Your privileges are limited by the account you log on with. So, in the case of IT trying to provide support, they will need to use User Access Control with an account that has elevated privileges to do any administrative work.
There is one unresolved risk with RDP: it requires that a port be open (TCP port 3389 by default) which cybercriminals scan for to identify paths of entry into a network. It should also be noted that simply changing the port doesn’t make RDP more secure; cybercriminals are scanning every port and looking for an RDP response on the other end. So, no matter the port, they will find it, connect to it, and attempt to brute force a logon.
RA solutions have the upper hand here, often providing far more granularity around security options:
- Authentication – Most RA solutions have a number of authentication options including passwords, integration with a Single Sign-On solution, support for the use of RADIUS services, smart cards, certificate, and MFA.
- Encrypted Channel – Most provide better encryption; usually up to 256-bit.
- Granular Access – While RDP has limited capabilities here, RA solutions take the opportunity to provide far more granular access through assigning which users can access which systems via the solution, by creating role based access definitions, and by restricting abilities when in the session (e.g., us of file transfer, whether they can control the remote keyboard and mouse, etc.),
- Privileges – Some RA solutions can provide elevated credentials to be automatically provided during a session to allow support professionals to make administrative changes without having to give up the credential itself.
Is there a “Winner”?
Having remote access built-in with little-to-no configuration needed (as in the case of the basic RDP in Windows) is a great thing. It’s empowered businesses to continue to function without spending a dime. However, RDP isn’t without its limitations or issues. The question as to whether you should be considering a third-party RA solution really depends on whether you need the advanced capabilities, better security, and more granular control that RA solutions offer.