Basic concepts

The overall task of nevisDetect consists of two parts:

• Detecting whether a HTTP request is malicious, and, if this is the case,
• Mitigating the consequences of the malicious HTTP request.

Anomaly detection technologies

Several anomaly detection technologies are available to decide whether a HTTP request is malicious or not. The anomaly detection technologies differ in the kind of information the decision is based on:

• Context information: Information related to the physical context of the login attempt. Geo location and time are two examples.
• Device and network information: Information related to the application and device of the user, i.e., the kind of computer (device) as well as browser (application) the user uses.
• Biometrical information: Information related to the user themselves and their behavior. For example, how the user is moving the computer mouse see chapter Plug-in BehavioSec.

nevisDetect operates in two different modes:

• A training mode in which only data is collected. In this mode, 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 mode (or prediction phase) in which detection takes place.

Risk and Action plug-ins

One of the main concepts of nevisDetect is the use of plug-ins. There are two different type of plug-ins, Risk plug-ins and Action plug-ins:

• Within the context of nevisDetect, a Risk plug-in serves as an adapter for a particular anomaly detection technology. A Risk plug-in itself contains no detection functionality. It calls a remote anomaly detection service and extracts and converts data. Because of the Risk plug-in concept, nevisDetect is able to integrate various anomaly detection technologies. Their results are aggregated into a normalized risk score. In the chapter Risk Plug-Ins, the existing Risk plug-ins are described in more detail.
• An Action plug-in acts as an adapter for notifying other components of the Nevis Security Suite. Two different kinds of Action plug-ins exist: The NevisProxyActionPlugin notifies nevisProxy in a case of a malicious request, and the NevisAuthActionPlugin notifies nevisAuth during the login process.

An Action plug-in provides several actions. In case of the NevisProxyActionPlugin, these actions are, for example, AUTHENTICATE and BLOCK.

Policies

A policy is an instruction within nevisDetect to define which Action plug-in and which of its Actions should be executed. It defines the link between the results of the Risk plug-ins and a mitigating Action i.e. the Action of an Action plug-in.

Functionality

The figure below shows the functionality of nevisDetect from a high level point of view, by means of a flow chart:

The numbers in the flow chart represent the different process steps, which together build the nevisDetect functionality:

1. When a user sends an HTTP request, the system collects all request-related data. The detection technologies need this information to be able to detect whether a request is malicious. The most important piece of information is the login ID of the user that has executed the HTTP request. For an overview of all relevant request data, see the chapter Appendix: Request Data.
2. Based on the HTTP request-related information, the system decides whether nevisDetect should process the request.
3. If yes, the configured Risk plug-ins are invoked with the request data.
4. The system checks if nevisDetect is operating in the detection phase. If yes, the system proceeds with the next step. If not, it directly goes to the Evaluation of the Policies in step 9.
5. The system now verifies whether the user that executed the request is "trained". nevisDetect considers a user as trained, if all plug-ins/detection technologies consider the user as trained. In case of an untrained user, the system proceeds with step 9.
6. Next, nevisDetect aggregates the outcome of the invocation of the plug-ins into a normalized risk score. For more information, see chapter Normalization.
7. The system evaluates which policies are matching the normalized and plugin-in risk scores.
8. The Action plug-ins of the matching policies will be invoked by the system.
9. In the last step, the system updates the database and ends the process.

System overview

The next figure shows how nevisDetect is embedded in the Nevis Security Suite. During the authentication of the user, nevisAuth (1) passes the user's HTTP requests to nevisDetect (3). After successful authentication, nevisProxy (2) passes the HTTP requests of the user to nevisDetect (3).