The Common Credentials Dilemma - How to Get a Grip on Password Sprawl for Privileged Accounts

Good afternoon, ladies and gentlemen, welcome to our KuppingerCole webinar. The common credentials, dilemma, how to get a grip on password sprawl for privileged accounts. The speakers today are me Martin Kuppinger found on principle Analyst at KuppingerCole and Phil Liman, president and CEO of Lima software. This webinar is supported by Liman software. Before we start some quick housekeeping, some quick channel information, housekeeping information, and then I will dive directly into the content.

So keeping calls, Analyst Analyst company, we are providing enterprise research device services to support networking for it professionals through our research services, our advisory services and our events, and our main event here is the repeat identity and cloud conference, which will be held next time in next week. So next week May 14th to 17th. There will be European identity and cloud conference in MUN. All information is available online. So just have a look at our website and you definitely should not miss this conference.

It'll be the conference on these topics in Europe to see regarding the webinars and guidelines, you are muted centrally, so you don't have to mute or unmute yourself. You control these features. We will record the webinar. So the podcast recording will be available latest by tomorrow. The questions and answer session will be at the end. So you can enter questions anytime using the questions feature in the go to webinar control panel, which you'll find, find usually the right side of your screen. There's an area questions, and you can just enter questions once they come to your mind.

I always recommend doing that so that we have a good list of questions. Once the two presentations of this webinar are done. So let's have a look at the agenda, the agenda for today, as usual split into three parts. And the first part, I will talk about the scope of privilege management and some background things. And I will especially focus on golden rules for privilege management. And the second part then for Lieberman will talk about how to address common credentials, dilemma, and practice.

He will dive deeper into what he sees as the common credentials, dilemma, etcetera, for all the various types of accounts. So those will be a really in terms of information around this issue and how to deal with it. And finally, we'll have to Q and a session where we'll pick your questions and try to answer them. So when looking at overall, the sources of risk, the sources of in fact information risk we are facing, but there are a lot of different reasons and sources for that risk.

So there malicious activities such as coordinated attacks, hacking data theft, denial of access like mail, etcetera. So there are a variety of things which are just malicious. There's the misuse such as app use of privilege to someone who has produce is doing things he should not do. Curiosity corner cutting delib leakage. So things like that. And we have the mistakes such as accidental, lost, accidentally razor accidental disclosure. And when we look at the middle, there appears the term privilege.

And this term privilege, I think is an very important term in that area because this term of privilege really is tightly related to the level of risk we are facing. So the higher, the, the moral elevated the privileges of someone are the bigger, the risk. I think that's, that's really one of the, these, these important things to understand. So privileges are related to risks, more privileges, higher risk. That means we, we have to deal in inappropriate way with privileges. And one of the things around this is that credentials of privileges, unfortunately, are commonly shared.

It's sort of the higher, the risk, the more sharing of credentials, because that's the area where we'll find a shared account, something Phil will talk more about, but that's just the sort of the introduction. And we have a group of tools. The privilege management tools are, I sometimes use the abbreviation P XM for, for privileged account management or access management, identity management, or privileged user management. So these tools have several types of features. So very common features we, we frequently see, but not all necessary all in all in all of these tools.

So some are a central store for credentials. Then we have the onetime password for credentials of shared accounts. So using one time passwords, instead of reusing the same password all the time, automatic change of credentials without interactive log on. So all these system accounts, service accounts, etcetera, we have the single sign on to privilege accounts. So if you have several of them reusing them, then we have monitoring features, functional restrictions in some cases.

And we have sometimes also the opportunity to replace scripts credentials, which are for instance, store the script scripts and configuration files. So that's what we see here as sort of set of the features. And that group of products clearly helps us in managing these risks and in dealing with privileged account. And as you can see, the left side, dealing with the credentials is the one with the most have as longest list of features. And that's, I think for a good reason, because managing the credentials, dealing correctly with the credentials was the starting point for all these things.

And that's where Phil would, will put his emphasis on, in his presentation. Where does this apply then? So if you look at privilege management, a common notion of privilege management is, and if you look at privilege management tools, then many just look at shared managing shared accounts. So we have sort of one dimension, which is personal account or shared account. That's sort of a binary dimension, either account is personal or it's shared.

On the other hand, we have a dimension which frequently is covered by access governance, who starting with standard accounts going to elevated accounts. And if you look at different types of accounts, a standard user account, usually it's personal with, with relative few privileges. So it's not an elevated account.

