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

The Security Exception Management node is used to manage exceptions that handle false positives generated by security engines. It executes exception rules on events and returns a boolean telling if the request has to be blocked or not.

The node has to be used after security engines (for example, see the use case bellow).

Execution details:

When a security engine detects an attack, an event is added to the table attribute http.request.security.events (internal attribute). The node browses all events and executes exception rules on them. Exception rules are described in the Security Exception configuration profile specified in the node parameter.

When an event is accepted by rules, it is added to the table attribute security.exception.events (internal attribute) and removed from the http.request.security.events table:

  • If not all events have been accepted by exception rules, the provided attribute security.exception.blocked will be set to "false". The request still contains suspected content.
  • If all events have been accepted by exceptions rules, the provided attribute security.exception.blocked will be set to "true". The request do not contain any suspect element and can continue the classic process of the Workflow.

In DenyAll WAF 6.3, the Security Exception Management node does not work for ICX Engine. The event system is not yet supported by the engine. Use the internal system of ICX to manage exceptions.

Node parameters

  • Display name: name of the node displayed in the Workflow. Replaces the default name "Log Security Alert".
  • Security Exception configuration: Security Exception profile containing the exceptions rules. For more details, see Security Exception configurations.

Provided attributes

  • security.exception.blocked: boolean set to true if all events have matched exception rules.
  • security.exception.events: internal attribute of the Workflow containing informations about events matched by exception rules.

Use Case

Handling exceptions

  1. The first node "Normalization Engine" is used to normalize the request.
  2. The "Blacklist Engine" analyzes the request for attacks. If an attack is detected, an event is created and added to the table http.request.security.events.
  3. The "Security Exception Management" node runs exception rules on detected events:
    -If an event is accepted by rules, it will be removed from the http.request.security.events table and added to the security.exception.events table.
    -If all events are accepted by rules, the security.exception.blocked attribute will be set to "false" otherwise it will be set to "true".
  4. A condition on the security.exception.blocked attribute decides if the request must be blocked or not:
    -If equals to "true" (one or more events have not been accepted by exception rules), the "Log Security Alert" node will send events still present in the http.request.security.events table in the database. Then the request will be blocked by a HTTP code 403.
    -If equals to "false" (all events have been matched by exceptions rules), the request will be sent to the backend server.

 

Backup: Security exception management.backup