Closing the Gaps in Zero Trust

Hello everyone. Welcome to the webinar, Closing the Gaps in Zero Trust. My name is Alejandro Leal. I'm a Senior Analyst at KuppingerCole and today I have with me Alex Coco. He is the Global Solutions Architect at Veridium and he will be joining me in this webinar today. How are you, Alex?

Very well, Alejandro. Thank you for asking. How are you?

Good, thanks. Looking forward to your part of the presentation and then we'll have some time for Q&A, so I encourage the audience to to enter some questions, and we'll be ready for them.

All right, so before we begin, I would like to quickly remind the audience of a few things. So yeah, all of you are muted. There's no reason to mute or unmute yourself. Maybe Alex, could you unmute yourself just to make sure that there are no sounds.

Okay, now you're unmuted. Good. But we can see you now.

Okay, perfect. So we'll also be conducting a few poll questions, so please answer those and then if we have time, we'll...

Alex, I believe you're still unmuted. You're not muted.

Okay, now you are. And we will be recording the webinar, so in the next few days, make sure to check our website if you want to see it again, or if you want to check out the slides and the content of the webinar.

So, here's the agenda for today. I will be introducing the topic, then I will be talking about why identity is the new frontier. Then Alex will jump in and he will talk about his approach to closing the gaps of zero trust, and then we'll have some time for Q&A. So please make sure to enter questions.

So, I'd like to start with, let's say, a reminder with this quote that cyber security is ultimately about protecting people, because that is the backbone and behind our technology. So, every firewall, every policy, every authentication factor exists to protect individuals who make our organizations work.

Today, when we see the news, we see that there are data breaches or attacks on critical infrastructure. Again, we are trying to protect people. People are not just users. They are the new endpoints, let's say. In this webinar, we will look at how we can bridge the gap between strategy and reality.

So, we'll explore first the misconceptions around zero trust. Then we'll try to understand how ITDR, Identity Threat Detection and Response, how it reinforces both identity and access management strategies and the SOC, so security operations. And we'll try to remind the audience that it's about protecting the human endpoint. And I know that Alex will talk more about that after my part of the presentation.

So, just a reminder, let's start with zero trust. Despite the marketing that we see when we attend conferences or any workshops, in reality, there's no zero trust in a box. Zero trust is not a product. You cannot just simply buy it and instantly modernize your enterprise. But zero trust is more of a strategic goal. It's a mindset. It's a philosophy. And the basis and the foundation is that you have to assume that you will get bridged and that you have to verify continuously. For example, today we published our latest research on ITDR.

So, if you go to our website, you will find the leadership compass on ITDR. It took a few months to create it and to publish it.

So, it's based on the latest research. And I will talk more about the report later on. But it was interesting to see that during the research process, when I was talking to vendors, most of them would focus a lot on how they prevent identity-based attacks.

So, they focus a lot on the preventative side. And in the slides, I wouldn't see much on response and remediation.

So, I would ask them about that. Like, what are your response capabilities? What can you do if an organization gets bridged? Because I like that organizations have that mindset. You will get bridged. And I think that's a crucial aspect of zero trust. And of course, different organizations have a different path to reach zero trust. Some may begin first with identity and access management. Others with network cementation or device posture.

So, there are different ways of approaching it. But the point is that, and again, a reminder, zero trust cannot be achieved through one tool, but more of a collection of complementary technologies that work well together and they have also well-assigned policies around.

So, next time that you hear vendors selling zero trust solutions, just remember what they're selling is a building block. The strategy itself must come from you. And that's why at Coupling Your Goal, we developed what we call the 5 plus 2 approach, which is mostly based on the US Department of Defense zero trust maturity model. Essentially, the 5 plus 2 approach is a practical framework to help organizations assess their maturity level.

So, if we see here, there are five core pillars, which is users, devices, networks, applications, and systems, and data. These all represent key dimensions which zero trust initiatives must address. But we also added two other pillars. One is visibility and analytics, and the other one is automation and orchestration. We decided to add these last two because without visibility, you cannot really measure risk. And without automation, you cannot really scale your defenses.