However, they are personalized accounts such as windows operator accounts, which have elevated privileges. There are others like SAP business warehouse powers, which have highly elevated for business perspective accounts. On the other hand, we have these shared accounts. So some technical accounts might have not that elevated privileges. They still might have rise or low privileges, whereas others such as rude or the build an administrator account of windows, domain controller are highly elevated and shared. And clearly this is the area of the highest.

Whereas, however, as you can see, this is a, a broad range of different accounts and we have to cover all of them. But when we look at the common credentials criteria, then we clearly look more at the right side of this metrics where the shared accounts are because that's where the common credentials by sharing accounts really become a problem. And I think it's also interesting to see that this is not only about let's say the root or whatever. So we have different ways of where, how privileged access can happen.

So, so one is we have a user who has an account and this account has some entitlement uses a system and the system then uses another account, which then is a technical or functional account with some entitlements and system. So that while they, the first account, the one on the left hand side is personal and personal account and not necessarily privileged. The technical account on the left hand side clearly is an account was elevated privileges, privileged account shared and frequently. Also with credentials, you could find somewhere fairly easy.

Then we have the situation of classical shared accounts, or we have different people who can use one account, unfortunately frequently accounts with highly elevated privileges to access information. There might be also individual accounts with elevated privileges. The good thing with these accounts is that they usually are not shared. So we don't see the common credentials dilemma here, but for the first two types, we have to deal with the common credentials dilemma, especially with the, the one in the middle where we really have to share accounts with interactive login.

And this is sort of the, the most critical thing we are seeing there. So to deal with these situations, with these issues we need on one hand guidelines organization, etcetera. That's what I will cover a little with my golden rules over the next two slides, and we need technology and that's what Phil will cover in his presentation. So when we look at these golden rules, then there are, I think they're, they're, it makes sense to split them into two parts.

One is the part of what are, I would say, overall project golden rules, at least for the area of IM I, so identity, access management, identity, access governance here. I think it's good to understand what are things which really help you to succeed in projects.

One is, do not. Overengineer the solution. So you need technology, but you need to keep it simple. That's always important. So things which are too sophisticated frequently are not the best approaches. It has to be fairly simple. And they're sort of a, I think you can always apply sort of an eight 20 rule. So for the, the last mile of so sophistication, you will need far more time for you will spend far more money than for the, the first part. What you definitely should do is you should agree and understand your end goal and then define small steps to reach it. So what is privilege management?

What does it mean for you and which elements does it have, et cetera. And how does it integrate with other areas of your I IM IH infrastructure and how does it integrate with the overall information, security environment, cetera, understand the business and it requirements. And I think the business requirement is one area where we see compliance and other things.

If you, if you look at privilege management and I hear requirements, I think that's an pretty interesting area because one of the things you might observe in the project is that very quickly, some of the people who are affected by the new tool you want to implement say, oh, I can't work anymore. If I have to order a new password, anytime I access the system reality is that they quickly will say, okay, it works better than I have ever have expected, but this reluctance is a very common thing.

So you need to understand requirements and to build your system according to debt, but also you need to convince people that there's a need for it. And that you really do your best to find the balance between these requirements on one hand, for becoming more secure and the other requirement, which is doing the daily work, understand the required level of granularity and control. So how granular do you need to become?

It's also, I think always about finding the balance between granularity and efficiency, security versus visibility. I think that aligns with what I've said before, understand what you really need to mitigate, where do you really need to mitigate risks? What are your high risk environment, having an understanding of where are the biggest risk definitely helps in doing a better job on these things. And for sure understand your systems and infrastructure integrated cetera.

And then I have a set of privilege management, golden rules, the rules, which should help you when you're designing a privilege management system and designing a guideline for that. And also the, the implementation, which really should help you to, to build a good system. So clearly all critical systems must be onboarded.

And you, that means also you need to understand which systems are critical. You need to identify your privileged account. So you need also to have an understanding of what are privileged accounts and privileged tasks that must not use the standard account for daily use. So that's one of the things where I think in many organizations, a lot of people have, for instance, local administrative administrator writes for their normal, for their regular account. That's just one very common example, which means if someone attacks them, he has full control over the system. This needs to be segregated.

Passwords of privileged accounts are stored encrypted. In fact, all passwords always should be stored encrypted. They should be regularly changed. Ideally also for accounts without interactive login avoiding the use of shared accounts is a great idea. It's not that easy sometimes, but in many cases you just can avoid a lot of them also avoiding functional accounts. Something I have list later again, direct the use of shared accounts in the context of a specific person. So you at least need to know who has used that shared account when and what did he do? Limited capabilities.

