A False Sense of Security: Authentication Myths That Put Your Company at Risk

Hello and welcome to a KuppingerCole webinar today with One Identity. We are talking about A False Sense of Security, Authentication Myths That Could Put Your Company at Risk. We're with Stuart Sharp from One Identity. He's the VP Product Strategy and Alicia Townsend, who is the Product Manager, One Identity. So welcome to you all. Just to let you know that you are muted, so you don't need to do anything on the sound. There will be Q&A at the end. If you have any questions, submit them to the panel in the window on the right side of your browser.

And this will be recorded, and the recording will be available on the KuppingerCole website very shortly after today. So that's what's happening. Now a quick introduction from myself before we get into the myths themselves. Now that picture there, I don't want you to think that I googled Greek myths or just myths and came up with this picture, though this took many, many hours of research to find the right picture, because that, of course, is Icarus. And Icarus, as we all know, flew too close to the sun.

His wings, or the wax on his wings, melted and he fell to his death. So he obviously thought that he could fly, and that was obviously a myth, you see. So there's a lesson for us all there from ancient Greece. Now on to more sensible myths, please welcome our authentication mythbusters, Alicia and Stuart. And I will stop sharing now my screen and say welcome properly to Alicia and Stuart from One Identity. So we have a number of myths to go through.

Thanks, Paul, for having us today, looking forward to this webinar. I just wanted to give a bit of background, because what we did is we talked to several dozen people who are regularly meeting with customers, they're meeting with people outside of their work life, although they're all security experts themselves, and just to get a broad range of the kind of misconceptions, misunderstandings that they hear repeatedly. And just to give us, hopefully, an interesting array of authentication myths to bust today.

Okay, and Alicia, welcome to you. Today is official. I love Lucy Day. That's it. I was gonna say Lucille Ball, but no, I love Lucy Day. So you are probably the only person in the world celebrating that.

Well, actually, you know, me and Stuart are celebrating with you. Now, I can't think of any connection between Lucy and the first myth. But the first myth is, for you, Stuart, security is a business killer. One we've all heard. Sounds reasonable to me. Okay. Yeah. So I've been in security a long time. I won't say just how many decades.

And, you know, I think a lot of the misconceptions today are based in real life experience that people and organizations had, but really, literally last century, you know, in the 80s, in the 90s, where they did see security limiting business productivity, and this constant back and forth between, well, we need better security, but then it's so annoying, and people will just try to bypass it, etc. And not just inefficiency, but tighter security leads to poor user experience as well.

But technology has advanced enough, particularly with the rise of SaaS, not just for applications, but as a service for identity for all forms of security. That's no longer the case, right? The reality is that security options today, particularly think of passwordless options, on-device biometrics for opening your phone, etc., can actually enhance user experience, improve productivity, and increase security.

So, yes, there are reasons why people used to think that, but they really need to have to think twice again. It's perfectly feasible to say we need to tighten our security, but let's do it in a user-friendly way. Let's do it in a way that's actually more efficient than how we've been doing it in the past.

Yeah, but on the other hand, you do still hear that people deliberately go out of their way to avoid security, well, workflows, or policies, or anything, because they just want to get their work done. So, how are we dealing with that?

You know, like the classic one is the DevOps guys. They always get blamed for everything, but they do it, because they just, you know, leave stuff lying around. They put secrets in containers and all sorts.

So, are you dealing with that? Yeah, so that's a great example where there is a challenge on can you actually make the secure option the preferred option.

So, not just, well, we're doing it a different way, and it's not really more difficult, but I'm too lazy, and I'll do it the way I used to. Where you actually improve the experience so much, they'll be compelled to do that.

So, I think on the DevOps side, that can come about with credential vaulting, for example, where they don't have to keep track of the credentials, they're automatically rotated on the back end. You know, you've got the equivalent of a single sign-on service to access your DevOps resources, right? And then you've taken away that friction, and you've taken a load off the developers. On the desktop, the desktop equivalent is, oh, a nice fingerprint to unlock your laptop just takes a second, you're not having to retype your password.

And so, you don't mind so much if your screen locks when you go up to grab a cup of tea or coffee or go for lunch, and you come back. So, I think those are some of the examples how you can get the dynamics right that actually encourage people to follow best practices. Those guys don't get up for coffee and lunch, do they? They're just rooted to their chair.

So, I can't remember now how we decided to do this, but Alicia, I know that we thought that we would take it in turns, but I still think that you need to give us a little bit of maybe thought on this one as well, quickly, before we move on to your myth. Yeah, I mean, again, I think the general problem is people think that security has to be a pain.

