How to Ensure the Success of Your Privileged Access Management Projects

Good afternoon, ladies and gentlemen, welcome to our webinar. How to ensure the success of your privileged access management projects. Don't let your Pam projects stall successfully securing your organization against internal and external attackers. This webinar is supported by Dell security. The speakers today are me Martin. I'm the CEO, founder, and principal Analyst at Cole and Alan Redford, who is some specialist for privilege management, a Dell software. Before we start with the webinar, I want to give you some background information on call and some housekeeping information.

And then we directly dive into today's webinar. Copy a call is an Analyst company. We are providing enterprise it research advisory services, decisions, product networking for it professionals. So three types of services, which are our research services that include access to more and 500 reports. Our advice for services, where we support both vendor organizations and end users and our events such as the webinars and our upcoming onsite events. These include the European identity and cloud conference, which will be held next time May 10th to thirteens in Munich.

And in September next year, we'll do the digital finance world, which is focused on FinTech, blockchain, and all the evolution around the financial industry and new type of event that you shouldn't miss. All of these two events regarding the webinar, some guidelines you are muted centrally, so you don't have to mute or unmute yourself. We are controlling these features. We will record the webinar and the podcast recording will be available later by tomorrow. And that will be a Q and a session. At the end.

You can end the questions at any time using the questions feature in to go to webinar control panel, go to webinar control panel. There's usually at the right side of your screen, and there's an area questions where you then can enter your questions. The more questions we have, the more interesting the Q and a session will be. So if you have any questions, don't hesitate to enter them. You can enter these questions.

As I said, at any time, let's have a look at the agenda of today. The agenda as usual is split into three parts. The first part I will talk about why the entire Pam market or privilege management market is growing and why despite all this grows project, sometimes stall anyway. And the second part, then Ellen Redford will talk about secrets of successfully implementing a fusion real world, examples and recipes for success that avoid stalling Pam projects. So we hope to give you some information around what is this market about? Where is it moving? Why is it moving? Why should you do it?

And what are things you should consider to ensure success of your projects, as I've said, and that will be a third part, which is the Q a session that will then be at the end of our webinar. So let's start with a slide which looks at the organization's Crohns tools and which looks at what needs to be protected. And I think what we've learned over the past years is that there's a lot of stuff which is held in it systems, which can, if there's something going wrong, if it's attacked, if it's lost, which can massively damage organizations.

And so what we need to do is we need to find a way to protect these things such as branch reputation and branch reputation is what we've learned massively affected when you have a security incident or it might be massively affected. So when we go back some years, if there was something wrong in it, only a few people from the it professional and usually cared about today. If you lose customer data, if you have a survey incident, if you have a large blackout such as Twitter today, you might even end up as sort of the headline of the news and TV on TV in the evening.

Customer data clearly is one of the very critical, very sensitive data types of data. And when we look at so I'm from Germany. And when we look at, for instance, text data, which has been stolen from Swiss banks, which has been sold to German legal entities, and this is one perfect example of where it matters to protect that type of data properly because the customers obviously were not very happy about data leaking intellectual properties organizations.

And there's a, a recent survey which has been done by one of the security vendors, which said that more than 50% on average of the corporate values based on the intellectual properties. So if you lose your intellectual properties, have a problem. And then there's people which just a little different. So people are the other side of the story, but many of these ground rules are around data, around information or related to data and information, and we need to protect them. And this is becoming increasingly more complex.

When we look at the reality of organizations where everything and everyone become connected. So we have a world where it's not only about protecting a few central servers, but it's a broad protecting far more data, which comes from far more device and far more complex environments. We have the cloud, we have connected devices, we have connected things. We have all this stuff. So things are getting increasingly complex. And so the landscape we are dealing with this protecting data is more and more complex and what we have to consider over time. And this is sort of the next step.

So when we are running smart features in our customer's homes, when we are running connected vehicles at our customers, whatever else, then one of the obvious challenges we are facing is that we might need an administrative interface, but this needs to be well protected. The privileged access to these systems must be well protected. And then we have a problem, a far bigger scale than everything we have seen before, but even handling all the privileged access within your organization to the traditional systems is a huge challenge. And this challenge will grow.

