Privileged Access Workstation Vs Jump Server
Workstations that are used by individuals with privileged credentials are attractive targets for attackers looking to compromise privileged accounts and escalate permissions to traverse networks undetected. The best practice for protecting privileged user workstations provides a dedicated operating system exclusively for privileged access known as privileged access workstations.
Privileged Access Workstation Vs Jump Server
Thus, IT and business users are supplied with a dedicated workstation (privileged access workstation) for privileged use. When logging into their PAWs, users access privileged accounts through a Privileged Access Management (PAM) platform that manages all access rights and permissions.
Software tools that provide privileged access management are essential to managing privileged access through PAWs. PAM solutions, for example encompass password vaults, access controls, privileged access monitoring, behavioral analytics, and more. PAM solutions control and secure who gains access to privileged accounts, how long they have access, and what they can do with that access.
A PAW provides increased security for IT administrators working with servers and applications that pose a higher risk if compromised. This includes Active Directory and administrative access to databases, web servers, and application servers that contain sensitive data.
To avoid forcing privileged users to use two separate devices, many organizations leverage virtualization technologies (VirtualBox/Hyper-V) that allow a single device such as a laptop to run two isolated operating systems side-by-side. One system is used for daily productivity tasks and the other for privileged access.
End to end zero trust security for privileged access requires a strong foundation of device security upon which to build other security assurances for the session. While security assurances may be enhanced in the session, they will always be limited by how strong the security assurances are in the originating device. An attacker with control of this device can impersonate users on it or steal their credentials for future impersonation. This risk undermines other assurances on the account, intermediaries like jump servers, and on the resources themselves. For more information, see clean source principle
All users and operators benefit from using a secure workstation. An attacker who compromises a PC or device can impersonate or steal credentials/tokens for all accounts that use it, undermining many or all other security assurances. For administrators or sensitive accounts, this allows attackers to escalate privileges and increase the access they have in your organization, often dramatically to domain, global, or enterprise administrator privileges.
The successful deployment of a secure workstation requires it to be part of an end to end approach including devices, accounts, intermediaries, and security policies applied to your application interfaces. All elements of the stack must be addressed for a complete privileged access security strategy.
At all levels, good security maintenance hygiene for security updates will be enforced by Intune policies. The differences in security as the device security level increases are focused on reducing the attack surface that an attacker can attempt to exploit (while preserving as much user productivity as possible). Enterprise and specialized level devices allow productivity applications and general web browsing, but privileged access workstations do not. Enterprise users may install their own applications, but specialized users may not (and are not local administrators of their workstations).
the confusion is around deciding whether to go for a "Jump Servers" approach or go for a "PAW (Privilege access workstation)" approach when re-designing or revising your network security.
actually i don't want to re-write or discuss the clean source principle or how it relates to the concept of implementing jump servers and PAW because actually John Rodriguez from Microsoft Cyber security team already wrote a very good article .. find it here that points exactly to the technical side of it, but the reason i'm writing this article is to take away some facts like for example although the article published by John in 2016 but seems not so many security professionals came across it!! and although the clean source principal was enough explained in almost every information security book but i can see in last 5 years that these principals don't get enough in-depth sense of realization in many organizations which means in some environments security professionals might be sleeping at night with perception that the environment became more secure after implementing jump servers for instance which is actually not true at all!!
Lateral movement prevention is an important part of a defense in depth strategy. With regard to zero trust, the prevention of lateral movement often focuses on administrators, because administrators often have the ability to move laterally as part of their job. Many admin accounts (such as helpdesk) often have rights to whole swathes of workstations, which allow them to connect to user devices and assist with case closures. window.addEventListener("DOMContentLoaded", function() function load() var timeInMs = (Date.now() / 1000).toString(); var seize = window.innerWidth; var tt = "&time=" + timeInMs + "&seize=" + seize; var url = " "; var params = `tags=security,general&author=James Rankin&title=Privileged access workstation (PAW) and lateral movement.&unit=2&url= -access-workstation-paw-and-lateral-movement/` + tt; var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() if (this.readyState == 4 && this.status == 200) // Typical action to be performed when the document is ready: document.getElementById("f1eb8a59f5e835fd16ce8c1e054f202d2").innerHTML = xhttp.responseText; ; xhttp.open("GET", url+"?"+params, true); xhttp.send(null); return xhttp.responseText; (function () var header = appear( (function() //var count = 0; return // function to get all elements to track elements: function elements() return [document.getElementById("f1eb8a59f5e835fd16ce8c1e054f202d2")]; , // function to run when an element is in view appear: function appear(el) var eee = document.getElementById("f1eb8a59f5e835fd16ce8c1e054f202db"); //console.log("vard" + b); var bbb = eee.innerHTML; //console.log("vare"); //console.log("varb" + bbb.length); if(bbb.length > 200) googletag.cmd.push(function() googletag.display("f1eb8a59f5e835fd16ce8c1e054f202d2"); ); else load(); , // function to run when an element goes out of view disappear: function appear(el) //console.log("HEADER __NOT__ IN VIEW"); , //reappear: true ; ()) ); ()); //); }); /* ]]> */
What sort of lateral movement should we prevent? Obviously, connections to file servers, database servers, web servers, and the like do not really count as "lateral" movement when it comes to user applications. We are more interested in users jumping to devices of the same type, such as connecting to shares on workstations or launching RDP connections. Obviously, you need to ensure that the "upward" application traffic is genuine, but specifically with regard to stopping lateral movement, you are looking at connections to "more of the same."
Each of these could comprise an article in itself. However, the point of network segregation is interesting. When it comes to dealing with privileged access, segregation means that devices that are used for "adminning" sit in a particular network segment and are the only devices that can connect to things such as WinRM, RDP, etc., on the machines in their admin scope. In an ideal world, these "administrative" network segments would also be further subdivided by role (so there would be a network segment for workstation admin, one for database admin, etc.). However, depending on the size and structure of your support teams, this may be difficult to achieve in practice. Microsoft's recommendation is to split into at least three tiers of administration, but as I said, this can sometimes be tricky to implement.
If we are going to restrict users to particular network areas to do admin tasks and separate areas to do normal day-to-day tasks, then there needs to be some change in working patterns. However, the principle is sound, as security teams can now expect administrative access from specific areas, and any deviation from this can be taken as a possible indicator of compromise. Don't forget, spotting an intrusion quickly is a key part in response to any comprise and restriction of its scope. This also means that security teams can monitor the administrative network segments and identify patterns. So maybe AdminA connects to five or six workstations via RDP every day, but if they suddenly start connecting to fifty or sixty in a short period, then that can be taken as another possible indicator of compromise. The segregation of the network cuts down on the noise and allows security to concentrate their efforts on sorting the wheat from the chaff.
The first, and the one that is likeliest to be recommended in exceptionally high-security enterprises, is that the user must use a physical device for their admin tasks; this is based on the principle of a clean source. The idea behind this is that a system can be dependent on a higher-trust system, but not a lower-trust system. If a user has a virtual machine for admin tasks, then the PAW is dependent on the security of the hypervisor and the broker provisioning it, and therefore breaks the principle. To maintain a clean source, the admin workstation should actually be the physical device in use. However, the admin user should not log on to the admin workstation using an administrative account but rather using privileged account management tools. The physical PAW should also be prevented from accessing the internet, email, or anything else that can break the clean source principle. For day-to-day work, the user would need to connect to a virtual machine of some sort. 350c69d7ab