The Compelling Need for Privileged IT Process Automation

Good afternoon, ladies and gentlemen, welcome to our cold webinar. The compelling need for priv privileged it. Process automation, increasing productivity, efficiency, and security while minimizing human effort. This webinar is supported Byer. The speakers today are in Harris. Who's C of our Mark Warren product marketing manager, and me Martin around principle Analyst at co Cole. Before we start some quick information about a Cole and some housekeeping information for the webinar, and then will directly dive in the topic of today's webinar.

Cole is a call it global Analyst company, focused on identity and access, cyber security, artificial intelligence, and some adjustment areas. And we deliver a variety of services from our research, such as executive view reports and leadership to our Analyst, Analyst briefings and inquiry calls our webinars, advisory projects, conferences e-learning and other types coffee events.

We do this in three pillars, which is the content, which is the community and which is the so to speak coaching the advisory in research, we have formats such as our leadership compass, which compares vendors in certain market segments. Our executive view reports focusing on certain specific products, the advisory notes, strengths, and other background information and leadership briefs, which deliver very focused information on certain business challenges.

In advisory, we deliver our services for strategy for portfolio management, for technology selection, and for project guidance through our strategy portfolio tech and project compass, our standardized highly efficient methodologies that support customers.

And then there are the various events that we run many webinars, and we also have a number of other events, specifically our various one side events, which should run this year in Ottoman, winter, around digital finance, blockchain, cybersecurity, consumer identity, and other topics, which that lets quickly move to the housekeeping audio control. You are muted centrally, so you don't have to care about that. We are recording the webinar and we will provide both the podcast and the slides Friday this week or Monday.

And then we have a Q and a by the end, the more questions we have for the Q and a is, so please enter your questions once you have them so that we can pick them for the webinar. With that, let's have a look at the agenda of today's webinar. The content as usual is split into three parts. The first part I will look at privileged access management and some of the challenges privileged, privileged access management is focusing today. And these are specifically around how to sort of minimize the, the, the cognitive load people have when accessing systems for privileged tasks.

So how to make these things simple, how to also in consequence, mitigate risks of people, having too much of access to many capabilities they could use when they only need a very small portion of that. Then the second part, Andy Harris and Mark Warren look at umthere approach for P it process automation, and how to do that in a mix of background information and the short demo. And in the third part, then finally we will look at or do the Q and a session.

So again, the moral questions we have, the better it is because we then we'll end up with a very lively discussion. So let's start with a, a very simple thing, which is what is privileged access management. So it's not privileged access and privileged accesses from my perspective, power definition, more than trust administrator or operator access. It can be it access it. Users can be also business users. And the definition I prefer is one which looks at the level of risks to say, okay, if the risk of this access is above a certain defined level, then it's a privileged access.

If not, it's a sort of a standard access such privilege access can happen on both ends the root admin of critical server, the SAP power user, whoever all of these types of access can be critical and privilege. And it's about access. So obviously privileged access who is doing what on the system access a broad term from the authentication to the authorization, what concretely standard usage. And it's about managing that. So privileged access management is really looking at a certain type of access, which is more critical than other access.

And it's about mitigating the risk of these types of access. So why do we need this? Why do we need privileged access management? What are the reasons for that? And there's simply said from my perspective, there's absolutely no argument for organization not to have privileged access management specifically for medium size to larger organizations, specifically for organizations in which are facing massive regulations, which are a heavily regulated environment, or which are dealing with high risk data, which have sensitive data to protect.

There always are good reasons for having privilege management in place. One is risk mitigation. It's really about mitigating the risks associated with privilege access. It's about compliance. When you look at least privilege principle and other regulatory compliance requirements, and you look at what auditors are looking at when it comes to sensitive data, then P access management very frequently and very rapidly comes play. It's about cyber attack resilience.

The attackers are always after the highly privileged accounts, the ones which can cost the biggest damage, which is the most information to the attacker. It's about security, about protecting systems against malicious use and fraudulent use and human errors. And that is another it's about splitting responsibilities. So just saying, okay, there's the system. And we have to full admin super user route, whatever access means that too many people have two big capabilities compared to the responsibilities they usually have. They usually only need a little bit of that.