So we have to start our move to privilege management now. And it's very interesting for me as an Analyst to again and again, see even very large organizations that don't have a privilege management in place. They might have a little bit of PDO or something like that for a few systems, but it's interesting to observe how many organizations don't have a enterprisewide strategy and concept and implementation of privilege management, not to talk about privilege management for things and dispar wise and all that other stuff. So let's move forward.

The other challenge, and this is something which is happening for a wireless that the risk surface is changing. So when we look at this, so with the blue text, this is sort of the very traditional way. So with an application administrator who was in charge of a number of applications and also the operating system below that application.

So, but it was a relatively and still is a relatively simple environment. So we had to protect an operating system. The application re indicated this what happened when we moved to virtualization, which is sort of a standard type of deployment in these days. So we had the application administrator, we have system administrators, which are responsible for the operating system and the guest operating system, or in former days, it would have been the sort of standard operating system. But we also have system administrators for the hyper wiser system administrators or the host operating system.

So we have even in a trust, a virtualized environment, we have far more people that have privileged access, which cannot administer systems, but we also have very, very extensive, very elevated privileges to a lot of virus, things such as copying data from a system.

So this risk surface has definitely changed from traditional to virtualized and it's has it's first, first changing is to move to the cloud where we then have our own application administrator, but we have also someone at the cloud service provider or DSP who is responsible for, or who's able to access an application with some administrative access. He might not access be able to access our data. He might be do we really know we have the same story as system administrator and all the other levels. So when we moved to the cloud, when we move to MSP models, we have even more privileged users.

So there's risk, surface changing. And also we have, when we move to the cloud, we have also just connection between the local and the, the, the cloud environment. And then we look at this and this is partially true for MSP CSP, but many of the stuff I will show the next slide are also true for, for traditional environments. We have a number of major risks. So when we move to the cloud, we have all the risks of internal privilege shared accounts.

So the major risk and the very typical risk for shared accounts of use list that passwords very elevated entitlements become sort of common knowledge at least of a group of administrators. So a lot of people might be able to access systems if you don't handle shared accounts and their passwords, right? People might have rights well above what they really well beyond of what they really need to do. So if you're rude, you can't do every single system, but you might only be have the responsible to do responsibility, to do certain things such as a bag or some configuration stuff.

But if you don't treat the stuff right, you might end up as people having far more entitlements than they need for doing their job. And this really remains true when you move to the cloud. When you move to CSPs. In that case, you also have to risk of an insecure communication, additional interfaces. So you must open up your system. And this is also something that traps in other environments.

So the more you have on the more your systems are distributed across sort of the entire globe, the more interfaces you need to have to connect to these remote systems, you have more administrators, but you have clearly also have internally risk of app use of privileges. And as we all know, internal attacks still are amongst the most critical most suburb types of attacks. When you go out, it's even more difficult to audit all the stuff and also to manage all the identities.

But basically we have a growing need for privilege management for all of our environments, not only our on-premise systems, but also our cloud systems. So everything we do should be done in a way, which is so big enough for changing landscapes. So look at not only at some of your core units or windows server or SAP systems, look at all of the cloud services, look at everything and think about what is the privilege access and how can you protect it. And then I think this leads also directly to another perspective.

So when we look at the, the traditional type of privilege, management's more around privileged account management or shared account management, but basically it's around. So on one hand we have personal accounts. On the other hand, we have shared accounts and the personal accounts are more around, okay. Martin could be logs in as Martin Kuppinger. And then he has certain entitlements, shared account means someone looks in this rude or with the administrator account windows or with super user account or database administrator account or whatever else there.

This is the challenge around how can you protect the password of a shared account. On the other hand, we have a situation where we have elevated privileges and elevated privileges also happen to be there for standard administra for standard users for standard power uses and SAP power user uses a personal account, but he has massively elevated privileges. So this is more about session management, the witness operator it's more or less the same, a windows operator frequently linked to personal account, but was elevated privileges.

On the other hand, we have then for instance, root, elevated, and shared, which is very critical, but so the, the area of elevated privileges, this is where out of types of technologies come into play. It's not only about shared account management. It's also about managing the sessions, understanding if someone app uses this rights in a session or implementing access governance for the more, the static part of the, the review. So this is what we need to do. It's not only about shared accounts privilege manage, or Pam is bigger than just shared accounts.

