Skip to main content
Version: 1.14.x.x RR

Basic concepts of nevisAdapt

Overall task

The overall task of nevisAdapt consists of two parts:

  • Determine the context of a user request, by means of different modules, and store the observed request context data in the database.
  • Calculate the risk score of the actual user request, using statistics from the stored, historical context data of the user.

Observing the context of a user request

nevisAdapt observes several aspects of a user's HTTP request, to determine the context of the actual user request and to calculate risk scores:

  • Device recognition cookie
  • Device fingerprint
  • IP address
  • IP reputation (experimental)
  • Geolocation
  • Geo-velocity (experimental)

nevisAdapt compares the context data of the actual user's request with the stored (persisted) context data for this user, to find an answer to the following questions:

  • How many times has the actual request context been observed for this user?
  • How often does the context change?
  • Has the actual request context also been observed for a different user?

Depending on the answers, an observed user request context will be marked either as

  • unknown / known / established OR
  • private / shared OR
  • trusted / suspicious OR
  • ok / blacklisted


nevisAdapt consists of several modules:

  • Fingerprint module
  • Geolocation module
  • Device Recognition module

The modules are responsible for storing the context data of the user's HTTP request. They also calculate the risk score for the user requests. Each module contains several analyzers; each analyzer calculates one risk score.

All modules operate in two different phases:

  • A training phase in which the module only collects data, for a specific user. During this phase, it is not possible to decide whether a HTTP request is malicious or not. The system does not have enough information yet to base its decision on.
  • A detection phase (or prediction phase) in which detection takes place.

For each HTTP request, every module returns information on whether the corresponding user is "trained" or "untrained" in regard to this module. Based on this information, nevisAdapt makes a distinction between a training and a detection phase on an overall level, for a specific user.

In the nevisAdapt configuration file, you configure the number of stored observations that is needed before you can call a user "trained". By default, this configuration is set to 1, which means the first requests are ignored for every user.

Threshold definitions

The calculation of the risk scores is based on threshold definitions. The system stores the context data of each terminated session for a given user, and counts the number of terminated sessions with the same context data. Based on this number, the system calculates the risk score of the current user request: A request is considered as "high risk", if the number of observations with the same context data as the current request is below the defined threshold. In case this number lies above the threshold, the request is of "low risk".

The "established" thresholds are configured in the nevisAdapt configuration file. The "known" threshold is "1" by definition. That is, the context of a user request is considered as "known", if the system persisted the same context data at least once in the past, for this user within the given time frame.

Time frame

For the calculation of the risk score, nevisAdapt only considers context data observed within a configurable time frame. nevisAdapt will "forget" about all context data that is stored before the time frame. For example, suppose the time frame is one year. More than a year ago, a specific device was regularly used and considered as "established" by nevisAdapt. However, no one has used the device within the last year, which is the set time frame. So the next time a user uses this device to log in, the system will consider the device as "unknown".

The default time frame is set to 60 days. This can be changed in the nevisAdapt Instance pattern in nevisAdmin4 or in the file in case of manual integration.