One of the major themes in network and application access in the past few years has been the concept of “zero trust.” In this paper, we show how, at its core, zero trust can be characterized by a small set of simple beliefs that can be applied not only to access but also more broadly across the cybersecurity space.
This paper presents a framework to encompass the broad concepts around zero trust, relating them to the existing business backdrop that motivates today’s application security business leaders. Finally, this paper provides a characterization of the zero-trust belief system – the driver for the tools and security implementations that address the current and emerging threats, which will be the focus of a follow-on paper.
This paper’s goals are twofold: first, to convey the security mindset that application business leaders should embrace, and second, to introduce a framework for security practitioners that we will expand on in future white papers.
The term “zero trust” is associated with a number of different concepts at various layers of abstraction: sometimes as a specific solution architecture, sometimes as a prescription to apply specific technologies, and at other times when it might refer to a property of a product. We believe zero trust security is, at its core, a mindset – a belief system – from which techniques and tactics emerge and leverage specific technologies, which can then be applied to address a broad spectrum of security threats.
The belief system that underlies zero trust security (ZTS) can be viewed as the next step in a security mindset evolution that started with “defense in depth” years ago. Defense in depth is predicated on the belief that while any single defensive screen has some small, but real, likelihood of breach, the addition of increased layers of protection for key assets reduces that likelihood, slowing down the attackers while also forcing them to use more resources for a successful attack.
Zero trust is a maturing of this mindset in three dimensions:
This evolution has been, in part, the result of time and experience, but it is increasingly driven by the confluence of two other application security trends. Specifically, today’s application architectures open up a much larger potential space of application vulnerabilities – notably threats from “inside” the application infrastructure – which are open to exploitation by the increased sophistication of today’s adversaries. Fortunately, concurrent advances in security tools, especially when they are used in conjunction with modern data collection and analysis capabilities, have enabled practical implementation of key components of the defensive strategy.
The remainder of this introduction presents an overview of the framework for our approach to zero trust security as well as its scope. From there, the following sections expand on the problem statement and its relationship to other contemporary approaches to zero trust, leading to a discussion of the core beliefs – the “why” – that should guide the choice of solution technologies and their application. Future papers will dive into the “how” – the requirements placed upon specific technologies such as authentication, access control, and AI-assisted analytics as they relate to the zero-trust maturity model.
Simon Sinek’s “Start with Why” approach is an effective tool for communicating the ZTS framework, as shown in Figure 1 below. You can view this graphic from the outside-in, starting with the classes of threats that ZTS addresses, then drilling down into the security methods used, and finally distilling it all down to common principles. Or, you can view it from an inside-out perspective, starting with the core beliefs as the north star, from which the appropriate tools and techniques emerge, which then enable your ability to address a broad range of threats.
Later sections dive into each concentric layer of this diagram, but in brief:
Zero trust security extends holistically across the full application, infrastructure, and delivery stack, and should span the complete development pipeline. More specifically, this should include:
Traditionally, the focus of zero trust has been directed toward application development and delivery teams, often captured as the personas of Dev, DevOps, DevSecOps, and SRE. We point this out primarily to note the larger picture; that a comprehensive approach to zero trust should ideally include non-traditional personas and infrastructure as well as additional workflows, such as the supply chain procurement strategy.
One of the top priorities for CIO and CISO is to modernize information technology to help accelerate the business. They also play a key role in corporate risk governance. Their goal is to help the business delight customers with new digital experiences, increase operational efficiency via digital connectivity with third parties, and let employees be productive from anywhere, while minimizing business risk. This requires the CIO and CISO organizations to free their workforce to use the latest technologies, architectures, and best practices for agility while simultaneously tasking these same individuals with taking appropriate security measures and establishing controls over people’s behavior, the information they access, and the technology they use to prevent loss exposure.
Organizations must understand and control risks related to changes in market and macro-economic conditions, consumer behavior, supply chain, and security exposures. An accurate assessment of risk and the ability to take rapid mitigation action is a competitive advantage for businesses. In this paper we focus on the risk of security exposures, which among other things can cause loss of intellectual property, disruption of business processes, loss of personal identifiable information, and fines from regulators. Security risk can be computed by evaluating the following aspects of a situation under consideration:
The challenge at hand is to compute risk associated with every single transaction in near real time and take appropriate mitigation action to control the impact of potential compromise.
Business acceleration demands lead to new practices that exacerbate cybersecurity risk. We discuss this point in more detail below.
After a barrage of persistent cyberattacks against various US federal, state, and local government agencies, and several US corporations, President Joe Biden issued an executive order on improving the nation’s cybersecurity on May 12, 2021. One of the key elements of this order is for government agencies to use the principles of zero trust to prepare for cyberattacks. The Biden Administration followed this order with a memorandum from the office of management and budget (OMB) for the heads of executive departments and agencies on January 26, 2022. This memorandum from OMB “sets forth a Federal Zero Trust architecture (ZTA) strategy, requiring agencies to meet specific cybersecurity standards and objectives by the end of Fiscal Year (FY) 2024 in order to reinforce the Government’s defenses against increasingly sophisticated and persistent threat campaigns.”1 Both the executive order and the OMB memorandum refer to the zero trust architecture described in the National Institute for Standards and Technology (NIST) publication SP 800-207, which was published in August 2020, and require government agencies to follow it.
Thought leaders in government agencies and the private sector have published papers that help to explain the zero-trust architecture and offer advice on how best to adopt it. We summarize ideas contained in these papers below. We note that the critical essence of ideas and suggestions contained in these papers is to examine every transaction to assess Who is attempting What action on Whom, and to make a real-time decision to allow or disallow the transaction based on computation of the risk associated with it.
The NIST team enumerates the tenets of zero trust and defines an abstract zero trust architecture (ZTA) in their paper NIST SP 800-207.2 Further, they discuss variations of zero trust approaches and describe different ways to deploy the abstract architecture.
Key abstractions discussed in the paper are the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP) which work in conjunction with each other. The Policy Decision Point is composed of the Policy Engine (PE) and the Policy Administrator (PA). The Policy Engine uses a trust algorithm to make decisions on whether access to a resource should be granted to a subject. This decision is executed by the Policy Administrator, which communicates with the Policy Enforcement Point to allow or disallow a new session and to modify or terminate an existing session. In addition, the paper discusses variations of the trust algorithm, network components for a zero-trust environment, and various use cases or deployment scenarios. Finally, there is a consideration of ways in which the zero-trust architecture can be thwarted by attackers, such that implementors are mindful of the threats and take appropriate measures to protect their zero trust architecture components.
With the goal of assisting agencies in developing their zero trust plans, thought leaders at the Cybersecurity and Infrastructure Security Agency (CISA), published a zero trust maturity model.3 The work builds on the abstract zero trust architecture described in the NIST SP 800 -207 paper. Authors have identified five areas and recommend that organizations make consistent progress in following principles of zero trust in each area. The areas are (i) identity, (ii) device, (iii) network, (iv) application workload, and (v) data. They recommend use of visibility and analytics, and automation and orchestration in each of the five areas.
The document offers a high-level maturity model across all five foundational pillars of zero trust identified earlier, and then digs deeper into each area. Organizations can use the maturity model to understand their current state and set an iterative course toward the optimal state.
Following the discovery of the Solar Winds attacks, the National Security Agency (NSA) issued guidance advising cybersecurity teams to adopt a zero trust security model in their paper “Embracing a Zero Trust Security Model.”4 Experts from the joint Defense Information Systems Agency (DISA) and National Security Agency zero trust engineering team authored the Department of Defense (DOD) zero trust reference architecture.5 Authors express the need for adoption of zero trust with the following statement: “Vulnerabilities exposed by data breaches inside and outside DOD demonstrate the need for a new and more robust cybersecurity model that facilitates well informed risk-based decisions.”6
This reference architecture bases its recommendations on the abstractions defined in NIST SP 800-207 zero trust architecture document. The document presents a high-level operational model and describes its elements in detail. It also includes a high-level maturity model and the mapping of capabilities for applying principles of zero trust to various areas of interest. Collectively these documents help organizations assess their current state and devise a plan.
Having an attitude that “assumes breach” and following zero-trust principles can help organizations in their risk-management and governance practices. The zero-trust principles of “continuous monitoring” and “explicit verification” of actors involved in transactions allows organizations to build a dynamic risk score for all actors and their activities. This is in line with Gartner’s recommendation to use “continuous adaptive risk and trust assessment” (CARTA) methodology for enhancing existing security programs. Adopting the principle of only allowing least privilege access to resources reduces the risk of loss even in the wake of a breach. Information generated by continuous monitoring and explicit verification is also useful in generating compliance reports.
This section is intended to focus on the mindset – the belief system, the “Why” – that motivates the strategy and decisions around the tools and design that an enterprise should adopt for zero trust security. In fact, one can distill the impetus for all the methods and component technologies employed by today’s zero trust solutions to four simple key principles. This section opens with an enumeration of these principles, followed by a discussion of how they can be applied within the broader context of the application development lifecycle – that is, how to consider these principles up-front, in the design phase, as well as operationally, in the deployment/run-time of the application.
If zero trust solutions are understood as fundamentally building trust in system interactions – “Who is doing What to Whom?” – then the building of an interaction-appropriate level of trust can be broken down into four components.
As the name suggests, the zero-trust mindset is one of, “Don’t blindly trust, always verify.” Therefore, any actor in the system – the Who and Whom in system interactions – must be able to:
In addition, the principle of explicitly verify can be applied not only to identity, but also action – the What of the transaction. A common use-case is where the action is expressed as an API call, such as an API to perform a database query. In this example, the explicitly verify principle can be used not only to have confidence in the identity of the actor calling the API, but also to verify the correctness of the use of the API action, such as verifying that the parameters passed to the API conform to the appropriate constraints.
In a mature zero trust mindset, “proof” is almost never absolute. Identity credentials can be stolen and devices can be compromised; API parameter constraints are often incomplete. Therefore, the term “confidence” in the zero-trust context should be interpreted as more of an indication of how likely it is that the attested identity or transaction parameters are legitimate. Thus, the “confidence” level should be viewed as one key factor, but not the only one, in the decision to allow, block, or further inspect a transaction.
Once an acceptable level of “confidence” is established in the actors participating in a transaction, the zero-trust approach requires that the actor (typically, the requestor, the “Who”) be granted only the minimum set privileges required for it to be able to do what it is designed to accomplish in that system. This principle embodies what is also referred to as a “positive security model” – an approach where all actions are disallowed by default, with specific privileges being granted only as required for system operation. For example, a reservation system may allow anonymous users to browse flight schedules but – as per the application design requirements – an anonymous user may not be permitted to book a flight.
These privileges may apply to individual actors, or to classes of actors. Typically, application consumers are either human actors or proxies for humans, and are grouped in classes, such as “anonymous users,” “customers,” “partners,” or “employees.” The less trusted classes of actors typically require a lower confidence threshold to pass authentication, but they also have access to fewer or less-sensitive APIs. Actors internal to the application or its infrastructure, such as specific services or containers within an application, may often have more customized privileges, such as “only containers <X> and <Y> can access the database, only <X> can write to the object store, but <Y> and <Z> can read from it.”
An important consideration for the implementation of least privilege is to strive to apply it in a more tailored manner, with forethought.7 Specifically, rather than applying a generic set of privileges across all actors, or a class of actors, a mature zero trust implementation should have a more granular view of What action is being attempted. For example, at a very coarse grain, “filesystem access” may be granted privilege, but “filesystem read” is a tighter specification of the true privilege required, which yields high-quality implementation of the positive security model.
Finally, more sophisticated embodiments of least privilege can work in conjunction with mature implementations of “explicitly verify,” by viewing authorized privileges for an actor not as absolute, but instead as being predicated on the authentication-supplied confidence. Thus, privileges are granted only If the confidence in the attested identity (Who) meets a minimum threshold, with the thresholds being specific for the action that is being attempted. For example, some particularly impactful action (e.g., shutting down the system) may require 90% or higher confidence that the actor is an administrator. In this example, if the system’s confidence in the identity is only 80% when the shutdown is attempted, the system would require additional verification to boost the confidence score in the attested identity before allowing the action.
Explicit verification and least privilege are key concepts; however, the principle of continuously assess captures the fact that those principles must be continuously evaluated, in the sense that:
The final principle is rooted in the presumption of highly motivated adversaries against a backdrop of healthy paranoia. Specifically, the premise is “assume you have been breached,” where “breach” is defined as “a transaction that should have been denied (with perfect knowledge and execution) but was instead permitted.” The root cause of this escape may be imperfect knowledge (e.g., an incorrect high confidence score from authentication stemming from undetected fraudulent credentials), or may be implementation limitations (e.g., not having sufficiently fine-grain specificity of granted privileges, such as having “open network connection” as a privilege, but without the ability to differentiate based on geolocation of the network destination), or may be caused by an incomplete implementation of zero trust (e.g., not applying zero trust to vulnerable open-sourced components used internally).
Therefore, the zero-trust mindset must also address how to best manage/minimize the impact of such breaches.
The implementation of this principle varies more than the other principles, but generally manifests as:
If the approach chosen is to use policy-based adjustments, the adjustments may be applied by leveraging any of the available static policy tools. Examples of policy-based adjustments would be to restrict the transaction-granular access control privileges (i.e. no longer allow Who to do What to Whom) or to instead apply a stricter the “standard of proof” (i.e., require MFA or a higher confidence score) for an actor (or class of actors) to take a specific action.
If, instead, the approach of using an additional “backstop” layer is chosen, this strategy can also be implemented as either fine-grain or coarse-grain. The most fine-grained strategy would be to block exactly and only those transactions that rise above a specific risk-reward ratio, although that solution also has the possibility of adding unacceptable levels of latency to some allowed transactions if the implementation requires additional analysis. Coarser-grained strategies could be used instead, such as sandboxing future transactions from that actor or even entirely disallowing the actor from the system. In extreme cases, even coarser mitigation methods – such as shutting down file I/O – may be appropriate.
Of course, all else being equal, finer-grain backstop mitigation is generally preferable. However, tradeoffs often must be made based on the constraints of the solution technologies available, and a coarse-grain backstop is usually better than no backstop. For example, if the coarse-grain response to prevent suspected ransomware is to disable file I/O, the side effects of that response still may be preferable to the alternative – allowing the actor to continue to operate in the system unchecked – assuming the result of inaction would be a ransomware-encrypted filesystem.
The best starting point for a secure application development using zero trust is, unsurprisingly, at the beginning. The foundational principles that enable operationalizing zero trust principles should be baked into the design phase of application development processes. Therefore, any discussion of an operational zero trust solution integrated into the CI/CD pipeline must begin with an understanding of these foundational elements that should be first-class design considerations.
The core of these foundational elements should capture the desired/intended behavior of the interaction of system behaviors, coupled to sufficient visibility and control to detect deviations and act upon them. The intended interactions are used to define the desired set of actions (What) for each actor (Who) toward each target (Whom). That said, there may be some scenarios and environments where the intended interaction patterns are unknown. In such cases, an organization can leverage deeper visibility to “discover” the set of appropriate interactions,8 which it can then codify in policy.
For example, in today’s ZTNA solutions, which focus on identity-driven access control to an application’s external APIs, visibility and controls into the authentication APIs is required. Or, in the cloud workload protection platform (CWPP) context, detection of a compromised container workload requires visibility into the actions each container performs, and in real time, if real-time remediation is required.
The following is a list of the high-level “buckets” related to foundational considerations that should be part of the design process, with additional drilldowns to provide specific questions to think about for each of the key points:
Explicitly asking these questions will help you discover where gaps exist in the foundation to enable zero trust. Often, the mere act of asking, early in the design, will result in the gap being addressed with minimal additional design effort. And, where a gap may persist, simple awareness of the gap will help direct additional security focus or identify vulnerable threat surfaces.
Doing this sort of up-front secure development analysis is a crucial part of the zero-trust mindset. Despite this fact, however, much of the focus of zero trust today is around what happens after the initial design, and the majority of most enterprises’ focus centers on the post-design aspects of zero trust. However, being thoughtful, in the design phase, about the requirements for effective implementation of zero trust will prevent much larger incremental efforts needed to “patch the holes” after the application is deployed.
As the “assume breach” premise of the mindset embodies, a security practitioner must assume that some sufficiently motivated adversary will manage to execute a malicious transaction – an instance of Who does What to Whom that met the policy rules, but, in a perfect world, should not have been allowed. In such cases, the focus then shifts to having an effective “backstop” mechanism that can find those cases, usually based on observations of patterns of transactions and system side effects, as described in the earlier “assume breach” section.
However, just as with the notion of identity, knowledge of whether a specific transaction is malicious or not will never be perfect. Therefore, just as with identity, an ideal zero trust solution should report a “confidence” score in the legitimacy of the transaction. As an example, seeing a daemon read and write 10 times the normal file rate for 10 seconds might result in a confidence score (of maliciousness) of 70%, but seeing the rate increase 100 times, sustained over 1 minute, might raise the confidence to 95%. In this example, taking the remediative action of inhibiting future file writes will still have some chance (a 30% or 5% possibility) of being the incorrect response – a “false positive.” Therefore, the decision to remediate or not must consider the risk of false positives versus the potential impact of allowing the possibly malicious behavior.
The point of the example is to highlight that any decision to take a user-visible remediative action is really a business decision, one that considers all the risks, costs, and rewards around the suspicious activity. Introducing additional friction to the transaction increases the probability that the value will not be received, but not intervening/adding friction introduces the risk of compromise. Therefore, the decision to act (or not) in such cases is a function of three inputs:
So, while a zero-trust strategy must embrace the fact that breaches will occur, a thoughtful approach will adopt a risk-versus-reward approach on the remediation of transactions that are allowed but appear suspicious. That tradeoff will comprehend the risk level of different application transactions and the consequences of applying remediation, and applying the remediation only if the risk level exceeds the expected business reward.
7 The aforethought begins at the design phase, as described later.
8 Or, at least, the set of “thought to be appropriate” interactions that the system appears to require. There is always the risk that the set of interactions derived from observation may be incomplete, or may have some pre-existing risk. Therefore, aforethought in the design is always preferable.