So, and I just a while ago created this chart, which shows sort of a approximate distribution of shared account versus individual accounts. So when you look at clients' probably most of the accounts and use our individual accounts, but yeah, still have a lot of low level technical accounts. So just service accounts, et cetera. When we look at network components, most access stands through shared accounts and web service. It's more a mix application service as well. Database server.

We see a lot of shared accounts because we commonly have the database administrator that are in, on the other hand, we have the, the technical and functional accounts, which, which, which are used to access the system and so on. So we have both and we have to cover elevated privileges as well. So what are the, the major risks we have to look at?

And there, there's a number of areas we have to look at. One is local privilege management. So how can we manage local access of privilege users and shared accounts? How can we, on the other hand identity and access management, how can we manage the identities and entitlements appropriately privilege session monitoring? How can we monitor the sessions and how can we ensure that nothing is done this sessions, which goes beyond what is allowed. We also might be need to restrict access to certain, for instance, commands and the Unix command line within a session anomaly detection.

So how can we detect anomalies in use of behavior? So is there something happening in a session which is not standard, which is very uncommon, how do we treat it and how can we audit all this stuff? So privilege management is a little bit bigger. It's a landscape where I would say shared account password management and session management are at the core, but we have other features such as anomaly detection, application, privilege management, and some other areas which adds to this.

And on the other hand, we have a number of integrations and when we do this and when we want to be successful, we, first of all, and I think this is one of the most important aspects, why projects stall, that they don't cover the entire breadth of privilege management. So you don't need to implement everything at one point of time. You also don't need to implement everything for all systems from the very beginning, but you should have a plan for it.

You should understand what is privilege management about, because if not, then you might end up in your project was identifying, oh, I addressed the wrong problem, or I didn't address. I selected the solution, which only come solve power of my problem. So avoid avoiding projects, stall means, understand this scope first, understand what this is about, which elements your solution should have, how you prioritize them, whether you can do it with one tool or set of tools, etcetera.

This is one of the very most, from my perspective, very most important reasons why projects stall, because you thought, or you started too small and privileged management is bigger and it's even it's growing further. So look at it from a perspective of a bigger type of solution, which also has to integrate with your provisioning. So who is the manager of your P accounts tries to integrate with system? So security information and event management and realtime security intelligence solutions, R TSI. So what is happening? How does this relate to other events, etcetera, this is what you need to do.

Then you need to implement a life cycle. You need to not only throw in a tool and say, okay, maybe it works. You need to understand your problem. You need to identify your accounts, you, your privileged accounts, you need to protect them. You need to monitor them. You need to detect what is going wrong. You need to respond, you need to improve your solution. So it's a process you need to have in place lifecycle for everything.

It's not just throwing a tool on it and hoping that everything works well, but changing its red landscape and all the changes you're observing, you have to constantly improve your implementation you environment. And from what I see, one of the biggest challenges in privilege management is security itself. So what I've seen is in, in many projects right now, not only once situations where the decision for a pro product, in fact wasn't done because I wanted security insecurity said, okay.

Yes, but there's theoretically that problem, which could happen to the centrally stored passwords, if that and that, and that that goes wrong. And I've seen it more than once that at the end, the organization, some two years or three years later, still didn't have a privilege management in place, which obviously is worse than having a solution, which is close to perfect. And the one thing we always should keep in mind and security, just why I bring up is to charge. The one is there's no perfect security, never, ever. We never will have 100% security.

And the other thing is the closer we move to the perfect security, the higher, the cost, the limit of security cost for security moving towards 100% is infinite. On the other hand, we have to understand our risks. So we can't spend more money for risk mitigation than we would have as cost of an incident. And we have to understand the lower, the risk, the higher risk. So we have to take these equations into account and look for solutions, which help us to mitigate risk in an adequate way, but for the perfect solution.

So let me end with, I've already brought up some, some reasons why projects sometimes stall, let me bring up some other reasons. Repeat some of the ones I've already mentioned. There are some generic challenges of projects, of information, security projects on identity, access management projects, where privilege management is a part of in general. So one is lack of sufficient budget. You need the budget. Yes. And it costs money. It's about risk mitigation. It's about mitigating the potential cost of incidents. And that's what you have to balance risk.