And so, one of our challenges is to make sure that, say, when you're logging into a single sign-on type portal, which is one of our main focuses, that it's as easy as possible so that you can use your fingerprint, that you can use something that's immediately available, that you're not trying to memorize a whole bunch of passwords. We're trying to make this as smooth as possible. You've got a nice, easy panel where you can see all the applications, you don't have to memorize or create your own bookmarks to get access to all the applications that you need to get access to.

So, as much as we can make it easy and smooth for the end users, they're more likely to want to use it. They have a new application that everybody needs to use. They're like, oh, we've got to add it to the portal, right? Everybody needs to get access to this easily.

Well, it's interesting you mentioned SSO there, which I think you did. I did. Yes.

See, we didn't just throw this together, because the next myth that I've got up my sleeve is SSO, single sign-on, for those of you who perhaps are wondering what that is, is less secure. And I can see why people would say that, because they think that it's more secure to have lots of factors when you sign on, and people have a feeling of security when they get asked to add another PIN number or something on top.

So, how do you assure people that SSO is secure? Yeah, I think part of the problem there is that they're also viewing it as, if I make it so that you can log in one place and you get access to all these applications, that now I have this single point that if they can break through that one point, now we've opened up all the doors. They've gotten through the castle, basically. But the idea is that you want to protect that point as much as possible, right? The alternative is having what you described, a whole bunch of different applications. They all have their own passwords.

They all have their own ways that we've got to log into them. So, there's all these different ways that now people have to keep track of these passwords and keep track of all these different applications. And how do you as an administrator make sure that they are logging in securely, that they have complex passwords that are hard to hack, that they are using additional authentication factors so they aren't subject to brute force attacks where somebody's just trying as many usernames and passwords as possible to get into an application?

So, what you want to do is put everything in the nice little castle, and you protect that one door to get in. And you can put as many guards as you want to in front of that. And if you have even applications within there, resources within there that you want to protect a little more, you can do that as well. But you want to make sure that that single entry point, again, is as secure as possible, that you've got, again, the complex passwords. You've got additional authentication factors. And make it as easy as possible for the user.

So, again, they just want to enter through the door. Now they can do what they need to do to complete their jobs.

So, is it right that SSO, once you're logged into one application, you can then roam around to all sorts of others? Or is it not as simple as that?

Well, it's the same. That's the basic idea, right? Single sign-on. I'm logging in once, and now I should be able to get access to my other applications. And ideally, you've set up a federation-type relationship between that initial identity provider, the SSO portal, so to speak, and these other applications, such that you're not even using passwords to get into those other applications. They have to log into that SSO portal first, and then they can log into the other applications.

There's a trust relationship that's set up between the applications and what we call the IDP, that SSO portal identity provider. I think I was going to say, Paul, that, yeah, that federation step is absolutely key. Because it's without that, without that centralized control, you're really relying on security by obscurity. And users are going to reuse the same password in different applications. They're not going to keep the passwords up to date. The accounts will lie dormant, et cetera.

There are all sorts of reasons why the chaos associated with dozens of applications per user, and even small companies with 100 employees, they will have dozens, or even sometimes they have more applications than they have employees. So we're not talking about 5 or 10 applications to keep control of. So that centralized management and order far outweighs the obscurity of, well, I'll just let the systems be separate and apart. And then your experience with customers, are they gradually becoming more comfortable with SSO? Are they asking for it?

Yeah, yeah. Yes, I think it's now accepted as standard that federation component is key. And they're trying to reduce the number of applications that don't support standards like SAML or OIDC, Open Identity Connect, which are the ways that you control, centrally control authentication to those applications.

Actually, that's a point that's just, I've been thinking about a lot recently is, you mentioned SAML just then. It seems to me that the world is never, our world is never happy unless there's a new identity protocol or authentication protocol to be made, which then makes all the others kind of get annoyed and jealous. But it does mean that people think, oh, maybe that one's better. So then the whole industry then has to start, if it catches on, then they have to make it compliant. Do we actually need yet more standards and protocols?

Well, so there are different standards, obviously, for different actions within the architecture. But where we're talking about how a central identity provider, IDP, it's often called, interacts with an application, that's the federation standards. SAML is very effective. It's very powerful. You can do some really interesting things, like passing fine grain entitlements and rights at the authentication time to the application that control what a user can do without having to go and make changes statically in the application. There is a new standard, OIDC.