So, the 5 plus 2 model gives you a way to benchmark where you are to identify the gaps that you currently have. And it can also help you to plan for improvements, not just in technology, but also in operations and governance.

So, in reality, it's not really about just checking boxes, but it's about evolving towards cybersecurity resilience. So, it's important to think about your zero trust use cases first, and then prioritize them. Describe them well, and you also need to keep the future in mind. You have to stay up to date to the latest developments.

Right now, we see a lot of talk on protecting machine identities, Q-day, you know, post-quantum authentication. So, you must maintain your strategy to be future-proof.

So, if you have these things in mind, then you can assess your maturity level, and then you can move forward and start implementing step-by-step in small projects as part of the zero trust program that your organization will implement. But another thing, another important thing to keep in mind is the identity fabric.

So, the Kuping Equal Identity Fabric is our vision for a modern unified identity and access management architecture. So, again, it's not a single product or a platform, but a strategy. And this approach, I think, recognizes that most enterprises live in a hybrid reality. Many organizations still rely on legacy systems.

So, you don't have to rip and replace, but you can build an adaptive identity fabric that is evolving with your organization. So, it's about orchestration, interoperability, and continuous alignment with business needs.

So, the identity fabric can help you leverage what you already have by integrating legacy systems with modern cloud-based services. And at the same time, it allows you to integrate new tools, new technologies at your own pace. But as I said, I think my, okay, here we are. Yeah.

So, as I said, most organizations today, they have silos, the operating silos mostly have loosely coupled tools rather than an integrated ecosystem. So, you can have your separate PAM, IGA, SSO, MFA, often with limited communication between them. And this fragmentation can slow down response times. It can also increase administrative burdens. It can also leave more attack gaps.

So, to truly achieve zero trust, we need to move beyond tool-based thinking and more with this identity fabric way of thinking. So, the identity fabric can provide this glue which can enable unified disability, policy enforcement, and risk assessments across your identity stack.

So, now we have the first poll question, and that is, how is your identity and access management infrastructure implemented? Is it already converged in a suit or more of an orchestration of multiple tools? Or do you have more of a fragmented stack?

So, now we'll move to the second part of the webinar where we'll talk more about how identity is this new frontier. So, we know that the perimeter has dissolved, right? It's no longer your firewall, but it's your people, especially now with Gen AI and more sophisticated threats. I think that organizations are realizing that the real endpoint is the human being using it. We see a lot of social engineering attacks, deep fakes.

So, ultimately, these new attacks are trying to trick people. And if we look at traditional serial trust and IAM models, they tend to be more focused on securing devices, logins. But as I said, attackers nowadays are exploiting behavior, context, and relationships and trust because now if you've been paying attention to the news, there are cases of deep fakes and people making transactions because they got tricked, because they thought the boss was asking them to make some sensitive transaction or sharing important information.

And I think that's where identity threat detection and response comes in because it extends protection into the realm of user behavior. And in the cybersecurity industry for many years, we often hear that humans are the weakest link. But I would like to reframe that and say that humans are the most targeted link. But with the right training and with the right tools, organizations can improve security. So it's also about maybe changing the mindset of always blaming humans, blaming the the intern because he or she has weak passwords.

But it's more about having a stronger cybersecurity culture within the organization as well as having the right tools that will help humans increase security. So I think that the future is more about empowering humans, not blaming them. So if we look at how to close the gaps in serial trust, in hybrid environments, let's say with local active directory and other cloud directories, authentication must be consistent and unified. One of the most exciting developments is the shared signals framework, which allows threat information to flow between different systems.

And that also provides real-time risk sharing. And that's where ITDR becomes essential because ITDR connects both the identity teams and the security teams. It sort of bridges that gap. And by treating the human endpoint, let's say as a source of continuous telemetry, organizations can dynamically adapt trust decisions. So it's interesting to see, for example, in the ITDR report that was just published, and you can, if you have a account with us, you can take a look at the results, the leaders, and check out all the information there.

You will see that we're slowly seeing more vendors having more integrations. In the report from two years ago, there were still some limitations with ITSM systems, SOAR, SIEM, but these days we see more vendors understanding that being able to provide as much context as possible is what makes ITDR special.

