The Future of Privileged Access Management

Welcome, everyone, to our KuppingerCole Analysts webinar, The Future of Privileged Access Management. This webinar is supported by BeyondTrust, and the speakers today are Morey Haber, who is Chief Security Officer at BeyondTrust, and me, Martin Kuppinger. I'm Principal Analyst at KuppingerCole Analysts. Before we go into the talk we will have today and the agenda, just a bit of housekeeping information. So you don't need to care about the audio. You are muted centrally. We care for that. We will do two polls during the webinar.

We have a Q&A session, but you can enter questions at any time, and we will pick the questions whenever appropriate during either our conversation or in the Q&A session by the end. And we are recording the webinar, so you don't need to write down everything or so. There will not be really that many slides. We just have a conversation today, so the slide deck will not be of that big value in this case. Agenda. So in contrast to many of the other webinars we are doing, it's not one slide deck by me, one slide deck by Morey.

It is that we will do really a discussion, a conversation and exchange our thoughts on topics we see as relevant around the subject of The Future of Privileged Access Management. And then, as I've already mentioned, we will do a Q&A by the end where we can also answer your questions.

And again, if you have any questions, enter them whenever they come to your mind so that we then, if it fits into our talk, we also can pick up the questions during our conversation. So this is the plan we have for today. And with that, and before I introduce Morey, a quick poll. And that is about how many Privileged Access Management solutions do you have in place in your organization? So is it zero, you don't have, or is it one or two or three and more? Interested into your responses here. And the more people participate, the better it is. Please enter your answers.

I'll give you another 10 seconds. Okay. So thank you very much. And with that, welcome Morey. A pleasure to have you here. Thank you so much, Martin. Pleasure to speak with you today.

Yeah, it's our first conversation and it really is a subject of Privileged Access Management. Even while we're just ahead of starting this webinar, we had a very interesting conversation about the disruptive impact of things like chat GPT and sort of conversational AI, but not our Privileged Access Management team. So we go to some other areas here. And so I think the first thing I'd like to start with, that is about two technologies that have a link from our analyst perspective. Significant overlap, but still frequently are a bit separate technologies.

I'm talking about Privileged Access Management in the traditional sense and about what most commonly is called Cloud Infrastructure Entitlement Management, which is a new set of technologies. And so the question or what I'm asking you and where I'd like to get your opinion is do you see this converging or is it something where you say this is at the end really different use cases, maybe even different ownerships and organizations so that they will stay apart? I really think that the definitions of both are where people struggle to see either divergence or the convergence.

Privileged Access Management has traditionally been thought of as the on-premise least privileged secrets management approach to assets and resources in your data center or your employee's notebook. When you apply that to the cloud, it doesn't translate. And that's where the definitions become an interesting problem. The word entitlement as a part of KIM, C-I-E-M, applies an identity and account relationship which has privileges, rights, permissions all the way down the chain, but a high level definition to state as an entitlement, I'm allowed to do something. That doesn't translate to root.

That doesn't translate to a power user which we normally associate with PAM. And that's where the overlap comes because you have something with a privileged ability in the cloud based on an entitlement definition to do work in the cloud as a part of its infrastructure. So isn't that something which is a bit also based on a sort of a narrow definition of what PAM does? So when I look at many of the PAM installations I've seen in organizations, they are not just about root and super user access. They tend to be broader and also cover whatever other types of more privileged users.

So I think there's a truly blurring line between who is privileged, who not. You can have a lot of discussions around that.

And then, so my thinking always is traditional PAM looks at humans to systems and servers while Keen looks more at sort of services to resources. So it's in both ends a bit more granular and smaller sort of also the Silicon side of things than the human side of things. But maybe in this context, we could quickly pick up a question because we're talking about Keen and maybe we're expecting everyone to understand what Keen is about.

But there's the question about, could you kindly, which came just in, could you kindly elaborate a bit more on the terms and concepts of Keen or we call it DREAM for Dynamic Resource Entitlement and Access Management. So Murray, maybe you started a bit with a definition but maybe you can give a bit of a definition for Keen.

Sure, so Martin, you're a hundred percent correct. I gave the traditional legacy definition of PAM and where I was going was PAM has evolved to do much more based on business role, whether it's a help deck personnel, a database admin, a backup operator and that's what we know for PAM today. But the translation to the cloud is exactly your point.

