Welcome to this Master Class video around advanced authentication within your organization. I'm Mike Cockbill, and with me, I have Solenne Le Guernic, who's a solution engineer for OneLogin in EMEA. In this session, we're going to cover off what advanced authentication is with a brief introduction. We're going to go through some best practices that we've seen when deploying advanced authentication as well as how we can overcome some key challenges during our deployment.
But first, an introduction. What actually is advanced authentication? Well, in today's digital age, cyber threats are becoming more frequent and sophisticated. And according to a Verizon 2022 data breach investigations report, 42% of the investigated breaches were due to stolen credentials. As a result, there is an increasing need for stronger authentication methods since those traditional auth methods, such as the combination of usernames and passwords, are no longer enough to protect sensitive information and systems from unauthorized access.
So advanced authentication is a cybersecurity approach that requires the use of additional security methods. And just to drill into those particular elements, we're using additional security methods to make it more difficult for hackers to gain unauthorized access. But how does it work? Well, advanced authentication relies on user verification methods that are less likely to be stolen or compromised by attacks like phishing or MFA fatigue.
Advanced authentication includes the use of two or more factors for authentication, such as something the user knows-- for example, a password, PIN, or security factor-- something the user has-- for example, a physical token, smart card, or mobile phone-- and something the user is-- for example, maybe biometrics like an iris scanner, fingerprint, or facial recognition. Added to that, we're using adaptive authentication and maybe even passwordless authentication.
For example, the user comes to do single sign-on to an application or a desktop client or maybe a web browser. The authentication system then looks at analyzing the different parameters of that auth mechanism. It determines the risk level, and then it uses that as a means of where to go next. For low-risk events, it may just ask for one authentication factor-- for example, a one-time passcode. For high-risk events, we might see that there are multiple proofs of identity needed-- for example, prompting for a one-time passcode plus a fingerprint or a security token.
If that validation is then successful, the user is granted access. And if it fails, then they're denied access altogether. And, of course, we're logging security events as well. So we're going above and beyond the standard MFA alone. And we're using additional measures as a means of allowing or denying access as well as making use of login alerting that may be within our system.
Why should you consider deploying advanced authentication within your environment? Well, first of all, we're enhancing security. The primary benefit of advanced authentication is enhancing security. We using MFA, which can significantly strengthen security, and then combining multiple factors together to make it exponentially more difficult for those unauthorized individuals to gain access.
We're also protecting against password-based attacks such as brute force, phishing, and other dictionary-based attacks. This can be mitigated with advanced authentication as we're adding in more secure authentication methods such as biometric scans, hardware tokens, and other methods that are not susceptible to common password-based attacks.
We're also helping to meet increasing compliance requirements. Given the rapid increase in breaches, there's many industries such as health care and financial services who are facing increasingly regulatory requirements. They're generally around data privacy and security, and advanced authentication is often a requirement for compliance with those regulations. If those companies fail to comply, there can be quite stiff financial penalties and other reputational damage, maybe other legal consequences as well. So rolling out advanced authentication allows us to protect against those from occurring.
Of course, it also improves the user experience. Whilst we're strengthening that security, we're enhancing the user experience and productivity. They might not have to remember complex passwords anymore. They're not having to enter lengthy security codes, and instead, they can simply use their fingerprint, facial recognition, et cetera, to authenticate themselves. And that gives them a streamlined authentication process and improves their productivity.
Added to that as well is the increase in scalability and adaptability. Solutions that are provided as part of that authentication mechanism can be implemented across platforms, from cloud-based services, mobile applications, even on-prem systems. So whether it's biometric smart cards or other authentication factors, advanced authentication systems can be adapted to those changing security landscapes, and ensuring that we're protecting against emerging threats. We can effectively safeguard systems, data, and users across the board and reduce the risk of unauthorized access and potential security breaches with that.
So let's look at a few best practices when it comes to deploying advanced authentication in your organizations. The first step is to look at performing a risk assessment. This is a real key step and, really, a priority number one. First of all, we need to identify those potential threats and vulnerabilities. What do we want to do with those? How do we want to mitigate them?
We need to determine what level of protection we've got for number one users and also our applications. Different users will have different protection requirements. Different applications will have different protection requirements. It might be a specific application needs to step up authentication because it's a high-risk application, whereas a general day-to-day collaborative application-- for example, Google Workspace or Office 365-- the user is allowed to sign in with just a username and password and MFA.
We also need to look at whether we need to establish strong authentication workflows for our privileged accounts, those that have got high-level access to each of our applications or even to our overall access management solutions. Role-based access control is key here as well as other things such as governance and attestation programs, looking at that ongoing access rather than one time, maybe a six-month review or even more regularly. Does the user still need that access? What are they doing with that access? When did they last use it? Does the manager think they still need that access? And are they, of course, still with the business? The objective for all of this is enhanced security posture and ensuring that we're reducing the chances of our environment being breached.
When we look at risk management, there are three main ways to manage the risk. First of all is we ignore it. Another way is we share it, and another, of course, is to mitigate it. And it's having a balanced approach around how we manage that risk. Some elements we might have to ignore because actually, it's extremely difficult to implement something to fully mitigate that risk. It might be we need to offload that risk to our insurance policy or maybe to a third-party vendor, or maybe we need to implement something to mitigate that risk. And this is how we'd give that balanced approach to when we are looking at how we manage our risk.
So I'm going to hand over to Solenne, who's going to go through the second best practice here.
Thank you, Mark. The second best practice would be to implement multifactor authentication. But let's come back to the basics. What is multifactor authentication, or MFA? Well, it's simply the combination of something you know, something you have, and something you are, so your password in combination with your mobile phone on which you can receive a push notification or use OTP code and biometrics-- a touch ID, fingerprints, face ID, those kind of things.
It makes it more difficult for hackers to breach your password. It's a must-have addition for your password. It's not simply the password. It's something else to add to be able to authenticate. And MFA is also a great replacement for password. If you want to go passwordless, you don't need to enter your password anymore. You can just use MFA-- multiple MFA, for example-- and that makes it even more difficult to breach your credential. But we'll come back to password lists later on.
Implementing MFA is great. Implementing effective MFA is even better. What does it mean? Well, it means that you need to know your users to make sure the MFA you're going to implement is going to work for all of them or that you have multiple MFA possible so that it can adapt to different users because depending on their job, they might not have the possibility to use the same MFA. Working in an office is not the same as working in a warehouse, so you might want to adapt your MFA factors depending on your users.
Then you need to use MFA in combination of single sign-on. What is single sign-on? One set of credentials to rule them all, meaning there's only one set of credentials to access multiple applications. So you just have one set of credentials to secure to be able to access application and resources. Choose strong factors, the ones that are more difficult to breach, more difficult to replicate-- like biometrics, for example-- and require at least two factors that you increase the difficulty for hackers to breach the credential. And then as I said at the beginning, which comes back to knowing your users, adapt to your audience. You adapt the MFA depending on the user it's going to apply to.
What does it mean with OneLogin? What does it look like? Most of the MFA settings are available in the security policies. You can create multiple security policies to adapt the rules to the different users that are going to log into your portal. OneLogin offers multiple security factors, which gives you flexibility and failover. You can make sure to enable several MFA factors for all your users so that they can have a backup in case one is not available at a specific time. They can use a backup one that they have configured in their user profile.
OneLogin also gives the option to step up authentication for you to protect even more the most sensitive application and resources that you have in your environment. You force the users to use MFA again when they want to open that specific application. And OneLogin also offers you the option to enable passwordless authentication by simply ticking a box in a security policy so that you can enable that login flow for a specific group of users that would benefit from it.
Those are screenshots from OneLogin platform to show you what it looks like. So as you can see on the left side of the slide, you have all the different factors available, which goes from OneLogin Protect, our mobile application that supports OTP code as well as push notification. We also have OneLogin SMS and OneLogin Email, the security question that can prove handy sometimes, WebAuthn to enable biometrics, and OneLogin voice, but we can also integrate some partners like Duo or YubiKey, but also other OTP applications like Microsoft and Google Authenticator.
And on the right side, you have a screenshot of some settings inside a security policy to show you how to enable MFA. It's simply a matter of ticking a box. And then you select the different MFA factor you want to enable for that specific security policy that will apply to a specific group of users. So as you can see, you can adapt depending on the population the security policy will apply.
OneLogin also gives you the option to enable certificate-based device trust, meaning you can decide to only allow access to your application to some specific devices on which a certificate has been installed. And so if you decide you want to limit the population of machines that can access your portal, you simply have to enable it in your security policy. And once this is enabled, your users won't be able to access the portal unless they are accessing it from the device you have installed a certificate on. This gives you some more control around the machine that can access your portal, and this can also be enabled in the security policy. You can use either OneLogin certificate or a third-party one and decide when your certificate is going to expire.
On this screenshot, you can see the different login flow that we have. I mentioned the passwordless earlier, but I'll come back later to passwordless. We can also offer a brute force defense flow that will swap password and MFA so that in case of a brute force attack, your accounts are not constantly locked out because the password field is never made available until MFA has been validated.
Let's come back to passwordless for a second. This login flow is becoming more and more popular because we know that passwords are easy to breach. We have so many passwords to remember that we often reuse personal passwords, or we use the same password for different resources. This becomes easier for a hacker to breach your password because once they have guessed it once, they can use it multiple times. So passwordless can be a great option to avoid that issue because it's more difficult to hack an MFA factor than a password.
How does it work? Well, it's pretty simple. When a user is going to log in to their portal, they're going to enter their ID. It can be email address, but it can also be something else. Once the ID has been entered, OneLogin is going to check the security policy that applies to that user. And they will receive a push notification on their mobile phone, for example. To validate that push notification, they will have to validate biometrics because nowadays, smartphones can accept biometrics, whether it's face ID or fingerprints. And so you can enforce the biometrics on mobile phone. And once the biometrics has been validated, then the user will be granted access to their portal. Very user-friendly login flow, no friction, very seamless, great for users and for administrators, very simple to implement since it's just a login flow to tick-- it's just a login flow to select in a security policy.
Now moving on to the third best practice-- adaptive authentication. What is adaptive authentication? Well, it's simply a matter of using contextual information from your users to decide on how we want them to authenticate to the portal. It allows you to provide dynamic authentication responses by enabling MFA bypass when the risk is low or deny access when the risk is too high, requires step-up authentication when needed, et cetera, et cetera. It delivers a positive user experience resulting in reduced friction, increased productivity. And it's going to strengthen your position overall.
To provide the dynamic response, we need to use contextual risk-based authentication. So OneLogin uses a Vigilance AI, which is an artificial intelligence that is going to calculate a risk score based on multiple different contextual information, like what application a user is trying to open, what browser they're logging from, where are they based geographically, what time of the day is it, what device is the user using, what is their IP address, et cetera, et cetera. Our Vigilance AI is also capable of detecting if two consecutive logins are possible.
For example, I'm based in Ireland. If I'm logging in at 10:00 AM in the morning in Ireland, is it possible that 15 minutes later, I'm logging from the UK? Probably not. So all those information can be gathered prior to login and used to adapt the security policy that will apply or simply deny access if we think the risk is too high.
In OneLogin, as I was saying, our AI is called Vigilance AI, and it's going to calculate a risk score for every single connection, whether it's to the portal or to an application that is connected to the portal. We use Smart MFA to remove MFA completely if the risk score is very low. This is simply a threshold that administrator has to set up in the security policy. And once this is enabled, over time, when Vigilance AI knows the contextual information around the user login, like where they are logging from, what machine they are using, what web browser, et cetera, et cetera, they will know their behavior, the generic behavior. And so over time, the risk score is going to become lower and lower. And when it's very low, we might want to remove the need for MFA because we know the context around that user's login, and we want to ease their login process.
On the other hand, with Smart Access, we can completely deny access if the risk is too high. So again, you will set up a threshold as an administrator and decide that when the risk is very high, you want to block the access, because maybe they're accessing from an airport where the network is very weak, the security of the network is very weak, and you don't want them to access the platform until they connect to their VPN or until they are back home and they can connect to a more secure network. And when you enable Smart Access, the users won't be able to access their portal when the risk is very high. Because again, the AI knows the behavior of that users. And so when it will change to the point where there's a huge difference between the previous login and this one, then the risk will become very high, and we can block the access.
Using our Smart Hooks, we can enable dynamic custom flows, meaning that instead of removing MFA or completely block access, you can go in between and simply switch the security policy. If the risks becomes high, then you might want them to validate a more secure MFA to make sure it's still the right person that's trying to access the application. And so our Smart Hooks will help you to automatically switch the security policy depending on the risk. As an admin, you can select the threshold, and you can select the different policies that will be used, from which policy your user is going to log in, and then from which one they will be switched if the risk is too high, et cetera, et cetera.
This is what a Smart Hook will look like. So as you can see, it's a little bit more coding. It's not inside of OneLogin UI, so it's really if you want to go deeper and secure your environment even more. And so this Smart Hooks shows you how to adapt the security policy when the risk score is too high. So here, we have set a threshold to 90. And we decide to move them to a different security policy that is represented with the ID here.
And this policy has been set up in OneLogin. And so simply, the Smart Hook is going to switch the security policy when the risk score is going to become more than 90. So I'm not going to go too deep on this part. We have a video around Smart Hooks, so feel free to have a look at it if you want to know more about it.
Now let's have a look at a video to show a real example of what I've just talked about in adaptive authentication and the different possibility you can set in OneLogin. This is OneLogin Administrator Dashboard, and we are going to have a look at the users now. We'll check a username Dante to see everything that applies to him.
So he's part of the department sales, and he's an account executive. So using the information we have applied in a role and a security policy, we can see he is part of the brute force defense group, and smart access has been enabled, meaning when the risk is too high, we deny the access. We can see the MFA factor that is registered to his profile, which is OneLogin Protect, our mobile application.
And now we'll see what it looks like for Dante when he's logging into his portal. So he's entering his username. And because he is using a brute force flow, he will have to validate his MFA factors before he can enter his password. So now he's receiving a push notification on his mobile phone, has to validate his biometrics with the fingerprints, and now he can enter his password. Once the password and MFA will be validated, then he can access his portal with all his application. That's very simple.
Now we're going to log Dante out. And we can see that because the risk score has decreased, it doesn't have to validate MFA again. He simply has to enter his password. Remember, Dante is using the brute force defense flow, so MFA and the password have been swapped.
Now we are using a Tor browser, so it's supposed to increase the risk score. Now that Dante has entered his username, we're going to see the login flow, so MFA request, again brute force defense flow, so password will come afterwards. The push notification appears on the phone, so we have to validate it, validate biometrics. Then Dante will have to enter his password.
And even though the credentials are correct, he will see access denied because Tor browser is considered not secure, and so the risk is very high. If we have a look at it in the activity and in the events log, we can see the different risk score, and we can see all the different reasons why the risk score was so high. So we have a different browser, different location, et cetera, et cetera. So we can see the different risk score related to Dante's login.
So the time when the MFA has been bypassed, the risk score statistics-- as you can see here, the risk score is pretty low. There's no risk reason, not much compared to the previous login. And you have more information around the Smart Hooks. And the time when he was using the Tor browser, we can see the risk score was maximum, 100. And if we click on it, we have all the reasons why, and especially the Tor network. We can see this was a reason why the authentication was failed and that it was not able to log into his portal. So you can have all this information from an administrator standpoint to be able to understand your users' behavior.
Now we're going to use a web browser with a VPN, and now we connect from the USA, so the same process apply. Dante is going to enter his username, validate his MFA after receiving a push notification on his mobile phone, and validate biometrics. Once again, we are using a brute force defense, so the password will be required afterwards. Dante validated his password, and then he will be granted access to this portal, same as before.
Now we're going to log out, and we're going to change the location using the VPN. We're going to use Singapore so there is a huge jump in between the two locations. So Dante will enter his username, and now you can see get access denied straight away. No requests for MFA, no requests for password. And we'll check why by going in the event log. So just refresh the page. So we see the previous login risk score was 34, not much information, and he was able to log in all good on that side. And the risk score 34 once again, so pretty low.
Now, if we have a look at the time where Dante was not able to log in, again, risk score is maximum, 100. And what we can see is Singapore is blacklisted. This is something you can enable in the Smart Hooks. You can block some countries if you don't want your users to log from them, or on the opposite, enable some specific countries only so that you control the location where users are logging from. So this is just an example of what you can do with adaptive authentication.
Now I'll hand it over to Mark so that he can tell you more about the monitoring and analysis of your users' activity.
We saw there that we're gathering a huge amount of information when it comes to users authenticating, or even when we're looking at admins when they're navigating through the admin portal and making changes, et cetera. We want to do something when we see something that we don't like. So, of course, we can look at tooling that we can integrate with OneLogin to help us with that.
Integrating a SIEM or a CASB-- for example, maybe Splunk or Sumo Logic-- allows us to do more. So we can do real-time alerting for administrators or even security teams. We can look at identifying security threats very, very quickly. We can then take appropriate actions, and that then enables teams to investigate and mitigate potential risks very promptly.
Not only does it allow us to start doing things around the risks that we're seeing in the system, but it also allows us to start adjusting our settings over time to stay current with those threats that are out there, but also our users' activities. So are we seeing that users are starting to access in different ways or different applications from different places where we have got new offices that have opened-- therefore, new IP addresses needs to be allowed, et cetera? This allows us to help ensure the ongoing effectiveness of our security measures and therefore makes our user experience great as well as balancing that with the security posture.
On screen here are a couple of examples of dashboarding that we can build out of Sumo Logic. Both Sumo and Splunk we have out-of-the-box dashboarding for within those particular solutions, so it's very quick to integrate with OneLogin. You can do that via either our webhooks or our API. And, of course, here's another view around the dashboarding that we have, because it's not just visualizing it. It's reporting as well on top.
We can also dive deeper into particular functionality. Maybe we want to look at specific functions like adaptive MFA. Where are our users logging in from? What sort of risk scores are we seeing? Are we seeing any spikes in certain login events? Maybe a certain user is getting attacked, and we want to be alerted around that so we can then mitigate that above and beyond maybe alert the user to that particular attack occurring.
I'm going to hand over to Solenne, who's going to go through our last best practice, which is around training and educating your users.
It's great to implement MFA. It's great to adapt the security policies depending on your user behavior to enable Smart Hooks to make sure you have the right policy that applies depending on the risk score that your user is going to have when they log in, but it's even better if you train and educate your users. You need to work together to secure your application even more, to secure their identities even more. And you need to tell them and to train them on what you're going to do, explain them that after some time, maybe there won't be requests for MFA, and that's OK. We know their behavior, login behavior, and we don't need to validate that.
Maybe sometime they will see an access denied because they are logging in from an airport. They are traveling, and they cannot log in. So they need to understand that if the login is not secure, it can happen. And then there might be no need to contact IT. Just wait to be back on a more secure position or connect to a VPN. This is crucial for you to train and educate your users so that they know what you're trying to do, why you're trying to do it, and how they can help you.
And you need to provide them not only a single training, but it has to be a regular one to keep them up to date, keep them up to speed, and let them know, make them understand that what you're trying to do is simply to protect the applications, the data, their identities, and then everything is going to be simpler for everyone. Back to you, Mark, for the different challenges that you might have to overcome.
Thanks, Solenne. So we're going to cover off three different challenges that we see when we're deploying advanced authentication. The first is around user experience. That balance of user experience versus security has been something that's been around for a long, long time. And we generally see people talking about this quite often. We want to make sure we've got a balanced approach, but we've got that best of breed on both sides. We need to select a solution that's both user-friendly for our admins but also user-friendly for our end users as well. So the admins are getting what they want, but the users are getting what they want too. Of course, we want to reduce the user friction by minimizing the number of authentication steps that take place. But also, we want those authentication steps to be robust.
So deploying something that's both easy to use but also easy to manage and giving us a security posture that's great is important here. And that's where advanced authentication comes into its own. We're able to start rolling things out such as passwordless authentication, removing that password altogether. We're able to adapt to different mobile devices, different situations, depending on what our users need. And we can deliver a great user experience. So it's really important to listen to our users but also listen to the admins as well and give a balanced approach.
The second challenge we see is around integration. When we look at advanced authentication and access management as a whole, customers come to us, and they want to deploy everything at once, or they want to deploy everything as a whole. Of course, that's not always possible. There might be particular solutions that are legacy that don't adhere to industry standards such as OIDC in SAML. It might be those complex environments. It might be that there's not just one particular authentication framework that they adhere to.
And that's where these key points that I'm showing on screen at the moment come into their own. We want to make sure that we're having a cohesive authentication framework, that we're treating every authentication mechanism the same, that we're adhering to those industry standards that are out there-- for example OIDC, OpenID Connect, and SAML. They're the main standards that we see when it comes to authentication.
Of course, we want to also reduce the complexity. That knowledge of how to troubleshoot, of how to integrate, of how to get a new application and bring it onboard quickly generally boils down to how do we look at the standards. So which standards are we looking at integrating? And if they're supporting those modern industry standards, then we can very quickly deploy.
If we manage our own particular application that we've built ourselves, then it might be that toolkits are available that allow us to enable the front-end authentication mechanism to support OIDC and SAML. And OneLogin as a platform provides those toolkits. And you'll find that within the Developer Portal. We also want to focus on those quick wins to begin with. So what's the broadest strategy to get the most people onto the platform at the start? How can we get the most people using that platform and seeing that great user experience to begin with who can then start to rally and say, hey, can we get my application on board, please? I'd like to get it into a stage where it's simpler for me to access my full suite of applications. And that's the place you want to be to make sure you're gaining that momentum to start to integrate the majority of your applications.
The last challenge that we want to cover off here is around vulnerabilities. How do we address the potential vulnerabilities that are out there? Of course, this is basics, really. We want to make sure that we're using those modern standards which, of course, increase that security posture when it comes to authentication, but we also want to make sure that we are implementing regular updates and patching, as that takes time. We need to make sure we've got that process in place so that we can take that system offline to update or patch it. We might want to conduct pen testing and vulnerability assessments to do that.
And a great way of mitigating both of these is to start to move to IDaaS solutions and SaaS-based solutions because, of course, those vendors are looking after that for you. They're regularly updating and patching in the background. They're conducting pen testing and vulnerability assessments as well as getting all sorts of certifications to prove that. So that's then reducing the load from you, and you can think about just running the day to day. You're not having to think about how can I secure this application that's sat around on the on-premise infrastructure, that you're hosting in your own private cloud. You're ensuring that you're using a best-of-breed solution, you're integrating using industry standards, and you're making sure that the vendor is looking after those security vulnerabilities for you. This
Particular diagram here is great to just overview how we get on board with our advanced authentication. How do we go from where we are today to a paradigm of advanced authentication? We can see where we started around assessing the risks, defining the authentication goals, looking at which mechanisms we're going to use, and then, of course, piloting and testing those because we want to make sure that they're right. User experience and education are key here as well as the security aspects, too, but we need to make sure that our users are going to start using this.
And we can also look at implementing this in stages. So if we think it's going to start being friction-based, then we can start to implement this in phases to make sure that particularly users get access to this first, and we can slowly roll that out. Of course, harking back to that monitoring stage, how do we make sure that we're staying current? Constantly making those changes on a regular basis to ensure we're giving the best possible end user experience whilst also staying at the top of our game when it comes to security.
So I'm going to hand back to Solenne, who's going to go over a few last things before we close this off.
That's it. We're reaching the end of our presentation. So we have just added some useful references. If you want to go further and learn a bit more about the best practices around MFA and adaptive authentication, you can find several blog posts that have been written by our colleagues that will summarize what we've said and go even deeper for some specific topics. There is a great blog post around balancing the ease of use and security with advanced authentication, so feel free to click on the links if you want to know more and if you want to learn more. And, of course, feel free to reach out to us if you want to have more information or if you want us to help you configuring MFA in general, adaptive authentication, [? smart ?] [? talks, ?] et cetera, et cetera.
Thanks for your attention, and have a nice day.