Security for Privileged Access

By Henry Harrison, Co-founder and Chief Scientist at Garrsion

If you work in finance, healthcare, the energy business – or in any other regulated sector – you might want to turn your attention to what is currently going on in the telecoms industry, where the UK government is currently putting in place detailed cybersecurity regulations.

For some time, regulators in the finance sector have been worried about cybersecurity, but for the most part the regulatory approach has been to ask financial firms themselves to propose suitable security measures to the regulator. In contrast, , a new approach is being taken in telecoms; the UK government has just put in place detailed technical regulations with which every player in the sector must comply.

Why should you care? Firstly, because in the long run it is likely that the approach will spread to other sectors. And secondly, because it provides insight into what the UK government (and in particular, the National Cyber Security Centre, who are advising on the proposed regulations) believe is really important when it comes to protecting critical services.

Some of the measures in the new regulations are of course specific to the telecoms sector itself. However, some have ubiquitous applicability; in particular, regulations relating to the security of privileged access.

It is well known that restricting access to privileged functions is of critical importance. It’s long been essential to make sure that only those few employees who have a need to carry out privileged tasks like systems administration have the permissions to do so. But what the new regulations are concerned about is not just that. They’re also worried about what happens if a remote attacker is able to use malware to take control over the endpoint device (e.g. laptop) of a legitimate systems administrator.

When a legitimate sysadmin types a command like “rm -rf” at their keyboard, their physical actions give rise to electronic signals which are communicated over a network to some critical system’s management interface. The security problem is that those physical interactions are not the only way to generate those electronic signals. With suitable software, the signals can be generated without a physical interaction. In the case of keyboard presses, for example, the technique is known as key stuffing. There are legitimate uses for such techniques, but the regulations’ concern is for their malicious use. An attractive approach for an attacker is to install covert malware onto a sysadmin’s endpoint that can generate electronic interaction signals (e.g. key stuffing). Once achieved, the attacker can do anything that the legitimate user of the endpoint can do.

If the legitimate user is a sysadmin or someone with privileged access to data and systems, that’s a potentially really dangerous situation. And it’s not something that can be fully mitigated with multi-factor authentication. Techniques like man-in-the-browser or session hijacking mean that the principle remains – anything the legitimate user can do, the attacker can do too.

As a result, the regulations require that users with privileged access use endpoints that are very carefully protected against malware – Privileged Access Workstations (PAWs). The really key point though is how they require those PAWs to be protected. It’s clear that NCSC doesn’t have a high level of confidence in endpoint security tools, because what the regulations require is that PAWs aren’t connected to anything that could potentially be dangerous. Above all, they mustn’t be connected to the Internet.

Unsurprisingly, the telecoms industry wasn’t very keen when this was proposed during the consultation period that the UK Government ran ahead of introducing the regulations. In fact, a consortium of telcos made representation about it to the government, proposing an alternative approach using “virtual privileged access workstations” that could be used from a regular endpoint device. The government responded strongly and clearly to this: “The solution proposed by respondents does not achieve [the required] security outcomes, primarily because it would not prevent PAWs from being compromised by attackers over the internet.”

A PAW then is an endpoint device – typically a laptop – that can be used for privileged access tasks, and privileged access tasks only. It can be remote, connecting over a VPN – but that VPN must not allow it to access anything except for the environment where it needs to carry out privileged access tasks. Above all, wherever the PAW is and however it’s connected, it must not be possible for the PAW to connect to potentially risky Internet-based resources. In today’s Internet, that’s almost everything except for highly trusted cloud services.

The obvious problem with this approach will be apparent to anyone who’s ever done any systems administration; the single most important systems administration tool is Google. Without access to Internet-based forums and knowledge-sharing sites, the job of the sysadmin is nigh-on impossible. So does the PAW model mean every privileged access user will have to have two physical endpoints – one that can access the Internet, and one PAW that can’t?

Actually, no. And the answer to how that can be avoided is published alongside the regulations in a Telecoms Code of Practice. The government observes that a PAW can actually access risky Internet-based resources, but only using a security model that the government calls “Browse Down”. That’s a model where endpoints can access risky content without actually connecting to it – by using their endpoint to view the screen output of another, sacrificial, machine which is the one which connects to the risky content and runs the risk of being compromised by it. At the core, it’s a model that has a lot in common with traditional Remote Desktop – but with a particular focus on security, where it’s necessary to assume that the remote machine may be compromised by an attacker. In fact, what it has most in common with is Remote Browser Isolation.

So is any Remote Browser Isolation solution adequate for the job? Undoubtedly some are effective while others are far less so. How can the difference be discerned? The answer is to look at existing deployments of PAWs. As shown by the representations that the telcos made, the PAW model is not one that yet has wide acceptance in the commercial world, so that means looking elsewhere – in particular, at deployments within the more sensitive ends of government. In those environments, the use of PAWs is widespread – for example, among users who have privileges to view and interact with classified systems and information.

That sounds like a difficult suggestion to put into practice – after all, aren’t those environments by their very definition secret? The good news is that while the information stored and processed in those environments is certainly secret, their technical design is much less so (although this can certainly vary between different countries). In the UK, the NCSC is increasingly public about the techniques used to protect these higher-sensitivity environments, and for the most part the technologies used are also available as mainstream commercial products. That certainly goes for the tools used to implement Browse Down, which increasingly are not only available to buy as mainstream commercial products, but can also be delivered as a cloud-based Remote Browser Isolation service.

As the response of the telcos has shown, the use of PAWs can be a bitter pill to swallow, but one which is considerably sweetened by the Browse Down model. PAWs are now a regulatory requirement for telecoms operators, and it’s probably time for your sector to start understanding what they will mean for you.