Skip to main content
Version: 1.8.x.x LTS

Policy

A policy is a set of appropriate counter measures based on the normalized risk score or the plugin risk scores. A policy consists of several ranges and associated actions of an Action plug-in. See the following sample policy with the NevisProxyActionPlugin and the normalized risk score:

  • If the normalized risk score is below 0.3, no counter measure is required. The system forwards the HTTP request to the application.
  • If the normalized risk score is between 0.3 and 0.5, the system forwards the HTTP request to the application, together with the normalized risk score (via the HTTP header of the request). Mitigation of the risk can then take place in an application specific manner.
  • If the normalized risk score is between 0.5 and 0.8, the system terminates the current session of the user. The user has to log in again.
  • If the normalized risk score is above 0.8, the system blocks the request of this user.

Relation between normalization and policy

The normalization and the policy of required actions are closely related. The algorithm used to calculate the normalization risk score has a direct influence on the required action to be taken. As a consequence, the normalization also influences the level of security. This is illustrated by the following sample setup with two plug-in risk scores A and B:

  • Due to some security considerations, the weight of plug-in risk score Ais set to "2" and the weight of plug-in risk score B to "1".
  • The following policy is configured:
    • For a normalized risk score of \[0.0 , 0.6\] : → No action
    • For a normalized risk score of \[0.6 , 0.9\] : → Action = AUTHENTICATE
    • For a normalized risk score of \[0.9 , 1.0\] : → Action = BLOCK

The following figures show the relationship between the normalized risk score (composed of plug-in risk scores A and B), the algorithm to compute the normalized risk score and the action-to-be-taken.

  • Required actions if the normalized risk score is based on the minimum normalization algorithm:
Normalized risk score - minimum normalization
  • Required actions if the normalized risk score is based on themaximum normalization algorithm:
Normalized risk score - maximum normalization
  • Required actions if the normalized risk score is based on theweighted sum normalization algorithm:
Normalized risk score - weighted sum normalization

Comparing the green "no action" areas in the figures above shows how the different normalization algorithms influence the level of security:

  • The minimum normalization algorithm is the least restrictive. In this case, every plug-in risk score must match the respective range of action before the action is triggered.
  • The maximum normalization algorithm is more restrictive. Here, it is already enough if oneplug-in risk score matches the respective range of action, to trigger the action.
  • The weighted sum normalization algorithm is the most restrictive. Here, every plug-in risk score contributes to the normalized risk score. This normalized risk score is always larger than a normalized risk score consisting of just one minimum or maximum weighted plug-in risk score.

The chosen normalization algorithm reflects a trade-off between security and user convenience. The minimum normalization algorithm will trigger less counter measures and as such offer a higher user convenience. However, it may also forward illegitimate HTTP requests, and is therefore less secure. The weighted sum normalization algorithm, on the other hand, may trigger counter measures or actions even if the HTTP request comes from a legitimate user.

The following figure visualizes this trade-off:

Normalization trade-off