Old Dog:New Trick - Musings on Enterprise Identity Governance in a Cloud-First Zero Trust Ecosystem

Shame. I can't be with you there in person, but I think this is the, the new normal, I guess. And if you don't know me brief introduction there, I've, I've been kicking around identity management for, for quite a while now. And I was actually at way set and sun Microsystems before my time at SalePoint. And I was the CTO at SalePoint for 12 years, you know, fantastic time we had there last five years, I was actually the real CS O through a public company and a public offering. So I can say I've certainly spent my time in the hot seat there.

I know we have a lot of CISOs speaking and in the audience being of 20, 20, 20, I retired from SalePoint and I'm now an independent advisor and, you know, helping with a bunch of market people to bring to market the next generation of identity solutions. And then Martin said, very importantly, I, I joined my long term friends here at Kuppinger a research fellow last year. So before I continue, I do feel the need to explain my title a little bit old dog, new trick, being a little kind of gray around the edges. Myself.

You might assume the old dog is me and that this presentation is, is some form, a new trick, not. So the old dog I'm referring to here is the provisioning and governance that certainly I've been talking about at events just like this for the past 15 years. And the new trick is exactly how to apply legacy and new cloud first IGA tooling to better support a cloud first zero trust ecosystem.

Now, while I'm defining things, I think it always pays to explain what we mean. Let's say something like cloud first, a cloud first ecosystem, or what does that mean? Or to me it means that all the applications that we buy to serve our employees and basically run our business, these are delivered from the cloud and of course, legacy systems don't go away.

You know, do they ever, you know, today's buy is tomorrow's legacy. That's always the case, but cloud is a definite clear preference for anything new. It also means that all of the services that we provide to the customer come from the cloud too.

So, you know, if you're building your own web cloud delivery, wherever you are really microservices, containerization, and a really prime focus on dev op, these are really the keys and, and a bunch of new technology and new tricks you might say there, for sure. So it's really important that we think about where our provisioning and governance extends to meet that right into our dev into our sec and into our ops.

So our dev sec ops, and finally, I guess, for the purposes of this conversation, it means ensuring that IEM services, the things that you procure and deliver that deliver identity are wherever possible cloud first in their structure and how they're actually delivered to you and through you to the customer. There's also just take a moment to make sure we're all on the same page regarding what I mean by zero trust. If we look back over the presentation titles for the rest of this event, you'll see that this is a very widely and somewhat loosely used term.

For me, zero trust it's meaning is very clear. It represents basically a different way of thinking about identity governance services. And that will be the focus of our conversation. It does say assume for a moment that the network is compromised and let's ask ourselves a very important question. What would we do differently in identity governance? If we thought that the network was compromised, what would we do differently? So zero trust simply says, change the way you think about the problem and take a different approach.

It means assuming the network is hostile, as I say, but that obviously doesn't mean giving up on network security and, you know, opening the door to the bad guys of, of course, that would be crazy. It, it simply means accepting this idea that the bad guys have visibility on the network and they understand the cloud applications and services you've procured, right? They see your footprint accept that fact and focus on delivering extremely fine grained, controls and governance over who gets access to what are pretty simple.

That entails cataloging people, applications, and devising devices, devising devices. If you, if you think about pretty, pretty basic security principle, understanding what you've got, but here we're talking about access plans. So where people come from and how they connect, and very importantly, building a history of who should have access on, on why they need it. And zero trust almost certainly, at least to me means delivering on the principles of least privilege. I think that's pretty well understood. And this is a topic I'm gonna come back to several times.

And at the end, we're gonna hopefully really emphasize exactly how easily this principle can be achieved using the right approach and tooling. So finally for me, zero trust says in summary that managing fine grained, access control and entitlement is the ultimate thing we're trying to achieve. And it really comes down to understanding access at a very fine grained level. And so in lots of ways, sort of conveniently that really comes down to making identity and access management a serious core competency for your business. Okay.

