Add red flags to risk-based access weights in IBM Security Access Manager

Automatically flag a transaction as risky, regardless of other factors

Learn how configure IBM Security Access Manager to combine the new risk-based access algorithm, which uses weights for different factors, with a "red flag" approach that specifies that particular values are suspicious regardless of what other fields show.

Ori Pomerantz (orip@us.ibm.com), Technical Enablement Specialist, IBM

Photo of Ori PomerantzOri Pomerantz has been securing computer networks and teaching other people how he does it since 1995. Since joining IBM in 2003, he has written and taught classes on several IBM Security products, including IBM Security Identity Manager.



19 November 2013

Introduction to risk-based access controls

Identity and access intelligence

Identity and access management infrastructures are becoming a major source of security intelligence information. EMA analysts have published a new report that describes the nature of identity and access intelligence and the factors driving this aspect of security evolution. To learn about this aspect of IT security, download and read "Identity and Access Intelligence: Transforming Enterprise Security."

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
VariableRisky Value?Weight
userAgent5
userAgentVersion5
screenHeight15
screenWidth15
Language10

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

Failure Condition

This algorithm fails if there are over 100 red-flag variables. This is unlikely to happen.

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
VariableRed Flag?Weight
userAgent0
userAgentVersion0
screenHeight1
screenWidth1
Language0

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
VariableRed Flag?Weight
userAgent10
userAgentVersion10
screenHeightN/A
screenWidthN/A
Language10

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
VariableRed Flag?Weight
userAgent10
userAgentVersion10
screenHeight30
screenWidth30
Language10

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
ConditionTotal risk weightRisk percentage (risk weight/90)Considered risky (risk percentage 17% or more)?
One of the weighted parameters is risky1011
Two of the weighted parameters are risky2022
One red-flag parameter is risky3033

As you can see, the algorithm works. You can prove it mathematically if you are so inclined.


Conclusion

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.


Acknowledgements

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Security

    Pragmatic, intelligent, risk-based IT Security practices.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security
ArticleID=952919
ArticleTitle=Add red flags to risk-based access weights in IBM Security Access Manager
publish-date=11192013