Another important aspect is the MSP to talent relationship. So the management service provider to talent relationship it's about controlling by the MSPs are doing it's about restricting their access to the minimum, keeping a grip on that, to which extent do you trust? It's also about workforce enablement. If you have it's about looking at how can you enable your workforce to do the critical tasks that is already hi hiding, or that's already guiding to what we are talking, we'll be talking next.

That's about, do you do access management the way that it works for many people here, the, the aspect of task based produce management comes to play. And finally, if you do it right, and if it's restricted, so really this more advanced approach and management, not just giving someone full access to a server, but restricting it again, dealing well with that, that is also about avoiding human error. That is massive risk of human error in all these activities.

And the more privileged they are, the more, the bigger the risk is if someone has a lot of, or is about to do a lot of things, because it's accessing this route to use or whatever, then the actually can cause a speaker. And if you make some mistake that the consequences can be far more severe than when we try to restrict it. So ed access management is not only about granting access. It's about mitigating the risks of that access. That is why we should do ed access management and basically is about restricting the elevation of privileges.

So PED access management and right means that people can use the, do the right, perform, the privileged access they need, but not more than that. And so to starts with permissions, one of the things to do is restrict the provisions fuses for all of their tasks. That's the first thing. That's also about entitlement. And that's sometimes also discipline outside of, for Pam. That's really more standard provisioning and identity governance administration piece. The second lenders access enable the access of these people.

So match the access to the, to the systems, but also make it easy to access what people need to access across all these systems they have. Then it's about looking at the actions. So what can they do, how to restrict this, how to monitor this, how to avoid as things go wrong, the more critically accessed the higher, the risk, the more important this becomes. And then it's also about ensuring that this task can be ex executed as easy as possible because at the end, there's always this factor of human error. So the best thing, what you can do is to say, okay, these are simple tasks to execute.

The more repetitive it is. Yes, there are things which require full control access because you have a major issue here, and it's not an automated thing, and you need that super experts to do it. But many of the things that require privileged access are repetitive, creating user accounts, changing certain types of configurations, moving configurations from your development, your test to your production environment. Many of these things are repetitive. They also can to some extent be automated, but also they need sometimes still some human intervention and some human work.

So when we look at the approaches for privileged access management, it's not that there's a one single solution, but there's also some sort of an, I would say, an evolution in what is done within privileged access management. So the, the basis of what we see in privileged access management is really around passwords. It's a shared account, password management, avoiding this sprawl of passwords, delivering one-time passwords for access to privileged sessions. That is sort of at the core of, of British access management. That's an important thing.

Avoiding passwords, sprawl of account passwords, etcetera. So many of you might have observed these scenarios where a couple of admins are sitting in the same room and one shouts to the other end of the room and says, oh, do you have made a password for that machine or the password for that machine?

We, that that must not happen. There's another element, which is not usually not Pam, but which is closely related to that. I touched it already. It's entitlements. It doesn't focus on the static entitlements, but obviously we should ensure that people are only, or accounts only have the minimum entitlements they need, but it could still, even if you have certain entitlements, you still can use them the wrong way and the bigger the entitlements. So who accounts other super user accounts, the more things can go wrong. So we need more of that. And that is sort of reducing the elevation.

So the privilege elevation management is, is focused on ideally only elevate privilege is temporary or restrict certain abilities for instance, at a command line or other things. The challenge with elevation management is that it's very system specific.

So it, it's more intrusive, it's more complex to handle, but it's an another important element. Then we have this usage aspect. So what about what is happening in this session for our principles in session monitoring the recording for the forensics afterwards, which doesn't help to avoid error anyway, but also the ability sometimes to restrict. So working sort of hand in hand with privilege, elevation management might also be combined with advanced user behavior analytics and other technologies.

