Starting Down the Zero Trust Path

It’s a common quandary. In order to support the success of the business, IT needs to drive cloud adoption, enable work from anywhere, and integrate the explosion of connected devices. But at the same time, security teams need to defend a rapidly expanding attack surface against increasingly advanced threats. Defense gets more difficult when security teams don’t have the visibility they need to protect important assets.

Security shouldn’t impede IT and business velocity. But teams frequently don’t have a good way to defend it. This gap gives attackers an opportunity, and naturally, they’re exploiting it. Fortunately, there’s a way to close that gap: zero trust architecture. Unfortunately, it’s not a quick or easy fix, but large, complex organizations like the U.S. Department of Defense are committing to it because they view it as the best approach for standing up to persistent and sophisticated cyberattacks.

What Is Zero Trust?

It might be easier to start with what zero trust isn’t. Zero trust isn’t a product or solution you can buy and add to your security stack. It’s a mindset and security architecture focused on resource protection and the idea that trust should never be granted implicitly. In 2020, NIST released Special Publication 800-207, which offered the following definition:

Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned).

The principles of zero trust referenced in this definition are fairly straightforward, though they require a shift in mindset from traditional, perimeter-based security.

• Never trust, always verify – Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies. No user or device is trusted implicitly, even if it’s inside the firewall.
• Use least-privilege access – Limit user access with just-in-time and just-enough access (JIT/JEA), risk-based adaptive policies, and data protection to help secure both data and productivity. Users should have enough privileges to do their jobs in relevant applications, but no more. Overprivileged users are a hot target for malicious actors.
• Assume breach – Segment access to limit the blast radius. Verify end-to-end encryption, and use analytics to gain visibility, drive threat detection, and improve defenses. Perimeter defenses aren’t perfect, so it’s best to assume the attackers are already inside and do what you can to reveal and limit their movements.

Another thing zero trust never is: done. Zero trust is a path, not a destination. As your organization grows and changes, your particular implementation of zero trust should adapt to protect it.

The Basics of a Zero Trust Framework

While NIST SP 800-207 isn’t the only framework for zero trust, it’s the one that forms the basis for CISA’s Zero Trust Maturity Model and the Department of Defense’s Zero Trust Strategy and Reference Architecture. Let’s break down the seven tenets.

1. All data sources and computing services are considered resources. Networks are composed of many devices, applications, and other resources that may have access to enterprise-owned assets. Each of these resources should be treated as a potential risk.
2. All communication is secured, regardless of network location. Location alone doesn’t create trust. Access shouldn’t be granted automatically because a device is on enterprise network infrastructure. No matter where a request originates, it must meet the same security requirements.
3. Access to individual enterprise resources is granted on a per-session basis. Just because a device or user was trusted in a previous session doesn’t mean it should be inherently trusted for the next. Each session must be authenticated so that the user’s identity can be continuously validated.
4. Access to resources is determined by dynamic policy. Authorization decisions should take situational attributes and external sensors into account. This includes location, device, and real-time application context.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No device or asset receives implicit trust. Every request triggers a security posture assessment and all assets are continuously monitored to ensure they’re updated, safe, and uncompromised.
6. All resource authentication and authorization is dynamic and is strictly enforced before access is allowed. Trust is granted on an ongoing basis, factoring in a variety of elements before making an enforcement decision.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses this information to improve its security posture. Collecting and analyzing information on assets allows organizations to understand what “normal” is, making any deviations more obvious. This leads to better decision making and fewer risky approvals.

Protecting Your Pillars With Network Detection and Response

It can be helpful to think of zero trust as seven pillars that represent the resources you want to protect and key enabling capabilities. These pillars are users, devices, applications and workloads, data, network and environment, automation and orchestration, and visibility and analytics. Access to each of these pillars is governed by policies that must be enforced in real time based on the attributes and conditions of a transaction. This includes aspects like user location, device type and health, and real-time application context. Once again, no user or device is granted implicit trust. Access to resources is authorized conditionally and continually on a per-request basis.

