Deciphering NIST Guidelines to replace your legacy VPN and deliver secure remote access.
The world of Secure Remote Access has changed
It’s almost become a cliché to say that cloud computing is growing, and there are numerous stats available that confirm the rapid move to the cloud. 451 Research has its own data to support this, as shown below. For me, there are a few interesting takeaways from the slide below. The first is the variety of locations where we are putting our workloads – on-premises, on-premises private cloud, hosted private cloud, SaaS and public cloud (IaaS/PaaS like AWS or Azure or GCP).
The second thing I wanted to point out was how evenly distributed they are – except for third-party co-lo, each category is roughly within a range of 15-20%. Last, and perhaps most interesting is that by next year, and for the first time, the number one way to deploy workloads will be as SaaS applications. Conversely, traditional on-premises workloads will essentially be cut in half and will no longer be the dominant way to deploy applications, falling from 39% to just 16%.
Figure 1: Primary workload deployment venue Source: 451 Research’s Voice of the Enterprise: Digital Pulse, Workloads & Key Projects 2019
At the same time, the workforce is increasingly remote, and using multiple device types (desktop, laptop, mobile) and operating systems (macOS, Windows, Linux, Android, and iOS). Additional data from 451 Research shows that just over a quarter of workers access corporate resources and applications all or most of their time either from home or from another ‘non-office’ fixed location (Starbucks?). And almost two- thirds of employees work remotely during at least part of their week. Unfortunately, these trends are likely to accelerate due to the response to COVID-19, which will likely lead to a big increase in the use of things like VPN solutions and VDI to provide secure access to work environments, but I also think we may also see a bigger push towards using SaaS apps, and over time, more apps migrating to public clouds like AWS, Microsoft Azure or Google Cloud Platform (GCP). Moreover, there is increasing speculation that to some extent, this shift to remote work may be permanent – at least for some employees who may never go back to the office.
Figure 2: Remote Working is Commonplace for a Significant Portion of the Workforce © 2020, 451 Research, LLC – A division of S&P Global Market Intelligence Page 3 of 6
VPNs were not designed for the Modern Enterprise
However, your existing VPN infrastructure is not optimized for this new world. While legacy VPNs do a good job of providing remote connectivity to internal resources, they suffer from a number of drawbacks in terms of user experience, functionality, and performance. VPNs also present security challenges, in the sense that they provide broad access to an entire flat network, rather than to just the applications that users need to do their jobs (the principle of least privilege, which we’ll touch on below). This leaves open the door to harmful cyberattacks from hackers and threats like malware and ransomware.
Also, the combined cost of VPN hardware and client software can quickly become expensive. VPNs are also typically a challenge to deploy. Installing new hardware and rolling out VPN client software is also a challenge, particularly for unmanaged devices used by contractors, partners and consultants. This is even more true when firms go from having 20% of their employees working remotely to over 80%, or even 98% in some cases as we’ve recently heard making access management a nightmare for admins.
Zero Trust is the new sheriff in town
In this new world that we now live in, perimeter-based security models are becoming less and less relevant, particularly as both applications and users become more distributed. A new approach to security has been gaining a lot of attention in the past year or so, known as Zero Trust Network Access (ZTNA). We have discussed Zero Trust in depth in other blogs (for example, The Evolution of Zero Trust), but at a very high-level, Zero Trust security rests on a few core concepts:
- Provide, and continuously authorize, access to resources based more on ‘who’ you are than ‘where’ you are – in other words, access should be based on your identity – which in turn implies greater use of authentication technologies like MFA and Device Trust – not solely on what network subnet or VLAN you are on.
- Enforce the principle of least privilege – only grant users (or services) access to those things they specifically need to do their jobs, and nothing more.
NIST Guidelines for Zero Trust Access
Software Defined Perimeter (SDP) is a relatively new technology that fits within the broader Zero Trust framework that can be an alternative to traditional VPNs. There are a number of different architectural approaches to SDP and zero trust-based access, and a set of formal recommendations were laid out by NIST in the following document: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft2.pdf
To be honest, the NIST paper is a dense read that most people won’t have the time or inclination to plow through. However, in the rest of this blog we’ll attempt to highlight what we see as the three key recommendations of the paper, as well as provide our attempt to decipher what they really mean for an average enterprise. More importantly, focusing on these three themes will help firms prepare to start out on their own Zero Trust ‘journey’ towards replace their legacy VPN estate with a more modern approach to secure remote access.
NIST Requirement #1
“Remote enterprise assets should be able to access enterprise resources without needing to traverse enterprise network infrastructure first. For example, a remote user should not be required to use a link back to the enterprise network (i.e., virtual private network [VPN]) to access services utilized by the enterprise and hosted by a public cloud provider (e.g., email).”
Translation: One size fits all approaches don’t work. Select the appropriate Zero Trust enforcement mechanism based on where your sensitive corporate applications are deployed.
As our earlier VoTE data showed, modern apps can run anywhere: on-premises in a traditional data center, in a private cloud, in public cloud environments like AWS, Azure or Google Cloud Platform (GCP) or run as SaaS apps. However, each of the latter has its own unique security requirements, and as such, your access strategy and policies should be tailored to suit each application scenario. Simply put, apply the appropriate Zero Trust enforcement mechanism based on where your applications are running. And if that means a SaaS app, no need to back haul all of your user traffic to the enterprise mothership just to access applications and apply security policies.
NIST Requirement #2
“The infrastructure used to support the Zero Trust access decision process should be made scalable to account for changes in process load. The PE(s), PA(s), and PEPs used in a ZTA become the key components in any business process. Delay or inability to reach a PEP (or inability of the PEPs to reach the PA/PE) negatively impacts the ability to perform the workflow. An enterprise implementing a ZTA needs to provision the components for the expected workload or be able to rapidly scale the infrastructure to handle increased usage when needed.”
Translation: Scalability and performance are key. Use a future-proofed cloud-based architecture.
As we noted earlier, one of the downsides to traditional VPNs is scalability, particularly in light of massive new work-from-home demands. Further, scalability and agility are two of the primary benefits of moving to a more cloud-based architecture, particularly as new developments like Kubernetes, microservices, and serverless computing become more popular. However, the latter would be of little value without also creating an equally scalable cloud-based architecture for deploying Zero Trust principles, which in some cases can leverage existing cloud migration initiatives.
NIST Requirement #3
“Enterprise assets may not be able to reach certain PEPs due to observable factors. For example, there may be a policy stating that mobile assets may not be able to reach certain resources if the requesting asset is located outside of the enterprise’s home country. These factors could be based on location (geo-location or network location), device type, or other criteria.”
Translation: Implement a granular yet flexible policy framework for contextual access, integrated with your existing enterprise tools
As we noted earlier, security policies in a Zero Trust framework should be based more on user context and attributes rather than network location, in other words ‘who’ you are, rather than which network you’re on. Rather than the primary input that determines what resources you can access, location becomes just one of many different contextual (time of day, day of the week, user role, geo-velocity, etc.) and behavioral indicators (does Joe normally access that application? does Jane type that way?) that help form a more complete picture with which to make access decisions. It is unlikely that your Zero Trust solution can natively provide all the signals needed to make policy decisions – instead, integrate with the enterprise security tools that your organization has already invest in.
* * *
While the road to Zero Trust will be a journey that will involve many considerations, adhering to these three key items will go a long way towards establishing a solid Zero Trust foundation:
- One size fits all approaches don’t work. Select the appropriate Zero Trust enforcement mechanism based on where your sensitive corporate applications are deployed
- Scalability and performance are key. Use a future-proofed cloud-based architecture.
- Implement a granular yet flexible policy framework for contextual access, integrated with your existing enterprise tools
* * *
Anxious to learn more? Watch our webinar.
How to Achieve Zero Trust Security by Leveraging Your Existing Security Investments – Register here.
Garrett Bekker III
Principal Research Analyst, S&P Global Market Intelligence
@gabekker