How do you take the abstract concept of supporting infrastructure in the cloud and giving a entitlement, which has the rights to a file, the rights to create a virtual machine, the rights to set up a network as an entitlement, the proper privileges needed. So you're taking the concepts of legacy PAM and modern PAM, which can do everything role-based and applying it to the cloud, which you don't own the assets, you don't own the resource and still saying you have the proper privileges to operate with this entitlement.

This is why many security teams will run KIM as a part of their operations, but also cloud ops teams have embraced it when PAM hasn't been mature enough, either legacy or modern because they need something to protect the cloud. And that brings us back to sort of the initial point. Do you think it will converge over time? Or like you already mentioned two different teams.

And then when we look at conversions, I think there's the other aspect, which is also about you give someone or something like a service entitlements to do something with system services, resources, data, which also is not only, which is partially privileged access management. So this is one angle to look at. The other angle is to look at it from a sort of an IGA perspective, from user very critical life cycle, identity life cycle management and access entitlement perspective.

So that means there could be even more conversions because at the end of the day, KIM seems to sit somewhere in between these two areas. They do. And I find very empirically when speaking to peers or clients of ours, that mature modern PAM companies have embraced KIM as a part of their own information security or own stack. For organizations that are newer, that are really focused on the cloud only or have never fully embraced PAM. And now this is their first area into forming some type of privileged strategy. They're handling it in ops or IT or another department.

So I do believe the divergence or basically the coming together depends on the maturity of the organization and the digital transformation that they've already embarked on. So I don't think of it from a technology standpoint. I think of it from a business standpoint. Have you been doing privileged management before? KIM will naturally fall in. If it's something new and you're mostly cloud, you're probably gonna do it differently. Fair point. And I would say for us as analysts, we see that the maturity of PAM vendors are looking very intensively at the KIM prior to evolve their offerings.

I think from that perspective, you have, so to speak, a bit of both options. And what is really important is that you understand the different use cases and have a plan to manage all of these. I think this is something, what I think KIM brings with it and which leads us to our next part of the conversation, that is the trust in time access or the ephemeral access.

Also to a certain point, I think that what I see as a very big difference is, so when we go to traditional PAM and I look at many of these projects and I said, okay, let's make a plan and onboard our whatever 3,000 Linux servers first. Okay, there was a bit change. Some servers disappeared. Some came in over time, but it was a relatively static world. KIM and the cloud infrastructures also look at, we have a permanent change of the resources, the services we consume. And so it is way more agile.

And that means also that this a bit more static notion of very traditional PAM rollouts doesn't apply to the very dynamic nature of the cloud. And I think this is one of the elements, but not the only where this terms of trust in time or ephemeral access come in.

Again, maybe we start a bit with a definition on how you understand these terms first, Murray. Sure, just in time means that you are granted access for a duration, a window, that is literally just in time. The account may have zero standing privileges. In other words, there may be an active credential where the password itself is vaulted or stored in a safe and you're granted access just in time for that mission, for us, that task, and then it stops. Ephemeral takes it one step further where the entire piece of that is time-based.

The credential may not even exist until it is actually needed, it's created, it's brought out of a disabled state, you're placed in the appropriate group, and then it's revoked when you're done completely so that the zero standing privilege concept doesn't exist. Both of these concepts are the foundation for zero trust because you do not want zero standing privileges and you need some way of saying, I can get in for this time, for this place, to do this mission, this task, monitor the behavior, and then it's done.

When you add the rest of the tenants and zero trust, you take this concept to the next level. This is the future of modern PAM because zero standing privileges are a liability to every business that's just onboarded accounts because threat actors are just a password away from compromising them because they are active, they are ready to use.

Yeah, so in a little bit more bold statement, I sometimes say static entitlements or standing privileges are the root cause of everything bad we have around identity management. So this is why we need so complex recertifications, why we spend so much time with role models, et cetera, et cetera, and they impose a risk. But I think in what you said, and I fully agree with you with these definitions, there's one element which is really interesting in this context that is the policy-based access control aspect in that.

Because when we grant access at runtime, trust in time, then it means we need to do that not based on a manual approval workflow that takes worst case days or weeks, but it must be based on pre-approved policies. And I think that means that this entire change is closely related to a lot of other sort of new things or old things coming back we are observing like open policy agent for developing digital services that run authorizations against the system.

