Zero Trust Threat Modeling

Zero trust is all the rage. Zero trust has undoubtedly gathered the attention of companies of all sizes and National Governments. CISA and NIST have written extensively, including NIST's 800-207 Zero Trust Architecture and CISA's Zero Trust Maturity Model.

While these are excellent resources that set the stage for all you think you need to know about Zero Trust, neither covers an approach for discovering the depth of security and privacy challenges that Zero Trust unleashes. The maturity model categorizes the things to be done without expressing the more significant security and privacy issues requiring consideration. Neither of those documents set out to answer the question posed. So, where do we explore the depth of Zero Trust Threats?

Nevertheless, zero trust has vast implications for application security and threat modeling. Zero trust threat modeling means the death of the trust boundary. Zero trust security models assume attackers are in the environment, and data sources and flows can no longer be hidden. This uncovers threats never dreamed of in classic threat modeling.

In this rant, we'll consider how to lay a foundation of zero trust against the lens of application security. We'll explore what Zero Trust architecture means as it reaches the top of the technology stack.

We'll apply the concept of zero trust to threat modeling by understanding what changes with threat modeling in a zero-trust world and by considering a threat model of the zero-trust architecture. We'll explore using new design principles in a zero-trust threat model and introduce a mnemonic to help apply the major threats impacting zero trust to threat modeling and expose a new taxonomy of threats specific to the zero-trust application.

How do you handle the complexity of ZT security and privacy design today? Our goal is two-fold: expose you to threat modeling and encourage secure by design thinking for ZT architectures.

Zero Trust Primer for AppSec – Seven Tenets

Many people will approach this work with an application security background and a limited knowledge of Zero Trust. Let's set the stage and connect the dots on what Zero Trust is and how it works at its core to prepare for the rest of the conversation.

This list contains the seven tenets of Zero Trust according to NIST SP 800-207. These tenets are things to accept as non-negotiable in a zero-trust world.

Comments in [] are from this author and not the tenet.

1. All data sources and computing services are considered resources. [Everything is a resource. Zero-trust architecture brings us back to when it was all about objects and subjects. The essence of zero trust is only allowing certain subjects to access particular objects.]

2. All communication is secured regardless of network location. [Assume TLS everywhere.]

3. Access to individual enterprise resources is granted on a per-session basis. [Session management is a crucial security control and dictates the security stance of the entire architecture.]

4. Access to resources is determined by dynamic policy. [Say goodbye to static policies not informed by deeper information than just the policy.]

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. [Monitoring and measuring integrity provide additional controls to detect compromise of a specific asset.]

6. All resource authentication and authorization are dynamic and strictly enforced before access. [AuthC and AuthZ are core to ZT, dynamic, and must be non-bypassable.]

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture. [Continuous improvement by data collection.]

The Definition of Zero Trust Threat Modeling

Zero Trust Threat modeling analyzes {Zero Trust} system representations to highlight concerns about security and privacy characteristics. This definition is extended from the definition of threat modeling found in the Threat Modeling Manifesto.

Zero trust threat modeling aims to highlight and fix security and privacy issues discovered, preferably before the zero trust system enters a production state. This is achieved by creating a representation or architecture diagram and performing the threat modeling process against that architecture.

Benefits of Threat Modeling Zero Trust, or Why Do We ZT Threat Model?

Applying threat modeling to Zero Trust has three primary benefits.

First, threat modeling helps to ensure that security is built into everything during development. Threat modeling helps pinpoint the connection points where protection must be added from the first rough design of the architecture until the system goes live in production.

Second, security and privacy problems are found and fixed early in the ZT system lifecycle: early problem detection and mitigation decrease rework across the project. Rework saps the lifeblood out of a new system, causing infrastructure folks and architects to revisit points within the system that needed to be appropriately secured from the start.

Third, threat modeling simplifies a complex system to enable analysis. Zero trust is complicated, and threat modeling simplifies a complex system, scoping it down into smaller parts that are easier to analyze.

Consider three scenarios to answer why to perform ZT threat modeling. First, not every architecture is as infallible as the reference architecture, nor is every design as clean—threat model to uncover the security and privacy challenges resulting from every modification against the reference architecture. Second, people make mistakes when designing things… even SECURITY people. GASP. Do security people make mistakes? Yup, they do. Nobody can create an infallible system of anything. If human beings design systems, there is an opportunity for threats to be uncovered and exploited. Third, anything is possible – any threat is possible. Expand beyond the cookie-cutter threats and brainstorm things specific to your system. You are the only person with the time and qualifications to threat model your ZT system.

