Protecting data from unauthorized access while making it available to authorized personnel is the IT security professional's...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
ultimate objective. While simple passwords and basic data protection methods are becoming less effective, technologies like multi-factor authentication, biometrics, out-of-band PINs and even voice callbacks are being used to combat risk.
Not all logon attempts will appear suspect, which is why risk-based authentication shouldn't be limited to logon requests.
The problem is most users don't want to answer a call or enter a PIN every time they do something. But by using an intriguing concept called risk-based authentication, it becomes possible to require additional steps only when the risk is elevated. I'll explain how risk-based authentication works, what typical use cases look like, and how to conceptualize a smooth authentication process for users while reducing organizational risk.
An introduction to risk-based authentication
Risk-based authentication, sometimes called adaptive authentication, can most easily be described as a matrix of variables whose combination results in a risk profile. Based on that risk profile, additional authentication requirements may be added before certain functions can be performed.
These functions, if allowed, will typically introduce significant risks. Examples include login requests (both for internal network or systems access, as well as Web application scenarios), sensitive data requests or modification of security information.
Risk-based authentication variables
There are two sets of values in this matrix. The first set is the user or client-side variables. These variables are derived from the client, and include information such as originating IP address, hardware identification (MAC address, brand of hard drive and other static identifiers), browser, time of day, how long it takes to enter the user's password and others. This set of information is used to determine if the user is the same one who logged in with the applicable account credentials previously.
Application developers define the second set of values, which are based on the effect of a potential compromise of the function in question, such as letting a hacker log in as another user.
Risk-based authentication systems are designed to identify heightened authentication risk. For example, a user on his or her home computer accessing online banking once a day represents little risk, because it is a predictable (logging in once a day) and logical method and source (from the home computer). If that login request instead came from a computer located in the Shanxi province in central China at 1:00 a.m., those variables would suggest an unauthorized login attempt and the system would determine that the risk of that user being a hacker is elevated. In such a case, the system can challenge the user login request with a request for additional out-of-band information, or even prompt the user to answer security questions.
This is a simple example, but the method is currently in use and is highly effective. Login time and location information may not be enough to detect a change in the risk profile, so a plethora of other identifiers can be included in the risk matrix to determine if client-side variables have changed, such as hardware identification, SMS text messages or even voice calls from an automated system.
Expanded use cases
Not all login attempts will appear suspect, which is why risk-based authentication shouldn't be limited to login requests. Other high-risk transactions, such as banking scenarios involving a transfer or a change to notifications, should receive extra scrutiny. In an enterprise setting, access to sensitive sales or financial data or applications presents more risk for the organization than simply accessing an email account, so a risk-based authentication system can be configured to require users to provide additional user information.
Often with Web applications, Web designers are instructed to only require risk-based challenges on high-risk transactions. Allowing an attacker to log in and view basic data isn't a high-risk threat, but letting an attacker withdraw money or shut down services affects a business negatively. This methodology also presents minimal disruption to most Web users, who want only to view information in 99% of use cases. This way, only 1% of user interactions with a website would require multifactor authentication.
Taking this a step further, using device and user data such as behavior, it is possible to combine the source risk with the transaction risk to create a matrix that streamlines the authentication process. Device identification data automatically can detect if a new computer is attempting to log in and user behavior history on the site can indicate, with some degree of accuracy, if it's the same person. This is done using navigation patterns and timing. If the user always takes the same URL or click path through the site to arrive at the point where the high-risk transaction takes place, and it always takes them three to six seconds to do it, then a deviation in which an attacker directly accesses the high-risk transaction page and does so in only two seconds would indicate an anomaly and greater risk, and should be challenged accordingly.
Vendors and implementations
Vendors such as RSA, the security division of EMC Corp., CA Technologies, Entrust Inc. and others have taken risk-based or adaptive authentication to a whole new level with easy, intuitive integration processes. By integrating the technology into the websites, applications and authentication suites that enterprises use, the technology can build profiles for users through monitoring behavior and activities. As each user logs in, browses a website, accesses corporate systems or requests data, an integrated adaptive authentication system profiles users' actions so their behaviors and other pertinent details about their sessions can be compared with future sessions. If an important risk indicator changes from one user session to the next, it can be a clue that something is up, and further authentication details can be requested.
It's no surprise that Gartner Inc. forecasted that three out of every 10 business-to-business and business-to-enterprise user authentication implementations will incorporate adaptive access control capability by 2015. Combining the latest two-factor and multifactor authentication technology with user and device data tracking, risk-based authentication technology can go a long way in helping enterprises protect sensitive systems data, while making the experience as painless as possible for users.