Introduction to risk-based access controls
IBM Security Access Manager for Web (ISAM) access control policies usually depend on which URL is being accessed. Different URLs can require different levels of authentication, can be accessible to different user groups, and so on.
In risk-based access control, the decision to permit access to a URL can also be determined by request characteristics. For example, the address of the device that sent the request could be factored into the access control policy.
The weighing algorithm
The standard algorithm used in risk-based access uses weights and a risk threshold level. The weights of all the variables that appear risky are added, divided by the sum of all possible weights, and the result multiplied by 100 to create a percentage. If this percentage is above the risk threshold level, then an action to mitigate the risk, such as a secure form of authentication, is taken.
For example, Table 1 checks attributes of the device the user is using for a transaction against the device ISAM expects the user to use, based on previously recorded information. If the device characteristics are significantly different from what is expected, ISAM concludes that the user is probably making the request from a different device. This could indicate that someone else other than the expected user is making the request, which triggers the need to use an out-of-band form of authentication to verify that the end user is the expected end user and to register the characteristics of the end user's new device. In this case, a risky value is one that is different from the end user's registered device's values.
Table 1. Risk weights
The risk score here is (15+15)/(5+5+15+15+10) = 30/50 = 60%. Whether that
score is considered risky or not depends on the risk threshold, which is specified
as part of the policy file. This policy file is then imported using the
wsadmin.sh command (for a link to the documentation, see Resources).
If you wanted to identify when a new device is in use, you would set the risk threshold lower than 60%. If the screen resolution changes, this is probably a new device. It might be the same user, but it could also be an imposter who knows what browser (= userAgent) and language the legitimate user prefers.
Introducing red-flag risk assessment
Many organizations prefer a red-flag approach to risk assessment. In this approach, certain variable values in a transaction are defined as "red flags," and if any of those variable values appear, the transaction is considered risky.
For example, if the screen height or width variables in a transaction are different than the expected value, then the transaction is clearly a different device because mobile devices typically cannot change their screen resolution. So the screen height and screen width might be considered red flag variables, which is to say, any time their values differ from their expected values, the transaction should be considered risky.
Implementing red-flag risk assessment using the risk-based weighing algorithm
To implement red-flag risk assessment, give every red-flag variable a weight of one, and every other variable a weight of zero. Set the risk threshold level to 1%. If any of the red-flag variables are risky, the risk level will be above 0%, and, therefore, it will be considered dangerous and treated accordingly.
For example, see the following table.
Table 2. Weights using red-flag approach
These weights ignore the user agent and language completely. But if even one of the red flag variables appears risky, the risk score is 1/(1+1)=50%, which is above the threshold value of 1%.
Combining the assessments
A more complicated case occurs when the requirement is for some variables to be treated as red-flags, and other variables to be treated according to the weights algorithm. For example, consider the requirements in Table 3.
Table 3. Combined algorithm requirements
The risk threshold level for these requirements is 50%. This means that if two out of the three weighted variables (userAgent, userAgentVersion, and Language) change, the risk level is (10+10)/(10+10+10) = 67%, and the transaction is considered risky. If only one changes, the risk level is (10)/(10+10+10)=33%, and the transaction is considered safe.
How to create a risk assessment that combines red-flag variables and risk-based weights
To implement combined risk assessment, first give each red-flag variable the same weight as the sum of the weights of all the weighted variables (in this case, 10+10+10=30).
Table 4. Combined algorithm weights
Next, scale down the risk threshold level. To do so, multiply it by <sum of weights of non-red flag variables>/<sum of weights of all variables>. For example, in Table 4 the factor is 30/90 = 1/3. The new risk threshold level is, therefore, 50%*(1/3) = 17%.
To verify that this algorithm works as expected, look at Table 5.
Table 5. Verification of combined algorithm
|Condition||Total risk weight||Risk percentage (risk weight/90)||Considered risky (risk percentage 17% or more)?|
|One of the weighted parameters is risky||10||11||✗|
|Two of the weighted parameters are risky||20||22||✓|
|One red-flag parameter is risky||30||33||✓|
As you can see, the algorithm works. You can prove it mathematically if you are so inclined.
Using the algorithm described in this article, you can create risk-based access control policies that combine both weighted risk factors and red-flag variables in the same policy.
I would like to thank Steve Moore for the question that inspired this article, and Eric Schulz for reviewing it. Any remaining mistakes are, of course, my own.
- "Risk management" is the documentation for risk-based access using IBM Security Access Manager.
- Visit the Security On developerWorks blog to learn about new security-related how-to guides, articles, and demo videos.
- Sign up for the weekly Security On developerWorks newsletter for the latest security headlines.
- Follow @dwsecurity to get updates from the developerWorks security zone in real time.
- Start your journey to implement IT security through pragmatic, intelligent, and risk-based practices at Security on developerWorks.