Risk-based authentication
Risk-based authentication (RBA) is a feature of AuthControl Sentry® that is designed to deliver intelligent authentication by optimising security based on the user, the device and the application.
How it works
AuthControl Sentry®
Risk-based authentication (RBA) is a dynamic feature of AuthControl Sentry®, designed to automatically request the appropriate level of authentication to access applications, whether the user is connecting through a VPN, cloud, or on-premise.
Based on parameters set in the policy engine, RBA will request the appropriate level of authentication to access applications based on the user, their device and the application.
The policy engine
Based on a points system, the adaptive authentication policy engine enables administrators to set parameters per user, per application.
Parameters include:
– Group membership
– Application being accessed
– IP address
– Last authentication
– X509 Cert
– Device
– Physical location (GeoIP)
– Time / date / day
​
The Policy engine allows you to create new rules and combine existing rules, as well as providing a mechanism to support a range of scenarios with increasing complexity.
Key Features
Benefits & capabilities
Ultimate flexibility & control
RBA enables you to set the appropriate risk required for an individual or group to access particular applications.
Using a predefined set of parameters, it works for you and decides what level of authentication is required, based on criteria including but not limited to:
– What applications they are trying to access
– What group membership they have
– Where they are accessing the applications from
– What device they are using
Maximum adoption
Everyone is different and with a range of authentication factors to authenticate access to applications, administrators can select the factors that are suitable for their organisation.
Authentication factors include:
– Mobile app
– SMS
– Fingerprint
– Image authenticators: TURing & PINpad®
– Hardware token
Ready to ensure only authorized personnel
are able to access confidential information?
Example cases
Risk-based authentication: Example 1
The Purchasing Assistant has flown to South East Asia to visit a supplier with the Purchasing Manager.
She has just finished a meal in a restaurant and realises she forgot to check the stock of some components for a meeting the following day.
While waiting for the taxi, she thought she’d quickly login to the ERP system, using her company-issued mobile device.
Risk-based authentication: Example 2
The Sales Manager is working in the office today and wants to access the CRM to create an opportunity following a meeting. He is using his company-issued laptop and is accessing the application which is located on-premise.
Result – unsuccessful
Although she is trying to use a company-issued device to access the ERP, the IP range sets her back -100 points because of her location. She will not be granted access to the ERP this time, independently of her willing to use multi-factor authentication.
Result – successful
The Sales Manager clearly exceeds to points he needs to access the CRM. Once he is authenticated, he can use single sign-on (SSO) to access other applications. He receives a call from the Purchasing Assistant and is able to access the ERP system, and provides the quantity with the part number he is given.
