A Task-Based Approach to Privileged Access Management

Despite notable investments in Privileged Access Management (PAM) technologies, privileged accounts are still overexposed. Historically, PAM providers have focused on controlling access to accounts and their passwords, not on the activities an administrator needs to perform. The result is an excess of privileged accounts and privileged access control groups with standing privileges to the resources they are intended to secure. This proliferation of privileged accounts has an adverse effect on an organization’s attack surface. An overabundance of privileged accounts provides threat actors an abundance of opportunity for lateral movement attacks.

Gerrit Lansing, Field CTO at STEALTHbits Technologies

Gerrit Lansing, Field CTO at STEALTHbits Technologies, is an expert in the area of protecting privileged accounts. Having worked as both an Information Security Analyst as well as in product management for high-profile PAM solution providers, Gerrit has studied the issues around lateral movement attacks from all sides. 

Brilliance Security Magazine had the pleasure of meeting with Gerrit at this year’s RSA Conference to discuss his new role at STEALTHbits. It was, arguably, one of the most interesting and informative meetings we held at the conference. His enthusiasm for STEALTHbits’ new SbPAM product was contagious. 


Gerrit explained, “STEALTHbits has recently launched a new product called Stealthbits Privileged Activity Manager (SbPAM). 

“We think that privileged access ultimately needs to be about reducing and eliminating the attack surface. Rather than trying to apply a host of controls around a host of accounts that have always-on privilege, our focus is on eliminating the privileged account by looking at just-in-time elevation.

“For example, if I’m an Active Directory administrator today, in most enterprises, I’m going to have an administrator account. It’s not the account I use to log on to my workstation or check my email or browse the web, but it’s the account with which I connect to a domain controller. Even though that account has those privileges all the time, I might only use it for one hour a day. 

“And every time I use it, I’m leaving artifacts around that attackers might be able to steal to compromise that account. If I’m an organization that hasn’t adopted the best security practices around the domain administrator, I might allow an attacker to escalate from the workstation directly to the domain controller. At this point, the attacker would own the enterprise. 


If always-on, or standing privileged accounts, increase the attack surface, then the objective should be to do away with them. Gerrit explained, “When we think about privileged access management, we believe there’s a lot of wasted effort around securing administrator accounts that are used only one hour a day, one hour a week, one hour a month, whatever it might be. The idea is that if we can eliminate them, we achieve this objective called Zero Standing Privileges (ZSP). 

“ZSP is, again, the antithesis of the idea that I have these accounts that are always on; they always have this high level of privilege. Therefore, I have to protect them all the time, but they’re only used a small amount of time.” 

Just-in-time – Just-enough

SbPAM uses “Activity Tokens” to provide temporary permission and access that are auto-provisioned when needed and de-provisioned when not, reducing the attack surface and potential for lateral movement attacks.

Gerrit elaborated, “For us, the idea is that we want to remove the standing privileged accounts. We want to replace them with a just-in-time, or what we like to call “just-in-time – just-enough” privileged provisioning. It is an idea where instead of saying, I have an account that provides me domain administrator privileges and access to a thousand servers, what I have is a policy that states I may obtain access to any of these servers under certain conditions. There is no persistent identity that has access to all the servers all the time. 

“As an administrator, I have to say I want to “become” a particular privilege on a server. For example, I want to RDP to a windows server. When I request that privilege, and if the policy allows me to do that activity, an identity is created for me that is bound to just that activity. I have permission to log on to that server only. I’m allowed to interact with it through a session proxy, so we’re never exposing that password to the workstation, never exposing that session to the workstation. And then, when I’m done with whatever I needed to do on that server, we destroy that identity; it’s gone.” 

The Uber of Accounts

Gerrit says that if you, by way of analogy, compare the personal standing privileged account to your car, it is something you own. You have to maintain it and pay for it all the time. In a world where risk is the currency, these are expensive accounts to maintain. On the other hand, SbPAM creates these ephemeral task-based just-in-time – just-enough identities that are the Uber of accounts. You only have it when you need it. Once you’re done with it, you don’t have to worry about it anymore. They represent a much lower cost in terms of risk. 

Traditional PAM solutions grew from a need to address insider threats. The question was, from the beginning, do you know what your employees are doing with privileged accounts? It was about controlling passwords and managing privileges. 

Sometimes it is beneficial to stand back a little and ask why we do things the way we do them. In this case, that question has given rise to a more sensible way of looking at privileged access. Namely, don’t create accounts that have persistent privilege, just let your administrators do what they need to do when they need to do it, and not more. 

Steven Bowcut is an award-winning journalist covering cyber and physical security. He is an editor and writer for Brilliance Security Magazine as well as other security and non-security online publications. Follow and connect with Steve on Twitter, Instagram, and LinkedIn.