A critical review of PAM capabilities from a customer standpoint
Ihave recently had the opportunity to read through a much anticipated review of products in the PAM sector. The said review is conducted by a storied and credible research/publisher. This report would typically be behind a subscription paywall, but the vendors featured were eager to get the good word out, which meant that practitioners like me could view and digest it.
The idea for this article has been brewing for a while, but the PAM product reviews, rationale and structure prompted me to put pen to paper, so to say. It brought back to me a growing sense of unease that i have felt about product ratings, which in my view is part of the problem from a customer perspective, rather than a solution. I say this from the hindsight of being on both sides i.e; having quoted these ratings to clients as a “consultant” and having consumed some of the fine print in their true living sense as a “customer”.
Privileged Access Management as a discipline has evolved by leaps and bounds over the past decade. On-premise infrastructure has moved from in-house data centres to bare metal outsourced ones, to PaaS providers. Traditional client server applications have been progressively replaced by a wide variety of SaaS or hybrid forms of hosting and delivery. Meanwhile, the disciplines of change and configuration management have had to contend with continuous integration and delivery pipelines. Engineers have been empowered by cloud computing platforms like AWS and Microsoft Azure Cloud and GCP. PAM, traditionally a domain that has covered privileged access of the human and non-human personas has seen a diversion of paths for the latter. This is driven by an explosion in credentials, driven by factory scale generation of APIs, integrations and the ease with which ephemeral infrastructure and application workloads are being created in continuous delivery and integration environments.
So much has changed, and yet so much remains the same. At least, if we were to go by this much awaited vendor assessment. Let us put the non-human element aside for the time being and forgive the report for some lazy generalisations on this count. The issue that i have with the report is that some of the more pertinent trends on the human PAM side were pushed into the “Optional” category. Now, i may be totally out of sync with the industry view on this, but for the record, wanted to add some perspective, not on what was missed by the report, but what i think is more, or less, important from a PAM perspective given the context covered so far. Here goes:
Privileged Account Lifecycle Management is the holy grail
As they say, start with the easy bit and then brace for the uphill climb. Privileged Account Lifecycle Management is much easier to track today than it was, say 5–10 years ago. If you using Microsoft Azure (90%+?), have healthy conditional access policies in place, other layered controls and are using some form of continuous authentication and verification (CAEP, for example), you can probably reduce the exposure to a reasonable level. It helps if you dump the shared account model (except some glorious antiquated exceptions) to the dustbin of history, where it belongs! This goes back to my point on focusing on fundamentals. Traditionally, PAM solutions were not built to manage lifecycle of access, as it was assumed that robust Identity Governance processes could do the job. However, the usage of generic accounts and accounts not linked to authoritative sources have made this situation messy. For an IAM Manager, ensuring effective governance and lifecycle of Privileged accounts is a priority beyond everything else. If the sieve does not hold up, everything that you pour into it will bleed.
Just in Time is Just in time — Period
This is arguably the biggest challenge our deft community of PAM Managers have at their hands. As is usual, the security teams are trying to reign in the horses after they have bolted the stable. Cloud computing has been around for a while now, practices have stabilised for the good or for the worse, flexibility is cherished, pipelines run critical business processes for an enterprise, so disruption is not an option. So, lets see how the conversation about imposing JIT to run Terraform/Sentinel governed pipelines will work….hmmm… Badly? It is one thing to say, that something is absolutely critical, and it another thing to deliver it. I know this, again, having been at both ends. But, there are principles. My advice would be ditch the “land and expand” conversation and go for the target. Understand your engineering teams’ ways of working. Is there is a tweak required for the access models to segregate environments adequately, think about inter-planar lateral movement, think about the use cases (e.g; console access, command line, pipeline, remote proxy or other services). It will avoid the long drawn testing cycles, the iterations across various user cases. Slow creep is not an option, unless you want to lose credibility with your Cloud Infrastructure team. Just in time equals zero standing privileges for the most part, no ifs no buts. If you split this problem into component parts, , example, start with credential management, then booked time intervals and then elevate to JIT, what you will end up is a ketchup of your own making.
Policy and Persona Based Access Control is a pre-requisite for JIT
If you want to make your life easier, dear PAM managers, please do not rush into JIT until you have a proper Policy and Persona based access control in place. In my previous stint, we tried to hard code this by not using any external tool-sets and the results were robust, but still less than optimal. There is always the risk, that you sacrifice security at the altar of established (poor!) engineering practices, and vice versa. But going into JIT with the built up knowledge of access controls layers, working practices and personas will save you a world of trouble. You will also sound more empathetic to your users (read: buy-in). The model that you inherit from the IGA processes is likely to be an RBAC based one. For cloud infrastructure, this basic model has to be iterated upon and translated into what is essentially looks like a PBAC model wraparound (or ABAC, choose your poison, after all it would be scary if attributes do not drive policy). CIEM solutions can help model this, specifically with PaaS, at scale. Which means…..roll the drums…..CIEM solutions or like are not optional for at scale use cases! This effort, irrespective of whether you invest in a product or not, is a required investment to get to JIT.
Credential Management — Oh the good old days!
Terminology is important. “Must Have”? How about “Basic”? Those who have read the report will know my reference here. If there is someone out there still running an IAM house that is using shared credentials which are not vaulted, Credential Management is least of their problems. PAM programmes of the past spent 80% of their time on getting credentials vaulted. The remaining 20% was a hail mary pass to get as much of distance with session management. Over time, the complicated session management features would be shunned or rarely used. Today, this approach is no longer sufficient. The conversation should be — why are you vaulting human credentials and if so, how can these credentials be accessed? Do i have to go through strong authentication? Will there be a context check? Is it mapped to a valid approved service ticket? Is the access timed? What are the fraud triggers involved in this process? Can new clusters be created without vaulting root credentials? What is the fall back procedure if the vault is unavailable? Which is, it is less about the fact that you are vaulting the credentials, and it is everything that sits around such a request i.e; Governance. I would not go so far as to say that we must reduce the surface for vaulted credentials and generate discrete credentials by policy and demand, but i would not be surprised if that is the general direction that the human bit is headed towards.
PAM Discovery — Yeah, Sure!
Back in the day, when CMDB was the much maligned under performing asset, back in the day when networks were flat and all “Corporate” and where vulnerability management systems ran scans that were less unobtrusive, but ineffective where common identity threat detection metrics were concerned, it made a lot of sense for PAM tools to build discovery capabilities. Now, if you are a PAM Manager that does not already have a lot on their plate and want to open a new front with your colleagues in your SOC, VM and Service Management teams, please go ahead and fight that battle. I suspect, most of us will not want to perish on that lonesome hill. PAM systems, today are a net consumer from systems of record and not the initiator of discovery activities. CMDB data quality is improving (shh….don’t quote me here!), efforts have gone into segmentation of networks to limit attack surfaces, in certain PaaS environments, infrastructure are increasingly non-domain joined and/or ephemeral. PAM managers should use the sources of record and and existing investments to pull in data instead of seeing Discovery as the nail and their favourite PAM tool as the hammer.
Agentless vs Agentful — Cat vs Rat, do the colours matter?
Deng Xiaoping said it best. The colours do not matter as long it gets the job done. Talking about session management and orchestration, the question as to whether sessions should be facilitated Agentless or Agentful, has occupied some space. With recent developments (Microsoft/Crowdstrike), the appetite for updates touching any of the lower layers of the OSI model is close to zero among core computing infrastructure providers. The remote possibility of an agent not behaving properly following a patch Tuesday and the accompanying credibility crisis, is not what a PAM programme would want to invite on themselves. And agents for what? Your engineers are probably spinning up sandboxes by the dozen on your IaaS and PaaS environments and by the time these get tested and deployed to development it is already too late. Change Advisory Board, did you say? Well, good luck getting all of this featured on the agenda, good luck being invited, and good luck being heard. So, the insistence on Agentful in the said report was a queer throwback to the time when regular patch updates did not have so much riding on them, zero day vulnerabilities were few and far between and there was an assumed better sense of control on what infrastructure was delivered into the corporate IT environment. Agent based architectures, whether this be delivered through an Application package like MSI or through API calls or cron jobs, are up for increased scrutiny as these tend to be a weak link. On the other hand, and specifically within PaaS environments, agentless methods are less intrusive and as secure, when backed with other layered controls (like Microsoft Defender) at the device level, CAS and ZTNA at the user level.
To summarise, i think PAM programmes are due a reset and unfortunately, the report by the said storied entity does not add much to the conversation at this time. You may have noticed that i have avoided names to not distract from the content. Smart customers with a tested PAM strategy think requirements first and vendor capabilities second, and not the other way around.
Finally, while this is a critique, i must underline my respect for the said entity behind the report and their work in building awareness about IAM across the CIO/CXO community. I am an avid consumer and follower and this will hopefully continue in the future as well.
The views expressed here are based on the authors own experience and knowledge and does not represent artefacts, output or perspectives of any organisation. The text has been wholly human generated.