Differences with Zero Trust Threat Modeling vs. Classic Threat Modeling

Threat modeling is adaptable and expandable, and the focus of threat modeling on Zero Trust is no different. Consider the changes when we apply threat modeling in a zero-trust world.

• When explicitly authenticating and authorizing all subjects, assets, and workflows that make up the enterprise, we must consider a new set of threats.

• Zero trust security models assume that an attacker is present in the environment -- death to the trust boundary -- it no longer exists.

• All data sources and computing services are considered resources accessible to anyone. Classic threat modeling considers that data sources are always protected from external intervention unless through an intermediary. The world is changing, and all data sources must consider threats never considered before.

• All communication is secured regardless of network location. Threats derived from a lack of confidentiality and integrity must still be considered in a zero-trust threat model but will be seen far less.

• Access to resources is determined by dynamic policy, focusing the bulk of threats in a zero-trust world on the policy engines and authentication and authorization systems.

• Zero trust threat modeling assumes no ownership of assets or infrastructure. This opens more threats that would have been discounted in classical threat modeling due to trust boundary protection.

• The network is no longer a trusted asset behind a trust boundary. The network is the wild west, and threats must be considered as such.

• Zero trust is not the complete end of the boundary -- the boundary is replaced by policy enforcement points or bumps along the road for an attacker.

There is no reference architecture in the real world

You may have seen the NIST reference architecture in 800-207. If you want to see something funny, go to Google Images or any other image-searching tool and search for Zero Trust reference architecture. You'll receive images of the same NIST reference architecture, tuned up by the vendors to display their color schemes. Organizations only post their fundamental architectures on the Internet for all to see if you are Google, and you post the BeyondCorp paper that shows how they assembled their network.

This is to say that no reference architectures exist in the real world. Everyone's ZT deployment is different; yes, they use the same principles and architecture patterns, but they are not the same. We cannot review and secure the reference architecture once and expect that we will be good to go in perpetuity.

Using STRIDE to model Zero Trust

STRIDE has been the go-to threat modeling methodology for most people. STRIDE provides a mnemonic and a set of threats to consider. The key to STRIDE is that it is simple to use, apply, and internalize. STRIDE is helpful for all time, but as you become a savvier threat modeling person, you will come to rely upon other, more in-depth methodologies.

Let's explore the application of STRIDE to Zero Trust.

Spoofing and Tampering

This analysis lumps Spoofing and tampering together, as the same control mitigates them. ZT Tenet #2 says, “All communication is secured regardless of network location.” If all communication is secured using something like TLS, then spoofing and tampering by observing or modifying network traffic in flight is no longer possible. Spoofing and Tampering can be assumed away if the ZT model is followed.

Repudiation

Repudiation is the threat of an attacker or anyone performing an action that cannot be attributed to them. Given the penchant for logging prescribed in the ZT Maturity Model, repudiation is relatively easy for ZT. The Maturity Model uses an SIEM solution to store logs and describes scenarios where logs must be generated. Repudiation is not a significant threat to ZT.

Information Disclosure

Information disclosure is a slippery possibility and one that is possible with almost any interface. Information disclosure is a proper threat for consideration against STRIDE but requires additional thinking about the data that could be disclosed based on what the system is protecting.

Denial of Service

Depending on how open the ZT system is determines how likely a DoS/DDoS could cause an outage deeper into a system. Some ZT systems are described as being open, using public IP addresses for all assets. In these systems, the threat of DoS is more prominent, as the attacker has a method to address the internal systems and attempt to pass traffic inbound.

This exposes the age-old architectural debate about how many other layers you should add to your ZT to ensure proper protection. Is ZT still ZT if you have additional layers of firewalls?

Elevation of Privilege

Elevation of privilege is attempting to go from a standard user account and gain the privilege and, hence, the capabilities of an administrative user. The challenge with considering this threat against ZT is that ZT exists to prevent this threat! ZT has scalable authentication and authorization and dynamic policies to make the elevation of privilege unlikely. Hence, EoP is not a significant threat to apply to a ZT system.

Conclusion on STRIDE

