Close this search box.

The 3 Principles of ‘Zero Trust’

The author

In my last post, I explained what the zero trust model is, its three core objectives, and how it can prepare you for even the most unpredictable ransomware attacks. Today, let’s explore the three principles that fulfill those objectives.

Inevitable Breaches

As I explained previously, the foundation of the zero trust model is the assumption that a future attack is not a matter of if, but when. More importantly, it assumes that no security is perfect, therefore an attack will breach your defenses eventually.

This first principle informs the other two. Instead of focusing entirely on prevention (though critically important in its own right), it calls for containment strategies so that one breach doesn’t compromise everything. This means adopting security strategies that include ransomware tabletop exercises, a reliable disaster recovery strategy, and a plan for isolating and removing ransomware before it can spread.

Explicit Verification

Because we assume a future breach, the model never assigns too much trust to any internal account, and instead doubles down on identity verification.

Explicit verification means authenticating each entity (a user, device, service, and so on) based on all data points available. For example, data points may include the account’s user ID, location data, a device’s BIOS UUID, a binary’s SHA-256 hash, etc. The more data points, the more explicit the verification.

By doing so, you regard all requests across your network (external and internal) as if coming from an uncontrolled network. This may seem excessive at first, but consider your situation once your defenses have been initially breached. A compromised internal account will have a much harder time compromising other entities if it’s under constant scrutiny.

This requires a solid identity management system. Microsoft provides an excellent (albeit Azure-centric) guide on this topic that centers on (a) strong authentication, (b) verification that any given entity’s access is compliant and typical, and (c) any access granted is in accordance with our third principle: the principle of least privilege.

The Principle of Least Privilege

To paraphrase the National Institute of Standards and Technology’s (NIST) definition, this principle requires building your cybersecurity architecture in a manner that results in granting each entity only the minimum resources and authorizations necessary for it to perform its function.

This may sound like a no-brainer or excessively strict (depending on your background). For example, if a normal everyday application user needs a basic level of database access to view data via their frontend, it may be routine to simply grant them a standard “out-of-the-box” account and move on—but this principle requires constant mindfulness. No matter the account and no matter how typically trusted they are, you should only ever give them the bare minimum needed to do their work.

Executing this principle daily means always erring on the side of failing to grant the user enough permissions. It’s better to need to grant additional permissions after the fact than to need to remove excessive permissions that may later threaten a system during a ransomware attack.

Now that we grasp zero trust’s three objectives and the three principles that accomplish them, we’ll next explore how to actually implement the model, which is primarily driven by microsegmentation.

Sign Up For Our Newsletter

Don’t worry, we hate spam too!

Get The Latest On Ransomware Right In Your Inbox

Sign Up To Receive Our Monthly Ransomware Newsletter
Don’t worry, we hate spam too

Is This Your Business?
Get In Touch

Contact Us To Sponsor Your Business Listing & Learn More About The Benfits.

Before You Go!
Sign up to stay up to date with everything ransomware

Sign Up To Receive Our Monthly Ransomware Newsletter
Don’t worry, we hate spam too

JUST RELEASED: The 2024 State of Ransomware Survey is in.


Share via
Copy link
Powered by Social Snap