The Future of Privilege Management – Understanding the Bigger Picture

Good afternoon, ladies and gentlemen, welcome to our Ko Cole webinar. The future of privilege management, understanding the bigger picture. This webinar is supported by one identity. The speakers today are me Martin Kuppinger I'm CEO, founder, and principal Analyst at Ko Cole and Jackson Andro from one identity and TRX knowable then explained a new brand one identity. When his part of the webinar will start before we start some housekeeping information on some information about the agenda could be a call Analyst company. We providing enterprise it research advisory services, decision support, and networking for it professionals. So our research services, our advisory services and our events in the area. We went, we have two upcoming conferences. One is the digital finance world, which will be held March 1st and second 2017 in Frankfurt and the European identity and cloud conference in Munich main ninth to 12th, which will be the 11th edition of our lead conference.
And I believe it's an absolutely absolute mass attempt, went some guidelines for the webinar. You are muted centrally, so you don't have to mute yourself. We are controlling these features. We will record the webinar. The podcast recording will be available latest by tomorrow and the Q and a session will be at the end. You can end the questions at any time using the questions feature in the go to webinar control panel, which is, which is usually at the right side of your screen, so that I can pick the questions them whenever appropriate. When we look at our, at our agenda, this agenda is split to three areas. And the first part, I will talk about a new normal for privilege management, where privilege management is heading. The second part, then checks and show of one identity will talk about one identity integrated approach on privilege management. And in the third part, then we will do a Q and a session. Again, if you have any questions, you can enter them at any time and we will pick them. So let's start. I want to start with something which was a little bit bigger than the, the privilege management. You know, some of you might name privilege management, privilege, identity, or privilege account or privileged user management.
I think that the entire topic is somewhat changing in the scope of more people being connected with more devices, more things, organizations, and ever increasing complexity and within such complexity. We also see that the number of privileged accounts privileged shared accounts for, for access to things, external accessing sensitive systems of organizations within the organization outside of the organization is sort of an ever growing number. So we, we have more and more situations where we talk about privileged access. And so where we have to think about what do we need to do for privilege management? The other thing was this connected world is when we look at it from the other side, it means things are increasingly open, which means that we not only have the privileged access from internal, but we also have externals which have privileged access that might be managed service providers, or we are accessing the cloud, or we have the attackers, which try to get access to gain access to privileged accounts.
And so in this world, clearly the need for privilege management is increasing. So what are we talking about when we talk about privileged access? I like to, to split it into three types of access. One is that an account? So individual account has some entitlement for our system and that system uses another account, which commonly is a technical or functional account with other entitlements to access another system. Then this second account, the one, the technical account accessing the other system, for instance, the database in the backend is an account with elevated privileges. A privileged access is happening here. The second scenario is about shared accounts. So if multiple persons can use the same account to access the system, we have another scenario. The, but in that case, we don't necess necessarily have highly elevated privileges, but we haven't higher risk due to the fact that a shared account isn't used.
And the third area is that we have individual accounts which have highly elevated privileges and does impose major risk. So that might be uses, which are now have another look at is in a later slide that might be uses, which are in the system administrative space. But this might, might also be business users with highly elevated privileges, where we need to implement additional controls to mitigate risks. And when we look at privilege management, then one of the, the main things to, to do is on one hand to mitigate the risks of privileged users. And on the other hand to fulfill the requirements of regulatory compliance, this is not easy to solve. Always. Sometimes we also have the situation that we say, okay, if we want to monitor sessions, we might end up with problems regarding compliance or the legal aspects role. On the other hand, there are more regulations which are about how do you control the flow of data? How do you control the access of data and privilege management managing the privileged access, restricting privileged access, mitigating the risks. This is something which helps us to remain or to become compliant and clearly mitigating the risks is one of the most important things because, and I already touched it for instance, attackers still targeted attacks always are after privileged accounts.
Okay. And then with, when I touched this also before, when we look at what is happening these days, the risk surface also it's changing and it's changing in sort of a variety of ways. One thing is we ha don't have the only, the sort of the traditional way where we say we have an host operating system and we have an system administrator who's accessing the system, but we have more and more situations where we have, so the traditional way would be operating system application, the middle pillar here. And we have a typical scenario, which says we have the host operating system, we have the hypervisor, we have the gas operating system, and then we have the application. So we have the application administrator and potentially also uses this elevated privileges. We have the system administrators at the guest operating system level, the system administrators at the hyper wiser level and the system administrators at the host operating system level and what adds to the challenge here.
So we have more of them. We have more privilege users than before we have bigger risk surface. And on the other hand, we have the access to the cloud. We have the managed service providers, so managed service providers, helping us with our internal or cloud systems, cloud service providers, where we have the cloud service and the cloud service providers have his administrators and operators. And we have our, so we are to some extent operators and administrators of our talent while CSP is the operator of the entire cloud service, but also might be privileged in access to our talent at a, in the cloud. And for MSPs, it means we have also another group and we see more and more use of MSPs. We have other external administrators and operators working for us on our assistance and all of this is privileged access. So the risk surface is changing.
And particularly in this context of MSPs and CSPs, we see a number of additional or major risks. And I just wanna work through quickly. So clearly there are, first of all, there are the risks we also have for internal privileged users for internal shared accounts, but there's also risk of someone intercepting the communication between the MSP and CSP and the customer or the customer and the cloud service. We have more interfaces for communication. We have a risk of app use of privileges of operating administrators at the MSP. And maybe also at the CSP, depending on how, how security operations are set up at a CSP.
We clearly have a challenge that we have some lack of meaningful audits for MSP CSPs and the lack of insight into activities at these. So we need to find ways to, to get better here. And we also might have issues with identity and access management. So do we really know whether all of the operators at MSP use their individual accounts or whether they share accounts? We don't know. So we need ways to handle all these types of privilege, privileged access. And I think what is very important to, to understand and to have in mind is that privileged, privileged management or privileged access management is not only about shared accounts. So there's on the horizontal access. There's the traditional privilege management where we have on one hand personal on the other hand, the shared accounts and on the vertical access we have, well, I put in more the terms session management, because this is more the type of technologies applied here.
We have another access at least, which is about sort of standard normal access or more elevated access. And so a standard user account is personal and has sort of standard access, but there might be other types of users. So call center operators, which have a little bit elevated privileges because they can access customer records. For instance, the windows operators, the office 365 admins, which might be shared to some extent, the SAP administrators highly elevated or the rude, highly elevated and shared. So we have a number of different accounts and we have to understand for all of them, we need some form of privilege management to mitigate risks. And it's here. I have another, another slide, which makes clear that it's not only about shared accounts. So when we look at this is really a rough picture of the distribution of shared account versus individual accounts.
Then at a client end, a lot of Stu a lot of we are individual accounts, but we also have to service accounts. We also have system accounts. We might have an administrator account accessing this network accounts are very much on the shared account side, still so frequently for tu cetera. You still have a situation where you access these devices with one standard account web server, more on the individual side, the same for application service database service. We have a lot of technical accounts, which are shared by, by, by, by default, the guest operating system, man varies a little. Then we might have more individual users and so on. So what becomes clear is we have still a lot of shared accounts, but we also have a lot of highly elevated individual accounts. And we need to apply privilege management for all of that. And there are various things we can do.
And when we want to mitigate risks, there are various ways to do it. So when it comes to mitigating nature risks, some of the priorities you should set local privilege management. So how to manage local access of privilege uses and shared accounts who can access these, who can log in the identity and access management part, manage the identities and entitlements appropriately. The less entitlements people have, the less harm they can. Cause that's, I think a very important thing here as well. So manage the identities, entitlements appropriately, we have to privilege staff monitoring. So this is about monitoring the sessions of operators and administrators and their access to cloud service, MSP access. We have the area of anomaly detection. So what is changing in the behavior and new area? Are there things which are not normal? It might be that the account is high checked or that an internal administrator becomes fraudulent and we need better audits.
So we need a, a number of things and not all of them are traditional identity management, so traditional privilege management. So if you look at identity access management, managing the ownership of shared accounts, something which commonly happens more in the provisioning and the access governance world. Anyway, the privilege management landscape still has its sort of core elements. When I look at these core elements, then I have two major areas which are shared account password management with onetime passwords privilege, SSO accounts, Cing cetera. And the area of session management was monitoring, recording forensics. I have integrations into provisioning, access governance into lock management, theme tools, realtime security intelligence. And I have sort of newer areas such as application privilege management. So if waiting to have, have blame text credentials in scripts, et cetera, and on the other hand, privileged user behavior analytics and anomaly detection. So understanding when the behavior of people is changing, the evolution of privilege management, so to speak is when you look at it on the upper end, on the upper part, all accounts was elevated privileges on the lower part here, the shared accounts, and then look at credential management session access on session, run time.
Then we see that on the right hand side, we see more text I have put in red, which is sort of the, the trending topics, the, the, the emerging topics. So adaptive application, which is more standard identity management topic or session monitoring, recording user behavior analytics, but also the management of the elevation of privileges. So she restrict restricted feature sets and so on. And we have more traditional things like password walls, privilege, things, and on, but also on the, in the upper area, identity provision access governance, which are technologies that help us to get better in privilege management. So when we look at where things are are heading, then it's very clear in privilege. Management is going beyond shared account password management today. It needs to integrate with other areas of identity management and other areas of security. And there are new fields of capabilities which are emerging and we need to use to support the full privileged management life cycle.
So we need to understand what are our risks from privileged access. We need to identify the privileged accounts, which means that only a few shared accounts or a few administrators, but all the accounts, which really impose several risks to our organizations, which also includes system accounts, service accounts, individual accounts with slightly limited privileges and so on. We need to protect. So we need to protect access to shared accounts and all that stuff we need to monitor. So what's happening. And in some cases we need to monitor is around and we need to detect what is going wrong. There various ways like using scene tools and other stuff, we need them or access governance applied. So where are shared accounts, which don't have a manager anymore anymore, we need to respond. So that's always the same respond. If something goes wrong, take your action and improve your entire system and privilege.
We can apply that cycle to a lot of areas, not only to privilege management, because it's about managing access, but particularly for privilege access. It's very important to say, okay, we don't stop at shared account password management and the one time password for shared accounts, but we go beyond that to a far higher level of privilege management. And we also need to be clear about this is my final slide for today. And then I'll hand over to track need to be clear about we will never be perfect. So we also need to understand what can we do? And I just bring this up because it's something I hear so frequently in discussions that people don't say, okay, we are not perfect. We can't do it that way. Don't try to get perfect. Try to do as much as you can for a reasonable cost because there's no perfect security ever.
And the limit of security moving toward perfection towards 100%, the limit of cost is infinite. So what you need to understand is what is the cost of risk mitigation and the lower the risk? So this is sort of the, the, the other side of the, the picture, if risk goes towards 0%, the cost exponential, and we need to understand what is the cost of incident and what is the cost of risk mitigation with that we can then decide on which technologies help help us best to mitigate risks and privilege management is something which can help us very much in risk mitigation at an overall reasonable cost. So it's something which clearly is meaningful to look at as one of the key technologies in your information security strategy. So was that a hand over to Jack Jackson, make him the moderator?
Awesome. Well, I, I learned something new every time I get on a call like this. So thank you very much for that Martin. I also, it also brought back memories of why I was never a math major. So I appreciate that too good day, everybody. My name is Jackson Shaw. I now work for a new company called one identity, and it's not really a new company, but I'll take a couple of seconds to talk about it just so that you guys understand originally a number of years ago, actually I think about four years ago now, the company I worked for quest software was acquired by Dell and we operated as Dell for quite some time. And Dell recently decided to make a number of changes in their, in their portfolio of products, including the acquisition of EMC, which was a, I can't remember how much, but I, 60 billion acquisition.
And as part of that, we were spun out. Basically we went back to being quest again, and I work for one identity, which is one of the business units within the new quest software or the reemerge quest software. My email address is on there. jackson.quest.com. This all happened November 1st. We don't have our own email addresses yet, but in the, in the winter, the new year, it will become jackson.one identity.com. So we'll be kind of completely transitioned at that point in time, but be it as it may, you know, we have a great history in identity management. I've been with quest since 2005 and working with a number of colleagues, all of whom I would say, you know, 95% of them who are still colleagues at quest building out our, our portfolio. And today, obviously we're gonna talk about privilege management and it's my pleasure to be here with Martin and with you guys, the, my email address is, is on you see on the slide.
I don't know if it'll be the ones that are distributed. I just put it on a few minutes ago. You're welcome to shoot me an email. I'm always happy to hear from customers about their challenges. And we'll get started with talking about privileged accounts. And, and I think, you know, O obviously Martin has some great insights. He probably talks to more customers than I do. He talked about how, in many cases, the action of a hacker with a non-privileged account, once they get into a system is to find a privileged account. And this is something that we just see every day. I mean, I tweeted last week, I think it was on Wednesday or Thursday, GrubHub sent me an email and told me that my password was reset. And they were doing this out of an abundance of caution because someone had gotten to their systems, well, you don't get my password in any system, unless you're a privileged user.
It's not, you know, I'm hoping that most people store them in a way that they're not accessible by a non-privileged user, but it, it is incredibly important that privileged accounts are protected. As I say here, you know, the misuse of privileged account of, of credentials, privileged credentials is, is behind about, you know, 80% of these various data breaches, the, the target break in cost over 162 million. If any of you followed the target break in, I did because it was very, very, an interesting one. The CEO lost his job as did the CIO as did the CIO O it was really an amazing situation to, to, to put it sort of in a, a colloquial way. The fire alarms were ringing all over that operation center at target. And everyone kept push pushing the silence button on the, on the fire alarms until basically the flames, you know, went through the door door.
It was a very unfortunate situation, but it was a great illustration of how someone used a non-privileged account to get onto a system, and then basically run, run AOK until they found the right privileged account, which led them to more privileged accounts. And then, and then basically, you know, cost this amount of, of, of damage and destruction at target. There are, there's a lot of internal use of privilege credentials. I mean, I, you know, the best story I have is the one from a number of years ago, you can certainly look it up just as easily as you can look up the target. One of the network administrator at the city of San Francisco, who basically held the city hostage when he got fired, he was the only one who knew the credentials for all their networking infrastructure. And he basically locked everybody out and said, if you give me a quarter million dollars, I will give you the credentials.
I mean, he called up the mayor and said that. So of course, I'm not sure if he's outta jail yet, but that's just another good example. And, and as I say here, you know, folks deleting things, you know, so the eternal abuse is something that I think companies, you know, have to have to be really seriously concerned about. And the old days and quotes, when I first started as a network administrator in the late nine, late eighties, there was a level of trust of your network, administrators of your it staff. You hired somebody. And there was a level of trust that was just based given to that person.
Nowadays companies are getting much more involved in things like employee background checks. And to be honest, a lot of companies now are, are just taking a military approach that, you know, need to know and, and doing a lot of background checks on folks and, you know, basically not giving that same level of trust. So all of these things are important factors with respect to privileged accounts. You, you should never underestimate how key these accounts are to a security breach. And to be honest, a lot of these happen a lot of access to privileged accounts happen because the unprivileged accounts aren't adequately locked down. So, you know, security starts with those, those accounts, putting a really good security infrastructure around your privileged accounts is, is equally if not even more important.
So we do, we do a fair amount around privileged accounts. We've been, as I said, we've been doing this for quite some time. I started in 2005 with quest. We, I, I came to quest as an, an acquisition that they made of, of a company that basically did a lot of work in the Unix and Linux area, which is, is, you know, reason why we've got such great coverage of, and, and expertise in, in Unix and Linux. But at the top of this slide, as we say, we have a privilege safe. That's, that's our main, our, our main claim to fame for doing things like request and approval workflows around privileged accounts. You know, Jackson wants to check out the SAP password, and if my boss would have to approve checking it out, or there has to be some kind of workflow associated with checking up passwords, if you want, it's a, it's an important aspect of, of that automating password changes.
So I don't even know what the password is. I get the password, or I get logged into a system. And after I've logged in having that password changed, and of course, a full audit trail session management, which is, which is awesome. We're seeing, I mean, almost every customer wants session management. And what do I mean by session management? That's actually the equivalent of recording the session that the administrator is, is doing all the things that they're doing, the commands that they're issuing, you know, allowing you to do things like searching and see what commands are issued. If you wanna find out who did what or what Jackson did when he was on the SAP system, you can just go through that and look at it. You can see everything around the request and approval workflows and et cetera. The other, another product that we have is we have our active directory bridge technology.
This is basically single sign on using curb with active directory. So all your Linux and munix and Java systems, the authentications on those can be tied back to active directory, lots and lots and lots and lots of customers using this, mainly because it enables all those privileged accounts and all the non-privileged accounts on Unix, Lin, or Java to be secured through active directory. And most companies are really good at having a 80 help desk and password policies around active directory. So it's, this is a very popular product of ours. As I mentioned, we, we, we come from a Unix and Linux background. We've done a lot of work around sudo, which is a way of issuing privileged commands on Munich's Linux. If any of you are not familiar with it, we have the way, a way of doing centralized administration and management and keystroke logging of everything related to PSDO.
We just plug right into PSDO. So you get all the benefits on top of sudo. You don't have to, you don't have to do anything or learn anything new. And of course, we can also replace sudo with our own agent based software that runs on Linux system that's even provides a stronger security. It depends on the level of security you want. And the other thing we do across our whole product line is we've done a lot of integration with two-factor authentication. So things like having approvals or, or checking out a password requiring, you know, a multifactor authentication of some nature is part and parcel of, of our capabilities. And as we say, here, we have hardware tokens and software tokens, and, you know, tokens for your iPhone, et cetera. So we have, we have real nice integration again, to, to provide that extra level of protection for you around your privileged accounts.
We spend a lot of time with my team, or I spend a lot of time with my team. My team spends a lot of time building our products so that they are integrated together. We have a whole line of identity management products, all of these products that we build, we build them with restful APIs and we provide significant amount of integration capabilities between the various different things that includes here. For example, around privilege management, where all these things basically snap together, you don't have to use our two-factor authentication. For example, if you don't want to, you don't have to use our a bridge. You don't have to use our session management, all of these things, you can have separate and, and purchase separately, and then just add onto them as you want. We've got lots customers that have the ad bridge, for example, and then purchase privilege management or the other way around, or add two factor. You know, we have tons of customers right now that that are, that are buying two factor. Again, I think this is because a lot of the breaches, you know, have occurred with someone just knowing a password and customers really want to enhance the security of folks that are logging into their network using two-factor authentication. So it's becoming much more popular. Now
You can easily
Integrate our systems together. You know, one of the, one of the things that, that I talked to customers a lot about, and, and we started on this some time ago was the fact that customers are starting to see that privileged identities are actually just identities with a different set of attributes, a different set of capabilities. And what I mean by that is that a lot of companies are, are, or have embarked on privileged, have embarked on identity management products or identity and access governance projects. Sorry. And what they've started to ask, and we've seen this over the last few years, and it's becoming more, more interesting question is, you know, we, we, we provision accounts. We de provision accounts, we suspend accounts, we change attributes of an account. Well, how do we do the same thing for our privileged accounts? We are reporting on all these different accounts.
We are assigning policies and roles inside of our identity management system for our general user. What about the privileged aspect of these different people and these different accounts that they might have? And, and as I, as I'm pointing out here, the typical identity management system does not provide the full picture across the privilege system. So you don't have, for example, separation of duties that cross the boundary to the privileged account management systems, you don't have risk assessment that crosses the boundary to, from the, from the privilege systems to the identity and access management or the risk system. And, you know, Martin had that great point about risk surface. Well, it it's, it's obvious to me that if in this particular case, Sam has privileged access, that Sam's risk is much higher than Sam who only has general access. So how do we basically surface that and integrate that?
So we can, we can ensure that we understand the actual risk of Sam. And that's one of the things we've spent a conservable amount of time on doing and integrating fortunately with, you know, rest APIs. It's, it's, it, it was a lot easier for us to do this, but basically what we've done is we've extended access governance to our privileged users. So through, you know, our APIs and our, and our modular module approach, we're able to privilege, sorry, provision deprovisioned accounts. We're able to see that Sam in the last slide that, that I showed has both a regular account and a privileged account. And therefore the risk associated with Sam is much higher. And that in turn means that the risk surface as Martin was discussing is more complex around that particular person. So for us tying these two things together has been, you know, an important task because we, we truly do believe that a company needs to have a clear view of their risk across all users. And that includes privileged users. There's no, we don't want to, we, we really don't want to treat a privileged account in any different way than, than normal unprivileged user account in a company.
So some of the additional solutions around are additional considerations around Pam solutions, I think is really important. I've just talked to you about how important having open APIs is. I mean, it's extremely important. In fact, in that last diagram, we have an open set of APIs that allow our product to tie into our identity management system. One identity manager, those APIs are open, and we have customers who tie in other privileged account management systems to one identity manager. So, you know, I believe that the use of those APIs and having open APIs in your, in your privileged account management system and in your identity management system is extremely important for exactly that reason. At the end of the day, I know that I can't sell my solution to every single customer in the world. There are gonna be customers that have different solutions, and we want them to be able to integrate just as easily with our identity management system, as, as possible to, to give that benefit to a customer.
We wanna provide identity as a service and software as a service capabilities. We're, we're doing a lot of work right now around introducing cloud-based privileged account management, both to both manage cloud properties, but also to run in the cloud. I just think that, you know, customers now want to see more hybrid solutions and in the future, you know, I, I think people are starting to understand that, you know, running things in the cloud is not as insecure as they originally thought. In fact, there are more and more people now starting to be begin to think that there's better and more security in running some software in the cloud. We want the investment timeframe, or you should want the investment timeframe for your, your solution to be as low as possible, as small as possible. And what do I mean by that? I mean that you should be able to show value and get value out of the investment you make in your Pam solution.
Extremely fast. One of the, one of the key benefits that we provide to our customers is a hardened sec hardened appliance, and that hardened appliance can basically be up and running within 15 minutes. And it is totally common for us to have customers checking in and checking out and migrating privileged accounts and their, their systems into the appliance on being up and running literally in hours, if not dates, no expensive consulting. It's it's, I think, you know, just an awesome solution. You can just turn it on and, and get to work right away, you know, buy it, have it chip, turn it on. And you're good to go from a frictionless security perspective we're doing again, I mentioned a two factor authentication. A lot of our customers have been asking for easier security, but, and easier capabilities to do approvals. We've done a lot of work and have integrated what we call push to authenticate for anywhere approval with this product.
And that's just basically an application that runs on your mobile phone and a manager can approve a workflow, right from their mobile phone, just by clicking a yes or no. It's, it's really nice. And that's, it's quite a time saver. And because it works from a mobile phone, it works from anywhere. We have situations where some approvals at, at some customers require a number of managers to approve it. And folks travel a lot as, as I am today here in New York city, you know, how can I do an approval if I'm not on my laptop, you know, 7 24, so to speak, and these things will just show up on your phone and you can do an proof rate from there. So we're, we're really spending a lot of time on both the security of this stuff, but also on having, as I said, the open APIs, the capability to connect in any way to our system, using things like Federation Martin talked about contractor access.
That's a great point. We have so many customers that have contractors that come into their, into their systems. We want them to be able to federate to our appliance, to check in or check out a password. It's just a much more secure way in a much easier way than having to create an account for each of these people on all these different systems, the quick time to value short investment timeframe. And of course the frictionless security, all these things extremely important in the open APIs. As I said before, a lot of, a lot of value there.
So why want identity? And I'll just go ahead and build this slide. This is, you know, our overall value statement for all the products that we work on. You know, we've spent a ton of time, as I said before, around things like governance, policy based access control, privileged account lockdown. We've talked a little bit about those things. I feel that the industry and customers are going through a little bit of a shift. You know, when, again, when I first started as a network administrator in it, in my early career, everything was, it based was done because of needs of, of the, of the overall business, but it was done in it fashion. Now we're seeing a lot more interest in customers being able to have the business drive their, their, their it aspects, so to speak. So we spend a lot of time with easy user interfaces, you know, making it, making it a heck of a lot easier for the actual business to, to run it.
We're we we're very future ready. As I said, everything, API, API based. We want people to be able to configure systems, not code systems. I mean, one of my real key things is, is the less services a customer needs to get one of our products ready, the better modular and integrated we, this is, you know, a huge watch word for us, a huge tenant for us that we spend a lot of time on. And again, the API economy and all the work we do around APIs makes that easy. It doesn't only make it easy for us, but it makes it easy for you. We have lots of customers who use these APIs and build specific things into them, just makes really easy for, for them to plug into our products and rapid time to value across all our products. We it's a, it's probably the, the number one thing I want to do. I've been in the identity management business for many years and having the ability to go to your management, go to your leadership folks and have them see that you just spent X dollars and within, you know, weeks you've got that value that you can show them extremely important to you. And also extremely important to us.
So just a, a couple of final wrap up points. You know, we, we invented the 80 bridge technology for Unix and Linux over 12 years ago. In fact, I knew the folks at vent, which quest acquired, you know, back to my days as the product manager for active directory. When I worked at Microsoft, a lot of experience around that. And of course I loved the fact that that vent did all this great work and quest has done all this great work, integrating Unix and, and Linux into active directory and, and making them just basic citizens of active directory. It's, it's awesome. A lot of top customers using our product I'm here in New York city and of course, touring around with a lot of our banking customers. We, we have a lot of customers worldwide. I always in London going back to London, a lot of, lot of the big banks in, in Europe use us.
We have the only privileged account management system in a self-contained hardened appliance, a lot of great benefit to having a hardened appliance. Then, then, then software that you also have to worry about protecting if you ran it yourself on a server, we have over 2,500 customers of our privileged management products. And we have over 8,000 customers who use our identity and access management products. And well over half the fortune, a hundred using our privilege management solutions. I, I don't know what the number is for our, for our identity management solutions, but it would be bigger than that. And I, I think one of the key things for us is being able to, to provide service and support to our customers worldwide 76 customers, 76 countries. Right now we have follow the sun support in various different geographies around the world with support centers in the, the UK and India.
And in Halifax in Canada, you know, our products are well distributed, multilingual teams. We spend a lot of time on that. And I think, I think we provide pretty good service to our customers too. So all these important things for you guys to be considering when you're looking at a, an identity management or a privileged account management solution. And with that, I think we may have some Q and a Martin. I don't know if you wanted to take back control at this point in time, but I wanted to thank you Martin, and thank everybody for, for their, their paying attention to me at this time of the day and, and attending.
Yeah. Thank you, Jackson, for your presentation. And as you can see, I take back control. So in our agenda for today, we had its first part. And right now it's time for Q and a, and I'm happy to receive questions from your end. So I have some questions already here and, and maybe the first one is one to choose directly for you, Jackson, which is what is the hardest part of Pam?
I think, well, I think the hardest part of Pam is the inventory. It's almost like the hardest part of identity management. It's the inventory of all the systems that you have or applications, because you may have a server that's running Oracle and in, or that Oracle database that's running on that server might have, you know, 10 different applications, all of which have identities that may need to be protected. So in my mind, it's the inventory and, and, and pulling together that level of detail that is tough for every customer. And it's tough, no matter what.
Okay. I think it's, it's a good time because also when you look at POCs and our stuff, and also looking at the technical details, all the account identification stuff, the grouping of that, and so on clearly is always one of the, the larger challenges we see. And so, so from your experience, where do most people start a Pam project?
Most people start a Pam project. I, I, I mean, you know, obviously inventory is an important aspect of it, but if we think of a customer taking an inventory and even while they're building an inventory, most customers know right off the top of their head, that they wanna protect their ad accounts, their active directory accounts. So their domain administrators, their scheme, administrators, all the folks that have privileges on active directory. And that's usually followed pretty quickly with their, with their key applications. They're key applications that, that provide, or that have the potential for having a huge risk surface. As you mentioned, like Oracle, like SAP. And then of course the servers that run those huge applications. So whether they're unit systems or the windows systems and protecting those. And then I think, you know, what I typically see as a customer wants to get those, those ones real quick. And once they do that, they, they, they continue down the inventory path, looking for all those different systems and adding them over time. I say to every customer, this is a journey. It's not a destination. You won't be done by X date. You'll probably be mostly done, but new systems are being added. And you're, you're always expanding your, your, your, the usage of your system to reduce that risk surface that you talked about Martin.
Okay. Another question I have here is, so what about a service accounts? How do do come into plan? I think I might, I might add another part from my end, when we look at the service accounts, how do you, you know, the challenges they are frequently not used interactively. So, so if you set a certain password, how does this really work? I think technically you see, not that the easy, the challenge.
Yeah. It's, it's, it's not, and you're right. It's not technically as easy. We've done a number of things, both around service accounts and, and non interactive accounts to make that a lot easier. We have, we include in the product, we don't charge anything extra for, but we do have a capability for example, to provide application, check in and check out very much the same as a, as a service account. So that when an app, for example, needs to log on as somebody that we can do that easily and, and manage service accounts very much in the same way. It's a little bit more challenging. I totally agree. But it, it is something that folks do have to look at.
Okay. Another point is, or another question we have here is maybe you can talk a little bit more about quest versus one identity also from a portfolio perspective. So from what I see, one identity more was a very small set of larger product to speak compared to the traditional transitional quest.
Right? So when we were at quest before Dell acquired us, you know, obviously quest had a broad, broad portfolio of different tools. They were well known and still are well known for toad, for example, which is all around Oracle development, developing the, the, the code and, and working with Oracle databases, still a hugely popular product, but at both at Dell. And then now, as we've been, we've been split out on November 1st, we've been formed into four different business units. One of the business units is, is us the one identity business unit. And we have in quotes, I'll call ownership for lack of a better term at the moment, but ownership of all the identity management products that we had originally and, and, and continue to build and, and work on. There's another group, which if you're familiar with us, you're probably pretty familiar with them called platform management.
And the platform management team is the group that owns all of our traditional migration tools for migrating, from, for example, outlook, Microsoft outlook, or Microsoft exchange to office 365 and from GroupWise to active directory, et cetera. And then we've got a couple of other business units, one around databases, and one round information management, you know, but traditionally the, the most of the quest tools ended up either in the platform management group or ended up in one identity. And like I said, we, we have all the one identity or all the identity management products in our portfolio.
Okay. And the last question I have so far is how do you see the, the, the, the, the value of, of P management for, for other environments, such as I think operational technology security is an interesting one where we see a lot of systems that still rely on shared accounts, or maybe also step ops where you have a lot of people. So we might change a little bit your, your traditional development test production processes. Right. So any ideas on that?
Yeah, I mean, it, it's, that's a really, really great question. I mean, we're, we're launching, we just launched a, a cloud-based product a few weeks ago. We've got more that are being launched. In fact, I'm here previewing some of those things this week, while I'm here in New York city to some of our customers. And I'm seeing that the use of privileged account management product in a DevOps environment is, is extremely important. You know, when we looked at it ourselves, we're like, well, we've given out user ID and passwords to our cloud, our cloud properties, which in our particular case are all based on Azure to our DevOps team. And we need to protect those just as if they were an important asset inside the company. So I do agree for DevOps. It's extremely important, you know, just to, just to give you guys a, you know, a little, a little bit more on some of the things I'm seeing, I have started hearing from customers, and it's, it's more than a handful now of customers who are at the point where they actually want do session recording.
And this is gonna sound a little crazy. They wanna do session recording of all their employees. I mean, there are obviously privacy issues with that in, in, in certain countries and certain geographies, but we're hearing more and more of that, where for forensic reasons, they want to be able to do session recording of everything that an employee does. I, I think it's a little over the top, but, you know, that's, that's me and, and the customers are actually starting to talk more and more about this. So I, I see usage of privilege, account management products, expanding into what, what you would call or what I will call non-traditional areas. And, and I think that's just gonna grow over time.
Yeah. I had this scenario with, for instance, in call center environments where a lot of stuff might be recorded. And I think it's the challenge is if you do something like that, it's about how can you identify the fraudulent activities. Yes, exactly. So recording doesn't fully solve your problem. You need more than the recording done, but in general, I see also a clear trend to use more privilege beyond the traditional area of privilege with that. I thank you, Jackson, for your presentation and for answering all these questions. Thank you to all the attendees attendees of this webinar for listening to this could be on cold webinar. We have another two, I think, upcoming before Christmas and understand the new year. So thank you very much and hope you attend one of our upcoming conferences or the next webinar. Thank you.
Thanks a lot.