PANEL: Rewiring the Enterprise Identity Backbone

Maybe before we start with the discussion, just a brief introduction from each of you and maybe one sentence about your focus on IAM. So, Jan, would you like to start?

Hello, everyone. My name is Jan Quack. I'm working for a Swiss-German company named Swissbit. We are building a two-factor multi-protocol authentication device, which is used to log in securely, to authenticate securely, to on-prem and cloud solutions. And my take on IAM is, yeah, I'm coming from the authentication side of things, but due to my history as a consultant, I'm also coming from the GRC side of things.

So, no, both were tech and process policies. Yeah.

Hello, everyone. Thanks for having me here. Guido Grillenmeier with Semperis. Semperis is a company known for protecting your identity plane, both in the cloud world and on-prem. That's what we do. We bring you back when disaster strikes. We warn you about, let's say, challenges around risks and, let's say, challenges that you need to take care of before disaster strikes. And we help you to stay secure on the identity plane.

Hi, I'm Chris Weber. I'm VP of product marketing at Teleport. We're the AI infrastructure identity company. And what that really means is we provide a single unified identity layer based on cryptography, not on credentials that can be lost or stolen or shared, so we can eliminate standing privilege completely and all those millions of hidden access paths that have accumulated over the years. And I'm Robbie Winchester, chief services officer at SpectreOps.

We kind of started off as an offensive security company, really focusing on a lot of, like, Active Directory and identity tradecraft and created the open source Bloodhound tool, which has now turned into an enterprise product. Really, our focus is around identifying and understanding kind of the attack path perspective of interconnected technologies, not just Active Directory, but expanding into many different enterprises.

And that kind of identity snowball of how one small compromise can lead to bigger compromise through kind of expected but not intended configuration changes that aren't really – it's not necessarily a vulnerability, but boy, does it look like one. Okay, so let's start directly with the first question. I'd like to address it to you, Chris. When enterprises say they want to modernize IAM, what problem are they actually trying to solve? That's a good question. It's – depending on the enterprise, it's a little different. Some folks are – in fact, we talked to a few here.

They're moving to the cloud seriously, right? They're taking Kubernetes seriously, whether it's in the cloud or on-prem. They're looking to see if they can move out of just pure sovereign data into something that's a good failover that may be outside of their perimeter there, and they want to make sure that everything fails consistently if it does. There are other folks who are just trying to prepare for, like, the non-human identity and maybe AI identity side of things.

In all cases, what folks are looking to do – not unlike what you were just saying – is minimize those hidden paths that we all have. Like, I used to be a practitioner. It's been 20 years. I lived in Active Directory only because that's kind of all that was there. And even then, I knew when an auditor came, I could not confidently state that, like, there are no paths to get to this private data. I had to say there is a possibility of something. It must have gotten more complex for all of us.

So some folks are looking to modernize identity by actually uncovering or eliminating those paths rather than just try to live with the continuing alerts. Anything you want to add? I'll just add that basically modernization is often adding more security but also adding more resilience. And for many, that means let's try to get more into the cloud. And they might not necessarily be aware that resilience in the cloud is a completely different story than resilience on-prem.

And so you've got to look at the details as to what workloads make sense where, where you're maybe even more secure on-prem than in the cloud. Depending on the workload, your choices may vary. And resilience is not just failover. It's also the whole recovery story from disasters where just be aware that the cloud means it's someone else's system. It's someone else's server. It's not under your full control. That's where shared responsibility model comes in.

So, yes, modernization has various aspects to it. And it's not just move everything to the cloud. I think it's also to gain an overview about what's really going on in your infrastructure. It's all about understanding what are your assets, what are your processes, what are your real identities. Is it only human? Is it a lot of non-human identity stuff? And I think this is super important. And this should really be something that should happen prior to any activities understand what's really going on in the infrastructure.

Yeah, and I think that the challenge as well is you have to be additive of these new technologies, which have an identity layer, which integrate in either clear or unclear ways with the overall kind of IAM structure. But you don't necessarily as you integrate like a CICD pipeline, that team may not be directly related at its start with the identity team. But there's going to be crossover and correlation as things are getting deployed.

And so I think navigating and understanding this web back 20 years ago was relatively easy, let's say, because you only had to deal with the gigantic mess that was Active Directory. But now you have to deal with that plus six or seven different IAM tools and integrations and zero trust. And so it becomes this kind of snowball of you need to add the capability. You want to have the additional capabilities and tooling and staying current with NHIs and AI.

But how are you making sure that that still fits that cohesive picture and understanding what risks do we have overall, not just, you know, risk here and risk there, but the cumulative perspective? Okay.

