Zero Trust is a concept which has been around for at least the last decade. Whilst organisations were aware of it and implementing aspects of a Zero Trust architecture, it was not until 2020, for obvious reasons, that pretty much every organisation was forced into thinking about its adoption; responding to a distributed and fragmented workforce and a sharp rise in demand for Bring Your Own Device (BYOD). These challenges are addressed head on when implementing Zero Trust architecture.
According to the definition of Zero Trust, no network is trusted, whether this be your management virtual LAN on campus or the free Wi-Fi in Starbucks; all should be treated generally as potentially hostile environments.
One of the major IT implications of Covid is the need for remote access and, unfortunately, as we have seen over the last 18 months, remote access has been increasingly attacked since the pandemic began.
So how should organisations meet this demand for remote access?Before we delve any deeper into the topic, no further advice trumps the fact that TCP port 3389 (RDP) should never be externally presented outside of your network. RDP is not a protocol which should ever be exposed to the Internet. On that basis, let’s look at a few alternatives.
VPNs
Client VPNs. Yes, these are the classic robust solutions which organisations rely upon to allow a secure tunnel from a potentially managed endpoint to their internal networks. However the security of a VPN is not a given.
VPNs, like any other piece of software, have vulnerabilities. Recent examples which spring to mind are CVE-2020-12812, CVE-2019-5591 (both targeting Fortinet VPN solutions) and CVE-2020-2050 (Global Protect); with the prior being actively exploited in the wild.
If you are running unpatched VPNs, detection of these issues is trivial when using a passive scanning service such as Shodan, at which point vulnerable firewalls will stand out like a sore thumb.
Even if patched and up to date, the authentication piece on a VPN is also not a simple matter. The golden rule for remote access – well the second rule closely following “Do Not Expose RDP” – is to use multi-factor authentication; yes LDAP/AD integrated solutions can be implemented with lockout policy but that only minimises the risk of brute force. MFA obliterates the risk of traditional brute force. Machine Certificates are effective when paired with credentials. However, in line with Zero Trust, how can you determine if the endpoint machine has been compromised or whether a user has accidentally placed the cert in the computer store as opposed to their private user store – user identity cannot be verified via a certificate.
It is our recommendation that if you are utilising a VPN then looking at cert based auth in combination with SAML integration and pushing authentication to Azure is an effective way to secure authentication. As soon as Azure AD is in the authentication chain this opens the door for Conditional Access. A holistic Conditional Access policy can be effective in granting access. This can be as granular as looking for geo-location, specific user groups, MFA, Device Compliance (BitLocker, AV, Patched), corporate owned, and with the request originating from an approved client app. At this point the user, device, network and client technology are all challenged before access is granted, ticking most boxes in line with Zero Trust
If your VPN solution does not support SAML an alternative via the RADIUS route is a service called Microsoft NPS Server. This can be integrated with Azure MFA.
Remote Desktop Services
Remote Desktop Services is also another technology which has been attacked increasingly throughout the last year. RDS does not natively come with any Multi-Factor Authentication. Therefore, if your account lockout policy is not set aggressively enough, your configuration will allow for trivial brute force attacks. Aside from traditional brute force, compromised credentials can also be used without intervention
RDS can however be mitigated via Azure technology. This can be done via NPS/Azure MFA plugin, forcing all RDS users to require MFA. However, a more modern approach is to integrate RDS with Application Proxy. This solution allows for traditional Azure AD authentication to sit in front of RDS, thus allowing MFA & Conditional Access.
As this alternative is relatively recent, there are a few limitations to productivity; impacting services such as SSO (From Azure-AD to RDWEB) & RDP/clipboard functionality is limited. But on the flip side, security is dramatically increased when pushing a service through Application Proxy.
So, what is Application Proxy?
Azure Application Proxy is a well-established service available to any organisation with an E3/A3/AAD P1 license SKU. It works by placing an agent in front of a web application (it needs line of site via HTTP/HTTPS to the application).
Application Proxy does not require any ingress ports on the firewall as it operates entirely on an egress model, therefore allowing organisations to reduce the number of open ports and consequently their exposure to the Internet.
Once configured, simply point your DNS to an Azure generated CNAME and traffic will be proxied accordingly. Application Proxy can provide pass-through authentication (in cases where authentication is configured solely on the origin web application). However more often than not pre-authentication via Azure AD is desired.
Application Proxy again can integrate directly into Conditional Access, with applications appearing within the M365 App Panel. It also supports SSO with the backend web application. In most cases credentials can be passed to the application with the service supporting a variety of methods.
Virtual Desktop Infrastructure (VDI)/App Streaming
Azure Virtual Desktop (previously Windows Virtual Desktop) is designed to take the complexity out of VDI environments and, from a security perspective, there are a few advantages to running AVD. Without sounding like a broken record, it allows for full integration with Azure AD.
All Identity and Access Management is via Azure, therefore… Conditional Access and MFA.
With the service having lots of PaaS functionality, you can rest assured in handing security responsibility over to Microsoft in respect of the external facing elements of the service.
Where an Application Proxy cannot support anything other than web-based applications, AVD supports application streaming. Therefore, legacy thick clients can still be supplied to end users via a secure platform.
Recent updates to the service have resulted in new capability with AVD; it can soon be entirely Azure-AD joined, meaning no line of sight to a domain controller is required.
If correctly implemented with Azure Defender, AVD can benefit from Adaptive Application Control (essentially AppLocker in audit mode backed by powerful AI), Windows Defender for Endpoint (Defender ATP EDR), continuous vulnerability scanning and any NSGs (Azure’s stateful firewalls) can also be locked down via automation.
The above technology will make lateral movement post-compromise much more difficult than on a traditional Active Directory backed VDI, and with micro-segmentation in place on the network results in a robust VDI solution.
So back to Zero Trust..
Zero Trust in Microsoft speak can be split (at a very high level) into three key principles:
- Verify Explicitly
Validate: Identity, Location, Device Health, Service/Client Application Context, Data Classification, Anomalies - Least Privilege
Implement: Just-In-Time Access, Just-Enough Access, Risk-Based adaptive policy, Data Protection - Assume Breach
Implement: Micro-Segmentation, Encryption, Threat Detection
Whilst we’ve only touched upon how remote access can integrate with Zero Trust in this article, it is important to note that Zero Trust is relevant to ALL access. Most organisations have made efforts to secure their remote access solutions and are aiming to move towards Zero Trust. One idea is to use that same modern security for pandemic working and apply it to your internal networks and devices. This will aid in achieving compliance against Zero Trust architecture. It is also worth recognising the power of Conditional Access. The link below contains Microsoft’s reference architecture for Zero Trust; Conditional Access is central and arguably the key ingredient for any successful Zero Trust Implementation.
Many more examples are there, including Microsoft Cloud App Security for CASB and Data Security and Microsoft Defender for Endpoint for advanced device threat prevention.
I’ve only just scratched the surface with potential remote access and Zero Trust offerings in this blog. Admittedly my focus been on solutions that many organisations may already be capable of running because of their Microsoft 365 licensing (except for AVD which M365 users can potentially run a reduced cost).
And I believe I have demonstrated that whilst both Azure/M365 have some very powerful tooling, Zero Trust (in the Microsoft World) can be extended to any location, whether this is on premise or on a different cloud platform.
At Jisc, we also have expertise in securing remote access solutions powered by or running from within Amazon Web Services. If you have any questions or queries, please feel free to email cloud@jisc.ac.uk.