Setup Custom Rules and Exceptions
Last updated
Last updated
Configuring Web Application security or Web API security is easily done via the configuration wizard, and in the vast majority of the cases, is enough to fully protect the web assets without additional manual changes.
However, as event logs appear, a security administrator might want to make specific exceptions to the default behavior of the system, regardless of the automatic learning mechanism.
The most common use case of exception configuration is when a log is issued and as a security administrator decided that traffic matching one of the log fields (for example, the URI field) should not be detected or blocked by the open-appsec engine.
A common change might be to generalize the exception to all sources by deleting the condition for "Source Identifier", or to change the action from "Skip" (relevant only for the "Matched Parameter" field) to "Accept".
An exception configured this way applies to the combination of the specific open-appsec security practice that caught the original event and the Asset relevant for the same traffic.
For further information on how to configure exceptions from asset view and the full options an exception can provide, please read further.
Accept - Traffic matching the exception's conditions will be accepted.
Drop - Traffic matching the exception's conditions will be blocked.
Skip - Relevant only for specific keys like "Parameter Name", "Parameter Value" and "Indicator. Allows skipping the value of the matching parameter from being inspected by the AppSec engines. The rest of the traffic will be inspected for malicious behavior.
Suppress Log - Traffic matching the exception's condition will not activate their Log Trigger object/s upon event.
There are several keys allowed to be set in exceptions rules, each of them may be relevant to a different security practice or sub-practice.
For open-appsec:
Exception Key | Value String Search Location | Relevant for Skip Action | Relevant Practices |
---|---|---|---|
Host | Regular expression of the HTTP Host name | No | All open-appsec Security |
URI | HTTP full URI in request | No | All open-appsec Security |
Source Identifier | Regular Expression the identifier, according to the definition of Source Identifier in the Asset's configuration | No | All open-appsec Security |
Source IP | IP address of the request's source in IP address or CIDR format (e.g. "<IP address>/<number of bits for network>") | No | All open-appsec Security |
Parameter Name | Regular Expression of a parameter name is a key in the HTTP request body's XML or JSON file | Yes | All open-appsec Security |
Parameter Value | Regular Expression of a parameter value is the value to a key in the HTTP request body's XML or JSON file | Yes | All open-appsec Security |
Parameter Location | A value that matches the "Matched Location" field values in a the open-appsec Log (e.g. "body", "cookie", "url", etc.) | Yes | All open-appsec Security |
Indicator | Regular expression of indicator/s to be be used with the "Skip" action. Allows exclusion of desired indicators while continuing to provide security for all other traffic. | Yes | All open-appsec Security |
Protection Name | The protection name used by the security sub-practice | No | IPS and Snort Rules only |
Country Code | Country is resolved according to the source IP address. Code is the recommended use for country-based exceptions and can be searched here according to the Alpha-2 code of ISO-3166. | No | All open-appsec Security |
Country Name | Country is resolved according to the source IP address. Name is less recommended for country-based exceptions, but is more readable. Exact names can be searched here according to ISO-3166. | No | All open-appsec Security |
File Hash | SHA-256 string of the file the exception should apply to. | No | File Security only |
File Name | The file name to match the configured exception. | No | File Security only |
Response Body Note - Scanning response traffic adds a performance impact. | Regular expression of a pattern within the HTTP Response Body | No | All AppSec Security. In addition, this key allows adding manually Data Loss Prevention (DLP) rules. |
Header Value | Regular expression of the HTTP header value | Not on its own | All open-appsec Security |
Header Name | Regular expression of the HTTP header name | Not on its own | All open-appsec Security |
The following is only relevant for keys where the table states their value is a regular expression.
When an exception key expects a regular expression value (regex), it should be configured according to PCRE 2.0, which will undergo a partial search unless the '^' or '$' regular expression operators are used.
For a nicer tutorial about PCRE regular expression crafting, visit here.
A complex logical expression with "AND" and "OR" between conditions can be created.
In addition - the following operators are available for each condition:
Equals
Not Equals
Key Exists
When clicking the 3 dotted lines you will see the logical operators available for multiple conditions:
When clicking on the ':' between key and value you will see the additional value-based operators for a single condition:
Add a comment for view purposes and click OK.
When exceptions are configured, the same location in the asset provides a view of the exceptions for the practice used by the asset. The view shows the comment and the last administrator that edited the exception:
It is possible to save a group of exception rules under a global name, and then use the same object by multiple assets and practices.
The global exceptions objects can be viewed and edited under Behaviors: