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.
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 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.
To help administrators to migrate on this new version, we introduced the "Legacy resolve" for ICX. The optionand is available in the :
- if enabled: exception rules will be added in an ICX Configuration.
- if disabled: exception rules will be added in a .
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:
- create a new Security Exception Configuration and migrate exceptions from your ICX Configuration in it.
- here is an example of an ICX exception rule (screenshot 2) (screenshot 1),
- conditions on the request (screenshot 2) can be migrated in a Workflow Context (screenshot 4),
- conditions matching a pattern (like SQL Injection in screenshot 2) has be to translate in a "matchingParts" token condition (screenshot 4),
- repeat those steps for all your exceptions.
With both systems
It is possible for an administrator to use both behavior, in this case:
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 -rule in a
Screenshot 5 - 6.3 - Workflow using an ICX engine
Screenshot 6 - 6.4 - Workflow using an ICX engine with the newnode
Screenshot 7 - 6.4 - Attack Detection condition after the newnode
Screenshot 8 - 6.4 - Legacy resolve option available in the ICX Configuration
- No labels