Introduction
Years after the term was coined by Stephen Paul Marsh in 1994 and popularized by John Kindervag more than a decade ago, Zero Trust has become the “new” security solution that addresses the confluence of today’s three critical factors and the emergence of what amounts to a cyber-war on businesses and governments.
Zero Trust switches the focus from outward-facing defense of a network perimeter to prevention of unauthorized exfiltration of data and other exploits. This short work looks at why it has become virtually impossible to create a defense at the perimeter of the “network” – because you can no longer find it in today’s Multi-Cloud, distributed workforce environment.
As might be expected, Zero Trust is a term that is subject to marketing hype. This blog provides clarification, balance and some guidance. Before looking at what Zero Trust is and what it isn’t, it’s important to understand the three factors that have made it so important today.
Three Critical Factors
As Cloud Security developed, “The (single) Cloud” became Multi-Cloud with complex supply chains and Internet connected IoT and open-source code.
2. “Working from home” was enabled when acoustic couplers were invented 5 decades ago and enhanced by Google’s BeyondCorp model more than a decade ago. However, Covid-19 transformed the world and the instant emergence of the “Distributed Workforce” has flipped the responsibilities to have organizations require protection from their own remote employees, contracted workers, supply chains and suppliers working in “unsupervised” locations.
3. Both of these factors shattered the perimeter of the network as if it were made of glass. The attack surface became everywhere. Then began the emergence of state-sponsored and organized crime developments of sophisticated ransomware and cyber attacks based on sophisticated, automated software platforms to exploit these vulnerabilities.
Zero Trust: What is it?
Zero Trust is a systematic strategy, a set of desirable service attributes, a set of principles that, when followed, result in defense against critical attacks. The most notable of the long list of attacks being: corruption of and unauthorized exfiltration of data (typical for ransomware attacks), attacks on system and network resources including denial of service, infiltration of multi-cloud, multi-organization applications and control of network devices especially in real-time industrial networks where attacks can wreak havoc. Special mention goes to Open Source code exploits such as Log4j and Solarflare. As Ken Thompson said in his 1984 paper “Trusting Trust” the only code you can trust is the code you wrote.
The implementation of these attributes and principles is dependent on where and what is being protected. However, the common principles are present when a request-response event triggers a Zero Trust action. Thus, the first guidance offered by this blog is to prioritize the evaluation and vulnerability of key organizational assets that require such protection.
Access to such assets is governed by who or what is requesting access (user, device or application software) and the target of the request (user, device or application software), with approval or denial based on the factors we describe later. This is more complex than the earlier simple, user/device attack on a targeted asset. Today, 70-80% of current interactions are between apps (a.k.a as East-West traffic) and IoT devices are a key element of the security framework. Works by NIST and Gartner are recommended reading*.
Zero Trust: What it is not.
Zero Trust is not a product, not an all-embracing hardware and software system, not a service or even an architecture to be implemented – NIST similarly describes it as a set of guiding principles and SASE refers to the user access network transport aspects it refers to as Zero Trust Network Access (ZTNA). Great caution is advised when claims are made about Zero Trust Systems or Services. Instead, it is better to say that a service or product complies with the principals or includes service attributes that result in successful implementation of the strategy.
At best, security approaches can only strengthen weak links so as to deflect attacks to more vulnerable targets – not unlike the thief looking for unlocked cars. Zero Trust is no exception, being no panacea for a holistic security policy driven from the top of the organization.
Zero Trust and Multi-Layer Security
Earlier we did not cover where – and even when – Zero Trust principals can be applied. We also stated that system-wide implementations from one vendor or integrator may be far-fetched at this point.
Let’s examine what, where and how Zero Trust can be applied.
The “what” is best answered by realizing that cybersecurity is a multi-layer, multi-dimensional issue.
From a network perspective, encryption of data over a trusted path removes the likelihood of a man-in-the-middle attack but does not prevent control/management plane disruptions, nor does it prevent access to devices or data from unauthorized users. Similarly, changes to code in a container that initiates cross-domain workflows must be protected. An overlay network such as SD-WAN that carries workflows across provider domains must also be protected. These are just 3 examples of the application of zero trust at different network layers.
Emerging Best Practices for Implementation
Rather than get distracted by the term “Zero Trust,” more important is the implementation of the principles. Granting of access to data (including code and servers or applications via APIs) is subject to control of a policy management process that interfaces with Identity Management systems that not only Authenticate identity but the level of access permissions, roles that may be adopted, frequency of access, etc. Policy Management will typically match requesting users, application or management software authorizations with the appropriate policies allowed (e.g., read, write, update) for the data concerned. This will govern the granting or blocking access to the requested resource and trigger Monitoring for anomalous use. Automation is an obvious requirement to create scalability especially for ongoing auditing of the implemented solution. This may well include offloading investigation and deep packet inspection to track potential attacks to avoid performance delays and automatic distribution of new attack types discovered in real time to create dynamic block lists.
The granting of authorization is typically distributed. Open Authorization models such as SAML and OAuth2 and of code to validate that the source is verified as genuine are becoming increasingly popular and multi-factor authentication has become a necessary evil. Access to the management of Zero Trust services and their code is especially important.
Where Zero Trust is enforced at what Zero Trust terms Policy Enforcement Points. Requests are intercepted, then agreed or denied by a collaborating Policy Manager.
For updating data or code in a secure container this function might be co-located in a cloud system, for access to the control plane of a virtual firewall service it might be at a layer 2 switch in front of a firewall or for an SD-WAN device it could be in a provider network. The key guidance here is to look for approaches that intercept requests, have the appropriate functions and do not permit unauthorized connections.
Performance Requirements
The best way to ensure performance is to quarantine discovered threats as quickly as possible so that future similar attacks can be blocked before they cause problems. Some processing and performance reduction could well be experienced but will hopefully be short-lived.
Implementation Guidance
Due to the fact that data and code exist and many layers within and between systems, Point Solutions are required to enable trust and protection. These range from distributed workflows and ZT enabled services to establishing trusted paths in a closed system or from a remote location. Cooperation between such point solutions can be used to coordinate between solutions. Every time a Zero Trust Point Solution protects key assets, risks are diminished. The following gives just a few instances of where and at what layer enforcement could take place in a security-enabled multi-Cloud ecosystem.
This is a fast-moving topic and emerging implementations will likely use their own terminology. As implementation becomes more widely adopted, we hope the recommendations made here have provided useful insights and make the choice of selecting a solution that adopts Zero Trust principles obvious versus one making claims that can’t possibly be achieved.
* NIST Zero Trust Architecture: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
Gartner’s Secure Access Service Edge encompasses Zero Trust Network Access as a key element: https://blogs.gartner.com/andrew-lerner/2019/12/23/say-hello-sase-secure-access-service-edge/
Mark Fishburn, MarketWord, Inc.