Unveiling 2024's Identity Landscape: Real-World Tactics, Top Risks, and Cybersecurity Best Practices Revealed

Hello and welcome. Good afternoon or good morning from London and also from the United States for this special webinar supported by BeyondTrust with myself, Paul Fisher, Lead Analyst at KuppingerCole and Morey Haber from BeyondTrust.

Morey, do you want to just say a quick hello? Paul, thank you so much for having me today and I'm looking forward to our conversation. Great.

Okay, so you can see on your screen we have rather a long title but we're unveiling 2024's identity landscape, real-world tactics, top risks, and cybersecurity best practices revealed. So before we get into that, just so you're listening, pleasure, you don't need to do anything. Just sit back, listen to us banter on. We can control everything from here. We were going to run a poll but we've had a slight technical issue with that so we might not be able to do that and we will be obviously offering a Q&A session.

You can enter your questions into the panel that you see on in the screen and this will obviously be recorded as well so that any of your colleagues who wished to be here today but can't, will be downloadable from our website. So that was the poll. Let's just do the poll as if, you know, a poll of one person which is you, Morey. So what will be the most impactful area of innovation in digital identity in IAM?

Paul, I would have to go with number five and I know it may sound cliché-ish with trend-setting and all the different hype around AI but there's so much new AI technology that is just coming out for identity and access management that commercially is just breaking the news. I honestly think we've just barely scratched the surfaces to the potential capabilities in the future.

Okay, well no doubt we'll come back to that because I know that many vendors are starting to use AI not just in identity access management but in other areas too. I probably, okay just to be different, I would say automation of IAM which is actually kind of the same thing. Fair enough. I think for you guys at home, I think you can actually still do this poll. It's just we can't see what you say so but do it because it'll be useful for us for later on. So let's get into our first topic of conversation today which you may be not surprised is actually identity.

Well obviously that's a huge, huge subject but I guess we should. There's been a lot of talk recently in the last year or so where identity has sort of become well kind of like the new AI actually that everybody's talking about it but for those of us that have been in the identity space for a while it's not new but perhaps Maury we could just say look at some what we actually mean by identity related risks and what we perhaps when we talk about the identity fabric what we're talking about there.

Sure, so I would like the audience to think about an identity as a concept machine or human and we have accounts machine or human associated with an identity. A one-to-many relationship that has existed for quite some time. Now when we think about our IAM solutions, our identity and access management solutions, we think about it in a concept of a house. You have contractors, employees, vendors and you have all these IAM tools that allow potential access and your internal workflows potentially have machine accounts that interconnect human processes, applications, SaaS, hybrid, on-prem.

An identity today with that one-to-many relationship in this house model of everything plugged together has risk. All plumbed together it's called the identity fabric. It's the fabric of everything linked together, working together, operating together. And threat actors today have found that it is easier to log in versus hack in. It's cheaper for a nation-state to teach social engineering and steal credentials than to weaponize a vulnerability and exploit for it to fade away once the security patch is out there and is adopted.

So attacks against the identity fabric, everything that links IAM together, everything that links an individual authentication, a login, a credential, a secret, are more prevalent. In fact, 90% of organizations in the last two years have experienced some form of identity type of incident where credentials were stolen and someone logged in versus hacked in. And that's the biggest changes in identity today because you think about you and I and how many different accounts we have. Even though we may have single sign-on and MFA, there are still plenty of places that don't use MFA.

Machine accounts can't use MFA. And if a secret is stolen, a credential is stolen, a certificate is stolen, then identities become the risk. And the best practices and changes needed to essentially secure them are what this whole webinar is about for Paul and I to discuss. Yeah.

So is it, I mean, I too have noticed that we talk about the identity fabric. Some people, especially EIC last week, some end users that is, were saying, well, isn't the identity fabric just a platform? It's just basically I can buy everything I need from a single vendor and there is my identity fabric. But it's a bit more than that, I think. I think it's more about architecture and, well, I was going to say zero trust.

I mean, that's another aspect. That's fair. Yeah. How would you answer that to a buyer if they said, oh, well, I just buy this and I'm covered? Yeah. So think of the platform as the technology. Think of it as the solutions you license, things that there's the custom integrations, the scripts. The fabric is more than that. It's an abstract component of the platform to the policies, procedures, workflows, monitoring. It's everything that is needed for you to keep an eye on the platform and all the vendors.

Because truthfully today, there is no vendor and hopefully there doesn't become one vendor, which is something we could talk about a little later, that does everything in IAM. We would be thinking of monolithic enterprises that have succeeded for several years and then imploded because their technology became stale. I am a huge proponent of best of breed in the IAM space, mainly because if good integrations exist with standards and APIs and languages like SCIM, then you can always maintain a secure fabric because everything is plumbed to the best of its capabilities and the right standards.

