While the concept of zero-trust security has many IT organizations thinking in terms of identity, access, and cloud services, zero trust must run on a solid foundation.
We should start by talking about the goals of zero-trust security. Zero trust involves creating an environment where each access request is first scrutinized to determine whether it should be allowed. This “never trust, always verify” method of access is a bit like passport control when entering a country—the default answer is no, but if you pass the system of checks, you’re allowed in.
Organizations using zero trust typically focus on identity and access management solutions
for a federated and centralized means of identity that can provide users with access to a wide range of both on-premises and cloud-based resources. But simply focusing on this part of zero trust is much like solely thinking about building and staffing the passport control checkpoint without doing anything else.
What’s also needed is a way to establish and ensure underlying security controls are in place that define “who gets in.” There are three elements of zero trust that should be seen as foundational—they need to be in place and correctly implemented for zero trust to work. To keep with the passport control analogy, if you build and staff the checkpoint, but have no questions to ask the visitor nor standards of who can and can’t get it, it’s no security checkpoint at all.
So what three elements help establish the foundation of zero trust?
The concept of “never trust, always verify” is rooted in only allowing the right person to access the approved resources. It’s that “approved resources” that needs to be addressed. The principle of least privilege establishes that users should be granted the minimal amount of access necessary to do their job. Zero-trust security only accomplishes its intended goals when permissions assigned to resources are in a state of least privilege.
It’s necessary to have a means to both assess the current state of permissions and make needed changes centrally. Why centrally? For the same reason you don’t want seventeen zero- trust solutions in place—you need visibility and control over all access within your organization. This means a single solution to simplify the process. There’s a ton to cover on least privilege, but the basic process involves assessing what rights are assigned to each critical resource, comparing them to a defined minimal set of permissions, and then modifying the assignment to reflect the least privilege state. And repeat.
Least privilege isn’t a one-time effort; it’s an ongoing process of reviewing the current state of permissions to make certain that, as the organization’s needs evolve, access remains in a least privileged state to continually help ensure your zero trust practices help keep resources continuously secure. It’s necessary to monitor the environment for changes; after all, we all know that in almost every environment—whether on-prem or in the cloud—once a permissions change is made, no one else is ever made aware of it, and it’s forgotten.
Tactically speaking, you should look for a way to watch for permissions changes to data, applications, and systems you deem important. It’s also smart to have a system that either automatically addresses unsanctioned changes or notifies security teams to investigate.
The last piece of the puzzle is ensuring the security of the environment itself. In the same way you don’t want permissions modified in a manner that makes access insecure, you also don’t want the environment configuration to change in a way that makes it vulnerable to attack. Changes made to directory services, servers, and applications can have adverse impacts on the access zero trust assumes is locked down. Start with a configuration baseline that defines the critical parts of your environment as secure. Having configuration baselines is analogous to defining least privilege to permissions—it gives you a point of reference to know whether you are using a known state of security or not.
Monitor for changes from your baselines either by using built-in system and application auditing or via third-party solutions to augment your visibility. It will also be helpful to have a means of automatically remediating any unapproved changes to allow security teams time to investigate.
Ensuring the “Zero” in Zero Trust
Zero-trust security depends on the previous three factors. Once a zero-trust implementation has approved a request to access a resource, it assumes the account has only the needed access. But without addressing these foundational elements, there is no real ability for organizations to know for certain whether the environment exists in a known-secure state. By implementing least privilege and the ability to monitor and manage both permissions and environment changes, organizations can help ensure the trust given is as close to zero as possible.