So the cost you, you have by incidents and the risk, so impact X risk, and this is your sort of what really can happen. And then, then you have, on the other hand, look at what does the cost, your system lack of available resources, internal and externally. Another challenge. There are not that many people who are really deep into privilege management. So ensure when you work with your vendor, that you have provide people on board and it's across silo project. It's not only about windows admins or Unix admins, or application owners of critical applications or network operators.

It's about all of them, which is not easy. So you need something which supports a heterogeneous environment. You have to bring the people on board specific challenges, accented security requirements. I already talked about it, lack of understanding for the breadth of the topic, leading to focus on point solutions. It doesn't help. You need to understand the press of your topic. Then you can start with solving it. But if you go for a point, so if you need to understand you are not at the end of your journey, the strengths, the weakness integration with specific target platforms.

Yes, it might be that some of the tools are better on Unix or on windows or so you have to balance those. Then there are two different types of approaches host based versus gateway based. So the ones are more sitting in between UN system. The others are executing components on the host. There are advantages in disadvantages of both approaches. There's not a perfect solution. Sometimes vendors offer a mix of it, have a look at this and understand what you can do and whatnot. And what is the best solution for you.

But don't shoot for the a hundred percent solution because there's no perfect way to solve all of your privileges. So there are not that many comprehensive of integrated offerings available. Some vendors have a quite broad range of offerings right now, including Dell, but it's at the end, it might be best of breed versus suite for at least for some of the features. And you clearly as always might end up as technical problems in detail. So I've seen a lot of stuff, whatever command lines, which are contaminated after the, after 80 characters, which can be a real problem.

It looks small, but it means you can't really work well with your today's consult. Or so there are so many small stuff, small problems which can happen. That's always a risk as well. But so when we look, talk about these, these, these risks and reasons why prime project stall, it's the right point to hand over to Ellen who will right now talk about secrets of successfully implementing a Pam solution, real world examples and recipes for success that avoid stalling Pam project.

So a, I will make you the moderator now. It's, it's your turn. Okay. Excellent. So thanks very much, Martin. So my name's Alan Radford. I'm a solution architect for Dell software, formerly quest software as part of the acquisition. So I'm in my ninth year in the industry now, and my team is responsible for identity access management in Amir. My focus specifically is privilege access management. And that's what I'd like to talk to you about today, about some of the projects that we've been involved in. So before I do that, I just wanna highlight some overlap.

There is with, with identity access management, in terms of complexity, privilege, access management. Isn't a generally very well known, very well understood subject. A lot of organizations aren't particularly mature in the privileged access management space, but maybe very mature in the identity access management space.

And those of you familiar with an identity access management project who, who may have also skipped lunch like me, might be looking at this sandwich with some familiarity because an identity access management project can be quite daunting to look at, you know, where do you start? Do you take a bit of cheese, bit of ham, break it up into smaller parts. It's usually the approach, but looking at a privilege access management project, it almost sets itself apart.

There are some similarities, but to a lot of organizations, privilege access management is this is this strange thing that they're not sure how to, how to cope with and how to deal with it until a problem arises. And that's, that's been our experience. So in light of that, there's been some different approaches that the organizations I've been engaged with have taken over the years in addressing some of these challenges, the most basic approach being of course, trusting our teams.

We might have a small team of people may have large team of people, but there are gonna be generic accounts that exist in the organization. Most commonly things like admin administrator roots, some of them may have default passwords that haven't changed in years. Some of them might be being changed regularly as a good practice, but these accounts would be shared across different systems and different users. And then an organization might look at this and say, well, that's not really sufficient to my needs. How do we address this?

So they come up with what I call the a dash model, which is a kind of split identity approach where we'd say, okay, well, Alan dot Radford can be Alan's normal user ID. That could be for his email, or it could be for logging into a workstation. But if we want him to do privileged work, elevated access, then we'll give him a different account, a Allen dot Radford, and he'd use that to access his target systems.

It's interesting to note that of all the organizations I've spoken to, the only ones who are running with this model and having it working satisfactorily are those with very small teams to the tune of five to 10 people because they still trust their teams. All they've done is changed the way they gain visibility as to what they're doing. Larger organizations that have many more privileged users tend to find this unmanageable because as you would expect, we've doubled the number of identities in our privilege estate. And now we've got different entitlements to keep track of.