If you try to do one vendor, one platform for everything in your identity and access, and then have a fabric wrapped around that, the odds of you getting the best security, the most compliant security, or the most robust security are fairly low because there is no vendor that actually does best of breed for everything in the IAM space. I don't think it can exist in this market.

Yeah, but we are seeing, let's say, we're seeing some vendors from outside, outside of IAM, who are now saying, oh yeah, well, we can do identity as well now. So they're kind of bolting on what they might call a bit of PAM or a bit of identity access management. And I think that can be misleading as well. I agree. And that's where my comment comes from. You can do a little bit of PAM. You can do a little bit of identity. You could do MFA. Is it good enough or is it secure enough to protect the identity fabric? Many organizations will just say, yeah, I got MFA and there's still SMS space.

We know the risks. Oh, I can do PAM.

Well, I can remove your admin rights. Can you do session recording? Can you do history? Can you do all of the features that are required for a proper PAM solution in a small to medium size enterprise and do them well, cost effectively? The answer is, is PAM has been around since the mid 1990s. And truthfully, it's taken the most mature vendors in the space to do it correctly. Just bolting a little checkbox on or saying, I can remove admin rights might last for this week, this month. It's not going to support the organization long haul. Yeah.

I mean, I don't want to go on about PAM too much, but it's interesting. I mean, I'm doing the leadership compass for Copenhagen right now for this year. We still have 27, 28 vendors in there. And then normally what happens is the technology matures, the industry, the vendors tend to get smaller. But for some reason, we seem to forever be adding. And I think that is because, well, for me, there's two reasons.

One is that there is a demand from perhaps a smaller companies, smaller customers, I should say, who want some kind of PAM, but perhaps think the big PAM, as I call it, is too complicated and too expensive. So they see these new guys coming along and they think, all right, well, actually this will do. So I think, plus the other reason I think is it's still a huge market that hasn't actually been covered. The other thing that comes out from surveys that we have is that many customers don't even have PAM or even any identity practice.

So yeah, sure. Yeah. So if we look at that identity house again today, we have identity providers, we have access management providers, we have PAM providers. And when we think about the coverage as to why something like PAM or something like single sign on or MFA is getting highlighted is because there are real world business use cases like cyber insurance. It's showing up on our cyber insurance questionnaires. It's showing up in our latest laws and governance to say, remove admin rights, or you're securing your privileged accounts. And that's why PAM is evolving.

And all these other vendors are going, me too, I can check that box and help you either land and expand what I already have and not lose space to another vendor, or I can get into a market that is now becoming a business requirement. MFA has been mandated for many, many years. We're now only seeing the benefits of it, but also the risks of it because of things like MFA fatigue and SIM hijacking and SMS attacks, where we have to do better for things like FIDO2 solutions.

And you'll see all sorts of wearable FIDO2 tools coming out, like rings and credit cards that have biometrics built in to secure the identity. So we're all talking about that top level human and all of their accounts and everything underneath of how to get confidence that that identity account relationship is who they say they are.

Okay, let's move nicely into the next sort of theme that we want to talk about, and that is change. What is actually changing? You mentioned right at the top here that attackers are suddenly, you know, they're realizing that identity is an easy way in. So what is changing in the real world identity attacks and how is this landscape sort of evolving right now?

Well, think of it from a conceptual standpoint. I have an identity and I have dozens of potential accounts. Some may be monitored by AGA, some may just be registered with SSO. But if any one of them are attacked or compromised from a third-party exploit through a supply chain attack or credentials that are without MFA, some way of getting into that workflow. Then we have to think about a blast radius. How much damage can be done from even the lowest level account to other accounts associated with the identity or to the identity as a whole and lateral movement can occur everywhere.

And that blast radius really leads to a concept called the past privilege. Can I take a low-level account and laterally move to something of higher privileges and exploit an environment to system a user? And we're not only talking about identity-based attack vectors, we're talking about also mixing in malware, ransomware, other types of exploits and code that I could keystroke log a user even at the lowest level. I could break into their browser via an exploit and get into their secrets or some other technique.

So the biggest change here is that the attack vectors associated with an identity account relationship have morphed. Threat actors are realizing that I just need that little foothold and even if I can stay silent and they don't find me, I can do enough damage over time to get to where my final mission will be. And that is the change.

It's much like exploiting a forward-facing asset with a vulnerability and exploit, not being picked up by malware or doing a spray attack as we've seen with things like Midnight Blizzard, getting deep enough in and moving laterally enough through the environment where the identity becomes a very key part of the attack chain. That's the biggest change in my world. And is it because the attackers have suddenly realized this is actually so much easier, less risk?

You know, like you say, they can get in, you might not get them anywhere or it might lead them to somewhere else. It's perhaps a lot less damaging than some of the other forms of attack, as in bringing the heat onto them? I think it's easier for threat actors, nation states to train potential workers, individuals, malicious entities, or even script kiddies to do this type of work. The dark web has got a ton of credentials out there.

