Example - Calculating the risk score for the Fingerprint module

This chapter describes some sample calculations of the risk score for the Fingerprint module. It also illustrates the terms used in nevisAdapt. The risk score calculation of the other modules is similar to the one of the Fingerprint module.

Preconditions

• The Fingerprint module is enabled. Also, the device fingerprint is present in the HTTP request. That is, the fingerprintjs2 technology is integrated in the application and/or in nevisLogRend.
• The thresholds are as follows: the "trained" threshold is 5, the "established" threshold is 3, the "known" threshold is 1.
• The risk score mapping is as follows:
  • Device is "estabilished" → risk score "0"
  • Device is "known" → risk score "0.25"
  • Device is "unknown" → risk score "0.5"
  • Device is "shared" → risk score "0.3"
  • Device is "private" → risk score "0"
• The time frame is set to 365 days.

Trained/untrained

A user is trained, if the number of user requests with stored context data is higher than the configured threshold. The numbers are considered per module.

In our example, a user is trained if the Fingerprint module has stored five device fingerprints for this user, see the list of preconditions.

The stored fingerprints must not belong to the same device. It is possible that the user has used two different devices, and has thus generated two different device fingerprints.

As long as a user is untrained, the Fingerprint module will not calculate a risk score for this user's HTTP requests. In our use case, this means that the Fingerprint module will return "untrained" responses without risk scores for the first five logins of this user. As of the 6th login, the Fingerprint module considers the user as "trained". As of this moment, the Fingerprint module will start calculating and returning risk scores for this user.

Fingerprint analyzer - unknown/known/estabilished

The fingerprint analyzer checks how often a specific device is used by a specific user. The more often a device is used by a user, the more known is this device to the Fingerprint module for this specific user.

The first time a user sends an HTTP request with a new device, this device is unknown to the Fingerprint module: The device fingerprint has not been stored yet. As soon as the user logs in again with the same device, the Fingerprint module considers the device as "known". To become established, the user must log in with the device at least as often as the defined "established" threshold, which is three times in our use case.

Time frame

nevisAdapt only considers context data observed within a configurable time frame, and "forgets" about all context data with an older history. For example, a user logs in with a device that he used more than a year ago for the last time. The set time frame is one year. In this case, nevisAdapt will consider the device as "unknown".

The following example illustrates the meaning of the time frame for the risk calculation of the Fingerprint module:

• Suppose a user used device A seven times, however only two times within the last year. This means that the Fingerprint module will only consider the two last times for the risk score calculation.
• The same user used another device B fifteen times, all in the past year.
• If this user logs in with device B, his request will be considered as a low risk request:
  • The user used the device 15 times within the specified time frame of one year. This is more often than the "established" threshold of three times, which results in a risk score of "0" (see the list of preconditions).
  • The user is considered as "trained", because in the last year the Fingerprint module could observe and store context data for this user at least fifteen times. This is more than the "trained" threshold of five times. This means that the Fingerprint module will calculate a risk score for the current request of this user.
• The next time, the user logs in with device A. This will result in a higher risk score:
  • The user used device A only two times within the specified time frame of one year. This is lower than the "established" threshold of three times, however more often than the "known" threshold of one time. This results in a risk score of "0.25" (see the list of preconditions).
  • Within the last year, the Fingerprint module only observed and stored context data for device A twice. This is less often than the "trained" threshold of 5. However, within the same time frame, the same user used the other device B more often. So in total, the Fingerprint module observed and stored context data for this user more than five times within the last year, which makes the user a "trained" user. Therefore, the Fingerprint module will also calculate a risk score for the login with device A.

Fingerprint sharing analyzer - shared/private

The fingerprint sharing analyzer checks how many different users use the same device within the given time frame. Contrary to the fingerprint analyzer, the fingerprint sharing analyzer counts all sessions, not only the terminated ones.

There are two available options: "private" and "shared". Consider the following use cases:

• The user logs in with a device that no one has used before, also not the user himself. → the Fingerprint module considers the device as "private".
• Only one user has used a specific device within the last year (no matter how often). → the Fingerprint module considers the device as "private".
• User A, who uses an iPhone X, allows user B to log in with "his" iPhone. So both users share the same device at least once. → the Fingerprint module considers the device as "shared".
• In the next 365 days, only user A continues using the iPhone X. → The next time user A uses the iPhone after the 365 days, the Fingerprint module considers the device no longer shared, but "private". (365 days = the specified time frame)

Calculating the risk score

In case of the Fingerprint module, the calculation of the risk score for a specific user request consists of the following steps:

1. The Fingerprint module determines whether the device used in the current request is "unknown", "known" or "established". The module also determines whether the device is "private" or "shared".
2. For each determined value ("unknown"/"known"/"established" and "private"/"shared"), the module fetches the corresponding risk score from the riskscore-mapping.propertiesfile.
3. The module sums up the two risk scores, to get the final risk score for this mdule and this user request. Note that the total risk score may never be higher than "1.0".

The file riskscore-mapping.properties defines the mapping between observed context data and risk scores for all modules. For more information, see Risk score mapping for nevisAdapt.

Here are some examples of possible risk scores calculated by the Fingerprint module for a specific user request:

The risk scores are based on the settings in the list of preconditions.

• The user uses a shared and known device. This results in a risk score of "0.3" (shared) + "0.25" (known) = "0.55".
• The user uses a private and estabilished device. This results in a risk score of "0" (private) + "0" (established) = "0".
• The user uses an unknown, but private device. This is the case when the user uses the device for the first time, and no one else has ever used this device before. This results in a risk score of "0" (private) + "0.5" (unknown) = "0.5".
• The user uses an unknown, but shared device. This is the case when this user uses the device for the first time. However, some other user has already used this device, and the Fingerprint module recognizes the device fingerprint. This results in a risk score of "0.3" (shared) + "0.5" (unknown) = "0.8".