So, again, what is ITDR and what does it do? In a way, we can see that ITDR collects telemetry across the enterprise. So from identity systems to endpoints to cloud services, and the goal is to prevent identity-based attacks, privilege abuse, and lateral movements. So you can also correlate events, you can visualize attack paths, and you can also automate responses, such as terminating a session or disabling compromised accounts or enforcing MFA. So some of the things that we found out in the research is that many ITDR vendors come from very different backgrounds.

Some are well-known PAM vendors, others focus more on the visibility side of things. So vendors vary in maturity, in integrations, and in scalability.

So that, in a way, made us realize that ITDR is more of a discipline than, let's say, just a product. So another interesting thing that we discovered is that many vendors are also developing sort of like deception technologies, like hunting tokens for early detection. I believe Alex will talk about that later on, but it's one of the innovative things that we saw.

So yeah, if you're a Coupang.org member, you can access the full report, so make sure to check that out. When we think about the primary activities of ITDR, we could say that it all starts first with identity hygiene. So you need to start discovering all the user and system accounts. You need to, you know, assign owners, remove abandoned accounts, and it's about continuously assessing risks, monitoring events, and trying to minimize false positives. And in the next phase, you can see that in a way, it's about monitoring.

So watching for unusual authentication patterns, privilege escalations, or impossible travel scenarios. So you can think of ITDR as an identity raider, and also as your response engine. So this will allow your identity signals to not get lost in the noise of your security operations, because in many ways, one of the goals of ITDR is to reduce false positives. I know I'm running out of time, so I'm going to go briefly on this.

So we know that traditional SOC tools like SIEM, SORA, and XDR are excellent tools for aggregating events and orchestrating responses, but many of them lack the identity context, and that was a problem that identity and security teams wouldn't really communicate with each other. So ITDR is supposed to bridge the gap, and it's supposed to feed identity intelligence into the SOC stack. So ITDR provides, in a way, the who behind the what. More findings from our report. So we see that many of the vendors have different strategic approaches on how to do ITDR.

As I said, it's more of a discipline than just a product. So many of them have different backgrounds on how they started to do ITDR in the first place. So that's why the Leadership Compass Report is a good tool to assess which of the vendors is more suitable for your own organization. So in a way, we can close with a practical path forward. It's important to assess the current state of your organization and identify gaps. So as I said earlier, what are your serial trust use cases and priorities? And you need to know where your risks are. And it's also about prioritizing assets and data.

So the ones that matter the most. And integrating identity and privilege access controls, because they form the heart of serial trust. It's about continuous security posture. It's about continuously assessing your own organization. And serial trust and ITDR, if you probably got this during the webinar, these are not destinations per se, but these are journeys. And like any journey, the key is to move forward with awareness, collaboration, and understanding. Understanding that security, at its essence, is about protecting people.

So it'd be interesting to know in the next poll question, what are your plans for ITDR? Are you already implementing it? Are you in the process of doing so? Or are you considering it? Or you haven't already? So this is a question that I would like to talk to Alex later on at the end, just to see the responses from the members of the audience. Because ITDR, just a few years ago, it was something sort of new. Some people didn't really know how to call it. And I wouldn't say that the market is mature. We still see new vendors that are merging, that cover very niche areas.

Vendors that are stronger in certain geographical regions of the world. So I think it's a dynamic market, and I expect to see more movement, more momentum, and even some acquisitions. So with that said, Alex, I would like to give you the floor.

Thank you, Alejandro. That was really an excellent overview of the Identity Threat Detection and Response phase. So I'm going to spend a little time talking about how we at Iridium are approaching this particular aspect of cybersecurity. Because at its heart, we're trying to prevent fraud. We're trying to prevent user impersonation from adversaries posing as legitimate users, getting access to systems where they can exfiltrate data or otherwise execute transactions that are harmful to the organization.

And so we talk very much about the human endpoint security and making sure that the person at the end of every transaction is the person that's authorized to perform that transaction. And we do this by getting involved directly with the user credentialing and authentication of that user. We felt that that was the most powerful position for us to view and collect actual human behavior and the way that the person at the end of the transaction is interacting with the device so that you get a level of visibility down to the actual person in any suspicious transaction.

