The slow demise of the VPN: 5 lessons from DoD's Zero Trust framework
From culture to SASE, DevSecOps to network segmentation
Once upon a time, a VPN was a neat way to securely tunnel into your company network remotely, use on-premises applications, access the digital files you kept there and generally act as if you were still at work, from a distant location. IT teams could also use VPNs to swoosh themselves (capes flying) out to a distant endpoint like a laptop to fix broken stuff, delete dangerous stuff, and intervene to stop bad stuff happening.
For all this ageing wizardry, VPNs have been a pain for some time. They imply that once you’re through the walls you’re trusted. That can make them rife for abuse. Stolen VPN credentials have been used to breach companies like Avast and Colonial Pipeline among many others. Critical software bugs in widely used enterprise VPNs and security software have also been widely exploited by hackers in recent years for their easy access.
Join peers connecting with The Stack on LinkedIn
Security professionals may recognise CVE-2018-13379 (Fortinet); CVE-2019-11510 (Pulse Secure); CVE-2021-20016 (SonicWall); CVE-2019-1579 (Palo Alto Networks), among many other examples…
That world is changing as more and more enterprise applications head to the cloud – and more people adopt a Zero Trust or indeed Secure Access Service Edge (SASE) approach. (More on that below). Yet most corporate security architectures including firewalls are still deployed on-premises as part of a castle-and-moat security model; all too often causing network latency as traffic is backhauled to a central location for inspection.
The US Department of Defense’s new Zero Trust Strategy and Reference Architecture is an interesting example of a shift away from this model being proposed at scale; not least given DoD’s eclectic array of both on-premises and cloud systems. The Stack dug into the 104-page document to pull out 5 key Zero Trust lessons.
Key Zero Trust Lessons from DoD's new Framework
1) The End of the VPN?
As per the above, adopting a Zero Trust (ZT) model should entail taking a hard look at how and why you are using your VPNs (are on-premise file shares holding you back?) As the DoD notes: “A ZT environment dispenses with the distinction between “internal” and “external” users. An internal user should have no implicit trust associated with it than an external user. All users are untrusted. One outcome that can follow is the removal of VPN. In a ZT environment, all users are effectively ‘external’ or untrusted and therefore must undergo the same rigorous authentication and authorization processes…VPNs pose a threat to enterprise security.
“They create a path in the network perimeter and provide access to network resources after authentication. The conventional approach cannot provide a method to intelligently confirm the identities of users and entities attempting to access the network or provide adaptive policy enforcement based on authentication.”
2) Is SASE the answer?
Gartner first coined the term SASE in 2019. In essence it involves converged network and security as a service capabilities. SASE security functionality is both “identity-centric and cloud-native, with security measures focusing on the identity of the user or device instead of on the data center” as Cisco puts it.
What does that mean in practice? The graphic below illustrates it tidily. Very simply however, that network and security convergence in a SASE environment allows a ZT environment to be built without also having to backhaul traffic to a central location for inspection (with all the attendant latency issues). As one COO told The Stack: “IT's need to manage you on-network is going. Previously, for example, you would have to be on-network for us to manage your device. The rollout many people are doing at the moment [including SASE adoption] moves that management to the cloud. So you can be on-network or off-network and IT can still patch and vuln-test your machine.” [Things like Microsoft’s cloud-based endpoint management tool Intune help].
They added: “That's the same for SaaS apps; more and more people are doing SSO through Okta or whatever so that need for on-premises is really going away. File servers tend to be the sticking point.
“If you haven't moved terabytes of files to the cloud, then you still have to get onto the networks.”
(That’s the reason for most that VPNs are still a thing…)
DoD may be some way from full SASE but network security is a priority in its Zero Trust architecture. It details plans to “segment (both logically and physically), isolate, and control the network/environment (on-premises and off-premises) with granular access and policy restrictions. As the perimeter becomes more granular through macro-segmentation, micro-segmentation provides greater protections and controls over DAAS. It is critical to, control privileged access, manage internal and external data flows, and prevent lateral movement…”
It also suggests that “all data and applications will have direct visibility removed from the public internet. Devices wanting to access resources would be required to pass a ZT enabled SDP [Software-defined perimeter] [with] agents installed on both the request and receiving end and a ZTA broker with policy enforcement points. An optional but highly recommended piece to include would be a gateway to broker these communications.”
3) Data governance
A big challenge for DoD’s Zero Trust vision is data governance. Getting that right means a lot of data tagging.
As it emphasises: “In the federal government system, specific access and rights of openness apply to much of the data. This potentially can conflict with the technologies and approaches to data access and security embedded in the core of ZT. These must be reconciled in the ZT architecture so that the data governance technical policies, data access roles, and proper retention policy are implemented [with] ZT access and security.
That means a host of data cataloguing. Often (as with the enterprise file server example above) this is one of the biggest challenges of organisations; knowing what data is where, who can access and who does access it.
As DoD notes: “Since access controls, implemented at a session level, show what data even can be seen; the functions of data discovery, and the principle of data openness, must be reconciled with the protections of ZT. This likely will be done via an organization’s Data Catalog. The data catalog, itself accessed via ZT controls, will contain descriptions and meta data about the data without itself holding that data… Once the initial data assessment policy is complete, ZT security rules will be implemented to protect the data and enact segregation of duties. Much of this will be implemented via data tagging. Specific ZT policies will govern how data is tagged and ensure the data is tagged. These tags will be used by multi-factor authorization, under ZT policy.
“Data tagging is used by ZT, and is a function of mature ZT, but will have business use beyond ZT…”
4) DevSecOps
There’s no point in having an all-singing “Zero Trust” policy with sophisticated analytics and MFA if your developers are pulling in compromised binaries and your software supply chain is fundamentally unsupervised.
The DoD has little of detail to say on ensuring a DevSecOps environment beyond some platitudes about CI/CD and using “static code analysis.. in the source code evaluation process to perform dynamic vetting.”
See also: US Space Systems Command CIO “Colonel K” on shipping good code, transforming culture
It does emphasise its criticality however.
Those concerned with some detail may find Microsoft’s recently open sourced S2C2F framework helpful here. It includes some highly practical guidance on enforcing an effective secure OSS supply chain strategy; something that necessitates standardising your open source software (OSS) consumption process across various developer teams, so all developers in your organisation consume OSS using governed workflows.”
5) Culture
Implementing a Zero Trust framework will not be a technical challenge only, but a cultural one. As DoD notes: “... it requires a change in mindset and culture, from DoD leadership down to mission operators.”
Things do not move fast in the machinery of government at this level and DoD’s objectives are necessarily not over a short period as a result. It plans to “conduct a comprehensive ZT outreach initiative to inform and share data from ZT efforts and to define standards, minimize duplications, emphasize successes, and to facilitate an open exchange of information sharing with DoD, federal, and academia partners by end of FY2023” and to “implement internal and external communication campaigns at all levels, including with the DIB and foreign allies as appropriate, to include Department-wide advocacy, awareness, and support for the implementation of the DoD ZT strategy goals and objectives” within the same period.
