All the Kings Men: Building the New Zero Trust Enterprise

What Zero Trust Is

It was 2010 when John Kindervag, then an analyst with Forrester Researchfirst wrote about the idea of a zero trust security framework in which the idea of a network edge or perimeter was no longer the front lines of the cyber battlefield for an organization.

Rather, that instead of an organization implicitly trusting anything inside its perimeter as being “friendly fire,” nothing inside or outside the perimeter should be trusted and that both users and devices should be authenticated, authorized, and determined based on who, what, when, and even where a user or device is from and what it’s trying to access should be scrutinized using IAM, orchestration, analytics, encryption, scoring, and filesystem permissions.

The concept of zero trust security effectively erases the castle approach to security architecture in that the “castle has left the moat” with data now being everywhere, no longer behind the defenses of a network perimeter but instead extends to mobile devices, cloud drives, cloud servers and that the threat to those assets are everywhere, everyone, and everything.

This approach to cybersecurity implements an inside-out mentality of protecting the organization’s most critical assets where security is designed as “micro-perimeters” around the assets being protected and that the “bad guy” is not trying to be kept out of the perimeter, but is already inside.

Zero trust security is achieved through a litany of different security solutions with identity access management and micro-segmentation at the very heart.

Implementing Zero Trust in 5 steps

The implementation of zero trust in a pre-existing enterprise is a challenge but not impossible. Unfortunately, it isn’t as simple as throwing money at the problem and implementing a stack of security solutions that give you “zero trust.” It does, of course, involve a healthy amount of budgeting, but it also involves a re-architecture of the network and understanding of “who needs access to and from what” and “what needs access from and to where.”

Step 1: Create an asset catalogue that includes devices and applications, making sure to document data transmission paths (ports and protocols) that the applications talk over.

Step 2: Locate your data. What is it you are trying to protect? Where is it? Is it on a shared folder on a file server or on a NetApp server? Who needs access to it? Where are they going to access it from?

“You can’t protect something when you don’t know where that something is or what that something is.”

Step 3: Implement micro-segmentation. Segment the network up into different virtual local area networks (VLANs), not just moving devices based on their role to their own unique subnet, but also implementing VLAN Access Control Lists (VACLs) between those subnets or default route them directly to a firewall responsible for internal core traffic filtering. Servers should be in their own VLAN, users should be in their own VLAN, VOIP equipment in its own VLAN, and so-on. An ALLOW-ALL rule should not be set between the VL