If you're running something like iOS, you can even see how many credentials right at the top of the passwords page under general they believe are compromised on websites. That gives you that foothold into that supply chain.

Obviously, mostly personal in this case, but it's easier to train and teach someone, look, here's a pretty standardized attack path. This person is using password 123. Odds are they're using password 123 because it's so simple. Let's spray attack it against where they work.

Well, how do you find out how they work? Social media, LinkedIn, other sites, and you build that attack chain, that attack path. In my opinion, it's easier to teach someone pretty reliable workflows for an attack versus here's an exploit, go scan the internet and see which ones it'll work against. Yeah. You mentioned the iPhone or iOS. It always astounds me that all you need is access to the phone to then see every single password you've stored in the phone to every other service that you use.

Of course, that, again, is convenience versus security. It's actually very useful to have those passwords, especially when you forget, because it means if I log on to the same application or service on my PC, I can look up the password on my phone, but it's almost like writing your passwords down in a book. It's at a high level from the end user perspective, it feels like that. The encryption and using TPM under the hood, it does a much better job.

Hopefully, many of you have seen the iOS 18 now that there's a password app, but Android has been doing this for years as well. There are tons of third-party applications that work across platform to secure that one-to-one relationship with the account and the identity.

If a phone does get SIM jacked, if there is a malicious app that does access it, or you accidentally click on a link that is a watering hole that allows you to trick you into entering those credentials, all it takes is that one particular type of incident to start the ball rolling and the threat actor gets further and further and further. One of the biggest attack vectors to date for an identity account relationship comes from either the business or personal side is where I need to contact a company. I need to contact an airline, a financial, or somebody else.

I just go to my favorite browser and say, please tell me X is contact phone number. What is the phone number for this vendor? You'll find in most search engines, the top rating phone numbers that are listed in websites are fake. They are actually malicious websites that have been stuffed for search engine optimization to get you to call that number and you're going to end up in a malicious call center somewhere else.

The attack paths for getting identity account penetration have changed drastically in the last year to two years, including just saying, please show me bank X's contact phone number. Odds are it's probably not. Right. Yeah. So you mentioned the other tools there are, and of course you're right, I shouldn't just pick on Apple.

Google, oh sorry, Android has done that, Windows does it, you know, and they're all effectively password managers, which brings me, which for, have always been consumer focused for that very reason that we all forget our passwords to so many things that we need to log onto. But some organizations think that a password manager is the same as a privileged access management tool, which of course it isn't. It's not. So let's look at the differences.

I mean, a password manager literally does what it says. But so many smaller businesses, especially, and even some larger ones rely on a password manager because they think, well, that keeps our passwords safe, but it doesn't, does it? It does to a degree. So password managers are designed to create a randomized lengthy complex password that's barely human readable, if you do it right, and store it. It can also inject it into a system. They may or may not tell you the history, they may or may not be able to rotate, and they may or may not even be able to share.

A privileged access solution can do all of that, plus rotate, plus history, plus delegate the session, plus honor lease privilege, plus user behavior, on and on and on. And the primary difference here is, if I'm using it for work, I now can track who's using a shared, or I actually never know the password for a system. Oh my gosh, there was a catastrophe. We've had to restore from backup. I did have a ransomware attack. What was the history when that backup was run?

Password managers don't necessarily have that historical approach, more than a couple of passwords, or even potentially years, where I could say, I'm taking a backup from x period of time, and restore it, because that was the password for these accounts at that time. So I always think of personal password managers as a subset. Doesn't necessarily understand the organization of the company.

Some of the enterprise versions have a rudimentary method, but all of the other things to control, the most sensitive accounts, those ones that get you to the path to privilege, the PAM accounts, have additional features that make the two different. I would encourage any small to medium-sized business, use a personal password manager. It's better than memorizing them. It's better than writing them down. It's better than putting them in a spreadsheet.

But as soon as you start sharing, and you have to control access to something sensitive, you've actually surpassed the feature sets of a password manager, and you're now into privileged access. And that's that special case of the identity account relationship.

Okay, well, let's stick with passwords, because that's another thing that we could talk endlessly about, but let's do it anyway. Because PAM traditionally still uses passwords, but in a very different way.

So it has, you know, traditionally you have passwords in a vault, which are checked in and checked out by someone trying to get access to a privileged account, or a privileged account get access to some resource. We've seen recently a move towards what is called just-in-time access, or ephemeral access, which aims to get rid of passwords altogether, or at least hide them completely from the end user. Personally, my take is that we should try and move to that situation as quickly as possible. But it's not as easy.

It's easy for us as analysts and vendors to say just-in-time is good, but it's actually harder for some companies to get their heads around. Some businesses actually still prefer a vault. They feel because a vault is a secure thing. It is encrypted. It's pretty hard to crack a vault. But the real issue, I think, is convenience and speed, isn't it? We're looking at new types of employees or users that need access to privileged stuff.