Guido, when addressing to you this question, when you are rewiring your enterprise identity backbone, why is focusing on the security of the cloud identity architecture so critical? Partially already touched. The security is the piece that allows you to keep an attacker away from your most precious data. This is all about where you need to take least privilege down to the definition. Don't grant more permissions than your users need, than your administrators need, because it's all you have to assume breach even more than on-prem. Someone's going to lurk there, steal tokens.

It's all about token theft these days. It's not so much getting to a system anymore. It's getting your token. What can you do with it? What can you do with it? So that's why security is paramount, ensuring that you don't grant more than expected.

And that, of course, is the same thought around when you're going down the agentic AI route. What can the agents do with the permissions that you grant? Could be the user itself that the agent is running under, impersonating the user. What can that agent do? Is it only what he's supposed to do, or does the user have more permissions, and they typically do, than they need for their, let's say, daily business? It's going to be used by an agent. And the same thing is, of course, if you assign dedicated identities to those, scope it.

Scope it properly, because that's what we see way too often, is that general permissions, scope for the whole tenant, even for user administrators, go much beyond what you want them to be able to do, and take it serious. Scope it down. Take least privilege serious. And not just the cloud is safe. Maybe let's look at the practical perspective. I'd like to address this question to you. Can you share some practical lessons you learned from real projects? What are typical pitfalls or unexpected problems? What did you observe there?

Yeah, funny things. Well, I think the most important thing is, A, take time. Take enough time to plan things properly. And that comes back to what I said earlier. The first thing you should really do before you touch any product, before you implement any solution, is to implement the proper policies, the proper processes, have the governance in place. And once you defined all that, then you can start with implementing some techniques, technologies, products from you guys. This is super important. And I've seen that companies and organizations did it the other way around.

They thought, hey, this is the product that solves our problem, but they didn't really understood what their problem was. And that's, I think, crucial to start with non-technical stuff and then continue the journey from there.

So, and that's the number one thing. And time. I remember I had a project once to replace a simple MFA solution. It was planned to do in three months.

It took, at the end of the day, nine months. And there was a reason, because there were so many dependencies that nobody really had on the list. And this is super important. Do your due diligence. Do an inventory. Understand what are the dependencies, and then you're good to go. The other ones, any experience you want to share with us? I'll just back up. We used to live by the PPT, people, process, and technology. And we often, I mean, I'm a part of a vendor. We think of the technology often first. I think I agree.

When you think of how it's going to impact your folks and then how you're going to actually deploy, things go a little smoother most of the time. And with a little less hidden issue that takes somebody like you to go find.

Yeah, I mean, I think the difficult part is it's very easy to fix all of the configuration challenges. It's very hard to have the company still work when you do that.

So, that's the danger is you want to make these changes and you want to have that security posture there. But you have to balance that against what is the risk of the business and what needs to actually get done. And what are, can we quantify what are the actual acceptable risks and go and do that. If you just go and rip everything out, you can have a secure network, but a business that doesn't function.

Well, that's not what you want. And often, to your point, it takes, it potentially took years to get to where you are. And that doesn't mean you want to take years to get to a good state. But it's probably not possible to do it in, you know, hours or days. It's going to take some time, some planning.

You know, realizing any feature functionality or things that shouldn't have been there, but now are business critical. How can we go and migrate that? I want to have a question for you, Guido.

So, planning proper resilience for cloud, for your cloud IDP is quite different from what you are used from on-prem. Are there any hidden risks?

Yeah, how long do we have? So, yeah, I already mentioned it's quite different.

On-prem, you own the infrastructure. You can back up everything. There's tools. Even without tools, it's under your control. In the cloud, it isn't.

So, resilience, think about it, could also be, can I attach multiple IDPs to my application? That would be a cool path forward. But that's up to the product owners of the applications to take care of that. The identity guys, they can make such suggestions. They can even offer solutions for synchronizing between different identity providers. Could be different tenants. Could also be literally different providers. Think of Okta and Entra ID. Totally different.

Of course, Entra, or let's say M365, Office 365, wants its Entra token. You can't get around that. But plenty of the other apps just need an OAuth token, and they're fine, they're happy, wherever it comes from. But you need to configure them to do so.

So, a failover would be beautifully easy if the applications supported multiple IDPs. Salesforce does, as an example. But most others don't.

So, it's the exception to the rule. But if you take resilience serious, think about preparing applications at that level, because it's not a simple tooling choice to failover for you. It's an application configuration that you will have to do in a disaster if one of those other IDPs, could be your tenant, of course, not the whole IDP that's attacked. But just think about the possibility that that Okta tenant or that Entra tenant has been breached and completely under the control of the malicious guys.

