Delegate the Task, Not the Privilege: How to Simplify and Secure Your Privileged Accounts

Good afternoon, ladies and gentlemen, welcome to our Kuppinger called webinar delegated task, not a privilege, how to simplify and secure your privileged accounts. This webinar are supported by aerium speakers today are and Harris who engineering director Atium and me Martin Kuppinger I'm CEO, founder, and principal Analyst at co a call before we started some quick information about keeping a call on some housekeeping information. So keeping and cold, we, an Analyst company headquartered in Germany, focusing on information security, identity and access management, risk management, and other areas concerning the digital transformation. We provide services in the areas of research events and advisory. So research such things like our leadership compasses, where we trust recently published the leadership compass on privilege management advisory, where we support customers for instance, and tools, stress, and events, where we have a couple of events up coming in the next few months, such as our consumer identity world tour, which will take place in Singapore, Seattle, and Paris, our next generation marketing executive summit, focusing on marketing automation related aspects and the digital finance world clearly done in may next year, our European identity cloud conference.
So guidelines for the webinar. You are muted centrally, so you don't have to mute or mute yourself. We are controlling these features. We will record the webinar and the podcast recording will be available probably tomorrow latest on Monday and the Q and a session will be at the end. So you can add the questions at any time using the questions feature in the go to webinar control panel. The control panels is usually the right side of your screen. The more questions we have the better it is. So don't hesitate to enter your questions, to have an interesting Q and a part in our webinar. So when we look at the agenda as usually it's split into three parts, the first part I'll talk about approaches or restricting privileged access and enforcing least privilege for privileged users. In the second part, then Andy Harris will talk about the privileged task approach and detail, which tasks lend themselves to delegation and will give a deep dive more on what you can do when you focus on providing a task based approach to privileged users in the third part, then we will do, as I've already said, we'll do our Q and a session where bothy and me will then answer the questions you enter.
So let's start. I think when we look at privilege management in general, so privilege management is very much under change. So we have privileged management for many, many years. And if you look at some of the installations we had found in the VMs or mainframe and Unix early unique world, it's out there for a long time, but it has changed and it will continue to change for various reasons. So one thing isn't, that's, I would say a little positive thing for privilege management at the end of the day. So to push projects for the vendors, which is that suited threats and attacks. These are increasingly after the privileged accounts, particularly when it comes to targeted attacks. So we need these technologies to mitigate security risks. We have different deployment models. So how do we protect the management of our cloud services, where we frequently don't have well thought out administration and security concept.
So you have done one administrator which can do virtually everything. How can you limit what he can do? We have the services on the other side, so what, what are our MSPs allowed to do and whatnot? How do we secure that? Or yes, we have other areas such as the connected things. We need to integrate it more with our governance tools, our excess governance, other tools. And clearly we have also the challenge of compliance. So it's a, a variety of, of drivers, which lead to a change the way we do privilege measurement. So privilege management is really constantly, I would say over the past years changing, and there's still an ongoing evolution. And one of the things, that's the slide I used a couple of times before for the past years, but I think it's still something which is important to understand, and it might also end up with different types of technologies.
So I just put in more, I probably would've better called it shared account password management on the bottom and then session management or task management. That's where we will talk about more on the vertical axis. So what, what we in fact have, so it's not only about the root at the upper right edge when we talk about privilege and there's some, some notion of, okay, it's about managing the root accounts, the administrators, the super uses the database administrators. But in fact, we have shared accounts and we have accounts with elevated privileges and some of these have both. And if they are highly critical system than a root as a shared account with highly elevated privileges, clearly of high risk account, however, there are also functional accounts for technical accounts, which are more, how should I phrase it, which are less critical at the end of the day, sometimes because they might have rough limited might have right.
Limited privileges on the other hand, because they are shared, there's a risk that the password or the credentials become sort of common knowledge in the organization. So again, we have the challenge. On the other hand, we also have personal accounts which have highly elevated privileges. And so we should not only look at shared accounts, we should take a broader angle and we should think about all these operators, all these administrators, and maybe even more. And when we look at where do we really have this privileged to access, we need to limit and how can we best do it? Then broader scope helps us in succeeding in our projects. And as I said, there are various ways. And there are, if we go to the, sort of the middle of this graphic, there are typical shared accounts. So we have multiple physical persons accessing one account, knowing the credentials and based on the entitlements or privileges of that account, they're accessing a system.
So that's one thing. The challenge here obviously is how can you ensure that the password or the credentials for that chat account don't become common knowledge. On the other hand, we have the technical account where a user uses a certain system and that system then uses the technical account to access in our system to try share sometimes is more that for instance, credentials are stored somewhere in clear text. So the security risks occurs on other end. And then we have these at the bottom. We have the individual accounts with the elevated privileges. These individual accounts with elevated privileges obviously are the ones we also need to focus on because these are users which have higher privileges. And one of the challenges we have here is if you, we look at it from least privileged perspective frequently, the point is we know they don't need all these privileges or entitlements, but it's hard for us.
Sometimes it appears to be more or less impossible for us to reduce the privileges. And so we need technologies and that's the privilege management landscape, which helps us where the traditional focus is very much a shared account password management and also session management right now is very much a standard feature of that. However, when we look at it, then we also see that the understanding we need to integrate privilege management with our provisioning. So setting up users automatically, we need to integrate with log management scene and realtime security intelligence for analytics of what happens. This is I think also increasingly well understood. And the other hand we have other features and we have this detection and pretty user behavior analytics. They have application to application privilege management. So if one application talks to another, how do we deal there with this, these elevated privileges with the British accounts.
And we have the privilege, elevation management and task management, which is the area we will focus on today. And so the next couple of minutes, I'll give a, give an overview and Andy and the next step will dive deeper into that. So when we look at restricting the elevation of privileges, what is this really about? So the question we, we, we have to look at is what can a privilege user do? So can he access the system? That's a part which we can in most cases, so, or as is simple, but then the interesting part begins, what can the privileged user she, or her he can do on that system? So it's easier to keep the doctor system shut than to concretely control what someone can do. And frequently still have the situation that we give access. We are a console or whatever, to a system.
And then we struggle with restricting access with really enforcing these privilege. And the other side of the things also might be which skills does he need to do? What he needs to do? So the skill aspect is a different one. Sometimes it's the point is if you say, okay, I give him this Linux access to the Linux command line, then to a she, then, then we still have to challenge. It's not easy to use it. So sometimes it might be better to say we can potentially make it simpler. That's the what? And then that's the why. So why should we do this? Because staying compliance, compliant and enforcing these privilege, mandatory requirements in many areas, and it will go more into detail on this. Clearly it's about mitigating the security risk by really minimizing the privileged access. If someone can access a system as a root and he can do a lot, maybe he only needs a part of that. And then again, it's about how can we effectively mitigate, minimize the, the, the privileges he has. We have this challenge of split responsibilities across service and support levels. So the external managed service providers might do something different than you do internally, or you have a first and second and third level support, which have different tasks. And so how can we give them exactly what they need?
How can we allow only define access for MSPs? So, yes, we want to help them to help us, but also we need to keep control about what they do. And we might consider doing it to simplify operational activities by minimizing what someone can do. So the less people can do, the less things can go wrong. The easier it is to do these things and to concentrate on these things. So there are a couple of reasons for restricting the elevation of privileges. And then there's the question of about how can we do it? So privilege management historically started with shared account password management, which is a very cost crane approach on restricting privileges because it just says, okay, you can access that account or can use that account because you can get the credentials, but then you can do whatever account is allowed to do. So it, in fact says, if you have to the doors to the key, then you can do everything in the house or in the system.
You want to do session monitoring another way to do this, that looking at what happens in the current session, the challenge is identifying really in detail, what happens and then reacting in real time and then frequently saying, okay, oh, that's what you right here. You're not allowed to do. If someone is not able to, to start doing something, it's better then afterwards saying, oh, no, stop, stop, stop here. So session one, touring helps to some extent can be more fine crane, but there are obvious restriction with anti provisioning and access governance. We can do a fine crane access of what a certain account is allowed to do. Yes, we can do that. We can use define all these accounts and can say, okay, this account has accepted these privileges. The more we go into detail, the more complex it gets and for shared accounts, it doesn't really help us.
So if we need to say that someone is allowed to, to use certain types of tools, then we, we might end up at the, we might end up with challenges and reality is in fact, we could do a lot with the access control on various systems, but frequent. We don't do. And we have systems starting with many of the cloud services look also with many of the network devices where we don't have these capabilities for fine access control. So then we also have the privilege elevation management as some discipline, which is out there for a while, where then the capabilities of what you can do on a system are restricted either by intercepting, what is, what can be done on the system or by providing specific types of shelves. Cetera, that brings a lot of intrusive mask to these systems. It's commonly limited. So for instance, we have to accountability for the Unix Linux world and or for the windows world, which sometimes then works rather different other platforms.
Usually aren't supported that well. So if you look done at hyper wiser level, which is also privileged and critical system, if you look at network devices, then you've commonly lack the, the capability to really limit the, the privilege elevation in these areas. So that brings us to the task management. That's where Andy then will go far more into detail. But if we go out and say, okay, we provide tasks and we assign certain tasks, which can be very fine crane. Then we potentially can make this work for far systems and on a broader scale. So beyond the traditional heavy administration tasks, the other approaches commonly are aside of identity pollution, access governance, for sure the other approaches commonly are centered around. So when you put us into a picture about, so, so to speak the reach, so how good is it in supporting different types of systems?
So the windows on Linux and the Unix and whatever mainframe and network devices hyper wise and whatever else. So what is the reach shared account password management, many of these systems have a broad reach to various systems. Task management also has a broad reach. On the other hand, what is the granularity? So shared account password management, as I said, just says, go in route. So it's a yes, no decision session monitoring can be more perennial it's limitations, ion management, where it works and identity provisioning where we can use it. Yes. And provisioning, as I've said, it's good. It's important. But when you look at administrative and operative, operational task or upper administrator operator tasks, then we have some limitations here. So task management, in fact, when we look at reach and granularity provides from my perspective, the biggest potential of enforcing least privilege approach for the privileged users, particularly. So the administrators and the operators, but also beyond that, this is where I'd like to hand over right now to Andy, whom I will make the moderator again, the presenter, Andy, it's your term
In the section that I'm going to do, I'm going to layer on what Martin has already said. And I'm going to assume that our audience already have a fairly good handle on, on the kind of pen world or, you know, the privileged access world, but I'm gonna take it in a slightly different direction because I'm gonna talk about tasks, which to me are the way of getting the wind triple, which we'll come back to later of speed, accuracy and security. So in the beginning, of course, we started with CIS admins. And if we go back far enough, everybody had their own CIS admin, their own CIS admin was very dedicated to the organization and everything worked well. Now we live in a world of the outsourced outsourced, outsourced, outsourced, extra outsourced outsourcer. And, you know, we don't know who we've outsourced to in the end, which is an interesting thing, but we'll, we'll, we'll, we'll get to those sort of ideas, data breaches.
So let's just talk about when data gets started from your organization, it happens in two ways. People either gain access using keys or credentials, or they use an exploit. And there is an idea that I just wanna pick up on. One of the things that Martin was saying, when he was talking about how you, maybe you want to restrict people's access by having things that restrict the commands that you could issue on systems. And I was gonna say that in all cases that I've ever seen of systems that restrict commands, that you can use on systems, you can normally drive a bus through them. And a great example that we did the other day is we just write a post program. The idea was to take away the delete command. So we did Python import OS, and then literally OS stock delete the fall with her.
We literally rewrote it. So it was really quite easy exploits. If any of you listening here have actually tried exploits. They turn out to be remarkably difficult to use. The's an interesting place on a Wednesday and a Friday. We have a lecture actually in, in this very room that I'm talking to you from, and it's called lets. And sometimes when there's been an exploit, we find out what the exploit is. We get all the parts together and we have a go and see if we can operate it. So we had a go at operating poodle and things like that. And it turns out to be quite difficult, but there you go. That's that's breaches. What gets stolen. I'm gonna skip over this because Martin covered this excellently, except I'm going to mention that one of the things that can be quite easily stolen from some systems is the entire VM.
So your entire virtual machine. And that's an interesting thing to steal because if you steal the entire VM, you can reason over its security at your leisure and when you appear or when the attacker appears within your system, they come in perfectly, right? And they look absolutely fine. So if you have systems and scenes and, and other algorithms designed to spot these things, you don't spot it because it looks right. That's the traditional kill train. And I am gonna skip over this again quickly because I think Martin did a great job of this, except I, I kind of got it in a, in a, an graphic showing you the, you know, the injection and the rinse and repeat nature of these things credential acquisition. I wanted to talk about because you know, maybe we don't understand so much how credentials get stolen from your organization in the first place.
86% of them are straightforward, stolen from the desktop. So lots of applications have these in cashes. That's a great way. There's hashes that are used to jump onto windows machines. And then the, the rest of the credentials are stolen through brute ING and fishing. And the other thing I wanted to think about was the absolute irony of anti-malware stuff. So if you've got antivirus tools and you were to lose access to the anti or, or somebody was to acquire the credentials that your malware products use, they then have the right to read every single file and every single bite of memory completely legitimately. And I always think that's an irony. So looking after service accounts is really important. So why are people logging on the systems anyway, in reality, and I've got a slide about this. Most people do the same things month in, month out, but they need high privileges for some tasks, right?
Which gives you automatic access to tools that you didn't really want people to have. And you know, they're all classic come classic. Examples of that. One of them is resetting administrative sessions on, on windows boxes or the classic, you know, reset domain password. People who do have access, tend to make parameter errors. You get the humor factor and then you often get particularly in help desks. You have, well, there's nobody to help you, but let's have a go. What harm can it do? And if you've got a domain admin account, it turns out it can do a lot of harm. So work repetition across your team, across your team. You tend to find that DevOps are doing about 45% repetitive work. They tend to use things like ible chef puppet, Jenkins, continuous integration environments to reduce the amount that they actually do as people CIS admins do about 70%.
And the health desk is right up at 90 or 90 plus percent of repetitive work. And the, the little graphics along the bottom, the green ones are designed to show you the cost of each of, of each of the individuals in that environment. So your help desk costs you, the least per person, your CIS admins cost you more. And your tend to cost you more again, and work patterns look like this. You've got similar issues running around all the time, new issues coming in because you're deploying new systems and retired issues leaving because you've retired some systems. But when you look at the actual tasks that are being done, they break down into two areas and the two areas are operational and business tasks. Now the operational tasks are common to just about every organization that's out there. And in fact, when we build a Syrian, we literally prebate loads and loads of common tasks.
And in fact, I might just for the fun of it, just come out for a second and fire up this interface into a, you don't normally see this interface. This is a bit of a treat today. This is a development interface that we use. But if you look down these this window that I'm showing you, every time you get, I'll show you one in particular, this one here. So that's a task that says reset, all disconnected administrator RDP sessions. And that's a classic thing that all it departments have to do because somebody's logged in the second person's logged in. One of them goes off. Third person can't come in. Or the first, you know, the, the first person normally forgets that they've left their session open and you just need a quick task to drop those sessions. So you can come back in again. So that's an example.
The other one that we have here, which is quite interesting is this APC power rack because at a serum, we buy Cisco routes by the meter. And we don't like to leave them on all night because they use far too much power. So that's an example of that. So this is examples of the ordinary it infrastructure task that you see on a regular basis. And this is called our dog food machine from the kind of old joke that you, you know, you need to consume your own dog, dog food. Or as our sales manager puts it to me, we need to drink our own champagne. Anyway, back to presentation. If you switch over to business tasks, they're different. So we find with our customers, they tend to have a lot of database operations and that's because they run services for their customers and their customers are forever forgetting their password, losing their phones, breaking their phones, leaving them in hotels, getting them back from hotels and changing departments.
So those are those kind of tasks. The service operations are normally bring this up, move this up, do this. And what's interesting is that when we I've that you quick swing of water, I've got a slide later that shows you an actual analysis of one of our customers tasks. But we do find that restart service and reboot server are still very common between the operational tasks and the business tasks. So what's the goals, the goal, when you move away from manual operation to automated operations, to get yourself security, speed, and accuracy, and it is generally a Govin dry fact, which is German for wind triple, but to help you I've put the, the French and the English translations as well. But it's really important to get those done business goals. Let's get to the business goals. Cause we've talked a lot about the infrastructure goals, because I guess everybody, everybody can understand the infrastructure goals, but everybody's business goals are slightly different.
So if you are looking the customer's first call resolution is important. If the customer has to phone back, or if you have to phone the customer, and if the customer you are phoning is the one that just lost the phone. That's not easy. The cost of resolving their problem goes up. So it's, you know, a cost of calling a customer base could literally be had a hundred euros to the resolution of a problem. So if you can get it all done in one go, it's really good. You need to know the state of your customer facing services. So if you are sitting on a help desk and some part of your service is broken because of some connectivity issue, if you see it in front of you and you can do something about it, you've got speed. The other thing about tasks is you need to shift them to the most appropriate part of the business.
So resetting domain passwords for all the people who come back from holiday for getting their passwords can go to your it help desk, but switching departments or switching applications that your customers allowed to get to should go to your customer help desk. And the other thing to do is to reduce the opportunity for data access. Because if somebody's only got a task that can move somebody from one department to another, normally they might need the privilege to be able to do that. And along with that privilege to login session would be the ability to take all the data out as well, which is quite important. So that was a bit that again, right? I'm gonna go back to that slide and not let it play that did play earlier, played beautifully. So this slide is all about how you end up acquiring more and more tools that you need to do things with. And this is quite important because when this thing I don't what we're gonna do, I'm gonna make it run manually. How do I get rid of go? We go, here we go, all click.
We go, that's better a, a bit of presentation wrangling there for you. So now you, this is a little timeline going along and it's showing you how you are gradually inquiring versions of vmware.net, Java, and all the rest of it. I'm gonna slide this to the end. Here we go, manual operation, and then gradually how you lose them. And what this means is you end up with a lot of legacy tools within your environment. And a lot of legacy tools lead you to needing access to all those legacy tools. And that gives you this multi dependency environment. So it means that your CIS admins and your help desk, people need all of these applic or actually all of these applications and the prerequisites for all those applications running on their machines and people like people, you know, just the, the irony of it as well is people like a sir, we release four times a year because we're a security product and other people are going towards the agile model.
And the more agile model you've got, it's great. You get functionality quicker, but you also get legacy quicker. So one of your problems we find in organizations is they create a jump box for each one of the applications. So every time they get an old application, they go, ah, they'll install that on my machine. I going to install that on a little jump box. And then before, you know, it, everybody in the it department, plus the help desk, plus the contractors, plus the outsources, plus the outsourced outsources, all get to know that password. And when they do get to know that password as Martin put it earlier, you have the hole in your security, the size of several buses. So the principle that we're talking about is not is delegating the task and not the privilege and the co of that task of, sorry, not the task.
The core of the principle is to separate the people from the passwords. So we're gonna delegate the task, not the privilege, we're gonna separate the people from the passwords. So here's an architecture that we use to do it. So if you go over the top loop, that's the single sign on route. I'm not gonna talk about that cause that's, we do that very well, but that's not what this is about. And the bottom route is the tasks, which is really, really quite interesting. And then I added another note because I was listening to Martin's presentation, which is, and we're going to tell the scene what happened as well, cuz it's very important that a product likeer lives within a proper corporate environment and you get to see, it gets to inform people. He also made a point about using technical accounts. So you have a user account and a technical account.
Sometimes that we call that your privileged account in a, we have the concept of mapped accounts and some companies want to lose all of those and just go to the route and admin account and know who used them. And if you've got someone like a sir, that's allowing you to do that because it's separated those passwords or it's actually running a task as route or maintenance or the administrator. It's important that you then go and tell your scene who did what, where and when, because that lot then goes into your security posture. And if you know your security posture, that's extra double good.
So it's about a tax surface reduction. Why leave accounts enabled when you don't need them? And that is genuinely the least privileged model. So this is a slide take there's there's about 20 of these slides and this is not the best slide. Actually. There's another one. That's 276 days. But this is an example of a task that's done by one of our customers in the space of the year. It got run 2,597 times. If they'd not used a, it would've taken an 808 hours with a serum. It took them six hours, which is pretty good. So you've gone from 30 minutes down to eight seconds of a task, but more importantly, it's error free because those other 808 hours nobody's taken into account the, I don't know, 300 times of those CBLE U a T checks that were done wrong and run into an issue. So that's really important. The other thing that's really important is if you can do something in eight seconds, you've got a chance of first call resolution. It says to stop here for Q and a, but that might not be, we might stop here for Q and a. We may just because I've been watching my time.
We may just have a look at, go to where are you hiding? Strongly, go to where? Here we go, you were hiding underneath there. Sub bro.
See
Dear. So what I was gonna do is I was gonna bring up a view of how we can see, there we go. I was gonna bring up a view of, I hope you don't see this, but I see the go to webinar control panel all the time, go to profiles, office infrastructure admins. So in our world, we get to see this. We get to see all these people can run. All of these tasks were appropriate on all of those machines and that is the essence of task automation. And it makes life an awful lot easier for us, which is good. So I will start to take the questions.
Okay. Thank you, Andy. I'd love directly move to the Q and a session. If you have questions then to the end end is if you have questions, then it's time to enter these questions here. We already have a couple of questions here. So one of these questions is so, so how so for, I would say maybe let's start with one question I see here for, for which types of systems can you create tasks?
Right? I don't think that there is a type of system that we can't create tasks for in terms of infrastructure tasks. Mostly you get to see everything anyway, but when it comes to business tasks, there are different ways of approaching it for us. The easiest tasks are always the API tasks. They always go down. They're always a really easy thing to do in our system here. I dunno if you can still see my screen.
So I made media, but I can't give you the moderator roll the percenter. Roll back.
Thank you. Show my screen. So somewhere down here, we have security admins and in here, you'll see, I'll just move this to one side. You'll see things like how we manage our necess scanner. So the necess product has an API and that's absolutely the easiest thing to deal with to write a task for.
So how do, how are these tasks created then?
Oh, they're created through templates. So in a, you have this massive template library. And if I picked one of them or dunno, let's pick iOS SSH and I hit edit, that will then bring up the template editor for one of those tasks. And if you wanted to see the port tasks there, they all are. That's how you manage a Cisco router. And all of those tasks are made beautifully into the little this'll Dewey interface that you see you saw you saw earlier. So it means that, I mean, I know that, you know, one of the things you could say is why don't you do it yourself? Which I might answer in a moment, but the, the fact that it's here and managed by us and it's all nicely divided. And at no point, do you ever get to see the passwords? And this is how we do the, this is how we divide it, separate it.
Sorry. So, you know, there's your, there's everything involved in doing a connection. There's everything involved in doing a backup. There's everything involved in doing an art flush. There's everything to set an NTP server, really important to set your NTP servers if you've got loads of scenes and things like that. So yeah, that's, that's a good environment to, I mean, I hope people hope the resolution of their screens is good enough because I can read that. But you can, you can kind of get the idea that you've, you've got your ability to set your NTP and,
And why, why shouldn't I trust fire standard scripts? So, so their scripting capabilities are available in many areas. Why not trust firing scripts instead of doing the type of task? That's one of the questions I see here.
Ah, yeah. Now that's the classic. Why don't I just do it myself? And that is because if we there's loads of reasons for that, but one of them is the cost of DevOps is really high. People get a way of doing things. And if you want to write a script, I mean, you can see here, let's just look at art, flush. Your art flush is incredibly easy. Show up and then, sorry, art flush clear up. That's all you have to do. So the actual tiny script that does it is an incredibly easy thing to do. However, to create a UI to go in front of it is a really heavyweight work to do. And not all CI admins want to create you guys. And when they do create a UI, it won't be optimized. And when they do create a UI and they move on to another company, you've got a maintenance problem.
Whereas here we've made it all nice and easy for you. So if we go and look at our, this device here reset, or I won't do this because I don't know who's on the machine at the moment, and this is live. This system is live, but there you go. Now we haven't got a huge estate here, but you can imagine here where I'm highlighting this, sorry, we're highlighted that you could imagine a list of systems that you might want to run that task from. So being, being able to use something like a means that if you do want to write some of your own tasks, you've got this environment in which to do it. And you know that it's gonna percolate up to a standard UI. And you also know that the passwords are never going to enter the workstation of the users so they can never be ran straight. They can never be hashed. They can never be stolen and they can never be fished either. So you can't even get them out the users that way. So,
So, so, so to speak a task automation with standard UI and the privilege or the credential security built in
Yes. Yeah. Ongoing maintenance and all the rest of it.
Okay. So how automated are the tasks that are created by your software?
That is a good question. We have tasks the better, the better example of the, the strong really strong examples of automated tasks are ones that do database operations. So a database op operation can check the value of several fields in several tables, in several top columns, and then decide what to do because of it. You can also do in terms of automation, change ticket management as well. So you can say, if you want to issue this task, you need an incident ticket or a change ticket for it to go on. We are thinking more and more of changing the way that we do tasks to DSLs, to, to domain specific languages. So that in here, in these blocks of code that you are seeing here, you can start to put your own references. Well, you know, not only just references, but your own code in here to get your own tasks done.
Because when you think about it quite often, you need decisions. So to give you a real classic one that we do standard is reset the main password. So if you have an account that's disabled, your help desk, can't reset the password for them. Or can't, re-enable the account because the workflow says, sorry, you can't do that. You need to go and ask personnel and the personnel can have tasks saying, oh, we haven't actually terminated that person. Let's reenable their account. Or we have terminated that person. You are not going to reset their password. So that's the kind of level of automation that you look at the next things that you can do, the, perhaps the more complicated levels of automation. And I'll just see if I've got one here because it is the most complex one that we do is necess where's necessity. Oh my goodness. I've just got to move this so I can work out which one we're using. We are using that one. Oh. Cause we do I own these days. Of course. Yeah. Sorry. We've gone to the PO version. So or scan, scan, scan, scan, scan, scan, scan, launch, download, scan, connect, get assets, download scan, IO scans. There you go. So look at that. This is us automating tenable IO. I know I said necessarily, but we've gone up to IO. This is us automating tenable IO tasks. Lovely.
Okay, great. Andy, I think this was a pretty good demonstration of the depth of capabilities here tool is offering. So I think we don't have any first questions right now from our attendees. So, and I'll switch back to me, but I thought of that. I think it was very interesting to see as you drill down into the details and I hope it was worthwhile to attend for all the attendees. So thank you very much, Andy, for your presentation. Thank you very much to all the attendees for listening to this copy and call webinar. Hope to have you back soon as attendees of one of our events. Thank you.