The zero trust model was published in 2010 by John Kindervag, who was employed by IT analysts Forrester Research at the time. However, the foundations for zero trust were laid down as early as 1994 by Stephen Paul Marsh in his doctoral thesis at the University of Stirling (Scotland).

The strategy only really became popular in 2020 when, as a result of the coronavirus pandemic, many companies had to switch to home offices and new labor models at short notice, putting their previous safety solutions to the test. As a result, many companies defined zero trust as the core of their cybersecurity setups and launched projects to match.

The steps from the basic model to a concrete implementation are painstaking, partly because the model was initially very network-centric (zero trust networks) and primarily postulated generic requirements. However, the zero trust architecture [1] from the US National Institute of Standards and Technology (NIST) and a position paper from Germany's BSI [2] (for which the institute expressly invites suggestions, comments, and criticism) have since been released.

Basic Principles

Zero trust originally focused on security in network infrastructures, with the focus on preventing lateral movement (i.e., preventing attackers from moving relatively freely on the network to attack systems after working around the firewall). The next basic idea was not trusting individual components, but rather carrying out continuous verification at different points and on different levels: never trust, always verify. The fundamental cornerstones of zero trust are derived from:

• Continuous verification or, to be more precise, repeated verification of users, devices, and applications during access and in ongoing sessions, because they are all considered inherently insecure
• The minimum principle, which is the assignment of only the minimum required authorizations that, ideally, should also be assigned just-in-time (JIT; i.e., only as soon as and while they are needed)
• Multilevel security, with checks carried out repeatedly and at different levels

Also cited frequently is microsegmentation of networks to reduce attack surfaces, create more points for verification, and contain the spread of attacks. However, this measure is just one technical implementation among many.

Figure 1 provides a slightly different and broader view: Users rely on their devices to access services on the network. In turn, services are at the system and application levels to access and manipulate data, and software forms the basis. Access is also supported for service accounts and non-human identities, but the principle remains the same. On the one hand, the figure illustrates the complexity of zero trust as a strategy, because it does not just apply in a single place. On the other hand, it shows how it is possible to break down the comprehensive model into smaller parts and focus on a variety of security measures across the entire chain, which then come together to form a zero trust approach.

Figure 1: Zero trust encompasses many areas of IT, so successful approaches require numerous measures.

Important Technical Components

Figure 1 shows the areas in which measures are focused when establishing zero trust security:

• Identities with identity and access management (IAM) and especially multifactor authentication (MFA), which ideally no longer works with passwords (passwordless authentication)
• Devices with terminal device security and device management
• Networks with microsegmentation and zero trust network access (ZTNA)
• Systems with hardening and access control in conjunction with IAM.
• Applications with hardening, access control by IAM, and, if possible, dynamic authorization by policy-based access management (PBAM)
• Data security and data governance
• Software with supply chain security

Figure 2 shows additional interdisciplinary functions. Of note are policy management and monitoring in the broadest sense (i.e., topics such as extended detection and response, XDR). Other aspects such as incident response management; security information and event management (SIEM) and security orchestration, automation, and response (SOAR) tools as part of monitoring; and attack surface management are also key components of a zero trust solution.

Figure 2: Zero trust relies on policy-based control of access across different units and on continuous monitoring.

Policies or guidelines, which NIST also emphasizes in its zero trust architecture, are important elements. Security must be controlled by policies, which has long been the case at various levels, such as firewall policies for network access. What is still missing, but is not an obstacle to implementing zero trust models, are consistent solutions at all levels (e.g., PBAM in the application access authorization area) and consistent tools for policy management and governance. Consistent policy governance can also be implemented without technical tools for cross-system policy management.

Ultimately, these very large numbers of fields of action are the result of the many facets of cybersecurity that cannot be reduced to individual technologies. On the other hand, organizations do not typically need to start from scratch, but already have various elements in place. It is therefore usually more a question of completing and optimizing rather than completely rebuilding cybersecurity.

Organizing and Planning

The key to success with zero trust is easy to define and comprises two aspects. The first is reducing complexity, and the easiest way to resolve this problem is to break it down into small parts, which IT managers then look at individually – but without losing sight of the big picture – before putting everything back together. Figure 1 shows that zero trust comprises many elements that can be resolved separately. In other words, the aim is to define and implement manageable projects in a zero trust program while defining the superstructure (e.g., overarching monitoring and policy governance).

The second aspect is concretization. Although zero trust is an abstract concept, the individual elements can easily be concretized. What do you need to improve network security? What does modern IAM look like? For these simple, clear-cut questions, the basic idea behind zero trust (i.e., never trust, always verify) acts as an acid test. You need to ask yourself whether the chosen approach is one of many layers in a multilevel security model with continuous monitoring or whether IT is just creating another layer that it trusts.

The first step before defining projects in a program is to understand what needs to be done. The best starting point is a business impact analysis (BIA) to help you understand which parts of business operations and the underlying IT and operational technology (OT; e.g., in production) are particularly critical, which together with attack surface management (ASM) makes it possible to determine where criticality for business operations and risks from attack surfaces are particularly high. On this basis and armed with the knowledge of the basic building blocks in a zero trust approach, a rough ideal scenario can also be sketched out that lists the necessary elements and can in turn be mapped against the assessed risks and critical areas.

The next organizational step is gap analysis, a critical comparison of the required and prioritized components and the current status. This step helps to identify the biggest gaps and subsequently to develop a roadmap to further improve the current state of the cybersecurity infrastructure in line with zero trust. The result is the logical sequence of a concrete program and project planning.

You should always keep critical comparison in mind. Unfortunately, defensive arguments are often used in gap analyses because individual departments and managers feel attacked when gaps and the need for change are brought up. However, the objective is to take the next step toward state-of-the-art security strategies and technologies – not to criticize what has been achieved so far.

When progressing toward a zero trust model, it is also important to rethink the organization. As a rule, this part is the responsibility of the person in charge of IT security or the chief information security officer (CISO). In practice, however, this is not always the case for all elements. In some organizations, IAM is still assigned to the IT infrastructure and not to the CISO. Network security is sometimes the responsibility of a separate network and communications division; application security is often organized in a decentralized way; and terminal device security is often the task of client management. Ideally, companies would want to adapt to ensure that all security-related issues are dealt with by the CISO. If this arrangement is not feasible, the other departments must be involved in the zero trust project, and the CISO must receive the necessary backing from IT management and the executive board.