If an application supports SAML, that's fine for majority of use cases. But the OIDC does have some improvements. It's more flexible for a number of different types of authentication flows. So if you're doing, if you're creating a new application, you make it compatible with OIDC, you don't need to worry about SAML, probably. But absolutely, SAML is rock solid. And I think the more mature security teams or security focused organizations will say, we need, when we're on board or when we're going to select a new application vendor, they need to support SAML or OIDC.

They have to support that federation. Okay. Do you have a view on this, Alicia? Do you live for new standards? Always trying to keep up with new standards. Tomorrow could be International Identity Standards Day. You never know. I still think, I mean, the majority of the applications out there are still supporting SAML. So it's not going away anytime soon. But I think Stuart is correct that the newer applications, they are going to start off probably with OIDC. And we are seeing, of course, applications that have supported SAML for quite some time now adding in support for OIDC.

But still, SAML owns the market as far as the majority of connectors that we have are all SAML. Okay, great.

Well, my next myth is a big one. And to introduce it, on my phone, I have a sticker, which I picked up at one of these security conferences that we all go to, identity conferences. And it says passwords, 60% of the time, they work every time.

Now, I think that's meant to be funny. But I don't really get the joke. Is it saying that passwords are crap because they only work 60% of the time? Anyway.

I mean, fat, fat fingers, 60% of the time, you actually type what you think you're typing. Yeah. But anyway, I don't know if it's not going to work on the screen. So the myth that we actually is sort of around that is because passwords have a terrible reputation now. And people can barely use the word without spitting. So the myth is that we've kind of got to this point where everyone says passwords are dead, and there's no safe way to use them at all, they should go. So I remember who's who's asked me this one now.

Yeah, no, I'd love to because this is this is one of my pet topics. It's broken down already, Alicia.

I mean, you know, he's taking your myths. Yeah. No.

So with, you know, with passwords, there, you know, let's look at any password can be hacked. Well, that's true. But that doesn't mean it doesn't have a place.

And, you know, what's the computing power required to do it? And do you have a quantum computer to do it instantly, etc, right?

You know, and then people, you know, and the other thing is, users will always reuse passwords, well, the reuse passwords, if they have to have too many passwords, and you make it too difficult for them to use them, you know, or to come up with ones, you know, so part of that, where I think the, the recommend, you know, best practices have shifted over time is just choose a pass phrase that's longer, you know, lyrics to a song that you like, that rather than having them change a password every month, and if they're changing 15 passwords every month, of course, they're going to forget and the 60% of the time, the work will go down to 10% of the time because you're right, so you're making it too difficult for passwords to be useful.

Right. So I think we're passwords have a very high level of entropy, that is, you can come up with with if you allow phrases allowing special characters help that it does take more computing cycles to be able to, you know, do these rainbow attacks on on hash values, if a bad actor got into a password store, etc.

So let's just say that, particularly when you've got the single sign on, if you want to use passwords as part of your single sign on authentication, it's something you know, which is different to something you have, for example, a hardware token, or your phone, or, you know, something you are, which would be biometrics, you know, your fingerprint, your, your facial face recognition. So the password is something different from those. So when you use it in conjunction with other factors, it will decrease risk, not increase risk.

I think the point is, don't just rely on passwords and allow and if if users only have a couple of passwords that they use, then if they change it once a month, or once every six months, whatever, it's not such as it's easy for them to remember. And if a password, it's also easier to protect the password stores when you've only got one or two password stores in your organization, and not 50 of them, right.

And also when the password stores are under your control, and not, you know, if you've got a third party vendor that only supports password authentication and doesn't support federation, you're relying on them to safe, you'll keep your past those passwords safe. Right, I've always thought actually, the end users, the great public employees would actually like passwords, you see, but if we could diversify device a system where they can actually use the same password for every single thing they sign on to securely, they will be happy because I think that's why passwords persist, persist.

Because, you know, it's quite convenient. And, well, also, it's because it's something that you know, yes, you can forget it. But probably, it's easier to lose your phone or forget it at home, then necessarily to forget a password if you got one password that you're using every day, right. And there isn't yet a perfect authentication factor. There isn't that factor that when your laptop and phone are stolen, and you need to log into to contact work to tell somebody, you know, what do you do, you're stuck when the things you have are gone.

And the things that know who you are with your fingerprint, etc, are gone, what do you do, so that's, that's where a password can play a role in that partial authentication. Now, I think we will get that perfect auth factor. I think identity verification, for example, is getting very close, where if you've got your passport or your driving license, or maybe company does have a, you know, a photo of you, you know, as a part of the employee record, you can do a liveness test and verify that it is you, etc.

