Hello, welcome to the webinar. And thanks for joining us here today. Today, we'll be talking about privilege access management and how we can solve some of the challenges or problems with automation joined today by Mark Warren. Who's the product marketing manager for who also supported the webinar just before we get into that, just a quick little overview of what Kuma Cole does. So we deliver, as it says, focus, content and services on identity and access cybersecurity and artificial intelligence, which makes us fairly unique amongst the Analyst Analyst firms around the world. So, and there's an overview of what we do. Research documents, Analyst briefings, advisory projects, and of course, conferences are big conferences coming up soon in may the European identity conference quickly to tell you about our new content and research platform up until now, most of our content has been available for down download, but with our new KC plus platform, you can directly access the content from mobile devices and pay once and you get to read it all for only Euro 800, or should I say 800 euros.
You can get to every piece of KC plus research, including the market leading leadership compass documents for 12 months quickly. As I said, the EIC conference is very soon now made at 12 to 15th in Munich. So if you haven't yet booked your place, there's still time to do so. And then looking ahead to later in the year, we have SEK, which is taking place in Amsterdam, then in Berlin, our famous cybersecurity leadership summit and the cyber access summit. And finally, in Stockholm, we have cybernetics world. Do you wanna find out more about all of those events and all the information is available at KuppingerCole dot com?
We've recently just started a new theories of online learning tools called KC masterclass. The first one is already live, which deals with privilege access management. These are interactive webinars. We also have recorded webinars to help you revise and go over certain topics. And we also have, at the end of each module, we have an all day classroom, a workshop with a final exam and the opportunity to discuss individual challenge with Analyst from quick housekeeping you muted essentially. So don't need to do anything don't need to mute or unmute yourself. So just sit back and enjoy. We are recording this webinar and we'll be available for you in a space of time. And we can also give you the slide deck for download. There are please the,
So I skipped over the agenda there quickly because it's not the right one, but what we will be talking about is the, what the character defines a privilege account. And then I'll be talking a little bit more about the challenges and market conditions, which are affecting privilege access account today. So we have different types of privilege account. We have individual versus shared in an ideal world. We wouldn't have too many shared accounts and something that I'm sure we'll be talking about a bit more later on. So, and also we have accounts that require interactive logins by humans. And then increasingly we have accounts that belong to machines or applications. We have it versus business and increasingly accounts. Then there used to be, it used to be just administrators, the, the guys that needed access to certain parts of the systems to upgrade or make changes or to delete et cetera. But now more and more people finding that they need access to privilege accounts to do more line of business type operations, particularly in things like marketing or accounting or large financial transactions.
We have servers versus endpoint. Do, do people need access just to servers or do they actually need access to endpoints? And also in access from endpoint, which is increasing complication and the, the mix of privilege accounts out there. What about corporate Twitter accounts? Increasingly social media is something that people that companies use and take very seriously to sort of project their public image. Some of these are automated and some obviously need should only be accessed by authorized people to make sure that the, the social media is on message. What about traditional versus agile accounts? We say DevOps is the new normal, well, maybe it's not quite the new normal, but certainly DevOps is becoming more important. And one thing about DevOps is that it's a, a much more agile and business leaders are looking to DevOps to help them develop the applications and services. That's gonna keep them a lot more competitive in the future,
Actually privilege accounts or privileged users where confined mostly to internal users, but you'll find with digital transformation, etcetera, but external users, including such things as managed service providers, suppliers, partners, and people in the supply chain are gonna want access or need access to stuff that's within your own organization. And you're gonna have to factor those into your pan strategy as well. So finally, it's all about the risk, which again is a bit of a broad statement, but you do need to, with so many more privileged accounts appearing, you need to really think about what is the risk of people having access to this. What is the risk of certain people having access to that and so on? So a risk based policy is something that you should really think about when thinking about privilege, access management.
So here's some characteristics of a privilege account. As we said, they obviously have high privilege. They have high risk. They're not in the scope of traditional identity and access management systems simply because those don't deal with privilege accounts. Quite often, there is a lack of life cycle management. There's a lack of request management and they're not associated with a person there's no audit, no auditability. These are all huge risks. If you don't have a pan system to control your privileged accounts, if your privileged accounts are literally just sort of looked after by, you know, a piece of paper or with passwords written down and randomly given out to various people, you're gonna find that it's gonna Contra nearly every single one of those things. There P accounts include personalized admin accounts as well as non-personal accounts. And the reason why these are high risk is that the, these accounts traditionally have access to the kind of data or company resources that are, are highly valuable and also highly vulnerable to bad actors getting in exposing confidential data, stealing confidential data, but also being able to damage critical systems.
So which privilege accounts pose a risk. And I won't go, you know, go through the entire it. But it's what I just said was these are the things that cyber criminals or nation state actors are looking for, particularly IP. This is stuff that should be protected anyway, but you can understand. And in the workings of business, at some point, people who you want to have access to blueprints and corporate strategies are gonna need it, but you need to protect those. The same is true of business data, such as M and a information, financial data, customer data, particularly customer data. This is where if privilege accounts are not protected, your company is liable to, for foul of things like the GDPR act or California privacy act. And then of course there is company confidential communications, such as board communications, HR. Again, you've got information there about individuals, which is valuable, social security numbers, pay numbers, even bank account details, all that stuff. And finally, because we are now letting in more people into our own organizations from supply chains, vendors, and customers, even the data that they provide is kind of doubling up all of that. So vendors, you might have access because of the two way nature of business. Now you may have access to privilege accounts within the vendor community, or your supply chain and all that data. And all that information that I've just mentioned is a risk if it falls into the wrong hands.
So what are, if you don't have Pam, how can it mitigate those risks? There is a very high risk of external threats, which is I've just been talking about. So target attacks by external tactics are always going to be directed at the most privileged accounts and way. Typically that they'll try and find those is they'll use things like LinkedIn. People are very public these days about who they are and what they do. They're quite keen to share information on LinkedIn. And most of the time people use that for legitimate reasons, but there there's also also people that troll for information. They look for people that work in senior positions. They look for people that work in senior accounting positions and they'll try and fool them into revealing access through techniques.
But there are also internal threats where you have so-called malicious insiders, which I, I think sometimes the malicious insider threat is, is, is perhaps overdone there. Aren't probably actually that many malicious insiders, but what they are is people who work within the business that accidentally do things that might put privilege accounts at risk. So that's something that all security software should be in my opinion should be aiming for, is to prevent people from doing those things by using technology. And particularly as Martin will be talking about automating certain functions so that they simply can't get access to things that might cause exposure.
These are just some of the I've already mentioned GRC. So I'll, I'll just leave this slide within the deck. I'm not gonna go through all these one by one. The TRC and compliance is now something that all businesses, whatever their size should take seriously, not just because they might get fined, but because it's a good thing to do. And it makes you a better organization is better for your public image. And it's better really all round to know that your data governance is up to scratch. So all those things, there are just some of the various compliance laws that could impacted if you don't.
Here's some of the things that P accounts may do to avoid insider and cyber attacks. So damage to people, we don't mean literally physical damage to people, but damage to reputation, damage to their personal details, et cetera, lots of information, information theft, blackmail. That's another way that bad actors can access privilege accounts. They will also use social media to find out where people might have certain things they want to keep quiet. So they will say to them will expose you unless you give us access to these accounts, et cetera, there's brand reputation damage. I've already mentioned that availability, risk disruption to the business, and of course reduce product quality. And don't forget also brand damage is something that is hard to recover from. If you think of those businesses that have had high profile attacks, people think about them in terms of, of, of those attacks.
So a little bit about digital transformation, which is something that is happening everywhere. And of course, digital transformation is a good thing. And most businesses are, you know, at some stage trying to become more digital, become more flexible so that they can generate better products. Cetera. So I'm just go through this here. This is a big slide and digital transformation is increasing the privilege access load. So what we see in the orange is kind of the traditional Pam requirements and they, they are probably complicated or complex enough. However, when we start looking and adding in the things that are gonna be happening with digital transformation, which are all you could add in there, IOT, but there's also things like artificial intelligence, excuse me, and blockchain, which are gonna be added to the mix once these things start being added in. So we have internet of things, microservices, containers, container platform, DevOps, and service desks.
The number of privilege accounts is gonna increase again. And the complexity of trying to manage them will increase again. And the conundrum, all the balance that info organizations have is, is trying to get the benefit of all these digital services whilst keeping privilege accounts secure and keep the cost down. So they benefit from the efficiencies of digital transformation. And again, one of the ways to do that is for much more of not just privileged account management, but all our services to be automated. So that stuff that a moment takes humans some time to do, can be taken away from them. So I just also software as a service there. So within that, to the mix, we've got vendors, workflow, software, and consumers also coming in. So that gives you a sort of idea of the upcoming access load on privilege access.
It's it may be a kind of obvious thing to say, there's no single solution for all requirements. And that's certainly true. But what we, we would say is that a basic Pam solution is better, certainly better than done at all. Once you have a basic Pam function of you can start looking at the things that we would suggest are important, like shared accounts or credential vault is obviously essential session monitoring, recording life cycle, and IGA integration. And now increasingly application to application anomaly detection. But we are looking forward now to things like pound for DevOps, which is you could argue that DevOps can already use Pam, but some vendors are looking towards developing particular modules for DevOps, particularly. And then we have cloud, sorry, integrated cloud pan, and also Pam as a service, which is something which is being developed, which takes away a lot of the management responsibilities from the organization. So if you want a good Pam solution, but don't want to actually have to maintain it itself, that is a good solution. But the key message is that there are, there are more Pam solutions available now than probably ever before. And there's probably one that will suit your needs.
So just the end of my part of this webinar, I just wanted to give you some key takeaways. So Pam once was sort of as a, kind of a siloed solution that simply protected the passwords and credentials to privilege accounts. And that was that it's increasingly something that must support the whole organization. Pam's gonna have to accommodate so many more people, temporary workers, contractors, partner, organization, developers, it security admins, obviously, but also web applications, machines, vendors, and customers, remote access. We talk a lot about mobile working and it has been around for some time, but we, we need to make sure that privilege accounts or privilege access management is gonna be ready for the kind of new workload of remote access where people are accessing from probably multiple endpoints. Pam's gotta be capable, accommodating new privilege access demands as they arise with digital transformation, with something we've been talking about. And as I've mentioned, if Pam is gonna meet these new demands, we need put a greater load bearing on tasks that need to be automated. So with that, I'll hand over now to Martin and let you take it from there.
Okay. Thanks very much, Paul. That was a great summary. So let me just start my, my deck there. So I think Paul did a great job there of a, an overview of why Pam is important. I want to take the conversation on a little bit from that and talk about how we can actually turn that Pam or good Pam practice into a business advantage. So that's what I'll talk about for the next few minutes. I can't remember if we said this at the beginning. I think we probably did, but if you do have any questions about anything that Paul's mentioned or I'm going to cover, please do submit them through the go to webinar panel and we should have time at the end of this to, to cover some of those. So let's get going. You know, Paul has already talked about how Pam is just so such an important skill and capability across the organization.
We've talked about large numbers of devices and hugely and far rapidly increasing number of devices and different kinds of devices, whether that's internet or things or web services or cloud services, but those things, those devices, those applications, those services are actually all across the business now, no longer is it the, the, the kind of keeper of that big room in the basement or in the back of the office where all the hardware is, those devices, services and applications are out across the business. And also the administrators, the people with those access to those privileged accounts are also out across the business. Think about your traditional database administrator. Yes, they may be in it, but the person that runs the marketing database is probably in the marketing team somewhere. So in a world where there's a, this huge number in diversity of devices, applications, and services, and it's growing at an ever increasing pace, it's a really complicated world and it looks a bit scary.
And because everybody is so overloaded and overworked, there's no wonder that shortcuts are taken. And that opens up a huge amount of risk, but I don't want this session to be just about fear and scary kind of outcomes. I think there's some real positives and POS and advantages to good management of privileged access and automation around that. So that's what I'm gonna be talking about in this session. For those of you that haven't come across a Syrian before we are specialists in privileged access management. That's what we've been focusing on for the last 10 years or so. We are based here in the UK, just the west of London over the last year or so. We've moved beyond pure privileged access management and particularly solutions for security based around automation. And that's what I'll spend time talking about today. First off, I wanna step back a little bit and say the life of an administrator is not an easy life.
Think about the many challenges that they face every day. Here are a few examples of the kinds of tools administrators have to deal with. Most systems administrative tools are highly powerful, which means that they're also very complex. And these are complicated user interfaces here. Even if you're using a command line interface, which is perhaps the preferred way of working for many admins, there are so many combinations of options on those command lines. This is no wonder that nobody could know every possible system and why you need to have domain experts. So the person that knows active directory, the screen at the bottom right here, isn't likely to be the same person. That's the expert on the firewall, which is the big screen in the middle. And that's worth spending a little bit of time drilling down into because there's one simple switch right in the middle here that defines what this firewall is going to do.
Is it going to accept traffic on a particular port or is it gonna reject it now that looks pretty straightforward. But if you hit the wrong button here, you either take your business off of the internet and you can't get any work done, or you suddenly open your entire business up to the world to be attacked. So clearly this is a high value high risk operation. So you need to make sure it gets done right? Which is why this kind of tool is reserved for experts. You wouldn't want non experts to touch this. Maybe even not another administrator within the it team. You want somebody who's a specialist, but what happens if you do need to delegate that capability to somebody else? Or what about if you have a third party that's actually helping to manage your systems as well. So it's complicated and it's not easy.
And these administrators are really busy. I don't think anybody ever said it are under worked and need more work to do. Requests are constantly coming into the it team from across the business. And here's just, you know, some, some examples of what might be filling up an inbox. Now, many of those tasks are relatively routine and relatively low value to the business. Add a new starter, create error accounts, provide some billing information from AWS is the eCommerce site up and running. And is it responding fast enough? Can you reset my username and password? And we keep hearing time after time that that is the most frequent request. It help desk just to reset a password after somebody's been locked out somewhere in that pile, there will be the high value tasks that need high quality. So for example, updating that firewall rule that we discussed earlier, but what makes that even more complex is that in the real world, people have a mixture of different hardware vendors, different device versions.
So updating firewall rules, you know, to open a port, whatever may sound like a simple operation, but do you have to find a Cisco administrator and a ju put administrator and a parallel networks administrator and an F five administrator cause each one of them knows how there particular piece of kit works. They won't necessarily know how the others do, and do they even know what the passwords, what the credentials are to log into those other devices, should they know, do you really want people sharing those credentials via email or post it note? So this may not be a task that's performed very often, but when it is performed, it has to be done, right? And it has to be done consistently across a number of different devices. And then somewhere in that pile are the really interesting pieces of work. The high value, the strategic business initiatives or the digital transformation projects that Paul was talking about.
Now, this is the interesting work. This is where admins would really prefer to spend their time. But if they spend all their time, just checking, if a server is healthy or resetting people's passwords, it's no wonder that they get dis charted and dissatisfied. And so we see retention rates of those skilled administrators is dropping. And also it's harder to recruit highly experienced people because the market is very, very volatile. Actually they're in much demand. So retention and recruitment of staff is a priority for a lot of it teams. So I said, I didn't really want this to be a negative session, but, you know, just consider a few of the potential problems that are out there in the, in the world. So what's the solution let's start looking forward and looking up a little bit. I believe that the solution depends on removing those low value tasks from those administrative workloads, automating them to avoid errors and manual manual errors are happening all the time.
So that introduces rework. So again, more boring stuff and ideally being able to safely and securely delegate those administrative tasks. So let's see how that can be done. And I think there are a few basics to the solution. The first is to understand the principle of least privilege or another way of saying it is to say that the right level of privilege is given to the right people at the right time. Now there will always be some people that need root level access to a server or to a device, but that access should be reserved for the most experienced and most highly trained members of the team, because the damage that could be done, if those root level credentials were compromised is huge, compared that to a normal user, perhaps somebody on, on, you know, the call center or whatever that really has, you know, a lot of access to databases, but not very much update access.
This chart tries to show that there's a, there's a kind of blast radius associated with each of those different levels of capability. So for normal users, credentials are compromised. The potential impact of that compromise is relatively low. Whereas if the route server access is compromised, the potential blast radius could be very significant. Indeed. That's where discs file systems get completely erased databases get erased, firewall rules are opened up so that attackers could easily get in. Perhaps another way of looking at that is to switch it around and start looking at levels of isolation around particular applications. So imagine that the most granular, oh, so the highest level we've got a server, some kind of machine that's running some applications. So some people need access to the server. Some people need access to a whole application and some people need access just to a specific function.
So for example, most people may need to be able to do a reset password function within the active directory application. But if you give them access to whole application, they could potentially do things that like change somebody's permission level or delete an account. And if you got access to whole server and not just the application, they could delete the whole active directory database, which is clearly a very dangerous thing to do. So this is where Pam comes in. So privileged access management is about isolating credentials at the server or at the application or at the function level, isolating the application to just the people that need access to application or isolating a specific function to allow people that need access. Just that one function. If you, if you like another way, think about this, that, that isolating the application could be considered a kind of dedicated remote desktop into just the app, which might be the active directory console.
It could be a SQL server management console or whatever, really. You want to get people accessing those systems at the lowest level possible down to that function level. And that's great. That gets you a long way in, in increasing your security, increasing your well reducing the risk of compromise and of, of the damage done. When if, if you should be compromised, where things get really interesting is that most operations actually need more than one application to be involved. Now, if you can isolate each function in each of those systems carefully, and then you can start orchestrating how they work together, then you can start doing some really interesting things with it and business processes. And this is what we at a called privileged process automation or PPA. Now it might be easier if I actually show you some examples of that. So here's a here's one example.
This is something that we found actually running here inside a, our finance team, get a regular invoice from Amazon for some huge amount of money. And they wanted to know how our AWS usage was, was being allocated. You know, which teams are using AWS, how are they incurring? These costs are the bills correct? Now, traditionally that might mean two, two ways to solve this problem. One is you try to train somebody in the finance team, how to log into AWS, how to navigate this management console, how to find the information that they need, of course, to do that. They need administrative credentials. So do you want to give somebody in finance, the login details for your AWS management consult? Well, most places that's probably not the right answer. So in that case, finance has to call it to find the information that they need to do their accounts payable.
Reconciliation. Of course, it don't really want to be doing this. That's a pretty low value task. It's pretty boring. Oh. And by the way, they'll probably get it wrong. They'll get the information out of AWS. They'll send it to the finance team and the finance team come back and say, oh yeah, sorry. No, I wanted the three months before that, or I wanted this additional breakdown. And so you go around that loop several times, trying to complete what seems like a simple task actually starts taking quite a lot of effort from it where they could be spending their time doing something more interesting. So that's something we've wrapped up internally here in PPA and privileged process automation. So you get this browser based conversational experience where the finance team can, if they've been permitted, they can connect to this task. They can say in, in the some simple example, how many months of data do we want?
What currency do we want it in? And then behind the scenes, PPA connects to AWS using those administrative credentials, which are never exposed to the user, navigating the management console in AWS, extracting the data and pulling it down to present on the screen in a beautiful interface here or making available to be downloaded in a spreadsheet format that finance have already agreed is correct. So, although this is only automating one system, it actually includes a number of different operations and different steps against the AWS management console. But they've all been wrapped up in this very simple user interface. And now we don't have any fear of letting finance source the information for themselves because they can get the information they need, but they can't do anything else. We've completely isolated this particular function. So they can't get out and create additional user accounts or delete virtual machines that are running in our AWS instance.
So we've got secure automation of a business process. Now here's another example, which is a little bit more complicated. Imagine when you have, and this is, you know, the second most requested thing I think most help desk have to deal with after the password reset is, is imagine you've got a new starter coming into the business. Now there's a lot of things you have to do to make your business ready for that new starter. But one of the most important is making sure that they have all of the accounts and logins that they need into the different business systems that they will use to get their work done. So oftentimes HR will notify it that there's a new start coming in on Monday or the first of the month or whenever. And the, the help desk agent will log that request in their service management Porwal Porwal Porwal, which in most cases, many cases is ServiceNow.
Now in ServiceNow, it would work through their predefined workflow in ServiceNow to make sure the data is collected correctly and approvals are in place. But at some point, the automation in ServiceNow turns into somebody doing some real work. And at that point, ServiceNow sends out notifications to all of the relevant teams that a new account needs to be created. And this is the name of the person and their manager and whatever other information is needed. Now, no one administrator will have access to all of the systems and nor should they, that's a dangerous thing. The person that has access to active directory, probably isn't the person that knows how to control virtualization environments are VPN access. So all of these tasks are delegated out to a number of administrators and they all come back at different times. Somebody may be able to do the work real quickly.
So they reply within seconds or minutes where others may be busy on some other projects or outta the office. And so they'll get back to it when they get a chance and that could be days, weeks, or even months before all of the accounts have been provisioned. And that new starter has all of the tools ready for them to get on with their own work. So clearly this is not a great situation. And especially if we start considering the shortcuts people take in saying, well, let me just borrow your credentials. And I can, you know, one administrator says, give me your credentials. I'll sort it out for you. Don't worry about it. Because at that point I'm starting to share some very valuable credentials, but also I'm starting to dabble in a tool that I don't really necessarily know how to use. So this is again, is where previous process automation comes in, PPA integrates directly into service now.
So that once that automated workflow in service now has completed, and the change has been approved, it can automatically invoke a previous process automation process or task, which if you like is like a black box, which behind the scenes talks to every one of those systems using those privileged credentials, which are all protected within the PPA environment, never exposed to help desk, never exposed out to HR and provisions all of those accounts. And so what used to take days, weeks, or months can be completed in minutes. And the ServiceNow ticket is automatically updated to say the task has been completed. And here's the audit trail of all of the changes that were made. So rather than try and find the, if you ever had to do that investigation into how the changes were made, you don't have to go and find 6, 8, 10, 20 different log files that are all available in one place.
So again, we've isolated, the credentials, we've isolated, the functions, we've isolated the applications and wrapped them all up in this very simple transaction. Now, if you've got that level of confidence, which you should have, that this automation is going to work, new opportunities arise, why don't we let the HR person or the new starters manager, somebody out in the line of business invoke the process for themselves. At that point, there's no need to wait for administrators to be available. The credentials have never been exposed and a phrase that the serum have been using since almost day one, which is delegate the task or other people say shift left the support request. So we are not waiting for valuable admins to be available. We can move that left and move it out into the business and let our business partners do the work for themselves with the confidence.
They can't do anything they, they shouldn't do. And that we've got a great and detailed audit trail around all of the changes that that were made. So this is what that looks like. I know it's really small on this screen, so don't worry about it too much. But again, it's this kind of conve conversational interface where we'll collect the information that's required. We can go back to the operator, whether that's a help desk agent or the person out in the business to verify the data is correct, or maybe make some choices about, say, for example, what groups this new starter should be included in. We can also have management approvals integrated into the workflow as well. And once all that information is completed, then we can go ahead and go off and hit each one of those backend systems to actually create the accounts that are needed.
Again, no credentials exposed, no need to know how each one of those systems work. So those are just two relatively simple examples of what could be done with PPA. But process automation is a very open framework. That's very easy to install and configure on the left hand side, we've got the different kind of user types. So whether that's a user that connects through the PPA task gallery, where they can see just the tasks that they've been authorized to use. So HR could do HR kinds of things, and finance teams could do finance kinds of things, or through an API. The user can use a system that they're already familiar with, whether that's service now, especially if you are in a service desk yourself or through your, your corporate employee, Porwal connect to PPA as just part of your normal workflows or automate again through legacy applications or through task scheduling.
So different ways of driving the task, the same task can be driven in those different modes and talking out to a wide variety of backend systems. I've just used a few examples here with active directory and info blocks for software defined networking, but that open architecture means that we can drive just about any kind of device or system or application that has some kind of privileged accounts. And of course, put down to the bottom right there. We have this rich audit trail that shows you exactly what happened through every process, regardless of how many backend systems were updated. So there's one place to go and find that audit information. And there's no doubt that automation has great benefits. This is some data from one of our customers and they were just doing a very simple server health check. They had to check that service are up and running and responding fast enough.
And they were doing that multiple times per day. It used to take 30 minutes every time they did the health check, which is equivalent to over 800 hours a, a year when they got that down to 10 seconds, that just becomes a ridiculous amount of time freed up over the year. They calculated, they saved over 200 days effort. That's the equipment of a full-time employee. So what would you do with an extra person in your team? All of those business initiatives, all those digital transformation projects that really need focus. And it's not just us saying this. This is some data from the PON report on the cyber resilient organization, the red bars show on the left hand chart, the red bars shows organizations that have automation and the blue bar is the average. You can see that companies that have automation have fewer cybersecurity breaches, and they have less impact when they are breached.
If they are breached on the right hand side, the red bars confusingly show, oh, sorry. The red bars show how much more resilient organizations are. Should they be attacked in different ways, whether it's preventing or detecting or responding, importantly, responding to a cyber attack. So that's about how fast can you close down the firewall that was opened? How fast can you quarantine a machine? How fast can you roll out an update? And automation is absolutely critical. So summing all of that up. I hope I've shown you how you can reduce risk through previous access management in particular with isolation of credentials and applications through automation. So you're reducing errors. You're reducing the effort spent on low value, low impact tasks and freeing up resources to work on. The more interesting business strategy and business initiative kinds of tasks and PPA ed process automation is part of a Syrian's privileged access security suite, which also includes our core Pam solution.
PPA can actually be standalone and work with third party password vaults as well. But Pam is our privileged access management solution. And recently we've introduced P ed endpoint management to control and manage execution of ad of, of elevated privilege on endpoints as well. But I haven't got time to talk about all of those today. So I've got through a lot of ground there. I hope I've made some sense and made the case for Pam with automation to make a difference to your business. And I look forward to hearing your feedback and any questions you have. So with that, Paul I'll hand back to you.
Thank you very much, mark. And I think I didn't call you mark earlier on. Sorry about that. No worries. We do have a couple of questions. We haven't got much time, so I'll whi through them and you can see on the screen at the same time, the related research, I won't go through that. Pam sounds a lot like identity and access management. What's the difference? Well, you've got minutes on that.
Okay. So for us, we, we see them as complimentary. So identity access management IAM is more about proving who you are, so that may be provision, but you know, there may be there's different ways of doing that. It could be through username of password. It could be through multifactor, a education bio, or whatever, and it often talks about things like password, life, cycles, nothing other, and that's, that's important and things that should be looked after, but for privileged access management, we see that as what can you do once you've told me who you are. So when I connect to my Pam system, I'm presented with, well, certainly through a serious Pam solution, I'm presented with shortcuts to the systems, the devices, servers, the applications that I've been granted access to that provides me a real quick, short way of getting to say that firewall that's in Paris, that I need to make a change to, even if I don't know the actual server names.
And it also takes care of injecting the credentials to let me log in as a, as the administrator on that device. And it presents to me either the SSH terminal or the, you know, the RO remote application access to actually do the work I need to do on that particular device. So it's saving me a bunch of time is protecting the credentials and it's watching what's going on during that session. So it can do session recording, which could be used for water purposes or for investigation later. So identity management, who are you making sure that identity is correct? And then privileged access management is what can you do now that you've told me who you are and managing those high value or those potentially high risk operations against shared it services and devices.
Thanks. Mark got time for one more. I think actually this, the PPA automation looks a lot like RPA.
Okay. Is,
Is it
In, in some way there's, there's an overlap there and it's, it's common one. I mean, you know, the lessers are very close to each other, so you can understand that's one. Yeah. It for RPA, you know, the whole point about that is the robot trying to reproduce what a human being does. So RPA tools spend a lot of time and money and some great innovation in trying to be as accurate as human beings in reading what's on a piece of paper or reading what's on a screen trying to understand where that content is and then deciding what to do next. And so emulating at that point, you know, fingers on a keyboard or mouse movements in attended RPA, that's typically running on an endpoint. So it's automating how I copy and paste data from one spreadsheet to another. That's a useful thing to do cause that's really boring work, but that's not the kind of thing that PPAs after on a server, they might be, oh, I've just scanned a new document.
I want to unpick the invoice number and supplier ID and the personal order number and feed that into my payment system. That's okay. But it only makes sense to automate if you do it often enough. So if it's a transaction that has to be performed tens or hundreds or thousands of times per hour, then it's worth spending time spending the months it takes to learn how to process those documents with a reasonable level of accuracy for PPA, the tasks tend to be not always, but tend to be more ad hoc. So in response to requests, I want to reset a user's password, or I want to create a new user account, or I want to change this DNS record in my, in my routers.
They aren't necessarily done hundreds of thousands of times per hour, but when they're done, they need to be done to correct policy and procedures and follow the right steps and have an audit trail. But because the automation building that automation in PPA is actually very fast, it's worth automating it cuz after you've performed that same step, that same process two or three times you've already paid for the amount of time it took to automate it. Also PPAs built from the point of view that we are protecting access to privileged accounts in those systems. Whereas RPA, it's very unclear sometimes exactly what credentials are being used to connect to those systems and, and what level security they have and you might lose a traceability. So that's, that's another thing
For us. I'm sorry. I'm gonna have to break you off there cause we are literally running out of, we got seconds. Sorry Paul. That's fine. Thanks so much Martin brilliant webinar today. Thank you all for listening. And also don't forget that if any of your colleagues want to hear it for themselves, it will be uploaded to our website. Thanks a lot again. And hope to see you soon. Bye for now. Yeah.
Thanks everybody dropping.