And then through shared signals, we're making sure that we are tied into the rest of the security landscape of the organization so that we have that data sharing to look at the larger picture of what a threat might be and how it may be developing over the course of penetrating your environment and lateral movement so that you can stop those adversaries before they reach their final goal. But we look at this firstly in terms of the techniques that these adversaries are using for impersonating the user.

And we look at this through the MITRE ATT&CK framework specifically, the credential access tactics. Now MITRE classifies these in about seven categories, but I think you can distill them down to four general areas where adversaries are coming after user identities and attempting to impersonate those users. And I always start by talking about the password attacks. The best thing that you can do in your organization is to remove passwords wherever possible and where it's not possible to improve any counter measures that you can add against of impersonation through a password attack.

And so by providing passwordless credentials, and in particular, we feel that biometrics play a strong role here in not only removing the password, but giving you a level of identity verification that goes beyond possession of a cryptographic key. At the end of the day, one-time passcode tokens, as well as modern WebAuthn passkeys, are more about possessing a physical device that has a cryptographic signature to it than they are about matching an individual person. Even when we look at a biometric-protected FIDO passkey, we don't have control over that biometric.

It is controlled at the endpoint, and users can do stupid things, or they can leave it in a position where someone else could enroll their biometrics. Then that's, you know, either as an adversary or even a collusive type attack. So adding not only biometrics, but biometrics that you can control centrally gives a level of control and visibility into the actual person.

Now, there are some privacy issues, and it's something that doesn't work in every jurisdiction, but where it's possible, we highly encourage using those additional layers of security to do things like verify the identity of a user who's contacting helpdesk and prevent the types of social engineering attacks where the helpdesk can be fooled and enroll a strong credential to an imposter. Now, beyond those pure credential-based attacks, you know, we see a lot of adversary in the middle, imposter sites, ways that users can be fooled into giving up their credentials.

Having phishing-resistant credentials like a FIDO passkey helps here, but we also layer in our human behavior analytics, where we're not just looking at the session behavior and the device behavior, but the actual human behavior. We have a passive biometric technique that we can use for mobile devices and desktops to measure that user's physical behavior, the way that they interact with the device, and give you a confidence score that that user is the same user that has been using that device consistently over the period of time where we collect a sample size.

And so we get a much higher level of assurance that it is the right person who is at the end of that transaction, who started the session and has stayed in the session, and it isn't someone else who has otherwise hijacked the session or sat down at their desk when they got up to get a cup of tea. These are the things that we can pick up with the human behavior analytics, and then that also goes along with strong user device and session binding.

And we do that internally as well as rely on the overall security architecture of things like Zero Trust Network Access or traditional VPN, and just plain old secure web protocols to make sure that we have the right connection that is authenticated to both ends and part of that Zero Trust posture across the organization. But we bring all of this together with AI-powered policy orchestration, and what that gives us is this flexible flow chart style policy where we can define prescriptive combinations of access risk and the credentials that a user must have given that risk.

And so I have three just sort of general examples here of when we're in the office, we're on a wired network, we can just ask for plain old Windows hello and a pin, the user gets in and they go about their business day. Now our continuous monitoring is still there at the desktop, watching that user's behavior, polling on a regular basis, and we can lock the session if we see something unusual even here at the office. That same user takes their laptop home, we can now look at a different set of credentials that are more powerful.

We can look at that centrally controlled biometric if we feel that that's warranted for the risk. And we can dynamically decide what's risky and what's not risky. If they're a normal work from home type user and they're logging in at nine in the morning and leaving at the end of the day and they're logging into their usual set of applications, we could scale the requirements down for that user to only use hello again and treat them more like they're in the office.

But as soon as they're doing something after hours or they're going to a highly risky or sensitive resource, we can step up that authentication in a dynamic way. We can also put the user to a dead end. So if we do through the collection of data that we have determined that this particular session has an behind it, not an authorized user, but some adversary, and that could be an AI adversary. An AI adversary is going to look very different from a behavioral standpoint than a legitimate human user. And we can send that user down a dead end where there is no accepted authentication.