Consider all the explanations for each of the STRIDE categories. Nothing is jumping off the page as a crucial issue requiring mitigations within the STRIDE framework. There must be some other way that we can threat model a ZT environment. There is; it's called CAPITALS.

ZT CAPITALS Methodology

CAPITALS is a methodology forged from a threat modeling analysis against the ZT reference architecture. A collection of threats was identified and then used to reverse engineer the methods and the mnemonic.

• Compromise & Exploit: Gaining unauthorized control over an element in Zero Trust (ZT) or exploiting its vulnerabilities.

• Authentication & Session Management Failure: Compromising any part of the identification and authentication mechanism or workflow.

• Poisoning: Introducing deceptive or misleading data.

• Information Disclosure: Exposing confidential or private information.

• Tampering: Altering data or interfering with an automated procedure.

• Authorization Bypass: Bypassing or undermining any aspect of the access control system or its procedures.

• Lack of Logging: Intentionally or unintentionally neglecting the creation of accurate audit logs.

• Segmentation, Visibility Breakdown, and DoS: Disrupting the control/data plane, impairing network visibility, or causing a Denial of Service.

CAPITALS is tracked in a GitHub repo and is available for comment and update by anyone in the community. https://github.com/edgeroute/zttm

How to Use CAPITALS in YOUR Threat Model

CAPITALS works in conjunction with a solid process of threat modeling. Here are some tips for using CAPITALS for effective ZT Threat Modeling.

• Utilize a collaborative, functionally diverse team of threat modeling people to work with you.

• Build a data flow diagram if you have no diagram, or use your existing ZT architecture diagram to inform the threat modeling process.

• Consider each threat category against each component and flow of the ZT architecture.

• If you can dream it up, an attacker somewhere can make the threat a reality.

• Capture your threat brainstorming exercise, documenting everything that is suggested.

• Focus on mitigations – the model is only as good as its mitigations.

• Perform a prioritization exercise against the threats; fix critical and high ones. Backlog anything that doesn't fit into the current fix cycle.

• Update your design based on the prioritized threats and mitigations.

Reference Architecture

I want to perform this analysis without using the reference architecture. Still, Enterprises do not post their ZT architecture diagrams for people to peruse and use as input to a threat model. We're stuck with the reference, but you can draw conclusions and parallels between the reference and your specific architecture.

If you're unfamiliar with the reference, let's start with the users, non-person entities (NPE), and attackers. These subjects attempt to access resources behind the policy enforcement point or PEP. The PEP is informed by both the Policy Administrator (PA) and the Policy Engine. The Policy Engine receives data from many sources, including Continuous Diagnostics and Monitoring (CDM), Threat Intel sources, and data access policies. Identity Management and Enterprise PKI are both supporting functions of the architecture. The other big point is the split between the Control and Data Planes. The Control Plane is a protected pathway tightly controlled and isolated from public networks. The control plane allows back-channel administration of the system, minimizing the threat from external actors. The data plane is the wild west, where all the traffic flows. Any connections that cross the barrier between control and data must be tightly controlled and secured.

The Threats Against ZT

The represented threats contain a subset of all the available threats against ZT and are one researcher's attempt to capture a taxonomy. For each threat, a set of possible mitigations is provided for consideration. There are more threats and mitigations possible in the ZT universe. See the GitHub repo for opportunities to add additional threats to the taxonomy.

Compromise and Exploit

Compromise and exploit capture any attempt to gain unauthorized control over an element in a Zero Trust (ZT) architecture or exploit its vulnerabilities. This category starts off the ZT threat journey because of the many canned components in all ZT architectures. Each component is a target for attackers to attempt to access and control.

Threat #1: Policy Subversion

An attacker subverts the ZT decision process by compromising the PE and/or PA. (NIST 800-207) The PE or PA could be compromised due to remote code execution or a web application-style vulnerability. One of the great things about threat modeling is that we don't have to declare the exact exploit that will be used for this to be a threat. The fact that an exploit could be used or discovered is enough for us to craft a series of mitigations.

Mitigations:

1. Proper, timely patch management is crucial for a ZT architecture's primary security-enforcing components to be patched and treated as the most critical infrastructure in your environment. Monitor and patch them as they are available.

2. Testing the environment for known security issues will uncover any potential challenges that could be corrected before an attacker finds them.

3. Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA). Any subject should only have access for a short period and only enough access to achieve whatever their current mission includes.

