The Future of Privileged Access Management

Welcome everyone to our Coan Cole Analyst webinar, the Future of Privileged Access Management. This webinar is supported by BeyondTrust, and the speakers today are Marie Harber, who's Chief Security Officer at BeyondTrust and me Martin Kuppinger. I'm Principal Analyst at Co Coal Analyst. Before we go into the talk, we will have today and the, the agenda, just a bit of housekeeping information, so you don't need to care about the audio. We are, you're muted centrally. We keep care for that. We will do two polls during the webinar. We have a q and a session, but you can end the questions at any time and we will pick the questions whenever appropriate during either our conversation or in the q and 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 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 by me, one slide. It is that we will do really a discussion or conversation and exchange our thoughts on certain topics we see as relevant around the subject of the future of privilege access management. And then as I've already mentioned, we'll do a q and 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 Murray, 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, don't you don't have it? Or is it one, two, or three and more interested into your responses here? And the more people participate, the better it is. The please enter your answers. We, I'll give you another 10 seconds. Okay. So thank you very much and with that welcome ma, a pleasure to have you here.
Thank you so much Martin. Pleasure to
Speak with you today. Yeah, it's not our first conversation and it really be on the subject of British Access Management. Even while we trust ahead of starting this webinar. We had a very interesting conversation about the disruptive impact of things like chat, G P T and sort of conversational ai, but not our access management team. So we go to some other areas here. And so I think the, the first thing I'd like to start with that is about two technologies that, that have a link from our Analyst perspective. So it's a significant overlap, but still frequently are a bit separate technologies. We, 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 I I, or what I'd I'm asking you and where I'd like to get your opinion is do you see this convert virtual or is it something where, where you say this is at the end really different use cases, maybe even different ownerships organizations so that it'll stay apart?
I really think that the definitions of both are where people struggle to see either divergence or the convergence privilege. Access management has traditionally been thought of as the on-premise lease privileged secrets management approach to assets and resources in your data center or you know, 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 entitlements 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 train. 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.
Yeah. But but isn't that something which is a bit also based on a, on a sort of a narrow definition of what Pam does. So when I look at, at many of the patent installations I've seen in, in organizations, they're 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 hugely blurring line between who is privileged, who not. You can have a lot of lot of discussions around it. And then so, so my thinking always is Pam looks at humans to systems and servers while Kim looks more at sort of services to resources. So it's in both a bit more, more granular, it's more on the sort of also the silicon side of things than the the human side of things. But, but maybe in, in this context, we could quickly pick up a, a question because we are talking about chemo and maybe we are, we're, we're expecting everyone to understand what key is about. But just a question about could you kindly, which came trust in, could you kindly elaborate a bit more on the terms and concepts of key or we call it theory for dynamic resource and title and access management? So, so Murray, maybe you started a bit with the definition, but maybe you can can give a bit of a definition for Kim.
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, 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 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, you're, 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 at this, with this entitlement. This is why many security teams will run Kim as a part of their operations, but also CloudOps teams have embraced it when Pam hasn't been mature enough either legacy or modern because they need something to protect the cloud.
Okay. And and that brings us back to the sort of the initial point. Do you think it'll converge over time or you already mentioned two, 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 entitlement to do something with system services for services data, which also is not only, which is partially privileged access management. So this is one angle to look at. The other angle clearly is to look at it from an sort of an IGA perspective and user very created a lifecycle identity lifecycle management and, and access entitlement perspective. So, and that, that then means there could be even, even more conversions because at the end of the day, chemist 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 or 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'm thinking of it from a business standpoint. Have you been doing privilege 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 I would say for us as analysts, we see that the, the maturity of of pan managers are look very looking very intensively at the key prior to to evolve their, 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, and have a plan to manage all of these. And I think this is something what I think key brings with us and which leads us to a bit to, to our, our next part of the conversation. That is the trust in time access or the Fal access. Those are to a certain point, I think that what I see as, 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, 3000 Linux first.
Okay, there were was a bit changed from some servers disappeared, some came, came in over over time, but it was a relatively static world. Kim and the cloud infrastructures also look at, we have a permanent change of the, the, the resources to 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, very dynamic nature of the cloud. And I think this is one, one of the elements, but not the only where where this, this, this terms of just in time or ephemeral access coming again, maybe we start a bit with a definition of how you understand these terms. First Marie,
Sure, just in time is 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 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 your understanding privileges are a liability to every business that's just onboarded accounts because it's threat actors are just a password away from compromising them because they are actively are ready to use.
Yeah. So, so in in a little bit more bold statement, I I sometimes say static entitlements or standing privileges are the root cause of everything bad we have around identity management. Yeah. So this is why, why we need so complex recertifications, why we spend so much time with the role models, et cetera, et cetera, and they impose the risk. But I think in what you said, and I I fully agree with you with these definitions there, there's one element which is really interesting in this context. That is the, 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 this then that means that this entire change is, is closely related to a lot of other things, sort of new things we are, and on our old things coming back, we are observing li like open policy agent for developing digital services that that run authorizations against, against the system.
And so I think that is something we must under underestimate that trust and time means we are going away from static entitlements, from static approvals, from access to pre-approved policy-based controls that say, okay, under these circumstances, Martin or MO are 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, all take into account the authentication context. So Martin can do that privileged act 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 is on wifi versus the office versus 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 of far Merle and it is absolutely needed for initiatives like zero trust.
Yeah, and and there's an interesting question trust coming in, which is how do we manage the policies then for, because at the end we, we formerly we managed whatever for Pam, we managed, okay, these are the admins and they can do that on that they can run these sessions on these services, et cetera. For iga, we, we, we had a role based entitlements, but right now we need to manage policies. So is there, is there anything you could tell about how do we set up a 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 p in their settings to look for. They'll have the ability to say, am I running on battery? Is my network connection wifi, 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 method methods, open source methods or consolidation type agents that can help field that information for you.
Yeah. So I'm, I'm by, by the way, I'm for our upcoming conference in maybe European Identity Conference, I'm, I'm currently preparing quite, 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 are really at a tipping point in the evolution here where, where things become more important. So there's a question around that, around this trust and time emer trust and time access, which is do you see tools that will manage trust and time entitlement? So is there something, maybe you look at it also from beyond trust perspective, you already see out there,
There are quite a few of, 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 s 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 V P N, which hopefully you've gone past that or if not planned 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 for instance, I believe to to the next part of our, our conversation, which is around, let's keep a bit apart for now, but authentication plus versus pam. And that's I think one of these interesting questions. A lot of specifically traditional PAM tools do their own authentication for administrators right now. And, and I think there was a reason for that because strong authentication wasn't the norm in whatever a decade ago. Nowadays strong authentication, multifactor authentication, also path less authentication are increasingly the norm. And I think there, there are two aspects I I'd like to, to discuss. The one is, will we see these, these tools sort of replacing, so will we say okay, there's an access management solution that that's the authentication. It delivers information about the level of assurance to the PAM tool and the PAM tool says, fine, I don't care about it, it anymore, I get it from, from an external tool.
They could leverage all the password 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 this, 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 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 I is really here today. The traditional approach as you first stated, would've 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, we're deploying today and I 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 re-validating with Microsoft hello or Mac touch ID biometrics Fido two 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 5 0 2 external key or a smart card for that privileged command already initiate it using a different method just in case something was compromised in the earlier part of authentication. But anybody looking at access management today or even Kim to do resolution of infrastructure entitlement findings should be using modern prem MFA with these techniques and not relying on the authentication just solely from the PAM solution.
Okay, so so what you're saying is at the end, the strong f that's not a question we have coming in here, sorry, you get from a, a standard access management solution is good enough to protect your PAM environment if you implement it properly and and sort of combine it correctly with, with the PAM tool and what a PAM tool is doing. But, and I think this is the but on this answer, but it requires potentially that you do for instance, a step up for certain privileged actions.
Agreed. And if, 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 have quite a number of things we, we can discuss. So by the way, personally, what what I like is personal authentications also that that is really, and I think this is important also for admins, is it reduces the complexity and what I hear a lot before we, we go to the next topic, what I hear a lot from, from admins and also from 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, when he does or performs privileged actions because we want to keep the sort of the standard user account separate from the admin account and, and that finding good solutions is, is complex here. I think that that is the charming thing with modern password less authentication, that modern password, less 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 if 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 we combine these things then we can make privileged access just more convenient and even more secure.
Oh, I a hundred percent 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 the 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.
Pam. If you go to five aal, three level then certified devices, then you have really strong technology you can use even for the, the most critical use cases or almost the most use case. Maybe have a, let's have a little look at DevOps pam. So we touched it a bit with, with the, the key topic already, but I believe that it that it's bigger and, and when we look at this entire thing then we have I think some sort of a, a privilege or specialized access, which means who can do what this the code, because code is where we're seeing things can go really fundamentally wrong. You can implement things and code you don't want how having code malware. The second aspect is we have to runtime environments. We touch with scheme like we run, we run this application on 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, 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 QA development, 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 or as 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 becomes back to the business use case. Where is your pain point and how do you plan on solving it?
Yeah, but I think the, the point is this pain point is ubiquitous nowadays. So, so I I when I look at, so yes, I also look at for instance, all the, 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, we have a huge challenge here. So I I think we need to, to apply the concepts of British Access Management across everything here so that we, that we ensure that nothing goes wrong, that we have it under control. That truly is something which goes in, in many areas beyond the traditional pen. But you're right, I think the, what you call the application to application password management, we, we called it traditionally. So this don't use hardcoded secrets and applications or, or encode. That is surely one of the things we definitely need.
We need to, to have a privileged access to the critical functions in, within the DevOps tools chain so that nothing goes wrong and we need key and we need the software supply chain security. And, and I'm 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 functional 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, in, in, in the software, in, in, 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 the, 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, many of you do as well, you know, 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 Beyond Trust 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, in, in my, yeah, 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,
You know, I've, I've been, I've been, I mean around industry for a while and whatever, two decades ago or even a bit more, I, I wrote a lot of stuff around Windows servers. So Windows and TV and Windows servers two, 2003 and all that stuff. And I, I talked about a lot about to use the operator consult instead of the admins. Yes, because I, I always say, you know, if if you need your domain admin whatever, more than two or three times a year, then probably something is going wrong. You only should use it for the very, very few actions that really requires account. Everything else should be done with more granular operator accounts. But a lot of software even to today, I see still lives in at best cost grain admin roles, not in, in, in in more fine printing. And so we, we still definitely have a long way to go for better security here, which, which by the way directly heads us to the application security aspect.
So this is this one aspect. So unfortunately for us as sort of the consumers of software, it's hard to to change that. So poorly coded or, or not optimally coded, I think not everything is poorly coded to phrase 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, we look at for Linux server or Windows server, but also for administrative activities and applications. We touched in some way with DevOps seeing we already had. So, so how do you see this? Do we use enough British access management for at the sort of the application level?
So application security definitely has a privilege component, but I look at it in a, 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 then with all of those privileges. Is 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 privilege 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 privilege is used to develop and manage it. The d privilege is used to update it and so forth. And then finally, the risk that everyone worries about what privileged 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, privileged access management, modern privilege 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.
Yeah, so what what you're saying is don't limit privilege access management to passwords.
Correct. Any secret. Any key. Yes.
Which also means that that there's a bit of, 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, this, this very much when we look at more the code level secrets management versus key tools et cetera, where the line is also a bit blurry blurring and I, I think we, 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 start in talking about application to application privilege management, then truly 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, 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, and I think we have have two areas. The one is clearly when it's about just about understanding our, our suppliers doing their chop of protecting their IT good enough so that nothing triples in malware from their IT into our it. The other part from my perspective is when we look at this, this, this topic, MSP access are is 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 c I S zero one 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 inversion. 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 are 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 gonna 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 send 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, and by the way, one area where, where Pam fits perfectly well into supplier risk, that is every organization that manufacturers whatever, that produces something because there you always have the, the, 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, in an area which is, which is very critical because I think everyone who, 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 the real problem is if the production stops because that costs real money immediately and then where, where supplier risk is is high and so we must limit the excess 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 panel suppliers where I would start looking at, if you don't do it, you 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. Yeah, I think very comfortable
Management surely is a good idea. I'm absolutely with you. So by by the before each type of asset, the identity is 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 conversation is privileged access management is by, by, by far not at the end of its sort of evolution so to speak. Trust starting and branching out into many other areas. And on the other end it also means you need to be very careful when you start looking at mention or reviewing your current installation to think about what does it need in 1, 2, 3, 5 years from now. And that will be quite more, quite a bit more than it provides today. Murray, I think we go to the second poll and then into the q and a right now. Okay, so I have one more poll here, which is, are you considering shifting or, 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 lift your, okay, close right now. I trust said, okay, lets hope for another few seconds anyway. Let's do a bit of q and A here. So we already have a number of questions here and if you have further questions to Mario or me, don't hesitate entering your, your questions here. So, so, so one of the questions I have is, and we we didn't, we didn't answer yet, I think we touched it to a certain extent that this don't privilege access management and team compliment each other. So we talked about the convergence, is it complementary or is it something I believe it's complementary, that's why it'll 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 MA new way asset and resources in the cloud to perform work.
Yeah. Okay. And may there's a staying at this key topic. There's not a question that is, I think you already provided the answer but I think we can pick it anyway. So should key 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 hen hound 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 CloudOps use the cloud environment.
Okay. There's another question I I like, I like that one because it's, I think something we, you really need to, to be aware of and think about and look at the implementations that is when we talk about FM certificates, so something which is drowning us just a bit of access for a certain period, don't we still need back doors for accessing the target system? For instance, in emergency, if the PAM doesn't operate, how do we come in into the target system then Doesn't mean we leave back doors 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 apple 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 are, emergency accounts should always be used when it's an emergency and the rest of the environment failed. There are software methods like password CAS to ensure DR and high availability and not get into a break class scenario. But concepts of back doors, bad idea.
Okay. Next question I have here. So can, can these solutions help? I think one, one of the challenges we, we always have, and I think we we, we touched it a bit, but we can elaborate a bit more I think on this. How, how do we best deal with the fact that a lot of people have, so on the admin side or the operator side haven't used a persona and one or more admin personas, so, so what is in practice the best way to, 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. Maureen, 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 G D B T before, it's very enlightening to me. And second Martin, you had up a slide ago about E I C 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 ma. Thank you to everyone attending this clinical webinar. Thank you to Beyond Trust for supporting us with this webinar. And I hope to see a lot of you at EIC in Berlin, as Mario already said, and hope to have you back soon in one of our upcoming webinars. Thank you and have a nice day. Bye.