Zero-Trust — What The Hell Is It

Defining and Delivering A Successful Zero-Trust Initiative

Zero-Trust is how Information Security empowers the business to deliver its imperatives by seamlessly enabling the use of nearly any service from anywhere utilizing identity-centric security. What does key core capabilities does this statement include? Anything identity-based control or capability that you choose to include. There isn’t a wrong answer. Within this article, I will contextualize my definition of Zero-Trust and provide different perspectives on how a program of this type could impact teams within the organization while also providing ideas on measuring progress along the way.

Why Now?

Corporate networks are a lot like grocery stores. Once you’re inside, all options are easily visible and accessed. Just take what you want. The grocery store model even has some of our heightened checks and balances, like checking the signature on the credit card and requiring a PIN. If you are trying to buy alcohol, you have to validate your age and ID.

But what if the corporate security model was like exploring a dark cave with a flashlight, where you could only see the one thing you specifically need and nothing else? And what if we validated your identity and risk profile before we let you access that one thing? And what if we didn’t assume that just being in the cave gave you the rights to access that one thing? That is the basis for Zero-Trust.

Zero-trust at its core means assume breach and trust no one; validate all access all the time, with dynamically updating conditional access rules based on the user’s risk profile as well as the value profile of the asset(s) being accessed. Don’t assume anything and require proof for everything. If you meet the requirements for identity and entitlements, you can access that one thing, but accessing that one thing doesn’t give you access to anything else.

Zero-Trust is a model that inherently limits the scope and scale of any security incident because it is contained in the micro perimeter defined by your identity, and is constantly retested and revalidated, while also enabling the business.

Why Now

Traditional information security defenses have relied on our data being in well-defined places and following well-defined paths. We assume that once our user base has identified themselves positively, they are within the walls of our secure enclave and can move about as needed to access the things they are entitled to. And despite technological advances that have allowed us to challenge individuals for their identity and authorization at multiple locations throughout our environment — when accessing apps, when performing tasks like uploading or downloading data, etc. — most environments have used the concept of a “secure premise” to reduce disruptive burdens on users. Once you are in the door, that’s pretty much good enough unless you try to do something that has been deemed riskier than normal (such as elevating privileges for accessing really sensitive data).

In other words, we have guards posted at the gate, we check your ID, and then you are free to move about the enterprise, largely without getting hassled anymore. Sure, most organizations have restricted data zones with extra guards and extra processes like privilege elevation, but once you are in, you’re in.

This defensive model has been so ineffective that the entire Information Security industry shifted in the last few years to an “assume breach” stance, essentially admitting that EVEN with all of our controls and visibility to our secure enclave, a well-motivated and funded attacker can still get in…so the focus of “assume breach” really means, “we need to ramp up our detection and monitoring so that we can catch the invaders as quickly as possible and mitigate the damage.”

It’s no longer practical or efficient to try and route everyone back through the castle defenses. We need to be more agile and recognize efficiencies in how people work and what they need to access.

Until we know who you are and what you are entitled to do, you get access to nothing. You can see nothing. Being in a building, or coming from a particular location, or even having a set of credentials is not necessarily enough. We use conditional access to balance security and usability, so users don’t have to use MFA unless there is a substantial change in their security posture detected.

The Different Perspectives of Zero-Trust

Zero-Trust affects users in different ways. Is the user a consumer of Zero-Trust or a peer who will help implement the program? An effective Zero-program will identify each unique persona and identify and describe what Zero-Trust means from these differing perspectives.

The Associate

Zero-Trust from an associate’s perspective correlates to consistency, consistency in the process, and experience of accessing applications and services. There is no more figuring out if you need to use the VPN (Virtual Private Network) as an example. Privileged access becomes a step process rather than a logout, login, change identity process. Maybe you choose to include MFA (Multi-Factor Authentication) consolidation in your program if multiples exist in your environment. All of these choices are up to you to define.

If you access the same apps each day from the same location, Zero-Trust may correlate to relaxed multi-factor rules or elongated times between validations. With a non-exploitable password digitally tied to you and your computer, Zero-Trust may feel like a single sign-on to your laptop and seamless access to all of your business applications.

The Architect

Zero-Trust from an architect’s perspective equates to cloud-native, system assigned and managed identities that virtually eliminate exploitation while automatically managing identity lifecycles.

The Application Developer

Zero-Trust from an application developer’s perspective correlates to non-exploitable secrets, managed service identities, certificate-based identity, and authentication with auto-rotation and auto-expiry updating, no more shared secrets across applications and services. Each identity secret will be short-lived and private and assigned to the resource using it. Application teams will need to architect their applications to support privileged/admin application roles as a step-up role, not a permanently assigned. Tactically this evolves the application to utilize separate URI’s for admin roles to enable role step-up. Robust application logging becomes essential to facilitate risk-based behavioral learning and dynamic conditional access rules across the application ecosystem. Which users are taking which action and which action is privileged?