4. Harden the PEP for battle. The Policy Enforcement Point will be attacked constantly; harden this device for combat.

Threat #2: OWASP Top Ten Exploit

A ZT environment consists of a collection of various components. These components will have administrative interfaces that use the web. This threat is when an attacker exploits an OWASP Top Ten vulnerability in an administrative web interface.

Mitigations:

1. Constrain ALL administrative interfaces to the Control Plane; this seems like a simple conclusion, but when building real-world systems, things aren’t always so simple. By enforcing this rule, we take any admin interfaces outside the data plane danger zone.

2. Keep the Control Plane isolated; again, this seems too simple to bear repeating. Respect the Control / Data Plane isolation in your design.

3. Awareness amongst system and application builders; teach your developers and builders the OWASP Top Ten. Ensure that all builders and defenders know this set of issues and understand how to apply mitigations against the specific OWASP Top Ten application security risks.

4. Testing and mitigation of environment specifically for OWASP Top Ten. Use network vulnerability and API scanning tools to discover any OWASP Top Ten issues.

Authentication & Session Management Failure

Authentication is how subjects identify and prove who they are to the system. ZT assumes using MFA, but not every assumption comes true in the real world. We have an authentication threat when an attacker compromises any part of the identification and authentication mechanism or its workflow.

Session management is the control that generates and transmits secure identifiers that prove that a subject has been authenticated and can access the system without authenticating on every request.

Threat #3: Session Hijacking

The first threat against authentication is when an attacker discovers/compromises the session management strategy and gains access to an object by impersonating another user or a service. For purposes of the threat model, we do not have to prove how the attacker would accomplish this task; instead, focus your efforts on how to modify the system to ensure that this scenario is not possible

Mitigations:

1. TLS encryption of data flows. ZT prescribes encryption everywhere. We state it here as a reminder to ensure this is the case. Encryption protects authentication and session information as it crosses the wire. If an attacker cannot see the auth and session info, it is much more difficult to cause an issue.

2. Strong authentication token strategy with strong session identifier for users; a session management token is only as good as the algorithm that created it. Ensure you use the most robust token approach that works for your subject population. (OWASP Session Management Cheat Sheet)

3. Protect the generation, distribution, and storage of service tokens. Service tokens are employed by Non-Person Entities to access the system. Ensure that the generation of the service tokens is secure, the mechanism in use to distribute those service tokens to the NPE, and the storage of the token on the NPE.

Threat #4: Credential Theft

An attacker steals or guesses a password using a brute-force attack, phishing, or credential stuffing and provides the password to a ZT AuthC that supports username/password as a fallback authentication mechanism. In this case, we don't care how the attacker gets the password, as there are other approaches the attacker could take beyond those spelled out. We focus on a place within the architecture that supports username/password fallback.

This is another place where we can be ZT purists and claim that this condition isn't possible because ZT requires MFA. While this belief may be true, systems operate in the real world, and it's worth considering whether this threat applies to your system.

Mitigations:

1. Implement MFA, simple two-word mitigation, which is 1000X harder in the real world. You must set up all your systems for MFA, train and enroll your user populations, and then monitor the MFA systems for signs of compromise. Implementing it may be 1000 times more challenging, but it is worth every second invested.

2. Disable any usage of username/password AuthC. Analyze all corners of the ZT system to ferret out any AuthC fallback mechanisms. There may be skeletons in the closet.

Poisoning

The poisoning category describes when an attacker Introduces deceptive or misleading data into a trusted data source. The attacker's goal is to get the ZT system to misbehave based on the inputted data, changing some scope of a security decision.

Threat #5: Data Poisoning

An attacker poisons the Continuous Diagnostics & Monitoring (CDM) data set or injects false data into the data set {to trick the AuthZ process into opening access}. (800-207+) This threat was originally taken from NIST's guidance, with our unique spin added within the {}. With any poisoning attack against ZT, the primary goal is to get an access control decision to provide access to a subject that should not be allowed access against the original policy.

Mitigations:

1. Design the CDM solution within a separate Control/Data Plane. ZT has clean separations between the Control and Data planes, while every representation of CDM shows it as a single rectangle. Extend the Control/Data Plane concept to the CDM solution, protecting the integrity of the data that the CDM sends as input to ZT.

2. Cryptographically validate any CDM updates. Add a signature check to prevent poisoning, proving that a legitimate, trusted party is sending the update.