So, as those advances, they become less expensive and faster and more convenient to use, then I think we will see a gradual shift away. But for everyday use, password as one of multiple factors, I think still has a role to play. What I tend to do is I'll set up a very incredibly secure password in on my iPhone, thanks to Apple's generating password tool, which is great until I then try and log on to the same account on the web. And of course, I have no idea what that password was. I then have to then open the iPhone, open passwords, and then type in something that's like 25 characters long.

But that's just, yeah, that's just the way I work. But yes, so Alicia, anything on passwords?

Because, you know, we, we're still going to be talking about passwords in 15 years. I just always like the passphrase, because it was actually something that I was introduced to when I started working here a few years ago. And so I started, I used a really long poem that I'd memorized, and I've just been rotating through and I realized I've been here long enough, I'm, I'm almost to the end of the poem. So I'm gonna have to learn a new poem.

Yeah, I tried that as well. The passphrase, like, you know, a very long address or something.

But yeah, I tried everything. Let's, let's move on to the next myth, which is, let me see now.

Well, those nicely from our previous discussions. Oh, you already know that you How do you know the myth? This is entirely spontaneous. So the myth is, if you have MFA, you're safe.

So Alicia, this is yours. Yeah, so I mean, we have talked about right, just using a password on its own is not going to be safe. So you do need an additional authentication factor. But we also need to realize that not all those authentication fact, additional authentication factors are the most secure as Stuart was saying, you know, we're still not reaching any perfect authentication factor. And even with the ones that we do have, some are a little bit better than others. So if we talk about something like security questions, people can figure out what those security questions are.

So those are on the line of the not so secure. And you do want that combination of something that you know, plus the something that you have, or the something that you are. So it's ideal that if you are using passwords, to use something different, like biometrics, or, you know, a passkey or something along those lines, so that we've got something else, other than just again, that password that we're going through.

So yes, we need MFA. But again, we have to look at those additional authentication factors that we're using, and make sure that they aren't, you know, can't be spoofed.

Can't, you know, other people can't get a hold of them in an easy way. And there are ways of even enhancing that by implementing things like adaptive authentication, where we're paying attention to the behaviors, right, where the people logged in from the machines that they're using the browsers that they're using the locations that they're coming from. And we're determining that the user is logging in sort of using that usual behavior. And if it's something outside of that, then maybe blocking them or prompting them for additional authentication factors.

So we can tell that maybe somebody has gotten a hold basically of their password, and they're trying to kind of hack their way into that account. So we want to put up some additional protections, you know, additional hoops that they have to jump through in order to get in themselves.

Okay, at this point, we've got a question come in from, I don't think this is there. He's John Kolb. I hope I pronounced that. But they say, Federation is more than authentication. It's also between companies using the same application. How do you see authorization authentication in relation to OADC or SAML, knowing that users have to be provisioned first in an application?

So yeah, the overlap between authentication and authorization is an important one and not one that is, I was going to say that people don't understand. It's not that it's there are, it's not necessarily intuitive. There's not a clear line between it.

Well, I don't think people do understand. I think people think it is the same thing. And why do we have two words for the same thing? So I mentioned earlier about SAML being quite powerful, where you can send these fine grain entitlements with it in real time.

That actually is what the person, the listener was talking about, where they're saying, well, authorization, those fine grain entitlements, what is a user authorized to do, what data can they access in the application, are a fine grain description of rights rather than the authentication, which is this user has successfully passed authentication challenges, and you should give them access. So what they can do within the application, that's the authorization.

Now, SAML does support it, OIDC does it in a more generalized and powerful way, because you create a JWT access token, for example, that can be passed around to backend services that have all the entitlements or rights that a user should have included in it. And it's a very flexible, powerful tool. So because this SAML authentication and the OIDC authentication flow can include entitlements with it, the user doesn't have to pre-exist in the application. Some applications support what we call JIT, just-in-time provisioning.

And this can even be when you federate between your identity provider and a partner's identity provider, what they were talking about, the kind of B2B connection. Now, in that case, you're trusting your partner's identity provider to say, to validate that the user has gone through their authentication checks successfully. So we call it trusted IDP, you're trusting a third party for the authentication flow.

So really, in that case, our IDP is the application, right? We're trusting an external source to authenticate the user and say the user, tell us that the user's successfully authenticated. That can be real time. So that's great. It's flexible. What it doesn't do is remove users who are no longer active, because it's passing entitlements in real time. So when the user gets access to the application, their authorization is always up to date. But there's no communication to say this user is no longer active. Delete them. And that's why we have provisioning.