And then we have these tasks and the task management is one of the areas, not that frequently found in the Pam products of today. So we see some, we see not much of that, but factually it is about looking at what are really the granular tasks. The people using the systems really need to perform. As I've said, there are scenarios where you need a broad access because it's, it's not a standard repetitive thing, but many, many of the things people are doing this privileged access are repetitive. So we can automate, we can standardize.

This goes very, very far beyond the traditional administrative operator task as well. This is really also a lot of stuff which is more done by, by standard help desk workers, etcetera.

And, and one of the, the interesting things, and I'm sure Andy and mark will touch those. One of the interesting things is you can shift workloads from the resident level three support levels, one support by making them easier to perform by minimizing also risk through task. So when we look at these various areas of P and service management, IGA and process automation, then from our perspective, it's apparent that all of the, these have their value, but for themselves, they don't. So of the full extent of the problem, the ed access management is really good.

When you look at this full access of administrative operators, monitoring tasks, stuff like that, but it's not good and, and deliver our credit granularity or making complex tasks, complex privilege tasks, easier to perform for a broader group of users. It service management on the other hand, looks at automated meeting service and support processes, but frequently lacks the death when it comes to dealing with the specifics of privileged access. So how do you really control what people can do? How do you really enforce the, the least privileged for these tasks?

How do you work with granular technical tasks, which span a variety of systems IHA on the other hand is more focused on aesthetic entitlements. However, if you have certain entitlements, for instance, you're allowed to back up certain data and you do it more than once. IGA will not tell you because it just looks at the static entitlements, not the way they are used. And that is where we need to look at more the task based stuff and things. And I think it's a good, good, interesting approach. The brings in here is what they call privilege process automation.

So how can you really automate processes between Pam it service management to optimize the execution of privileged tasks? How can we streamline these processs? And we have a lot of process management tools, but when it comes down to, we need hear a little of, hear a little bit of British access here, a little bit of that, and that system, et cetera, those things become increasingly complex. So we should go beyond restricting the administrator access. So not trust restricting the login. That's a important thing, avoid passwords for ensure that these things work well.

It's also important to monitor access. It's interesting to have simple tasks, but the challenges that many of the processs are not a simple task, but there are chain of tasks. And that is where, where, where the, the interesting fee starts. How can you then really run these process such as you do also with, with it service management, but in the context of privileged access to a variety of systems, which need a very granular control. So British process automation is an interesting field, which has, from my perspective, a huge potential to optimize workloads in organizations.

So it's factually it's really about optimizing your service desks, sort of providing the link between the service desk, the ITSM world, and the privileged access management. So it's about simplifying the work less complexity reduces human errors. It's about automating what can be automated it's by the way, also about documenting what you automate doing it well, doing it centralized, not having hundreds of dispersed scripts where two years after, no one knows what in how these scripts work anymore.

So well-documented stuff, et cetera, train your team and ensure that people can do stuff because these are small and granular and optimize task. They weren't able to for roll out, maintain the solution, ensure that it's well documented that people understand monitor what happens, improve it, and look at both security aspect and the effectiveness of pure automation. So there's a, from my perspective, there's, there's a need in potential in doing so. And with that, we, I hand over to Andy and mark, which try now will look at how a theory is approaching that and also show demo of that.

So Andy and mark, it's your turn. Okay. Thanks very much, Martin. That was a great overview and summary, and really set the scene very well for what we'd like to talk through the next, next few minutes. I'd just like to reiterate some of the, the really key findings there that, that you mentioned Martin, and that's the kind of need for the need for automation and need for managing privilege. And let me step back a little bit and, and think, and, and discuss some of the reasons why people need automation and why traditional solutions for automation.

Aren't really up to the demands of modern secure it. Automation has been a great answer to the problems that many it administrations face, but they feel the pain of highly complex, quite detailed operations that have to be performed multiple times.

And there's a function of combining the pain with the number of times that that pain has experienced a repetition of a task that increases the need for automation and traditional solution for automation, haven't really kept up, kept a pace with those demands and the it admins have been very, very good in the past that automating all sorts of things through various forms of scripting, they may be using bash scripts or PowerShell or Python or any one of a number of other languages that are spread around the estate these days.

