As businesses onboard more mobile and remote employees, partners, contractors, and other external users, the volume of people needing access to critical systems and data grows exponentially. And while this increased connectivity provides tremendous operational and productivity benefits, it also creates new attack vectors for intruders and cybercriminals.
CSOs, CIOs, CTOs, and other security and IT leaders have a responsibility to protect their organization's data, systems, and IP assets. It’s important to leverage the right technologies to make system access as safe and secure as it is seamless and affordable. Password-based authentication methods must be replaced or augmented with additional layers of security that are easy to deploy and frictionless for the end user.
Risk-based authentication (RBA) meets both criteria and should be considered by organizations of all sizes. This technology protects against sophisticated security breaches and hackers, while reducing issues that result from a dependence on passwords and one-size-fits-all authentication strategies.
RBA is a form of strong authentication that calculates a risk score for any given access attempt in real time, based on a predefined set of rules. Users are then presented with authentication options appropriate to that risk level.
While risk-based authentication can be static or adaptive, the focus of this post is static RBA.
Risk scores are the key measure for RBA and are used to determine risk level. In turn, risk levels measure whether a login attempt is legitimate or likely fraudulent.
Risk levels are compared to a threshold score that is established as a policy in your authentication or identity and access management (IAM) platform. This comparison determines the authentication method needed for the login attempt.
Risk scores are based on a number of contextual factors related to the access attempt, including:
Risk scores also can and should include other actors, such as:
To be clear, a risk score should be a combination of many contextual, individual, and system factors, as any one factor on its own can and will be beaten by an attacker.
Most RBA implementations use challenge and response questions—an authentication protocol in which one party presents a question (challenge) and another party must provide a valid answer (response)—as the second factor after submitting a username and password. While cost-effective and easy to implement, we recommend only using this method as a fallback when internet or WiFi are unavailable. Challenge and response authentication is simply not as secure as other smartphone, token, and smart card-based authentication techniques. This is because breaking the authentication method only requires a little social engineering, rather than actual technical hacking.
Instead of challenge and response authentication, we recommend choosing from these other strong authentication techniques:
Smartphone-based options, such as push authentication and one time passwords, are a particularly good fit for Risk-Based Authentication. This is because they deliver a multi-factor verification experience that is largely transparent to the end user.
For example, a user logs into the RapidIdentity Portal with a username (something you know).
Next, the user is asked to approve or deny a push notification on the user’s smartphone (something you have)—either in addition to or in place of a password (something you know). Now, what you may not have even realized is that a third authentication event happened when the user logged into the smartphone with a touch ID and verified him or herself as the owner (something you are).
And there you have it: three factors. However, to the user, it just seemed like one—the push approval. This is an example of a highly secure, yet non-disruptive, experience for end users.
In reality, RBA should be considered by companies of all sizes. RBA is:
We also recommend deploying a secure single-sign-on portal that consolidates all external applications. In this scenario, users must first authenticate to log into the portal to gain access to applications. Another alternative is through a federation approach, in which all external-facing applications point toward a federation server, which is a software component that provides users with single-sign-on access to systems and applications located across organizational boundaries. When attempting to log into applications in this scenario, users are redirected to a shared server that can perform risk-based analytics to grant access.
With today’s widely available hacking tools and cheap computing power, persistent and sophisticated intruders can get past even the most fortified perimeters—often simply by guessing or breaking a password. However, by deploying risk-based authentication, you can protect your systems and data by making those stolen passwords useless.
Stay tuned for a future blog on adaptive authentication, which takes RBA to the next level with behavioral analysis and account adaptation and learning.