And that can be a real challenge and actually enhance what in many cases is an already existing challenge. The more mature organizations will move through this model towards implementing a solution that will commonly involve something like a password vault or session management. And some of the other items that Martin touched on and these kinds of models, a user who doesn't have any privileges would request temporary privileges to do something through a single point of access and in, so doing the auditable and be able to prove compliance and get visibility and so on.

So those are the kind of approaches or the sort of spectrum, if you will, from left to right, that we see a lot of our customers going through. And when looking at these projects, the reason that our customers come to the table is there's usually a very long list and no organization, no two organizations the same, but at a high level, the five most common reasons for running an identity project tend to be around what you see here. Often accounts, not being able to have visibility of who's accessing what and how taking access approval away from the business.

So they need solution to actually get that approval model in place, having toxic combinations of accounts. And of course, the management of privileged users, we are seeing that, and we have done for the past couple of years now, actually seeing that cropping up in identity projects. And then when we look at more focused, privileged access management projects, it's interesting to know many of the requirements are actually the same with one very big difference.

Audit failure, the fear of an impending audit or the failure of a previous audit is by far the most common driver for a lot of organizations. It's not often we encounter a customer who is window shopping for privilege access management, if a customer wants single sign on, they might think, yeah, okay. That's nice to have they'll enhance the user experience in my organization. They might go looking for something perhaps to use up a bit of end of year budget.

But when it comes to privilege access management, it's not usually the kind of thing an organization goes, actually, I'd really quite like to have that. It's usually something they've been told to get rather than something that they feel like they should get. And then it plays into all the compliance things as well. So that's what we tend to see.

And in terms of the functional areas that we'd use to address this kind of requirement, there are a couple of different functional areas that Martin touched on that I'd like to expand on a bit, because these might factor into how you would scope a project like this. So when we look at password management, perhaps the most important aspect, if an attacker, for example, and there's been many public, very messy attacks recently in the media with various organizations that I won't list here.

But when an attacker is going at an organization, perhaps internally as well, if they get the keys to the kingdom, if they get those privileged accounts, that's really the end game. That's what they're gunning for. And so passwords are the most immediate area we seek to address. And those would be things like not just the generic accounts that we've spoken about, but also things like service account. And what's also often overlooked. Surprisingly is passwords that have been hard coded into in-house applications can be a really big risk.

Other areas might include session management where you seek to perhaps restrict a password so that we don't want the privileged users to actually know what the password is ever, but we still want them to be able to do their jobs and in doing so, we want their sessions to be recorded to a video and perhaps monitor those actions in real time.

And of course, how do we more finely grained control this access provide a path of least privilege or provide a path of most privilege, two different practices that are essentially two different tools for two different jobs, a path of least privilege where you might have a white listed command might be where you'd have a session, but a user can only do one thing or very few very specific things.

Whereas a path of most privilege might be where a user needs to do whatever they want, except there's some critical things that they could do in that session that you need to be alerted of, or perhaps restricting from being able to do on an individual basis. And then at a higher level, looking at the governance overlap, there are a lot of items in privilege access management that often aren't considered because privilege access management projects tend to be new territory for a lot of organizations.

If we consider a good old identity access management analogy of accounts payable and accounts receivable, never the two shall meet. If one person's doing both those jobs, there's a big compliance problem. But of course, if a privileged user had the, has the administrator account for both those systems, then perhaps that separation of duties issue hasn't really gone away. And these are things that the business needs to have visibility of and be able to control.

So in terms of an example, what a customer project looks like from our side recent project we had was with a customer who had around 20,000 systems and they had quite a large team of privileged users cause they're a service provider and they've got lots and lots of tools and processes and their compliance and reporting requirements are defined on a customer by customer basis. So not just their own internal requirements, but also requirements from all the customers that they're hosting for can be a real challenge.

And they found it very challenging to actually achieve and also prove compliance, which was a key requirement for them to be able to actually prove that their compliance to their customers and in, so reassure their customers. One of the customers they had, I remember was a financial institution who had a requirement that their, their own stuff was stored on separate bare metal by the service provider. And so with a mix of customers, some customers having that requirement, other customers having the more basic ISO 27 0 1 requirements and so on their solution needed to be dynamic.