And oftentimes there's more than one, one language in use, but it's very risky because you've got highly expert experts, admins specialists on one or a few topics inside the organization say that database administrators really know how to manage their databases with great efficiency and great security, but maybe they aren't the right people to be worrying about software defined networking or the right people to be worrying about how the finance team work with their, their accounting package.

So you end up with many experts with lots of detailed knowledge, and it's really difficult to share and combine that knowledge. And as we see as we go through this, the, the modern world needs multiple experts, multiple areas of expertise being brought together to deliver a solution. I call that islands of knowledge, the islands are beautiful by themselves, but they're not very well connected.

Another weakness with automation today is that if they need to connect to these systems with an elevated level of permissions, as, as Martin was describing where they're introducing more risk to be able to achieve more valuable outcomes, they end up doing taking shortcuts because it's really difficult to manage secure connections to servers and services and devices. So you end up with unfortunate habits like putting passwords or tokens or certificates in source code or in scripts. And we've seen some examples recently of GitHub and GitLab repositories being hacked because of script.

Those secrets been, been, been found inside source code depositories, and overall, it's really hard to get a view across the entire infrastructure or entire state and say, what scripts do we have? Where, what do they do? Who built them, who last updated them, who has access to them? And if you want to execute a number of steps, where do I go to find out whether those steps completed correctly or not, and, and who has access to all of them? So it's really, really hard to get the visibility of control.

Now in the business world, a robotic process, automation or RPA has been getting a lot of ground over the last year or two, and they're doing great things in transforming highly robotic, standardized processes for most businesses, many businesses, things like handling your insurance claims, et cetera, but they often have features such as document scanning or obstacle character recognition and screen recording because they try to emulate human behavior, but they don't really understand complex tools that need a high degree of interaction.

And they don't really know how to handle privileged accounts and privileged secrets because that wasn't really a priority for their, their creation. So let, let's take a look at what that, that might look like. This is a very abstract example, just to illustrate the point. We'll see some real code in that's demo in a moment, but on the lefthand side, here is a kind of stylized script that has demonstrated a couple of the problems.

The first one, there is a step that executes an app called my app, and I've had to put the username password in the script so that he can actually execute the operation. I want to, clearly that's not a, not a good thing to be doing.

And then, and then later in this, in this script, I've also got a step that just list out the results from a query, say into a database. This might be an add directory query where I get a long list of data. I might pipe that to a tool like more or less so that I can just page through the data, but it's really hard for me as a human being to pause that data and do anything useful with it. And this is one of the drivers for Opus, as we'll see in a second, how we can actually take that credential information out of the script.

So replacing the user password with calls out to, to the kind of container shell to get that data, and also how we can augment the output from commands and turn them into very rich, very useful commands or controls like the grid control, which has built in features like source and filter, et cetera. And you'll see that in a second as well. And all of this is wrapped up inside a Docker container. So this easily deployed and easily managed and highly scalable. And of course these steps don't execute.

Don't leave in isolation more and more often you'll need to complete multiple steps to finish a change request or finish a task in this kind of abstract example, we've got the existing code wrapped up in a Opus container. We've got a couple of existing scripts, and we've also had to write some new code that didn't exist before. Maybe we're integrating with a new system that we didn't, we not not encountered before.

The important thing is Opus wraps around all of these steps to add that isolated security and a user experience, which is actually fantastic to look at and actually has an interactive and conversational flow with the operator. And importantly, looks across the entire flow to keep an audit trails. You can see end to end what goes on. Let's look at a, a kind of real world example of that. A very common task that that people are looking at the moment is, is joiners, movers and levers.

It's really important that when your granting access to privileged systems, that, that you have a traceability around what systems have been updated to give that, that user access. In this example, I'm creating a new user has to be a developer, so they need access to quite a number of systems. So I might from a HR point of view, raise a request to say, I have a new start coming. I might do that in service. Now that's gonna require an account to be set up an active directory and a mail account in exchange, maybe an account in SQL service. I could do some debugging, do database work.

