You might once have been told not to trust anyone over 30. Now, if you help manage IT infrastructure or applications, you should not trust anyone in general.

That’s because we’re now living in the age of zero-trust security. Zero-trust security (sometimes also called trustless security) is a new paradigm that can help improve your security posture.

Keep reading for a definition of zero-trust security, followed by tips on how to implement it.

What is zero-trust security?

Put simply, zero-trust security means that your security strategy is to trust no one and nothing by default. Consequently, you only give people or systems access to resources once you have confirmed that you can trust them and they should be able to access those resources.

Thus, zero-trust security doesn’t mean that you never trust anyone. The term can be somewhat misleading in this respect. It means instead that your policy is not to trust anyone by default.

You could think of zero-trust security as an extreme form of, or at least a variant upon, the principle of least privilege. The latter term refers to the strategy of assigning each user within an IT environment the minimal level of access necessary to perform his or her defined role. Adopting the zero-trust paradigm can help you to achieve this goal and avoid giving users more access privileges than they require.

The term zero-trust security was coined in 2010, but the concept has become widespread within the IT security community only in the past couple of years.

Why zero-trust security matters

At first glance, it can be easy to dismiss zero-trust security as just another buzzword. After all, hasn’t the goal of any right-minded IT admin always been to avoid configuring resources in such a way that anyone can access them?

To a degree (especially insofar as public-facing or external network resources are concerned), this has been the case.

However, what makes the zero-trust security movement significant is that it emphasizes the importance of not trusting and not giving access privileges to everyone. That includes not just users or services that originate externally on the wilds of the Internet, but also internal users.

It’s the zero-trust policy toward known, internal, behind-the-firewall resources that makes zero-trust security a big deal. In the past, you would typically have assumed that anyone already on your network could be trusted, and that your firewall would effectively keep the bad guys out of the network.

Today, however, that approach no longer works. You can no longer hide behind your firewall, because perimeter-based security has ceased to work in the age of hybrid clouds, Bring-Your-Own-Device policies and dynamically configured network endpoints.

Nor can you assume that anyone who seems to be a network insider can be trusted. Some of the worst security attacks are initiated by insiders.

In short, then, zero-trust security is a way of evolving your security strategy to address the challenges of cloud-native computing.

Implementing zero-trust security

Zero-trust security is a philosophy, not a specific practice. The way you go about achieving zero-trust security will vary widely depending on which specific technologies you use, the architecture of your infrastructure, and so on.

However, following are some examples of simple steps you might take to enforce zero-trust security within your environment. These examples address a containerized environment in particular:

  • Don’t run containers as root. You probably already know that you should never run a container as root. But if you want to embrace zero-trust security, root-user containers are an absolute no-no.
  • Run each container as its own user. Consider running each container as a distinct (non-root) user. This strategy helps to isolate containers from each other and ensure that no two containers can trust one another because of a shared user account.
  • Configure data volumes so that no one can access them by default. You could do this by assigning group ownership of the volume to a GID to which no users belong by default. Then, when you know that a user is trusted, you can add that user to the group.
  • If you use Kubernetes, configure your pod security policies to disallow as many behaviors and actions as possible by default. Update your policy files to create exceptions only when you are sure it is secure to do so.

The bottom line: Zero-trust is not just another buzzword. It’s a valuable strategy for rethinking and reconfiguring the way you keep systems secure. Indeed, in today’s ultra-dynamic, perimeter-less world, zero-trust security is the only security posture that mitigates risks by default.

← Back to All Posts Next Post →