ON2IT Global CISO Prof. dr. Yuri Bobbert
Yuri Bobbert

Biden’s Zero Trust advice, as well as the Dutch NCSC advice, has put Zero Trust on the map more than it has ever been before. But what exactly is Zero Trust? And how has it developed since John Kindervag popularized the term?

In this blog series, we take a look at what lessons we have learned from many years of Zero Trust implementation. These practical lessons were gathered from six experts in the field with a collective experience of over sixty years of actually implementing Zero Trust in diverse settings.

As a professor in cybersecurity, I have examined Zero Trust extensively and observed a lack of empirical research being put to use in business environments. In this blog series, I will shed some light on lessons ON2IT experts learned over the past years, organized around the famous five-step model.

5 step model zero trust

Building on their extensive experience with Zero Trust implementations, these experts have published many works and conducted research specifically regarding Zero Trust. Their joint experiences and expertise are the foundation of the lessons we’ve learned.

What is Zero Trust?

Zero Trust is a strategic initiative that prevents successful data breaches by eliminating the need for digital trust in your organization. Rooted in the principle of ‘never trust, always verify’, Zero Trust is designed as a strategy that resonates with the highest levels of any organization, yet is tactically deployed using off-the-shelf technology. Zero Trust strategy is decoupled from technology. While technologies improve and change over time, the strategy remains the same.

How has Zero Trust changed over the years?

The term Zero Trust was first coined in 1994 by Stephen Paul Marsh[1] and then further popularized by John Kindervag. John, who at the time was working at Forrester, created this concept for cybersecurity improvement. Zero Trust has since never really strayed from its original definition, nor has it strayed from its original principle of ‘never trust, always verify’. Over the years, the implementation of the strategy has adapted to new technologies, however, the strategy itself has remained loyal to its roots.

The five lessons on implementing Zero Trust

Before we look at the specific steps though, here are some lessons we’ve learned that apply to Zero Trust in general which are relevant when considering implementing Zero Trust:

When it comes to implementing Zero Trust, there are five important steps that should always be taken. These steps are also adopted globally by local NCSCs (National Cybersecurity Centers). In each installment of this blog series, we’ll look at one of the five steps and the lessons we’ve learned that can be applied to that specific step.

Before we look at the specific steps though, here are some lessons we’ve learned that apply to Zero Trust in general and are relevant when considering implementing Zero Trust:

Zero Trust concepts and terminology

Stick to the original Zero Trust concepts and terminology, thereby avoiding misunderstanding and misconceptions about Zero Trust. This is key to getting everyone on the same page. For a refresher on Zero Trust terminology, you can check out our Authentic Zero Trust Guide.

Network segmentation ≠ Zero Trust

Network segmentation is not the same as Zero Trust; The basis of Zero Trust lies in determining the protect surfaces (formerly MCAPs or micro-segments). Each protect surface is based on a specific type of data, which logically includes an appropriate policy. The policy is not limited to firewall rules (which is often assumed in the context of micro-segmentation) but can also describe that data must be stored encrypted, or that endpoint protection is required.

DMZ ≠ Zero Trust

DMZ is NOT Zero Trust; The traditional DMZ setup is not secure anymore; it doesn’t protect what it was supposed to protect. In fact, in many cases, there are multiple servers in the DMZ serving different types of data, each with its own risks. There is no protection against lateral movement and thus no isolation in case of compromise.

Learn more about Zero Trust

Yuri BobbertThis webinar provides tools to start with Zero Trust within your organization. It also offers solutions to bridge the gap between strategy and operations before and after the implementation of Zero Trust.

During the Zero Trust Strategy to Operation webinar, this and other topics will be discussed by ON2IT Global CISO prof. Yuri Bobbert.

Register for the webinar

Indication of the current and desired state

Depart with an indication of the current and desired state of Zero Trust Readiness maturity level. The Readiness Assessment is used to determine the in-house required capabilities to implement Zero Trust successfully. This Readiness Assessment and the associated Frame of Reference, e.g., Framework, are depicted and described in previous publications and validated by +73 CISO’s in the field.

Risk and impact estimation on the critical business assets

The information security requirements (e.g., measures in the form of process measures, technical measures, or people measures) are based on the risk and impact estimation on the critical business assets. Zero Trust takes a more holistic approach to this, focusing not only on the asset but also on the associated applications and services that form a logical data segment. These are formed into a “protect surface” and risk assessments need to be conducted on said protect surface rather than just the siloed asset.

