Rethinking Cloud Access Management

I think we'll get started. I'll let the panelists introduce themselves, who you are, where you're from. Sure. And
Wolfgang Gok. I'm an American. I'm with Cisco Systems,
Matthias Bower, living in Berlin, luckily so. And working for a company called One Identity, which is a daughter of Quest and doing that for 25 years now. So old white guy.
My name is Ma Haber, I'm the Chief Security Officer at Beyond Trust. I've been with the organization for 19 years. I reside in Orlando, Florida, United States. We are a leader in privileged access management and focus on identity security.
All right. So what I'll do is give you the initial question. Just raise your hand if you want to indicate that you wanna answer it, and then we're gonna go to the audience to see what questions they have. So in the question about rethinking cloud access management, so, so what are the current challenges of cloud access management and why do we need to rethink it? Well,
Well, where to start is a good answer. How are you using the cloud today? Is it through APIs? Is it virtual machines? Is it cloud washing? Is it remote sessions? We need to rethink it for all of the new use cases that are occurring today because they're not just virtual machines in our data center or applications that we are using as legacy systems.
Or is it about workloads? So we have, or audiences, we have normal company user, we have customers, we have admin tasks, we have machines, as you said, what are you using? How are you using cloud? How do you have a multi-cloud environment? So you have different challenges in terms of policies if you want to shift dynamically from AWS to Azure or to another instance. So this all brings up DevOps always forgot about it. So many different areas that are not brought together today and live in kind of different silos. Mostly that it's really a hard topic at the moment. I think we have spot solutions everywhere, but we, we really don't have a comprising overarching management solution that everybody can use regardless what type of user it is.
I like that word silo. I'm gonna pick up on that. Who would've thought we would find ourselves nostalgic for the days of active directory and physical servers, right? But at least then I knew if I put a user in a group and I sign the entitlements to the group, then he will get it and we could audit and maintain it. With the siloization that you're speaking to, there is a multitude of different entitlements, multitude of different ways that the authorizations are being performed. A multitude of different policy engines, a multitude of different identities. And we are lucky. We are lucky if we're running around 50 service identities, non-human identities for every one person. So there's also a multitude of identities now that we needed to keep track of. And you're right, they're all siloed everywhere and, and there is no good easy way today to maintain that.
I think I'd add to that the problem with the definition of the cloud, it's into the siloed. What does the cloud mean to you? To me, to my colleagues. Is it some private service? Is it a SaaS solution? Is it platform? Is it infrastructure? Is it serverless? Is it codeless? The access requirements for each of those types of cloud definitions is different. And yes, there is no one solution for all of cloud access. So the first thing that you have to do is define what is cloud to you. And then in that silo, what do you need to gain access to and where, because different cloud requirements here will be different than in China than in other regions of the world as well. Yeah.
Okay. So let's go to the audience. Alejandro will moderate
Already one online question.
The question is, what features should be part of the future cloud access management?
I will start. So I'm the first one. I think we will see a, hopefully we will see some convergence of the silos we have today. I think Pam, traditional Pam for cloud and standard user xs and DevOps need to come together a little bit better than today, especially for one reason. From my perspective, if we are going forward as we do today, only large enterprises can afford to have people that can maintain that. But we are talking about as well, we need that security as well. For at least in Germany, the strong SMB market, I don't know how it is in countries possibly is the same way. And if we keep those silos and the operational overhead and don't reduce the feature set as some silos are pretty mature, we are in a, in a feature set race, basically between the vendors. And if we don't lean back and bring something to the market that can be consumed by S smb. With our limited ability to have people hired for specifically security, I think we will be in trouble as well. So I see that convergence a little bit, at least on a lower feature level than might be the enterprise solutions might have as a feature set.
Yeah, I would add dynamic nature of privilege management, right? So if you think about how we used to do it, we would have our, you know, asset management and someone would register it and log it in. We'd have our person, we would do a life cycle and we'd have all these manual processes and there's all these exceptions we don't see. I think when we envision the future of cloud access management, we have to get to a point where I can apply a policy object to anything. If I've never seen it before, I can automatically have visibility into it. I can automatically inventory it, I can automatically classify it. I'm not maintaining a week long process or a month long process to deal with something that could be an ephemeral instance of just a few hours. And speaking of ephemeral instances in the ephemeral nature of a lot of this, in addition, having just in time ephemeral access. So being able to provide access when it's needed and revoke it. So we also get away from this long-standing world where I've got entitlements that live for 12 months until someone does an access review on something that was only around for a couple hours at a person that was only engaging with us for a couple of minutes.
I agree with my colleagues on this, but I want to add one twist. Don't forget your cybersecurity training and your basics. While we're talking about cloud access security, we still need session, we still need log, we still need config, we still need patch. We now have appropriate behavior. We now have just in time, many of the technologies that you see for cloud access are thinking of the future requirements. Like just in time not to have zero standing privileges. But you have to go back and think about the basic features that you need that you used and have today on premise. If you're not doing session recording on premise, it's something you should be doing. You also need full log management. Some of the problems with the cloud today is that you will pay an exorbitant amount of fees to get detailed logging just to match what you were doing on premise. Not to pick on one vendor, but I'll mention Salesforce as an example. If you want detailed logging on every download and every click and everything someone does, you will pay sales force a lot of extra money to get that just as to have a proper audit trail for cloud access management. So you have to consider your basics, the cost and the benefits. And then in addition, some of the modern things like just in time in order to get the proper features.
Any questions from the audience?
The question is, is C I m the answer to control privilege platform accounts or discovery and afterwards account and access management by the IM system? Or should they be created centrally by the IM system in the first place?
I think we're gonna answer this one for hours, but go ahead.
No
Agree
And no, you cannot have two records of authority. IGA across the board should be doing it. Kim has got an interesting problem, cra, cloud infrastructure, entitlements management, because the definition, and this is something that I try to drive home of an entitlement, is privileges, rights, permissions, et cetera. It's now just encapsulated into a concept. If you delegate the ownership or that delegation in the cloud without iga, you'll have all sorts of problems for certification at a station and potentially rogue accounts. So a a big no
And with regulations, and we have enough customers that have those challenges with regulations and failing audits from government side because they are not doing that.
And I'll get back to what I was saying about ephemeral access, right? Your, your point about centralizing is critical. We need that central identity, but we also need to take into account that there are a lot of people creating a lot of identities, right? So how do we have a process that we can recognize those identities on board them even if they didn't come through that standard, you know, request process and onboarding process. If there's an identity in the environment, we need to be able to recognize it, apply policy to it, audit it, and and work with it.
Can I have a, a mess? I'm gonna mess with that a little bit please. Because as a cso, this one bothers me. How many of you had identities created that you did not know about in your cloud environments? Who created them? Was it another vendor and you were unaware of it? Some of you are laughing, this is a real problem. I'll onboard a vendor and they start creating accounts in various places and there's nothing in their documentation that tells me anything about it or how to implement lease privilege. Yes. So from a vendor community standpoint, we have to do better from an IGA perspective, even for that provisioning
And, and regarding future for that, I, I hope at least that the topic of decentralized identity becomes a support for that. Because this will be, first of all B2B enablement and then B2C enablement or business user enablement from that vendor or partner. And I hope that this won't take too long anymore in the future. That this becomes a standard use case to have that trust so you know what's going on based on decentralized identity, with identity, proving, verified, however you want to call it. But using those modern technologies to have that B2B and B2C problem solved basically, at least for the onboarding.
Yeah, because how often, back to the vendor side, how often does the vendor set up a dozen accounts? Two dozen accounts, and then that employee who worked for that vendor is no longer there, but the account still exists and is active and you don't have oversight or governance to that.
Any other question? There's one online. Oh, now it's like five come. How do you foresee the interaction between users and Pam? Do we, do we really need it in a world where dev teams own their product environment?
Ah, do we really, do we really need Pam? I mean, yes, yes. My other answer was no. This answer is yes. No, we, we absolutely need to control privileged access and we need to control that as tightly as possible. Even if the developers are in their own world and have full access to everything, why do they have full access to everything? But the way that we go about Pam, and I would love to hear from you guys cause I know you have a lot more depth, but from my perspective, the old school way is I show Volta credential and I will give you that credential when you need it. Now we're moving more into ephemeral access, more into API driven access, more into dynamic policy driven access. So yes, we do need Pam, but I, I believe the way that we contextualize PAM needs to evolve as we evolved into DevOps apps.
That sounds correct to me. I cannot agree more.
I think there's a good piece and a good lesson from that question that Pam was very role-based access controlled. You're an admin or you're not, or you had admin features or not. With cloud DevOps modern use cases, we're now switching to attribute based access and policy based access and that's where Pam has to go and does apply. So for DevOps, how far in the pipeline can a DevOps engineer promote code go between zones, go between boundaries that's policy based, that's not role-based. Yes. So the evolution of PAM absolutely needed. Think towards what is applicable role-based business context and not just root in admin anymore,
Plus least standing privileged, zero trust, whatever you want to use as a buzzword for it needs to be more incorporated in Palm as well. I think it's a shortcoming today as well. And as I said, that convergence of those tools and make it accessible for SMB as well. So reduce the high end feature set. And this is regardless of IGA or PAM or access, we all are in a world of feature, dunno, sprawl or something. Reduce it, make it accessible, make it easy consumable for the s and b market and for, because not everybody can become a specialist like we are here in the room and sometime today it feels like if you want to use it, you need to be a specialist like we are. And this kind of is one of the next things I guess we need to take as a step as vendors.
But I gotta imagine in s and b it's even more important, right? This idea of activity based as opposed to role based. I can't hire a person who writes the code, A person who checks the code, a person promote you. You don't have staff for that. Correct.
You need, you need to code, I think a lot before, call it task based. I think this is the good word for me because I want to avoid workforce or role or something in that context. It's like the task based approach and give the task based access when you need it and remove it when it's not needed anymore.
I believe we have time for just one more question. Anyone from the audience or online? Okay. How to bridge the different approaches for users versus DevOps. Can you repeat that one
More time? I'm sorry.
How to bridge the different approaches for users versus DevOps.
I think it was answered, it's
Up to you if you want to reiterate.
Go for it. To reiterate, it was basically it's the bridging from role-based activity based to activity based. This is the basic concept that needs to be there first. The rest is nice to have around and and, and evolved by itself and, and by adding policies and cross-platform policies to be maintained from a central location, stuff like that. But the first thing is really to accept that there is a need for that role-based to activity based and to lost lead standing privilege.
And I'll, I'll add a a bit to that. In addition to that, just like you're saying, what is cloud? What is DevOps? It? They're, depending on how you want to answer this, there's a million different ways. I'm gonna answer it this way. Not necessarily the people, but the code itself. Again, we have around 50 identities for every human identity and most modern applications systems. So in addition to that, how are we providing, doing everything you just said, but when I've got a front end service that's calling a backend database or when I got a a middle tier service that's calling a microservice to spin something up. Each one of those identities also needs to be tracked and go through everything you just mentioned.
Let's expand on that for one second to answer. Does anybody have a director, vice president or higher title here in the room? Or is everyone engineers. Okay. The reason I'm expanding on this in, in this context is, is the higher up in the title in the organization, the less privileges you should have. You become more of a target controversial or serious?
Well, one of the
Serious,
Serious, serious, completely
Serious.
Completely serious might be controversial in terms of a topic. But if you're the executive, you should not have admin and route as a director. You might for something specific. But for a DevOps engineer, they're working lower level. They will have it based on applicable tasks and roles. When you go through this process and taking DevOps to marketing, when you're taking it to finance and taking it to other roles conceptually consider as the higher the manager in the organization, the less privileges apply. The same is true for DevOps.
Please run off applause. Good point. Thank you.