They're different solutions, different standards, SCIM, REST, for the provisioning side of things. Sure. So this actually, almost as if we rehearsed this, the next myth is about authentication. So that was a timely question. But my myth, this one, is authentication is only for creating sessions. Or if your session cookie is stolen, you're toast. Or the company's toast. So yeah. You just talked, obviously, about authentication. But obviously, that's not true. Yes.

Well, cookies are not toast. So there you go.

Very, very clear. Oh, I didn't even realize.

Yeah, I didn't even connect that one. Yeah. Toasted cookies. That's right. Toasted cookies. Yeah. So this comes back to federation. So when you think of federation, you think of connections between different entities. And while we've been talking about the identity provider is that central hub, is a good way. A hub and spoke model is the way people often think about it. And the different applications are all spokes on that hub.

Now, every time a user goes to a new application, there is a federation event that takes place. So a user, when they log into their SSO portal, doesn't suddenly have active sessions to all the applications that they have access to. Say 50 applications. It's only when they click on that tile, they launch the application, that the application talks to the identity provider and says, does this user already have an active SSO session? And the identity provider says, yes.

Therefore, the application will let the user in. So when it comes to session cookie theft, if that SSO session cookie is stolen, there are still ways to do checks mid in flight when a user is accessing a new application. So when they launch, let's say a bad actor does steal the SSO session cookie, and they launch their SAS application.

Well, some identity providers, like one login, will do a risk check. So it can say, is this from a known machine, IP address, geographic location? Is there impossible travel involved? The user just logged in from London in the UK, and then all of a sudden, they're logging in from San Francisco.

Wait, that doesn't make sense. So the risks can be detected, and the user can be challenged based on with another authentication. Or you can just say, OK, for our HR team or our finance team, when they're logging into their systems, they log into their finance system, they will always be challenged with MFA again, even though they've logged into their SSO portal. So you think of it as a step-up challenge. And that's best practice.

I think a lot of organizations are not doing that, and it's very important that they do, particularly with the way that session cookie theft has really been on the rise in the last two years, and where now there's malware that will steal session cookies, for example. It's very automated now. It's no longer a targeted attack where somebody gets a backdoor onto your machine and manually grabs your session cookie. It's automated now. OK. We've got a question, but I think I might leave this near to the end, just so whoever sent this knows that we do actually read the questions.

But the person is talking about implementation and execution. And where do you get started on that? But let's just sort of prepare you for that. Quite a tricky question, actually. So we'll come back to that.

Thank you, viewer, whoever you are, for that one. But let's move on to the next actual myth. And this is Alicia's, I think. And I think we're getting into dangerous territory privilege access, which just is another level of complication for many people. But the myth is users with access to critical information must always use strong authentication, or the same authentication policy should apply across the board. So two myths for the price of one there.

But yeah, so Alicia, what's wrong with that? Well, I think Stuart actually sort of touched upon it in his answer to the last question, where he talked about when you want to access maybe particular applications, that you do step up authentication.

So A, you don't have to have the same policies for everybody across the board. So there might be some users who you're requiring, like they use their YubiKey versus other users can use an authenticator app, depending upon, again, the types of applications or the data that they need to access. But even within that process, once they've logged into the portal, again, they're different applications, and you might have different policies for different applications.

So again, additional hoops, for example, the DevOps team, they need to get access to AWS. And you know, we're hosting all of your services. And you want to make sure that that's extra secure. So you might require that, you know, they can log into the portal and get access to their email, and they can get access to, you know, Teams or whatever else, you know, applications they need for their basic job. And they're only required, you know, password and maybe authenticator app to get access to those type that level.

But when they want to go to AWS, they've got to be logged into the corporate network. So they have to be connected to the VPN, and perhaps prompt them for an additional authentication factor. So if somebody has, for example, stolen their session cookie, they're not going to be able to get into AWS, because they're going to have these additional requirements there.

And again, you have that ability now to protect certain resources with different levels of security. Yeah, I'm gonna throw in a left field thing now, but zero trust is something that is bandied around, and has been for the last few years.

In fact, I had a bit of a revival, I think it kind of came, died a little, and then three years late ago, it suddenly became the in thing again. But I, I like to say there's no such, there's no such thing as zero trust, as much as there is no such thing as full trust. But you can't have 100% this, this is my myth. 100% zero trust is impossible. But is that a? Would you agree with that? Stuart?

Oh, yeah. No, absolutely.