And in that way we can continue to prompt that adversary in a honeypot style through authentication. So by injecting ourselves into the user authentication and credentialing process, we're in a very unique position to watch for and detect imposters and adversaries and put them down policy paths that do not let them in, that are only there for the collection of additional intelligence on this adversary. And that's part of the deep observability that we provide with every interaction that we're performing through the authentication process.

We also have the ability to pull in external threat data in each of these decision points in our policy tree. So I can reach out to an endpoint security tool and find out, oh, is the endpoint this user coming from having any indicators of compromise?

If so, I can once again either put them into a more stringent authentication profile or put them down a honeypot path that says, look, I think your endpoints compromised. I don't know if it's you or malware doing what you're doing, but I don't want to let you in. I'll put you down a path that is frustrating, but it's frustrating because there's a high degree of suspicion that this is an adversary and it's unauthorized access.

And so that's how we approach this notion of identity threat detection and response at runtime, when a user is authenticating and attempting to gain access to a system, as well as watching that session over time. But credentialing and the initial enrollment and lifecycle of the credential is perhaps even more important, because this is where the adversaries are going lately. They're finding ways to get a credential enrolled as though they were a legitimate user and impersonating that user with what appears to be a strong credential.

But the credential is only as strong as the protections that you put into those lifecycle events and making sure that the enrollment policies and the validation of the user is sufficient every time. So not just when you first onboard them, but for every time there's a help desk event and that user or an imposter attempting to impersonate that user wants to get a new credential enrolled. This is what we've seen several times over in recent events. And so one of the things that we've done is enhanced authenticators.

So these are the types of authenticators that we see in most of the existing authentication solutions. We support all of them and we make it easy for the policy to allow for those traditional style authenticators for the use cases and the risk profiles where they are warranted. But we also layer in our own enhanced authenticators. One of my favorites is this roaming facial biometrics because where we can, again there are jurisdictions where keeping biometric profiles is less attractive than others.

But where we can, this means we have a credential of last resort and that user who might be attempting to socially engineer your help desk can be directed to a link to match against the profile that they enrolled when they enrolled their initial set of credentials. And now that help desk operator can see this is more likely the correct person to now either issue a re-enrollment for or perhaps an emergency you know passcode for them to have access and it really helps prevent those types of social engineering attacks against the help desk and support personnel.

Then when we look at our contactless face and fingerprint biometrics, this gives us a way to have robust biometrics in cases where we might not have a very robust device in the first place. Our technology is able to standard HD cameras for facial biometrics and for fingerprint biometrics, all we need is a 5 megapixel camera and an assistive light. So they're fairly low requirements where we can use older or perhaps off-brand mobile devices, but still have robust biometrics for those users.

And this is common where we have situations that we want the user to have a smartphone, they don't want to bring their own device for that, we can find ways to use lower cost devices that can be issued just as authenticators if biometrics and more importantly our behavioral or passive biometrics are of interest because as long as we have a gyroscope or an accelerometer on the device, we will generate a human behavior profile, something I like to call digital body language.

So this level of enhancement to the authenticator allows us to really compare the way that that person interacts with that device during authentication and build a profile over the history of their authentication as to what is normal human behavior when they pick up the phone, what angle do they have it at, how do they type their in their pin or what angle they generally hold it when they are doing a face ID. Those measurements are taken and they build a profile over time where we can have a confidence score that becomes part of that flow chart decision tree in our policy engine.

And so we can use it to make decisions. We can also use it strictly as an indicator of compromise for the external security infrastructure to use as a point of correlation. And so we give all of these additional AI enhanced authentication tools to really help for the use cases where these traditional methods just fall short and they don't give you that deep observability into the actual person at the end of a transaction because these tend to stop at the device later. So I do like to talk a little bit. I know I'm running short on time as well.

One of the things that we've done very well at Viridium is build a enrollment workflow engine that is automatable where we can take a REST call to kick the process off. That process will have a defined policy of what credentials the user can enroll and it will generate a one-time enrollment code. It's really not one time. It's time and event bounded.