I create an accounted JIRA, another accounted, a DevOps tool like chef, maybe I, I create some VMware development and test systems. And then I can update the service now to say that the job is being completed.

Now, it's highly unlikely that any one admin will have all the details to connect to all of these servers with an administrator account. It may well be that the person that creates the active directory exchange accounts can do that, but then they need to hand it over to somebody in the database team. And at that point, you get a break in, in the flow that could be waiting for somebody to come available. That person could be on vacation or whatever, and suddenly the whole flow breaks.

And you can imagine that being repeated time and time again, across each of these expert domain areas, and then after the event's being completed, how do I go and look end to end to see what was actually done in each of those systems in terms of the, the update and that's the problem that Opus is gonna be solve or is solving. Now, there are many things can do, but this is the, the kind of scenario we we're focusing on today.

In fact, in the demo, we're taking a cutdown version of that because we've got a lot of ground to cover. So we're just gonna take a simple ish example because we've actually got a very common request, which is an end user has managed to forget their password. They've tried too many times. They've been locked out their account. The request has been raised, please reset my account. And while you're there, the it team said, actually, we are cleaning up our ad groups. We need to reassign this person to a different ad group.

So that's at least two fairly complicated operations that need active directory integration. Now, each one might have a command line around it, if you know what that is, but we're gonna show you how we can do that in a highly interactive and highly graphical way. And I think that's enough of me talking about slides and really see some fun stuff with Andy. So I'll head to you, okay, then I am gonna go off the tasks and we are going to do that task. That mark outline for us, but I'd like the attendees of this webinar to imagine that it is any task that they want to do.

So if you look upon this thing as a generic task, and we just put it together on this example, because it's gonna touch a bunch of different things. So just to expand on that a little bit, the code that runs this runs inside a Docker container, which then has some libraries around it and a vault proxy that gives it indirect access to a vault. Okay. And that's a, a vault of secrets. So let's start off by kicking the task off. You'll see that all these tasks here have been presented in a web interface, but the actual task that sits underneath all, this is a relatively simple Python script.

Okay? Now it could be a PowerShell script or it could be another language. And it doesn't know that it's talking to the web. All it thinks it's doing is talking. All it thinks it's doing is accepting input and printing input out. So let's kick this off. So first of all, it's gonna tell us what it's about, what it's gonna do. And it says, we need a service now, incident number. We gonna flip over to service now, oh, your sessions expired. There we go. And we have a new service ticket. That's all about David Bennett needing his account reset.

So we know that a service now ticket is required just out of interest. If we put the wrong ticket in, by putting wrong and say, submit, it's gonna come back and say, that is not an incident. So if you think about it, that's an integration with ServiceNow. That's not allowing you to move forward unless you provided the right ticket. So one of the ways of looking at this is that you are not granting privileges to a user. You are granting privileges to a task. And one of the privileges that the task needs to have is the ServiceNow incident number.

This one, as you might remember from the examples called ServiceNow Opus service desk, and we submit that and it pulls back the information, and it says that David Miller says that David Bennett's account needs to be unlocked with a new password set. Is this the correct incident? We're gonna say yes. Now there's loads of different ways to access data. And when we think about tasks, we think a lot about human error and the fact that they're collecting data from the wrong places, or they're putting the wrong username in, or what have you.

In this particular case, we're going to search through our active directory based on Sam account name and to make it slightly awkward. I'm gonna put da and wild card in there. And when I submit that data, it is going to show us 46 pages of information, which is kind of a typical sort of thing that happens. You go into a utility somewhere, you ask for something, it says, here you go. There's everybody that begins. Or every component that begins with da.

Now, this filtering that I'm about to do is in the open environment, the code was very simple. It just sped out all this data, but we need to choose one item from this. So if I start B E N, you can see that this is narrowed down to two pages, B double N it's narrowed down to two people, just the David Bennett and the Daisy Bennett and David and Daisy Bennett are a classic thing that you could have mixed up. So we're gonna go off and say, yes, David, Bennett's the one that we want. And it goes off and it finds David Bennett.

