Racing Towards a Zero Trust Access Control Model

July 17, 2017

Drag racing. From 0 to 60 in less than 2 seconds. It’s all about controlled speed. Success depends on maximizing power, minimizing weight and drag, and no obstacles in the way!

In IT when the pressure’s on, admins also want to avoid obstacles. They need to get the job done fast whether it’s an OS refresh, new corporate apps rolling out, or fixing a network outage. For this, they too need power (accounts like “root” or “administrator” with superuser rights).

SO, just give your admins full rights all the time. Minimize obstacles, bureaucracy, red tape, friction. Jobs get DONE super fast. Happy days!


Not a good idea. Enabling fully-entitled superuser accounts for IT use grants those same entitlements to any cyberattacker able to compromise said accounts. On the flip side, disabling them and throttling IT admin rights to zero -- while shrinking your attack surface to a bare minimum -- cripples IT’s ability to do their job.

Clearly, both extremes of that access control spectrum are impractical. So, where’s the balance?

What we advocate at Centrify (and enable through our Infrastructure Services) is striving towards a state of zero trust through Just Enough Privilege, granted Just In Time. Central to this theme is migrating to a role-based access control (RBAC) model that's dynamic, using short-lived instead or long-lived privileges.

You start with a low privilege static baseline. Additional rights (via roles) are available upon request, and their issuance can be governed through a workflow-based approval process. It's critical that both the request mechanism and the scope of roles available for a request are pervasive -- across all platforms and everywhere privilege is controlled. This ensures complete coverage with the option of enforcing approval requests for vaulted accounts (password check out and session initiation), server login, and on privilege elevation. Similarly, a role can be scoped to grant access rights on a single platform or cross-platform. E.g., for an administrator responsible for managing web servers enterprise-wide, a single "Web Admin" role might include the necessary rights to manage IIS on Windows, and http on Linux and UNIX both on-premises and in the cloud.

So with Just Enough Privilege, Just In Time, the entitlement landscape for a user expands and contracts dynamically as business requirements demand.


It starts off low when IT admins log in with their individual (i.e., fully-accountable) low-privileged identity. It grows when they're granted elevated rights to perform a specific task. It shrinks back down when the task is complete. These elevated rights are aligned to the task (i.e., just enough, not full "root" privileges). They can also be time-bound (e.g., 30 minutes) and when they expire, they can be automatically revoked and vaulted passwords cycled for good measure.

Let’s change perspective to that of the attacker. If an IT admin’s account is compromised, the attacker can't do much at all with such a low level of privilege out of the gate. Elevating privilege could involve an approver and ideally, a 2nd factor of authentication (based on static policy such as location, or a behavioral anomaly detected by the analytics engine). Human attackers, malware, and bots are stopped in their tracks. This elevation model also thwarts Pass-the-Hash; there's no admin-level token/hash in memory to exploit. Security tokens are adjusted only during elevation.

The goal is to break the attack chain.

What the attacker does next depends on whether they’re “casual” or “professional” and is where a trivial understanding of hacker mentality and motivation helps. A casual/lone hacker is more likely to take this as a personal challenge to their skills and do whatever it takes to circumvent. Adjusting on the fly like this often leads to more risky attempts, mistakes, and alerts. That’s good for IT.


Professional attackers have a wealth (literally) of the best people, tools, and methods. One-upping them, blocking every vulnerability and thwarting every attack vector can be a very expensive chess game. A major objective for us, then, is to disrupt their business and cause them sufficient hassle to simply move on.

Let’s be clear - they are businesses in their own right and do this for a living. They organize into groups with well-defined attack plans for big potential outcomes. Attacks are researched, managed, and executed as projects with defined roles and responsibilities. They might have spent months socially-engineering employees, establishing a foothold on a corporate workstation, and surveilling the network figuring out an attack plan. Putting an approval step or a 2nd factor of authentication in their way (at multiple layers) puts a spanner in the works and can easily set them back weeks or months. Time is money. Move on.

In summary: lower the risk and potential damage of security breaches. Grant users just the privilege they need to do their job, prompt for MFA and implement a just-in-time model where:

  • Elevated access can be governed by a streamlined self-service request/approval mechanism
  • Multi-factor authentication and behavioral analytics at multiple layers increase identity assurance
  • Privilege is temporary, time-bound and automatically revoked

Oh and let's not forget - this model protects you from the insider threat too, whether malicious or accidental.

Please pop over to our website to learn more about Centrify Privileged Access Security.

This is written by the individual author in his/her personal capacity, and the opinions, views and/or thoughts expressed herein are solely the author’s own. They are not intended to and may not necessarily reflect the official policy or position, or the opinions or views of ThycoticCentrify or its affiliates, employees, or any other group or individual.