What Is Risk-Based Authentication and Authorization?
On the surface, access seems like a binary decision. Should this person access this application or resource? Yes or no? But as applications and systems increase in value and sensitivity, the types of questions you need to ask change. Can we verify the user’s identity? With what level of certainty can we determine their identity? What would be the damage if we’re wrong? Are they using an approved device to access the resource? Are there regulatory compliance implications?
Access = Authentication + Authorization
Access is actually a two-part decision: authentication and authorization. Authentication is the validation of who is requesting access, and authorization is the more granular decision of what this person should be allowed to do. Each of these two decisions work on different scales.
For authentication, the scale is the likelihood that this person is who they say they are, and with breakthroughs in authentication technology such as Beyond Identity, this decision is becoming much more binary – yes or no.
For authorization, the scale relates to the different risks associated with different levels of access that can be granted – from no access, to limited access, all the way up to administrative access.
The result is a matrix of risk factors for each authentication and authorization decision. These risks fit into three interconnected categories: device risk, app risk, and contextual risk, which we call the “triad of risk.”
The Triad of Risk
The triad of risk is a methodology for conceptualizing risk factors when permitting or denying access to applications.
This describes the risk of the hardware from which the user in question is trying to access the application. In order to decide if the user should be allowed to access the app, you must first decide if their device is secure. In a BYOD environment, you may not know for sure if the user’s device has malware, so instead, you will need to factor in their susceptibility to malware to make an authorization decision.
- Whether the user’s device requires a passcode or bio-authentication
- How frequently that passcode or bio-authentication needs to be entered
- Whether the operating system is up to the latest version
- If they have a firewall installed
- If the device has a TPM, etc.
All of these things can be checked individually, weighted by individual risk factors, and compiled into an overall device security posture. This tells you how likely the device attempting to access the application is to be compromised. Based on the likelihood of compromise, you can make the decision as to whether this device is secure enough to access the desired level of functionality within the application. This is not the final barrier to entry; it is vital that all three components of the risk triad be accounted for, and so far we have only established whether or not the device is secure enough to access. We still have to assess the risk of the application and the context of the request.
This is a bit of a misnomer because you are not actually looking at the riskiness of the application itself but rather the potential impact this application could have on operations if a malicious actor were to have access to it. For example, does access to this application grant the user access to PHI or financial information? Through this application, could they gain access to other applications? All applications are not equal, nor is every function within an application. Some applications or access levels within applications can lead to much more catastrophic outcomes than others when in the wrong hands.
The potential impact or damage resulting from access – and level of access within each particular application – can then be coupled with other risk factors to make more adaptive authorization decisions. For example, a payroll application may place more weight on device security posture than a task management tool, and within that payroll application, the ability to conduct a transaction may be weighted more heavily than another level of access.
With COVID-19 forcing many employees to work from home, the bar for abnormal behavior has been raised. While you used to be able to make decisions based on whether or not the user was accessing from the office network, now you need to look at a more granular array of contextual tidbits to build a picture of what is normal behavior and “abnormal behavior.” You need to understand which behavior increases the likelihood that this person attempting to access an application is in fact a fraud or a bad actor.
Geography is still one of those contextual factors; however, rather than being tied to the office, the zone of geographic normalcy is tied to the user’s behavior. From what location do they normally access applications? Contextual risk in a remote work environment is all about gauging behavior as normal or abnormal, and when it is abnormal, assessing just how abnormal it is. Other contextual factors include whether this is a commonly used application for this user, what time of day the user usually accesses this application, on which device they usually access the application, and so forth.
Their behavior builds patterns, and when these patterns are broken, alarms should be raised. But some behavioral abnormalities should be weighted more heavily than others. For example, a user based in New York suddenly accessing an application from Hong Kong is more likely to be fraudulent than a user who usually stops working at 5 PM but then accesses an application at 7 PM.
Now that we understand the risks, we can make decisions. The first decision is not, however, a “let them in or don’t let them in” decision. Since there will always be some level of risk, the first decision is whether to block access based on that level of risk or to mitigate the risk through verification methods. If the total risk is high enough based on weighing all the factors from the triad, then it may be a simple “no” to the access attempt. But if it is less clear (as it usually is), then you need to take steps to mitigate the risk.
Verification Methods to Mitigate Risk
There are three levels of verification to mitigate risk. Depending on the overall risk, you may need only one of them, but for the highest-risk applications, you may need all three.
Verifies: If this is the user’s device
Does the device have possession of the necessary private key to authenticate?
Verifies: If there is a living human using this device
Prove you aren’t a robot! This is verified by requiring the user to touch something on the device.
Verifies: If this is the user who owns this device
By using a biometric such as fingerprint or face scan, this step will verify beyond a reasonable doubt that this user is who they claim to be.
In addition to improved security, the triad of risk has compliance benefits as well. Consider the HIPAA implications of a medical professional accessing an application from a personal device that does not have an encrypted disk or does not require a biometric. The device risk score would spike even if the other two inputs of the triad were within acceptable levels. Although this scenario is not so much a security risk, it poses a compliance risk that can be neutralized with proper controls.
Adaptive Risk-Based Auth Should Make Access Easier
As with all security, it is always better to prevent than to detect an issue. Risk-based authentication is designed to prevent issues from happening in the first place, without causing friction to users and protecting the organization at the expense of the user experience. When applied properly, high-risk applications should not be any more difficult to access, as long as you have adaptive risk-based authentication ensuring it is the correct person accessing the application, and ensuring the wrong person cannot gain access.