And we can see that David Bennett is the user, his password, his account is locked three password accounts. This is the correct user. Yes. And now we've got, and you can imagine that the underlying code just gave you five options of what to do with this account. And what we've done is we've re represented these into a web phone. And in this particular case, we're gonna unlock, reset the password.

And well, we won't do anything else, but we could actually add or remove them to security groups to take into account marked example. So we're gonna submit that and we now need to enter a new password. And the password strength meter that you are seeing here is something that's part of the Opus system, not part of the original code. So that's interestingly, if you use cooking gear in your password, it turns out to be rather strong. I've gotta remember to type look, it's got two PS. If I didn't get it wrong, it just, if I get it wrong, it's gonna push things up.

All operations have completed successfully. Would you like to see the updated user record? I would like to see the updated user record, and now you can see it's not locked. It's not disabled. The password count is zero. So we're good to go. Then finally, it's gonna add a comment, solve, work around, submit, please put a value for this. And I'm gonna book cup, call Webinar, job done, tick Submit that that will then go off and the task was completed. And then the next thing we'd like to do is go here, refresh this page. And if we look at here, we see that the state of the ticket is resolved.

And then we see the resolution code is work around and the notes were cut called webinar job, done tech. So in that particular instance, we've gone off and we've integrated with interacted with two different systems, which is, which is quite interesting. So I thought I would, at this stage, show you a little bit of code, not from this example, but from another example that we have, that's quite interesting. This example is from some infobox stuff. So this is where we are adding addresses to the infobox platform.

And I, here, I'm going to show you how we are getting the secrets to operate the infobox system. And in fact, here in the second example, this is how we're getting secrets to operate the mail system. So you can see it's just a key value pair. So we're saying for infobox, we need to get the username, the password, and the address for mail. We need a little bit more, we need to server the from address the login and the password. We need to get those things. And that's what that's that's doing. Now. The thing is, is this is built into a task that is immutable.

So if we go back to our diagram here, the code is this section in here. And once it's put into the container, along with the helper and the Opus libraries and the vault proxy, it cannot be changed, which means it cannot access that vault inappropriately. And it cannot be changed by a bad acting programmer to access that vault store the code somewhere else. So you've got this nice level of isolation. So you've isolated the users from the privileges by attaching them to the task.

You've isolated the programmer from before, because the programmer could have written this in an environment where they were using a test vault. And then this is deployed into an operational locus and it's then using the operational vault.

So you've, you've created that level of isolation. And then you've created another level of isolation, which means a bad actor that has got access to the Opus engine. Can't come along and upload factual C cuz I'm just logged it as ordinary user. There is no upload of any extra tasks or anything like that. So the next stage to talk about is the fact that every one of these tasks, when we look at it, so if I just mouse over this or just hit this button here, you'll see that this is a unique identifier on the top of the task.

This is completely unique and that URL can be placed into the catalogs of your I TSM solutions. And then the beauty of that catalog is that the metadata for the catalog item is this here. It says what it is, what it allows you to do. So from a service desk environment, probably haven't got it connected on this one. This service desk environment is ServiceNow environment is one that we set up this morning. But in here you have flow designers, decision tables, and you have catalogs of how to get things done, service catalog.

So in there this one will be blank, but in here you could put references to these documents, which would get you to that stage. We can go further than that in the, from what mark said earlier, your organizations will have very good people for the various platforms that you need to put together to organize your business. And by using Opus and the various modules around it, what you are doing is you are separating those good programmers from the need to understand the security around credentials, privileges, web representations.

And it means that they can create tasks that can be shift left and used by your operational help desk or operational organizations. And that brings me to within 30 seconds of your time. Very good. Very good. You so switch back to the slides. I think they can switch. I think these guys can switch back in.

No, you've got slides. Oh, okay. Let me just switch back to the slides. Perfect. Thank you. Thanks Andy. So there's lot of grounds covered there. I recommend that you, if you get the chance, take a look at the recording again, because you've better drill in actually see the, the screenshots, et cetera.