So you can create an enrollment code that says for the next 10 minutes this user is allowed to enroll three credentials and those credentials are a mobile device with our proprietary biometrics, a passkey, and another FIDO key that has to be on a security key. And so we give that very prescriptive enrollment policy that we can deliver in many ways. Out-of-the-box, SMS, and email delivery come standard.

But we could also do delivery through some other automated process using REST or through a CSV export and it allows us to deliver these time and event bounded enrollment codes in whatever secure manner is most appealing to your overall business process. We're giving organizations the tools to establish these credentials as securely as possible. We can use the REST calls here to build a kiosk in a security office and that's where the most secure credentials get enrolled. While at the same time we can print off QR codes for rank-and-file manufacturing employees.

They'll be handed out by their supervisor to then, you know, enroll, bring your own device style, authenticate. These are the different things that we can do to be flexible but still providing that breadth of authentication options and that ability to tailor where you need the most stringent, not only credentials, but assurance behind the enrollment of those credentials. Then the other side of this is after we get the user enrolled and they are now logging in with those credentials and we're looking at really the shared signals framework. ITDR isn't a single solution.

It is a practice within the larger organization. We can provide a large piece of that through this depth of observability and the strength of our credentials as well as our ability to participate in this larger data exchange throughout the organization. And so that gives us a unique set of capabilities for organizations that need these stronger credentials and stronger protections to really prevent the types of impersonation attacks and attacks against identities that we're seeing in the modern technical environments. And I think with that I am just about out of time. Alejandro?

Yes, unless you want to take another slide. So there is one larger one to give the overall flow of how we're tying in this data exchange, the larger security organization, and just what a user experiences when they attempt to log in and they initiate their user session. Once they do that, this is where we are figuring out what credentials should apply to this session and what data we should collect.

Assuming that that goes out to a mobile device where we're collecting the most data of what that human is actually doing with their phone during authentication, then all of that data comes back in for processing where we can combine our anomaly detection, our risk scoring capabilities, with any external data feeds to make our final decisions. And again, it's also iterative. When we look at that flow chart style, we can actually have several steps that sort of repeat between five and six if necessary.

If we need to step them up to a second or a third credential, if that's what we want to do to make sure that they're the right user, or if we do want to send them down that dead-end honeypot path, they will continue to get prompts, but it's actually not going anywhere. It's just for our benefit to collect more information about that adversary.

So yes, that was the last slide. Thank you Alejandro. Thank you so much, Alex, for your presentation. I think you did a really good job describing the importance of building user profiles over time and taking a look at all the past behavior, the content, etc. And also the importance of this bi-directional exchange with the SOC. So thank you for your presentation.

Now, we'll just go over a few slides from my side and then we'll jump into the questions. So back to my presentation here, I have another poll question. So how should ITDR functionality be implemented? You should see this on the screen. So feel free to answer this question, but on a different note, we have related research on this topic, on what Alex talked about on the topic of this webinar. So we have plenty of content on ITDR and on the importance of having this signal-driven fabric.

also, we will have a lot of sessions next year at our conference in Berlin on identity. Here's more information on our services, webinars, research, and advisory. And there's also, there was, I think, a slide on the membership program, but if you plan to attend EIC, for example, and you're a member, you can get a free ticket, access to research, and you can also get some discounts. So if you have any questions on the membership program or the ITDR report that we published today, just feel free to reach out to me and we can talk about that.

So Alex, we have some questions from the audience. We can start maybe with a question about your if the question here is saying, can you share case studies or successful case studies or references of large deployments? So in this forum, no, but absolutely. We have had successes in the field.

Today, we have a deployment of up to 150,000 users using the features that I explained during my presentation. Great. Another question is around passwordless, can you give us maybe an estimate on the percentage of your customers that have adopted passwordless? How many of them have adopted Passkeys? So the majority of our customers implement us first for passwordless access to the desktop, and where we do passwordless access to the desktop, we can use a combination of Passkeys or certificates for the user access.