I mean, you know, how are you 100% sure that the person that you think is doing the action is not only the person you think, but also that what they're doing, they won't be misused. Right?

You are, there are, you're always, it's some, I think, trust, sometimes I think it's better to think about risk. We're not what, like you were saying, you can't have zero risk, there's always going to be some level of risk associated with access that you're granting, and author authorization, authorized actions that you're allowing, you just have to decide what level of risk is acceptable. And based on what the person is doing, and what they're accessing, the risk will go up.

Therefore, you have to take more steps to reduce that risk. Yeah, for sure. For sure.

At least, I mean, I just think that zero trust has become a culture almost, and a kind of religion, even that, and people feel they have to somehow create a zero trust environment. And they get very stressed about it.

Yeah, I think it's a mindset, right? I mean, so it's a way of looking at things. But you always have to realize, I mean, we can't be perfect, right?

So it's, it's a goal that we're always trying to reach, but we realize we can't reach it. You know, we all have goals, like we're going to exercise every single day. And only vegetables, right? So we can always aim for these goals. But it's not like, you know, we're going to become this perfect being at any point.

No, well, I just wanted to get my little, my little to two pounds worth to use an English version of an American saying, because I think two English pounds are probably worth two cents. But yeah, this, this obsession with zero trust, I think sometimes gets a little out of hand.

But, but the next myth, then, is interesting, actually, because I, I actually would agree with this myth. I thought it would be but biometrics are more secure than passwords.

Yeah, okay. I think. So this is partly where hype in the market in the media, when you've got exciting new innovations, can kind of obscure just the fundamental logic behind a new system.

So, you know, with a biometric, okay, you think it's, it's personal and unique identifier, and biometrics, you think, I think, intrinsically, people think they can't be copied, and they're 100% accurate. Well, they're not, they're a digital representation of a person at a point in a point of at a point of time. So when you register your face or your fingerprint, it's based on what that looks like at one point.

And so, you know, when I was doing some rough work on my hands over a weekend, and then on Monday, my fingerprint would not work on my laptop, because my finger had been worn, worn down. Right.

But also, if you think about it, so biometrics, a scan of your fingerprint is stored in a digital format. Therefore, if you can get access to that store, you know, it can be taken, it can be copied. So we're relying on hardware manufacturers, etc, to securely store those biometrics. And that is part of the reason why I prefer on device biometrics, like on your phone, your laptop, rather than centrally stored, where I think they'd, you know, a hacker could go after a million or a billion biometrics, rather than they have to get onto your personal phone, just to get your fingerprint.

But but also, if you think about it, the when I scan my fingerprint on my phone, it's that particular make and model inversion is interpreting my fingerprint in a very particular way. You couldn't go then and use that fingerprint on a different, totally different device that that scan, because it wouldn't mean anything. So they can have a high degree of accuracy, but they certainly aren't perfect, you know, so there are false positives.

And I just think it's important that people understand, take a step back and understand what are their strengths and what are their weaknesses, and deploy them carefully. Like, yeah, I mean, I think it's absolutely because, like I said, I even, you know, kind of assumed biometrics are intrinsically intrinsically safer or more secure than passwords. But you've clearly shown that's not necessarily the case.

So well, so I just one point on that, I think one reason why biometrics are secure, it's not the biometrics themselves. But it's that chip manufacturers, phone manufacturers have actually done quite a lot to store them securely on your device. So it's the way they're stored that makes them more secure than the way many passwords are stored. But it's not the concept itself.

Okay, right. How many have we got? A few. I'm just gonna have a look. We've got a comment, right, I would say, interesting comment.

Also, I don't know who this is from. But the person says, I'd say that some implementations of zero trust actually reanimate the myth of security slows down business. As you have to apply for rights, do anything in the systems you're supposed to work in?

Yes, interesting point. I think it's worth maybe a little discussion.

Yeah, so I, again, the problem is how they're implementing that, right? Is there a smoother way of implementing it? I think when we start locking things down, security can get in the way. But as we said, we've been involving ways to make it easier for the users. And so they have to take a step back and see, what is it that they're asking them to sort of reauthenticate? Or they're asking them to ask for additional information? How can they make that smoother, right? Could they make it something that they're just gonna maybe use their fingerprint instead of having to enter in a password again?

So it all depends upon who's doing the implementation and what their priorities are. I think security has to start thinking about the usability side of it. Yeah.

And again, I think it's because people have got so hung up on zero trust, it's hammered at them. Every conference they go to, there's gonna be at least five presentations on how to do zero trust. And I think that question is very good.

