Hello and good afternoon, good evening and good morning, depending on where you're listening in. This is the latest KuppingerCole webinar supported by OneIdentity and Paul Fisher. I'm a lead analyst with KuppingerCole.
Today, I'm really happy to be joined by Jason Moody, Global Product Marketing Manager for PAM at OneIdentity, and Bruce Esposito, Global Product Marketing Manager, IGA, OneIdentity. So, we have two absolute experts with us today. And the reason we have them is because the title is all about IGA and PAM.
So, as usual, if you are new to this, the audio control, you don't have to do anything. We control all that for you. There will be a poll in a second, which you can answer during the whole thing, and we'll look at the results at the end. And at that quick Q&A session, we also – it's your chance to ask Jason and the others questions, and we are recording this as usual.
So, if any of your colleagues wish to watch it, or if it was so good that you want to watch it again, then you can. It will be on our website. And believe me, some people do look at these more than once.
So, here is today's agenda. So, I'll be doing a very brief overview of what we're talking about, IGA – sorry, I keep saying IDM. It's IGA and PAM. And then Jason and Bruce will go into a lot more detail about the One Identity platform. But what we really want to do today is have a discussion.
So, we're not going to focus too much on the actual slide bit, but get into the details. And then, of course, hopefully that will generate some questions from yourselves.
So, before we start any of that, here is the poll I was talking about. We just want to know if you have any of the following foundational security items in place. This actually relates back to another webinar, but I think you'll agree that identity governance and PAM are very much part of a foundational security set. And you also have the choice of regular anti-malware tools, PAM, as I just said, data encryption, identity governance, and threat detection tools, which presumably would include the ITDR and things like that.
So, anti-malware, PAM, data encryption, identity governance, threat detection. So, that will remain open during the rest of the webinar, and then we'll discuss the results at the end.
So, I mentioned foundational security only because, as I said, it did form part of a webinar I did before, but I thought it was worth just re-looking at that because I do believe that what we're talking about today is very much part of what you might call foundational security, something that people have maybe not forgotten about, but is kind of being slightly lost in all the rush to talk about AI and all the other sexy stuff that's going on at the moment.
So, the four things that are pretty much key to security, and there are others, but I think these ones cover most of the things that we need to do these days. So, identity access, and then authentication for those identities, data protection, and network protection, and also endpoint security because so many people now work at more than one endpoint, and they don't just work in an office, et cetera.
So, all of those things add up to foundational security, and identity access includes – I've just lumped it under identity, but governance of identity comes in there as well. So, that's just something to think about when we're talking about the rest of today's topics.
Also, you can include security training or awareness training and governance as in the sets of laws, legal requirements, that every business now has to adhere to increasingly in the European Union, across the United States, and the rest of the world. In fact, most companies now have to – there's more and more governance and compliance coming up.
So, we also now talk a lot more about identity first, access and data, access to data in business, and this is a slide I also just like to use as a kind of framework for discussion, just basically shows how identities are using different types of identity management to get access to data, which is held in different – usually these days increasingly on cloud infrastructures, et cetera, and containers and things like that. But what we do have is what I call sort of identity silos right now.
So, at the moment, when we look at privilege access management, when we look at cloud infrastructure and title management and identity access management and IGA, they're quite often looked at, perceived and purchased as separate items.
But increasingly now we need to see that all four, but particularly privilege access management and IGA, which is what we'll be talking about, need to be thought of as things that work together, rather than settling, you know, this will do privilege access, this will do my cloud access and so on, which is why we're also seeing a lot of companies now offering identity platforms, because they can do a nice job of integrating all those different aspects into a integrated platform that works very well with each of its cousins.
So, we'll talk about that, the difference between an identity silo and also identity platforms, also maybe a little bit about why some people would still prefer to purchase a separate PAM tool and a separate Kim tool and so on. But generally speaking, it's not just the fact that we buy stuff in silos. I think also perhaps the management of these different tools are also siloed within organizations.
And again, that'll come up. And then just at the bottom there, the foundational elements, things are zero trust design, which is a whole huge, huge subject, but people are increasingly interested in how to apply those kinds of designs. We're talking a lot more now about zero standing privileges.
So, identities don't have continuous access to privileged data. Lifecycle management and governance, of course, is something we can talk about. Data governance, I mentioned that earlier. We're seeing start of organizations and vendors realizing that before we do anything else, we need to think about what data we actually have access to and who should have access to it before we actually start handing out roles and responsibilities and privileged access.
So, this really is, when I was talking about zero trust, this is assumptions right now of how networks work. So, nothing is trusted.
So, there's two ways of looking at zero. One is that there is no trust in the network, and the one is that we should have a zero trust network, and there is a difference. But there is little trust in the network because of these things which are happening. Not all devices accessing the network, or even in the network, are owned or controlled by the enterprise. The resources that people are accessing, or identities are accessing, are not inherently trusted or known about. And not all enterprise resources are on the enterprise network.
Enterprise resources are on the enterprise-owned infrastructure. So, increasingly, businesses use partners' networks. They'll use cloud devices, use SaaS, et cetera, which is something they don't actually have the full control over. This is important. Remote enterprise subjects can't always fully trust the local network connection. How many people will use a local Wi-Fi connection rather than a dedicated connection, and so on?
And in that case, most people will happily use a cafe connection or a Starbucks Wi-Fi because it's actually pretty easy to log on to, and you can log on to it every time you go there. That's a security risk. And finally, a consistent security policy and posture for assets and workflows across all infrastructures is needed, but it's not that easy to get. There is no easy 10-step plan to safeguarding identity or safeguarding resources right now.
In fact, it's probably got a lot harder, which is why we'll be talking about the way things need to work together. So, a combination of tools may be necessary to at least improve your posture. There are many, many questions you can ask yourself, but just as an introduction, you need to ask, like, what worries you most in your organization? What is most at risk? Where do you think threats are coming from, and so on? What obligations do you have will also impact not only your security posture, but your data governance posture?
So, do you have obligations to your customers? Do you have obligations to your partners? What kind of data do you hold? All that stuff.
What, indeed, types of compliance are you obliged to meet? And finally, what is your business?
So, if your business is in healthcare, if your business is in automotive, or if your business is in fishing, for example, your needs and resources are probably going to be different. So, there's no one-fit-all, but you can bet your life that all of those types of business now will need some kind of identity management. They'll need some kind of privilege access management.
And so, what I kind of say now to people that I talk to is, whilst we talk about identity first, you need to think about things backwards, almost. So, look at data first. Like I said, what obligations do you have? What worries you most? That feeds into the data that you have, where it is. Once you've thought about that, then you can start thinking about policies and access policies and authentication and so on. I put in there as code because that's the new fancy thing people are talking about, automating policies, which is good, but it's something else for another day.
Then you think about your authorization tools. You know, what kind of authorization do you think that you need? And finally, you get into, or you should get into, your identity security management tools, which includes IGA, PAM, SIM.
So, it's only when you've done the first sort of three steps there, and I know that authorization will quite often be integrated with security management, but it's only when you've done those that you have a better idea of where and when you need to place identity security. And I think that's my short overview open, so now I shall turn this on to, I think, either Jason or Bruce. I don't know which one of you is starting, but here we go. Awesome. Thank you so much. Great lead-in.
If you're a little bit older, there was a very popular commercial that came out that talked about two great solutions that work great together, and it was really two things that work great together. What we're talking about is two great solutions that work great together.
So, my name is Jason Moody, as introduced. I am the Global Park Marketing Manager on the Privileged Access Management side. And really, when I'm talking about Privileged Access Management, what I'm talking about is the access to all of the different privileged accounts, devices, things that people have in their network.
So, this is the super-secret stuff that either grabs you a new account, changes accounts, does things that your privileged user, your admins, things like that, have access to. And many of you may already know this, but this is the really, really important stuff. If I have a password and a login, I can get in, and generally, when people have that information because they've gotten it from somewhere, they can live in your network for a very long time, over 200 days. Many people use over 25 different solutions where pieces of information about identities and about things are kept.
So, there's a lot of different solutions out there and a lot of different stuff that happens from a privileged side. Now, Bruce, why don't you talk about the other side? Are you sharing? I haven't seen any slides yet. Sorry about that. You've spent so much time on those beautiful slides, and nobody's seen them yet. One more button. There we go.
Yeah, and I didn't even notice. I'm sorry.
No, you're good. We did spend so much time, so I would hate to not give that joy to everyone.
Anyway, so where do we leave off? Well, we left off with – so, talk a little bit about the PAM side. What about the IGA side, Bruce? All right. What slide are we on? I think we're at the main slide here. I'm trying to figure out where we're going in our – let's see here. I think you did the PAM one. I don't see any more slides moving. There we go. Let's see if I can get it up there on my side. There we go.
Yeah, of course, we did. There's two great things together from the 70s and 80s, flying together, tying PAM together. What was our next slide, Errol? That's kind of like you and Bruce. There you go. That's it. To be honest, everybody just wants to see our faces. They don't want to see slides anyways.
Yeah, no, and I think you kind of touched on this here. The reality of it is this is what we see all the time, and it's customers want solutions to their problems. They don't want products, and we see that in RFPs all the time.
Jason, I'm sure you see the same thing. We get RFPs. An RFP may be labeled the Acme Company IGA RFP or PAM RFP or whatever, but sort of look at the questions, what the company is actually looking to solve, and the questions cross domains of products. And so they'll be asking questions that are PAM-related, that are IGA-related, and from a customer perspective, it kind of sounds like they'd be the same thing because the reality of it is it sounds like IGA and PAM kind of do the same thing, which is different types of identities, right? They're both managing identities, just different types.
Some are privileged, some are non-privileged per se. So those assumptions are the same, but the reality of it is it's two separate systems, and this is what's frustrating for customers. In the world of the people who use PAM, typically IT engineers, security professionals, you hire somebody, and you want to automate that process and set them up, but the reality of it is it's two separate systems, that IT engineer that gets hired, the IGA system goes and sets them up, and all the email systems and all the enterprise applications and gets all that going.
Oh, the PAM? No, we don't do that.
Well, the PAM, you've got to go talk to the PAM people, and they've got a separate tool, and they're going to manually set them up in that system and get them all configured to be able to access that. So while it sounds like a single, typically, an IGA system should automatically do both, the reality of it is IGA tools out of the box do not manage PAM.
Now, I've even seen customers buy IGA tools thinking foolishly, we're going to manage our full PAM just from IGA. We don't need a separate tool to manage it. But there's so many use cases on the PAM side that you don't get with IGA. You can't do that. So that's the problem we run into is the customers look at.
Typically, customers don't even realize that they can solve this problem. It's just like, okay, PAM people manage PAM. IGA will manage all the other enterprise apps, and that's just the way it is. So that's kind of the reality of where people find today that we're going to address. I'll give you a look at the next slide as we get into it. We're going to talk about this in our conversations too. And there's a reason for that because I think customers are going to be frustrated. Why is it? Why doesn't my IGA just manage PAM? It's just another application, right?
If it can manage Salesforce and SAP, surely it can just manage PAM out of the box. Why doesn't it?
Now, a lot of the enterprise IGA tools now have separate connectors, and we're going to talk about this a little bit. They have separate tools for managing PAM, but generally they don't just do it out of the box. A lot of times it's a separate add-on, an extension. It's a module. It costs more or whatever to do that. And why? The question again is why?
Well, the reality of why is that PAM is a different security model than a typical enterprise application. An enterprise application that IGA tools are really good at managing has simple security models. They basically deal with the entities on the left, which is you have a user or an account, you have a group or role, and those things are tied to permissions. And that's what you're managing. It's kind of linear in the way the security is managed. PAM doesn't work that way. Because PAM has that.
PAM deals with accounts, groups, roles, permissions, but it adds another context of containers, and it adds a context of assets or credentials. And what you're doing is you're having one person give you permissions to share an asset or credential of another object, which gives its own unique permissions to another resource or asset. So it's a complex model of security that isn't easily translated. An IGA system is very linear in how it does that. So in order for an IGA to manage PAM, it needs to be taught that different model.
And the challenge is PAM systems, while all very similar in what they do, their architectures are all slightly different, so it's not just a simple tool of we're just going to manage PAM. It's also realizing how we manage a specific PAM in that case. So that's kind of the challenge I think that customers run into when they start looking at IGA and PAM and trying to look at the same use cases across both product tools. All right. You want me to jump to the next one?
Yeah, for sure. Great. So I think this is where we get into what's actually needed.
It's like, well, what does each one do? Well, we know what the PAM does. PAM is providing the password vaulting. It's providing the session monitoring and all those basic tools. And that's something that an IGA tool does not do and will never do. The interesting thing is a lot of vendors are trying to combine these into a single tool. It was kind of touched on earlier. We see IAM vendors that are now adding IGA and PAM into their IAM, and that's all great.
But I think customers are quickly realizing they don't want to put all their eggs in one basket because what typically happens if an IAM vendor is selling you IGA and PAM, the IGA and PAM are not going to be market-leading. They're going to be basic, right? And vice versa. If a PAM guy is going to try to tell you, okay, well, I'm going to add some IAM in here, it probably is not market-leading. And what customers want, and also you tie in, right? Let's imagine I buy it all in one big suite in one thing. Let's decide I want to shift and go to a different IAM tool in five years.
We don't like our IAM tool. Well, now it's not just shifting IAM. I'm losing my PAM and IGA because it's all built into one giant thing. So people don't necessarily want a single app to do everything. What people want is what we refer to as integration between these, but I want them to be plug and play, right? I want to be able to buy whatever IGA, whatever PAM, whatever IAM tool I want and then be able to have it integrate seamlessly with the other pieces, but give me the option that I could shift from one to another. And that's what you deal with.
The biggest problem that you've got is all the IGA vendors, with the exception of one identity, they provide PAM integration to third-party PAMs, but they're reliant on a connector that they're creating with a vendor that they have a loose partnership with. And having come from a previous IGA vendor who had this, the challenge would happen is when the PAM vendor decides to upgrade it, modify it, change something, add a new feature, it breaks that connector that you've got going before you can upgrade to it.
And now the IGA people are reliant upon the PAM people until they can get enough information and access to update their connector to do that. And that can be delayed months or years sometimes to do that. And that's frustrating. Having an integrated tool from a single vendor, two separate tools, but a nice native integration, that shouldn't happen, right, because you do that. And the things you're looking for out of it, what do I want? What's the integration between IGA to PAM that I want?
Well, you want the IGA stuff to work with PAM natively. One, provisioning and deprovisioning, right, that automation. I want to be able to hire the IT engineer and have it set up his email account and set up his access to the PAM resources all in one shot, single done. And then more importantly, from a security, when that security engineer leaves the organization, I should be able to deprovision them across all systems in seconds. Most importantly, we need to make sure they're out of the PAM system instantly.
We can't wait for a ticket to be created and somebody next week to go in and remove that person's access to the PAM system. That's unacceptable from a security perspective. We also want all the goodness of governance that an IGA tool has to be applied to PAM, things like policy, separation of duty, enforcement capabilities, right. PAM does a good part of enforcement within the PAM permissions itself, but not with outside of that.
So we want to be able to say, be able to create policies that are far more extensive to separate things across all applications, not just centered within the resources of a PAM tool. And that's what an IGA tool provides that, including the point of doing access requests. So a user can go to a single interface to request access, whether it's requesting access to SAP or in the case of an IT engineer, they go to a single request to access a resource on the PAM side. It's one tool.
And then the policy tool underneath can determine whether approvals are needed, whether it conflicts with another access they currently have and deal with that, instead of treating it like an isolated silo in which somebody just has to go to a separate interface to do that. And then another big thing that IGA brings is risk monitoring. That's something typically that's not built in. If it is into a PAM tool, it's limited to just risk monitoring the PAM access itself. But IGA looks at risk holistically.
It looks at what is the risk this individual has to an organization based on the total sum of all access, including PAM access. And so that's an important part when it comes to doing certifications. I want to regularly review through an automated mechanism who has access to what, make sure people don't have too much access, and to make sure it's being validated on a regular basis. Orphan accounts have access that shouldn't even have access. So these are all things that IGA provides that generally PAM doesn't, that you want to be able to meld the two together.
And that's where the integration of the two is essential and having native integration, not just some secondary or integration that a lot of organizations have to do on themselves. I think that's kind of where we're at with what we're talking about.
So, yeah, thanks. You know, what you were saying just then or just before is actually a bit of a thing for me at the moment, because this thing about whether you go for a platform, whether you go for a single vendor, or whether you stick to what people sometimes call a point solution or a specialist solution, it's actually causing some angst in the market. It sure is. With different opinions, like some guys will say the last thing we want is a full-stack solution, or we want a platform. We want to buy the best there is for each thing.
But then, like you're saying, everything needs to integrate properly. It needs to understand, and it can't just be basic tools you need. So how would you – I know that, obviously, you're from one identity, you're building a platform. But how best would you advise these people? Who might think – who would think would be better off with, like, a time solution, who might be with a separate IGA or IM?
I mean, it's just – there is confusion out there. Absolutely. And when we talk to customers, we see it all the time. I think a couple of things to understand is what customers have been sold in the past often are portfolios, not platforms, right? They come in there, and I won't put the big names. The big names. You can pick out the big names. You know which ones I'm talking about. I have no idea. And they're told that, hey, buy this one product, which you really want, and we're going to sell you everything else we do for one sweet enterprise agreement. And so they buy that.
Procurement gets it. And then they go down to the security people and say, hey, you've got to use this PAM tool and this IGA tool because we bought it. And these aren't market-leading. These are the things you want to use, and you're stuck with them. And now you're frustrated, right? That's what we're talking about.
Now, a true platform is different than integrated application, right? We have other major vendors now that are trying to get into all the spaces, and they're integrating into their single application, right? And the problem with that is that's great until you don't like one of the pieces. Now you can't pull it out, right? Like I said, if you're an IAM vendor and you're buying also their IGA and PAM, which are plug-ins for it, what happens? You decide you want to move to a different IAM vendor. Now you've lost everything, right? And that's the other one eggs in one basket nobody wants.
A true platform, as I like to refer to, is these are tightly integrated, loosely coupled, right? So as you add each component, you can pick and choose. If I go and buy your IGA, that's great and wonderful. Now I'm looking at PAM. I'm going to make your PAM compete against all the other big ones.
Now, if your PAM seems to be the best in there, great. I can link it in. There's a natural integration there. If I decide five years from now your PAM's no good, I can pull it out and pull somebody else's in there. But there's an advantage to it. If I'm getting different pieces, there's nice integrations there, tight integrations like a Lego brick, but I don't have to use yours. I can pull it out and put somebody else's in there. And I think that's what Warfocus has been at OneIdentity. We're trying to make sure that every piece of our platform is market-leading.
We need to be one of the top three or four products out there and be just as good as our competitors to compete. But at the same time, if you do go with multiples, we have to have integrations that you're not going to get if you try to piecemeal with other pieces. That's the way we look at it.
Right, right. And isn't there an argument as well the type of architecture that the platform or each piece of the platform is built in? So microservices is now the thing. So it's much easier to plug and play if you have a common code base underneath. And some of those vendors you're talking about say that they've integrated, but they're still using last generation architecture underneath it all. Right? Absolutely. And I think that's the challenge. And that's got to be natural.
I mean, the reality of these things is it's hard to do a big bang and change everything at once and do this. In fact, customers aren't going to do it in a big bang either. No customer is going to go out and say, hey, we want to buy all your stuff at OneIdentity.
I mean, I wish they would, but very few do that. We want to buy all your stuff. And we're just over the next year going to move all of our stuff to all of your things. It just doesn't happen. What typically happens is they have one project. Maybe it's a PAM project. We're looking at our next PAM release. And we compete in that space, and then decide. But one of the things is when customers go, and I think this is what we're trying to say is, when a customer looks at going with a point solution, right, they're going to compete out there.
Don't just look at the point solution necessarily on the basis of what features it brings to me today. Also, you should be considering what's the roadmap for that vendor on that point solution, and how does it play into our roadmap internally, right? How is that PAM vendor going to affect my IGA? Maybe we're going to look to refresh that in three years.
Well, will that affect the two? Is that an important connection between them? How will it affect my IAM access? So it's looking at the broader picture, long-term roadmaps, and not just, hey, what does this do to solve these eight problems we have today? Great.
Okay, so let's dive into some more questions, actual questions, more targeted towards the things that people are. And one thing that has come up is we're told privilege accounts are a common target for cyber attacks.
That's, you know, kind of accepted. But some people here are asking how prevalent is that really, and why do attackers focus on privilege accounts in the first place? So either of you. Jason.
Sure, yeah. I haven't heard from you for a while. No problem. So privilege accounts are the main target. And if I have an access to a privilege account, I then have access to basically keys to the kingdom. And as mentioned in the very beginning, people who have gotten into a system are there over 200 days. The market is continuously growing to billions and billions and billions of dollars. So the financial reasons to go after and look for some type of account that you can get into and sit on and then use for different reasons, ransomware, data exploitation, things like that, is massive.
So I definitely have a financial reason to go do that. If I'm able to just grab someone's account, like my account, if I'm just an individual at an organization, if I can get in and then start to see who Jason works for and who manages other things because I'm weaving around within the directory trying to figure out things, I can then start targeting those specific accounts, get much more information, and then really go after, and like I said, sit on things until I'm ready to make my move. And at that point, I can do anything I want. And that's what we've seen with a lot of customers.
They don't know that they've been exploited or that they've got someone, a cyber attacker in their network, and that they're basically rooting around looking at different pieces of data. And you never know what all has been taken. So that's the benefit of having a really good privilege access management solution in place, because I'm not just leaving things out. I'm changing passwords on a regular basis. I have policies.
When you were mentioning some of the foundational things at the very beginning of the conversation, there's so many regulations that, and I totally understand where they're coming from. We have governmental agencies, we have other organizations saying these are some best practices we have to put in place. In order to meet those regulations and be able to hit certain marks, you need to have things in place. One of those core pieces is that privilege access management. That then can really stop, change, do all the stuff that you need to do to protect yourself from those cyber attackers. Yeah.
And you mentioned you, they might just sit on those accounts as well, or those access points or whatever we want those identities for some time. Right. So they don't, and they just wait until there's, they've really got the measure of the place and then they strike. So it's hard to, it's hard to know that they're in there, isn't it? So very hard to know.
I mean, what, what we have seen obviously is that the data breaches that come out and talk about data breach reports and all of the, the identities that have been taken. I mean, I hate to say this, but you know, our, our U S government lost pretty much everybody's social security numbers, their dates of birth, their, their names, addresses, things like that. So my information is out there. I need to be on guard and I needed to be on guard forever.
And being in this industry, you know, I am probably more aware than many common people who don't think that they're a target, but anybody who works at an organization or anyone is actually can be a target because you can get the different pieces of information you need. Yeah. I know. And also it's surprising how we're not few, but it's still certainly less than like 40% of organizations that we've surveyed actually have PAM in place. So there is huge scope for, well, not just the, you know, market share, but huge scope to improve things. Definitely.
And as the regulations, as I mentioned earlier, keep putting in place, there's going to be more and more companies looking at a privilege access management. As Bruce mentioned earlier, companies were hoping that with, with IGA or with knowing the person's identity, because I think a lot of people realize now that that identity is the core piece to all of this. If I have an identity, I then have access to things and they're starting to realize the importance of having this separation.
But when we talk about the benefits of those two things, talking to each other and companies have been talking about this for a while, having your PAM solution, being able to talk to your IGA, it's hugely important. And I say that as someone who's worked at different technology companies, I still had access to data two years after being gone. Now it wasn't super privileged access, but when I asked my hand, please raise your hand. If you've seen this before with your organizations, many people that I'm on calls with or do webinars with exact same situation.
So there's a lot of data that's just floating out there and that, that access is not cut off. Sorry, Bruce, carry on. Yeah. Yeah. I was just going to add, I think that's a big point. I think organizations have to ask themselves if people on here to do, and hopefully most will say, ah, we got this covered. But if you ask yourself, the basic question is, do you have control? How many privilege accounts do you have? Can you pull up a list of every privilege account in your inventory? Right? And then the bigger question is who has access to all those privilege accounts?
And then can you go to any single person and say, Bruce, what access does Bruce have across the organization? Right? Those are simple questions.
In fact, if you're regulated, that's often a required question you have to answer on a regular basis on a certification, right? And that's the challenge is a lot of organizations, they do this haphazardly. They have a spreadsheet that's kind of half updated. They ask a manager, hey, can you update the spreadsheet? And it's only halfway there. But the reality of it is they probably don't know the information for that. And that's the big part. Like for example, that's where an IGA tool comes in, right? Automates that process.
But the amazing part is even people who have IGA, most of them do not do certifications on their PAM tool. And so if there's any single application in an environment, that's probably the one of the most important to keep secure that you have to be able to answer the question, who has access to it? What levels are access? Is it still accurate? Is a PAM tool and people don't do it. Imagine having orphan accounts in your PAM tool or orphan accounts that have access to privileged accounts. That's the biggest question to access that are asked that a lot of organizations either can't or don't ask.
And that's just about taking time bomb from a security perspective. Right. And I talked about, you know, overprivilege, et cetera, but I'd like to know for you, the expert, how does over provisioning and vice versa, ineffective deprovisioning of account privileges contribute to more cyber attacks? And you've already said some of it, but what are some of the common mistakes that organizations make when it comes to provisioning and deprovisioning privilege? I think you just hit it. I think it's the over provisioning is a common mistake, right? Because it's the path of least resistance, right?
I hired an IT person or hire someone, they need access. Or we got, we got developers, devs are the perfect example to work on a project or whatever. I can't access this or whatever.
It's like, ah, forget it. Just give them all access. It won't bother me anymore. Right. And that's easy to do. And that's often what's done because the path of least resistance, just we trust them, give them all the access he needs. He won't bother me anymore. My job's done. He's happy. Everybody's happy. And that's the way an organization will all run unless one thing occurs certifications.
If you now go to a security officer or an application owner or a manager and make them on a quarterly or annual basis, review the access and then sign their name at the end of it and say that accurate, that access is correct. And it's all they need, right? If you don't do that, no one's good. No one's going to care. If you do that all of a sudden, now you're putting people's jobs on the line saying you have to make sure this is accurate and correct. And that's the, how you solve it. Because otherwise it's just a matter of give them whatever they need to be done with. Yeah. Yeah.
What we see too many times what's happened when I've, I've gone to organizations, they rubber stamp it. So as the new product marketing guy, you come in and then you get the stamp that the previous part of our product marketing person had, who happened to also be in sales at one point, who happened to be at that organization for a long time. And then they retired. All of a sudden I may have access to things that I don't need access to. And some of those could be financial reports. Some of them could be internal customer lists. They could be forecasting things like that, you know?
And so if I come in as the more junior person, but I'm rubber stamped on that, boom, I have access to all these older things that the previous person in that position had. And then you've got this whole mess of things because things are open. And as a new person in the organization, you may not have taken all the security certification tests yet. You may not have gone through all the training. And so I'm a prime target. When I first joined this organization, I started getting text messages from phantom accounts saying that they were the CEO welcoming to the company.
Please reply back and say that you got my message. That's starting to happen a lot more where we're seeing smishing attacks for new employees. Because if I make an announcement on my LinkedIn, I'm a prime target for that kind of thing. Congratulations on your new job. Start getting text messages, start getting messages. Wow. That's so great. You did that. Boom. You've opened up a whole new, new can of things at that point. Yeah. And people just love telling the world that they've got a new job. The first thing they do is go on LinkedIn.
I was just going to mention, that's funny, because the thing Jason mentioned, it's one of the most requested features that people ask about IGA. And it's any vendor I've worked for for years. It's often the things, the IGA guys says, do you have a feature where I can basically photocopy somebody? I can just go in and click one guy and say, make him the same, be done with it. Right. And from a, from a provisioning perspective, that's a great tool. And to be able to offer that, you know, we can offer that. So it's not a matter of, it can't be done. You can always do that.
It's not a hard thing to provide as a feature, but, but a security person looks at that and go, what the heck, we don't want to offer that. Right. Because that just basically says nobody's looking at what, what the previous person had. We're just copying it from one person to another. And so that's why there has to be some sort of security process or policy in place before you start doing that. Yeah. And policy is key, isn't it?
I mean, I mentioned policy as code, which is emerging as, as an automated a way of applying policy to identities without, you know, a person having to be involved. And hopefully that will develop, but that has got to be where we control this surely. So that the identity doesn't just get the blanket access that the last guy had and so on. Especially a Pam.
I mean, if there's any one area, you should be photocopying somebody and just copying one to another. It's the Pam world. Yeah. Yeah. And what we said too on the, on the Pam side, one other thing on the dev ops and Ed was mentioned earlier, but, but our developers in general need access to things because they're testing new code all the time. They also have access to things and they tend in the past, not always hopefully now leave passwords of different things, different VMs. So I have access.
If I have access to John's information, I can go into different VMs that he's working on and boom, I can get access to all kinds of different things that's happening in the code. And then you're looking at having code injection. You're looking at having other things on the supply chain side of the house where we've seen attacks over the past five years that have just been, I mean, catastrophic at times. Yeah. Okay. So why is visibility into privilege accounts critical for maintaining the security?
I mean, we have kind of covered this, but what are the consequences when organizations can't identify, which is pretty much where a lot of organizations, they don't even know they privilege access because they've never even actually looked at it. Well, yeah. One of the things that started happening too is people are looking at cybersecurity insurance and when they start filling out those forms on, on the things that they need, obviously they have to do a quick audit on what's going on because those renewals come up each year. And as they come up, you need to have an idea of what's going on.
So that's kind of a first thing. Second thing is all of the different regulations that have been put in place are telling people that you have to have control over these accounts and the financial institutions, healthcare, government, all type of verticals have specific regulations that are coming down. And if you don't know who has access to those accounts, what those accounts have access to and how deep it goes, you're going to have lots of different problems. We always talk about the fact that if I have a login and a password, I'm able to get access with privilege access management.
We're not giving someone the password or we're put, we're injecting it quickly. We're also rotating those passwords. So really there's no password they can get out there. And I give you this example, there was a hospital chain. And so when, when a tech was going in, looking at an x-ray machine, that x-ray machine had been offline, that cookie was still on that machine. They were actually able to grab that. And then they had a password that was hashed and they could use that for that machine. And that's one of those random things that you don't think about.
You're like, Oh, that thing is, is it's a piece of hardware sitting in the basement. Haven't thought about it for a long time. There's no way that could cause a problem. That's some of the things where you look at and you go from a privilege. If I had my privilege access management piece in place, that was rotating passwords, managing those accounts, doing audits, the things that would not be a problem, but it can be.
And HIPAA regulations in the United States across the globe, medical regulations are hugely, they can be not only impactful for the individual, hugely financially impactful as well for the organization. Okay. So I'm just going to throw out this question. How can organizations then start to manage this? Do they need a privilege manager, literally a privilege, a person? Do they need an IGA person? At the moment, I think it all falls on the cyber security or it falls under a risk officer, but how could they do a better job of managing privilege and privilege access and identity access?
I think that's, I mean, I would put it into, of course, I'm going to be prejudiced because I'm the IGA guy. It falls under IGA, right? Because typically, you see, if you're regulated, you're already doing that, right? He mentioned before healthcare, energy, whatever it might be. You probably already have a person and a process in place that, that manage the regulated components where you're having to go through individual certifications or whatever.
The chat like this is the big thing that we're saying is that process you're going through that you're doing for your regulated accounts should also be in place for your privileged accounts, right? There's no reason. And the reality of it is it's often overlooked because again, natively that IGA app doesn't automatically even have the ability to see and pull in the permissions for the privileged account. So the odds are the guy setting up certification for IGA doesn't even know he could add privilege to that.
So to having that integration between the two is mission critical, but it should just fall under what you're doing for all of your type of regulated accounts or accounts that you're trying to determine risk and security and certifications on. So IGA comes before PAM. Is that kind of the way you see it or it just PAM is part of IGA? It's chocolate and peanut butter, which comes first, right? Right. But the reality is I think most organizations from a maturity perspective probably have an identity management system to some level in IGA before they actually go PAM. I think PAM is relative.
That's what I see most of them. But the reality of it is their IGA may be older. Maybe that needs an upgrade to a newer one to be able to handle the newer PAM information. I don't know. I think from a mission critical perspective, if I had to invest in one or the other, I'd probably invest in PAM first for mission critical if I didn't have either of the products. But definitely once you have PAM, you've got to have somebody to be able to overlook and manage that.
And Jason, you were going to come in there. Well, because you started out that question with the exact problem and when we talk about chocolate and peanut butter or we talk about different things that need to go together, right now they are separate for most organizations. If I and Bruce and I go and we talk to customers, the folks that are managed to two different silos are down the hall from each other. Sometimes they don't talk to each other.
Many times they have their own tools and they're not interested or they're concerned about what would happen when they start to integrate those fiefdoms together. So there is a, and this happens a lot with in different environments, there's a sometimes of control issue. Sometimes people don't quite understand the importance of having those things, being able to talk to each other. But if I come in as a new IT person and I'm given access to specialty things, if I'm part of the IGA solution and I leave that full life cycles and taken care of, I can then, I've had my full experience.
I've managed all the things. I go on ahead and I retire. They can then take that stuff, hold back those permissions, change what I had access to in the first place and then put me out of the system.
So that, that long tail of having access to random systems, potentially shadow IT, other things like that isn't a common occurrence like it is today. Okay. So here's a big question, right? Which how do organizations determine which accounts are privileged and what steps should they take to track which individuals have access to these accounts?
Now that, that is a huge question. That's a Jason, that's a Jason question for sure.
Okay, Jason, away you go with the ultimate guide to deciding who's privileged and who isn't. And if, if you miss this people, you're never going to know.
Well, it's funny cause we were, we were some at this kind of as a, if you go into an airport right now, when I go to an airport and I'm going to pick somebody up, I can get into the terminal, but I can't go past the terminal because I don't have a ticket and I don't have security clearance to get back into the area where the flights actually are. So that's that first part. That's what everybody has access to.
When I, if I'm added to a, an organization and I'm in active directory, I'm part of that front first part essentially where the ticketing is. Now, once I'm given a little bit of access and start to go in, I take my ticket and I go into to wait for my flight. That's what's starting to happen where we're looking at beginning privileges. If I'm then getting access onto the tarmac, I for sure have privileges. So it really goes down to what can I change? What type of management does it, does it really touch? Am I doing certain roles?
I mean there's a lot of different people that get privileged to different things, but many times it's not to do any changes. If it's changed, it's obviously privileged access management. If it's just access to get my job done, many times I may not need that. That's a super high level way of looking at it, but. Okay. But now we have it. We have the definition.
So Bruce, do you want to add anything to that? I think the only thing I would add to, I obviously this, that's a big question that you raised because it's not obvious, right? There's privileged accounts and there's privileged users, right? And they're not always the same thing, right? A privileged account typically is a shared account. We think the obvious ones, the domain admins, the roots, and the database administrators and things like that, right? Those are obvious and that's, that should be managed by the PAM.
But now you've also got privileged users that are accessing the privileged accounts. That needs to be managed as well. And then there's this new type, for example, one that often comes up that people don't think about. What about the account or person that manages the social media for an organization, right? That's a privileged account. Because if you imagine if that's misused and we've seen things like that, where these social media accounts get hacked, how damaging that is to the reputation of an organization. So that now needs to be viewed as, wow, this is a privileged account.
How do we lock down on who can access that and do that and monitor that or whatever? So I think the idea of privileged accounts is definitely growing faster. Like what's funny, because we have organizations come in now and Jason can access, they look at PAM and they think about how can we use PAM for all of our users, right? Not just our privileged users. We love that idea of managing, locking down, session monitoring, everything for everybody. So I think that's expanding out quite a bit.
Yeah, that's a good point. I think we are slowly moving towards that, that at some point everybody will have a privilege at some point in their working lives, but not necessarily all the time. So what would you say though to, you know, a lot of, obviously it's an understatement to say a lot of people use Active Directory or Entra and they use, you know, most of Microsoft Stack. If they say, yeah, I can do all this with those tools pretty easily.
You know, I can give people access to this and keep an eye on them. Is that a rather complacent view or is it a valid view? I think it can be valid. We get that a lot. I think the reality of it is Microsoft has awesome tools and the Microsoft ecosystem is really fantastic, but that's the catch with Microsoft that you typically world. As long as you're within their ecosystem, they do a really good job. But what about your access outside of Microsoft? And very few organizations have everything Microsoft, right?
The Entra idea, all of a sudden you've got SAP, you've got a SaaS account, you've got Salesforce. Well, we kind of integrate that, but it's also kind of separate. And so that's where it starts to fall short. So I think really, when we have a customer come and say that or they compare us to Microsoft tools, the easy thing to do is we'll look at your use cases. What are you really trying to do? And will the Microsoft tool provide everything you need at the price point that you want? Or do you find that there's gaps in it that it's not going to suffice in?
Well, then that's where obviously something, another thing, like one identity, we can deliver things that go beyond just Microsoft. So I think that's not necessarily a valid, an invalid question people ask, but it needs to be looked at because it's too simple to say, well, they do everything too. We don't need anybody else. That's typically too simple. Yeah. And you're absolutely right in this world. Nobody uses just one thing. Yeah.
Jason, we're coming towards the end. So let's ask some more practical questions from the audience.
And again, these are like big questions, but we can't answer them in an afternoon, but some of the best practices for implementing governance policies to ensure visibility and control over privilege access. So yeah, step-by-steps, how do you get there? It's not just about the technology, obviously.
No, it's not really. It's really understanding what's going on in your environment, what's going on with your accounts and getting a hold of those. So mapping things out and then starting to put policies in place. Once you do that, you're in a much better place. And so as Bruce mentioned earlier, going back through and looking at accounts and doing audits, we talk about doing auditing a lot. We talk about reporting.
The discovery piece of things, understanding all the different accounts, all the different devices that are in the network, and then going really and putting a standardized policy in place and starting to look at that. But if you continuously can run reports on it and see what's going on with it, you get a much better idea of where things work and where they don't.
Obviously, we don't want to cause friction with things, but we do want to understand everything that's going on in the environment. How valid is it that HR folks get involved in this? Quite often, a new person will join the team, the HR will do the onboarding, and that's kind of the end of it. They don't really think about their access or what they might need. Does HR get involved? Should it get involved? I think you just hit it, Paul. They're the starting point typically for most organization, right?
So if you look at an IGA or identity management, that's often one of the top five connectors you put HR in there, you put AD in there, and whatever one or two of the big systems, that's phase one, right? So HR is often the key point because one, it defines the person, right? It sets them up in the system.
And two, often it's used as the initial role, right? It's what's their job title, whatever. And off of that, we leverage the basic fundamentals of what they get. But it's never enough.
Typically, an HR doesn't want to manage all the other stuff downstream. They just want to control to make sure it's perfectly set up right. We have them with the right role, the right title.
But then, that's where IGA and then the next level, PAM, has to say, okay, how do we take that and define it further to get granular on the access and permissions we provide? So HR is definitely involved in the beginning. They're always involved in the decision. But typically, they don't care about the downstream from a permission security perspective. Okay. Anything on that, Jason?
No, I totally agree. Okay, fine. I'm speechless.
Sorry, Jason. So finally then, what makes it difficult to enforce some of policies and governance across different accounts? Have I already asked that one? I don't know. I don't think so.
Well, that's a broad question. But I think there's really two kind of different answers, I think, Jason addressed it from a PAM side. But obviously, what makes it difficult is very few organizations walk in the door and say, we have one set of rules, and this just fits for us, right? Sometimes customers want to come to us and say, hey, you just have some templates, and we'll just click on some buttons, and it sets up all of our permissions.
I mean, typically, you can kind of do that, but it just doesn't work because everybody's different on what they need. And then when you talk about PAM and how you set that up, there's a whole other thing. So I think that's the challenge, is the initial sitting down and determining roles and access and permissions, and then using that as a basis to create your security model, right? That's just the inherent effort. But that's why we all have jobs. That's why we all make good money in IT. So thank goodness for this.
And on the PAM side, what we're talking about potentially is we're talking about changing people's workflow. We're talking about the time it takes to actually put a PAM solution in place. And then you are changing the way people are used to doing things. And the way we do things, we really try and make things easy. We try and get things in place quickly. And then we try and make it so that the workflow continues to be and we're not causing that friction. We're really making it easier. But that tends to be, you know, change. People don't like change.
They're used to the way that they've been doing it. And so that can cause problems when people are looking at putting in new solutions that stop the flow. That's a great point. People don't like change. If you start saying, you know, we're going to start adding some new rules here, it's got to be done in a way that is transparent and easy to manage at the same time. Yep. So we're coming to the end, as I said. Okay. So we have our poll results, which show, I cannot see it, but anyway, identity governance is the winner. So that's good news. Is that good news?
Paul, come on. Well, there's more opportunity for you. PAM is more opportunity.
See, you're looking for it. Bruce won this one, but we'll see what happens on the next one.
I mean, yeah, I mean, what is data encryption? Well, obviously no one's interested in my bit, the data encryption.
Well, that's embedded most of the stuff. To me, that's an embedded part. I don't look at data encryption always as a separate entity as much as just being embedded, but that's the way I would read it.
Anyway, this was a poll that was more actually I cheated. It was a poll that was for a different webinar. So I think data encryption, it did a little bit better. But anyway, I mean, interesting figures there. So you could make of those what you will. Perhaps a quick final word from both of you, Bruce, to start.
Well, I've said so much. I don't know if I should even say another final word. But I think the key point we're trying to have is what – Mr. Schick.
Yeah, exactly. We're trying to widen the minds. I'm trying to get into the big picture. We're doing this again in two weeks anyway.
Oh, yeah, that's right. There we go. Okay.
Well, I've got to say something for them too. But anyway, yeah, I think my last comment is I think we're trying to help customers sort of think out of the box and realize not always become myopic in their focus of, oh, I'm just concerned about PAM or just IGA. But when it comes to security, there needs to be a long-term look, even though you may be looking at one tool, you need to be looking long-term about integration with other tools and how it fits in together. And Jason.
Yes, so I agree wholeheartedly with that. And I really stress the importance of making sure things fit with someone's environment. They're understanding how the environment works. We're not slowing things down. We're actually helping to speed things up. So the implementation time, the UI or how the product actually works with users is really, really important because, in the end, their job isn't this security thing. Their job is really what their core business is. So we want to help them get that business done and be protected as possible. Okay. Thanks so much, Jason, and thank you also, Bruce.
Just on your screen there you can see some research that was useful follow-up to this. The Privileged Access Management, actually, the new version of that leadership compass will be out in the next six weeks or so, so look out for that. And the other two are obviously highly worth reading.
Again, thank you both for a great session today. It was really enjoyable to talk to you.
Thank you, Paul. I hope that you at home or wherever you are listening in enjoyed it too. And as I said, we'll be back I think in a couple of weeks with another webinar on a slightly different subject. Amazing. So thanks again. Bye for now, everyone.
Thanks, everybody. Thank you.