And it also needed to be very, very secure and they needed to be able to prove that security under scrutiny. So their compliance was key to them. Their efficiency in delivering reasonable service or high levels of service to their customers was also key. And the cost of actually delivering this project when they had a very, very tight time window. And usually with customers responding to audit failures, not this customer, I should say, but more generally speaking, there's a very, very quick turnaround in terms of, okay, well, we've got an audit coming up.

We need to get the solution in before the audit takes place. Or perhaps we've been given timeframe by auditors to sort this out. So privilege access management projects tend to be very time sense to very time critical. This customer was actually able to use a combination of password management and session management to centralize the control and auditing of privileged access and able to be able to prove that to their customers. So the password management component and the session management component were different tools that they could use for aspects of delivering that project.

And with projects like this, there are some things that can trip you up. And some of those things that can trip you up really aren't too obvious until you actually go down the road of implementing a project. One of those stems from the poor understanding of the landscape. So Tamar's point earlier the need to understand everywhere in our environment where privileged accounts exists and how we're gonna go about controlling them really is one of the key aspects to successful project. And a lot of the times there's some assumptions that get made.

So when you look at these systems, think to yourself, what's the impact of these systems. We look at a database, for example, very good example, where databases often have many different touchpoints in an organization. A single database cluster may be responsible for many different applications, possibly an application that's responsible for accounts payable. Another one that's responsible for accounts receivable for arguments sake. So for privileged user is accessing just that one database. There may be more than meets the eye. Privileged users are also very often treated as standard users.

And this is a concept that I'm, I'm quite passionate about when I speak to customers because it's, in my opinion, one of the most critical aspects normally, and historically, we've had to assume that our end users are very simplistic people because by definition, we have to make things easy for them to use, to save them time and enable them to do their jobs. But a privileged user is the polar opposite of that. Literally the polar opposite. They are in most cases, the most technically proficient people we've worked with.

And so the tools we use to monitor and control and bring compliance to a normal end user and the tools that we would use to do the same for a privileged user have to be incredibly different because a privileged user, not only would, they likely be part of, part of a wider ecosystem that would be responsible for managing any solution you put in place, but they also know the tricks as a trade. They know how to break these systems. They know how to break cryptography and so on.

So we have to be very, very mindful and very aware when we put processes in place that the processes reflect what we want to achieve from our privilege access management project. With respect to that simple fact, there's also the concept of project creep. Now this is a little bit of sucking eggs, but we see this in any project, but particularly in privileged access management. And my advice to you on this point would be expected, expect some level of project creep to give you an example.

Often there's use cases that are unexpected until the solution perhaps goes through not just user acceptance testing, but out into production. And the unexpected happens. One of the best examples that sticks in my mind is when you look at ticket systems, if you say, okay, I'm gonna have a process where a user requests a password, and in order to request a password, they have to give a ticket number from our ticketing system. Perhaps they need to raise a change request, or perhaps there's an incident. So it's logged in our ticketing system.

We put the ticket number in to get the password out, but guess what? The reason I want the password is to fix the ticketing system cuz it's down. So what do you do? This is the kind of use case that exists in the privilege access management world that does not exist in the normal end user management world. And it can take you by surprise.

So, and I'll, I'll talk more about how we can mitigate this kind of thing in a moment. And another piece of advice I would give is take a baby steps approach, look at the big picture, but don't be too quick to consume the big picture. Start with very small baby steps and take those steps on a risk by risk basis. And finally, the understanding of security in order implications is less common, but it does happen requirements such as well. I want to have more than one person using a session at any one time. That's great.

But if an incident takes place, how do you hold one of those two individuals accountable? So depending on what you want to achieve, there's ways to be smart about it. So those are the reasons that we and our organization see Pam projects, both from our own technology and from many other different vendors' technology. This is what we see in the market. This is what we see happening. Mitigating these, we very straightforward. So what we know works is engaging the privileged users and this I think is one of the most important. Nobody understands your environment better than your privileged users.