So not everyone needs full administrative rights. So move from administrator accounts to operator accounts, no permanent assignment of shared accounts with knowledge of passwords to multiple persons. So the password has to change. If more than one person can do an interactive login, the account passwords must be kept in sort of a world. In first one time passwords. It's a consequence of this, a first strong loss indication for using interactive shared account.

So have some strong loss indication somewhere in before for the persons who can request a password use of shared accounts require some approval. That might be a pre-approval. It might be a talk approval that something you need to design, you have to design your processes for various situations, because for a firefighter access, you need some very quick solutions for the daily use. You should have something which more looks at some time of re-approval, which is well designed and why they use a functional accounts by using appropriate security architectures for end-to-end security.

Another very important aspect. So functional accounts are in fact, they are a sign of not perfect security architectures and applications. So if you really think about anti security, you can do a lot of things on end-to-end security, then you do not need a functional account. So the problem is that many applications always are built in a way where people just say, okay, we're using functional account here because we did it every time or a technical account, instead of thinking about how can I implement end-to-end security, security?

And you also should identify critically combinations of entitlements and manage them. So, which are the administrative and operative accounts that are, if you put, if you use them together are even more critical than these privileged accounts are for themselves. So if you have administrative rights on SAP, the database and the server and the VM cetera, then you can cause far more harm than was having ATMI, right rights only on one of these levels. So these are in a nutshell, the privilege management goals rules I have in mind.

And right now I will hand over to Phil for his part of the presentation. Well, good morning, or good afternoon, depending where you are. My name is Phillip Lieberman, I'm president and CEO of Lieberman software corporation. Many of the things that Martin talked about, I, I do agree on the, the nature of this is, is a bit tricky because one of the elements of this is how do you actually get to the end goals that Martin mentioned?

So what I'd like to do in this presentation is review a few of the elements that Martin talked about, but then talk a little bit about how these problems are solved as well as a few of the nuances of achieving the goals. And by the way, Martin is absolutely correct. And that is that in terms of coming up with the solutions and solving this problem over engineering is a common flaw in the way people try to approach this. And that is that the problem is actually much bigger than it appears to be for most people.

And I'll talk a little bit about the scope of this and talk about the low hanging fruit that can be harvested and how security can be achieved with the, in a very short period of time for most of the easy things. And talk a little bit about some of the harder things in terms of getting to a secure position. So first we'll describe the problem a little bit about our solution and then give you a, a short background of the company itself and our history in the area of privileged identity management.

But I'd like to start by just somewhat reviewing what Martin had discussed, but I'd like to step back a moment and really separate really two different fields that strangely enough have been very different, but confused with each other. But one of the things I'll be talking about Martin at the EIC conference in my presentation is in fact how these are beginning to become merged together. So in our world, we see provisioning as really the IAM role. So most people see identity and access management.

What they're typically thinking of is user provisioning, a normal user, joining the organization, changing roles, and then eventually the user leaving the organization. And this involves primarily provisioning and deep provisioning abusers. The other side of the world in the area that we're talking about here is privileged identity management. And these are generally accounts, not normally used by users. These are sometimes generic account, but the crossover between these is that these are normally not day to day accounts that are used by users.

These are usually accounts with some kind of elevated privilege with some kind of super user capability. And these are accounts that are, should not normally be used on a day to day basis, but are part of a break glass scenario. These accounts are also used as proxies to get into other systems.

Now, the interesting thing about this is that many times regular user accounts can end up being privileged accounts. And in order to determine this sort of escalation of use becomes a problematic in that if you have a lot of users, you can't really track whatever user is doing. We'll talk a little bit about the discovery of this type of usage that is normal user accounts being used for privileged access and talk a little bit about how privilege is achieved. But for now we want to talk about provisioning. As one thing we don't do provisioning.

We do consume what provisioning does, but privilege identity management is managing the accounts that have those super user or elevated privileges. And we'll talk a little bit about how privileges can be managed besides just providing a password.

The, the interesting thing about this is that when you start to think about privileged accounts, they're used everywhere within the organization. We've got a slide here that shows really the entire stack of the world in the old days, say 15 years ago, people didn't think about privileged accounts because there weren't that many machines in many organizations, they were highly segregated from each other.

