Submenu – Policy Learning

Policy Learning

The policy learning dashboard gives an overview of requests violating the current security policy in place. For each violating request, automatically generated suggestions for preventing similar violations are offered. With a single click, generated suggestions can be accepted. This enables administrators to quickly integrate new applications by remediating false-positive blocks and learning allow list rules.

How to learn

The term "violating request" has a different meaning, depending on the configured threat handling mode:

Threat Handling

Violating Requests

Block Request,
Terminate Session

All blocked requests

Log Only

All requests that would be blocked if threat handling was changed to block/terminate mode

Initial learning

For initial learning, we suggest the following procedure:

  1. Put all relevant Mappings in "log only" mode.
  2. Let trusted users interact with the application. This allows Airlock Gateway to learn legitimate traffic patterns not influenced by potentially malicious users.
  3. Consult the Policy Learning dashboard and accept appropriate suggestions.
  4. Enforce the policy by setting threat handling to "block request" or "terminate session".

For enabling allow list learning (learning of Allow Rules) please refer to section allow list Learning below.

Continuous learning

Once a security policy is enforced, the policy learning dashboard keeps showing violating/blocked requests. The same machanisms for accepting suggestions can be used to fine-tune the policy in place. There is no need to enable the learning mode explicitly.

Blocked requests

The heart of the policy learning dashboard is the table presenting all violating requests (or blocks). The table can be filtered and allows drilling down into specific requests to investigate the root cause of the violation.

Currently only violations caused by Deny Rules and Allow Rules are visible in the policy learning dashboard. The set of covered violations will be continually extended.

Filtering

Various filter criteria such as a time interval, IP addresses, paths, or request IDs can be used to customize the set of currently displayed blocks. Use "%" as a wildcard in filter criteria.

The following options allow further restriction of the displayed blocks:

Option

Description

Show log only

If threat handling on a mapping or filter is set to 'Log only', requests are not really blocked but a notification about the potential block is written to the logs instead. Enable this option to display requests with a log-only block notification.

Show handled blocks

Blocks already processed by accepting a generated suggestion or by ignoring the block are marked as 'handled'. Enable this option to display handled blocks as well. Note that for handled blocks, no further suggestions are available.

Block details

For blocks selected by the current filter, various attributes are shown in the result table, e.g., the corresponding Virtual Host or Mapping. Simply click on the arrows in the table header to sort the table according to a specific attribute. To show or hide columns click on the button on the right side above the table.

By clicking on a specific block in the result list, the block is selected and can be further investigated using the tab 'Request Details' below the results table. The 'Request Details' show all details of a blocked request and the circumstances leading to the blocking decision, e.g., the name of the matching Deny Rule or the values of offending parameter and header values. These details help the administrator to decide which suggestion to accept and whether a certain block is a false positive or not.

Parameters and header values may be trimmed before they are stored in the block list.

Suggestions

For each blocked request, the administrator has two options:

  • If the block was justified (a true positive), a click on the 'Ignore' icon on the right side marks this block as handled without further policy changes.
  • If the block was not justified (a false positive), accepting a generated suggestion modifies the current configuration and marks the block as handled.

The state of a handled block message as well as the configuration change related to the accepted suggestion is stored in the current administrator session. This means that all decisions can be undone by re-login to the Configuration Center.

The favorite suggestion

For each blocked request, Airlock Gateway automatically generates suggestions that prevent similar blocks in the future. These suggestions consist of modifications applied to the current configuration. Typically, Airlock Gateway generates multiple suggestions with different specificity. To show all suggestions for a block, select the block and open the 'Policy Suggestions' tab below the result table. Of all the generated suggestions, Airlock Gateway selects one as the favorite suggestion.

The favorite suggestion aims to strike a balance between two scenarios:

  • Adding a very specific configuration change.
    This comes with a small negative security impact but with the drawback that similar requests may cause other false positive blocks. Further the configuration may get fragmented if many of these specific changes need to be applied.
  • Adding a very generic configuration change.
    This has a larger negative security impact by allowing more requests to pass than may be necessary. However, as it typically covers more variants of the same block type, there is usually no need to add further changes which may reduce the integration effort.

For example, if parameter 'comment' was blocked by an SQL injection Deny Rule on path '/application', several suggestions are proposed:

Suggestion

Description

Add deny rule exception for parameter 'comment' on '/application'.

This is the most specific exception suggested. The exception is only valid for the specific parameter name, the blocking Deny Rule and on the specific path.

Add deny rule exception for parameter 'comment'.

The exception is only valid for the specific parameter name and Deny Rule but not restricted to the path. That is, the exception applies to the entire Mapping.