So if that's cloud first and zero trust exactly what does governance and provisioning supporting cloud and zero trust actually mean in deployment, cuz that's really what this comes down to. It's not academic, right. And to answer that question, I'm gonna highlight three things that provisioning and governance can do to support a zero trust approach. They are implementing true lease privilege, building a model based lifecycle and adopting something that I'm gonna refer to as temporal entitlement, let's jump into each of them.

And I'll certainly give you Mike perspective on how to achieve these. I hope easily. So let's start by looking back at this least privilege because it very much is at the center of how we think about the problem. And I think most people understand that least privilege means only giving people the access that they need to get a specific job or set of tasks done. The question is, how do you apply this to a cloud first ecosystem? And the answer starts back with that old principle of, of inventory. Invisibility, as I say, it's the old mantra, right? You can't manage what you can't see.

And of course that gets even harder in a cloud first infrastructure. So if you don't know who has access to what and why they have it simp least privilege has just got no chance. It's really is as simple as that. So before you can sort of move into revolutionary thinking about your, your security for cloud, you have to deliver on.

I mean, these are basically, like I say, old dog security and governance tricks and principles. It means you have to aggressively manage a full inventory of all cloud and, and app access.

And, and this has to cover all of you knows GCP, Azure, all of your cloud resources, plus your complete devs lifecycle footprint, least privilege for cloud also means least access. And by that, I mean, thinking differently about providing access in the first place, we're often way too focused on providing the most access we can, right? If you are in a, in a provisioning enablement team, that's what you do, right? So we have to kind of flip that and always think about the least or the minimum amount of access.

So lemme give you a practical example of what, I mean, how many of us on we all do access reviews, right? But how many of us, when we see a cloud access element in an access review, think revoke by default very rarely, or if we are involved in delivering some sort of role mining and birthright access, you know what people get, you really have to be focused on the least amount possible.

So the closest peer group of matching the highest criteria to match and the smallest amount of access in the profile, because if we really want to support zero trust Riley's privilege, we have to give out less by default. It really is as simple as that and giving out less by default, something I've talked about many times only makes sense when it's supported by just great self-service and delegation. That's why that's so important. And we have to deliver intelligent self-service that has effective delegation, dynamic delegation, and highly automated provisioning and approvals.

And none of this is rocket science, right? This is nothing new, no new trick here, good inventory, minimal birthright access. And self-service, these are achievable with just about any provisioning and governance tool. Anyone I've seen they're the basic premises. So pretty simple do the second pillar of IGA supporting zero trust is a model based life cycle. And this one's quite important esoteric. And a model based lifecycle means putting well known and well understood governance models at the center of the access lifecycle.

And yes, that often does mean are back that old, not so building roles and maintaining their lifecycle, but it also means building other models, things that can basically capture the desired state, nice academic principle. So things like ownership and approval definitions that are gonna overlay responsibility and stewardship, very important word for all the things we care about down to the finest level and manual and automated change control policies.

So, you know, policies that can carry out well known actions that could be manual, right? When the identity, the attribute or any resource state changes, and maybe said this many times as well, that a governance model is simple as a clean set of requestable units of access.

So, you know, self-service available to the right people to request the right access at the right time. And so these are all models and they drive a governance based approach to identity.

Yeah, you've said this again, several times we have to commit to these models and govern them up front. If we are gonna minimize risk and, and deliver true zero trust, least privilege for our cloud first ecosystem. So a model based life cycle also means developing the something we call embedded controls, right? So we have to take the checks and balances, as we say of the business, best practice can have one of these, but not with one of those and embed them in the request and provisioning flow.

And again, you know, say no, no new tricks here, embedded controls of, you know, I've certainly been talking about them for 15 years, but it's still my job as an identity specialist. You might say to evangelize this fact and make sure that everybody knows that embedded controls like preventative sod, they're absolutely required for a cloud first based approach. And lastly, model based lifecycle means understanding when and where attributes drive access.

