All right, let's go ahead and get started. Thank you for joining us. My name is Dieter Schuller. I've been doing identity and access management for way too long, and I've seen the industry change quite a bit. One of the things that I found interesting, especially over the last couple of years in these conferences, is that people believe that, for the most part, organizations have solved the authentication problem, and they're now on to more important things or better things, right?
Centralized authorization, threat detection, identity security, posture management, visibility into the environment, and all those things are important. But what I have seen, and one of the reasons that I'm really starting to get excited about this topic, is that over the last couple of years, and especially in the last year, hackers have found new ways to get back into the authentication issue. And for the most part, we believe that companies are doing the right thing.
But the user is the primary reason that organizations are not more phishing-resistant and that they're not doing a better job of managing sessions. And I think the reason for that is because everything that we're trying to do for the user makes it incumbent upon them to take action before they can become completely secure. So what we'd like to talk about, and I want to introduce Prem Cherkavich and Ricardo Martins. What we'd like to talk about for the next hour, hour and a half, is continuous authentication and the importance of managing these sessions and these phishing attacks.
So with that, I'll turn it over first to Prem. Prem will introduce the topic, and we'll go from there.
Great, thank you, Dieter. Hello, and the title of this session is a bit of a mouthful. It's the one-day fix for phishing-resistant customers, partners, and colleagues that, just for Pete's sake, can't be bothered to adopt secure authentication practices that you guys put in front of them and invest money and your time in. And that's, as Dieter mentioned, that's one of the key things that we will try to tackle over the next 90 minutes. So I'm pretty sure you're going to love this session, because we're going to be validating that most of what you're doing right now is right.
It's just the user who's the problem, but the responsibility is still yours, unfortunately. So we're going to try and give you very pragmatic tools, including ours, but also a broader perspective on how to tackle this problem. How to tackle the fact that right now, no matter what kind of technology stack you have, it is almost impossible for you to get everyone phishing-resistant, let alone session-hijacking-resistant. And I'm going to speak first for about 30 minutes or so about... By the way, guys, on the technical side, I see there's a clock here. Could we turn the clock on just so I...
Yeah, thank you. And then we're going to have Ricardo join me to speak about the broader perspective and how they tackle that from a very practical standpoint. But before we go there, let's quickly talk about the problem.
You will, guys, see multiple versions of it both at this conference and if you go to other analyst events, you will see multiple versions of this slide. There's the same story basically telling you that the bar for what can be considered phishing-resistant right now is way higher than it used to be two years ago or even a year ago. And there is one very simple reason for that, or actually two. The first reason is still theft of credentials and attacks like stolen session tokens are still some of the most common vectors of initial access for successful data breaches.
So that's a problem we haven't solved yet. But then there's a new problem. That is how the phishing attacks have evolved over the last two years, over the last year. We have seen very advanced phishing toolkits emerge and we've seen them get commoditized.
Right now, if you have a hundred bucks on you, you can become a hacker, right? I'm a business founder and I think even I could do it at this point, right?
It's just, it becomes very easy for people to come between your users and your applications and pretend that they are a legitimate user. And we all know here that if an attack comes from what seemingly is a legitimate user, it is incredibly difficult to discover. And right now, I don't know how many of you are familiar with the modern phishing toolkits. Probably some of you are. It is scary what's been happening.
Right now, you know, the old adversary in the middle is not the same adversary in the middle we have right now. Right now, we have fully functional browsers sitting in between your user and your application that can modify the entire flow of information between the user and the application. And the user, which in practice means that even if I have something like passkeys, but my user is still using password as a default option, it doesn't matter.
It doesn't make them any more secure because the attacker can modify the flow of authentication, right, to downgrade that or to not even display passkeys. And if you think about the workforce, that's where you have the most tools right now to address these problems. If you look at a different... And probably there are some colleagues here who are working on these tools. And if you put together the right package of a software, you can make most of your workforce phishing resistant. But there's another problem. What are the barriers together for everyone? And the barriers are very pragmatic.
If you think about, like, if I asked you here right now, what would you need to do to get your users to phishing resistance, we could probably, among us, like, figure out a pretty straightforward, albeit costly, way to do it. The thing is, this is for the devices that you control internally.
Now, you have, or you may be managing identity for organizations that are far more complex than that when you think about your day-to-day business, right? You may have a bunch of customers. You may have a bunch of partners. You may have franchisees that need access to your critical applications. You may have a very complex supply chain. And you may have your supply chain colleagues telling you, hey, there's money on the table.
Like, if we do integration end-to-end across the entire supply chain, there's a huge bid potential. And could we set up all of these people with access to our applications? And then you may end up telling them, why don't we just set up a public API for this? Because if we give them passwords, we might as well, right? So you may end up working on these problems in multiple different ways that we're going to discuss a bit more in depth. And these are the three typical use cases for where we believe passive authentication could be a solution.
So yeah, the question is, what do we do now? If there is not a lot we can do, what do we do?
We, Relog, we propose that we adopt something that we call continuous passive authentication. Passive authentication is not another password that we invented. It has been used before for a general approach that is also something that's called ITDR, right? There's access posture management. It's basically whatever you can do without the user interacting directly with the application, without user's action. How can you make the user more secure without them having to adopt something, without them having to go through the friction of an action that they need to take, right?
Because that's where most of the problem with strong MFA is right now. The solution that we have for that is a pretty elegant piece of software. It is something that if we boil it down a lot, it's like a lightweight identity for the browser. So we verify the device that the user is coming from at every single request that they make to the application. Because let's not kid ourselves here. You're not and we're not in the business of protecting users. We are in fact in the business of protecting applications.
And if you think about most of the attacks that we face, they happen because we don't know if it's the stolen credentials, the stolen session token, if the bypassed MFA is coming from a trusted device. Now quickly about how it works before we go a bit deeper in the use cases. Here you can see a very simple schematic for what Relog does. In the top lane, you have your active authentication. This may be whatever you have right now for your application from something as complex as sophisticated as passkeys to something as simple as a password. And in the bottom lane, you have our Relog service.
So there's three components to it. It would be very high level here. There's a Relog service that handles the cryptographic verification of the user. There's a small SDK in the application itself that what it does, it basically keeps asking the service should I keep trusting this user throughout the session and at each subsequent access. And there's a small lightweight component that gets pushed to the browser that responds basically to this challenge. Now the browser component, that's why we call it passive because the browser component is invisible to the user.
Basically, the first time the user accesses the application, there's an establishment of trust. We can go a bit more in depth later on about how to do it or how you would propose to do it. But basically, once you have established trust between the user's browser and the service, both share a cryptographic key. There's one on the service side, one on the browser side. And at each single request, what the service will do is it will renew, rotate a key in a specific way.
We have a patent pending for it and then issue a kind of a challenge to the browser saying prove to me that you can do it in the same way. And the browser has to renew the key in the same way and respond back with a kind of a token, a response saying, hey, here's my proof that I have done it in the same way. And then our service tells the application, yes, keep trusting. Each time we do it, the key is different. That's why we call them transient one-time keys. Now there's two implications of that that are the most important for the use cases that we're going to discuss.
One implication is given that we do it at every single request, the window of attack is superbly narrow. So of course, as anything in cybersecurity, there's a way to attack that. A way to attack that would be to have an info stealer that will steal everything from you, all the components of our passive authentication keys and your current active authentication factors, whatever they may be. And then we could try to impersonate a legitimate user to the application.
Now, I can only do it for as long as the user is inactive because the first click they make, the key on the service side is going to be different, right? So the application not only will stop the attack, it will also say, and I'm going to flip to the next slide, the application will also say, this user has been breached. I know for a fact, that's why we call it a deterministic security signal, I know for a fact that this user has been attacked, that their authentication has been compromised because I've seen this key before.
Now, the second implication of this happening entirely in the background is it cannot be bypassed. It cannot be downgraded. The keys on the browser side are origin bound the same way pass keys are. So even if I'm an adversary in the middle with a fully functional browser, I will not be able to get the response from the browser side, which means that what I will be left with is trying to impersonate a new empty device to the application. And this will only happen in two cases.
One case, if it's an actual new device for the user. So at this point, you know, feel free to put them through however painful enrollment or device authorization because you only do it once. And second, the case of an actual attack.
Now, what you can see here is what we do in that case, right? If we see someone coming with the right password but without the passive authentication keys, if we see someone coming with a session token but without the passive authentication keys, or if we see someone coming with a wrong version of the passive authentication keys, we can tell the application, stop trusting. And we are also part of the CAPE working group. I don't know how many of you are familiar with the CAPE protocol, but it's a pretty cool thing.
Right now, that is part of the shared security signals framework. We can propagate this message across the ecosystem of CAPE enabled partners. Here's an example of partners that were with us at the recent interop demo. But there's about 30 more partners that can receive this message. So we can use that to say, okay, we know that this session has been compromised. There's a high likelihood there's more sessions for these users that have been compromised at the same time, because infosealers typically, you know, don't target just one set of credentials.
Block them off and re-establish trust across the entire ecosystem. Now, use cases in practice. Let's go back to our framework here. The most typical three use cases that we see when we speak with partners and when we speak with CISOs and IAM leaders is first one, the internal use case, where you have a very complex heterogeneous workforce. Some of your colleagues may not have the technical knowledge or may not have the willingness to adopt secure authentication methods. So for them, you can say, okay, do you? And I'll cover you in the background with Relook.
I'll just make sure, keep using password. I'll cover you. I'll check in the background if you're coming from the same trusted device and, you know, I'll see better. And the other two use cases are for external users. One is for customer-facing applications, where right now what you probably typically do is you offer a menu of different authentication options, right? Starting from social logging, through passwords, through passkeys, strong MFA, authenticator apps, so on and so forth.
And you would love your users to, all of them, you know, switch to passkeys, but you also know that typically the transition for a public-facing, customer-facing application takes years, right? Without even the months needed for deployment. So that's the second use case. And the third use case, which is very close to my heart, is the partner applications. So the example I used before of, you know, highly complex interconnected ecosystems where you have franchisees, you have vendors, you have partners that need to plug in directly into your applications.
And they often say, hey, could I use my IDP? Could we federate? And you would just shoot yourself saying, no, I have no idea how your users are logging into your SSO.
So I'm, you know, sorry, but no. Let me provision you with our credentials. We will foot the bill for that. We know it's expensive, but at least, you know, it has a semblance of security for us. With Relook, you can do it a bit differently, right? You can say, sure, come with, log in with Google, even if you want, and I will verify you from my side in the background. So in essence, all these three use cases, what they boil down to is we're giving you back the control over an important aspect of the security of access of your users.
If you want, like after the session, we have a more robust version of this available, so you can read through all these use cases. I'm just going to go through them really quickly to give you an example of what it looks like in practice, right? So this is the first use case. This is a very simplistic view of what you currently may have, right? You have your SSO set up and you make all these options available.
Hopefully your user group three, where people only use passwords, is dying out, but still there's a bunch of users that use MFI with OTP and a small group of users that use PASKIs, hopefully a growing group of users that use PASKIs. The thing is, and I'm thinking back to the recent report published by FIDO, even if you look at companies that have successfully implemented PASKIs and then rolled out PASKIs to their workforce, still typically about 50% of your internal users will use PASKIs and the password as a backup, in which case, you know, there is still some vulnerability there.
So what you can do with Relog pretty easily is you can set up this additional trust signal that will tell you, hey, yes, this user is coming back from a trusted device. I know it for sure, right? And at this point, you can get all your users to phishing resistance. Interestingly, you could ask, should I still do it for users using PASKIs?
Yes, I would say yes. Why? Because PASKIs have some very important strengths, but also we know that, you know, there's a possibility to compromise a PASKI, especially if we're talking about PASKIs that are not device-bound, but PASKIs that can be synced, right? Is it safer than passwords? Without doubt. We all know it. Without doubt. There's no question there. But is it worth covering with an additional signal in terms of passive authentication?
Yes, definitely. And for your users using, for example, authenticator apps, we would prevent here all of these attacks, like an MFA bypass or stolen OTP codes.
Now, if we think about public-facing applications, as we said, the situation is perhaps even more complex. Here, based on the data that we've seen from different analysts' reports, the level of phishing resistance sits right now at about 3%. And this is for organizations that have invested a lot of money, and some of you may have done it, for public-facing applications.
You go through the process of running it out to users, you go through user education, you beg them to enroll, you beg them to use passkeys, and still there's only a very small fraction of users that are more security-conscious that will end up doing so. And there's even one thing that's even worse, probably, than passwords here, the social login tokens and the external SSO tokens. Why? Because you have no control and very, very little visibility. There's some level of assertions of what the level of security of authentication was, but you can never be sure what people are coming with.
So you are at the mercy of your customers. And we all know that, for instance, I don't want to use names of companies, but let's say a large SaaS company providing business application for HR, let's say, if they get breached, what you'll read in the news is, company A was breached. And they have all these software tools that they make available to their customers, they are trying to convince people to use passkeys, and people just can't be bothered, which makes sense, right?
Users want to use an application, they don't necessarily want to think about the security of it, but at the end of the day, the responsibility, the cost, the pain ends up being yours, not theirs. So again, what you can do here with Relog is essentially the same thing, right? Keep your authentication application as is, keep transitioning people to passwordless, do it consistently, right? Granted. But protect them right away, right? You can do something to protect them today.
You don't need to wait for them for two years to be kind enough to adopt passkeys because they have a spare Sunday, where they're like, oh, okay, I'll do touch ID for them. Here what happens is, Relog verifies them, again, in the background, verifies their browser and tells you, yes, this user is coming from a browser that has been confirmed for this user as their trusted device, keep trusting. Interestingly, one thing about implementation, because you may be thinking, how do I implement that? For this one, there's two methods of implementation that we have worked on.
One is what we described before, what we would call the full integration, where you have a small SDK running inside of your application itself, telling you, yes, keep trusting, no, do not trust. And for us, this is the preferable way because we can enable direct enforcement, right? If we see a session that is compromised, we can tell you, okay, stop trusting, log the user off. And we do it continuously, right, throughout the entire session.
But for some of you, you may be thinking, okay, I cannot go to my front-end developers and tell them, hey, we have this SDK that you need to incorporate, could you please do it? Because they will not want to do it. So what you can do for these use cases is you can use it as a separate step of authentication. You could have a separate container and basically redirect the user when they come in.
The way, for example, some CAPTCHAs work right now, where you have a screen popping up, verifying you are a human user, here you could have a real screen popping up, verifying that you are coming from a trusted device. And then redirecting you back to the application. Downside of it, it's not continuous anymore. It only happens at access. But that alone gives you phishing resistance. It wouldn't give you a session hijacking resistance, not throughout the entire journey. Upside of it, you can do it without any integration, right? You just need to do a redirect and then redirect the user back.
And you're already covering them with a pretty strong additional step. Another downside, it's not invisible anymore, because they will see the screen coming up. And the third use case, you can probably already imagine what I'm going to show you.
This case, where you have your partner organizations using their own IDPs, sometimes more than one, sometimes just using your password to log into your applications. And you have neither visibility nor control over how secure their access is. With Relock, you can say, OK, keep using whatever you are using. I will verify you in the background without you even knowing. An interesting variation, let's say, of this use case came to us from one of the customers.
They said, hey, you know what? I have tens of thousands of temporary workers each year. And I need to provision all of them within our IAM. And they typically don't have neither knowledge nor experience to do even simple stuff like resetting their password in, let's say, Okta or Bing or CyberArch. Could I do something like this for them and let them come in with just a password? Yes. Could I do something like this and let them come in with their Facebook account or their login with Google? And I'm not paying for it at this point, right? Potentially, yes.
Of course, there's caveats. But potentially, that's a very good use case for it. Where I can say, OK, I'm not going to be provisioning them for the access to one application that they need. I'm just going to use Relock for it and cut down the cost by 90%, 95% for these users. And the complexity of onboarding for these users. As well.
So, perfect. I think I'll just stop here.
Ricardo, happy to hand it over to you for the more encompassing look. It was quick.
Yeah, I have 37 minutes here. Yeah, 37 minutes. That's good. OK.
So, my name is Ricardo Martins. I'm the CEO of Cloud Computing. And I'm here to talk about breaking the cycle of compromised credentials.
So, just to start explaining who we are. We deal with securing identity journeys, right?
So, when you access to service, you start in an endpoint. You go through several stages like operating system, login, browser, then web application, then back-end APIs, databases, storage, and so on.
So, you have several logins, several experiences. So, we just want to make sure that it's secure, it's consistent, and you apply things like least privilege principle.
So, basically, governance, access, single sign-on, and all that stuff around the identity journey. Good.
So, just a few words about us. So, we were born out of Portugal. We then expanded to Spain and the UK as well. We have done a ton of identity projects, both for workforce and also customer, and privileged and machine identities.
So, everything around identities, right? We are part of a cybersecurity group called Alurity, which is also present in Germany with two different organizations, which is security research labs and the Securix as well. Out of these 11, six of them actually work in identity and access management, and we are present in 18 countries.
So, what do we do? So, basically, we do everything around identity, right?
So, one of the things we actually do for customers, because identity is such a hard problem to solve, and also it's very hard to maintain really proper identity teams inside your organization. It's a very hard process to really have architects and consultants and support and all of that.
So, that's what we do also to customers in all these areas as well. We also do things like zero-trust assessments.
So, we understand the gap. What is your security depth? And also some household certifications as well. Probably the one that is more recent, besides NIS2, which is fairly recent, but already well-known, is the NHI gap analysis.
So, how can you understand what is actually your machine identity problem if you don't even know, right? So, we start there as well. And because we deal with identity journals, and identity journals, they actually start somewhere, typically on a tool, on a device, and we also deal with endpoints as well, with network access control and device management, and integrate everything in a layered zero-trust architecture. Okay.
So, that was the intro. So, let's talk about breaking the cycle of compromised credentials.
So, this is a known problem, right? So, actually, this has been more severe by the years. And even though we have lots of information about it, right?
So, you can actually search for yourself if your credentials were hacked. Of course, they were. But you can find out where in many applications. If you are like me, it's like 20.
So, you can actually free search on free portals, like if I have been pawned, or you can actually buy premium feeds from several players, like CrowdStrike and others. You can also get identity provider automations, like Okta and others, and Ping, where they will tell you if your user credentials have been hacked already, right? Which is nice. And then we also have mobile alerts. Most of you probably have received an alert from your Android device or your iPhone device, saying, oh, your credentials have been hacked.
Well, this doesn't seem to have solved the problem, does it? Right?
So, we do have more information about what has happened to our credentials. They keep getting hacked. And it's just not— Well, it's just so, so slow to understand the problem because when you actually get information, you really don't know how much time has gone by, right?
So, how much time were my credentials present in the dark web? How many times were they used? Do you have early access to that kind of knowledge? Are we talking about weeks, months, years? All of the above?
So, this doesn't seem to be the right solution, does it? And so, the industry, the cybersecurity industry, have created a ton of technology, right? And one of the things that we all— and I'm part of that, where we have all been very consistent in it— is actually, we have pushed the burden of supporting these new requirements to the user. Right? He needs to understand right now, if you check how many characters each password should include, it's more than 12 characters, right? You should be using SMS OTP.
Well, it's not actually secure, but still, it's better than nothing. You also have an OTP app, or actually 50 OTP apps that you can use. You can also use PushMFA, where you try around with workflows.
And yes, it's me. Yes, I'm working in Germany.
Yes, it's me. Well, all of this is actually quite complex. And you can also go to device-bound passkeys, or synced passkeys, which are— well, a synced passkey, if you actually think about it, it's like a password vault, because it's protected by a pin that you have on your mobile phone.
So, it's a bit weird, the concept. So, the actually most protected, let's say, passkeys is actually the device-bound keys, which is externalized in a token, which costs a lot of money. It can cost you like 100 euros just to get a biometric externalized 502.35 device-bound passkey-supported hardware.
Anyway, a lot of weird words, a lot of strong words for cybersecurity. It's just to mention that this is complex, and we are pushing all of this technology throughout the years to the end user, being workforce or consumer. And this is a pain, right? I think it was Peter Ducker that said, culture eats strategy for breakfast.
So, we can push a lot of technology. People just ignore, right? Hence the 3% adoption. And I'm not even talking about even weird technologies like blockchain wallets that you can install on your mobile device. Don't even go there. But that's like what the European Union wants to do right now, right?
So, that's even tougher. Can you imagine a 70-year-old person dealing with wallets and blockchain on his mobile device? It's a guaranteed success, right?
So, we are just pushing this technology to users. It's just bringing them the pain.