So how do you make well-informed decisions? Zero trust requires visibility across each of the pillars so that policy enforcement decisions are driven by data. That’s where network detection and response (NDR) shines. NDR is the fastest path to revealing the insights needed to make real-time policy enforcement decisions across all of the zero trust pillars, because NDR solutions continuously monitor wire data like network packets and transactions as the source of truth. Wire data is superior to other sources because it reveals the attributes and conditions of a transaction in real time and can’t be changed or circumvented. This allows security teams to make accurate and timely decisions and organizations to move quickly and safely.

But all that real-time data is only useful if you can analyze it before it’s too late. Threat actors are now using automation to move more quickly than human security teams can respond. That’s why advanced analytics and automation capabilities are a cornerstone of zero trust. Integrating machine learning and automation into security tools and processes enables security teams to stop threats before they get out of hand.

Taking on zero trust can feel like any of half a dozen cliche metaphors (eating an elephant, building a plane while it’s in flight, a journey of a thousand miles, you get the idea). But focusing on a few key aspects can make the process seem more manageable. Real-time analytics powered by machine learning grant you the ability to see and understand what’s happening on your network, including user behavior and resource usage. Devices need to be regularly inspected, updated, and patched to maintain their health. Finally, access needs to be authorized on an ongoing basis, as informed by real-time analytics and context, including device security.

Getting Started With Zero Trust

Unless your organization was just founded yesterday, you probably won’t be able to implement a pure zero trust architecture right away. For nearly every enterprise, there will be a period where zero trust and perimeter-based workflows must coexist. During this transition, you should ensure that security solutions shared between the old approach and your zero trust implementation, like identity management, device management, and event logging solutions, are flexible enough to work in both architectures.

The first step to a successful zero trust migration is a complete inventory of assets, users (including non-human users, like service accounts), data flows, and business processes. You can’t protect what you don’t know about, which means identifying all shadow IT in your environment and understanding the current state of your architecture. You also need to know which users have special privileges. In many legacy systems, admin accounts with wide-ranging access are common, but concentrating this much power under one user can quickly lead to problems.

Once your inventories are complete, you can start identifying the first services or workflows to migrate. Part of this evaluation should be understanding the resources up- and downstream of the process and how they’ll be affected by the migration. It’s better to start small, with applications or processes that only a subset of the organization uses, rather than one vital to the entire enterprise.

Next, you’ll start choosing solutions for the processes you’ve identified. Some solutions work better for certain deployments than others, which is why a detailed understanding of your architecture is crucial. Each organization will have different criteria for selection, but there are a few common factors that everyone should consider.

• Does the solution require agents or other components to be installed? This can be problematic for organizations with bring your own device policies. Certain privacy regulations also prohibit agents from being installed on certain devices, like medical devices.
• Will the solution work for both on-premises and cloud resources? Some solutions are only helpful for monitoring traffic inside the traditional perimeter, while others specialize in traffic to and from the cloud. It’s important to find a solution or combination of solutions that enable you to seamlessly monitor all resources, no matter their location.
• Is the solution compatible with logs? Collecting and analyzing data is a foundational component of Zero Trust that allows for policies to be updated over time.
• Which applications, services, and protocols does the solution support? Some offer broad support, while others have a narrower focus.
• Will this solution require behavior changes? Adding extra steps to a workflow may be unavoidable, but it’s worth considering how much change will be required. Introducing too much complexity can lead to end user resistance.

Once solutions are in place, you should monitor new workflows to ensure the policies are effective and to establish a baseline of normal behavior. Be prepared to modify policies over time as you learn what works and what doesn’t. After the initial deployment, it’s time to expand. As you add new processes, you may find that policies from earlier phases need to be adjusted. That’s why zero trust is never “done.” Welcome to the path!