And in some cases not even connected to each other today, we have a situation where a lot of organizations are not only physical, but virtual and operate in lights, out data centers, and where we see the proliferation of huge numbers of new machines and accounts appearing in some cases on a daily basis for some of our cloud customers who are providing cloud services to the world, they literally see new spun up VMs coming up on a minute by minute, hour by hour basis.

So the question is, is how do you secure an environment whether it's virtual or whether it's physical and what do you have to keep in mind? So we talk about this idea called from the iron to the application. And when we say from the iron to the application, we mean that everything has to be secured and everything can have a privileged ID at the bottom of this chart, you see shared hardware, this can be routers and switches. It can even be lights out devices that are being used by the servers like IPMI, DRS, ILOs.

This is part of the virtual networks or the real networks that you have that would be routers and switches and IPS and IVs devices. It's a part of the sand part of the NAS, all of the backend infrastructure has this and the hosted VMs. You have the hosted operating system, whether that's Microsoft or whether that's Linux or some other sort of interesting operating system that is gonna provide a hypervisor support. Hypervisor itself may have a credential in each hosted operating system within the environment has credentials.

And within the operating system itself, you would have root or administrator. You have middleware layers that contain credentials. These would be things like IIS, WebSphere, web logic, SAP, net Weaver, all have embedded credentials within them going up to databases, going up to applications. All of these have embedded credentials. So the trick to all of this is that as organizations have gotten larger and more complex, as they've grown by mergers and acquisitions, all of this infrastructure, all of this technology begins to proliferate accounts.

And as to what is a privileged account, that is really a, a judgment that has to be made by the organization itself. I mean, there are clear guidelines in ISO 27,001 and other regulatory standards, but effectively anything that has access to a lot of things would be considered privileged or has super user. So lots and lots of places where these accounts are. And essentially what ends up happening is organizations give up on managing them because they're just simply in too many places and they've lost control over all of these identities.

Now the spread of these, this usage is just somewhat of a normal evolution. You could think of it as entropy in the organization or disorder just as the organization grows, becomes harder and harder to find these credentials as well as where they're being used. But there are some behavioral characteristics that we see. One of them is that in many organizations, these credentials are well known. They may set all machines to the same password. They may be shared indiscriminately. They might be put on a spreadsheet and shared not only with the it department, but also with the users themselves.

But the reality of the situation is that what we see in many organizations is that many have stopped changing passwords and simply leave all of the privileged accounts all the same or leave them at the last state that they were working. And this is simply because it's become too difficult or too dangerous to make password changes.

Now, when you think about this, what do we mean by too dangerous? Well, the typical thing we hear from customers is that when they try to change a password, they don't get all the places where it's being used, all the services, all the applications, all of the middleware. And if you miss one of them and something within your infrastructure begins to call out using an old password, then that thing, whatever that thing is, is not gonna be able to authenticate and get access, which in fact, leads to the outage.

The other problem of this is that changing credentials, using manual methods and to some degree, scripts can be problematic and not necessarily reliable in which case, even if you know where everything is. And if you make the changes, sometimes the changes don't take or you fat finger a change. In which case, again, you get an outage. So outages and downtime are sometimes the reason why this problem becomes worse over time. So the common credentials flaws sometimes defined under the following terms.

One, all of the machines are set to the same administrator account are the same root account, and this is done as a matter of convenience. Now, there are some reasons to do this, especially if a group of people are gonna be working on a set of machines, but what really becomes crazy is if every machine in the organization has the same password and we've seen this, the other part of this has to do with cyber warfare.

And one of the things you'll see today, not with our presentation, but today in the generic sense of today is that the nature of the threats that we see are things like past the hash and past the hash deals with the idea that an administrative credential like a domain administrator might be picked up in flight and the hash of that value might be picked up. And then that hash can then be used to access other machines, even though the credential itself was not known. So in past the hash, if we can somehow get the hash of a valid credential, we can then use it.

So what this means is that common credentials flaw is not necessarily a matter of every machine being set to the same password. It can even extend to the idea that domain administrator accounts may need to be changed on a regular basis, but not every 90 days or every 120 days, you may end up in a situation where literally every credential in the organization needs to be changed every 24 hours or in some cases, even more frequently. So common credentials is not a matter of just static passwords being the same.

There can also be a matter of credentials that either are in common or used with the same password, or simply become known by some means either by the actual password or by the hash, which means you have to have a solution somehow to keep these things in a random state and constantly change it. So even if there is a disclosure, the disclosure limits where you can go, and also the time value of that disclosure itself. Now the issue about administrator accounts and I mean, administrator, as in any generic account, this means essay.