They understand where everything is. They understand the technology. It's why you employ them, but they're also very familiar with the processes. And if you want to change those processes or layer some process on top, it's critical that you involve them early and get sponsorship from the very outset of the privilege users. And of course the business and part of that is also designating a pan team. So you're going to need some consistency.

When you look at these pan projects as well, you can't have different people in and outta the project because as you would expect that can really destabilize things. Nonfunctional requirements tend to get overlooked, not necessarily because they're not critical, but because it's a privileged access management world. So security tends to surface as one of the number one priorities here. But when we look at things like backup, high availability, storing information, storing logs, where are we gonna store them? How are we going to secure them?

If I've created video recordings of what my users are doing in my financial backend systems, then do I really want those video recordings being able to be put on a hard drive, for example, even if they are encrypted. So these are some things to consider. And we know that planning for these ahead of time, including these as part of your design, not just, yes, we need a backup strategy, but how do we secure our backup strategy will save you time. And then of course having an understanding of where those critical assets are, take a risk based approach.

When you take your baby steps and you embark on privileged access management project, look at what systems are of the highest risk or most critical to you and address those first. And as I sort of touched on earlier, use the right tool for the right job privilege, password management privilege, session management are two different tools for two different jobs. Think if you give a user a password and they take that password away, what do you know?

You know, they have that password, you know, perhaps how you structure the process, that they're the only person who has that password. So if that password is used to do something, you could prove it's them. But if they're using a session, maybe they need to know the password. So it depends on how you want to implement these things and what I want to do finally, before we take some questions, it's just look at how we'd round this out and built a maturity moving forward and perhaps touch on governance as well.

Because when we manage privilege access, in order for the business to have full control, a layer of governance is also necessary as well. So I define management as being to do with the who, what, where when, but when we talk about governance, we start talking about how and why we start building some intelligence around what we're doing. Perhaps for example, automating things like ATEST, enclosure remediation. There are real horror stories out there that never make it to the press.

And they surprise me every time the sort of organizations you expect to be incredibly secure often have some of the most amazing slipups one organization had an active directory ad domain administrator accounts that they had no idea existed for seven years. And because there was no governance, they, they weren't able to tell if it was being used or not. So this is something where maturity needs to be built into the projects.

Now that example I've given can be very easily mitigated by using privilege access management methods, but having the governance piece as well to control how often accounts are treated, can be made easy by building something in like a simple at process. And finally, I'll just wrap up by to touching on one of Martin's points around it, being a cyclic process. When we look at traditional user accounts and we talk about how those accounts are provisioned, we're all very familiar with some of the more common identity access management tools out there to achieve this.

But when we start taking care of privileged accounts as well, it's actually quite simple to build it into the same process. Normal user accounts and privileged accounts are largely created in similar ways, but there's technology out there where normal user accounts don't exist. Network switches, good example, no end user will use a network switch, but a privileged user will. So from a business perspective, how we govern the provisioning of these accounts may be very similar, but how we attest these accounts, who we grant access to with these accounts will be very different indeed.

And so over the people who are responsible. So that concludes a slide where I had prepared. And at this point I'll hand back over to Martin. Thank you, Alan. So I'll make me the moderator again.

Yeah, right now it's time for our Q and a session. And I currently ask the attendees to enter their questions. There was one question which came up, which is how do you get a copy of the slide X for of today's presentations, very simple, the same website you were justed. So copy a call.com then went. And the particularly when you will find slide X latest tomorrow, as well as the access to the recording of the webinar, if you have any questions, enter them now. So we have a number of questions already here, and I wanted to start with one question which came in, which is what or the hidden costs.

Have you seen crop up with these kinds of projects? Ellen, do you wanna answer that question?

Yeah, sure. So again, it depends from, from customer to customer, but some of the more, some of, with most solutions talking of pan for a moment with most solutions, there's usually hidden costs around services and the complexity of solution that you're putting into play. And the best way to mitigate those kinds of things is to run a proof of concept against the biggest challenges. I always see that as a good practice for any project. When you're looking at putting a solution in play stress, the solution stress, the people see how far see where the edges of the envelope are.

Take your most challenging use cases and run a proof of concept and see how far it goes. That'll give you an indicator as to some of the hidden costs around things like customization, but what we also see very commonly more operational requirements around, okay, well, I've got a software solution here. I'm gonna put a software, virtual hardware, sorry, a, if I take a password vaulting solution and I put it on one of my servers, how do I secure my server? How do I maintain and patch that host, how do I secure the vault that I'm putting in play?

