Using the policy learning feature

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 and proposes a Favorite Policy Suggestion.

• The Favorite Policy 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.

To show all suggestions for a block, click on the block in the result table.

• This opens the block details section below the table:
• Tab Request Details – this tab shows all the details of a blocked request and the circumstances leading to the blocking decision. This includes, e.g., the name of the matching Deny Rule or the values of the offending parameter and header values. These details can be used for further filtering and can help the administrator decide which suggestion to accept and whether a certain block is a false positive.
• Tab Policy Suggestions – this tab can show alternative exceptions that might be chosen instead of the Favorite Policy Suggestion. The Blocks Covered column indicates the number of blocks covered to assist the administrator in accepting the appropriate suggestion. For instance, if a very ​generic​ suggestion covers only a few blocks, a 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 to accept the generic suggestion.

Of all the generated suggestions in the Policy Suggestions tab, Airlock Gateway​ selects one as the favorite policy suggestion​, which always has the most fine-granular blocking effect​, i.e., will block exactly similar requests. All other suggestions in the list are less specific and will likely block approximately similar requests. For example, if a parameter comment was blocked by an SQL injection Deny Rule on path /application, several suggestions are proposed:

Suggestion	Description
Add a 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 the specific path.
Add a 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 a 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 the group level without linking it to the path. Such a parameter exception will disable the protection against attacks covered by this group.
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.

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

• For threat handling modes Block request/Terminate session:
• All blocked requests are violating requests.

• For threat handling mode Log only:
• All requests that would be blocked if threat handling was changed to block/terminate mode are violating requests.

We suggest producing legitimate traffic for initial learning to see if false positive blocks appear in the policy learning database.

• Only violations caused by Deny Rules and Allow Rules are stored in the policy learning database and can be displayed in the result table. The set of covered violations will be continually extended.
• Parameters and header values may be trimmed before storing them in the block list.
• The state of a handled block message and the configuration change related to the accepted suggestion are stored in the current administrator session. This means all decisions can be undone by re-logging into the Configuration Center.

0. Initial steps:
1. Put the threat handling mode of all relevant mappings in Log only mode (Section – Service and 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. Check and filter blocks with the result table and accept appropriate deny rule policy suggestions for any false blocks appearing in the result list.
   For enabling allow list learning (learning of Allow Rules) refer to section Allow list (Allow Rule) learning below.
4. Re-enforce the policy by setting threat handling on the relevant mappings to block request or terminate session.

If further investigation on blocks is not required, the button Accept all displayed favorite suggestions below the result table may be used for bulk acceptance of all policy suggestions that are currently shown in the result list. However, we do not recommend using this feature without carefully reviewing all suggestions.

Once a security policy is enforced, the policy learning dashboard will likely show violating/blocked requests and give policy suggestions for deny rule adaption. Various filter criteria, such as a time interval, IP addresses, paths, or request IDs, can be used to limit the list of shown results to find false positive blocks. For a list of all filter options, including short descriptions, see the article Submenu – Policy Learning.

0. For each blocked request, the administrator has two options:
1. If the block was justified (a true positive), clicking on the button in the result table marks this block as handled without further policy changes.
2. If the block was not justified (a false positive), accepting a generated suggestion with the button modifies the current configuration and marks the block in the policy database as handled. Note that policy suggestions can be fine-tuned in place using the button.

By clicking on a specific block in the result list, the block is selected and can be further investigated using the tab Request Details and tab Policy Suggestions below the results table as described in the first part of this article.

The Accept all displayed favorite suggestions button is a powerful option when filtered blocks originate from generally trusted traffic. It may be used when the traffic originates from a set of internal test clients.
However, we do not recommend using this feature without carefully reviewing all suggestions.

The block history is limited in size. Old blocked requests are deleted from the database 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.

• Examples for using the Clear blocks button:
• To manually free space in the block list, select an option, e.g., NOT in current filter) and click the Clear blocks button.
• To delete handled block manually, select the option Handled blocks and click the Clear blocks button. This option can be useful when the configuration is exported or saved without activation. By importing the configuration later in time, handled blocks would no longer be shown, which prevents adding obsolete configuration settings by accepting suggestions for already handled blocks.

Blocks, removed with Clear blocks button are deleted when the configuration is activated.

Airlock Gateway suggests legitimate parameter names and value categories from observed traffic for a policy learning-based allow rule. These suggestions are persisted in a specific learning Allow Rule with named (generated) Policy Learning. This learning-specific rule must be added by clicking the button below the Allow Rule list. The new rule is in Log only mode and ready for learning. Disable Log only on the generated Allow Rule to enforce the learned patterns.

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

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

The table is sorted in descending order of filter strictness. In other words, the lower table entries are less restrictive and allow a wider range of different values in requests than the upper entries. To maintain the best possible security, the minimal required parameter value class should preferably be used.

• Internal links:
• Submenu – Policy Learning
• Tab – Allow Rules