John Kindervag, the creator of Zero Trust, is the newest member of Cerby's Advisory Board. In this role, John helps Cerby communicate the essential elements of a Zero Trust strategy and how Zero Trust can be applied to applications that lack support security standards like SAML and SCIM.

In this part one of a series examining Zero Trust in more detail, John gives a high-level view of the first step in implementing Zero Trust architecture—defining the Protect Surface. 

Moving towards Zero Trust

Cybersecurity is a top priority for most companies. Moving towards a Zero Trust cybersecurity model has become an even greater priority for many organizations worldwide. The key driver pushing Zero Trust adoption was the May 2021 Presidential Executive Order, “Executive Order on Improving the Nation’s Cybersecurity,” which stated, “The Federal Government must adopt security best practices; advance toward Zero Trust Architecture...” 

This EO has drastically changed the Zero Trust adoption curve. However, some confusion remains about Zero Trust and how to deploy it. In 2021, I was honored by an appointment to serve on the President’s Nation Security Telecommunications Advisory Committee (NSTAC ) Subcommittee on Zero Trust and Trusted Identity Management. We delivered the final report to President Biden on February 23, 2022. 

In Section 2.1.1, the report documented the “Five-Step Process for Zero Trust Implementation” I first developed while at Forrester Research. This model is widely adopted and successfully proven. The Five-Step Process is the easiest way for organizations to adopt and implement Zero Trust environments. 

5 steps of implementing a zero trust strategy

The Five-Step Process for Zero Trust Implementation
Source: NSTAC Report

Step One: Zero in on the Protect Surface

Throughout the history of what we now call cybersecurity, the focus has been on technology and products. The task of securing IT systems fell to technologists who were, unsurprisingly, very product focused. So problem-solving became all about buying technology and deciding what to do with it after it was acquired. 

Sadly, this technology and product-focused mentality continue today. I often get calls from individuals starting a Zero Trust journey. They tell me they’ve just purchased gadget X or product Y and want to know where to put it to become “Zero Trusty.” My first question is, “What are you trying to protect?” There is often silence at the other end of the call.

The first step in implementing a Zero Trust strategy is identifying the data or assets you are trying to defend and categorizing each asset as a Protect Surface.

What is a Protect Surface?

Typically, our industry is hyper-focused on the attack surface, asking, “Where are attacks coming from?” The problem is that the attack surface is undefinable. It is equal to the entire internet and everything connected to it. Plus, the attack surface is like the universe; it constantly expands. Therefore “attack surface management” is futile. It is unmanageable (like the apps we'll discuss later).

The way to solve this problem is to invert it. That’s why I created the concept of the Protect Surface. The Protect Surface is the inversion of the attack surface. We ask the question: “What needs protecting?” This shrinks the attack surface down orders of magnitude to something easily known. 

What is in a Protect Surface?

Cybersecurity is a massive problem. The way complex problems are solved is to break them down into multiple smaller problems. This is the value of the Protect Surface. You are trying to solve only some of your cyber challenges. You can focus on a single data set or asset class and efficiently put them into a Zero Trust environment.

To help organizations understand what goes into an individual Protect Surface, I created an easily remembered acronym, DAAS. DAAS stands for:

  • Data: This is the sensitive data your organization collects or processes that would get you in trouble if stolen or misused. Examples include credit card information, personally identifiable information, personal health information, and intellectual property. 
  • Applications: These are the applications that use sensitive information in some way. Finding and understanding these applications can be challenging as so many are now web-based, and controls struggle to understand one application from another.
  • Assets: An asset is almost anything that exists in your environment. Traditionally we considered things like servers and laptops, but an increasing number of assets fall under the Internet of Things (IoT) category. These are often unmanaged assets that have limited security controls natively available. OT devices such as HMIs, PLCs, other SCADA-type technologies, and medical devices would all be considered assets.
  • Services: Every organization uses technology delivered as services. These services provide raw functionality that keeps systems up and running. The most common services include DNS, DHCP, and NTP. Unfortunately, these services are unprotected in many organizations.

Build Zero Trust one Protect Surface at a time

You don’t boil the ocean all at once; it’s done a teaspoon at a time. This is the same way we build Zero Trust environments: Protect Surface is the teaspoon. (Apologies to Neo in the Matrix).

Zero Trust is:

  • Incremental - One Protect Surface at a time.

  • Iterative - One Protect Surface after another.

  • Non-Disruptive - Mistakes are limited within a single Protect Surface.

The top mistake teams make is trying to do too much at once. You can’t flip a switch to Zero Trust your entire enterprise, nor should you. Don’t try and protect everything using Zero Trust principles. Frederick the Great once said, “He who defends everything defends nothing.” This axiom resonates on both the physical and cyber battlefields.

Manage the unmanageable

I have traditionally found that applications are the most straightforward DAAS elements to discover and place into a Protect Surface. Until recently, most applications had a defined protocol that could be decoded and understood. These protocols could become the basis for policy.

But the massive movement from client-server to web-based and SaaS in the last three years made this much more difficult. All applications looked the same at the HTTP/HTTPS protocol level. It was impossible to distinguish one web app from another. Eventually, we developed technologies that could look deep into the packet and generate specific application identities or signatures.

Today there is a new class of applications colloquially known as Unmanageable Applications. These modern apps range from operational technology to social media applications. Unmanageable applications are defined by their lack of support for common identity and security standards (SAML and SCIM), making them difficult to manage and protect. 

These apps could fall into the Shadow IT category, but more often than not, it's much more complex than that. All companies try to control application usage on their corporate-owned devices, but this has always been challenging. Many years ago, I was involved in deploying and managing endpoint security at a global company. Employees could use 127 “approved” applications, and all others would be blocked. One day a ticket came in with a request to allow “Hallmark Greeting Card Creator.” That request was, of course, denied. It turned out that the user of this program was also the executive assistant of the company's president. It did not take long before “Hallmark Greeting Card Creator” made it onto the “approved” list. 

The point is that we can’t control which applications our users utilize anymore. But that doesn't mean we shouldn't be managing access to them with our identity providers. The challenge is that their lack of support for standards like SAML and SCIM makes it nearly impossible to do so. 

I joined Cerby because they are the only platform that brings these applications into the Zero Trust world by allowing us to create a Protect Surface around them. By doing so, Cerby is making the unmanageable easily manageable and secure.

Stay tuned for Part 2 of John Kindervag's Zero Trust series for Cerby, where he talks about steps two and three in creating a Zero Trust environment—mapping transaction flows and defining your architecture.