I mean, route, I mean, U I D zero, I'm talking about essentially the same thing. One of the big problems that we've seen is that there is a growth of tools out there that have been out there quite a while. Based on what's known as the rainbow attack, the rainbow attack allows you to, precompute the value of hashes that are equivalent to passwords. And in many cases, the hashes of the passwords are stored without salt, but in some cases, even salt can be reversed.

So the nature of all of this is that the rainbow attacks for a typical windows machine can be used to reverse out hashes that can be extracted from those machines. In which case you may be able to determine the password if the password is in a dictionary or is relatively short, making it easy to be picked up. But anyway, moving on common credentials mean just the idea that everybody knows them, or it's easy for them to be accessed.

Now, what some organizations will do is put all their passwords in a spreadsheet and then put that spreadsheet and vault, which keeps it from the auditors. But it's somewhat of a shared joke that everybody in the organization knows where that spreadsheet is or seen a copy of it. In which case you have static information that can effectively be used by anybody, even after they've left the organization to get into the company or into critical resources. So the spreading of these credentials is, is a matter of just the normal life cycle of organizations.

We've seen situations where machines themselves come in with factory defaults and during the hardware deployment, these never get changed, or they were set by the vendor and never changed. There's sometimes the matter that contractors may create or use their own user account and use that account to install line of business systems, and that credential doesn't change, it's sometimes a matter of job changes when somebody leaves the company or they change their job, they shouldn't have persistent knowledge to credentials.

There's also the issue of keystroke, loggers, social engineering, lots and lots of ways to get their credential. But if the credential has limited lifetime and is unique to one machine or limited in scope, these are some things that can be used for mitigation. So these are some reasons or some quotes that we've taken from potential customers or real customers that you might find resonant to your world into your situation. One of these quotes is it's too difficult to keep changing the privileged accounts and the applications that use them.

And this is a matter that if you have a privileged account that's used in 50, a hundred, 200 places, and this keeps changing depending on what your deployments are. This becomes difficult to not only keep track of the machines to keep track of the credentials where they're being used as well as what is the methodology to propagate the change. The second one is of concern to me, which is we don't have a budget to deal with this.

So effectively what you're saying here is you really don't have a budget for security and it's, it's okay for people to break in because we don't have the money to protect ourselves. The odd thing about this is that we do see this in it, and this is somewhat one of the interesting organizational crossovers. And that is that security is not necessarily a budget item for it, but really is something that should filter up to the CFO, the CSO and the CEO, because these are matters of mitigation for the corporation. And this is what I would call DiAlto.

So when somebody says they don't have a budget, it's usually because they need to reach up higher in the organization to explain what the risk is of having everything have the same password or being unable to change passwords and effectively explaining the business case why this needs to be handled. This is another interesting one. We don't make any more money to keep the system secure. And this has to do somewhat with the, what I would describe as risk reward and or compensation model for it. And that is that they're compensated to keep systems up and running, not to keep them secure.

So downtime, even if it's downtime for security is something that they're penalized for. So this is a cultural issue. And in fact, the introduction of privileged identity is part technology, but is also part organizational behavior. And so what we see is some interesting situations as, as Martin mentioned, was that if you try to fix everything and you try to create the perfect solution that solves every single privileged identity problem, and you put it into the RFP to do everything in the organization.

And if you're of any scale, you essentially will create a project that will fail because in fact, many things are in conflict and many things, even with full automation may need to be better done by hand. So there are some interesting political issues and some prioritization issues that you have to do.

Now, this last one is one that we see a lot, which is the auditors operate off of information. That's given by the organization to the auditors as to what accounts they have, where they're being used, and also how often they're changed. And it sometimes doesn't tell the truth to the auditors, or they simply don't have the information themselves so effectively the blind could be leading the blind. And in fact, many CSOs in terms of looking at their budget or their CIOs say the auditors didn't find the privileged ID problem this year. So we're okay for another year.

So one of the questions to ask about this last part is the goal of all of this compliance, or is the goal security. And so given budgets and given the nature of different roles for risk analysis and risk mitigation, this somewhat indicates that risk mitigation is not being done or risk analysis in not being done. It's really a matter of just simply moving on to the next forest fire.

