To it. It's an unfortunate natural evolution. One of the things I'm going to mention here today is I think as an industry, when we first rolled out MFA, championed MFA kind of did too good of a job saying MFA's gonna solve all your problems because that's all that stuck in everyone's head. And now everyone's like, Well, wait a minute. I have MFA. I'm good, right? You told me I was gonna be good if we just did MFA. It's like, Well, we need to reframe some of these things. We need say, you're good for now until the next happens. So like, resistant MFA, after this we're gonna have super fish resistant MFA, or whatever the next thing is after this thing, after this gets compromised, which it will, it's just how it goes. It's always a matter of time, right? It's always evolving, always changing. it's great to have you today, thank you for joining. I want to obviously talk about MFA a little bit today, but first, I think if we can just start with kind of a little bit of background on yourself, kind of how long you've been with Corsica, sort of your trajectory and your career, and how you ended up kind of in the seat that you're in. Absolutely. So I'm a recent joiner to Corsica. I joined as part of an acquisition of another company called AccountabilIT about six months ago. I was with that company since its very beginning as the first employee of that company. And then just overall in managed services, I've been doing managed services for most of my adult life, which is around thirty years. And so largely the kind of the first half of that career was all in operations as a application administrator and DBA. And then subsequently somewhere around the middle of that started moving more into infrastructure and platform operations and data center ops. And then there came a need with AccountabilITI to transition over to full time security operations. So the second half here so far has been, or the last ten years ish has been, full time security going operations, running security center, doing, you know, the CISO type services to other organizations, as well as a CISO position with my own organization's AccountabilITI. Okay. So you got a bit of a background then, like expanding the full gamut and not just, you know, in security, you know, for the past thirty years, it's been kind of all over the place. So you've got pretty good concept of, you know, the inner workings of the various IT facets and how they all operate and work together and where people are getting in. You know, I found that having that core in operation support has lended real well to my security life now because oftentimes when I'm dealing with a customer or I'm helping out client or a customer, I'm talking to their operations team so I can talk their same language, right? Because the security folks that if you've talked to them for any length of time, they kind of have their own made up language. And so, you know, I can communicate that, like, what does this mean to you in in practice? And so it's been hugely beneficial having that background, knowing what this looks like, as well as knowing, like, what does this look like for the users? What's the user experience? And we know so we're gonna be talking about MFA here in a little bit. A a big part of this the the whole challenge is adoption and making sure we're aligning user experience and that we're keeping that experience positive and best case scenario transparent to the users so that they don't aren't inclined to try to circumvent or go around the security controls that we're trying to put into Well, for our viewers at home today, we're actually going to be playing cybersecurity buzzword bingo while we go through this. So please take out your bingo cards and be sure to fill it in every time we say a threat landscape or attack vector or man in the middle attack. All jokes aside, we are here to talk about MFA. MFA has been around for a very long time, and it's something that most people would say, We have it. What's your experience with MFA as it relates to where it was a decade ago versus where it is today? So a decade ago, we're kinda in the same spot we are today, where we are experiencing challenges with our cloud identities, with business email compromise of our cloud identities because they're exposed and the the big risk with them is they're exposed to the Internet. And that's that's transition that really happened for most organizations ten, fifteen years ago as we migrated away from on prem services where everything lived behind our envelope of of perimeter security, and we started subscribing to these SaaS services. Now the SaaS this is not a negative on SaaS services because that has helped democratize high level capabilities across all the way down to the smallest of organizations, all have the same access to the same tools that the super massive enterprises have as well. And so that's a good thing, but it has changed our threat landscape or our exposure to, there's bingo for you, our exposure for our organizations that we need to support. And so as we move to cloud services, right, it changed our approach of how we need to secure our identities. It opened up a new exposure for us of these cloud facing portals that we authenticate to, and we found pretty quickly that and attackers realized pretty quickly that they were able to trick users using pretty low sophisticated means to intercept or or collect their password. And so with that, with only having the primary key pair between the username and password, it was pretty easy to gain access to somebody's cloud identity and the data that's stored there. So we introduced MFA. Right? And so the MFA was more of an interactive thing that would change during each authentication session. And lots of times back then that looked at these time based one time password things, like a little RSA thing that rolled to six digits every minute or so. And that's where we started. And now we've modernized past that. And unfortunately, some of those tools have suffered their own risks and weaknesses or vulnerabilities, or rather risks really for compromise. And so now we have maybe more modern approaches to MFA where we have an authenticator app and we have notifications that are presented to the user around like what application is requesting authentication, have a number match that's presented to the user during that authentication flow. But kind of what we're here to talk about today is that even that unfortunately isn't good enough any longer. The landscape has changed yet again. Yeah. Before I think we go any further, just so that we can kind of be clear, the MFA is that exists today or the MFA is has kind of lied to where we're at. The challenge is that the attackers are clever, right? It's an arms race between the defense and the attackers, or as we call it, the red operatives and the blue team defenders. The stakes are always raising, they're always looking for a leg up. So kind of what we have found today is that the attackers have created these real time attacker in the middle workflows that will intercept that authentication method or that authentication flow, and then get the session token as a result as a result of intercepting that authentication flow, and then be able to log in as the user. Let me kind of break that down a little bit more So the con, right, this is all like a confidence scheme. Like many of these attacks, they will coax the user to go to a website that they control. And so that's usually, they send a notification like, I have a document to share with you. And what gets really dangerous is that when the attacker is using the identity of somebody else who's a business associate of that person, right? So they're already inclined to trust, right? It's not a random email from a random person on the internet. It's somebody they already know. And we see this pretty commonly where an attacker will compromise one mailbox, and then they'll use that in order to try to keep propagating their attack from entity to entity and across the organization. So they'll send a note to the user, say, Hey, I have an RFP I want you to look at, or I have an invoice that I want you to review. Click here. That link will take them to a website that looks exactly like whatever authentication portal they're trying to intercept. So I'll take in the case of the m three sixty five authentication portal. The attacker will even, though, scrape the images off of the website. If you have a custom image for your sign on portal, they'll scrape it. It'll look exactly like your authentication page. And the reason why they do that is they they are scraping that information in real time. So you type in your username and it says, oh, it's, know, associated with organization dot com. So they will they at that same time, they are proxying your authentication activity. So they authenticate they put the username in to the real m three sixty five portal. They get that page back. They present the the next thing back, and the next thing back is prompting for the password. So the user types in their password. They then send that through to the real authentication portal. Then they get presented with the number match or whatever next factor of authentication, whether it's a TOTP token that you're gonna use, right? The six digits that you have in your authenticator app. If that's what's prompted by the portal, that's what they're then going to present back to the user. The user types in their six digits, and that then sends back through the portal. The authentication flow completes. The attacker gets given the authentication token. They hand that authentication token back to the user. The real user gets redirected to something, right? It doesn't matter what at that It could be Disney dot com because the attacker already has what they want, which was the authentication token. Then they can use that as part of a non interactive authentication flow to then get into that user's account from there on out until that token gets revoked. Now we can talk about, we'll probably talk about defensive measures a little bit later of how do we protect those tokens. But at its core, that is how this gets defeated. Now I'll maybe share just one more thing. The reason why this has gotten super popular is just like our email apps and cloud identities and all those things are now SaaS applications, so are these AITM attacker in the middle platforms. You can go right now and for a very low amount of money per month, you can sign up for a service, one of many services, and subscribe to some other attacker in the middle portal. They'll even give you training. There's the support line. I mean, it's just like any other SaaS application support. So it's super just like all of these other tools have gotten democratized, so are the attackers tools. They're getting democratized the same We're not even talking about dark web right now. Talking about there's just published applications out there, subscriptions that you can sign up for that will allow you to steal another individual's identity. Maybe not identity, but their online identity as it regards to their Microsoft three sixty five account or Google account or whatever it may be. Yeah. Whatever you're you're after. You can just add like yeah. There's five websites I can think of right now. Go sign up with maybe not your own credit card, someone else's credit card. Yes. Yeah. There's there's probably a a proper chain of events there that you should follow so that it doesn't trace back to you. However, not what this is about today. Yeah. It's good to know those exist though. I mean, it's truly I had no idea that those breeding out there. That's insane to me. But the fact that they haven't been shut down, I mean, I'm sure they're probably hosted somewhere where Not every country has strong security laws. So we've talked about the problem, right? Which is the man in the middle attacks are people being able to more or less steal cases of the data, redirect through redirection and smoke and mirrors. So how do we solve for it? Because it seems like we need to be able to log into these We need to be able to, you know, trust that our multifactor authentication is is working. In the situation you just described, unless, you know, you're just never clicking on the link in your email that you're unsure of, which we would recommend, there's no way to ever be sure that you're not doing something, you know, you shouldn't be. So the human firewall is absolutely a component here, right? User education, but we know human firewall is fallible. Humans are fallible, right? We all fall victim to things from time to time and that's just gonna happen. Now, the reason why the attacker in the middle position works is because there is kind of an oversight or just something that wasn't thought of at the time, that's why these things evolve and you get better over time. So it wasn't thought about at the time that somebody was even going to do this. So what happens if we look at the scenario of the user who's been coaxed to go to or tricked into going to this attacker in the middle website, the only clue that they have that they are not where they're supposed to be is up in the URL. The URL is still some other garbage site. It's not the real authentication portal. And we've trained our users, a lot of times users realize, oh, wait a minute. Right? We've also trained our users to be suspect of something like, wait, this person never sends me these kinds of documents or they never share these documents in this fashion. This seems weird, and so they will take that action. But we can also apply system level controls to prevent this from even being conducted. So with phishing resistant MFA, one of the approaches is to adopt a FIDO2 second factor, compliant second factor of authentication. So intrinsic to or built into the FIDO2 standard is a cryptographic key or certificate that is used for authentication. So when you register your authentication method, your machine, your thing gets this certificate back that you then use for authentication. Now that certificate has to be stored in a FIDO2 compliant repository. And part of that FIDO2 compliance is that when that certificate is being requested, it verifies that that person asking for it or the entity asking for it is the entity that actually issued it. So in our example, when a user is tricked into going to some garbage site dot com and the certificate that's being requested for authentication is from portal. Office dot com, when the authentication is requested, the FIDO2 compliant repository or Key Vault or, yeah, Key Vault, we'll call it, says, No, I'm not going to give you that certificate because you're not the person who gave this to me. And so it stops the authentication flow there, right? So it's dependent on the compliance of the thing that is storing it. And so when you're registering this, the authentication, the issuer of this cryptographically signed certificate will only let you store it in an appropriate vault. And so that's how that process gets protected from end to end. Now there's a few other approaches that we can take, but I wanna focus on FIDO2 and otherwise known as passkeys, because that's what we find most commonly easily implemented, as well as it's the best user experience from a port ability and putting the most amount of control in the user's hands, leaving them flexible with where and how they use their identity while still being safe. Some of the other controls that we use, like, like binding an authentication to a device. So can do things where we prevent authentication to our portal except when it's from a company issued device. Now there's other reasons why you might want to do that that are probably outside of our store conversations, such as data loss prevention and whatnot, where you say, okay, well, we're only gonna let you sign in here if you're signing in from the company issued device, which we know meets the standard and data can't be removed from it or what have you. But that is a more complicated thing to implement. And if what we're worried about, if what we're concerned about is just protecting the identity, that passkey really is the most easily implemented approach for our users and the most convenient for them to use. Okay. Before we kind of continue, can we just touch on FIDO real quick? Is that an acronym or is that a dog? It is. Little of both. So Fido stands for Fast Identity Online and Hang on. It is Fast Identity Online. It is a it's actually not necessarily new, but we know that these standards get established long before they actually start getting getting used. Right? We really saw PaaS Key as a technology or FIDO2 as a as a standard, really getting implemented within the last three years is where the adoption has kicked in. So it's kind of like how, know, today we're talking about quantum computing, say encryption algorithms, right? We don't even have We're long ways away from having fun on computers commercially available. But these things, they take time to develop today so that we're ready for when the problem presents itself tomorrow. And so, know, FIDO was developed back in twenty thirteen, you know, and it was a concept, But obviously the need was recognized even back then, though we really didn't see the big rise of these common attacks until recently. And I would say the reason why we've seen the rise of these common attacks is because the attack method has been heavily democratized because you can just go send a, you know, part of a Bitcoin to somebody and and you have your service, and you don't need to know really anything about it other than have a list of contacts and set up some templates and start sending out emails and you're good go. Well, that makes sense. Sorry for, you know, maybe the silly question. I just wanted to better understand, you know, before we dig in, what what is FIDO? But, you talked about storing, pass keys or, you know, certificates. It's essentially in vaults. What are the vaults you're referring to? Because I'm sure it's not a bank vault, right? So what are we calling a vault? So a vault in this context is going to be a device or a module, either on your computer or oftentimes our mobile phones, are also compliant with having the ability to store these secrets in a manner that is compliant with the FIDO standard. And so you have these password modules on our computers that are super secure encrypted storage devices in our computer that can store these certificates or secrets in a manner that prevents them from being stolen out of our device or only being used appropriately. Similarly, our phones also have a vault in them or a module in them where we store these secrets and then they can be authorized applications in order to access those secrets and be able to use them for authentication. So so for example, right, when you use your phone and let's say you have facial recognition recognition on it for when you want to use a password to go to a social media site. And so you go to the social media site, it prompts you, it says, oh, do you want me to put the password in for you? Well, it's asking for permission to go read from its own internal vault and you are completing an authentication flow such as facial recognition, giving the application permission so you don't have to type in your username and password with your thumbs. That's all that same authentication flow occurring very similar to how a FIDO secret would be retrieved from the vault on your phone. So what you're saying is the hardware device is more or less the Vault. I mean, it's probably a specific chipset or something within the device itself where it gets stored, but it's brought, it's allowed access or it's brought forward based on something biometric or some pin code or something of that nature. There's some actions the user has to take to more or less say, Hey chipset, release this certificate and validate this access request essentially. Yes. And so it's built in, right? Again, all the manufacturers have known this is coming, so they've been building these modules into our devices so that when the time is right, we're ready to do these things. And you make a very good comment around like, well, the interaction is something either I am right, I use my face or I use a pin. You might think, well, wait a minute. Why a pin is easier to remember than my passwords? Like the key to understand there is that that pin is local to that device. So physical security also comes into play here. The attack surface for your cloud identity is the entire connected Internet. That's where you need to have the super strong thing that your personal device is on you. So you just need to be able to keep from accidentally using it or somebody locally around you from intercepting that. Know what mean? Yeah, so it's physical and it's proximal and proximal may not be the right word. I don't even know if that is a word honestly but it's proximity right? It's how close you are you know to the device that is requesting access right? That's what stops the entire somebody from China or somebody from somewhere else in the world And it's funny, so let's get kind of maybe a little bit extra nerdy here for a minute. So there is a component to the FIDO authentication flow where we've been speaking mostly in the terms of same device authentication flow. So I am authenticating from the device where my secret is stored. We also have, for convenience sake, we also have cross device authentication flow with Fido. So I can sign in on my computer, but have my secret stored on my phone. And so your comment around proximity, so when that authentication flow, when I do cross device authentication, my computer actually, the authentication does not go back to the portal and then down to my device. The authentication flow is a circle. So when the challenge is received either way. Well, but cross device is essentially what we've used in in corporate environments for forever. Right? Mean, it's you're logging into your computer and whether it's a a number matching, whether you get a notification, text message, a call, whatever it may be on your phone, you know, that's the cross device authentication, right? You're leveraging a second device for the second factor authentication, for the multi factor authentication. But my question to you would be, okay, so we're talking about cross device because oftentimes when we're dealing in Microsoft three sixty five or even third party SaaS apps, it's Entra, it's Microsoft 365 as your identity source, right? So we're really logging into Microsoft to then authenticate us against an application. In that scenario, what if you're using a desktop that doesn't have Bluetooth, but you want to still use your cell phone? Is that an option or is there a better mechanism to kind of go down that path? Absolutely. So we have more options here as well to securely authenticate to our identity provider or IDP as it's called. Right? Whether we're using Google Workspace or or enter ID or something else, some other identity provider. Right? They all provide this option. So there is another authentication. There is another way of completing the FIDO2 based authentication flow that doesn't involve a Bluetooth low energy ping or accessing a module that I have on my computer, whether that's built into my computer or a separate device like a YubiKey type device. And in that model, what is presented to the user is probably the most complicated QR code you will ever see in your life. And so it's less convenient. So it's a good point. Our users are used to interacting with their personal device in order to authenticate. But typically they just have to tap a couple buttons or what have you. With this authentication flow, if I don't have Bluetooth, if I don't have an onboard module, the user is presented with a QR code. And then that QR code contains all the information, including information about the issuer. So if, again, if this is intercepted by the attacker in the middle and they try to replay this to me, there is still verification there that says, No, wait, this is not the legitimate source. And so it will stop that authentication flow. And so you'll get that QR code, scan that with your computer, it'll read the information about the page that's being presented plus the page about request for the authentication flow. And then you can complete the challenge in order to release the passkey to the authentication provider. Okay. That makes a lot of sense. And I don't want to continue down this, how many options do we have? Because it sounds like there's quite a few options in terms of the actual deployment of, you know, fish resistant MFA. But I do have one quick question that kind of comes to mind. In all of the conversations with clients that I have, know, the Windows Hello for Business idea comes to mind. Is that an alternative method as well to achieving the same outcome? That's a great question. So the key to implementation, let's talk, let's spend some time talking about implementation because that's where the rubber meets the road as it were. Yeah. What we find looks the best or the implementation is you don't pick one and stick with it. Situationally, it's really, you end up using a little bit of all of the above. You might have certain identities where it's most and and the goal needs to be whatever is most convenient for the users because that's what's going to be the most effective and the most successful in adoption and usage. So you might have certain identities where, okay, we need to buy a physical appliance, like a YubiKey token, because certain users need that. You might have somewhere it's like, okay, we're gonna do authenticator app, store the token in the authenticator app on mobile devices. And then kind of what's the most convenient for our users for the bulk of their authentication really is Windows Hello for a Windows focused organization, but is really using Windows Hello because that is also a FIDO based authentication method where now it's specific to Windows, but in that authentication flow, the certificate is stored in the TPM module on our Windows device. And so it's stored securely in Cred Manager. And so when the access is being requested, that module is verifying like, okay, it actually the real requester And then it'll release, right? You'll complete whatever the challenge is, whether it's a biometric or a PIN, you complete that challenge and then sends that credential back to the identity provider. And what's nice with Windows Hello specifically is that it's, correct me if I'm wrong here, but it's as you're logging into the computer, right? It's doing things, So it maybe saves you a bit of a step later on, right? Once you authenticate your computer, if it's synced to Entra, you know, it will take care of the other, you know, behind the scenes things that would grant you access. So from a user disruption or user experience perspective, which MFA is always one of those things where it can be pretty frictionless. It can be heavy on the friction depending on what route you take. That's something that I consider. Absolutely. You know, we do find that when reviewing So there are times with implementation of controls like conditional access that prompt for MFA challenges, sometimes they outlive their purpose. And so as we migrate and move towards stronger controls, we could actually reduce the number of challenges that we need to introduce to our users because the problem they were solving no longer exists. And so I have found a number of environments where customers have modernized, but didn't let go of the old things. You know, there's another term here, security theater, where we do things for the show of it. It's not actually making us any more secure. All we're really doing is just making life difficult for our users. And so a practical approach, really looking at each one of those scenarios where we're issuing a challenge, to make sure we understand, are we actually solving a problem? Are we doing this because we feel like we must and that somehow if we just keep challenging people all the time, that's going to make us any more secure than we were without the challenge. Yeah, well, I often kind of tell clients security is almost never convenient, right? But you gotta manage risk with convenience and at some point there's gotta be a little bit of overlap. But what I'm hearing is correct. You more or less just said that there's opportunity here where, you know, having better MFA or better security could actually be even more convenient for the end user. Well, a thousand percent, especially on a scenario you just laid out where we've fully adopted Windows Hello. That is about as frictionless of an experience as you can possibly get. I'm not getting prompted for another username and password when I sign into Outlook or when I sign into Word or SharePoint or whatever, right? That I sign in once with a PIN, not even with a password, right? Because as a security industry, we have made passwords easy for computers to use, but we have not made them easy for people to use. And so as we've required longer and longer passwords, we haven't solved the human problem of making it easy for them. Well, things like Windows Hello make that very easy because it's, contained to the device itself. So that doesn't let you sign into EnterID. That PIN lets you unlock a much, much, much more complicated password that's stored on your computer and only your computer because it's crypt it's bound to your device. So even if that is lifted out of your device and somebody tries to use it from some other computer, it can't even be used. So so, you know, there there's a lot of in built controls that reflect the current state of how these compromises occur and how they're used. So a lot of native protection there. And when fully implemented, a whole lot of quality of life improvements happen for our users. They no longer have the MFA exhaustion of, oh, I had to sign in ten times when I signed in. We find, though, not that it literally happens too much anymore because of changes to how our authentication works. If you remember when we first had push notifications on our authenticator apps, and all you had to do was hit accept. And so, and all you needed in order to conduct that attack was the username and password. So all I had to do, I didn't have to intercept the authentication flow. I just had to get you to go to a page, right, as an attacker. Get you to a page, get you type in username and password. And then I just keep beating that at your identity provider. It's called a fatigue attack. Basically, I'm just trying to wear you down until you accidentally slip up and you hit accept one time and boom, I'm in. Well, in a way, we kind of use that to our We create fatigue attacks for our own users when we over MFA challenge them and we don't make it convenient and easy for them to use these authentication methods. So then our users start to push back every time we have a change. They're like, No, I'm tired of making changes. When are you going to make my life easier? FIDO2, strong MFA, vishing resistant MFA is an opportunity for us to cut out a lot of the theater and really make quality of life better for our users on a day to day basis, save them time, create convenience, and keep them more secure. The absolute That's Yeah. And just for the record, that's the same methodology I used to win my wife. So just wear it down. Swear it out? Yeah. Swear it out. That's more convenient? No, at all. But you know, we've talked a lot about what the world looked like ten years ago, how we've gotten here, what here is in terms of fish resistant MFA, sort of some of the implementation methods that we can take, you know, I guess how it improves the life of the overall employee and can also improve security at the same time. So I think we've covered quite a bit of ground here. You know, think what I want to kind of just do real quick is maybe give you some rapid fire questions where you just answer them kind of off the cuff. There's some common objections or common questions that we often receive when talking about this with clients. So the first one is it hasn't happened to us yet. Where's the flow on that thinking? Past performance is not necessarily reflective of future dates, right? Like, so that's the disclaimer that you have on financial products. How about this? Like, if you flip a coin fifty times in a row and it lands on heads, what's the chances that it's gonna land on heads the very next time? Still fiftyfifty, right? So just because it didn't happen to you before doesn't mean it ain't going to happen in the future. Now we do find there are some organizations that are more prone or less prone to these types of attacks, right? Like a small organization where everybody knows everybody and you have a very limited number of external entities that you interact with. Okay, well, maybe maybe right? Your exposure is a little less, because anything abnormal is going to really stand out. But it happens. It happens to everybody. I've literally been there in the office with somebody saying, Hasn't happened to me. It's not gonna happen to me. And then a month later getting the phone call of, Hey, just happened. So it it will happen. It's just a matter of What about our users are gonna hate it? So I think we just covered that one. It's way more convenient than traditional MFA. And we can do things because of the inbuilt security of it. We don't have to depend on our users nearly as much to provide the security. So it's less stress for them and less stress for everybody else involved in the business and it's more convenient when properly employed. God, Eric. What about this one? I'm a small and mid or a mid sized organization. I'm I'm just less of a target. They don't care about me. They super care about you. Don't feel unloved because you're small. They absolutely like, everybody gets hit. Like, even individuals will get gotten because there's money in it. Yeah, you're not gonna make a whole bunch of money on it, but consider this, the margin is huge because all they had to invest was an email and a little bit of time. So everybody unfortunately is gonna get gotten or is a target. Absolutely. Well, if if the people at home haven't, you know, finished their bingo card yet, by way to say a term that will probably finish it off for everyone, which is AI. And the age of AI has only made, you know, these types of attacks easier because now AI can write emails to where it sounds as though it's coming from someone in maybe your native tongue, Your native language. And that's a good point. As I look at these phishing emails over the last two years, like it used to be like, obviously that's English as a second language. It's very stilted language. A lot of grammatical errors or whatever. Man, they look great now. Like they've really upped their They look like a legit real email. That language barrier, you know, those turns of phrase that we used to all look out for, they just don't come up anymore. The emails look legit. It's making it harder for all of our human firewalls to protect themselves. We need to give them some help. It just lowers the barrier to entry for these malicious attackers because they can bulk these out by the hundreds. Not that they couldn't before, but now they're it and the quality is so much better. Quality is better and they can make it much more personalized as well. They can use information that they call from other third party services such as LinkedIn. Everybody knows where you work, where you worked before, who your associates are. They can figure out your business. With AI, they can build that map to make a very tailored, targeted, with low effort spearfish to specifically target you. They're not just targeting your company, they're not just spraying it across the internet, they are targeting you personally based on a map that they have created of you to try to get you. Yep. Well, you know, think that that kinda closes out the the rapid fire questions portion of this this conversation, Clayton. I really appreciate you being a good sport and kinda humoring me there. Absolutely. Especially with the, you know, buzzword bingo card. I hope those at home, you know, if you got a bingo, let us know. We'll we'll send you a gift card. I've got one final question for you before we kind of wrap this all up. You know, if an IT or security list excuse me. If an IT or security leader today is listening to, you know, our conversation, what's one thing that they should be doing immediately after this episode? Asking their IT team if they have full coverage with phishing resistant MFA. It is the number one attack anywhere, right? It is your biggest weakness. It's your biggest exposure because your identity is generally, in most organizations, presented to the public world, right? That authentication portal has, you know, anybody can try to sign in from, well, okay, from anywhere. Because even if you say, well, we have geofencing. Yeah, that's fine, but I can be anywhere in the world and sign in from anywhere in the world. No, that's not really that effective. If you're not, do it now. And here's the beauty of it. Probably ninety nine percent of all customers already have paid for it. Right? You already have the service that you need to do this. You just need to go do it. And it does take a little bit of planning. There's a little bit of communication you need to do with your users, but it's not a tremendously big project. It's just a thing that needs to be done. And it's just a result of an evolving landscape that five years ago, ten years ago, we said, Okay, everybody needs to do MFA and it's all gonna be okay. That's changed. If I were to predict five years from now, we'll probably be having the conversation again and it'll be super phishing resistant MFA or whatever the new term is. So be ready for the next thing that comes because this is good for now, but the attackers will get smarter. There'll be a new technique. We don't know what it looks like today, but we'll have to figure that out tomorrow. That's great insight. And for those of you at home, again, business email compromise, evolving threat landscape. There's two more bonus ones for you. Hope you all have a great day and Clayton, thanks again for being a good support and coming on and have talking through this. Thank you. It's my pleasure. Take care. Have a great day. You