And if that responsibility lies with the organization, then the ongoing operational costs can Mount up there as well. The only other one that comes to mind is by looking back at some of the projects that I've seen in my, in my history is the back to the drawing board approach that I, that I like to call it is where organizations try to run before they can walk. They try to do too much too quickly and in doing so things get overlooked and then they have to go back to the drawing board to re-architect what they're doing.

Those are some of the things that, that I've seen and that we've seen elsewhere. Okay. Maybe let's move to the next question, which just came in. If an organization is using the, a username model. So the model you brought up in your, one of your slides, can that be integrated with Pam? So is this allowing Pam to manage the credential for such an, a account? Any pitfalls, any cautions around it? Yes. Excellent question. So the model itself is essentially a logical model.

So yes, any, any privilege access management solution certainly should be able to, to handle both an a dash approach and also a more generic approach. The key really is individual accountability.

And I, and I can't say that phrase enough or stress it enough individual accountability. If your privileged management project doesn't deliver individual accountability for you, then you're going to have some real challenges moving forward. So when that a dash model and you put it in play for some organizations that works fine, a lot of organizations will say, okay, well, I've got, if I, if I take that customer example again, 20,000 different systems.

So 18,000 of these, I don't actually want to restrict access to. I just want to be able to monitor report on who's accessing them, but the other 2000. Yeah.

So those, I want to have an approval process. Those I want to have very strict controls. Those ones. I might have generic accounts being used, or it might be more appropriate for me to have a dash accounts being used and then more generic accounts for the other systems. So it very much depends on the organization, but the pros and cons for both, I would say, come down to how you enforce individual accountability. Okay. Another question I have is I have here is you mentioned password waling, waling, which sounds a bit like putting all one's X in one basket.

What steps can an organization take in securing and building resilience of a Walt like this? Yes, that's another good question. So first of all, redundancy is an absolute must. I like the eggs, all inbound basket example. I would add to that by saying, have two baskets almost as a, almost as a common sense approach. Really the ed passwords of an organization, the security argument really doesn't get any higher than that. So if we're going to take all of those passwords and put them in one place, not only does it need to be secure, but it needs to be available.

If a privileged user can't access a password to remediate a fault. For example, then all the time that takes is going to cost an organization money. If an end user can't log into their workstation, then they just pick up the phone to help desk. So it's very, very, very different worlds. I would also say that you'd wanna keep backups as well. Those backups you're gonna want to make secure and of course have a break glass strategy. So if your solution, if you, if for sake, you wants to have break glass on solution or process, you put in play, have a break glass process.

A lot of the time, it can be as simple as having a password written down in a physical safe, in other scenarios, it could be extending that redundancy model to have a, a different solution in play. Again, will depend on the business. Okay. Another question I have here is in terms of planning a Pam project, how would you go about sizing? Something like this? So I thought, I think Martin did, did a great job of actually alluding to this earlier, but I would, I would add to that inventory, everything.

So it's a lengthy process, designing a privilege, access management solution, designing how you're going to use it, what processes you're gonna use and how it's gonna look in your environment can be a very, very lengthy process. You may even find that you actually implement the solution for some use cases overnight, but designing. It could take months and months and months because you have to look at things like everywhere, a privileged account exists, and then how many privileged accounts are on those systems and then decide what's more, most important to you and prioritize that based on risk.

So an organization might just want to have more visibility. They might want to address a failed audit, or it might be something more specific. Perhaps they've got a problem with sudo in the Unix world. Sudo is something that you use for elevation. It's a open source elevation. That's very common in the market, but sudo has to be managed on a server by server basis. So if you've got 20,000 servers all running sudo and you want to change and access policy, you've gotta change it 20,000 times. So that might be more focused requirement for sizing as well.

Okay, perfect. I think we are done with our questions. I think we had a very interesting number of questions here, Alan. Thank you for participating in this call webinar. Thank you to all attendees for participating in this call. Webinar. Hope to have you soon at one of our events or in one of our upcoming webinars. Thank you goodbye, and have a nice day.