Go ahead, Stuart. No, I think the user might be alluding to least privilege as well there, because that's where... Let's see if they say yes.

Well, just with the organization says, you've got no rights until we give them to you. You don't have access to applications unless you request it and approved. And that goes more towards governance and also certain privilege access management models. That definitely comes back to the deployment question and model. How do you deploy it? Because you do have to be careful that when you're taking a least privilege approach or a zero trust approach, you don't go too far.

Yes, you can definitely go too far. So it will affect the business. I think the point I was making at the beginning was you have the tools to massively reduce risk without impacting the business. You can still impact the business if you go too far or if you do it the wrong way, or if you don't have the right tools. So you have to decide how far do I go with least privilege? I can go quite far if I have automated ways of self-service access requests that get approved by a manager. It doesn't raise a help desk ticket and cost a lot of money, et cetera.

So if you have those tools in place, you can do a lot more. Yeah. Okay.

Well, thanks for that comment there. I mean, you could do a whole webinar on that subject alone and maybe we will. But back to the myths and geo-blocking is our latest myth or other, the myth is that it's a vital part of corporate security and compliance.

And again, geo-blocking is a relatively recent term, is it? Or is that like Lucy? I love Lucy. It's actually been around since 1952 or whatever. I think it's been around quite that long, but it's not totally new. Yeah.

So, I mean, the idea is obviously keeping track basically where the requests are coming from. And you might block requests from certain regions because you know that bad actors tend to be connecting from those regions and you shouldn't have any true business reasons to be connecting from there. So it can work, but unfortunately, there are easy ways around it. They can connect to VPNs.

I mean, people even do that when they're blocked from access in certain sites or they're trying to hide where they're coming from. They're going to connect to some VPN so they can appear that they're coming from some other geographic region.

So, I mean, it can work for preventing certain types of attacks. Again, certain IP addresses, certain regions known for trying to overload your network or do other types of attacks. But not in a way that it's going to be the best way to protect you across the board, right? And that's what we're sort of talking about here. There's lots of different options and you have to use a combination. There is no one size fits all for this.

And so, geoblocking certainly has its place. Passwords certainly have their place. Biometrics work as well, but we've got to use these things in combination and really figure out what we're trying to protect ourselves and what are our priorities.

Yeah, I think with geoblocking, it's like putting up a one foot high fence along your pavement, along the sidewalk in front of your house. It'll stop most people from walking on your lawn, but they can still step over it if they wanted to. It's really only good against automated boss attacks, but even so many of those now use VPNs.

So, trusting the source region based on the source IP address of network traffic, you can't put a lot of weight on that. Sure. Okay.

So, the next myth is you shouldn't allow BYOD in your business. Now, that's a term that has been around for a while and it was very fashionable. I think when the iPhone came out, the first iPhone and everybody wanted an iPhone and then that's when BYOD was invented.

But yeah, so the myth is that we shouldn't allow people to bring in their own devices and they shouldn't be allowed to choose. They should get the corporate Dell machine that's five years out of date and be happy.

Yeah, well, I think this one, this idea that you shouldn't allow it goes back a bit, but I think it was served a mighty blow when we went into lockdown, right? And so many people were forced to work from home and didn't have work computers at home.

So, what were they going to do? If they were going to work, they were going to have to work from their own devices.

I mean, that's an extreme case, but there are also many organizations where communities that they want to grant access to resources, these could be remote workers, like it could be store workers that you now want them to get their paychecks or do their timesheets from home. You're not going to give every retail worker a work laptop to take home.

So, for business flexibility and efficiency, you need to support non-managed, non-corporate devices, but you have to do it in a way that reduces the risk. So, there are other forms of mitigation available and things like the WebAuthn, which is a phishing resistant authentication standard, and that often uses biometrics. That's a great way to prevent phishing attacks and encouraging your users to have strong MFA for when they use a personal device. It helps reduce the risk.

Also, you can say, well, you can access your timesheets and your payslips, et cetera, but you can't access the finance app or the HR app from a BYOD device. You can only access it from a corporate device. You mentioned the lockdown, but it was, well, not funny, but suddenly we were in extreme, people were having to use the family PC or their son's school laptop, which, of course, had no security built in.

It had, oh, God knows how many bits of malware on it and so on. So, that was a stressful time.

But, as you say, it then forced businesses to think about BYOD more seriously. Okay, we're coming, I want to get that question in that I mentioned, the implementation and execution.