So we're very flexible when it comes to being passwordless at the desktop and in other applications. There are a few, I would say it's about 10% that have policies that require password plus MFA and we can do that too with our platform. So where we have to use the password, it's absolutely a possibility to configure that in that policy. But for most of our customers, they have implemented us to be passwordless at the desktop and then passwordless everywhere else that it is possible. There are some legacy applications where we're also tied to using a password.

Often what we'll do in those cases is create a secure web proxy where we can apply passwordless at the proxy and then get to the application using cache credentials. We, however, do not cache credentials at all in our platform. It's one of the things that we have chosen very strongly to avoid. So we do no password management and all access is tied back to a cryptographic key, typically on a certificate of some kind when it comes to the desktop access.

I see, that makes sense. It seems like you guys can address this in multiple ways depending on the needs of your customer. There's another question on credential lifecycle. So this user is asking that, I am not an expert in this field. So what are credential lifecycle events? So just like the identity lifecycle events, so the identity governance vendors have covered this very well where you onboard a new user, you get them accounts into your appropriate platforms, and then typically you have to assign credentials. Now the IGA vendors tend to stop there.

They'll send you off to some password reset portal to set your password. We can take over at that point and just like the identity lifecycle events of creating the account, creating the access profile, we can now decide what credentials the users need, how those users will enroll them, how their identities are verified during enrollment, and then after that operationally, we continue to monitor those credentials so that we know are they being used, where are they being used, are there credentials that are languishing that should be removed from the system?

When a credential is lost, how do we make sure that the user contacting the help desk is the right user before we reissue a new credential? These are those credential lifecycle events that are critical to maintaining a very strong security posture and preventing user impersonation.

You know, a passkey that's sitting on a YubiKey that is forgotten in an airport lounge can be a very devastating credential. That could be picked up by an adversary who knows where it is acceptable. The touch point on that key is not a fingerprint sensor in many cases. And without some additional layers of protection to look at who that user is and are they an imposter, you have a high risk of user impersonation and fraudulent access.

So that's just one example of how a passkey, a passwordless credential that is considered very strong, if left in a compromising position, can lead to user impersonation. And these are the types of scenarios where we're providing additional layers of protection to prevent that unauthorized and fraudulent access.

But again, it's about those lifecycle events. You know, the loss of the token is an event in the lifecycle of that token. And how we detect that that's occurred and respond to it is just as important as when the user who lost it contacts the help desk and says, I lost my YubiKey. I need to enroll a new one. So those are the different events that can occur in the lifecycle of the credential. The final one always being revocation.

We always want to make sure that when we are done with that credential, whether that's because we don't want to use it anymore or because that user account is no longer active anymore, we want to make sure that all of those credentials are safely removed and can't be used by an imposter later on. So those are the different lifecycle events in a credential.

And again, we provide a platform with capabilities to help manage all of those credential events. Awesome. Thank you for sharing, Alex. The next question is saying thank you for today's session. How does Veridium differentiate itself in the crowded identity slash authentication slash passwordless market? It is very crowded right now.

Where we, again, where we focus on is on the observability and the ways in which we can enhance the protections around the actual human user. We're also a solution that is meant to be deployed to the customer environment. So we divorce ourselves from cloud platforms largely and give you tighter controls around your credentials with real-time data about how they are being used. And that's very different than many of our competitors who have continued to say that this is something that they want from a SaaS service.

And what our experience has been is when we try and put the level of control that we have and particularly the kinds of data that we're collecting on the end user, it's not germane to be done through a SaaS service. It's much better when we can do it within your environment where you have complete control of the data and we can share that data through shared signals in real time. So we've attacked the problem in a way that is very different than our competitors. It's also a little market disruptive.

I've approached a lot of customers about how we're doing this and they'd say, well, we would prefer if you were a SaaS service. And I have to go through the different layers of what we're doing and why being a SaaS service just doesn't work for how we're approaching this particular problem to give you the types of controls and countermeasures that we're able to.

Yeah, that's a pretty unique approach and I think I agree with you on the visibility part. It's something that I mentioned in my part of the presentation that without visibility, there's really just gaps left and it's key in this field.