So this, I think, goes into our next conversation is what's new, right? Right. What's new is literally all of the changes in attack vectors from deep fakes to the concept of just-in-time. So let's just take privileged access, or actually, let me back it up. Let's take access of any type, password manager, PAM, not included. I need access to X. I do not have an account there. My role is unestablished as to whether I have access, but I know, and the company knows, that I should be able to have access to something on-premise, in the cloud, etc.

So we have to first understand that I'm doing work, and it's something that the business says is valid work. So we're shifting from role-based access of defining every identity account relationship to a specific task or mission to something that's policy-based. I'm an employee. I'm a contractor. I'm working in a geo. It's during business hours. I have these applications installed. I'm on a trusted device. I have confidence in my identity via MFA or whatever the tooling may be, and I work in this particular department.

I've satisfied all of those conditions, and maybe even a trouble ticket, a service ticket, an IT ticket is open to guaranty access for verification, or my manager has approved me access through some supplemental workflow. That policy, when built out like a flow chart, should answer yes that I'm allowed. That's policy-based access control. That's just in time. When I'm now satisfied all of those conditions, whatever I've requested should allow me to go in and do it, whether it's a command line, a PowerShell, a website in the cloud, on-premise, etc.

I know nothing about the account and entitlements that got me there, and the definition of entitlements is privileges, permissions, rights, everything that allows me to do a task. It's a high-level concept to go do a task, and that task can be done. It can be monitored. It can be recorded. It can prove my behavior is correct. Everything that is associated with traditional privileged access management, even though it's true access management, I don't have admin rights. I'm just doing this task. The benefits of this just-in-time model are massive. I don't have to create roles.

I don't have to create accounts in all of these different locations. I don't have to manage all of those credentials. I don't have to do all these other techniques that IGA was needed in the past for certifications and attestations. I'm doing it based on policy.

Now, depending on the application, some may need a temporary account recreated. Some may use a standard service or functional-type account that's heavily gated and monitored. The access technique itself is irrelevant because the end user never sees it.

They do a, who am I? It's a temporary fictitious account, but their privileges are highly gated, and that is the new future for that identity and account relationship. That's really, really powerful because you just have to establish when and how, not every single person, every single role, especially in large environments, that should have access and how they get there. Yeah. Okay. Let's also talk what else is new. One of the reasons Just-In-Time has become talked about and is seen as the future is, of course, the changing nature of privilege access.

Like I said, if you go back 20 years, Pam was considered for admins and super users, who I've never really understood what a super user was, but anyway, there they were. They could do bad guts in my world.

Well, they were just super, but anyway, they were allowed to do stuff that mere mortals weren't allowed to do. Of course, that's changed very much, which is why we're talking about change in the Pam market and identity markets. It's because we now have DevOps.

Obviously, that's the cliched example that we always use of people that need rapid access to sensitive data, et cetera, but it's more than that. I think privilege is now for people who need access to, say, an HR database, or they need access to financial data, and so on. It's those guys, along with the move to cloud and multi-cloud and people using cloud applications to get stuff done. It's kind of asked for the just-in-time, but it's also made just-in-time possible because everything in the cloud works faster. I'm not saying Pam is dead, right?

Martin's probably watching this from his sick bed. So, Martin, I'm not saying Pam is dead. I know you hate anyone to say anything's dead, but certainly, if it's not dead, it's mutating. It's mutating heavily. I always like the analogy that Pam used to be called PUM, Privileged User Management. It's been called PIM, Privileged Identity Management. I now think of Pam as not just Privileged Access Management, it's Privileged Access Mitigation. It's Privileged Attack Management. It's Privileged Attack Mitigation. It's Privileged Asset Management.

The A has changed into so many different words that when we think about modern techniques like just-in-time, we realize very, very quickly that every department has those super user or privileged accounts. Marketing, social media, right? If someone's social media for the business is compromised, sales, you shouldn't be able to download entire sales lists from Salesforce. The manager might. The manager might be able to tweak a SPF program, but every department has sensitive access that can make changes or cause damage. And that's where it becomes, where is the asset? Privileged Asset Management.

Does an asset have privileged rights that shouldn't? Privileged Asset Mitigation. And we start to see that play on the word Pam. That is really the future. And concepts like just-in-time, user behavior, et cetera, are all going to be needed to stop these modern identity-based threats. And you have to think of it just more than access, but asset attack, et cetera, to get there.

Well, it also stood for Privileged Account Management for a short period, I seem to remember. But the other thing that is new and related to this, actually, I'll come back to that. I wanted to also just say a buyer now might think, okay, well, there's now Cloud Infrastructure Entitlement Management, which is also new. And they'll say, well, actually, that seems to do pretty much all I need. It finds out who has access to what. It can scan for over-privileged entitlement, et cetera. So why do I need a Pam solution? Maybe Pam is dead to me.