So I think that is something we must underestimate that trust in time means we are going away from static entitlements, from static approvals, from ad hoc access to pre-approved policy-based controls that say, okay, under these circumstances, Martin or Mori are allowed to do that or not. Which opens, by the way, I believe a lot of new doors because we then can, for instance, always take into account the authentication context. So Martin can do that privilege activity when he's sitting on his desktop system, but not when he's coming in via an unsecured or unknown network.

I think that that is probably the best example I've heard to wrap your head around how. I always think of role-based access as the subset of what policy-based access is today. The role Martin is allowed access, the policy states, can he get it when he's on wifi versus the office versus he's abroad versus he's using VPN or not. And I think we are moving very heavily in the right direction towards policy-based management to handle just-in-time ephemeral, and it is absolutely needed for initiatives like Zero Trust.

Yeah, and then there's an interesting question just coming in, which is, how do we manage the policies then? Because at the end, probably we managed whatever, for PAM we managed, okay, these are the admins and they can do that or that. They can run these sessions on these servers, et cetera.

For IGA, we had a role-based entitlements, but right now we need to manage policy. So is there anything you could tell about how do we set up a good policy-based access control concept?

There is, and many policy-based access control systems will have the traditional Azure AD type integrations or IGA integrations, but they're gonna have additional attributes or traits in their settings to look for. They'll have the ability to say, am I running on battery? Is my network connection Wi-Fi? Can you please query geolocations and then evaluate that before sending the response back to the authorization or the authentication engine of choice?

So it's not that there's a whole separate tool to manage policies, but it is rather the maturity of many tools to have these characteristics built in to make those policy-based evaluations. And as Martin indicated, there are other methods, open-source methods or consolidation type agents that can help feel that information for you.

Yeah, so I'm, by the way, I'm for our upcoming conference, I made a European identity conference. I'm currently preparing quite some content around which role policy-based access and authentication authorization will and should and how it could play this role in future, because I believe we're really at a tipping point in the evolution here where things become more important. So there's a question around that, around this trust in time access, which is, do you see tools that will manage trust in time entitlements?

So is there something, maybe you look at it also from a beyond trust perspective that you already see out there? There are quite a bit of tools that do just-in-time and ephemeral-based access.

Yes, beyond trust does have a paper and our solutions do do it today. But the question becomes, what is your use case? Just to say I can do just-in-time access to a traditional remote desktop or SSH is one thing, but you have to ask who and what and why. You have to say, is it a vendor? Is it an employee? Am I still relying on traditional VPN, which hopefully you've gone past that, or if not, plan to. There are so many use cases around getting there that those questions need to be asked first before you go down the vendor route.

Yeah, and it brings us, I believe, to the next part of our conversation, which is around, let's keep the password list a bit apart for now, but authentication plus versus PAM. And that's, I think, one of these interesting questions. A lot of traditional PAM tools do their own authentication for administrators. And right now, and I think there was a reason for that, because strong authentication wasn't the norm in whatever, a decade ago.

Nowadays, strong authentication, multi-factor authentication, also password-less authentication are increasingly the norm. And I think there are two aspects I'd like to discuss. The one is, will we see these tools sort of replacing? So will we say, okay, there's an access management solution that does the authentication. It delivers information about the level of assurance for the PAM tool, and the PAM tool says, fine, I don't care about it anymore. I get it from an external tool. But we could leverage all the password-less authentication since we may already have deployed in the enterprise.

Second aspect brings us back to what we just discussed. That is, when we take the authentication tools, then they can deliver a ton of context. And I think this is a huge opportunity like we started discussing, because in a policy we then can say, it's not just that Martin needed to authenticate strongly, but only if the context for risk is okay. Then he's allowed to do that, or he can't do certain administrative actions when he's not in a certain location. What do you think about it? I think that this is part of that traditional PAM to modern PAM approach, which is really here today.

The traditional approach, as you first stated, would have used local authentication within the PAM tool. And I think that that is five to 10-year-old technology. Unfortunately, many organizations still do that today or are deploying today. And I would encourage them not to think that way. You can't necessarily always trust the third-party authentication that's gonna say you are who you are.

Revalidating with Microsoft Hello or Mac Touch ID, biometrics, FIDO2 is important, especially to say it is the same person, not that they were authenticated worse, but it is the same person that is now making this request. And I also strongly believe in the most secure environments, the privileged accounts that you care about the most, using different methods, whether you're using, let's say Microsoft Hello technology to retrieve a credential or start a session, but then maybe requiring a FIDO2 external key or a smart card for that privileged command or to initiate it.