The Network Engineer

From a network perspective, Zero-Trust correlates to no more extending layer 3 to provide access to an application, a device, or a vendor. Zero-Trust looks like micro-segmented networks with zero lateral movements and a minimized blast radius providing access to one thing, not all things. It equates to micro-segmentation, not just at the subnet layer but also the interface layer, all accomplished dynamically.

The Information Security Professional

Zero-Trust from a security perspective correlates to constant and continuous assessment & verification. To continuously assess, visibility is required. To gain visibility, logging is needed, so Zero-Trust from a security perspective correlates to visibility, confidence, historical context, and baselines. The ability to verify against baselined behaviors before granting access to other devices and applications in the network.

The Endpoint Systems Engineer

Zero-Trust from an endpoint perspective could mean management of remote devices begins to occur through proxied services, not more extending layer 3 to endpoints. In general, zero-trust means that no matter where someone is and no matter what they are asking for, validate trust and provide them access to that one thing they wanted.

The Zero-Trust Progress Dashboard

Initiatives are all about the journey, and Zero-Trust is no different. The key question is, how will you know when you arrive? Set context; define what you are doing, define the scope, and then define what success looks like. To be effective, success must be metrics-driven, and the gathering of these metrics should be automated and scalable. Once defined, it is imperative to capture baseline and reoccurring snapshot metrics to provide an objective view of progress, which provides an objective view of an ever-improving security posture.

One way to establish metrics depicting progress is by capturing data about things you don’t want, access patterns you want to reduce or eliminate from your environment. For organizations migrating toward cloud-native, this could be reflected by a shrinking IaaS (Infrastructure As A Service) VM (Virtual Machine) footprint, eliminating traditional vulnerability and VM host take-over exploits.

Technology KPIs

• IaaS VM Footprint Historical Trend

From an application perspective, metrics could include progress towards the adoption of system-assigned/managed identities. These identities play a key role in Zero-Trust because the secrets are not shared, known, or available; they and their lifecycles are associated with the resource directly. Other ideas for metrics could include the ability to auto-rotate keys and secrets; application adoption of PIM/PAM (Privileged Identity & Privileged Access Management) into their authorization process.

AppDev KPIs

• Managed System Identities
• Auto-Rotating Keys/Secrets
• Use of x509
• PIM/PAM Step-Up Use
• Production Systems Access w/o Bastion Proxy

From a Network perspective, teams could measure traffic patterns, including traffic from user segments into production networks. This would be reduced to zero if one of your goals was to never extend layer 3 production beyond its own boundaries in a Zero-Trust world.

Network Engineer KPIs

• Traffic from VPN / User Segments into Production Network
• Traffic into Production Network from Non-Production Network

Looking at Zero-Trust from your infrastructure engineers' perspective, you could start to measure the use and subsequent reduction in RDP and SSH access, ensuring this access is bastioned or proxied or eliminated through post configuration automation tools.

Infrastructure Engineer KPIs

• Production Systems Access w/o Bastion Proxy
• Production Systems Build w/o Automation (Chef, Puppet, etc.)

As an Information Security professional, you want to migrate any internal application access use case towards a proxied MFA scenario, where access to the application is all you receive with any given request.

Information Security KPIs

• Private Applications Accessed w/o Application Proxy
• Production Systems Access w/o Bastion Proxy

What Does This Mean To Me

Most departments are interested in how they are impacted and how they can help with other initiatives occurring within the business. Take the extra step to share your perspective with your peer teams, so they know you’ve been thinking about what they do. What does what you’re doing mean to them? Help them understand:

• What happens automatically vs. what do I have to do myself?
• What does instrumenting my app look like to support Zero-Trust?
• What information do I need to gather?
• What does your consistent front door look like in a Zero-Trust world?
• How does my application get integrated into that?
• What is a managed device vs. an unmanaged device, and why do they make a difference in Zero-Trust?
• What do we allow an unmanaged device to do vs. a managed device?

What Next

As a program, Zero-Trust requires contextualization to ensure individual perspectives are understood and aligned, which assists with scoping and success. A clear depiction of what is and isn’t included in the scope of the program is key. Make your journey to Zero-Trust yours and make it successful by defining what success looks like and measuring that. Help teams understand what it means to them and help them understand what they need to do to help the organization be successful. Good luck on your journey.

P.S. — I want to thank my friend Josh Brown for his contribution to this story.