Oh, there we go. Beautiful. So the, the Genesis behind this particular presentation began about a year ago. And one of the things that we wanted to do is we wanted to talk a little bit about what some of the customers are that we're running into, what some of their problems were, what some of the levels of capabilities were that they were achieving. In other words, we wanted to take a look at where they were starting from and where best practices were. Now. One of the things we're gonna do today is show you something new that is we're gonna be talking about a new version of our product. That's actually coming out. Now that's based on almost a year of work that we've been doing with one of our major accounts. So let me go ahead and get started with the presentation. Now, many of you're probably already familiar with privileged accounts, but if you're not familiar with them, let me go ahead and tell you a little bit about them.
These are usually the super user accounts, the route, the admin, the SA accounts they're used all over in your enterprise. They're used in the middleware layer they're used in the database they're used in hardware devices effectively. They're all over the place within your environment. Now, a couple of the common problems that a lot of people have with these is that there's a lack of attribution that is who's using them for what reason? For how long. And can you actually put a name to a specific person who's using that identity, but this afternoon, I want to talk a little bit about some additional elements to this. So here's some questions to ask yourself about your understanding of privileged IDs and the way that you're using them. First is the question about privileged ID, just being about accounts. A lot of people say, well, it's rude or it's administrator, or it's a domain admin depending on your platform.
But the big question is, is it always a password or could it be something else? For example, could it be a certificate that represents your identity? And are they always about usernames? For example, in Cisco, you have an enable account, which doesn't actually have a name or in a lights out device. You have an ID number rather than a specific user, but nonetheless, they do perform a specific function. Another question about your environment is that the issue as to whether these accounts are managed well or go completely unmanaged, and that's where we're gonna look at this maturity model. The other question is, do people really need access to these? One of the things that's been quite nice is that in the evolution of operating systems, let's say in the case of Microsoft going from XP to windows seven to windows eight, the issue is they have required less and less scenarios where you actually have to be full administrator in order to perform activities.
This has been an improvement in the operating system inherently to require less privilege in order to do ordinary things. But some of the questions are about how people get access to their systems. In other words, how do they manage to gather the administrative access? What is it that gave them administrative access? Is it that way from the point that the machine was initially generated, or is it something that they have to request where you actually have a tracking on what they're using these IDs for and how they're being used? The other question is, do you really need to always provide the credentials themselves? Do you need to know what the password is for an administrator account in order to do an administrative type of thing? So we'll talk a little bit about that, but these are some questions to say, what are the alternatives to just simply credential disclosure? And we'll look at a few of them.
So what we put together is this thing called the pin maturity model. The pin maturity model goes from zero, which is a fail. And we'll talk about what fail case is. And then we go all the way to best and best describes best practices. This is being on continuous compliance. This is about being able to get exemplary results from your auditors, and essentially where security comes for free and compliance comes for free because your processes are mature and you have a very good understanding about how things are done. So let's go ahead and break these down one at a time and talk about the fail case. Now, the fail case, and this is coming from experience in the field is that you don't really know what you have on your network. You don't know what machines you have. You don't know what accounts are in those machines.
Privileged accounts are never changed, and you really have no understanding of what's there. In fact, you probably even have factory default passwords in an actual production environment, which of course is not a great thing. You'll see things like blank passwords being used throughout the environment. You'll also see sticky notes. Everybody knows what the credential is to get into every machine. So this represents the worst of the worst. And in fact, in many cases, you may not even know what machines you even have in your network. I mean, is that a crazy thing, but think about it for a moment. If you have an environment with B Y O D and everybody's bringing their own devices, do you really always know what's in your environment and what's connecting to your network? One of the characteristics of this is that in many cases, the so-called secret password is known by everybody.
The, if you are using any kind of password spreadsheet, everybody knows where it's located. It's usually on a shared basically it's on a network share that everybody can get to. So in essence, this is the case where there's essentially no control whatsoever. So the next level up from this, oh, by the way, we're not only talking about the mismanagement of passwords, but we're also talking about the mismanagement of PKI. So let's talk a little bit about what we mean by this. Now, when we're looking at this particular model that you see up here, you're probably saying yourself, this must be a small company that has this scenario. This is the situation where you're using PKI. You have certificates they're being used for authentication and authorization, but in fact, you may find them sitting out on a share with the passwords, with those particular PKI certificates out there. So anybody in the enterprise or anybody who can get to those can actually pick up your certificates. So let's move up a little, a little bit. So in fair, what we're talking about is actually knowing what machines we have. We may not understand everything about the machines, but in this particular case, the it staff are the people who have access to the machines. It's not everybody. You actually have segmented access to it. Administrators, and some of the credentials are changed regularly, but most are not.
The other thing is that in this particular scenario, you may have the same password being used in a lot of different places at the same time, but it can get to anything they want, but without attribution. And that's the key element of this particular point of being where we are in fair. Now, this is the interesting element of this. And that is that in some cases you will pass your audit in this situation. Now this is kind of a, a scary thing, actually having a really poor security model and actually being able to pass. And this is because there's an interesting element of auditors and it, that is auditors. Get what it gives them. If it doesn't give them the fail cases, then they're going to pass aren't they? So in essence, controlling the flow of information from it to the auditors can in fact, give you a bad situation, which actually looks good.
Moving on to the good model. In this case, we actually know what machines we have. We control what's on there. We actually scrub out bad machine lists or bad machine entries. We do know on, we do understand local credentials. We're changing them, randomizing them on a regular basis. There actually is a check in and a checkout process so that the right person has access at the right time. And we actually understand who that is. And in fact, access to machines may not be done by credential disclosure. It may be done by remote desktop or by SSH proxy.
In this particular model, we call it good for the following reason. And that is that each user who needs to have privileged access has to have a reason. It's not a matter of anybody doing whatever they want at any time. They actually have a reason. They have a trouble ticket. There's a workflow. There's an attribution of understanding who has access to what, when, and in fact, the credential knowledge is destroyed. Meaning that after somebody has access to something, the credential will be changed after that work is done. So there actually is a closed loop in this entire process and things like spreadsheets are destroyed. They're actually turned into individual secrets that are parceled out appropriately. The secrets themselves are secured in some kind of an encrypted storage system. The number of people who are domain admins is limited. And in fact, every time somebody has access to something, there's some sort of an audit that's generated so best is we take everything that we had in good.
And this is where not only the local accounts are randomized, but also the domain accounts are randomized. So that in fact, even the highest level privileges in the system that is the highest level accounts have to be requested in order to get them. And the only for a limited period of time, the other part about best is that privileged identity management doesn't live by itself. That is having a vault to store. Things is good, but you have to go one step further in that is that you typically will tie it into things like Sims and loggers you'll tie it into an it till workflow. So in fact, you'll have an entire tracking, including integrations with things like multifactor authentication. In fact, some of the work that we're doing is also adding in reputation verification, and looking at behaviors of what people are doing with identities, not just the fact that they have a right to it, but what they're doing and what they're doing over time.
So time represents another element of this. The other part about best is that in this model, and this is a continuous compliance model, the auditors can come at any point that they wish, and they can look at anything that they want in the environment. And in fact, there is no getting ready for the auditor. You're always ready for the auditor and the auditor can come at at any time and test anything that they want. So in fact, there really is no preparation. So this is typical of large dynamic environments where TCO is important, and this is the continuous compliance state, but let's move forward. And let's talk about the way things are today. And some of these things may concern you, they should concern you. And I don't really want to talk about something where I'm trying to create fear, uncertainty, and doubt, but this is a reality that we have today.
And the reality is today that what we had saw as a potential in 1995, with the beginning of the commercial internet, which was the idea of nation states, getting involved in criminal activity and breaking into systems actually is beginning to happen. Now, the issue is today. We now see nation states actually using their zero day attacks and using their inventories for commercial advantage and actually crossing a very bright line. And you'll read about this quite a bit in the media, but here's some of the elements that I want to bring forward to you that you need to be concerned about. And that is that attackers are now using automation. So it's not a matter of a human doing this. These are actually machines attacking machines, looking for weaknesses in your environment. Another element that you should be concerned about is that spear fishing is successful.
Explain what I mean by that. And that is that in a organizations, they now know that their environment is generally owned. They don't know how many machines are owned at any one point in time. It might be one machine, three machines, 10 machines, but they understand that their internal environment is always being owned by somebody at some point in time. And if you're not familiar with the term owned, it means that somebody outside of your organization is controlling your systems. And the goal of security and the goal of the internal operations is to find them and to knock 'em down as quickly as they can. So the idea of spearing or the idea of you receiving an email and something running on your machine at the nation state level is actually very successful. Things like past the hash are elements that we see today, which essentially is if you get into one machine, find an administrative password in hash form, you can actually use that to get into other systems.
This is reality as it exists today. So the issue that we see is that even things like domain administrator accounts, and even if they're being changed regularly may not be enough. So let's talk about some of the assumptions that you really need to consider in today's environment. Number one, assume that your environment is owned. Assume that you do have a compromise and assume that somebody's trying to get access to your systems and do something, whatever something is. So this means, of course you don't need to, you shouldn't have common passwords, but these are some of the elements that we've seen from some of our customers who are currently under significant nation state, cyber attack. They're changing all of their passwords on every machine, every 24 hours.
We have one particular account that's changing every password, every eight hours. I don't wanna describe what they do, but you can almost guess what they do. But the other thing is they're not only changing the accounts every 24 hours, they're actually changing where they're being used, that is in services every 24 hours and that's become the service level agreement. So the assumption also is that their domain accounts are also being compromised and those are being changed on a regular basis, every 24 hours. And you're probably going, well, this is kind of crazy, but this is the world that we live in. And now does everybody need this level security? Probably not, but it's something to consider in terms of the value of the assets that you have. So let me talk a little bit about what we've done. What we've been working on for the last years have been, been working with one of the largest cloud providers on the planet.
And so we've actually implemented something for them. And we're showing this actually up on our booth, up on the main floor and what this is, is the idea of taking privileged identity management and PIM as a general term into something completely different that has never existed before. And that is the idea that we're going to collect all identities, not just the privileged ones and not just the user IDs and the passwords, but also the certificates, putting them all into one place and doing this in an automated way. And then using this automation to change everything on a regular basis. But here's the important part. The entire software that is the entire package is in fact, a platform. In other words, it has a web service interface, or it has a PowerShell interface. And the idea behind this is that when we get into what are called critical national infrastructure, where you might have more than 250 million accounts, or you might have more than 40 million systems, I mean, this is where we are in terms of critical national infrastructure.
You need to have something that is going to be scalable, but something that no longer has a UI, we're actually moving into the era where UIs are going away. You literally have to deal with this as a service or as a component that actually becomes part of your line of business. So in essence, a PIM and IAM end up being merged into one security platform that allows any application or any line of business to actually tie in and manage credentials, not just privilege, but everything including certificates. And so from the scalability point of view, these numbers may seem to be large, but consider this if you're a cable provider or you're an ISP, some of these are very large environments that are being attacked by nation states today. So there has to be some way to protect them. And this is one potential way. So the I'll wrap this up with just a few questions, and that is why does PIM not necessarily a choice of why is privileged identity management have to be managed?
And the answer is breaches, auditor, findings finds threats of a shutdown. These are all reasons in order to implement some kind of a solution, whether it's a commercial solution or an internal solution, but what inhibits, this is generally culture. Sometimes it's technology silos politics. But the important point is that this is one thing that I would like to just throw out there for a moment. And that is that security is not a cost center security. Isn't a profit center. Security is dial tone. You pay what you have to pay in order to keep your environment secure and available. So to try to save money on this is really a, a fools errand. The other part is that the cost of security is not a matter for the it department. The cost of security is a matter of the sea level executives and the management of the organization.
They're the ones who are gonna have to pay the bill. They're the ones who are gonna have to suffer the consequence. And so the right now there's quite a disconnect between what it does in terms of being compensated for uptime versus security, which can in fact, cause a downtime in order to achieve compliance. So there are some interesting elements that do need to be fixed in terms of the way our environment works today. So the question about how much it costs, well, how much does it cost not to have it, whatever it is, but here's the interesting thing. If you've worked in security a while and you've managed to get to the Nirvana known as continuous compliance and where security comes for free, because it's part of the process. What you find is that criminals hate you because your environment is difficult to break into auditors.
Love you, because they can come in anytime they want and check to see how things are working for you. It staff loves you. Believe it or not. Continuous compliance is actually eventually loved by it. Administrators. Why? Because they don't have to do any paperwork. They never have to prepare for the auditor. They're always prepared. They're always ready to go. So there's no more getting ready. And so it's also a matter of also trying to get better at what it is that you're doing. And continuous compliance is about every day, waking up, expecting to be compromised, finding ways to get these guys out of your system, and then always improving the general security of your environment. As far as our company we've been around since 1978 were a us based company, privately held non VC. And we're known for our auto discovery technology as well as our low TCO. And we partner with pretty much everybody upstairs and everybody that an enterprise works with and we have about 1200 customers. Now, given the format, we won't do the questions, but I want to thank everybody for attending and hopefully provided some useful information for you. Thank you.
Yeah. Thank, thank you. Thank you very, very much, Phil. I think the, the really interesting thing is that with this nation state type of attacks on criminal and critical infrastructures, it enables us to become understood by a lot of people. So when I talked about identity some years ago, no one understood me, but I can really scare the non-IT people. When I start talking about this topic, which is a think a great broker. It's not a good thing overall, but this is really something which is understood, which we need to solve. So thank you for your presentation. Thank you for your insights with direct we'll move to the next
Presentation. Thanks Martin Martin.