Using a different method just in case something was compromised in the earlier part of authentication. But anybody looking at privileged access management today or even Kim to do resolution of infrastructure entitlement findings should be using modern PAM MFA with these techniques and not relying on the authentication just solely on the PAM solution. Okay. So what you're saying is at the end, the strong, that's not a question we have coming in here. Sorry.

You get from a standard access management solution is good enough to protect your PAM environment if you implement it properly and sort of combine it correctly what is the PAM tool and what a PAM tool is doing. And I think this is the bottom of the answer, but it requires potentially that you do, for instance, a step up for certain privileged actions. Agreed. And if you're using any modern Windows system today, you probably have Hello built in. If you're using a Mac for the last several years, you've got touch. I encourage you to deploy that step up.

Now that works very well with many of the single sign-on vendors out there. If you're not doing that, the native technologies should be able to address it too. Okay. Great. Another point, and I think we have quite a number of things we can discuss. So by the way, personally, what I like with personal authentication is also that it is really, and I think this is important also for admins, it reduces the complexity.

And what I hear a lot, before we go to the next topic, what I hear a lot from admins and also from organizations that they say, this is one of our big challenges in the entire authentication story because the admin needs to authenticate again and again and separately when he does or performs privileged actions because we want to keep sort of the standard user account separate from the admin account. And that finding good solutions is complex here.

I think that that is the charming thing with modern passwordless authentication that modern passwordless authentication done right means we are more secure and it's more convenient. So it's not about balancing anymore. Balancing security and convenience is not a good idea, I believe, because it means the security goes up, convenience goes down or the other way around. So we need to combine it. And I think this is the huge opportunity also we have. So I believe if you combine these things, then we can make privileged access just more convenient and even more secure.

Oh, I 100% agree on that. And passwordless is the way to do it, whether that is biometrics, face, finger, other methods that are out there. And the reason being is anytime you have to type in a password, open an authenticator app or something else, you're slowing the user down and you're becoming inconvenient. The goal of privileged access management in a modern world is to get the privileged access you need as fast as possible but with an extremely high confidence that it is appropriate. You are authenticating as you.

So passwordless, with the modern hardware technology that's available, streamlines that approach. And I do believe that is a strategic direction for the future of PAM and something we should all be embracing.

Yeah, if you go to FIDO AL3 level, then certified devices, then you have really strong technology you can use even for the most critical use cases or for almost the most use cases. Maybe let's have a little look at DevOps and PAM. So we touched it a bit with the Keen topic already, but I believe that it's bigger. And when we look at this entire thing, then we have, I think, some sort of a privileged or a specialized access, which means who can do what with the code? Because code is where things can go really fundamentally wrong.

You can implement things in code you don't want to have in code malware. The second aspect is we have to run time environments. We touched with Keen, like we run this application on an infrastructure as a service environment. And the third element is we have the entire DevOps tools chain. And within that, we also have a lot of administrative activities. So what is your perspective on what PAM can bring and needs to bring to the DevOps world?

Martin, you hit it right on the head. When people normally think of DevOps and PAM, they forget that there's three primary use cases. And just to reiterate, they are the code chain itself from development to QA to publication, test, et cetera. It's the hard coding potentially of secrets or other privileges within the code. And then it's the operational runtime of the code itself. Does the code need admin? People forget that the reason Google Chrome became so popular is because you could download it and install it without admin rights. It was easy. It just worked.

If code could work that way regardless without needing admin rights and fulfill a purpose, then we reduce its attack surface significantly in terms of what a threat actor can get to. So from a PAM perspective, yes, you do not want hard-coded secrets in your code.

Yes, you want to be able to have dev, QA, test, promotion of code without admin rights, whereas minimal privileges is more appropriate between the zones, the testing, the production, et cetera. And then finally, code that needs excessive privileges to operate just increases your risk surface. And there are privileged access techniques operating the concepts of least privilege to make that work better. And I think that PAM can help in all three, but it comes back to the business use case. Where is your pain point and how do you plan on solving it?

Yeah, but I think the point is this pain point is ubiquitous nowadays. So when I look at, so we have to also look at, for instance, all the new vendors appearing in the market. And we saw quite a number of startups that do something around the entire software supply chain security. Because organizations have learned that we have a huge challenge here. So I think we need to apply the concepts of British access management across everything here so that we ensure that nothing goes wrong, that we have it under control.