The traditional DMZ setup is not secure anymore; it doesn’t protect what it was supposed to protect
These general learnings and insights are relevant in all cases of Zero Trust engagement. Taking these general learnings into consideration, we will now look at the learnings that are relevant for the first step of the Zero Trust approach: define the protect surface.

 

Important lessons on step 1: Define the protect surface

The first step to Zero Trust implementation is defining the protect surface(s). You do so by identifying the DAAS (data, applications, assets, and services) elements that you want to protect and logically grouping them into protect surfaces. Some important lessons we’ve learned when it comes to this first step are:

  • Align with business and asset owners. They own valuable assets and understand the economic value of the asset and the potential impact. Involve them by design; Zero Trust journeys require time and effort from the organization, extended vision, and mental stamina. Not all managers have a strategic view and are keeping an eye out day-to-day (clock watchers). Consider that on average, a CISO’s job rotation is two years, so take into account that they will be replaced.
  • Start small, expand; it’s a skill. First, grab three applications, put security devices such as firewalls around them, do that well. After that, the rest is a variation on well-known earlier work.
  • Pay (sincere) attention to objections, pay early attention to objections that can live in operations (e.g. performance, this will never work with an inline firewall; will there not be too much policy, how do we monitor that?)
  • Invest in capabilities to tell the Zero Trust journey (to non-technicians), awareness of Zero Trust has evolved over the past years; first, it had to be proven that it is necessary to implement, then that it is indeed possible, and now it is becoming clear that not every marketing story in which “Zero Trust” appears, is actually Zero Trust.
  • Demystify jargon, formulate your protect surfaces in readable language, so everybody understands the value to the business. Nobody understands IP ranges but understands the protect surface “General ledger.”

The Data is the patient information

To elaborate on what DAAS actually means we refer to the following definition:

  • Data. What data needs to be protected? Think about intellectual property such as proprietary code or processes, personally identifiable information (PII), payment card information (PCI), and personal health information (PHI) such as Health Insurance Portability and Accountability Act (HIPAA) information.
  • Applications. Which applications consume sensitive information? Which applications are critical for your business functions?
  • Assets. Which assets are the most sensitive? Depending on your business, that could be SCADA controls, Point Of Sale terminals, medical equipment, manufacturing equipment, and groups of critical servers.
  • Services. Which services can attackers exploit to disrupt IT operations and negatively impact the business, such as DNS, DHCP, and Active Directory?

Each critical DAAS element is part of a protect surface (or in some cases is a protect surface). For example, if your business provides health care, then personal health information (PHI) is critical to your business. The Data is the patient information.

Many organizations already use CIA ratings to determine the rating of the assets, and viewing this solely from the asset is an old practice

Applications are the applications used to access PHI data—for example, EPIC. The Assets are servers that store the data and equipment that generates PHI, such as medical scanners or physicians’ workstations. The Services are services used to access the data, such as single sign-on and Active Directory.

When it comes to defining protect surfaces, use the guidance below:

  • The name represents the name of the set of DAAS elements we want to protect in clear, unambiguous language.
  • The characteristics represent the types of data being processed by the set of DAAS elements. A good source for this can be the outcome of the Business Impact Analysis or the Data Protection Impact Assessments, where asset owners determine the type of data processed in and out of the protect surface.
  • The relevance score represents the Confidentiality, Integrity, and Availability of the protect surface. Many organizations already use CIA ratings to determine the rating of the assets, and viewing this solely from the asset is an old practice. In Zero Trust, we consider the entire protect surface as a set of DAAS elements, and the individual component with the highest rating reflects the relevance score of the collective.
  • The reasoning is the argumentation we need for a specific protection level for the protect surface, which we need for one of the next steps in the five-step model, “Build a Zero Trust architecture.”

Conclusion

One of the major pitfalls for organizations is that they define protect surfaces in the ‘IT silo’, without involving the business people or asset owners. If you want to implement Zero Trust in a more holistic way, business involvement is key. Other important stakeholders in this process are the data protection officer, corporate counsel, and privacy officer.

Enterprise architects and business process engineers are the right people to do this protect surface design work and facilitate this design process.

In the next blog, we will share our learnings on the next step of Zero Trust: map the transaction flows.

Learn more about Zero Trust

Yuri BobbertThis webinar provides tools to start with Zero Trust within your organization. It also offers solutions to bridge the gap between strategy and operations before and after the implementation of Zero Trust.

During the Zero Trust Strategy to Operation webinar, this and other topics will be discussed by ON2IT Global CISO prof. Yuri Bobbert.

Register for the webinar

 

Sources:
[1] Formalizing Trust as a Computational Concept by Stephen Paul Marsh. Department of Computing Science and Mathematics University of Stirling