Well, Akim's solution is quite unique, especially because the definition has changed so radically from its inception. Infrastructure Entitlement Management, again, that definition of entitlement saying, show me an identity in account or just an identity. Some cloud providers don't use concepts like accounts, whole different discussion to confuse the industry. And show me their entitlements. I can create a virtual machine. I can create a webpage. And that entitlement will have the privileges, rights, permissions, and everything to do that work. But it doesn't control access.

It doesn't do anything for the five A's, authentication, authorization, audit, et cetera. So you have to go to the concept of Akim being just that one piece, like a discovery of asset in account inventory and getting the entitlements. But how do you now manage the access, the usage, the governance, the policy, or even old-school role-based access to that? So Kim is just one small piece in modern Pam. And if your solution doesn't do that today, well, you have different problems. But anything you're doing in the cloud has to have that Kim component. Which you do. I think it's worth saying that.

I'm trying to be agnostic, Paul. Well, when I said that, I thought, oh, I hope they do have it because- We do. We don't label it as a separate product. It's a feature set. When it first came out, people were buying Kim solutions. And then all of a sudden it became a part of everything. I put the analogy to, hey, we had antivirus solutions and we started buying anti-spyware. It only took a year and a half before anti-spyware became a part of everybody's antivirus solution. It's the same concept. Okay.

Well, another one is Identity Threat Detection and Response, DR. Now, there are two opinions about this. One is that ITDR is kind of an acronym in search of a market. Or it's something that pretty much exists in most PAM platforms anyway. It's just perhaps does a little bit more.

So, I personally am not sure about whether we'll still be talking about ITDR in a couple of years' time and whether it'll just be a feature set, like you said about Kim. But does it have any value in highlighting or stopping some of these attacks that we've been talking about perhaps more quickly and with more effectively than traditional preventative tools? I think you and I might differ a little bit on this one, to be fair. I think every IAM vendor has ITDR built into their solutions. An MFA solution will have its own version of detecting MFA fatigue or some other MFA attack.

A single sign-on solution will have some form of detection, alerting, logging of some potential abuse to it, including session token hijacking. PAM solutions will have their own.

However, this is where the deviation occurs. ITDR applied to a single vendor is the protection of itself. What do you do about the entire identity fabric? And this is also what's a part of what's new.

Are there tools out there that look at the entire fabric, not just the platform, but the policies, workflows on all the vendors and bubble that information up to find where there are hygiene issues, where there are runtime issues, if the integrations between two vendors are potentially a problem, why are they miscommunicating, or was there something wrong that in the entire workflow was detected anomalous? Now, there is no category for that today. We're still calling it ITDR, but it is really the identity security of the entire identity fabric.

Now, there are solutions like BeyondTrust, I'll leave that alone, that do that and can find things like some of the more modern identity breaches and third-party suppliers. But that category has not emerged with a name yet, and I hope it doesn't turn into something like Cloud Workload Posture Management or CINA. No more acronyms.

It's the security of IAM, and hopefully people recognize that in the entire house, that entire ecosystem of all of our identity plumbed together, who's keeping an eye on all of the pieces to make sure that they're correct and safe from a hygiene perspective and a runtime perspective. Yeah, you're absolutely right.

I mean, another thing that buyers get confused or annoyed about is this forest of acronyms, and many of which are just duplications of other acronyms, but like you said, PAM, PIM, PUM, you know, it's kind of the same thing. But yeah, so yeah, I think, yeah, the jury's out for me on ITDR, but it's certainly there. The good thing is, I guess, that it shows that people are thinking about protecting identities in a way that they perhaps weren't before, so we probably should be grateful.

Yeah, it's a best practice, and that's I think what you and I are talking about, is don't think of ITDR as just the protection of any one of your IEM tools, disciplines, or workflows. Think of it as how all of those integrations work, even as something as simple as, hey, I'm forwarding my logs to a SIEM. Is that workstream protected? What is the certificate used? Are there ACLs involved? All of those things.

Well, the other thing that's kind of new but isn't, is actually really old, is Zero Trust. But it's kind of had a renaissance or a new life recently, and I'd like to talk to you because I'd love to get your opinion on Zero Trust because, A, we always say, well, it's not a platform. It's not a solution. It's an architectures way of doing things. And I think that we've moved on from the original definition of Zero Trust, always verify the original guy whose name I always forget, but the father of Zero Trust, he's called. Martin's now thinking, I know exactly who he means. I should be doing this.

I know you too, and once you said, I forgot the name, it went right through my head too, but please continue. So what I've noticed that the people have taken the concept of actually done something really good, but particularly in America, the NIST and also the Department of Defense, especially, have come up with some excellent frameworks and guidelines on how to implement Zero Trust. And I think my point to you is that people look at Zero Trust and I think it's way too complicated to even think about implementing, but it doesn't have to be.

