Good afternoon, ladies gentleman, welcome to our equipping a cold webinar, protecting the keys to your kingdom against cyber attacks and insider threats. Securing privileged accounts has to be your next step. This webinar is supported by psychotic. The speakers today are me multi equipping. I'm the CEO, founder, and principal Analyst, keeping a call. And as bunsler who's executive director of security at psychotic to start with some general information, some housekeeping keeping a Kohl's Analyst company for providing enterprise it research advisory services, decision support, and networking for it. Professionals. Amongst these services, we offer a number of events and two of our upcoming events are our European identity and cloud conference, which will be held next time, May 10th to 13 in Munich. It's the number 10 event of the European identity and cloud conference. And it's an event you definitely should not miss. And at September next year, we'll start with our digital finance world, which has been focusing on the transformation, the finance industry.
So all the FinTech stuff and so on, but also influences from new types of technologies, such as blockchains and distributed lectures. Also definitely an event which is very worse to attend regarding the housekeepings some guidelines for the webinar. You are muted centrally, so you don't have to mute or unmute yourself. We are controlling these features. We will record the webinar. The podcast recording will be available tomorrow, and we will do a Q and a session at the end. So you can end the questions at any time using the questions featuring go to webinar. Usually we pick all the questions at the end. It's a, basically a good idea to enter questions once they come to your mind so that we have a long list of questions to go through in the Q and a session. The agenda for today is split as usual into three parts.
The first part I will talk about why solutions for privileged account security and management are imperative for any global enterprise today. And the second part Nelson Wesler psychotic will talk about how psychotic secret server can help you easily control access to critical passwords in one centralized web-based repository. And as I've said, the next part then will be our Q and a session. So to start with, I want to start with, what do we really need to protect? So what so to speak are an organization's ground tools. And when we look at these ground tools, then one of the, I think these days, most important ones is brand reputation. Print reputation is also tightly connected to a number of other areas. So when you, as an organization lose customer data, it affects your brand reputation. And when you have other incidents and they become public effects for interpretation, this topic is far more important in these days because brands are important on one hand, brands have a value it's coupled directly to your success with customers.
And on the other hand, the risk that you end up in news is far higher than it ever has been before. So when we go back some years and you had an security incident, you most likely ended up at whatever page 15 or 17 of a computer magazine and few people really cared about today, you might make the header of the news and TV. So things have definitely changed. Another area of the ground tools is customer organizations tend to have far more customer data than ever before. It's part of the business. There's a value behind customer data. Customer data definitely is a very important part of the crown rules. We have the intellectual properties I've read of survey some two years ago or so, where companies answered that round about 50% of their corporate value's based on their intellectual properties. So for my some organizations, it might be more to customer data for others.
It's more the intellectual properties, particularly when you go to manufacturing and other types of industries and it's people. So people who are working in the organization because hiring, firing, getting new people on board, educating them, et etcetera, some expensive process. So people are another part of the crown tool because they have a lot of the knowledge in their mind and to protect these ground rules or at least portions of them, which are, are particular around customer data and intellectual property. And then in consequence around branch reputation, we need to understand where are our biggest risk risk. And one of the things we need to look at is privilege management. When we look at privilege management, I think it's very important to understand privilege management is not only about shared accounts. So, so basically there are within the privilege management area, there are some disciplines. One is the shared account password management or what I right now here in slide called privilege management in the traditional sense.
And there's the session management, which is more on who is accessing a system in which way, controlling monitoring these sessions, etcetera. And basically we have two dimensions. One is more, is it a personal account or is it a shared account? The other is, does someone have standard privileges? That's the Y axis or does he have elevated privileges? And we have personal accounts with highly elevated privileges. So ACP power users, some operator accounts. On the other hand, we have functional accounts or technical accounts, which are shared, but might have relatively low privileges on the other hand. And then we have the highest or most critical accounts, which are both elevated and shared, which potentially carry the biggest risk, whereas a standard user account personal and not that much elevated is a lower risk. So when we look at privilege management, we have to look at various aspects. We have to look at how can we manage share accounts. We have to look at how can we manage sessions of elevated users? How, where are all these functional accounts and all these questions are questions we have to solve.
When we look at where shared accounts are in use and a little bit on the distribution, this is sort of a rough estimate or an indicator, but depending on the level we are working on, we have sometimes more shared accounts. And sometimes we have more individual accounts. When we look at a client, many accounts are individual accounts. On the other end, we have still on every client. We have a number of system account service accounts, and other types of accounts, which are sort of shared accounts. When we look at network components, access commonly done, we are shared accounts and web service. It might shift a little bit more to, or the individual accounts. Whereas the hyper wise, we, again, commonly use just shared account. I think this is very important. These pictures are important for, for, from, from two perspectives. One is it shows, yes, we have on one hand shared accounts and we have individual accounts and we have to care for both because the risk might be on both ends.
The other thing is privilege management is not only the server operating system. It has to happen at all levels of our infrastructure, the host operating system, the hypervisor, and so on up to the client, it's something where we have to support a broad variety of systems because ethics can happen everywhere. And these ethics become more and more ubiquitous. When we just look at the reality of how everything and everyone have become and increasingly become connected. So more or less ever sing is connected, smart Watchers, wearables, etcetera, communicate with devices. They communicate back to some organizations, people use a number of these devices. So we have a very complex network. And I think one thing is very clear. Once something is connected, you can attack it. So some connection means attack surface. That's a very simple equation. And that also means that we are facing a fundamentally changing risk surface.
So historically seeing our risk surface has been the client to the server. So we had our application running an operating system. We had the application administrator and system administrator in our end organization. Then the hyper wise and the host operating system came into play with more administrators. And then we have right now, a lot of stuff also running in the cloud where we have another type, another crew of administrators. So we have in various directions, we have fundamental changes in the risk surface. We have more layers. We have more deployment models. We have more types of connected systems. That means the risk surface is far bigger than error. And we have to react on this. And in particular, when we go back to the privilege management part, clearly the more privilege that someone has, the bigger risk and administrators operators, they have the biggest risk.
So the biggest, the largest entitlement. So they are in fact causing the biggest risk. That means we have to in particular, look at these accounts, how can we manage them? How can we deal with them? How can we protect them? And that means we have to implement full privilege management life cycle. We need to understand first, what is our challenge? We need to understand what to do. We need to identify the privileged accounts. We need to protect them. We need to monitor what is happening. We need to detect things that are going wrong. We need to detect things that are suspicious. We need to look at these things. We need to respond on that. So we need to take actions. When we have science of fraud, science of abuse, whatever, and we have to improve. We need to get better to reduce our risk exposure, our risk surface, our overall risk.
So it's from our perspective essential and the changing landscape to fully support this entire, what I call privilege management life cycle. This is what we really need to do. And we need to invest in that. And we need to understand that it's highly important to act now and to do it always with risk in mind. So we have to understand what can we do? What can we achieve in risk mitigation by doing certain actions or taking certain actions? And one of the things we, we are observing again and again, and in that context is that there, there are a lot of things you can do potentially, and, and frequently investments are not made because someone then comes up and says, but doing it that way might cause that theoretical security risk up there. It's not a hundred percent secure. Let me just bring in some thoughts here.
So one saw, and it's not only a saw. I think it's a fact. There is no 100 person security trust. What I think it was Illuminati this movie where someone then attacks an Iris can, some of you might have seen it, how they have done it. There's no 100% security never, ever. There are always ways to overcome it. And simply that blackmail and other things are one of the increasingly typical approaches because there's a lot of value behind data and its on so organized drive, which is one of our largest attacker has its way to has its ideas on how to find a way into organizations and through people. This is something which is relatively easy for that group of attackers. The other thing is the closer we move to 100% security. The higher the cost, the limit of security cost for security moving towards 100 is infinite.
So it's extremely expensive to do the last mile. To last few percent of security, you can reach a certain level of security Raza quickly, but don't try to reach 100%. The other side of those things is that's again, where, where risk comes into play. We have to look at what is the cost of an incident and what is the cost of risk medication. And here, if we don't mitigate any risk. So if we have 100% risk, obviously there's no too little, little to no cost. If we move towards 0% risk. So towards the left side of this second chart, then again cost grows exponentially and we have to understand what is our cost of risk mitigation and what is our cost of incidents. And that is what we really can spend. And then we have to understand where are our biggest risks and where to invest and clearly around these administrators in an increasingly connected world, there are big risks and there are on the other hand, a lot of approaches out there which can help us to mitigate a significant portion of that risk at a reasonable cost.
That's what privilege management is about high risk and technologies to address the risk. So when we look at more, from a future perspective on how does the privilege management landscape look like today, then we have sort of two core groups of features. One is the shared account password management area where see the one time passwords privileged singles and answer accessing various administrative sessions was one single and accounts scanning. So which accounts are out there and so on and all the type of things. And then we have the session management part, which is looking at running sessions, monitoring them, recording them forensics and all the other things. And then we see an increasing number of additional features, such as anomaly detection, application, privilege management, and more. And we need to integrate it with our identity provisioning. So every shared account should have an owner. We need to integrate it with cm and realtime security intelligence. How can we first analyze the results, et cetera. This is the landscape we are looking at. And from my perspective in an ever increasing connected world and was ever increasing risks from the various types of cyber attackers, we have to in west, in privilege management in particular privilege, account management technology, and one approach to this is what Wester right now will talk about. So give a look at how secret server server can help you easily control access to critical passwords in one centralized web based repository. I'll hand over the role to it's your turn.
Hi, my name's Nathan Wesler. I'm the executive director of security with PCO and what I'm going to do here. My piece of this is continue to piggyback off the conversation that Martin has, has laid for us here as a foundation. What I wanna start with is to talk a little bit about what we see at DCO as a company that focuses very strongly in the privileged account management space. What we kind of see is going on out there with, in the industry as a whole and with our customers. And one of the continuing trends as Martin said is risk. And we find that time and time these situations when say data breaches as an example, which can affect all of the items that Martin mentioned, the reputation, loss, intellectual property loss. And so on time and time again, these sorts of things come back to the abuse of privileged accounts.
A survey that we had worked on with S a research firm out of Boston, Massachusetts, almost two thirds of data breaches from their customers and, and participants were reported to be from account abuse for these privilege accounts. And that can come in different forms. Of course, this can be the breaching of those shared elevated accounts. So we're talking about like local administrators and domain admins, root accounts, these kinds of things. But this also happens from normal accounts, which get compromised and then are eventually elevated up to a privileged state as well, which moves them into that other category of user based, but elevated types of accounts. So in whatever form of these privileged accounts exist, they're a key, key attack target for both malicious outsiders and your rogue insiders. Should you have a problem in house? These are situations where once you have those credentials, this is, this is the easy way to get to those crown jewels.
So when we work with our customers and talk to them about these kinds of problems, we tend to discuss, protecting those crown jewels as close to them as possible. The perimeter's still very important, but in today's connected world, it's becoming less relevant. You've got outsiders coming in. You might have contractors, third party folks. You might have employees working remote and we more and more do business outbound as well, more business to business, more cloud based hosting the idea. The traditional idea that we've had about perimeters is somewhat dead, but we need to be able to draw a line somewhere. And what we tend to say here is that identity is really the new perimeter identity, whether it's a shared account or is a personal account, defines what access you're allowed to have. And if you can get to the data, then you get there. If you draw lines based on identity, if you can draw perimeter based on that identity parameter, then you can really start to do some very powerful things in protecting those crown jewels.
So moving onto a little bit of, of a, kind of a, a fun info thing we've done here, we, we went to the black hat security conference this year, and we asked a number of attendees, people who are either researchers and pen testers, legitimately in the security industry, as well as some folks who identified themselves as hackers, whether that is nefarious or not. But we asked them some questions about what they were seeing and what they were doing in terms of privilege accounts and how they, they saw them. And the results that we saw were, were pretty interesting, even with all the investments that's been done in security, even as, as we move closer and closer to trying to reach that 100% secure state as Martin described, even now, we find that three quarters of the, the time accounts are still just as easy to compromise as they all always were.
And maybe more so troubling is that additional 12% that says it's even easier now. And a few of the folks we talked to about this, this is a very interesting point for us because it, it reflects the complexity of what we do in our organizations, as well as the security tools that we try to layer in the place to protect that organization. And as it becomes more and more complexity becomes more and more places for people to attack and potentially break them and then compromise the systems to get in. So it's something that, you know, even with all the effort that's been made, it's becoming more and more clear that we still have a lot of work to do, and that maybe we're not focusing in on the right places. Again, if two thirds of the, of the time a data breach can be traced back to account abuse, this is a pretty common sort of thing that should be looked at. And if it can be dealt with you can start to build a much stronger security platform for everything else. I'll talk a little bit more about that in an upcoming slide.
So to go a little bit more in depth here, with the idea of privileged account management and the kinds of pieces that should be part of your core strategy for how you protect these accounts, do you like to break it into three categories of, of features or really three categories of function that is control auditing and monitoring very similar to, again, what wood Martin just described when we talk about control while this, while role-based control is very important and defining who is allowed to access the credentials and who is allowed to access end points with those credentials, there are other aspects of control, which be just as important. We also look at controlling the credential itself, and that can, that comes usually in the form of password rotation. As much as we have often heard the rhetoric that the password is dead. We know that a lot of these systems will almost essentially never be without usernames and passwords.
It's simply the way they were built and legacy systems. If nothing else will require that we have to manage these things into the future. And if we have to manage them, then we should make those credentials as difficult to compromise as possible. And we do that today with password complexity and password length requirements. We also wanna make sure those passwords are changing on a very frequent basis. And it's really in that changing that we gain a lot of power and a lot of control over that credential. If we make it essentially impossible for somebody to guess the password or brute force attack the password, or in some other way, shape or form use and figure out what the password is, then we really have done a very, very good job of protecting that credential. So automating the piece of rotating the passwords is, is a really key step on gaining control.
Once you've got some side of control, obviously you wanna be able to audit everything that's going on. You want to be able to forensically go back and, and figure out what had happened. And this is incredibly critical for those shared elevated accounts. Cause typically they are not assigned one to one to a human being. It makes it very difficult to know who has accessed that account and what they did with it. When you look into a privileged account management solution, you should be able to very easily find that one-to-one relationship that say myself, Nathan logged in one day, got a hold of a domain administrator account, and then use it to log into a mail server. All of those actions, all of that, that access, if it's been granted to me should still be audited so that I can correlate what is happening and be able to identify that the human involved Nathan was the one who used the shared sort of non-human account.
And with that, then you move into the monitoring space. And this is where as Martin mentions, where you take action, you know, you can record sessions, you can monitor sessions as they happen. You can, you know, also have triggers take place to notify you when something anomalous happens. If somebody is logging into a domain controller, maybe your security team needs to know about that. If that's not expected behavior, if you've got third party outsourcers coming into your environment, logging, trying to access credentials that you shouldn't, you might want to notify an incident response team or, or go from there. You wanna be able to, to take those kinds of actions once you've got that correlation from your auditing and be able to also correlate that data back with SIM tools, to make sure that we are integrating all of that access into all of the other layers of security controls that we've got in the environment at the end of the day, credentials are really the, the core of this. So if we can get our arms around it with these kinds of feature sets, we can then leverage that, that control into all the other areas of our security program.
So I, I like to start with this slide every now and then when I, I give some presentations in other locations, and I like to refer to this as sort of my chaos slide, and I do it this way for a very specific reason. This is essentially a way of highlighting. Martin's earlier message about the complexity of dealing with accounts in today's day and age. When I have in previous, in my previous life, if you will spent a lot of time doing consultant work with government agencies, as well as large private sector companies, we often have a conversation where we'd sit down and talk about what sort of credential management they're dealing with and where they think these elevated privileged accounts are being used. And usually what we're told, or what I was told was the sort of the gray section, right? They know that there are admin accounts and service accounts that are being used in the infrastructure applications, talking to databases, network devices, keeping it all together, file servers, that kind of thing.
But what organizations typically forget about really is everything else. And whether that's from your it admins who arguably have access to everything in a lot of cases, that's very true. And they're typically doing that access from their workstations or their laptops. So now you have yet another point of entry that if that laptop or workstation is compromised, now, an attacker has a lot of free reign to move elsewhere. You've also got your standard users and they're coming in again from the inside or the outside. And they rely on these services as well. They're touching active directory or whatever directory service you're using. They're leveraging application accounts. Some of them might be application admins cause they're HR system or a financial system that they're managing. So really credentials kind of are everywhere and that where they're being passed around or use is quite literally everywhere in your organization.
So it's a very big problem to try to wrangle all of these administrative accounts, all of these elevated access accounts. And the way we wanna try to do that is to move to that centralized model and find a place where we can gain control of the, not just the credentials themselves, but the access to this credentials. This is where, and this slide now is kind of the model you want to consider for a privileged account management solution. If you can control the credentials in a single place, if you can doll out access appropriately to admins and users, you then have a place where you can audit all the actions that get taken. You have a single place to monitor all of these things, and you can make sure that these are linked into other services like active directory or SIM tools, IDs tools, whatever other layers you need to.
You've got a single point now that you can plug into those other aspects and really start to have a very powerful security model. And this is a really key point of the conversation, at least for my purposes, because it's here where if you can, if you envision this model for access, obviously this is very firewall. Like, and that's the point. If we're, if we talk about identity as the new perimeter and we can draw those protective lines there, privilege account management goes well beyond just dealing with the credentials, right? If you start to see the power of the model in terms of centralizing control, and then being able to doll back out access, there are a lot of different use cases you can begin to address. And we see this and, and I'll talk a little more about some of our customers and whatnot in a moment, but we see this quite extensively with our customers.
They more and more as they sort of get past this notion, that privileged account, management's just about passwords. They then move into a much more mature implementation where they can start addressing use cases like these. Now some of these seem pretty straightforward securing local administrator accounts and service accounts. That's credential management to some extent, but you know, what about it? Admin turnover? You know, when, when an admin leaves, if they've memorized all these passwords, what do you do now? Well, if you centralized control of the passwords, if you have been rotating them often, it's likely your it admin doesn't even have any passwords memorized. Not only does this buy you time in a sense, but it also gives you that centralized management tool to rotate all the passwords immediately. You can very easily protect yourself from the situation where an it admin leaves. And, and in fact, you can automate this end to end.
We see a number of our customers. Who've actually integrated this point into their HR systems. And so that when an employee is terminated, it automatically goes out and rotates these passwords so that all of the credentials are secured long before the employee has a chance to even get home, to do anything to various. Should that happen? Another one that we see quite extensively and, and a growing number of organizations are looking at this is for application security for many, many years. It's been a common problem to see organizations hard code credentials, into script files, into API calls, into even compiled applications. It's often argue that it's just simply the easier way to deal with it. But with strong privilege account management, you can actually solve this problem. There are ways to essentially tokenize the password so that you do not have to embed it into any kind of script or code file.
And then once you do that, you can have the system automatically grab those credentials from the central Pam repository and get whatever the current password is on the fly. And this is a very powerful thing in two ways. Obvi the obvious method is that if we don't hard code credentials, then an attacker cannot easily steal those credentials. They can't find the script file and just copy and paste it out. And this is very dangerous practice because simply you put, if we hire code these credentials, they are not going to change. And I have not yet heard a, a developer in any organization I've worked with say that they will recompile their application every week or two, just to update a password file. So an attacker knows if they can get ahold of those kinds of credentials, those credentials will be good for a long time.
If we can tokenize the password, if we rotate them out at a central location and simply have the application call back that information, then we can eliminate that particular attack vector. But the other benefit we get out of this is also similar to the it admin turnover problem. It's a developer turnover problem because if credentials have been hard coded into an application, at some point in time, somebody has handed that credential over to the development team. Someone has given them a username and password and they all know it. So if you can, instead automate that process of dealing with it in a way that's code based, it's not revealed the password. You can also then stop the practices of doling out those kinds of credentials to your development team and have them become shared accounts. So a lot of different use cases that we see now are happening. And again, it's all about once you have control of those credentials and can layer on the feature set that you need to really effectively automate the, the management of those credentials. There are many, many, many use cases that you can address in a very powerful way, well, above and beyond password changing.
So with that, let me talk just a very brief moment about ourselves and where some of this insight comes from as well as how secret server our privilege account management tools fits into this. We are dichotic. We've been doing privilege account management software for over 10 years now with organization size, from mom and pop organiz people all the way up to, you know, fortune 10 companies with thousands and thousands of it, admins that are, are dealing with their privileged account credential problems. What sets us apart in a lot of ways is, well, what you see here, we are the easiest to use and easiest to customize school in the industry. It's a tool that was designed for administrators ultimately. And because of that, there's a lot of power to extend the use through scripting, through API support. It's a very, very simple and easy tool to use, but it's also very simple and easy to extend outward into your custom applications, your custom hardware or whatever else that you might have in your organization.
As you can see, we, we have over 3,500 customers and nearly 200,000, it admins worldwide use the tool. So we have an extensive tool to draw from, to get insight into this industry and where we are able to really bring into kind of laser focus, how to deal with these credentials in an appropriate way and see how the industry's responding and how that benefits a large number of customers. And as you can see, we do have customers from just about every vertical. It, it is something that I, I use this slide as, as a way to emphasize one important point and Martin hinted at this as well. And I think it's, it's one that's useful to remember here. I sometimes will get asked this question. You know, what verticals you guys do really well and the energy sector most concerned about these things is government most concerned about this finance, you know, who, who is, who needs this the most. And my answer to this question is always, it's the company that has passwords. There's, there's really no one type of company that needs this more than another. Everyone does. Everyone has a brand to protect. Everyone has critical customer data. Everybody has an intellectual property, and it doesn't matter if you're finance, if you're software, if you are government, whatever it may be.
Everyone needs to be able to protect these credentials and deal with the viability of the organization from that standpoint. So for privilege account management, our tool is called secret server. This is our core and enterprise product that deals specifically with privilege account management will help you lock down those accounts and then provide that kind of access. We discussed all from a single central location. We can help with the discovery piece, we help solve the unknown. It's a very common issue that we see in a lot of organizations, not knowing what they have, not only can we store the accounts, but we can automatically go out and find them whether those are windows accounts, Unix accounts, even VMware hypervisor accounts, you can automate the whole process of going on, detecting where these accounts are and more importantly, even how they're being used. And this is a key point, especially for say windows accounts that might be used to run services or scheduled tasks. You can leverage that centralized model to go out, interrogate all of your systems and find out in an automated fashion where the accounts are being used, how they're being used. And this avoids the whole problem of having to send people out to do it, or try to remember what they did or look up in their personal spreadsheets. What happened. This helps to plug a lot of those kinds of holes that can happen when you rely on manual processes.
Now we also provide the ability to fully manage all of this. That can be from the automated rotation to all of the accounts that we just discussed all the way down to alerting practices so that you can know when something a miss is going on. You know, whether that's a new account that's popped up that you're not expecting, or whether that's a user that is trying to leverage a credential in a way that you don't want or violates policy. You can layer at a huge amount of management functionality into your credential management scheme. Once you have them centralized, once you know where they are, you can really do some very powerful things here with being able to manage this for your users.
And finally, we also then deal with the monitoring aspect. We help you make certain that these things are fully accounted for that. Everything is a testable that if you need to respond for audits, if you need to deal with any kind of forensic activity, if you need to respond to auditors, you can really dial this into a point where you, every action is, is recorded. Everything that is done is known, and this leaves so little to, you know, to chance that if there is something unusual happening or activity happening outside the scope of your privileged account management solution, it's a true red flag. I mean, this is an area where I often will argue that you can improve the strength of the rest of your security layers. If you can do this piece, if you can protect these credentials, if I can monitor them to the level that I know, the only time they ever get used is through this centralized system. I've got monitoring tools in place to verify that we've got SIM tools that I can correlate this with. If I see those credentials used anywhere else, I know for a fact, it's a problem. That's reducing the number of false positives for my IDs systems. It's reducing then the amount of overhead and noise that may end up in my log management SIM systems. It can be a very powerful way again, to just increase the effectiveness of the other security layers. Once you can get ahold of this level of control and protection for those accounts.
So I will just reiterate a couple of these things, managing all of this and, and having that central repository, if you will, for all of your credentials can be a very scary thing. How you deal with that of course, is to leverage a lot of enterprise class features that we see in, in all software packages and really we should at least so for our purposes and our, and our product secret server, obviously it's very scalable. We have organizations that are dealing with quite literally millions of credentials, all through a single console, wherever they are on the planet. We of course support database clustering, load balancing, making sure that the central pro is resilient, that it can scale outward. And that is not going to become a, any kind of single point of failure for you. And I do wanna emphasize, again, the customizable part between APIs that we leverage extensively throughout the tool scripting support that we build in just about everywhere to it.
It really is designed to be as flexible as your organization needs. We see a lot of custom development and a custom work done mainly because every organization does something a little bit different. And the flexibility that's provided here within secret server allows those organizations to continue doing business the way they want to do it without having to change their processes, to accommodate our tool. So very important philosophical issue for us. And it's one that for privileged accounts and managing those privileged accounts, I think is a really, really critical thing as it makes sure that the business gets done when it needs done without getting it without the tool getting in the way. And it's a very, very key point for us that, that we wanna leverage and, and emphasize here about privilege account management functions. So with that, I'm going to turn this back over to Martin, and I believe we have some time left over here for questions.
Yes, Nathan, thank you very much. And as you said, we have some time for a question. So we are right now in the third part of our agenda Q and a session. And as I said, if you have questions it's right now, time to enter these questions and the questions tool, and they go to webinar control panel so that we can pick these questions already have some, some questions here. So, so nice. What tends to be the first features implemented for organizations we're starting with a Pam solution?
Yeah. Getting started part is, is always, I think the most difficult part, but I think what we see most commonly is the discovery piece. It's really trying to understand the lay of the land. Really understand what you have. I see a lot of organizations spend a little bit of time upfront with the discovery functionality so that they can at least know what's there. And then, and then start making decisions about what they're going to do to protect them. There's been a, a few cases where we've seen an organization sit down in a boardroom table and decide that they're going to, you know, rotate passwords every one week and they're going to put all these controls in place and they, they build out the framework first and then start putting accounts inside of it and managing them. And inevitably what happens is they have forgotten about some application account. They have forgotten about, you know, some administrator that is in a different location or some something has fallen off the radar and then they have to stop and, and rethink everything. So most organizations, I see them start with that discovery piece, really try to understand exactly what they have out there, where those accounts are being used. And then once they have that data, they can make really strong decisions about how best to protect them, who should have access and what kind of controls they wanna place on those accounts.
Okay, perfect. So another question I have here is what sorts of trends are you seeing with current customers in terms of their usage secret server?
Yeah, there's probably just a couple of things that I see are happening more and more now. And I think as, as organizations mature and they get past that initial hump of discovery and control, we're seeing a lot more interest in application security. I know I touched on that one a little bit, but it even just in this last year, I have seen a huge increase of interest in people doing, dealing with hard code credentials. And, and in fact, I I'll even mention one of our customers who who's Adobe uses this extensively in their build processes. And we're seeing more organizations take advantage of automated software, build processes and integrating this in so that no developer, no QA tester, no compiler, nobody involved in the software process actually touches credentials. And there's a number of organizations that do custom in-house development that are starting to look at that kind of model as a way to shore up what they're seeing, what they feel is a very, very significant vulnerability gap in their software development, in their build processes.
Okay. Thank you, Nathan. I think the last question I have here for now, what business crews are you seeing have the most interest in implementing them?
That's a, that's an interesting question. I, I have, so I come from a security background. I I've been working in the security side of life for gosh, almost 20 years now. And I honestly, I had always assumed that this was a security tool. That fact that's all it was ever for was for auditors. It was for, you know, chief security officers who wanted to have control of this stuff. And we obviously we see a lot of security teams driving the project for privilege account management, but what I have learned, and especially my time here at tic is that almost equally, we see operations teams are often very interested in this product or these processes because they see it as an efficiency solution. If you can centralize your access, if you can use it as a jump post, if you can, you know, I can make it very simple for my outsource group that I'm managing to come into one location and then only get access to the one thing they need. It becomes actually a really powerful tool for operations folks. And that hits kind of a sweet spot in a lot of ways that I know security organizations struggle with, which is to get buy-in from the operations team to actually use the tool that they they buy. And it's interesting that I see this almost equally, both sides of the house tend to fall into wanting a solution like this because it brings, it brings gains to both sides, more secure plus it can become a much more efficient tool for them. So,
Okay. We just got another question and I think it's a very, very interesting one. So, so can you elaborate on how secret server handle as geographically disperse a multi domain organization? So more complex environments?
Yeah, absolutely. We, we use a concept, we call distributed engines, essentially what it is is, and, and there's a couple of ways to architect this. So depending on your organization, we can obviously talk about different ways to do it, but the most common way would be this distributed engine concept. So you still have to have a core setup, you know, at the, at the heart of this thing you're dealing with with encryption. And so it makes it very difficult to duplicate that all over the planet. But what we do instead is take these distributed engines or these very lightweight, essentially it's like a robust windows service that you can place in that disparate network could be DMZ, could be geographically disparate, whatever the case might be. And that engine is your foothold into that other location. It does essentially all of the work for discovering where accounts live or rotating passwords for, you know, managing the requests, that kind of thing.
And they will feed that data back to the central repository so that you can do all of the functions without having it, you know, wherever you are globally, come from that central server or central clustered servers. On top of that for a front end standpoint, we use, you know, basic web services on the front end. So IIS standard for the, for the web application side of it. So you can scale that out pretty easily. I mean, Microsoft does a pretty good job of, of making that easy. So if you have large groups of users in other locations, you can spin up application servers wherever they are. And they would interface obviously with that front end, which would reduce flag time or, you know, whatever the case might be, depending on where they are. So there are several tools we have to offer that can help deal with disparate networks in whatever way they are and makes it pretty easy. Like I said, we have a organization that, or one of our customers and they have 35, almost 4,000 admins worldwide in about 170 countries. I'm trying to think very large energy company and, and they've been able to leverage its kind of infrastructure very successfully for all of their users, wherever they are.
Okay. Nice. Thank you for this good and extensive answer. I think we are done with the questions. So thank you to all the participants for listening to this call webinar supported by psychotic. Thank you to, to you Nelson for your presentation and all the insight you provided and hope to see you, or you soon as an attendee again at are one of our call webinars and meet you in present at one of our upcoming ones. Thank you and goodbye.
Great. Thank you, Martin. Goodbye, everyone.
