Zero trust requires clear architecture plans before changing core systems

Zero trust touches everything: identity, applications, networks, data, and devices. The best approach is not to change everything all at once. Instead, start with the big picture.

In our research, we’ve found the most successful organizations dedicated the first phase of their zero-trust initiatives to working out an architecture. They didn’t rush into deploying solutions as though starting with a greenfield.

Everyone else dove in fast, mixing the foundational work on zero trust with one or more of the knock-on efforts: rearchitecting networks, security, and data management; buying tools; forming implementation teams and setting them to work. All those things need to happen, of course, but with zero trust, it pays to do a lot more thinking about how all the pieces will fit together before undertaking the changes needed, either at the architectural level or in the tool set.

When we talk about security success, in this case we mean organizations with a very low ratio of serious cybersecurity incidents. The more successful organizations had, at the most, two serious incidents per 100 cybersecurity incidents (a serious incident is defined as one that has an impact on staff or the business, or requires external reporting). And in most cases, these successful organizations kept their ratios well below this 2% threshold. (Data comes from Nemertes’ recent research on cybersecurity, the Secure Cloud Access and Policy Enforcement Research Study 2021-22)

Zero-trust planning

Make no mistake, zero trust will almost certainly require changes at the architectural level, for network, for security, and for data access. This makes sense if you consider the concept zero trust aims to make real: that there is no implicit trust in the environment, regardless of location or previous trust relationships.

Zero trust necessarily touches every aspect of operations, every level of the systems in the environment. Moreover, it is a radical shift from the currently dominant paradigm of trusting some parts of a network more than others, trusting some users further than they need to be trusted just because of where they sit in the organization, and trusting entities in the environment once they gain access. However, changes to these core systems must be considered once the big picture of your zero-trust environment has been pretty well defined.

For example, your architects may decide that network-level enforcement of application-level access rights is preferable—that if entity A wants to use service B but does not currently have the authorization to do so, A will not even be able to see or get packets to B across the network, let alone submit credentials. In that case, the network may need to be redesigned to enforce the policy map directly.

Or, enforcement might be handled at the endpoint level for systems able to run a software-defined perimeter client, and the network only required to handle policy enforcement for devices that cannot (timeclocks or sensors, for example). In either case, those high-level choices should, as much as possible, be made before the redesigns in the separate technology spaces begin.

Get the tools, get the talent, get in step

Once the high-level architecture and various space-specific architectures have been spelled out, IT should turn to questions of implementation. As always, this will involve people, process and policy, and technology.

On the people side, most organizations (including the most successful) pull together cross-function implementation teams at the beginning of a zero-trust effort. Such teams take on the initial aspects of translating vision into reality, architectures into portfolios and processes. Since zero trust is a major shift in foundational assumptions around security and access, there can’t be a “zero trust team” for the long term. In the long term, everyone is on the zero-trust team.

In the short term, though, key staff from network engineering, data management, and application engineering should be shifted to focus on getting the zero-trust effort rolling. As much as possible they should be shifted off day-to-day maintenance and management. As they work through the gaps between the zero-trust architectural goals and the existing environment, they will propose what tools are needed to fill gaps between tools to be retained, or to replace old systems with more functional ones, or to provide orchestration of policy execution across tools. Will it be a software-defined perimeter (SDP)? If so, which, and for what functions? A universal service gateway for user access to applications? Which, and how will it share policy with the SDP?

The zero-trust team will also provide the first pass of changes to security and access policies (e.g. what kinds of access to systems are “birthright” for any employee, versus being tied to specific job responsibilities?) and processes (How do rights envelopes get reviewed, and how often, to prevent creep?).

The takeaway is that the transition to zero trust begins with a zero-trust architecture; everything else should follow from it. There are multiple other levels of architecture required, and probably retooling as well, to implement the new paradigm, but everything has to start with the big picture being well defined.