Risk-Based Authentication (RBA), is the applied use of roles and attributes (sometimes thought of as policy control) to improve the security of your account and the system you are accessing. The basic guidelines are what role (or function) you have and which attributes or policies enable your role to login, access and control specific things. You can then add complexity of groups, organisations and factors like location, time or devices being used to determine the level of risk.

Practical examples of basic RBA

As a basic example, you receive an email informing you that you have logged into a service from a new device. If you did perform the login, then there is no issue. But if your account has been hacked into, you would be able to contact the service and potentially limit your personal exposure. It is now up to you to react and reduce the risk.

Another common example of RBA is when a user attempts to log into their online bank account from a new device or location. Modern online banking systems typically now recognise this as a higher risk login attempt and may require additional forms of authentication, such as a one-time code sent to the user’s phone or email, or it may prompt the user to answer additional security questions.

There are numerous RBA feedback loops like these common examples, but they all place the burden of security on the end user. If the account has been hacked or breached, the user must react quickly to prevent further impact (data theft, outright monetary loss, etc.). The service provider assumes that you will react – but only knows there’s an issue if you contact them. This is very passive from the service side and places most of the obligation on the end-user of the service.

Adaptive Risk-Based Authentication

In an adaptive RBA, there is an ability to layer different existing control systems into a cohesive system, which provides greater granularity and control points for both the users of the system and the service provider. An adaptive approach can be more impactful in terms of security to your end user. However, adaptive RBA can also provide better user experiences – by only requiring additional authentication steps when the factors such as user behaviour, location, etc. are deemed to be outside the norm.  RBA, by definition, should be relatively transparent, so long as the risk factors remain low by reducing the number of times the user is prompted to authenticate themselves.

Additional use cases of Risk-Based Authentication

If we consider supplementary areas that Risk-Based Authentication might help both the end user and the security of your organisation, then there are a few areas we can expand into.

For example, a business partner creating a sample order on your web store application has been sufficiently identified with their username, password and MFA from their initial logon. But if that same user were making a high value order, or shipping the goods to a newly added address, then additional steps to authenticate the order would be reasonable. Similarly, the ability to enforce EULA (End User License Agreement) terms – like users not having more than 5 devices accessing a streaming service – would help the user to understand the practical limits of their service, while protecting the value of your streaming content.

RBA and IAM

An Identity and Access Management (IAM) platform is the central location for all of your users, both internal and external, as well as the applications or resources they access. In managing active access control, the IAM system is therefore the key location to drive Risk-Based Authentication.

Being able to offer a wide variety of attribute and role-based access controls, along with the ability to perform interruptive Multi-Factor Authentication re-requests, is at the heart of Ubisecure’s Identity Platform.

If you have any questions or would like to learn more about how the Ubisecure Identity Platform supports Risk-Based Authentication, please contact us.