Now, the auditing frameworks that are used by auditors all have, these are us based standards, by the way, FSMA HIPAA NERC for the power industry PCI that does occur in Europe, all of these standards, including ISO 27,001, as well as standards, even for the cloud, such as the CSA star standards, all define that proactive management of privileged IDs has to happen, including their identification enforcement of use of strength, as well as uniqueness and change appropriate delegation to the access of them, as well as auditing the access to these credentials.

But all these things are very hard to do by hand. Therefore, we have a reason for being not only through the identification, but also all the management phases of this. So let's step back. And let me ask you a few questions as members of the audience and see if you can answer these questions in your own environment.

One, do you know where all of your privileged accounts are and do you know how they're being used? Do you know who's sharing credentials and are they accountable for use? So for example, when you look in your SIM system and you see root is being used, or administrator is being used, do you know who that is? Do you know whether that is an application using it, or whether it's a user and why are they using it? So what is the attribution for use? Do you change passwords regularly? Not just the user passwords that are done by provisioning or account reset, do you change them on a regular basis?

And are you still using default passwords supplied by your vendors? Can the passwords sustain PA dictionary attacks? And in fact, because you don't have automation and you're trying to do this by hand at the end of the audit, you simply say, well, look, we did the best we can. What else is there? We realize we're insecure, but there's really nothing we can do because the problem is too complex and there's no solution out there to solve the problem. So let's talk about a solution, both our solutions, as well as other solutions that you can do yourself for free and by hand, the most basic idea.

And this goes back a long, long time is the idea that your passwords are changed by somebody that's trusted. They're kept in envelopes in a physical safe use sign in and sign out sheets. You use multiple people to hold different parts of the password and that somebody somewhere, at some point after the disclosure has occurred, we'll go back and change the passwords. Rarely does this last part happen. Another solution to this is to automate the process.

So automation means discovering of the machines on a regular basis, discovering all accounts within the environment, discovering where those accounts are being used and then correlating this information and then providing technology to change these accounts. But all of this being built in what I mean by built in meaning that you should be able to turn this on point it at the network, find the credentials correlate where they're being used, change them immediately, and then have this run continuously 7 24, discovering, correlating, and changing on a regular basis.

New machines appear new services appear. These all get picked up automatically. And the ability to do this on multiple platforms, you should be able to change the credentials without causing an outage. This is a big part of why you buy a commercial solution. If you can't do it without an outage, then effectively you're back to where you were with a manual solution.

Of course, the information has to be stored in an encrypted form, and this can take the form of both software encryption and hardware encryption. And in fact, there are certification standards for encryption, such as PIP one 40 dash two, of course, the advantage of a solution like this compared to a vault with, or a, a solution that might have spreadsheet that would be encrypted is that you can provide granular access to each secret one at a time, as well as provide role-based provisioning.

And of course, everything that comes in and out of the solution, as well as every change in every verification becomes an audited transaction. And of course, because this is a technological solution, you want it to be highly available and it should be non-pro proprietary. You should understand how your encryption works. You should understand how the delegation works. You should be able to go into the database, that's storing the data and actually understand what's there.

Now, of course, you don't want to be able to see the passwords or any secret information, but that's where the encryption comes in and scalability and cost of ownership are other big elements. So for example, if you only have a hundred machines, any solution might work as you scale up into larger environments. If you have 50,000 machines, a hundred thousand machines, 500,000 machines, the number of vendors that provide solutions that are automated completely and fully scalable becomes fewer and fewer in our solutions.

We're able to scale to the rate of 1000 to 5,000 or higher machines per minute, in terms of the ability to do discovery and also change. But these systems don't run by themselves. They are integrated into not only provisioning systems. So for example, we can consume Corion or forefront, identity manager, or Oracle, or IBM Tivoli all our identity and provisioning systems. And they drive our system in order to determine who has access to what, when, where, why, and how, and even SAP can provide the provisioning.

You also want to tie into an event monitoring system, a SIM, and you wanna be completely cross-platform of those. And this should be easy to bring in, but this means that now let's say for example, if Martin checks out route, what we'll see in the SIM is an event in the event log or in the SIM saying, Martin checked out the credential at such and such time for the following reason and on the following machine. And you'll see that in the SIM, then you'll see that generic account being used. And then when we changed the account, you'll see that where Martin's access was terminated.

So the Sims become somewhat of a collection point in a correlation point, but you also want reporting. You want to tie into help desk trouble ticket systems. If you're doing Itel processing, all of these things are things that represent what you'd expect out of an enterprise tool to do this.