Now, I think we have maybe a few minutes just to talk about briefly the poll questions. So if we go to the first poll question, how is your identity and access management infrastructure implemented? We had 50 percent and 50 percent. 50 percent said they have multiple solutions, a little bit fragmented, and the other one is converged. So it seems like there's still some work to do there. Any thoughts on that? Surprised? It doesn't surprise me. The various organizations I've interacted with, I hear a lot of, well, we have converged on Okta or Microsoft or some other IAM vendor.

And the conversation I often have is, you know, where is their credentialing working and where is it a challenge for you? And sometimes what we will do is we will address the challenging use cases while letting both of the users remain in that converged IAM solution. Sometimes that makes sense because we can be a solution that is focused on the higher value targets in the organization.

However, it's been my experience over time as they see the benefits, they will move more of their credentialing into our platform as they see, you know, the level of control and visibility that we have over what you're getting from those converged platforms. I see.

Yeah, it makes sense. Next question because we're running out of time. What are your plans for ITDR? It seems like 43% of the members that answered this question, they are still considering or planning. 29% no plans yet. Only 14% have already deployed ITDR and another 14% are in implementation process. So we have more than half around almost 70% saying that they haven't implemented ITDR yet.

And as I said during the webinar, it's something that we've seen recently being more out there, more popular, but of course, it's going to take time and organizations are still not ready to fully maybe they don't know how to start, but that's why we're having webinars like this to educate the market and advise organizations on how to implement it. But do you have anything to say on that?

Well, the numbers aren't surprising. I think that there's still a large portion of organizations that are still trying to get their hands around that initial cataloging problem and the overall governance of their identities. And you pointed that, you pointed to that, you know, early on is that's foundational to identity security.

So until more organizations are at that point where they have those kinds of governance controls around identities, going deeper into the observability and the detection of imposters in their environment is it's almost secondary because they don't know what they don't know yet. They don't know where the threats could be coming from. They don't even know where to look.

So, you know, and so identity practices have to mature over time. I do think there's some good partners out there that can help organizations jumpstart things so there's ways that if you are behind a little bit or feeling like you're exposed to identity threats that you can find the expertise to help get a program started rather quickly. But for now, I think most, there's a large portion of organizations that are still struggling with the governance and that very initial just cataloging issue. Absolutely. And the final question was how should ITDR functionality be implemented?

60% of the audience said that it's built, it should be built into identity and access management while 20% said it should be a standalone product and the other 20% said it should be a feature of attack surface management. Well, as you know, our approach is that if we look at the concept of identity fabric, it doesn't really mean that you need to adopt a particular solution to have ITDR, right? So it's about really looking at what you have already and what you can integrate, what you can implement again or on top of that to be able to have these functionalities. But what's your take on that?

Well, I mean, we've taken a very strong approach that the core of identity threat detection is in the authentication of the user, which is largely considered a feature of IAM. we're not, we're also not in the business of trying to replace large-scale single sign-on deployments.

We will work in cooperation with an Entra or an Okta or a Ping Forge Rock type environment where our goal is by being the credential provider and having those tight controls over the credential life cycle, as well as the use of those credentials and the observability, the data that we can collect when they're being used for login, gives us a very healthy piece of what a good ITDR practice would be for security. But it's still not everything.

There's still data that's going to come in through security operations, through, you know, even application logs that will be germane to detecting impostors. And so that's why we also always talk about that, those shared signal framework and that ability to exchange data with the larger security enterprise. Last question for you, Alex. If you had, let's say, 30 seconds to say something to a CISO on this topic, what would you say?

Well, I would ask them how do they know that their users are not being impersonated, and what sort of data do they have to back up that faith? Because I think that when they really start to dig into user impersonation scenarios, they'll find that there is an overabundance of confidence relative to the actual processes and technical controls in place. So that's usually where I go when I'm talking with higher level executives is, you know, again, what's the threat of impersonation? How do you know that there aren't impostors in your network?

Because people are finding them all the time now, and it's a very prolific problem. That's a good way to break the ice. On that note, I will conclude the webinar now. Thank you so much, Alex, for joining. It was a very fruitful conversation. I really liked your presentation, and if anyone has any questions, feel free to reach out to Alex or to me. Thank you. Take care.