As multiple cities head into lockdown, IT teams face extraordinary pressure to urgently deliver remote working to more users in a broader number of roles.

Over the coming weeks, the contrast between well and poorly resourced IT teams will be stark. Many won’t have the wherewithal to navigate this crisis without introducing unacceptable risks. Those that can will leap ahead. The tools we have on-hand to provide remote access in 2020 are orders of magnitude better than even a year or two ago.

Web-based identity brokers, trivially-deployed MFA and identity-aware proxies have arrived to save us from the hell of “just install TeamViewer”. And while the least imaginative solution to the crisis is to ramp up VPN access, others will dare to use this crisis as an opportunity to move to a “zero trust” delivery model.

This week we’re asking: What can organisations do to quickly stand-up work from home options for a displaced workforce that might even leave us in a more secure place than we started?

Avoiding the worst

It’s safe to say that if a user wasn’t offered remote access to enterprise systems before COVID-19, it was probably for a fairly intractable reason. Many admins will now be looking for a ‘least worst’ option to make it happen fast. So let’s start there.

Availability and speed probably trump all other considerations at present. But security has to hold out on a few minimum requirements:

1. Use managed devices, wherever possible - Unfashionable though it might be to say, users need to be held to a minimum standard of security. For the majority of companies that haven’t arrived at a zero-trust nirvana, we only get the control and visibility necessary to secure remote connections when we can enforce policy on the device.
2. Avoid third-party remote support tools - Limit use of VNC, TeamViewer and other remote support tools. Users should only connect via remote sessions that are encrypted, and on apps that can be patched and monitored by the security team. If you aren’t using application whitelisting tools, a combination of Group Policy (restrict hashes of their EXE files) and firewall rules might be the best you can manage.
3. MFA, always - All user connections should require a second factor of authentication - irrespective of device or access mechanism. Hardware MFA is king, SMS the least desirable, and the many variations in between the most practical.
4. Scan and patch - All components of the remote access solution should be patched against known vulnerabilities - with close attention paid to VPN agents and concentrators.
5. Avoid RDP altogether - If you don’t absolutely need it, you should ideally have disabled RDP. But if you must…
   • Don’t expose RDP to the internet - User connections should only be made from managed devices over an SSL VPN.
   • Avoid direct RDP connections - RDP sessions should be forced through a centrally-managed RD Gateway deployed in a DMZ, preferably behind a web application firewall. If that sounds like a performance nightmare, it’s because it is. We’re going on the assumption that you’re desperate.
   • Enforce basic security config - Long and complex passwords, MFA and account lockouts for multiple incorrect passwords, in the very least.
   • Hunt - RDP is so commonly abused by attackers, you’re going to need to keep a close eye on it.

So what if the supply-chain of new devices breaks down, and BYOD becomes your only choice?

Connecting user-owned devices to virtual desktops in an organisation’s private cloud may be a reasonable compromise, especially for users requiring access to older or resource-intensive apps.

VDI isn’t the worst option - but you’re going to need a lot of spare compute, storage and network capacity. A sudden influx of remote users isn’t going to be cheap. If you’re going to go to that much effort and cost, you may as well be thinking longer-term.

Adjunct Professor at Stanford and fellow Risky.Biz contributor Alex Stamos suggests CIOs take the urgent use case to provide remote access - which has very good chances of being funded - and use it as a stepping stone to zero-trust.

Identity-Aware Proxies: your Coronavirus friend

It might not be as big a leap as you think.

Any organisation that has deployed Office 365, for example, has created a cloud-hosted identity store (in Azure AD). Microsoft’s Azure AD Application Proxy can use this identity store to provide the same remote (SSO) access into internally-hosted web apps as Microsoft’s cloud suite.

CSOs and CIOs aren’t limited to Microsoft technology here, either. Akamai, Cloudflare and others now offer the network-level plumbing required to provision internal services to remote workers via “identity-aware” proxy services. Users sign-in using SSO (via Azure AD, Okta, whatever), then get piped through Akamai or Cloudflare’s network to internal apps.

So if you’re really stuck - and feeling brave - the users previously bound to the workstation at HQ might make for a great pilot group. It’s relatively new tech and there will be teething issues, but it’s certainly worth a look.

How are you most likely to be attacked?

You can also build a strong case for taking a new approach to remote access when you look at the initial infection vector used in recent attacks.

Attacking vulnerable users

There’s already been a proliferation of COVID-themed credential phishing campaigns from both State-sponsored attackers and cybercrime gangs, to such a degree that US Attorney General William Barr has urged the Department of Justice to prioritise prosecution of COVID-themed scams.

We should also anticipate that attackers will double-down on tech support scams. Users will be asked to follow unfamiliar procedures over the coming weeks. Some will be unfamiliar with the devices they’ve been assigned. They’ll have no prior experience with connecting using the corporate VPN. They may never have raised requests for IT support when outside the network.

These attacks will have a higher impact than usual, as many users will be connecting to corporate apps from user-owned devices. These devices will be highly susceptible to malware infection, unmonitored, difficult to support and difficult to acquire and re-image after they get infected.

Malware distributors won’t need to innovate much to net a bigger and more profitable catch.

Trawling for exposed remote access

We can expect attackers to scan for internet-exposed RDP (remote desktop protocol - defaults to port 3389) and ports used for third-party remote support tools (VNC, TeamViewer etc) to find low-hanging fruit.

Ransomware actors in particular are fond of abusing exposed RDP connections as an initial infection vector for attacks - as evidenced by recent ‘big-game hunting’ ransomware attacks in France. We’re also seeing commodity malware distributors like the TrickBot gang target RDP.

To date, researchers we’ve spoken to that run RDP honeypots haven’t picked up on major changes in attacker behaviour. Scanners are gonna scan, epidemic or not, and there were enough boxes to own before the crisis.

But as Insomnia Security’s Adam Boileau noted in a Risky.Biz livecast this week, the impacts of the many poor decisions made this week are likely to be long-felt.

“Admins will install VNC on desktops, punch some holes in the firewall, and hand out a port number and a password. We will live with a very, very long tail of the mess we’ve made.”

Vulnerable gateways

Attackers will also be keeping an eye out for victims that haven’t patched VPN kit against known vulnerabilities.

In hindsight, it was probably good fortune that offensive security researchers got so intimate with corporate VPN apps during the course of 2019. A quick refresher:

• In April 2019, US Homeland Security warned of authentication bypass flaws in a long list of enterprise VPN apps. Using these flaws, attackers that compromised a victim’s endpoint could assume the user’s full VPN access and go for broke in the corporate network. Palo Alto and Pulse Secure were the only vendors to immediately respond with patches for their VPN desktop apps.
• Researchers dropped a new set of bugs found in Palo Alto Networks, Pulse Secure and Fortinet VPN solutions at Black Hat in August. Within days, attackers were scanning thousands of vulnerable Pulse Secure VPN endpoints and Fortigate SSL VPN web portals, collecting private keys and passwords for use in later attacks. From late 2019, the flaws were being actively exploited by APT crews and weeks later by ransomware gangs - including the crew that crippled Travelex.
• Already in 2020, we’ve seen attackers scanning for vulnerable Citrix gateways. It’s assumed that the ransomware actors that popped German auto parts manufacturer Gedia, France’s Bretagne Telecom, steel manufacturer EMRAZ and possibly the German City of Potsdam abused a set of critical vulnerabilities found in Citrix products in late 2019.

Where do you expect attackers to focus their attention? Hit me up on Twitter.