Add deny rule group exception for parameter 'comment' on '/application'.

Similar to the first suggestion, the exception is linked to the path. But here the exception is added to the entire Deny Rule Group for SQL injection and not only to the specific Deny Rule.

This is the favorite suggestion for these types of blocks.

Add deny rule group exception for parameter 'comment'.

This will add an exception on group level without linking it to the path.

Disable deny rule SQL Injection.

This is the most generic suggestion and disables the Deny Rule on the mapping. SQL injection attacks are therefore no longer prevented on this mapping.

Accepting suggestions

To assist the administrator in accepting the appropriate suggestion, the number of blocks covered is indicated in the 'Blocks Covered' column. For instance, if a very generic suggestion covers only few blocks, more specific suggestion should be accepted instead. However, if a generic suggestion covers many blocks that would otherwise require a lot of specific suggestions, it may be better accepting the generic suggestion.

For each block, the favorite suggestion is presented in the result table as a shortcut and can be accepted by clicking the 'Accept' icon on the right side.

On top of the 'Accept' icon column, an 'Accept all' icon is located. By clicking 'Accept all', all currently displayed favorite suggestions are automatically accepted. The currently displayed favorite suggestions are those visible in the result table as defined by the filter criteria and the chosen result size (10, 25, or 50).

Accepting all favorite suggestions at once is a powerful option when filtered blocks originate form traffic that is generally trusted, e.g., because it originates from a set of internal test clients. However, we do not recommend using this feature without carefully reviewing all suggestions.

For accepting alternative suggestions, open the tab 'Policy Suggestions' and accept any of the listed suggestions.

Block history

The block history is limited in size. Old blocked requests are deleted if the number of list-entries reaches the soft-limit. This check is performed every minute. Depending on the amount of traffic and the frequency of blocked requests, the block history may last for days or even months. If the number of entries in the list reaches its hard-limit, which could occur if too many requests are blocked within one minute (e.g. in case of a denial of service attack), further blocked requests are no longer written to the block list until the list is cleaned up.

To manually free space in the block list, select an option (e.g. NOT in current filter) and click the 'Clear blocks' button on the bottom of the page. Note that the block data is immediately deleted and that this action can not be undone.

Managing handled blocks in preliminary configurations

All handled blocks are deleted when the configuration is activated. To delete handled block manually, select the option 'Handled blocks' and click on the 'Clear blocks' button on the bottom of the page. This option can be useful when the configuration is exported or saved without activation. By importing the configuration at a later point in time, handled blocks are no longer shown, which prevents adding obsolete configuration settings by accepting suggestions for already handled blocks.

Allow list (Allow Rule) learning

Airlock Gateway suggests legitimate parameter names and value categories from observed traffic. These suggestions are persisted in a specific learning Allow Rule with name "(generated) Policy Learning". This learning-specific Allow Rule must be added by clicking on the correspoding button below the Allow Rule list ("Add Policy Learning Allow Rule"). The newly generated Allow Rule is in "Log only" mode and ready for learning. For enforcing the learned patterns, disable "Log only" on the generated Allow Rule.

It is possible to manually adjust the learned Allow Rule, e.g., in case a parameter was assigned to the wrong value category. However, please do not change the name or number of parameter rules in the generated Allow Rule.

The following table describes all built-in value categories used in parameter learning:

Parameter Value Class

Description

Example Values

Empty

Empty parameters

Boolean

Boolean values represented as text

false, TRUE

UUID

Universally unique identifier (UUID), sometimes also called a globally unique identifier (GUID)

123e4567-e89b-12d3-a456-426655440000

Natural number

Positive integer numbers

0, 42, 123456789

Real number

Floating point numbers

-45, 3.141592, 745.645E-5

Hex

Hexadecimal values with at least six characters.

123456, ABCDEF, beef1feeb

Date or time

dates or times

2017-04-02, 17:00, 2017-04-02T17:00, 2017-W12

Email address

Email addresses

info@airlock.com

URL

URLs, including query string

https://www.airlock.com/en/products/airlock-waf/
http://host1?param1=foo&param2=bar

Restricted technical parameter

Same as technical parameter, but even further restricted by disallowing "?", "!", and "--"

object.key-001@attribute:77

Technical parameter

Technical values without characters that may be used for injection of scripting snippets: whitespaces, apostrophe, quote, inverted comma, semicolon, brackets, and greater/less than signs

?object.key--001@attribute:77

Single line

All values without new lines

Hi George, it's me.

No restriction

Values are not restricted

Hi George, it's me.
I 'like' you; did you know?