Threat #6: Intelligence Disruption

An attacker poisons or injects false data into the threat intelligence feeds to prevent legitimate users from gaining access. (DoS) Of all the parts of the architecture, threat intelligence is most likely to be sourced from an external provider. These external providers could be a target all to themselves, based on the number of clients they support. They could also become a target because your company employs them.

Mitigations:

1. Strong third-party risk program. A third-party risk program is an enterprise-grade entity that exists to measure and assist in mitigating risks resulting from third-party business relationships. See the Third Party Threat Hunting podcast for more context.

2. Threat model / assess your provider's architecture. Use these same threat modeling principles to review threat models created by your providers. Determine if the provider is creating accurate threat models that focus on mitigations. If not, offer to help the provider go through the threat modeling process.

Information Disclosure

Information disclosure is old-school STRIDE. It makes its way forward into CAPITALS because the exposure of confidential or private information concerns any system.

Threat #7: Reconnaissance Abuse

Imagine that an attacker somehow gains access to your CDM. The data contained within is intelligence about the weakest points in the architecture. This intelligence would assist the attacker in targeting the low-hanging fruit.

Mitigations:

1. Design the CDM solution within a separate Control/Data Plane. We mentioned this in the previous section, so re-read that if you need a refresher.

2. Patch management and monitoring for CDM. Solid patch management and monitoring are essential for even the systems that perform the monitoring for everybody else.

3. Limit data exposed in the CDM systems. The first rule of privacy is only to keep information that you need to use. If you don’t need data, don’t collect and store it. The same rule applies to CDM.

Threat #8: Policy Recon

Like the CDM data previously, an attacker accesses the data access policies to understand the input being sent to the policy engine.

Mitigation:

1. Protect data access policies in whatever format they exist within. Keep the data access policies away from attackers and anyone who does not “need to know” how authorization works in the ZT system.

Tampering

Tampering is a category that encompasses altering data or interfering with an automated procedure. Tampering with data is an easy piece to understand. If an attacker can intercept data on the wire, they can modify it somehow.

Interference is a particular case of tampering where an attacker interferes with the correct operation of an NPE or service.

Threat #9: Data Interception

A simple threat, a simple scenario. An attacker receives or tampers with data on the wire. We don't have to declare how – only that the case is possible.

Mitigation:

1. Never ASSUME that TLS has been utilized in every corner. We all know what “assume” stands for. Sound it out. Never assume that TLS is everywhere; trust but verify.

Threat #10: Coercion Abuse

An attacker can induce or coerce a non-person entity to perform a task the attacker is not privileged to perform. (800-207) NPEs are hotspots for attackers because they are often left alone to perform a function with limited activity monitoring.

Mitigation:

1. Extreme least privilege for NPEs. We’ve talked about least privilege for decades, which still makes sense. Extreme least privilege limits the NPE/service to only exactly the requests it needs to make into the ZT system, down to the REST API method and endpoint. Through extreme least privilege, we create a system where an attacker with an NPE is limited in what they can reach. Coercion is limited.

Authorization Bypass

Authorization is the core of ZT. This threat category includes bypassing or undermining any aspect of the access control system or its procedures.

Threat #11: Timing Exploit

A "Time of Check to Time of Use" (TOCTOU, pronounced "tock too") vulnerability refers to a race condition where a system's security decision, made at the "time of check," becomes invalid or exploitable by the "time of use." This vulnerability arises when an attacker can change the system's state between the check and use times, leading to unintended consequences.

Suppose the Zero Trust system doesn't continuously validate the security posture of the user's device (or does so at long intervals). In that case, there's a window where the user's compromised device can access the sensitive resource. An attacker exploiting this TOCTOU vulnerability could gain unauthorized access.

Mitigation:

1. Limit subject access with Just-In-Time and Just-Enough-Access (JIT/JEA). JIT/JEA is crucial to preventing TOCTOU conditions.

Threat #12: Access Flaw

External policy attributes provide input to the policy engine about what data should be considered as the policy. Data incompatibilities could cause a PE/PA to allow attackers access to data they should not have access to. (800-207)

Mitigation:

1. Know what attributes and what sources are used for policy decisions. As ZT designers, you must understand all the various attributes used as input into your policy. An accidental interpretation of data attributes could open an entirely separate class of threat.