That truly is something which goes in many areas beyond the traditional PAM, but you're right. I think what you call the application to application password management, we called it traditionally. So this don't use hard-coded secrets in applications or in code. That is truly one of the things we definitely need. We need to have a privileged access to the critical functions within the DevOps tools chain so that nothing goes wrong. And we need Keen and we need the software supply chain security. And I'm absolutely with you.

I think we still see way too much software out there where we have sort of inflexible concepts when it comes also punctual accounts and other things, which are really not the best way to construct modern software. So I think we also need to learn a lot in software development to do it better. I think that would solve the bulk of the problems outside of the supply chain. I personally believe that the vendor risk is one of our biggest threats for the remainder of this decade.

And that is from either applications needing too much privileges or from the production, the supply of software that is done in an insecure manner. For example, I use a very popular and many of you do as well, messaging app. Every time it updates, it needs admin rights. I'm not a local admin. I don't have those rights.

Yes, I have a tool that does that promotion. That's part of what BeyondTrust does. But for the average user that knows running local admin for daily work is bad or in a corporation, the application is just poorly coded in my head.

Well, we need it for this. No, there are modern techniques for engineering it. And if you're doing your application that way, that also gives me an indication that you have other problems in your entire software supply chain that you should.

You know, I've been around in this industry for a while. And whatever, two decades ago, or even a bit more, I wrote a lot of stuff around Windows servers. So Windows NT and Windows Server 2003 and all that stuff. And I talked a lot about to use the operator concept instead of the admins. Yes. Because I always say, you know, if you need your domain admin for more than two or three times a year, then probably something is going wrong. And you only should use it for the very, very few actions that really require this account. Everything else should be done with more granular operator accounts.

But a lot of software, even today that I see, still lives in a best-cost crane admin roles, not in more fine-grained things. And so we still definitely have a long way to go for better security here.

Which, by the way, directly adds us to the application security aspect. So this is one aspect. So unfortunately for us, as sort of the consumers of software, it's hard to change that. So poorly coded or not optimally coded, I think not everything is poorly coded. To rephrase it a bit more friendly, the things which are maybe not perfectly coded, that is part of it. But on the other hand, privileged access management, from my perspective, is not only something we look at for a Linux server or a Windows server, but also for administrative activities and applications.

We touched it in some way with DevOps, seeing we'd already had. So how do you see this? Do we use enough privileged access management for sort of the application level? So application security definitely has a privileged component, but I look at it in a couple of contexts. From a software development standpoint, it's everything about developing secure code from the beginning. The pipeline for DevOps is different. With all of those privileges as it deployed, are excessive privileges needed to do standard functions?

So in other words, every time I upgrade, to Martin, your point earlier, do I need domain admin rights? How is the application vulnerable to privileged style attacks? You know what? Maybe there are no privileged accounts. It was installed once, it's done, and it can self-update all the time. And you know what? We start thinking of concepts like office applications, which don't need traditionally admin rights. They've already been granted it once to install, and they can take care of themselves afterwards. So application security becomes fairly broad.

All about the health of the application, the privileges used to develop and manage it, the privileges used to update it, and so forth. And then finally, the risk that everyone worries about, what privilege attack vectors exist? Are all the API keys properly protected? Can it be accessed in ways that are unnatural or leak information that could cause a liability to the business with privileged accounts, or even with limited accounts that have been granted access? So the keys that secure APIs and all of that become a part of application security that we have to think about.

Luckily, modern privileged access management can help secure many of those secrets, especially on the API side, but we still have a high risk if the application is poorly coded. So what you're saying is, don't limit privileged access management to passwords.

Correct, any secret, any key. Exactly. Yes. Which other means that there's a bit of a blurring line between more the secrets management types of solutions and the privileged access management types of solutions. I think we see this very much when we look at more the code level secrets management versus keying tools, et cetera, where the line is also a bit blurring. And I think we also see this, and I'm fully with you, which types of secrets do you manage? Because at the end, yes, password's clear.

Okay, key certificates, and then which types of keys, and then it becomes quite broadly here. And once we started talking about application to application privileged management, then surely we end up at API keys and stuff like that.