Now, of course, because of automation, everything stays up to date. The common knowledge gets destroyed. So nobody really gets to retain information for a long period of time. But most importantly, this is automated from day one. So literally within a couple of hours of deploying this solution, you would know where all the accounts are.

You would know whether all being used and in fact, you can mitigate it immediately take away all the access and then overlay, what is the proper access for access to the systems and access means not just providing credentials or doing RDP that is remote desktop or SSH. It even means the ability to escalate an account saying that an account rather than giving them the credential or rather than it necess them in or already ping in. It also means potentially adding them to a group temporarily in order to achieve an outcome and then have them automatically be taken out of that group.

As after a period of time, let's say an hour or two after their work is done, rather than disclosing the credential. And this makes it a little bit easier sometimes to audit access. So privileged identity management is not always a matter of managing the identity, but also managing the escalation of individual accounts.

So the other differentiator in the space is the fact that we are an interior application, meaning that there is no central core central appliance, we're distributed, meaning that pieces of our product literally live in different subnets, doing discovery, doing correlation, doing propagation. And the reason for this is to provide a robust capability and to deal with speed of light. If you have a data center in say Munich, another one in Paris, another one in London, another one in Singapore, Los Angeles, and New York, you have to deal with the speed of light and if we're doing discovery.

And for example, when we look at a typical windows machine, we need to do as many as 20,000 lookups per machine in order to understand what's going on in that machine and see how credentials are being used. If you try to do that over a slow link, it's just simply not going to do it effectively. So the solution is distributed so that these transactions occur at microsecond rates on the local subnets, where all this information gathering and change occur. But it also means that there's no single point of failure.

And in fact, you can double up on these in subnets at no extra cost multifactor authentication, as Martin mentioned, and making sure you are who you are, is a big part of these types of solutions. And so in our solution, we implement RSA oath radius. We have SMS token sends, we have hard tokens, soft tokens. Many of them are actually free in the product. So autodiscovery is one of the differentiators in the space. The big difference between solutions is how well does this work? Does this work 7 24?

Is it not just the discovery, but are the changes also handled in an automated way and how much built in knowledge is there in the solution. And then there's differences in technology as to whether one solution uses what's called WMI or whether native calls are being used. And even in changing a service, do you change a service? Do you change its dependencies on that service? Do you handle clustering? All of these things are differentiating elements that make solutions work a hundred percent of the time or 99.9% of the time or 80% of the time.

So you do get what you pay for, but in any case, moving on to what the user interfaces and how these things work, these solutions have web interfaces, as well as gooey interfaces. One of the things we're gonna be talking about Martin at the EIC show is we're gonna be talking about in critical national infrastructure. If you need to manage, let's say 1 million or 10 million or 20 million systems, you may not have the time to be able to do this with a gooey interface or a web interface.

We're gonna talk about at the session, how do you go about managing so many machines and how do you give such prolific or such a prolific environment? How do you manage it from its entire life cycle view? But in this case, we're showing you the, the web interface, which allows somebody to check out a password or effectively do great glass, either escalate or provide remote desktop access. Moving on. Other elements of this is being able to pick a machine, pick an account, or pick a database and pick account or pick a router and pick an account is great.

But you also have to put in the reason the reason needs to be correlated in some cases to a trouble ticket system. And then eventually if you want to provide credential disclosure, that's definitely possible.

Now, one of the other things we've been working on has been the idea of merging business intelligence with identity management. And the idea that we had here was looking at row upon Roe upon Roe of law data. Doesn't usually provide a whole lot of visibility unless you know where you're going and you're performing forensic analysis. What we decided to do is see what we could do if we merge BI with IAM and PIM.

And what we did is we came out with a solution that allowed us to graph out in real time, across a wide variety of different elements, different identity management pieces, like for example, password ages or, and so, for example, if you're, if you have 10,000 accounts and there's three that have lost the ability to be managed because they become became forgotten.

Cause there were so few being able to plot these things on rhythmic displays, being able to plot users, being able to plot accounts and being able to plot 'em over time, as well as being able to determine coverage turned out to be a beautiful use of this business intelligence package that we built. So this helps you find trends. It helps you understand users.

It helps you understand your inherent identity management system to see how well it's doing, but also allows you to drill down into it, to actually fix things, which is really one of the goals of all of this is to not only be in compliance, but to be able to be secure and also to be able to find where the weaknesses are and to be able to fix them as well as to be able to understand users and accounts and to understand if they're being operated in a safe and same way. So the difference in solutions is deployment.

