I gave a virtual presentation last week at the Kuppinger Cole CSLS event. My title was “Old Dog New Trick: Musings on Enterprise Identity Governance in a Cloud-First Zero Trust Ecosystem”. The thesis of the session was how to apply old-world identity governance thinking to solve new-world security objectives. I wanted to pull out a couple of the key points here to hopefully, promote a little wider thinking and debate.
Cloud-first & Zero Trust are key enterprise security topics, so the question posed by the session was exactly how does governance & provisioning support them both and what does that look like in deployment?
As I’ve done before in the past, I offered three specific things that provisioning and governance can do to support a Zero Trust approach: implementing true least privilege, building a policy-based lifecycle and embracing something I’ll explain here as temporal entitlement. In the rest of this article, I’ll explain all three and let’s open the debate.
Implementing True Least Privilege
I think most people these days understand what least privilege means. To me, it means only giving people the access they need to get the job done. The question is how do you apply this to a cloud-first ecosystem?
Inventory & Visibility
And the answer starts with inventory and visibility. Here, the old mantra that “you can’t manage what you can’t see” has never been truer. If you don’t know who has access to what and why they have it least privilege has no chance. So, before you can adopt Zero Trust for cloud, you must deliver on what are basically old-dog security and governance tricks. It means you must aggressively manage a full inventory of all cloud apps and access. Of course, this must cover all AWS, GCP and Azure resources, plus your complete DevOps lifecycle footprint.
Least Access
Least privilege for cloud also means Least Access. By that I mean, thinking differently about providing access in the first place. We’re often all focused on providing the most access we can, but we need to flip that and think least or minimum access instead.
Let me give you a practical example of what I mean. How many of you, when you see cloud access in an access review, think revoke by default? Or when you’re delivering role mining and “birthright access” are you really focusing on the least amount of access possible? So, the closest peer-grouping, the highest match criteria, and the smallest access profile.
Because to really support Zero Trust provisioning and lifecycle management, it means giving out less entitlement by default. Giving out less by default requires no new technology capability being delivered by some magical new cloud services either, it’s a simple philosophy, delivered by word of mouth if needs be.
Self-service @ Center
And giving out less by default only make sense when it’s supported by first-class self-service and delegation. You must deliver intelligent self-service to your users that includes effective delegation and highly automated provisioning and approvals. If you focus on understanding patterns of access, instead of delivering them directly via birth-right provisioning (by default), you’re getting there. It requires making the self-service capabilities you deliver easy to use and available “on request”, or maybe “just-in-time”, something I’ll come back to in a moment.
I’ll say it again, none of the things I’ve mentioned here so far are rocket science or anything new. Good inventory, minimal birthright access and delivering self-service are all achievable with pretty much any old provisioning and governance tooling. Or maybe you just need the right delivery partner, with the right philosophy in mind.
Building a Policy-based Lifecycle
The second pillar for supporting cloud-first Zero Trust is a policy-based lifecycle. This one’s important for Zero Trust, but it really is something much bigger that crosses over the access management, provisioning, and privilege management boundaries.
Governance Models
Building a policy-based lifecycle starts with putting well known and well understood Governance models at the center of the access lifecycle. Yes, that often does mean Role Based Access Control, so building roles and maintaining their lifecycle, but it also means building other models too. Models that capture the policy of the “desired state” for access and entitlement usage.
Sometimes governance models are simple things like ownership and approval definitions that overlay responsibility and stewardship for all the things we care about. Sometimes they are manual or automated change control policies that carry out known actions when Identity, attribute and resource states change.
Or maybe sometimes that governance model is as simple as a clean set of requestable units of access – so self-service available to the right people to request the right access at the right time. These are all the models that drive a governance-based approach to identity and ultimately to best support a Zero Trust approach. We must commit to model and govern these policies prior to usage if we plan to minimize the risk.
Embedded Controls
If a policy-based lifecycle means developing core governance models, it also means understanding and implementing embedded controls. We must take the checks and balances of business best practice and embed them in the request and provisioning flow.
Again, no new trick here. Embedded controls are what we’ve been talking about in identity for 15 years now. But it’s still our job as identity specialist and IAM thinkers, to “evangelize” and to make sure that embedded controls like preventive Separation of Duty (SoD) are absolutely required for cloud-first zero trust.
Attributes Driving Access
Lastly, a policy-based lifecycle means understanding exactly when and where attributes drive the access. I know this sounds a bit esoteric but when I say Attributes Drive the Access I mean when any system makes an access policy decision based on identity data, or any verifiable credential, controls need to be in place to govern it.
To explain what I mean let me provide an example. When an AWS access policy picks up an attribute like manager from an Identity Provider (IdP) and embeds it in an S3 access control policy, the attribute drives the access. How do you run govern that? How do you define and implement the controls and where is the governance? Who manages the Attribute providence, are these attributes accurate and up to date and who verified them? Does the IdP know that this attribute is driving access down-stream, and are these dependencies being reviewed and audited?
These are very important questions. So, I foresee a cloud-first Zero Trust future where the providence and assurance of identity attributes and runtime access policies will be a key governance control. As we edge ever closer to a world of verifiable credentials and self-sovereign distributed identity, composing, delivering, and validating verifiable credentials will be a key focus for the access governance of the future.
Temporal Entitlement
And so, onto the third and final element of Identity Governance supporting a cloud-first Zero Trust ecosystem, Temporal Entitlement. Like most of the things I’ve highlighted in this article, this can be achieved with old-school provisioning and governance. But what does it mean?
So, imagine if you will, a world where everything provisioned was temporal, time based and non-permanent. Imagine a situation where every entitlement and credential hit a pre-defined “sun-set” date and was simply suspended, revoked, or removed. Now that really would be least privilege, wouldn’t it? Maybe you only get access to Salesforce for day, or a week, or a month and then you must ask to retain it. I appreciate that this may sound unrealistic, but with the capabilities of just about any reasonable provisioning tool, this is very doable. To prove my point let me walk you through a scenario.
Consider Dave, your company’s #1 DevOps pipeline delivery guy. He spends all week working with the access he needs to get his job done. Whenever he needs access to an image or a test suite, or he needs credentials to check in code, the governance engine is squarely in the loop. That means all access entitlements and their connections are either recorded in, or delivered by, the centralized tool. Again, no new trick here, the primary goal of any provisioning system is to track and manage the connections between people access and data.
Then the following week Dave goes on vacation for two weeks and arrives back in the office early on a Monday morning. While he’s been gone, his access and his entitlements have simply dissolved away – and all he’s been left with is a basic network account, an SSO launchpad, and the ability to request more access.
Now I can already see the help desk folks reading this rolling their eyes and shaking their heads but, trust with me this can and does work. With just basic provisioning and governance capabilities, it is trivial to simply put all his access back in place, maybe before he even knows it went away!
Using basic integration between SSO and provisioning, you can catch Dave’s actual access event and trigger a provisioning response. Based on his attribute and credential providence and his documented access history, we know we have the right guy trying to make the right access to the right applications. We can run automatic approvals, kick off dynamic provisioning and enjoy the protection of embedded controls; in short, we can put the right least privilege back in place, Just in Time.
With just a little bit of Old Dog infrastructure and just a little bit of new trick thinking, we really can make cloud-first Zero Trust a deployment reality TODAY.