Agreed, and I think that's key here because this is the future of PAM. Anything that is a secret in a broad sense, application to application, key certificates that you have to manage, I think you're gonna see PAM moving in that direction just like it consumes more of the entire identity and access management space because everything interacts with some form of secret that you need to protect, and in essence, privilege. And I think you'll see more and more of that technology be incorporated into the modern PAM stack.

Okay, last topic for today's conversation, a bit different, supplier risk and privileged access management. So supply chain security, supply chain risk management has become a huge topic, and I think we have two areas. The one is clearly when it's just about understanding are our suppliers doing their job of protecting their IT good enough so that nothing trickles in malware from their IT into our IT? And the other part, from my perspective, is when we look at this topic, MSP access. Are these the two areas or is there more in the supplier risk? There's more.

So I think of supplier risk, first off, is do you even know that you're using that supplier and where? This is an interesting problem because it goes back to even the CIS01 control, asset management. If you're using a supplier that has any type of code or asset within your environment, you have to have good asset management to even know you're using it, where you're using it, and how you're using it, especially the owner and version. So if there is a threat based on a supplier getting attacked you know where it is and how it exists in your environment.

If you're not aware that you're running vendor X, Y, and Z, or you don't even know that it's being used in certain ways, you're going to fail in this particular attack. So that's, to me, the first step in all of the supply chain risk. After that, okay, how are we using it? What access does it have? Am I still sending them the standard security questionnaires? Am I using it looking at one of the online grading systems? And there's plenty of them out there that are legally scanning their forward-facing assets and giving them an A through F score in terms of their hygiene, et cetera, et cetera.

You have to know where you're using them, how you're using them, and how good they are to even begin to understand their risk. Now, if it's a vendor that's connecting into you as a part of vendor privileged access management, in other words, they have a remote connection into you to do maintenance, okay? Think of the old traditional target style attack where it came through an HVAC.

Then you have to apply the privileges and controls to ensure that they are restricted to what they can do, they're monitored to what they can do, and based on everything that we've spoken about earlier, just-in-time, ephemeral, policy, et cetera, so that it's not the technician while he's on vacation on an island doing the work for you when he's supposed to be near his home office or in his home country. All of these concepts roll into supplier risk, and I think we have a lot to learn there.

And by the way, one area where, Pam, it's perfectly well into supplier risk that is every organization that manufactures whatever, that produces something, because you always have the technical equipment for manufacturing, and you have the suppliers for this equipment. Latest, during the summer break, they all come in, and a lot of them remotely as well, so some change technically, but a lot is happening in maintenance, and the more we move into sort of permanent monitoring, et cetera, from the supplier, the more we have this type of privileged access.

And in an area which is very critical because I think everyone who has ever been working in a company that is manufacturing something, oh, if the SAP system is out for a few hours, this is not a real big problem. There will be a lot of people shouting around, yes, but a real problem is if the production stops because that costs real money immediately. And then where supplier risk is high, and so we must limit the access here. We must control it, and this is where privileged access management in the OT world is a very logical solution.

So this would be one of the things when I think about Pam and supplier risk where I would start looking at. If you don't do it, you really take a huge risk.

Martin, you're absolutely correct. The OT ICS environment for vendor access, it's one of those convergence for the future of Pam. Remote access privileges and management are key to get there, and I think dead on, big future for Pam, but I'll go back to if you don't even know where those assets are in your environment, you can't even manage the connectivity or the risk correctly.

So yeah, I think very complex. Management surely is a good idea. I'm absolutely with you. So by the way, for each type of asset, the identities, the systems, the applications, the data, you can't protect, you can't govern, you can't manage what you don't know. That's correct. And the future of Pam is that remote access to what you know. It's the ones that you don't know that people have access to that becomes your highest risk.

I think what becomes clear from our conversations, privileged access management is by far not at the end of its sort of evolution, so to speak, just starting and branching out into many other areas. And on the other hand, that also means you need to be very careful when you start looking at privileged access management or reviewing your current installation to think about what does it need in one, two, three, five years from now? And that will be quite a bit more than it provides today.

Maury, I think we go to the second poll and then into the Q&A right now. Okay. So I have one more poll here, which is, are you considering shifting or have you already shifted your privileged access management to a cloud-based deployment model? So do you use Pam as a service, yes or no?