And this is a big one, it's a little fuzzy, but when I say attributes drive access, I mean, when any system makes an access policy decision based on identity data or any verifiable credential, we'll come back to that controls need to be in place to govern it, to explain what I mean, look at an example, this is a pretty simple right standard practice in an enterprise provisioning deployment today to use an HR attribute like job code, to define access to a business role. And then through that business role, you know, through its assignment rule.

So clearly, you know, here, job code, along with the assignment rule, they decide the access it's clearly attribute based role provisioning and the attribute defines the access. Another example, when an AWS access policy picks up an attribute like manager from the identity provider, that's what we do. And it embeds it in an S3 access control policy. The attribute defines the access and the decisions are being made based on that supplied identity data, right based on the credential or again, another one winner. Zoom does that with an account like location.

Again, we don't think of these things as being so critical, it's protecting a OneDrive folder and it does. So using a dynamic access group again, access is being defined by the attribute. So how do you run provisioning for that, right? How do you define and implement the controls for those rules and where is the governance, you know, who manages will say the attribute Providence, a word that we hear a lot of these days, you know, are the attributes accurate and up to date? Are they verifiable? Does anyone know that this particular attribute is driving access downstream frequently not.

And are there policies and rules to control the life cycle, right? As the policy changes, the access changes too. And is there change control over the policy over those rules such that they will pass an audit. And these are just very, very important questions. So I foresee a cloud first zero trust future where the Providence and a, and assurance of identity attributes from runtime access policies. They're gonna be the key of, of a governance based control in the future.

And as we age ever closer to this world of, of true verifiable credentials, self sovereign, and, and distributed identity, composing delivering and onward validation of verifiable credentials, it's gonna be a key focus for our, our, our access governance programs in the future. And so running our time here, get to the third and final element of identity governance, supporting cloud first trust temporal entitlement. Like most of the things I'm highlighting here today, this can be achieved with old school provisioning and governance, right? For what does it mean?

So imagine if you can a world where everything that's provisioned is temporal. So time based, and non-permanent imagine a situation where every entitlement and credential hits a predefined sunset date, and it simply gets suspended, revoked, or removed. Now that really would be least privilege it.

The, you know, it's least it's taken away. Maybe you only get access to Salesforce or your cloud resources for a day or a week or a month, right. And then you have to ask for it back. It goes away. So I appreciate this sounds a little unrealistic. And usually if I can see an audience, there's the help desk in there, right? You looking at it and thinking, holy macro, there's this, this this possible, but let me walk you through a scenario.

So Dave, he's the number one 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, he or to check in his code, the governance engine is in the loop. And so that means all of the access entitlements and, and their connections are either recorded in or delivered by that centralized tool. So we see connections again, no new tricks here. Primary goal of provisioning is to track those connections between people and access.

And very importantly, as Martin said their data, right, that's what it does. Then the following week, Dave goes on vacation and after two weeks in what looks like a beautiful ocean, he returns back to the office. And while he's been gone, he's access to his ti and his entitlements I've simply dissolved away and all he's left with, and this is important is a basic network account and SSO launchpad. And the ability to request that access back again.

Now, you know, say usually the help desk folks here roll their eyes and shake their heads right at me and say, but I've seen this work at scale with just basic governance capabilities. And we can use those to just put the access back and maybe do it before Dave even knows it went so away. So using basic integration between SSO and provisioning, we can catch Dave's actual access events and trigger a provisioning response, right?

So based on his attributes and, and his credential Providence, and very importantly, that documented access history, we know we've got the right guy making the right access to the right applications and services so we can run automatic approvals. We can kick off dynamic provisioning and we can enjoy the protection of embedded controls and basically put the right least privilege back in place just in time. And so with that 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 and do it today.

Well, that's it for me. Thank you for.