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
- Geolocation
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 often has the actual request context been observed for this user?
- Has the actual request context also been observed for a different user?
Depending on the answers, an observed user request context will be marked as unknown, known or established, as private or shared, and as trusted or suspicious.
Modules
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 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, also nevisAdapt makes a distinction between a trainingand a detection phase.
In the nevisAdapt configuration file, you configure the number of stored observations that is needed before you can call a user "trained".
The modules do not calculate a risk score for untrained users.
nevisAdapt risk plug-in
The nevisAdapt service is used with the nevisAdapt risk plug-in, which is integrated into nevisDetect. See chapter nevisAdapt plug-in - Description to find out more about the configuration of the risk plug-in.
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 terminated sessions with the same context data as the current request is below the defined threshold. In case this number lies above the treshold, 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. Now the next time a user uses this device to log in, the system will consider the device as "unknown".
The default time frame is 365 days.
Continuous authentication
nevisAdapt calculates the risk score for every request, to be able to provide continuous authentication. To maintain a high performance, the risk scores are cached in the nevisAdapt plug-in. If the plug-in observes the same context data within the same session, it can return the risk score results without having to call the nevisAdapt service again.
However, if you observe request context data only once per session, you can disable the caching of the HTTP requests in the configuration. If you do so, nevisAdapt will only process the nevisAuth request.
The following sequence diagram shows the interaction between the nevisAdapt risk plug-in and the nevisAdapt service. The interaction consists of the following parts:
- The nevisAdapt risk plug-in calls the nevisAdapt service to calculate the risk score.
- The nevisAdapt risk plug-in caches the response of the nevisAdapt service.
- The nevisAdapt risk plug-in collects all information and calls the nevisAdapt service for updating the database.