This is part one of a two part series on Zero Trust Architecture.
What is Zero Trust?
Zero Trust. The buzziest of buzzwords. Cybersecurity thought leaders and vendors alike love to talk about Zero Trust: why you should do it, how you should do it, and of course selling you all the gear and services to possibly-maybe-actually do it.
Unfortunately, the cybersecurity industry is attaching the term “Zero Trust” to almost everything and heralding it as the next great solution to our many security challenges. Policymakers are starting to embed Zero Trust in new mandates. Vendors and service providers are throwing the term around so loosely—claiming their software, hardware, and services are all “Zero Trust”—to the point where nobody seems to even agree on what “Zero Trust” is anymore. Customers have an overwhelming feeling they need to be doing something with Zero Trust in the name, but without clarity, they risk depleting precious security budgets and distracting their teams by adding more shiny new tools without a true plan.
What we’d like to do in this document is clarify Zero Trust as a term and provide practical information to help you determine a reasonable path forward for you and your own infrastructure. Rather than take the word of a vendor or thought leader on this, though, let’s see how NIST defines Zero Trust in NIST SP 800-207.
“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). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterprise-owned network boundary. Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource.”
If we keep reading, NIST goes further and states:
“ZT is not a single architecture but a set of guiding principles for workflow, system design and operations that can be used to improve the security posture of any classification or sensitivity level.”
And you thought Zero Trust had something to do with zero days and ransomware, didn’t you? Instead of thinking about “Zero Trust” as a solution you can purchase, think of it more as a mindset or a consideration when designing and building your security architectures. Look past the marketing and you’ll realize that “Zero Trust” ultimately comes down to two classic security creeds: “Never trust, always verify” and “Enforce least privilege”. At its core, Zero Trust represents the mental shift away from protecting systems and data using a traditional network perimeter by implicitly trusting internal assets and towards enforcing least privilege by continuously evaluating risk and securing each transaction regardless of an asset’s location or ownership. It strongly emphasizes consistent and continuous authentication and authorization for access to systems, services, and data, regardless of their location. That’s it. However, organizations who have paid lip service to these creeds—especially as services have migrated to the cloud—now find themselves caught off guard by the increased logging and enforcement required at the system and service level to support the new mindset.
Ok, so now we know what Zero Trust is, truthfully, it’s something we should’ve been doing from the start: securing all the things. Should we have ever assumed that securing the “perimeter” was good enough? Has that been true at all for the last decade? Implicitly trusting anything is generally not good security practice, though it’s often more convenient and, yes, more agile in supporting an organization. But, ensuring users and systems are who and what they say they are, making no assumptions regardless of their location, who owns the device, or even previous authentications are all good things.
So…do I have to Zero Trust?
It depends. For most commercial organizations, there aren’t specific laws or compliance standards that specifically require it today. The closest comes in the federal space through the President’s Executive Order 14028 on Improving the Nation’s Cybersecurity, which compels federal civilian agencies to “advance toward Zero Trust Architecture.” Even with this EO, there isn’t a prescribed checklist of solutions, configurations, or settings that agencies must implement for their environments to be deemed “Zero Trust”. Instead, it provides guidance on what could be included and mandates that agencies work with the Cybersecurity & Infrastructure Security Agency (CISA) to develop specific plans for their individual agencies to achieve a Zero Trust Architecture (mindset). In your own environments, more than likely, you already have elements of what would be considered Zero Trust. So, adopting a Zero Trust mindset won’t necessarily mean scrapping your entire current investment. It will be a journey, though, as opposed to an overnight transformation after buying a new tool or ten.
Read far down enough in the Executive Order and you’ll note that even the Order states the term “Zero Trust Architecture” means a security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. Again, it’s not a prescriptive list of actions or a single solution you can just buy, it is a mindset or model.
But does Zero Trust make me more secure?
So, we agree that the principles of never trusting, always verifying, and least privilege are generally good things. Does that mean Zero Trust is the ultimate end goal for all security programs? Will having attained Zero Trust Enlightenment™ mean that our organization is protected from all security attacks — past, present, and future? What do you think? :)
- Will it prevent all third-party supply chain attacks like the SolarWinds Orion breach?
At best, it might prevent some of these types of incidents, but more than likely it can at least help limit the impact.
- Does it eliminate the risk of my trusted identity and access management solution getting breached and used as a gateway into my network?
At best, it might prevent some of these types of incidents, but more than likely it can at least help limit the impact.
- Would it have prevented the latest zero day or ransomware attack?
At best, it might prevent some of these types of incidents, but more than likely it can at least help limit the impact.
See a theme? Zero Trust won’t eliminate or prevent every attack, risk, or vulnerability but if implemented with realistic expectations and as part of an overall security strategy that applies defense-in-depth and a layered approach, it can at best prevent some incidents and at least limit the damage of others.
NIST SP 800-27 agrees with this sentiment:
A Zero Trust Architecture (ZTA) is an enterprise cybersecurity architecture that is based on Zero Trust principles and designed to prevent data breaches and limit internal lateral movement.
It doesn’t guarantee that it will stop everything, but generally speaking, it should improve upon an organization’s overall security posture.
Zero Trust Controls
Remember, Zero Trust is a mindset and a model. It requires a collection of hardware, software, and services combined with secure policies, processes, and procedures to make happen. And just as with anything, the infrastructure you use to build a Zero Trust environment also needs to be secured itself. In other words, you shouldn’t implicitly trust your Zero Trust either. In fact, you should Zero Trust your Zero Trust.
What does that mean? It goes back to those classic security creeds: never trust, always verify and least privilege—applying those concepts to our Zero Trust systems, too, and doing the basics before chasing after the next shiny solution. That includes hardening your Zero Trust systems based on industry-recommended secure baselines, performing timely vulnerability and patch management, and conducting regular security tests and audits.
Consider the following examples:
- Can we trust a “next generation firewall” with fancy access control policies that performs deep packet inspection if it’s still using the default administrator password and hasn’t been patched in a year?
- If we enable mobile phone push notifications as second authentication factors for our users, can we trust they won’t blindly approve them if spammed hard enough? Would a user even notice if someone added an additional authentication factor on their behalf?
- Does a next-generation, signature-less, XDR threat hunting endpoint protection platform prevent an attack if nobody ever created and deployed a prevention and detection policy for it? What about preventing users from simply disabling and bypassing it?
That’s just a few of the many very real situations that can exist in environments built on “Zero Trust.” So called “Zero Trust platforms” might have been purchased and turned on, but without secure configurations and settings, they can quickly become vulnerabilities themselves. These platforms, whether on-prem or in the cloud, need to be secured just the same and incorporated into an overall security architecture and mindset that does more than simply give lip-service to the time-tested cybersecurity principles that we’ve known for so long.
This is especially true in the cloud-first, work-from-anywhere world. Implementing any modern computing environment—especially one with Zero Trust—will almost certainly require the use of third-party cloud-based solutions. The irony is that to implement Zero Trust, we must trust (on some level) a third party to, well, “Zero Trust” and secure all the things. Because of this, it is imperative that not only do we implement strong controls, we also perform proactive monitoring of these controls and the environments that they support.
Up Next
In Part Two of this series, we’ll look at why we should also implement a Zero Trust Monitoring program to verify our Zero Trust Controls, detect threats, perform in-depth forensic investigations, and meet compliance requirements.
References
- Executive Order 14028 on Improving the Nation’s Cybersecurity https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
- NIST SP 800-207: Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final
- M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
- CISA: Cloud Security Technical Reference Architecture https://www.cisa.gov/sites/default/files/publications/CISA%20Cloud%20Security%20Technical%20Reference%20Architecture_Version%201.pdf