Just, I don't know if you've got any thoughts, because, just to repeat, they said implementation and execution is always the hardest part of any plan, true. So, where and how do you recommend organizations get started? I presume they mean get started with identity management and access.

Yeah, so, this is actually the reason why I've got, I've been in security for several decades, used to do database security, etc. But, I got into identity access since the 50s, apparently.

So, not quite that long ago. So, yes, I got into this space because I saw this opportunity to streamline the user experience in the business. That was joining OneLogin back in 2017, which was one of the first identity as a service platforms.

Now, because it runs as a service, you don't have to have anything on-premise at all. It's possible to use a full range of flexibility without you spinning up any servers or running agents, this or that.

And so, it's very quick to actually start getting your users onto an SSO portal, federating just maybe your top three or four applications that people spend 80% of their time on, right? Your collaboration, your HR system, your email, etc.

Now, the advantage with this is that the federation with an application is very quick, especially nowadays, you know, identity providers like OneLogin have thousands of out-of-the-box connectors. You just fill in about four lines and it literally takes minutes.

But also, it means you can centrally control that authentication flow that we've been talking about. If you've got Active Directory, you can hook your identity, your IDAS into Active Directory and users will use the same password as they do for Active Directory.

So, you're not even changing their password or username. And you can add on MFA centrally, so you can prompt them saying, well, you know, just prompting them, asking them to register MFA apps so they can use push notifications, for example. It's very quick and easy.

So, I would, when you're talking about identity and access management, which includes privilege access management, governance, etc., I would start with that IDAS authentication federation step because you get immediate results. It's weeks. It doesn't even have to be months for you to deploy it.

Okay, Alicia, would you like to add anything to that? Yeah, just one of the things that we stress when we're talking to customers and even training people how to, you know, use OneLogin is the order.

And so, you know, worrying about where your users are coming from is the first step. So, are you going to sync with something like Active Directory, existing directories that you already have in your environment, getting those users in, and then securing that initial login flow, right?

So, even before they start getting into the castle security, that's what we've talked about, right? Want to make sure that we're using strong authentication factors that, you know, they understand the password policy so they can just get into the castle securely and then start adding in those applications. And we talked about the provisioning side of it, making sure users, we of course know how users are going to be created within the applications first, and then they can log into those applications, so federate the applications.

And as much then as you can automate all of this, that would be the last step that you would look at. So, there's, it's a nice clean order if you just look up on it as basically those four steps. Where are my users coming from? How do I secure this? Start adding in my apps. See what I can automate. Those are the basic four steps. It doesn't seem as overwhelming, I think, when you break it down that way. Cool.

Okay, we have just enough time for one final myth, I think, and it's a good one, and it's something else that I used to believe, I'll confess. The myth is that my organization is too small to be at risk.

So, bust that one, Stuart. Well, I mean, if you've got a business, if you have an organization, it has value.

Otherwise, you wouldn't do it, right? So, there's always something valuable that can be taken away from you. And I think the, you know, so automated attacks can compromise any organization. They don't necessarily care how big the organization is. If it's automated, they'll just target anybody. And a business term is business continuity. The bottom line is attacks can stop your business, your organization from operating, stop it in its tracks.

So, a ransomware attack is a perfect example of that. You might not think your data is valuable, but if your disks, all your data is suddenly encrypted and you can't access any of it, you realize you can't really operate effectively. There aren't many organizations that are still have, are paper-based enough to actually operate even, you know, for 60 minutes. Okay.

Alicia, you have the chance to close this magnificent webinar with your thoughts. I, so as far as, again, the size of the organization, because the bad guys basically have this down to a science with automating, grabbing things like session cookies and passwords through malware and other places and just selling these lists to others who can then automatically break in and start ransoming your systems. No organization is too small.

They are, they're out to get whoever they can and find whatever holes they can. For sure. And also like, if you run it, I mean, like if you run a small business as I did, which is what I was referring to, you still have, you still have bank account details. You still have client details. They may be small, but it's, you know, they're useful to someone and they just get added to the great pile of stuff in on the dark web.

Yeah, absolutely. All right.

Well, thanks. I hope you enjoyed that. I enjoyed that. I hope that you at home watching also enjoyed it.

Then, as I said, right at the start, if any of your colleagues wish to view this, or if you want to watch it again for anything you missed, it will be on the Copenhagen website for download, probably from tomorrow onwards. In the meantime, let me thank both of you, Alicia Townsend and Stuart Sharp, both from One Identity for an excellent chat. And hopefully we can do this again. Thank you very much, Paul. Thank you. All right. Bye now. Bye.