How to Stop the Insider Threat: Protect Yourself from Privileged Users

Good afternoon, ladies and gentlemen. Welcome our call webinar. How to stop the insider threat, protect yourself from British users or maybe better from malicious privileged users. This webinar is supported by psychotic. The speakers today are me Martin coping and founder and principle Analyst, our call. And then the second part of the webinar CEO of psychotic software in Ben Yoder, product manager at psychotic software. Before we start some general information on housekeeping, etcetera. So first of all, I want to remind and from you about our upcoming European identity in cloud conference, which will be held next week in Munich. It's the conference around topics such as identity management, cloud privilege management and cloud security, all the other information security related topics. It's about all leadership and best practice on the, I would say a mass stand ones. I don't miss our upcoming European. I don't see in cloud conference regarding computer call itself, we are an Analyst company providing enterprise it research advice for services, decision support, and networking for it professionals through our research services, where we various types of research, including including our leadership documents, which compare vendors in particular market segment throughout advisory services and through our events such as the European identity and cloud conference regarding the webinar, you are mute, you are muted centrally, so you don't have to mute around mute yourself.
And you do not have to care about these features. We will record the webinar and the recording will be available tomorrow. And the Q and a session will be at the end. However, you can answer questions at any time using the questions feature in the go to webinar control panel. I always recommend entering questions once they come to your mind so that we have a good list of questions for the Q and a session. Once we are done with the presentations as usual, we have three parts in our agenda. In the first part, I will talk about the changing Fred landscape and the focus on the specific role of privileged users. The second part, trans and Coley and pander will dive deeper into the details of insider threat and how to address them in the third part. As I've said, we will do the Q and a session.
So let's directly start. So when we look at sources of risk for information, and many of these risks are associated with user behavior, then we have three big groups. One is malicious activity, one is misuse and one are mistakes. So malicious activities just include coordinated attacks, hacking data theft, denial of access on blackmail. And some of these such data theft are already areas where insiders come into play. If you look at many of the more prominent incidents of the recent time than insiders were in and still data. So there are things in that area when you look at misuse. So the app use use of privilege, doing things wrong, misconfiguration, stealing data, et cetera, clearly something is related to the internal uses, but it's curiosity just looking at data. Someone should not look at Corona cutting delib leakage. Also, there are various things where we see internal use involved, which are around privileged, uses cetera.
And then the end of there are mistakes. And when we look at privileged use and the term of privileged uses about users, which have more than average, more or more than standard privileges, which can be a root user and administrator and operator, which can be various types of technical users. When we look at these, they are so they're impose higher risk when it comes to mistakes. So when someone was high privileges that something wrong, the risk is just bigger. So the risk of exponentially raiser or exponential loss or existential disclosure is, is higher for someone who has privileges. And so when looking at the risks, it's very obvious. There are things which are driven externally. So users or attackers we are seeing, and we see more types of attackers, more professional attackers these days, but there is also the area of internals who are at risk.
And I think when we look at security, we should not, despite all concerns regarding external attacks from whoever, we should not forget to look at the insiders because they, as I've said, also impose a significant risk. And when we look at how this fits into a bigger context, then we come to the term of information, stewardship information, stewardship of something we have to find some two years ago. So various reports and described. And when looking at information stewardship, it's looking at various aspects. So understanding the information lifecycle, where does information flow, who is working with information, cetera, and includes those understanding who is who, whom of these accounts and the persons behind, or the systems behind can do? What was that information? So what is the business value of information? What you protect first, what are your sort of your crown tools, data architecture, where the data's distributed, how does it relate to each other?
How is it combined information, quality, privacy, compliance, and security, and also this area security, especially we have to look at what are specific people are allowed to do. So what are these insiders allowed to do? What can they do with information? But clearly it's not only about one technical element. It's about understanding a lot of things and understanding who can access, which data who can do, what was with data, what can happen here? So this is basically what we have to look at. And today there's a lot of talk about advanced attacks. So multiple stages started the right side and sophisticated, advanced per long running etcetera. And interestingly, many of these attacks are a mix of insiders and outsiders, or you, you just sort of high checking siren and then do things here. But overall, if you look at our attack landscape and our threat landscape, it's very clear that it's not only about advanced text and the outsider attack, but that the insider place plays an important role.
And as I've said, we should not forget that. So the, our enemy sort of, it was in the enterprise, not necessarily someone who's really an enemy, as I said, it might be mistakes. It might be something which is cost in a by very specific situation, but that's what we should look at. But inside our attacks, as I've said, they remain at a higher level there, various examples, malicious codes, data theft, etcetera. I just put together some examples around insider attack. So there's, there has been, especially in the German speaking countries, traveling in Switzerland, mainly there has been a lot of talk and a lot of news. And so on around text related data stuff at Swiss banks, where people from Germany had money at Swiss banks, they didn't didn't inform the German tax authorities probably. And then some, some people at Swiss banks started stealing the data, putting it on C, selling it to the German tax authorities, which them sued the, the people who had the money, the Swiss banks.
And so this tax related data stuff, there were various incidents following this. They were done by insiders and from what we have heard and what was told and, and report about us that as were, were both standard users. So in fact, not so standard but elevated. So was the ability to gain access to, to, to data and traditional privilege users acting somewhere from the system management system or side of things. But clearly there were people who had specific privileges to do things they could use for app use another example. I think it's more two or three years ago. There was a large incident around credit card transactions, which happened in between the part of sales and the bank. So there's a outsource credit card processor and insiders there working together with external attackers brought malicious code. And again, a sever incident, including insiders. If you look at some, some others, so Edwards, not Bradley Manning, both were insiders, both were able to do things indicated Bradley Manning, not, not really because he was really privileged.
He, he just sort of benefited from weak access management, I would say. But clearly again, insiders, if you look at association around UBS, etcetera, so what, some of the examples of Oak trading, all of these were insiders, it was fraud. It were weren't attacks. And so it's very clear if you look at, if you look at a number of the, the recent, so incidents, we see that insiders are RA a common are RA a common element, that type of incidents and that type of attacks or, or road behavior or whatever. So the, the British account is a key element in tax bridge accounts. As I've said before, accounts was elevated privileges, which have so more, more than average and more unusual access rights, which can be individual accounts, which can be shared accounts of some types. So system accounts, route service accounts, whatever. So there are various types of privileged accounts.
They are a kilo attack in attack clearly because privileged users can cause more harm. The more privileges, the more harm. And for, especially for say more, more advanced types of attacks, more sophisticated types of attacks, elevated privileges are required to run these attacks. So this is, and when we don't look at privilege management, I think it's important to understand, yes, we, we need to deal with this. And it's on the other hand, one part of the story. So privilege management looks at who are these, these British users managing shared account passwords, removing credentials, Computex credentials from scripts and other sources, monitoring sessions, managing sessions, providing single sign on. So, so especially also avoiding that shared credentials become sort of a public knowledge. We also have another area which is more around access governance, which is around managing elevated privileges, also business application occasions, which we might apply to, to it as well.
So an SAP power user or another, an operator with various roles can be handled the same way. Like any other business users with elevated privileges, that's allowed to, for instance, approve purchase orders with high amounts of money. So there, there are various types of things. And we have a big area of sort of more privileged access beyond the standard user account, which includes all of the shared accounts, which are a specific type of risk, but which also includes elevated rights of individual accounts. And if you look at the typical operator accounts, this is a great example. These are the people who frequently can cause a lot of harm to an organization. So it applies to various areas. It happens in various areas and it happens in various ways. So we have the let's start at the top. We have the individual account who's accessing based OnIt manage the system.
So this is a person who's accessing a system. And then the system is accessing another system using a technical account. The technically technical account usually is more elevated because he's used by a number of users. So it's the one account used to access the database while a lot of individual accounts are accessing the application server. For instance, in that case, this account is a risk because there are clearly, there are people who know the credentials of that shared account of the technical account, which then can potentially abuse it. And that's very commonly something which is part of insider attacks. So knowing the technical user accounts, having more access rights, another area are their shared accounts are rude, etcetera, where people various peoples are using the same account. This is also one of the areas of privilege access. And the problem here is that we have a sort of the horrible combination of shared accounts.
So with the risk of sort of well known passwords and elevated privileges, pretty bad combination, obviously. And then we have the individual accounts with elevated privileges. So people who are running or accessing systems with some individual accounts, no, no shared account at all, but they have more than average rights that can be on the business side where we typically handle it with the access governance tools, or it can be on the system side. So people who can do more systems. And I think it's very obvious. So the root of a Unix system might be less risk than the person who has operated roles for Unix theoretical database on the SAP system altogether. He might cause far more harm based on the three operator roles, combined, someone who has only access at one level system, but in general, all of these are risk. And when we look at the overall security or exposure for organizations, and it's very clear that we not only have to focus on the external threats of all on all these external attack, but we have to start sort with our own users and look at who are these insiders who can cause harm, who are a threat and how to handle these.
So when looking at this sort of threat landscape, we clearly have more external attacks, but we still have this internal challenge. And we have the situation that also external attackers are increasingly more advanced and trying to gain control over elevated internal or privileged internal users than using them for the next steps in their attacks. And based on that, it's very important that we get a good grip on our internal users and how to do this more in detail. That's something channel and Coley and will now talk about, I will hand over to them for the second part of this webinar.
Great. Thanks very much Martin. So what we're gonna look at next is five specific ways to stop inside a threat. So I'm Jonathan Coley together with me, I'm dander. So I'm the CEO of psychotic software. Dan is our product manager for pan tool, the secret server tool, just a little bit of background about psychotic. So the company was founded in 1996. We're headquartered in Washington, DC, the software that we're gonna be talking about today, our secret server, the Pam tool is actually used by over a hundred thousand. It admins to manage privilege within their companies. PCO software has seen enormous growth in the last five years. So we've been named to the Inc 5,000 as one of the fastest growing companies. We're also tech partners and have technology alliances with all the typical vendors that you would. So whether it be, you know, HSNs or encryption hardware level, whether it would be vulnerability, scanning some tools, pretty much all the tools that the enterprises are using today.
We have tech integrations with those so that you can get the advantage of managing privilege with those different integrations. So the tool we're gonna be focused on today is our privileged account management tool. But I did wanna mention two other tools that P makes as well. The first one is our end user password reset tool. So this is a self-service Porwal to allow your end users to reset their active directory password. And then we also have a self-service tool for managing active directory groups. And this basically allows a self-service Porwal where your end users and line of business level managers can use a Porwal to control manage groups, do ad group membership exploration, be able to validate who's in the appropriate group of the appropriate time. And then also be able to provide audit data for an order to coming in over access control. And who's using what so as marking showed earlier in his slide, we, when we talk to customers, we generally see people focused on three main problems, three things that they're worried about, and it's typically the internal threat, which we're gonna focus on today.
It's external threats. And then it's usually how do I appease my auditor? How do I meet compliance? And even though we're gonna focus on internal inside of threats today, many of these same techniques and procedures, if you apply them will be able to help mitigate external threats. And we'll also allow you to meet compliance mandates. So just to set the context that we know what we're talking about, Ben, could you give us just a quick walkthrough of what the Pam tool can do and kind of where it would fit in a customer's network? Sure. So secret server fits into your existing Microsoft infrastructure. It's it's installed on premises. So there's no cloud service you're using installs in your preexisting environment and you set it up as a web server. So the idea is the admins or applications access the gateway to retrieve those privileged credentials.
They can open up sessions using tools that promote desktop or put to the target system, or even log the websites. And the idea is an admin logs in with their named user, whether that's an active directory account or an account managed by secret server. So it builds out that audit trail of which named user accessed, which privileged credential, or as Martin mentioned as shared credentials as well or technical accounts. And then in the audit trail, you can see what they did with them through the session monitoring or recording features, as well as hook up into a SIM tool to help correlate what your, your privileged admins did with these generic or privileged accounts, and then to help mitigate risk. It can also do password changing. So every, you know, 30 days or 60 days, it can change those passwords for the privileged account. So admins don't know them or women admin leaves can also change all the passwords and manage those.
So an important distinction today, when we see this so often with customers, generally, people have a pretty good handle on their human accounts. So you think about all the accounts from your network, that map to a human being. So a typical example, being your active director account that you log into your workstation with, that's a human account and maps to you. So we're pretty good in general about password complexity and policy and how to control and manage those accounts. But when we think about insider threat, the real problem is typically the non-human accounts. So start thinking like Martin said around the shared accounts. So service accounts are a really big problem. If you look at a lot of the breaches that have occurred in the last few years internally and how data's been leaked or how access has been granted, it's often from service account passwords that haven't been changed.
Likewise, if you look at Unix route and other shared accounts, very high privilege, and then these accounts are really everywhere. Even at the windows level. If you think about all your local administrator accounts on network devices, you've got Cisco enable the list just goes on and on and actually getting a handle on these non-human accounts is quite easy. So the first problem we're gonna jump into is pretty much a class. When we look at it, admins that are leaving the organization, how do we have a good solution for that before we dive into the specific problem of Ben, could you just give us a, a brief walkthrough of the application just to orient us so we know what we're looking at? Yeah, so right here, I switched over to the secret server dashboard. So I'm signed in with my name user and I see all the resources or passwords that I've been granted access to over on the left.
I can see the folders ones that I have permissions to different secrets in the system. And these can be range, anything from set, a Linux root account to sensitive files or keys like SSL certificates, all of that can be stored and encrypted within the system. And you can set permission lists. So each admin only sees the, the resources or the secrets that maybe granted access to. So you can, a lot of customers will split it out by teams. So the windows server team would see their local administrator accounts. The networking team would see their Cisco routers and so on, and then just access a credential to walk through that right here. I've got a windows admin account so I can access the, the secret. I can see what the username is, and I can open up where my desktop to connect to the target server from the gateway here.
And this whole operation here, Dan, this is all being done just from a web browser, correct? Yep. I'm just writing Firefox right now. Okay, great. So let's jump over to that scenario. We've got all the, all of our it admins are now using the secret server tool as kind of a proxy or gateway to access and manage all the, all of their privileged accounts. And now we have one of those admins that's leaving. What, what would be, obviously we're gonna have at the HR level, we should have an open dialogue with our HR team, make sure that the policies are in place so that we know what to do. The typical things that we hear from our customers are having security present, having the person escorted out of the building, whether in on friendly terms or unfriendly terms, the same protocol is typically followed and having that procedure in place.
But then very importantly, we need to have the tools, the technology there to be able to close out all those accounts and limit our exposure. Yeah, so typically the, the workflow is you disable their active directory account, change some passwords in secret server. You can run a user audit report. So when I access that local windows administrator account and audit record got written in the tool. So secret server knew it was exposed to me. So here I can see my user year to date has looked at these particular secrets, the IP address they were coming from. And so on, I can expire all of those shared accounts or privileged accounts in the vault and secret server reaches out and changes them. So you you've really limited your exposure at that point. As soon as that person has left, or maybe they switched to another group. So there was a change in privilege. You can come into the tool, expire those secrets, and they'll be changed to any random accounts and networks, right across all platforms, whether it's Amazon, AWS credential or Unix or database firewall, whatever it might be. Absolutely. Okay. So that takes care of the first problem.
So onto the next way to stop insider threat in general. So there, we saw being able to assess our exposure and then be able to eliminate it. But what we see most customers doing is how can I reduce my exposure in the beginning? How can I actually make it so that my, my risk is lower because those insiders don't have access to things they don't need, or if we are gonna use the password for something, are there ways that we can potentially not give them the password or something like that? So what are the two to pick away that secret server uses far reducing exposure then? Well, the first thing they do is they can actually hide the password from the user and the tool. When I look at those windows administrator account, I can see there's a password there, but where I look at this Linux account here, I can actually unmask the password.
So in both cases, I can log the secret server audit records are written. I can open a launcher to connect to the target system. So right here I can open up put, but the, the admins can just actually hide the passwords from, from the technical users. So they can log in, run some commands, do their work on the system without ever actually knowing the password. The second thing they can do is they can actually change the password on a per use basis. So there's the whole scheduled password change. You might do service accounts or the report base changed when an admin leaves, you can also do a per use change. So here I've got a, an account. I can check it out. And when I check it out, I get exclusive access to it. So in this case, I could edit it. If I could grab off the password, if I wanted, maybe you have a legitimate need to see the password.
You can't hide it from the user, but if we're looking in the audit trail, we can actually see that the system changes the password on per use basis here. So 30 minutes from now, the system will automatically check it in and secret server goes out, sets a random password on it. So even if I wrote down that password or put it on my clipboard, it's now a new random password that only secret server knows. So that's, that brings a lot of accountability to the audit trail and it lowers your, it reduces your risk. We see customers do this with windows administrator accounts, as well as domain administrator accounts. So a typical use case, a customer has a name user they're logging in with, and then they also have a da account. They used for privileged action and they just know both passwords. What we recommend to customers is they put the da account in secret server set checkout on it for something like eight hours.
So the admin can log in access the accountant secret server, but then at the end of the day, it's changed. So any hashes that were maybe left due to remote desktop sessions or the, and that point, the admin, when they go home, they don't actually even go to the password for the da account. So that would reduce the exposure. Obviously the interval could be changed. You can couple it with workflow, approvals, ticket numbers, all that kind of stuff as well. But like Ben mentioned that there's that crossover again. So by doing the by thing to mitigate inside a risk, you also get the benefit of managing your patch hashes effectively across your infrastructure, which means that that helps for external threat where you could be vulnerable to pass the hash attacks. And like they mentioned, you can obviously do an eight hour checkout in a more aggressive situation though. You could potentially do say a 30 minute or a one hour checkout. And now while your windows server admins are working all day with your da accounts, those passwords are constantly being changed, which means that your threat profile for pass the hash is just so much lower.
So another thing that's worth mentioning here, so then showed how he launched the SSH sessions. Could you walk us through what the, the proxy capability is here, Ben? Yeah. So in that case, secret server was actually acting as an SSH proxy. So this allows the admin to set up certain network security rules. So again, you can limit exposure. So if an admin does know a password, they can't access servers from outside, like their work location. For example, you could make a, a requirement that all connections have to go through secret server for those target Linux systems or SSH connections. So that way an admin can take a password out of the vault and then open up, for example, put on's workstation and try and connect directly to a server from outside of your environment. And another my side effect of this approach as well is it means that the credentials to access those unit systems never actually come down to the admin. So even though he's launching a study session, the password, all the credentials stay between the vault and the target service. So again, just reducing your exposure and then also encouraging use of the vault, cuz there isn't no way around it that the only way to access the service is to go through the vault.
So next up our third way to stop inside a threat is if you look at your service accounts, so this is just a huge problem for it. Operations usually we'll pull customers, we'll ask how frequently they're changing service account passwords on the best case who often hear, you know, every six or every nine months. And when you dig in and you ask why, why you know, why not more frequently? Why didn't you do it every month? And there's typically two main problems that we hear about the first one is I don't know all the places where my service accounts are being used. And that's very problematic because if you don't know all the places and you forget one of those places, when you do a password change, now, all of a sudden that that old password will still be in use on say windows service or something like that.
And it has the potential to lock out the account and cause a massive outage. That's the first problem. How do I know the places where it's being used? And then the second problem is it's just incredibly labor intensive to change all that service account passwords manually. And it's really airplane. If you make one mistake anywhere again, you're dealing with an outage. So typically it operations just doesn't want to do this. And as we know, service accounts are prime target for insider risk. So Ben, can you walk us through solutions for those two problems please? So right here in secret server, what it'll do for customers and what they they use it for is to first run discovery. So we can see where service accounts are being used. So I'm hooked up to a few different domains here and I can see there's several accounts. So several of those active directory service accounts, running windows services here, and it'll show you where is out, pools are running with scheduled tasks.
So initially you just get a good view of where the accounts are actually being used on your network. Here. I can see on this domain on a few different machines, there's accounts running, you know, FTP, backup jobs, the apps, net, state service and so on. So I can create rules once I've added these secrets to the vault that automatically link up whenever a new service pops up and admin creates one, it'll automatically tie it to the corresponding service account in the vault. And then when secret server does that password change, let's say you've got set for every 30 days and you can set a window on it. So it only changes during your maintenance window, but it will walk through those dependencies automatically. You don't need human intervention here and it will update store password on the windows service. For example, things like schedule tax, application pools, and it can even replace password stored in files. If you have that situation where maybe you've got like a legacy II file, orig file with passwords in it and you want synchronize those.
Okay. So next up on our list, column four. So if we're gonna control inside a risk, how do we actually monitor the it admins? How do we know what they're doing? Like Martin said, oftentimes it's just misuse, right? They put additional tools on the server because they need to do their job more efficiently. Perhaps those tools aren't approved by security. Perhaps those tools are gonna be vulnerability later on. How do we monitor what they're doing on the server and make sure that it's appropriate. Yeah. So a big part of that is gonna be SIM and in secret server, you can log all these audit events directly to your SIM tool. So an admin logged in, opens up a put session or a windows administrative session. The events will get logged to your SIM tool. So you can correlate what that admin's doing with that generic account.
And then in secret server, there's also a session monitoring and recording feature. So with the links account, and this will work with remote desktop, if you have DBAs, it can work with your super management studio, but I can actually pop in over here and see what that admin is doing just right inside the application. So I can check in, see what they're doing. And this recording will be stored for later on. If like Jonathan said, you need to go back and determine who did what on the server who install this tool. You can go through and watch those recordings and you can also terminate the sessions so I can tell the admin to stop. If I see something incorrect or limit it or just send them a message and that'll kill their session because it's going through secret server. And again, I can do that same thing with the recording with SQL management studio, remote desktop. So you have all those recordings in the audit trail, as well as the FSH logs for the putty tool. So if we just drop over, we can see we've got session log here. So I can search through if I wanna see, you know, both commands, they ran, I can see user input as well as server data. And I can also pull down that movie.
So then I get a full view of what they were doing of the system as well as a searchable log on plane. Okay. And so the fifth way that we're gonna look at today for reducing insider threat and insider risk is what about application passwords? Right. So think about your application service that might be out in the DMV that are providing application applications for your customers could be internal applications running in your internet, maybe providing application services to your employees. Oftentimes there's credentials embedded in those config files or build scripts or different jobs that are running. And those again are prime targets for your insiders. They're able to quickly elevate their access by being able to go in and see those care text passwords embedded in those files. So how do we solve that one that can be accomplished through the API? And there's a few different levels of API and secret server.
There's a standard web services API. It can integrate with windows authentication. And we also have several application API libraries. So right here, we've just got a screenshot of a batch file. And this one's actually using our Java command line API. It just makes a, a call to the Java file and actually retrieves a secret from secret server and get the password field out of it. So we can see that before and after, before we had a password embedded in the, the actual batch file. So run the FTP sync afterwards when we're using the secret server API, we just make a call over command line for a particular record and we get the password out at one time. So then secret server can change those passwords like any other, and the applications don't have to be manually updated. And you also don't have passwords in Clearex, which is a big risk in those files.
And so this approach like Ben mentioned, this is for the, the Java API, but we have a.net API and then it can also be leveraged from lots of other platforms. So Pearl power, she PHP pretty much any scripting language or programming language can interface with these APIs. The way that it's authorized to it can either be authorized per application server or even per application. And that's very similar to having a private key. So you're able to almost have like a private key on the server that can then be further locked down with ACLS. And now the vault will recognize that server when it comes in, it can also be coupled with IP address restrictions, if you wanna limit who can use that user account in the vault. And then all of the activity of the script in this case for like FTP will be tracked by the vault. You'll be able to see that app server coming into the vault and retrieving and using the password that concludes our five different ways. And we wanted to hand it back COVID Martin and open up for questions.
Okay. Thank you very much. So I will right now start Q and a session. So as I said, please enter your questions to go to webinar control panels that we so that we can take the questions and, and start our discussion. So the, the one thing I, I don't want to ask you is from your customer experience, how is the perception of sort of insider threat versus external threats currently? And what is driving the projects?
That's a good question, Martin. I think, I think unfortunately it's mostly the press, you know, the news coming out about so many of these inside of breaches in the United States, we're certainly seeing a lot around Snowden. So as you mentioned in your slides, and I think that's just raised awareness, I think it's, it's raised awareness at the executive level. One thing, one phenomenon we've seen, I don't know if you've seen something similar, but we are seeing more and more situations now where the ISO or the CSO is no longer reporting to the CIO. It's starting to become a situation where they report to the CFO or the CEO. And a lot of this is just a, a fact that security is becoming is becoming a more important functional organization. It's not a side thing that it's responsible for, but it's now something where they're starting to make business level decisions by involving security and giving them kind of a full seat at the table. And because that's happening now inside of threat, whenever that comes up, it's a big focus. And then likewise with any external breach, the target breach was, has been huge. We've seen a lot of customers be able to get, you know, resources and budget aligned for their projects based on just all the press and upload that caused.
Okay. So, so we have a question here. I think it's an, it's an interesting question overall, because it's more, more, a little bit from the technical side. So, so does secret server manage SS H passwords or, and, or SS H keys? So what is your approach on that?
Yeah, you can definitely store both of those. So we have automatic changing of the SSH passwords. Some customers have used the API to rotate keys, but you can store sensitive files in there, like those keys or SSL certificates, so it can store both. And it has automatic, built-in changing for the passwords and some customers use the API for key rotation.
Okay. Got then, maybe back to that question before, so you said there there's more and more C CSO C reporting directly this to the CIO. If you look at the, the topic of privilege management you're you're in for a while, how did, or is there a change sort of in the, the people you're speaking the buyers in the organizations, the level of people who are looking at the topic?
That's a good question. So PCOS background has been a couple years back, was more focused with it, operations. They have a lot of experience dealing with it, infrastructure and their concerns on them. And in the last say, four years, we've been working more with it security teams. So I've definitely seen more awareness in it. Security. I think they've over the last again. I mean, not to harp bond, but back to the breaches. I think that's just raising awareness with them. And now, instead of them being focused, maybe just on SIM, that seems to be one of the first steps that security team is, is focused on is how do we deploy and use our SIM tool effectively. Then usually they're focused on building their own sock and, and some way to make that happen. And I think somewhere in there they realize that there's SIM tool, isn't getting them all the data they need, because like you showed in your slide, the shared the generic accounts.
That's great. You can see the activity in the SIM tool, but you still don't know if who's using them. And so all of a sudden that shifts the, the focus. If you look at the breaches, it's not usually the standard users, it's the privileged accounts. So you can get that at that activity, that privilege activity with accountability into your SIM tool. I think that's getting a lot of attention so that that's driven a lot. And then soon as you go to it, ops, they're aware of the problems. They're tired of managing service accounts. So they welcome any sort of changes around that. So I think it's, I think the whole organization, well, the whole it organization is getting more involved in publish account management in the last few years.
Okay. So, so when looking at various, so you have these five, five starting points or the five situations there, and we're looking at privilege management tools. We, we see various features to shared account management, such recording stuff, etcetera. What is from your perspective sort to most common sort of starting points or where, where do do most organizations tend to start with which of the various use cases?
Good question. Again, it depends on how sophisticated the organization is. What we see a lot of people doing is that they just often have very poor practices in place already. Usually it departments are using spreadsheets to manage service account passwords, things like that. So usually the first step is just the vault, you know, get a secure place to start storing things, establish some standards around password complexity, password, age, on those, on those accounts, and then dial it up from there. We put together an implementation plan that we've seen. I, I don't have the diagram to show here, but that we've seen a lot of customers go through and it basically starts with evolve. It moves up to actively testing the credentials, making sure that what's in the vault is really valid. Then typically the, the first use cases I see most customers tackle are automatically managing and rotating windows, local admin passwords, then usually Unix route is next.
And then they might push it out beyond next database application, firewall storage passwords. Sometimes the network team will get involved at that point too and start hitting everything. And then usually once they have some confidence in the approach and they see everything working, then usually service accounts are next. Just that that outage is, was a big fear. You know, like if it doesn't do it properly, then there can be issues. So usually service accounts at that level. And then quite honestly, the last step is usually session recording integration with the student tools, writing the correlation rules that they need looking for anomalies and behavior, things like that. That's kinda a typical evolution that we see.
Okay. That's good answer. When you you've quickly touched the topic of outage. So how do you deal with, with, with geographically first organizations? And I think one of the fears, a lot of organizations have to say, okay, what, what if I, if the system is down, so how to, how to work in that case, how to do still firefighter stuff, et cetera.
So absolutely Martin that's, you know, it's a big one. If you look at we're arguing for centralized control, right? So often they have spreadsheets or little ad hoc apps and really poor ways of managing these passwords. And we're saying instead put everything in one centralized system that security can monitor that all your teams can collaborate on, have, you know, policies enforced that kind of thing. And it sounds an awful lot like putting all your eggs in one basket. And the key there is it has to be a strong basket. So all the high availability disaster recovery options need to be there. So basically quite interesting. Usually the, one of the big things is if you're gonna do the application password management, and now you're gonna have all your application service hitting the vault just to provide, you know, up time of their apps to, to get credentials and run that that's an immediate high availability as, as a requirement, but even just toward geographically dispersed teams, again, it needs to be there.
So the, the typical things that we recommend to customers is to take advantage of the clustering within the product. The clustering on the front end have clustering on the back end. So we support standard Microsoft infrastructure. They can leverage, you know, existing SQL server cluster. If they have that they can use SQL server always on. And typically customers are putting like SSL load balances on the front. They're doing remote Dr. Sites, lots of different configuration options, but definitely if you're invest in a centralized system like this, you need to make sure that it's always going to be available.
Okay, perfect. So I think that was the last question we had here. So thank you to the advent of this webinar. Hope to see you at THEC next week. Psychotic will be there as well. Thank you. Thank you, bam, for spending our time with us and hope to talk you soon again. Thank you.
Thanks Martin.