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.
