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.