You can use a little or as much of Zero Trust as you want, and you can actually still have some trust as well in your organization. If we have no trust whatsoever in our working lives, then nothing would get done. I think you're right on that. I think it spins into our next topic, and that's attacks. When we think about all of these attacks, we think about ITDR solutions individually or as a whole, we realize that there are some very specific penetration points that are attacks.

And if you're trying to model your protection strategy against those attacks, you have to think about where's the most likely for me, for my organization, and how. So the original concept of Zero Trust in terms of attack protection didn't stop, as in this slide, the goal from happening. It stops the concept of the goals, goals, plural, from happening over and over and over again the same way.

Zero Trust was essentially built as a methodology that yes, incidents will happen, a breach may happen, but I want to contain it as fast as possible to prevent lateral movement and not allow a larger exploitation of my data or environment. That's its goal. It's not a product again. You can't go buy Zero Trust.

Okay, I have this mindset from a definition standpoint that threat actors are going after my endpoints. We would all agree that that's a number one concern, right? Especially for remote workers, whatever it may be. If I can get into an endpoint, I probably can get into something else. So let's just say it's going to happen. And if that does happen, that incident or breach happens, it's contained. Got it. Attack vectors. We've talked about identity account relationships. We talked a little bit about vulnerabilities. What model can I use to do this? That's Zero Trust.

Zero Trust does not apply to everything. You pick a workflow in your entire identity account authentication authorization model, all of it, and you go, I'm going to apply Zero Trust. So let's take that end user. We're going to keep them isolated. We're going to require step-up authentication. We're going to use all the best practices that we can potentially find and then monitor it and measure it through its cycle.

Now, NIST 207, 800207 provides a framework. The DoD in the United States has also done some work here where you can actually say, I do this, this, this, and this, apply to my end user workflow. And if something is potentially compromised, I can do isolation. I can do forensics. I can do all the things that they dictate. And now you've achieved Zero Trust on your endpoint. It's actually not as hard as you think when you pick the workflow, you understand the attack paths, and then you apply your tool sets across them, and then ultimately test them.

It's one thing to do the mapping, but you got to do the test. You got to go through that red team exercise or say, we're going to choose XYZ as a person today. They've been penetrated. How fast can I isolate, contain, analyze, and determine, and then restore in order to bring them back online. And when you get that workflow out, you think about it, okay, I got identity attacks. I got exploits. My Zero Trust workflows are designed to protect my most critical places, and it actually can be achievable. I think that's a brilliant way of looking at it, Murray. Yeah.

If you, and I'm a great believer in that as well, breaking things down rather than think, oh my God, I've got to apply Zero Trust to my entire global organization. Well, no, you don't, but you, like any project, you break it down, you take it step-by-step, you do your due diligence, you look at, you know, do data governance, which is something else which is creeping into this whole area as well.

So, yeah, I totally agree, but people listening to this probably are interested in Zero Trust, and I do recommend you look at some of NIST and the Department of Defense stuff, as well as, I should say, Coppinger Cole's own research on it. Your research is actually, I think, in many ways, foundational to what other government agencies have adopted. I'll give a shout out to analysts like yourself that have basically taken the concepts of Zero Trust, elevated them to a level that most people can understand, and then they become more operational based on entities like NIST.

One of the things that's so hard to understand for people regarding Zero Trust is, well, I just talked about Endpoint. What other workflows should I worry about? CICD is an easy one. Access into, if you're a software vendor or a SaaS provider, the entire workflow for support vendors and anybody else to get into that SaaS environment is another workflow. You have to go back to the concepts of how identities are attacked today, determine where your highest risks are, and then start that Zero Trust journey.

I think the material that your team has created will really help you understand how to think about that. Okay.

Well, thanks for that. I'm glad that it's useful. I was just going to say that you can tell that Martin put these slides together with his football-related... It's not on screen now, but anyway.

A goal, you see, interestingly, he's saying attack there, and he's showing someone a goal is not actually a negative thing if you're on the right side. That is correct. If you keep on getting goals by going to the top right, then you're not thinking about the attack vectors that are meaningful. One last thing about the Department of Defense, I love being a military organization.

Obviously, they're very cold about the way... They only talk about human entities and non-human entities.

It is, and the machine identity problem is huge. Don't get me wrong on this, but that's a much harder nut to crack that requires secrets rotation. There is no such as MFA. Everything has to have an ownership, but secrets rotation and secrets management alone, in my opinion, is not enough in a modern world. Yeah. I'd love to get... Yeah. Machine identities or non-human entities, they are probably harder to manage. Like you say, you can't apply some of the two-factor onto them, but also they are often automatic workflows or their service accounts, et cetera. How do you keep an eye on them?