There, we've only talked about one kind of narrow set use cases today for Opus. It could have, it has a lot of potential to do lots of other things, but this is a real problem that we've seen in our customers today in automating these highly complex, highly secure operations. And we see this moving out much more into enterprise service management. So that task of adding a new user for example, becomes a HR task and we've got out.

Some of our customers early adopters are already planning on doing that, rolling out that interface to their business users and not just being run by it importantly, it's a very open architecture. So it works across all the different systems that might be available inside the it organization across the business. It's not tied to the Aserium Pam solution. It talks to other password bolts as well. So it's intended to be as flexible as possible, but, but to be as, as secure and, and productive as possible as well. And we know that automation is incredibly powerful.

This is some data from one of our customers, very simple task, just checking the state of three servers, which gets done several times per day, but it's critical to keeping their business running. And they found that through automation, what took 30 minutes in the past could be size down to 10 seconds per task, per execution. And over the course of a year, that's more than 200 days of effort being saved through that very simple automation example.

You know, we've got other early adopts talking about doing that password reset operation that, that Annie just demonstrated. They're doing that dozens of times per day in a reasonable sized organization. So we can bring that down from what might have taken an hour down to seconds as well. So the savings, as well as improving security are just phenomenal. And everybody's a winner here. I'm not gonna go through the whole slide here, but end users will be happier because they're getting more of their requests delivered faster. Usually on first contact it admins that's.

One of their key metrics is often is how many times can we resolve a call of request on first contact in a way even thinking this is upskilling the first line engineers, they can now perform operations that used to require a third line expert administrator to, to actually action. Whereas those experts can now concentrate on what they're really good at their domain. Experts can focus on adding business value. So database experts make the database more efficient. The network people make the network more efficient. Everybody's making everything more secure.

And that makes the see so happy because they know that operations are being executed in a controlled way, and they have full visibility into what's going on with a great end to end audit trail. And the last plug is just for a sir, haven't come across us before we've been known for many, many years as leaders in previous access to management.

We've recently introduced a new endpoint management tool, but the tool we've been demonstrating today is Opus because we think this is the real key to efficient, secure process automation coming back to the title of Martin's presentation about compelling need for privileged automation in it. So thank you for that. I'm just about on time as well. I'll hand you back to you Martin and see if you have any questions. Thank you, mark.

Thank you, Andy. Then I'll take control again. Give a second. Here we go. As I've said before, the third part of today's webinar is around Q and a and already a couple of questions here. So I directly want to, to dive into the questions and let's start with the first one to you, mark or Randy, how do you control which open tasks are available to which users? Right?

That's a, that's a, a good, a good question. There are two main ways of controlling who can see Opus tasks. The most normal way of controlling access is through active directory grouping. So depending when you log in to the Opus system, you'll be a member of certain active directory groups, and that will affect which tasks that you can see if you were a customer of us for our pan product, our pan product has profiles. And if you are a member of a profile and there is a device in that profile, there's a task in that profile. That's the other way that you would end up seeing those tasks.

So they're the, they they're the two ways of doing it. So that gives you two different degrees of granularity. If you didn't use our pan product, you could use hopeless with active directory. And if you do, you can inherit all of the rights from the profile system. Absolutely. I just add a little bit more to that. Interestingly, one of our early adopters have decided that typical user accounts might be managed by one team, for example, whereas system accounts. So SQL server accounts, database account, you know, bank based accounts are other accounts.

They're much more, okay, coming back to Martin point about privilege and risk levels, they'll be managed by more senior team. So they actually have a workflow built in ServiceNow that routes those user requests to the standard help desk. And they have a set of tasks that can only update users, whereas system account updates go to a different group and they only have tasks that can update services. So that's really important that partition is talking about by groups, you know, make sure, you know, these tasks could be very, very powerful.

So giving the right level of power to the right kind of people. So I think that answers the question, Martin. Yes. Thank you. Let's directly go to the next question, which is can Opus automate web applications such as Salesforce, dotcom? Yeah. That's yeah. So I can see where that question's coming from. That question might be coming from the view of what's the difference between Opus and things like R RPA, things like RPA tend to operate in a screen scraping mode, or they just project the screen onto a virtual screen and then do OCR to find where they're going.

