How PAW Can Bring Much-needed Safety To The Cloud


Having made the move to the cloud, regional enterprises are left with a challenge — how do they secure a complex environment of nebulous networks, risky endpoints, and slapped-together mixes of legacy and cloud-native applications?

Many security teams now use a dedicated, hardened, strictly monitored privileged-access workstation (PAW), which is used to perform administrative tasks only, thereby mitigating the risks associated with privileged accounts hopping on and off an everyday workstation. Activities such as checking email, for example, would be prohibited as a matter of policy, limiting the opportunity for success of phishing attacks.

The PAW — which can be a physical or virtual machine — is used exclusively for privileged access to the cloud, and the sensitive secrets it holds are far less likely to fall into the wrong hands because users that have access to it while having privileged credentials are only using the machine for one purpose – cloud administration. Even then, users are restricted to a narrow scope of tasks. And if the slim chance of credentials compromise comes to pass, any attempt to use those credentials to access the environment from another workstation (even another PAW) will be an obvious red flag.

PAWs for thought

Not all PAWs are created equal. Some consideration must be given to design and configuration. The PAW model is becoming best practice because it offers many layers of protection. Well-implemented PAWs do not give their users direct access to the cloud. Instead, privileged access management (PAM) platforms broker sessions, monitor activity and inject managed credentials that are invisible to the user, who thinks they have logged into the cloud in a single step.

At this point, we should distinguish between PAWs and jump servers, which grant access to corporate networks from external ones. They do not implement security controls themselves. Rather they serve as conduits for the monitoring, logging, and controlling of digital assets. Jump servers can detect compromise of a source asset but can take little automatic action if privileges or exploits are leveraged as a part of an attack from that source. Risk mitigation through jump servers is therefore restricted.

Unlike jump servers, Bastion hosts are network-native assets named for their military-style fortification against a wide range of physical and cyber-attacks. Bastions tend to host a single application or process to minimise the attack surface. Some PAWs could be considered bastion hosts if they allow users to interact with a limited roster of applications. But in general, bastion hosts include other services such as firewalls and load balancers that are not used for privileged administration within a cloud environment. PAWs differ from most bastion hosts in that they are designed for more than the provision of a single function.

PAWs: dos and don’ts

PAWs are not jump servers. Nor are they bastion hosts. The most secure ones share a range of attributes. First, they must be hardened, dedicated assets, whether they are physical or virtual machines. The PAW will implement the principle of least privilege for every operation and will be actively monitored to the granular level of keystrokes, application launches and command-line executions. It will implement a whitelisting and/or blacklisting system that will permit security teams to block or allow any application as they see fit. And the underlying hardware will support TPM (Trusted Platform Module), preferably at least 2.0, to support the latest biometrics and encryption technologies. Multifactor authentication will be standard on PAWs, especially if they control access to sensitive resources. Step-up authentication or change control should be in place for the most important operations.

A robust PAW will be thoroughly screened for vulnerabilities and prioritised for patching. Automating this process is preferred to avoid any oversight that could lead to the incursion. The PAW will live on a dedicated, trusted network that is isolated from all others that may be home to insecure devices. It will be connected via wire only; no wireless communications will be permitted for the PAW. And finally, the PAW will be physically lashed to its desk or housing with anti-tamper cables to prevent theft, especially if it is a laptop used in a crowded area.

PAWs also come with a list of best-practice “don’ts”. They should never be allowed to connect to the public Internet, regardless of how much the browser is trusted. And email and messaging applications should be prohibited. Apart from unsecured Wi-Fi or cellular networks, the PAW should never be connected to any unauthorised USB peripheral and should be blocked from remote access or use with applications or services that could undermine its security.

High battlements

The PAW model can be implemented through virtualisation to avoid using multiple physical computers. VMware, Hyper-V, and others can allow a single asset to execute a PAW side by side with the base operating system, with the latter used for daily tasks and the PAW remaining battle-hardened and isolated in all the ways best practice demands — albeit implemented on a hardened OS to provide better segmentation. If practical, the PAW should be virtualised and isolated from the OS to prevent possible gaps in security such as clipboard sharing and file transfers.

While the past few years may have fomented fears to the contrary, our clouds can be secure. Privileged-access workstations form the foundation of that security, but not just any machine will do. However, the correctly configured PAW will be a stalwart defender against the growing threat landscape. Your battlements will stand high indeed.

If you liked reading this, you might like our other stories
Company Closeup: HPE’s AI & Analytics Play
Datatechvibe Explains: Zero-Trust Cloud Security