Because there is millions... Literally, we've all seen the statistics that machine identities outnumber human identities, like a hundred to one or something. In my opinion, you have to go to behavioral and log monitoring. If you look at the recent support breach from last October, we'll leave the vendor's name out. The secret that connected two systems in their support organization was stolen because it was stored in a personal password manager. The attack vector was actually a personal account in a password manager, then being used by the threat actor and sending up a separate IDP.

We'll leave all of that alone at the moment. You would have seen in log management, IP addresses and calls from an authorized location. You would have seen an IDP being added. It's one thing to do secrets management, discovery, rotation, et cetera, but you have to do hardening and you have to look for a machine behavior. Without the hardening and machine behavior, it doesn't matter how fast you rotate, the threat actor is just going to get it again. It is a much harder nut to crack, but when you're doing vendor-to-vendor in the cloud, you may not have that visibility whatsoever.

The storage of the secret that you've used and the hardening become key because there may not even be any automated rotation between connectors and integrations. We're supposed to be talking about attacks. Are attacks increasingly targeted at machine accounts? I think so. I think if you look at some of the trends of supply chain attacks and things of that nature, they're more popular in the news, but they're more obtuse in terms of the methods that those attacks were conducted. Did it come from source code? Did it come from a secret that was leaked?

Did it come from a rogue employee that was doing administration? Did it come from someone claiming to be support desk that managed to have MFA turned off and then entered the workflow as a machine? They're obtuse. They're basically ways of finding an attack path into the plumbing, the machine-to-machine plumbing within an environment or machine-to-cloud or cloud-to-cloud environment. Let's move on to our last subject area, which should be counter. Counter attacks is something that we could spend our last 10 minutes or so talking about.

I mean, that is basically everything we've been talking about, but what tools do we have, apart from the obvious ones, but what tools, what can we do to fight back against the attacks on identities, the attacks on privileged, the attacks on identity access management, which is increasing, as we've established?

What would be, let's say, Mari, let's say not a product solution, but things that people can do right now to start protecting identities, even if they don't have PAM, even if they don't have an identity and access system, but they do use the cloud, they use AWS, they're a typical, maybe a smaller business that runs stuff in the cloud. It's all about getting the business running, and security tends to sometimes fall behind. What would you recommend, number one? There's a lot of philosophies here, and we probably could do a whole other webinar on just counter.

I am a huge advocate of defense only, not offensive counter. I think offensive counter can get any organization in trouble that is hacking back too many loopholes, too much danger. Even if it's a trusted vendor, if you're going to do even a penetration test on one of your suppliers, you got to let them know you're doing it so that they don't think it's an attack upon themselves.

Outside of having this large discussion on offensive, let's talk about defensive, red teaming, purple teaming, thinking like a threat actor, using penetration services, subscribing to dark web services, looking for all the different techniques that identities, accounts, and even vulnerabilities and exploits are being used by threat actors today, easing your best interest. Now, it's not that you go buy a tool that says, hey, all of these people that I've worked for me are on the dark web. It doesn't matter at that point. That's only about 75% of the problem.

The 25% is what are all their personal accounts doing? Because we've seen very successful attacks on people getting into businesses. So the best counter is to think like a threat actor, do more than just that surface scan on the exterior of a pen test. Let pen testers operate with social engineering, with phone calls. Let them call your call center. Give them an image of your daily laptop driver that you give people and see how much damage they can do. Can they break out of the EDR solutions and least privileged solutions and any other web proxy filtering you may do on that endpoint?

Take that extra step because those are the way, those are the techniques that actors are using and saying to a really good pen test company, here's my daily driver that every employee gets. Do your best and see if they can will only help you. And surprisingly, the results will help you with your zero trust model. It'll help you identify the blast radius for accounts. It'll help you cover all of the things we just spoke about if you do it well. So my best counter is strong defense and think like a threat actor.

So you, because pen testing is something that some people think is a bit weird, a bit kind of nerdy and militaristic, shall we say. And I think that's a bit of a shame because it does actually serve a highly useful purpose, but it's just, it's just got an image problem, I think, slightly. It does.

I mean, I spent five years as a CISO. To me, I think we designed with my team an excellent model for the endpoint of five steps of using, you know, EDR, anti-malware reporting, proxying, a lot of different techniques. And then how did we prove that the model that we give to daily users was good enough? And as a CISO, we could have my own guys test it, but let's get someone that's an expert, someone that actually was doing it as a part of a nation state or organized that went, you know, private in terms of business.

And, you know, those results will be quite surprising. You don't have to do it all the time. When you mainly change your images, you go to a new operating system, you deploy a new application, you should always consider those additional tests. But just doing a vulnerability or a port scan on the outside and then running typical commercial tools, that's not good enough for the checkbox. Threat actors are much more creative today, especially if they can call into your help desk or say, hey, please reset my password.

