UBT

Certain threats cannot be addressed using filtering technologies such as white lists, weighted lists and black lists, because the malicious nature of these queries is not in the content but in other factors such as the frequency (number of queries), the origin (the previous page or “referer”) or a very specific scenario that goes beyond a malicious query.

For example, attempts to guess a password on a link requiring authentication would not be detected by conventional filters (no attack scheme in the query as it must be authorised by a white list to allow users to connect after authentication); a simple scenario  used to detect an abnormal frequency of queries.

Once the malicious behaviour has been detected, a set of predefined reactions (blocking, slowdown, rerouting, execution of a script) can be activated to provide effective countermeasures against such attacks.

The definition of rules is complemented by two unique functions of this analysis module:

1. The definition of a white list specific to one part of a site only (“Force URI”)
2. Force Browsing of users.

The partial white list is interesting in terms of exploitation of the system because it provides a compromise between raising the level of security and maintenance of the entire system. This takes the form of a list of authorised URIs, set up during a learning period.
This learning mechanism is also used for the implementation of forced browsing, which is useful when you wish to make users pass via a specific page, whatever the link used (result of a search engine, bookmarks).

Through the three functions offered (rule definition, definition of a dedicated white list for part of a site, forced browsing within the application) our behavioural analysis module provides a complete arsenal to effectively reduce the exposure of applications to ever-changing multiple risks, not forgetting its easy integration with the other security functions of our rWeb product.
 

Behavioural Analysis Module