Well, how do you get it back quickly? Well, a failover would be much quicker than trying to get access back.

So, those are things that you need to think about. And for your most critical apps, think about, can I switch them easily? Maybe it's only preparing to script something that you can failover to a different IDP within the application. And then tools can help you to sync the different worlds to be more resilient. Recovery is hard in the cloud.

And again, we don't have enough time to go into all of those intricate details, but the list is long. Anything the others want to add to this? Don't forget what happens if your core switch breaks and you can't reach a cloud at all.

I mean, that happens. I've seen it. I worked once for a company who really did it. They knocked off an entire data center of the air. Dead. And nothing worked anymore. And then you need to have some locally cached policies that help you to get around that as well.

So, another important thing. Chris, I have a question for you. How do enterprises realistically modernize without ripping and replacing everything at once?

Yeah, I think we started getting to that a little bit. Usually, certainly in the case where we come in and the deployments we've had, some of the folks in the room and others, it's not an overnight thing. It does take a little time, but it takes a lot of good planning. It sounds easy to say start small, but what does small mean? Sometimes I feel like today it's often the place where you have the most lenience to make a mistake.

So, if there's a new app that's being developed, a new cluster or set of that in Kubernetes that's going to be supporting an internal app and it's all in development, that's a great place to go establish your policy, get things going. In our case, to have it be completely just in time, ephemeral identity there.

So, there's no standing privilege, there's no standing access. Is it going to work the way I expect? Is the code going to support that? Where are we going to see things that go change? Sometimes there aren't those new, maybe the team's working too quickly to accommodate there, so it's about a set of people. Who are a set of folks who can accommodate this change, who maybe do have a backup policy?

They know, here's how I'm going to get a backdoor to the things I need to if this front door doesn't work, and then you migrate from there. I think the simplest thing is start small, but small could be a new project, it could be a small set of people. It usually isn't your executives, but a lot of them want to be part of it because a lot of the tools are projects that have a big budget.

So, finding a way to show that it works for some people without having folks have to go through that. And I think a stepwise, you know, we talk about crawl, walk, run. It's usually just picking place after place, and it gets easier. I work on cars. The first time I change my brakes on one wheel, I swear, and I hurt my finger, and it takes a long time. But by that fourth wheel, it's like, it's so easy and fast because you just have that handle.

Yeah, and I would say, I think what we found helpful is being able to kind of contextualize and visualize in such a way that you can see that there is progress as well. Because it can become a real challenge, like you said, on a car, it's more tangible.

When you start tackling this big, amorphous problem of this large challenge, if you don't have the visibility and understanding you're trying to secure an application, but you're lacking the context of where does that kind of fit overall, or how do I start tackling this large problem, being able to have that visibility and understanding of, okay, we started here. We're taking these steps, and it's not solved, but it's getting better. And being able to kind of, you can't necessarily just zero to one right away, but having that progress so it doesn't feel like it's zero in perpetuity.

Yeah, I like the idea of visible progress really is a good thing, just as motivation, but also justification. I think we should also just realize that, just prepare for a marathon. It's not a quick sprint to get from A to B. The world is hybrid these days.

It'll be, it'll stay hybrid for quite some time. You're going to need to manage multiple environments and ensure that they interact properly, and that the risks between those are also handled accordingly, so that you don't use, one doesn't become the risk to the other one. But it's not going to go away anytime soon. Most companies have been sort of, well, probably everyone here in the room has a Microsoft footprint on-prem and a Microsoft footprint in the cloud, if you wanted it or not. But M365 got you there, or Office 365, as it was called before.

And suddenly you have a tenant which might never, hadn't been on the forefront. Now, that's changed with all the other business apps also moving or trying to move to the cloud. But there's still the legacy that remains, and that probably won't go away anytime soon. Microsoft is doing its part to allow you to change the source of authority. Source of authority, yeah, I think I got that. Moving objects more towards the cloud, less on-prem.

But, again, that's not a quick switch. That makes it, for the while that you make that switch, even harder to know where's the ownership of which object when. But that's the complexity of today. And that's something that you need to handle. That's something that you need to be aware of. And that's what you also need to continuously monitor and understand where your risks are. Okay.

Yeah, we are coming to an end. I think we can talk about this topic much longer, but time is limited in this case. To the audience, do you have any questions you'd like to address to the panelists so far? Let me check if we have some online questions. I think that's it for the moment.

Thank you, guys, for your insight, for your information. And, again, you can rate this session. You can rate any sessions of ours. Just go to our app, to the agenda. And let us know. Give us feedback. It's quite helpful for us. And this helps us to get better. Thank you again. Thanks for having us. Thank you.