Closing the Jump Server Security Gap with PAWs

When I’m out and about discussing Privileged Access Workstations with customers, I hear one question more than any other:

Do we need to use PAWs if we use “jump servers”?

The answer is a resounding YES!  In this blog entry, I’ll explain why – the short version is that while jump servers can be valuable, they don’t actually increase your security as you might otherwise expect.  But the resulting security gap can be easily closed with, yes, a Privileged Access Workstation.

First, a definition – a jump server is, according to Wikipedia, “a (special-purpose) computer on a network typically used to manage devices in a separate security zone.”  If you’ve read our guidance on Privileged Access Workstations, you may have noticed that we devote a few paragraphs to the jump server question.  I’m going to expand on those paragraphs a bit here in order to really land the main point – that you need PAWs to make jump servers truly secure.

Let’s start with a question:  Why are jump servers vulnerable?  Simply put, if you can’t guarantee the security of the source, you can’t guarantee the security of any system to which you connect from that source.  It’s known as the clean source principle, and it’s at the very heart of many of Microsoft’s cybersecurity offerings (including, obviously, the Privileged Access Workstation).  If you, as an end user, connect to the Internet or open email on a workstation, you increase the risk of that system being compromised – and once compromised, an attacker can compromise any other activity on that system via credential theft tools, keystroke loggers, or screen recording software.  [It’s worth reinforcing this point – if the attacker compromises any administrative user on the workstation, s/he can easily install software that compromises any other user who logs onto that system.]  If the attacker is on my workstation, and I connect to the jump server using Remote Desktop, that attacker now has potential access to everything I can do on that jump server – and to the systems connected to the jump server.  This is true even if you configure the jump server to require multi-factor authentication – because MFA exposes reusable credentials on the source system, the attacker can compromise those and reuse them at will.

[caption id="attachment_215" align="alignnone" width="876"] Figure 1: An attacker who compromises an end user workstation can hijack the jump server thanks to credential theft.[/caption]

But all hope is not lost!  The jump server model doesn’t provide additional security, but a PAW does.  Imagine now that we connect to the jump server not from a general-purpose end user workstation, but from a PAW.  Now, when I log in using my administrative credentials, I have a high assurance that an attacker cannot access them – and when I connect to the jump server using Remote Desktop, the attacker can’t compromise my credentials there either (because the attacker doesn’t have access to credentials which allow him or her to access that system).  By isolating the credentials on a PAW, we render the attacker powerless to compromise them, and thus the connection to the jump server is protected.

[caption id="attachment_225" align="alignnone" width="880"] Figure 2: By connecting to an administrative jump server via a PAW, the administrator avoids exposing privileged credentials to the attacker.[/caption]

Does this mean that jump servers are redundant?  Not at all!  Although they don’t provide meaningful security assurances on their own, they extend and enhance the PAW model in two primary ways.  Here’s how:

• By deploying jump servers, you can install all required management software on it rather than the PAWs.  This helps minimize the PAW footprint (maintaining high security), and reduces the number of systems where you must maintain and update management software.  You’ll probably have fewer jump servers than PAWs, so jump servers can help reduce the operational cost of managing PAWs themselves.
• Jump servers should be relatively static objects from a network perspective, unlike PAWs (which are often mobile devices, like tablets or laptops, which connect to different IP addresses at different times).  If you know the IP addresses for your jump servers, you’ve just identified valid sources of administrative traffic.  You can then either block administrative traffic from unauthorized IP addresses, generate network alerts for it, or both.

Jump servers do provide value, but to really get the most out of them, you need to combine them with other security measures – namely, PAWs.  By securing all stages of the administrative path – from source to destination – you can ensure that your privileged credentials are never exposed to attackers.

Addendum:   One additional note about using Remote Desktop with jump servers – I’ve previously written about RDP RestrictedAdmin, and I want to reproduce my cautionary note about RDPRA here:

As an aside, RDPRA is a poor fit in general for “Jump Servers” scenarios where users connect to an RDP server and from there connect to other resources. This is because credentials are never provided directly to the target system (jump server) and any additional connection you try to make from that jump server requires you to enter new credentials.

To expand on this a bit – if everyone who connects to a jump server uses a PAW, we should have a high degree of confidence that the jump server itself is secure.  If that’s the case, then there’s no additional risk in providing reusable credentials directly to the jump server.  And if there were an attacker on the system and you used RDPRA, you’d need to provide them anyway to connect to other systems, which would expose them to an attacker on the jump server, thus eroding the value of RDPRA in the first place.  So, in the end, using RDPRA with a jump server adds complexity but doesn't add any additional security - a good reason to simply use traditional RDP when connecting to a jump server from a PAW.