We don't do that because we deal with privileged tasks. We need to be a lot more absolute. So we use a range of technologies at the bottom end. We'll use select like selenium to wander through the do model and find out exactly which buttons we need to click and exactly which IDs we need to read. And then we might even go up to things like Casper JS, where some logging systems require a little bit of JavaScript to be run and things of that nature.

But if you think about Opus as something that is walking through the Dom model of the webpage, that's being presented by the device system or application, that's the level that we are integrating at it. Interestingly, we've just done it for Microsoft office. And you might say, why have you done that? Because Microsoft office has an API, it does have an API, but not for everything. So there's a few things we've had to extend and go in and operate it at the web level. I think that's a really interesting power. Is it?

So if there's a, a Java API or if there's a restful API, or if there's a, you know, a browser we've never in a browser we've never seen before that we can navigate the dump, we can do that as well. So it's finding the right technology for the, the problem that we're dealing with, I think, do you mind?

Okay, great. Next question. Does Opus require some third party automation or orchestration engine? All what's in the tool?

No, it's all self-contained within the tool. We we've kind of deliberately kept it very simple, very lightweight to deploy the actual distribution is a very lightweight Linux container architecture.

We put it, you know, we talk about Dockers for the task for the actual server itself is, is running in a very lightweight Linux clients. And we don't have those kind of dependencies on third party databases or third party workflows.

And, you know, I have seen some of those, especially RPA tools have very heavy requirements for databases and some of the other, some service desk automation tools tools will often rely on an orchestration engine from a third party as well. And again, that starts to introduce a lot of complexity. It also starts to weaken that that privilege management story as well, cuz each of those different parts of the element from third parties starts to have their own different weaknesses in managing privilege.

So, you know, we've deliberately avoided getting involved in all that kind of thing, but, but, but keeping things simple for, for the administrators and, and managing this, I think a key, a key tenant to, to most security policies is keep things simple and, and obvious. And that's definitely what we're trying to do here. Okay. I think final question already. So how is Pam in your definition maybe also ed process automation, different to, to just password walls.

Oh, right. Okay. Yeah. That's that's, that's an interesting question. So if I just change it a little bit, so there's what, what's the difference between password vaults and then having a full kind of P XM solution password vaults effectively allow you access to the credentials that you need to do the job. And then from that point onwards you're on your own, the, the username and the password or the credentials have entered your workstation domain.

And typically when they've entered your workstation domain, they're vulnerable to malware and all the rest of it, whereas a sort of a P XM approach takes the first view is we don't, you want you anywhere near the credentials in the first place. We don't want you anywhere near the privileges in the first place. And we don't want you anywhere near legacy systems.

For example, we don't want you importing a legacy version of the SSH library because you've got to talk to some old device because you are instantly vulnerable to any of the vulnerabilities in that what a Pam solution does or a P XM solution does is say, we as much as possible, we're gonna get the task done for you. If we can't get the task done for you and you actually need a connection to this machine, we are going to make the connection. We are going to inject the credentials. And the thing that we're gonna pass back to you is just the pipe to the connection to the device that you want.

And before we pass you that pipe, or before we even create that pipe, we're gonna check your identity to the degree. So if you like its identity in results out identity in rollout, that's, that's the key difference. And you know, for very small operations, I can see that you've got the luxury of a password vault, but it doesn't give you that much in terms of security. And it doesn't give you that much in terms of business benefit.

And when you business benefit really happens when you get to the automation end of things, cuz not only you've got security, not only you've got shift left, but the speed of things has really improved. Your favorite word is isolation. So we've been talking about isolating tasks and it's about isolating people from privileged accounts and the roles. So yes.

Thank you, Martin. It, So then we are done, done with all the questions. So thank you very much for providing all that information. That was very insightful. Very helpful. Thank you mark.

Thank you, Andy. And thank you to all the attend of scooping, a call webinar for listening to us, hope to you back in one of our upcoming events or other webinars. Thank you. Goodbye.

Thanks, bye. Thank you.