We typically deploy in days hard to believe, but if this is all automated, why should it really take that long? Especially if all the domain specific knowledge for all your platforms is built in and that's all because of the automation. Another differentiator is we're based on open standards and no proprietary technology. You don't have to trust us all of the information about how we've done. This is actually available online, right off of our website. And of course you want to do this at scale. So you should look at what other companies have deployed this.

So the benefit of all of this then is you end up with no shared credentials in a matter of hours, across hundreds of thousands of machines. If you're that large, you understand that each credential disclosure is unique. Credentials are changing constantly. You can change every credential in the environment if you want, or just the privileged ones access to those credentials is now secure. And it doesn't cause outages, which is the big part of this. To tell you a little bit about the company Lieberman software we've been doing this a really long time. We started in 1978 in 1994.

We became an ISV originally in the OS two realm. We started and had been creating a lot of the technology and privileged identity management. And our first privileged identity management product actually came out in 1999. Originally we were windows only, but we became cross platform in the early two thousands. We have over 1200 enterprise customers were covered by companies that is Analyst firms, such as the prestigious KuppingerCole and they're evil competitors, actually, not really, but you know, I'll ask Martin about that in a moment. We're us based us owned.

Although development is done in the United States, by us citizens, we're located in Los Angeles, California, and also Austin, Texas boy of offices in New York, Dallas, Northern California, and others. The product has deep integrations into many, many different ecosystems, not just Microsoft, but virtually every variation of Linux and units are supported by the product we tie into SAP. We're actually an SAP partner with a certified SAP integration. We tie into pretty much everything that most enterprises have and late the last last thing we added was ServiceNow.

And also there's some other interesting new integrations that we'll be showing at the show at the EIC. Every industry uses our products in the us. The federal government is a big user of our products. We have clear personnel with top secret clearance, as well as polygraph, but we're used across everything from retail to credit card issuers to national security. So at this point, I do encourage you if you're gonna be going to the EIC conference, which I recommend strongly to visit us at booth P two, we'll give you a demo of the product and prove to you what we say we can do.

So I want to thank you. You can learn more about this is www leaps soft.com/erpm. You can even email me directly love to talk with you. My email is Phil leaps, soft.com.

So Martin, I'd like to turn it over to you. It's for any Q and a, I realized time is short, but let's see what we could do. Yes.

Thank you, Phil. And I'd like, like to again, remind the attendees to enter their questions. I think you raised one, a very interesting point, which was really this critical infrastructure thing. So how to deal with this millions of privileged accounts in an efficient way.

And, and I think the other thing, which is also very important is to understand that it's not only about rude and the windows admin account, but that there are far more accounts out there. And, and if you think about all your root term management and all the other things, then there are, there are masses of privileged accounts.

And, and if you look at all the, the security backs identified for instance, network harder during the last few months. So then I think it becomes very obvious that you have to have these systems and scope as well.

And, and yeah, we all know how many of the systems are out with having still the standard and password. Well, sure.

You know, Martin, one of the things too, is that you have to manage not just privileged IDs or passwords, but you now need to manage certificates. You need to manage files, you need to manage any kind of secret that becomes part of this. So for example, in the cloud, it's just as important to manage the certificates and their entire life cycle to, from the point of the CA issuing them. Yeah. And they've been installed somewhere. You need to store them away, securely, including the passwords that go with them.

And so, so You say you're telling that you're, you're entering the, the market, which is commonly known as enterprise key management. Yes, absolutely. And here's the reason why some of our customers, which are the loud cloud vendors, when they spin up an instance, the instance generates a whole series of certificates that are used in their backend infrastructure, but also in the hosts themselves and also in the service that they're providing to their customer. And so the actual spit up of an instance can generate dozens of certificates.

Some of which are backend certificates that the, that the customer will never see or need to know about, but in a break fixed situation, if somebody needs to go out into the field and replace, let's say a module in a cluster, they do need to get access as a break fix, or a break glass to the certificates and the passwords that go with them. So in fact, the shared credentials are truly of interest in complex to handle, but even the life cycle of certificates has to be really part of the process because today's modern infrastructure is a hybrid of both certificates and privileged IDs. Okay.

So I think we are running out of time. I think there are no further questions. As of now you have to contact details of both Phil and me. Don't hesitate to contact us and thankfully too useful for your presentation from all that information you provided. And thank you to all of the attendees for participating this call webinar and hope to see you next week in Munich at EIC 2013. Thank you. Bye. Thanks everybody Avi.