As a security architect within IBM Security Services, I often get asked the question, “What exactly is a Zero Trust architecture?” Well, there is no single or unique answer to that question for two reasons.

First, Zero Trust is not an architectural model but rather a set of guiding principles that should be applied to existing and new designs. With that said, these principles present a number of architectural patterns or use cases that can serve as a starting point for implementation.

Second, the implementation of Zero Trust principles results in very different technical solutions and approaches for different uses cases. For example, applying the same Zero Trust principles for an employee remote access use case would be addressed in a very different way than handling micro-services connectivity in a service mesh running on containers.

So, where does one even start and how would Zero Trust change the way security solutions are designed? To answer these questions, I propose starting at the right architectural entry point: enterprise security architecture (ESA). In this article, I’ll briefly describe how the principles of Zero Trust could be introduced at your organization through the different architectural governance levels and against ESA.

Looking at Zero Trust Architecture Through an ESA Lens

To establish an IT security governance model, most organizations define an ESA as part of a wider enterprise architecture program. In an ESA, all aspects of IT security are defined through the different stages of design. You’ll typically find the following stages: the contextual or business layer, the conceptual layer, the logical layer and the physical layer. Below I provide a summarized overview of the concepts.


Source: IBM Security

In addition, an ESA should address the governance of how the solutions and artifacts are maintained at the different layers like what is shown above. Security operations will need to manage the day-to-day operational risks while architecture review cycles ensure that the solution’s building blocks are identified and up to date. I’ll come back to this last topic later.

Also, the security controls of an ESA should be designed, implemented and managed at the enterprise level. A security control is typically a solution that combines your people, processes and technology. From a high-level perspective, both the actions required to mitigate identified IT risks and the actions required to ensure regulatory compliance are translated into a set of security policies that are then enforced and implemented through an extended collection of security controls. An ESA helps to define the approach of how to achieve that goal in line with business requirements.

Combining Security Architecture With a Zero Trust Governance Model

If we start applying the Zero Trust principles to security architecture, it is clear that the contextual level does not change. The regulations, risks and business drivers are not changing, but the way an organization would address these requirements might change. Therefore, implementing Zero Trust principles will start at the conceptual layer of your architecture. IBM Security’s four-tenet Zero Trust governance model could be leveraged to structure the approach (see figure below).

Source: IBM Security

1. Define Context

Defining context is key for Zero Trust across all security domains. Here, the foundation for your Zero Trust implementation road map has to be defined. New security policies will have to be defined and existing policies might require adaptation. The use cases within the organization should be identified as soon as possible, including what kind of integrations should be established between the controls at the different layers. Integrations will be one of the major changes coming with Zero Trust implementations in the next couple of years.

The vanishing perimeter paradigm will have to result in more integration between the security controls installed at the different layers of defense. The result is consolidated insights that can be used to make the access decisions for your data dynamically (under the principle of “Always Verify”) and access is no longer solely based on static access-control lists (ACLs).

From the ESA point of view, this “Define Context” tenet is where the security policies are set. Moreover, security services are needed to support the organization’s requirements. The capabilities needed to provide the services should be compiled and the high-level solution patterns built on these capabilities will need to address the Zero Trust use cases. The new and adapted capabilities have to be defined at the technical level and then deployed. The ESA should also define how to move from architectural version N to version N+1 through a transformation road map. In the picture below, I map the IBM Zero Trust governance model to the ESA example.

Source: IBM Security

2. Verify and Enforce

The “Verify and Enforce” tenet in the IBM governance model is where most security vendors position their Zero Trust solutions. In an ESA context, this is where the logical architectures define the required security building blocks (SBB).

Next, the logical architecture is worked out into technical designs based on the selected technologies. For example, the implementation of micro-segmentation for infrastructure in the data center will require a detailed technical design at the network layer. The role of ESA is to ensure the overall principles are followed during design and that the design goals like integration are achieved.

3. Resolve Incidents

Next comes everything related to security operations. This third tenet is called “Resolve Incidents” in IBM Security’s Zero Trust governance model. It is here where security operations are defined. This is also where security teams learn how to cope with security incidents impacting trusted connections and speed up both the detection and response for these incidents.

From my perspective, the operational architecture within ESA is the most important concept here. You could have the best security technologies available, but if they’re not properly managed by the security operations team, it won’t meet expectations and can result in failed outcomes. We all know that security maturity can’t be achieved in every layer at the same moment. To overcome this challenge, adequate security monitoring solutions and automated response measures are the best tools to overcome possible gaps in maturity.

4. Analyze and Improve

The tenet of “Analyze & Improve” is a key element of the Zero Trust governance model and it should also be a standard component of every ESA. In a rapidly evolving technology landscape, where there are accelerated product releases thanks to Agile approaches combined with automated CI/CD delivery models, an ESA should focus on the continuous improvement loop.

Implementing Zero Trust principles won’t be achieved overnight. The changes should be tested on a single use case that’s relevant to your business and the effectiveness of that implementation should be consistently measured with improvements applied in an Agile way. Once your initial use case is deemed ready, the same approach can be scaled out to other enterprisewide use cases, meaning that all activities related to “Analyze & Improve” will have to occur at an accelerated pace.

Interested in learning how you can begin your Zero Trust adoption? Learn about the steps you can take with an integrated, multi-disciplinary governance model that advances progress toward maturity.

More from Zero Trust

Contain Breaches and Gain Visibility With Microsegmentation

Organizations must grapple with challenges from various market forces. Digital transformation, cloud adoption, hybrid work environments and geopolitical and economic challenges all have a part to play. These forces have especially manifested in more significant security threats to expanding IT attack surfaces. Breach containment is essential, and zero trust security principles can be applied to curtail attacks across IT environments, minimizing business disruption proactively. Microsegmentation has emerged as a viable solution through its continuous visualization of workload and device communications…

Why Zero Trust Works When Everything Else Doesn’t

The zero trust security model is proving to be one of the most effective cybersecurity approaches ever conceived. Zero trust — also called zero trust architecture (ZTA), zero trust network architecture (ZTNA) and perimeter-less security — takes a "default deny" security posture. All people and devices must prove explicit permission to use each network resource each time they use that resource. Using microsegmentation and least privileged access principles, zero trust not only prevents breaches but also stymies lateral movement should a breach…

What to Know About the Pentagon’s New Push for Zero Trust

The Pentagon is taking cybersecurity to the next level — and they’re helping organizations of all kinds do the same. Here’s how the U.S. Department of Defense is implementing zero trust and why this matters to all businesses and organizations. But first, let’s review this zero trust business. What is Zero Trust? Zero trust is the most important cybersecurity idea in a generation. But “zero trust” is itself a bit of a misnomer. It’s not about whether a person or…

Effectively Enforce a Least Privilege Strategy

Every security officer wants to minimize their attack surface. One of the best ways to do this is by implementing a least privilege strategy. One report revealed that data breaches from insiders could cost as much as 20% of annual revenue. Also, at least one in three reported data breaches involve an insider. Over 78% of insider data breaches involve unintentional data loss or exposure. Least privilege protocols can help prevent these kinds of blunders. Clearly, proper management of access…