You got to check to make sure that the policies for the end user, the technician, the help desk person sitting on the other side of the phone, always says no to a manual turn off of MFA or something. Yeah.

Well, that is, you know, let's not go there in detail, but that just shows you that all the technology in the world is useless. If at the end of the chain, it depends on a human person. It does. The humans are always a slink.

Yeah, I know. All of what I just described is the testing of the fabric. It's the security aspects of your fabric. With humans, as you point, is our biggest problem still. We are a problem. Yeah.

Well, okay. So that comes, that leads us nicely into the replacement of humans. I'm looking forward to the next Terminator movie. It's good.

AI, which again is a threat and also an ally, or it can be. And I mentioned right at the start that some PAM vendors and some identity vendors are starting to use AI to help with things which are very boring for humans to do, but also can do things much faster. So like log analytics, session management, even picking up variables in human behavior.

So I think that's, we're at the start of all this, but it's got to be, if it's used well, I'm sure that nearly virtually every vendor is going to be using AI in some way to just take away all the donkey work from admins and humans, but also to hopefully reveal new stuff, like new ways of doing workflows that don't work, that the AI can say, yeah, well, this workflow is secure, but it's really, really inefficient. I fully agree with that.

And I think the reason I said earlier, AI has just scratched the surface, is being with a vendor, we're always thinking of new ways, new methods, and every vendor is going to have something. But I read over the weekend, some natural language models being applied to animals. And I just got blown away. A study that was done across a variety of animals found that whales actually call each other by name and have a structured language. Elephants do as well. They actually use some form of name to communicate to each other.

And using AI applied to dog barks, 70% of the time could determine the breed, the age, and male or female, 70% of the time, which I'll take those odds if I'm in a casino. So we don't know the full aspects of AI yet, whether it can be used for just behavioral confidence or anything else is up to our imagination. But AI is doing things today that several years ago would have just been in a children's cartoon. And that's why I do believe we're just scratching the surface because it's going to be creativity and imagination. And look what it just did. I never expected that as the result.

So you're saying that a whale will call another whale by a special name? Google it. You'll find that this one particular study has took thousands of hours of whale song, found that there's a structured language and whales and elephants actually use unique names to contact each other.

I mean, we've long known that elephants are very intelligent, but also emotional, you know, that they feel... Creatures as well. They feel lost, et cetera. This is behavioral now. Things that we would never have considered potentially having traits of individuality, taking AI and applying it to our daily actions, behavioral usage, confidence, all the things we're worried about in terms of attack vectors for the tooling we speak about, I can't tell you where it's going to go yet. I just know that we're just scratching the surface.

Yeah, for sure. Well, I'd like to know what they'd apply it to cats. Can you imagine what cats get up to? Any animal. If we're now talking through AI to animals in the future, we're all going to have new jobs and philosophies on the world.

Well, if we finally find out what our cats are really thinking, it would be a great help. So Murray, slightly off topic, but let's close then with maybe a closing statement or a thought on where PAM is going, where identity is going. Is it an optimistic future? Is it a less confusing one for buyers? What would you predict in the next five years or so? I would predict optimistic. We know what the technology looks like in terms of protecting the most sensitive accounts. We're now worrying about this concept, the pass to privilege and the identity account relationships. We know what we need to do.

It's getting there that's going to be tricky because we still have our legacy systems. They're not going away. We have our modern cloud systems that are representing new challenges. I'm optimistic that we know how to tackle them, but the maturity has got to be pushed down to all organizations worldwide to recognize the threats and to be able to counter them. So that just like vulnerabilities and exploits, we scan, we patch, we walk away. Most companies do that fairly well today. We think of identity-based attack vectors in the same context.

BeyondTrust being a leader in identity security helps with these techniques. As for myself, I am the chief security advisor. I've been with the organization over 20 years, multiple books, including Identity Attack Vectors as a book, helping streamline or discuss these topics today.

But Bob, overall, optimistic. I don't see any doom and gloom. I just think we got to get better. Okay.

Well, I've got a copy of your book right here, but I can't reach it to show people. I appreciate that, but thank you.

So anyway, I really hope that you watching this have got something out of it and enjoyed our chats, even if we wandered off a little bit into slightly strange areas. I will put the results of the poll on my LinkedIn page. So if any of you follow me or you can find me on LinkedIn, then at least we can see what the results are. And I'll copy you in on that, Morrie, and then maybe we could just have an online chat about it.

And also, as I also said right at the start, that this whole conversation is recorded and will be available on the Copenhagen website very shortly. But with that, thanks again, Morrie. I really appreciate your time today. Thank you also for listening in. Thank you to my backroom team, Oscar, for keeping us live. And with that, I wish you all a very good evening or good morning, wherever you are.

Paul, thank you. Pleasure is always speaking with you.

Take care, everyone. Be safe.