Martin, I think cloud as Pam from the cloud makes a lot of sense for people when they're going through this digital transformation, which we briefly touched on. But in terms of labor and cost and maintenance and upgrades, Pam traditional, traditional Pam was always a heavy lift. This alleviates that burden. So we'd really like to know how many of you have already tried or going to alleviate that heavy lift. Okay. So I'll leave the poll open.

Okay, close. Right now I've just said, okay, let it go for another few seconds.

Anyway, let's do a bit of Q&A here. So we already have a number of questions here. And if you have further questions to Maury or me, don't hesitate entering your questions here. So one of the questions I have is, and we didn't answer yet is, I think we touched to a certain extent of this don't privileged access management and Keen complement each other. So we talked about the conversions. Is it complimentary or is it something, I believe it's complimentary. And that's why we do converge.

I believe they're complimentary and will converge with maturity of the business and tool sets because it is just another form of privileges in a new way, asset and resources in the cloud to perform work. Yeah. Okay. And maybe staying at this Keen topic, there's another question that is, I think you already provided the answer, but I think we can pick it anyway. So should Keen be owned and operated by the same team as the traditional PAM solution or not? I think it depends on your organization. In most companies, I do see it operating that way. And this is the fox and henhound approach.

If cloud ops is doing all the work, generally you don't want them monitoring themselves for security. You want an independent party or a three-legged stool, someone to write the policy, someone to implement the policy and someone to monitor the policy. So I do believe Kim is best off in the information security area, monitoring the way the rest of dev and cloud ops use the cloud environment. Okay. There's another question. I liked that one because it's something where you really need to be aware of and think about and look at the implementations.

And that is, when we talk about ephemeral certificates, so something which is driving us just a bit of access for a certain period, don't we still need backdoors for accessing the target system? For instance, in emergency, if the PAM doesn't operate, how do we come in to the target system then? Does it mean we leave backdoors open or how is this done best in practice? So backdoor access, bad idea. Break glass access, great idea. Okay. So I'm just gonna clarify on that. There should never be backdoor. But break glass in case of an emergency or something else is a good idea.

And there are multiple techniques to get there. It could be everything from an ACL to a trusted resource that sits separately. It could be everything from a zero standing privilege account that does have its complex password, literally printed on paper and put in a safe. It all depends on your environment. But break glass accounts or emergency accounts should always be used when it's an emergency and the rest of the environment fail. There are software methods like password caches to ensure DR and high availability and not get into a break glass scenario. But concepts of backdoors, bad idea.

Okay. Next question I have here. So can these solutions help? I think one of the challenges we all have and I think we touched on a bit but we can elaborate a bit more I think on this. How do we best deal with the fact that a lot of people have, so on the admin side or the operator side have an user persona and one or more admin personas. So what is in practice the best way to make it really easy for these persons to do their job? So the best way to handle the relationship of multiple accounts is to think about the identity. The identity is the machine or the human.

And then the identity as a machine can have a different set of variations, different topic. But as a human, I have multiple accounts. I have my daily driver accounts and I have my variety of admin accounts. The best way to think about that management is to manage those privileged accounts in a modern PAM solution. Passwords are obfuscated, they're never known, they're injected, they're never exposed and the session is just available if you're doing it correctly with all of the advanced MFA and biometric or passwordless techniques that we spoke about.

That means that when I need to use that privileged account, the policy validates who, what, where, when, et cetera. I'm allowed to use it. Everything I do is documented and the session just starts with either the secret being injected or another vehicle to get there. But managing it through PAM, so it's seamless to the end user is great and it eliminates that one very important piece, I don't have to remember and I don't have to write down that password in order to gain access.

Yeah, and I think this is the most important things because passwords are a security risk. Maury, anything else you'd like to add to today's conversation before we come to the end of today's webinar? Two quick things.

Martin, always a pleasure speaking with you. It's a delight to speak about topics like this, even our conversation about chat GDBT before, it's very enlightening to me. And second, Martin, you had up a slide ago about EIC in Berlin in May. If anybody is on this call, I will be attending and giving a quick presentation on cloud attack vectors, my most recent book on protection and mitigation strategies on attacking the cloud. So I look forward to meeting many of you in Berlin.

With that, thank you very much, Maury. Thank you to everyone attending this clinical webinar. Thank you to Beyond Trust for supporting us with this webinar. I hope to see a lot of you at EIC in Berlin, as Maury already said, and hope to have you back soon in one of our upcoming webinars. Thank you and have a nice day. Bye.