2. Define the order of operations for different sources. Given that different sources are used as input, it is crucial to know the order of operations for how attributes should be considered against the policy. The order of operations must not be left up to a random function.

Lack of Logging

A lack of logging could result in an attacker having a field day inside the system, with no tracking or traceability of the attacker's actions. Lack of logging is Intentionally or unintentionally neglecting the creation of accurate audit logs.

Threat #13: Logging Failure

An attacker can attack the App Server, and because it does not log at the correct level, the Response team is unaware of the attack. Or worse, a National Government inquiries about the operations of a bad actor within your systems, and you have no evidence to prove or disprove the actions taken by the actor.

Mitigations:

1. Comprehensive logging from all elements. Ensure that logging is applied across your architecture and is considered for every security-relevant action.

2. Perform a logging audit to ensure policy compliance. Trust but verify also applies to logging—audit applications and systems to ensure proper logging data is making its way to the SIEM. The log you save may save your butt.

Segmentation, Visibility Breakdown, and DoS

This final category is a miscellaneous one. We had some additional things to cover, but they did not warrant a letter. Welcome to the kitchen sink category.

Segmentation breakdowns describe threats when an attacker attempts to cross over some ZT-defined boundary. This primarily impacts or disrupts the control/data plane separation. Also covered are impairing network visibility or causing a Denial-of-Service condition.

Threat #14: Control Breach

The “piece de resistance” is one of the worst possible things that could happen in a ZT environment. An attacker accesses control plane resources (PA) from the data plane, violating a boundary that should be a wall.

Mitigations:

1. Threat model the control plane as a separate entity. The control plane is the most precious asset within ZT, so perform a separate threat model of only the control plane. Update this threat model often as the architecture evolves.

2. Aggressively test the control plane interfaces. If the control plane is our most precious asset, we must use any available resources to test its interfaces.

3. Attack surface analysis and monitoring of the control plane. If any area of our architecture screams for automated attack surface analysis, it’s our control plane. Connect an attack surface management tool and have it constantly scan the control plane for any new interfaces. If you get a hit, jump on it and close it down.

Threat #15: Network Compromise

An attacker compromises the network layer devices and reconfigures the ZT environment. We often forget about the network layer in ZT. We never show the network layer on the fancy diagrams, but a network underneath makes ZT possible. It also opens potential attack vectors at the network layer.

Mitigations:

1. Control/data plane separation for network devices. This idea was invented in the network, so ensure you follow this principle at the network layer.

2. Threat model the network as a separate entity. We've said threat model about two hundred times in this paper, but it is a viable approach to model the network outside ZT and mitigate any threats you discover.

3. Patching and hardening processes for network devices. Yup, patch and harden are mentioned again. Ensure the network gets the same rigor of patching that you apply to the ZT system.

4. Network device complete visibility in the SOC via SIEM. Ensure the SOC has complete network visibility to see network-related security problems that may happen outside of the ZT scope.

Lessons Learned from ZT Threat Modeling and Conclusion

As you can guess from this article, there was quite a bit to learn when applying threat modeling to Zero Trust.

• Threat modeling and secure by design/default are constructs that move security and privacy forward with ZT.

• The universe of applicable threats crosses identity, devices, networks, applications/workloads, data, subjects, and objects.

• ZT TM requires a holistic view of the system, as threats can exist anywhere within the architecture (even in non-ZT things like applications).

• The standard threat modeling process applies to ZT (scope, draw, analyze, mitigate, and retrospective.)

• The ZT Capitals methodology is needed to capture the unique threats of a ZT world: compromise & exploit, authentication & session management failure, poisoning, info disclosure, tampering, authorization bypass, lack of logs, and segmentation/visibility/DoS.

• It is easy to make assumptions about the strength of a portion of the ZT system. Never assume anything when it comes to security and privacy.

• ZT is vast and complex, and securing something complex vs. simple is more challenging.

• There are no reference architectures in the real world. Model the thing that you have built, not the reference architecture.

Threat model all the things, including all the ZT things! You now have a reference and a methodology to apply to ZT. Your task now is to take it and put it into use. Drop me a line if you find this useful; I’d love to improve it over time with feedback from folks who put it into use.

Threat modeling is life.

References

• NIST's 800-207 Zero Trust Architecture.

• CISA Zero Trust Maturity Model.

• Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by Design and –Default.