Page tree
Skip to end of metadata
Go to start of metadata

What's new ?

In the version 6.4 of DenyAll Web Application Firewall, the security logs related to ICX blockings are now generated with the same format that the security logs of all the new security engines (see Security Logs for more details about the format)

Three majors changes have been done:

ICX security logs

Before the 6.4 version, all rules matching a request were collected in a single event (log) (n matched rules = 1 event).

Now, in 6.4 version, all rules matching a request are collected in different events (n matched rules = n events).

In case of false positive resolution, pay attention to resolve all events happened on the request to allow the unblocking.

ICX Exception

A new way to manage exceptions on the ICX engine is available through the Security Exception Management node.

Before the 6.4 version, exceptions were handled in the ICX Configuration itself. When resolving an ICX log, an exception (positive rule) was added to the "Positive" category of the policy (see screenshot 1 below).

Now, since the 6.3 version, we introduced a new exception system, generic and working for all security engines. In 6.4 version, the ICX engine can now used this system. It allows to declare ICX exceptions (and exceptions from other engines) in a Security Exception Configuration that will be executed by a Security Exception Management node. For more detail, we invite you to see the node documentation.

Security logs view

The panel dedicated to ICX security logs has been removed from the product and all security logs are now displayed in the "Security Logs" panel in the "Alert & Reporting" menu.

New resolve behavior

The resolve system has also been re-implemented to automatically create exceptions for all security engines. See Resolving false positives for more details.

In 6.4 version, resolving an ICX false positive will create an exception rule in a Security Exception Configuration and not in the ICX Configuration like before.

To help administrators to migrate on this new version, we introduced the "Legacy resolve" for ICX. The option indicates how to resolve false positives generated by the engine and is available in the ICX Configuration:

  • if enabled: exception rules will be added in an ICX Configuration.
  • if disabled: exception rules will be added in a Security Exception Configuration.
The Legacy resolve option is automatically activated when upgrading to 6.4 version or when restoring a backup from an older version than 6.4. The configuration will keep the same behavior as before.

Now, how to manage exceptions ?

With ICX Configuration

If an administrator wants to keep the same behavior as before, there is nothing to do because the Legacy resolve option is automatically activated when upgrading to 6.4 version or when restoring a backup from an older version than 6.4.

With Security Exception Configuration (new system)

If an administrator wants to migrate ICX exception rules to the new system, we recommend to:

  1. create a new Security Exception Configuration available on Policies panel > Security > Security Exception Configurations and migrate exceptions from your ICX Configuration in it.
    1. here is an example of an ICX exception rule (screenshot 2) in an ICX Configuration (screenshot 1),
    2. conditions on the request (screenshot 2) can be migrated in a Workflow Context (screenshot 4),
    3. conditions matching a pattern (like SQL Injection in screenshot 2) has be to translate in a "matchingParts" token condition (screenshot 4),
    4. repeat those steps for all your exceptions.
  2. add a new Security Exception Management node in the workflow after the ICX engine (screenshot 5 and 6),
  3. modify the condition node to block the request if the "security.exception.blocked" attribute provided by the node is "true" (screenshot 7),
  4. then, disable the Legacy resolve option in the ICX Configuration (screenshot 8).

With both systems

 It is possible for an administrator to use both behavior, in this case: 

  1. add a new Security Exception Management node in the workflow after the ICX engine (screenshot 5 and 6),
  2. modify the condition node to block the request if the "security.exception.blocked" attribute provided by the node is "true" (screenshot 7),
  3. then, make sure that your ICX Configuration has the Legacy resolve option disable (screenshot 8).

After that, new exceptions will be handled by the Security Exception Management node and the old exceptions will be handled by ICX Engine node.

 

Screenshot 1 - 6.3 - ICX exception rules in an ICX Configuration

Screenshot 2 - 6.3 - Detail of an ICX exception rule

Screenshot 3 - 6.4 - Security Exception rule in a Security Exception Configuration

 

Screenshot 4 - 6.4 - Detail of a Security Exception rule

Screenshot 5 - 6.3 - Workflow using an ICX engine

Screenshot 6 - 6.4 - Workflow using an ICX engine with the new Security Exception Management node

Screenshot 7 - 6.4 - Attack Detection condition after the new Security Exception Management node

Screenshot 8 - 6.4 - Legacy resolve option available in the ICX Configuration

  • No labels