Web Security Analytics shows only those requests that triggered your security configuration rules. As these requests contain multiple dimensions, Web Security Analytics offers a range of filtering options that allow you to narrow your results and precisely target the cases you want to analyze.

Before we dive into details, here are a few handy tips to keep in mind when building your filter:

By default, Web Security Analytics filters your attack traffic by requests. Learn more on filtering modes and how to change the default setting.
After you set your filtering mode (by rules or by requests), add filter conditions to narrow down your search. There is an AND operator between each filter condition you define.
Click the Lock icon to keep the filter visible, even when switching between views.
To apply filters, go to the top right of the screen and click the Filters icon .

The gray filter box opens. While you work you can collapse and open this box by clicking it.

View results by requests or rules

Web Security Analytics allows you to filter data either by requests or by rules, depending on how granular you need your security analysis to be. To choose your method, click the dropdown in the Filter widget and select your preferred mode:

The two filtering modes let you look at your data through two different lenses:

Filtering mode	Apply filters by requests	Apply filters by rules
Primary goal	Finds all requests that contain specific conditions. Use this filtering mode for general traffic analysis, investigating complex multi-vector attacks, or querying the final Action Applied to the request.	Isolates only the specific data for a defined condition (for example, Attack Type or Rule). Using Apply filter by rules helps isolate a specific rule responsible for mitigation, while the results continue to represent the number of affected requests.
Filtering logic	Filtering results can include requests that triggered not only the rules specified in your filter, but also additional rules, as long as at least one rule meets the filter conditions. For example, if you filter by Rule 111, but a given request triggered Rules 111 and 222, the request is included in the results and all rules that it triggered are shown in the relevant widget to give you a full request context.	Filtering results include requests that match only those conditions that you set in the filter. There’s a strict AND operator between the rules you provide in your filtering conditions. For example, if you specify several rules in your filter, the requests returned in the results include only those which triggered all them.
Statistics view	Displays all data associated with the filtered requests.	Widgets only show data for the specific Rule ID set.
Samples view	All request context associated with the filtered requests is shown, including all rules that were triggered by that request.	All request context associated with the filtered requests is shown, including all rules that were triggered by that request.

Examples

The following examples illustrate how rule-based filtering works:

Let’s assume that request A triggered the action Alert by one custom rule: 10001, and Deny by two custom rules: 10002, 10003.

In Web Security Analytics, select the following filter: Custom Rule ID does not match 10001, 10002, and Rule Action matches Deny.

To analyze this data in the Statistics view, add a widget and select a relevant dimension, in this case Custom Rules.

When you apply filters by requests, the results include request A as one of the rules it triggered was rule 10003. Even though request A triggered rules that you excluded in your filter, it will still show them in the Custom Rules widget as they were triggered by that request. In this way, you can see a full request context. The Custom Rules widget displays all three rules: 10001, 10002, 10003, as the request triggered all of them.
However, when you apply filters by rules, the system returns only data for requests triggered by rules that strictly meet the filtering criteria. In this case, Custom Rule 10003.
In the next example, a single request triggered two bot rules with the following IDs: 3991006 and 3912000, both containing the value BOT JCE in the data field (Botnet ID).

In Web Security Analytics, select the following filters: Botnet ID matches BOT JCE and Bot - Rule ID matches 3991006.

To analyze this data in the Statistics view, add a widget and select a relevant dimension, in this case Bot - Rule ID.

When you apply filters by requests, the Bot - Rule ID widget displays all rules associated with the request that triggered the rule you filter by (in this case, both 3991006 and 3912000). However, if you apply filters by rules, the system returns only the rule entries that strictly match all filter conditions. In this case, only rule 3991006 is included, while rule 3912000 is excluded, even though it also contains BOT JCA and was triggered by the same request. This ensures you can focus on the exact rule matches defined in your filter without including other rules from the same request.
In Web Security Analytics, select the following filters: Attack Type matches Bot, Rule Action matches Alert. Add the Rule Action widget in the Statistics view.

In this scenario, when you apply filters by requests, the filter evaluates the entire request against all filter conditions. A request is included in the results if its Attack Type includes Bot and if it triggered at least one rule with action Alert. For example, a request classified as bot traffic that triggered a bot rule set to Deny and another bot rule set to Alert is included in the results in this case.

When you apply filters by rules, only those rule matches that satisfy both conditions are included in the results, in this case those with Attack Type matches Bot and Rule Action matches Alert. For example, the same request that was denied by a bot rule is excluded from the results. Only those requests that triggered alerts are included.
A single request triggered multiple security rules across different protection areas. A custom rule denied the request, while DoS protection evaluated the same request and generated an alert. Web Application Firewall rules also evaluated the request but did not enforce a mitigation. The request was ultimately denied due to the custom rule.

Add the Action Applied widget in the Statistics view. Next, query the mitigated DDoS traffic using the request-based filtering mode and applying the following filter configuration:
- Attack Type = DoS
- Action Applied = Deny
Web Security Analytics returns one result. It’s misleading because the request is counted as mitigated DoS traffic because the Action Applied dimension reflects the final action on the entire request. However, the mitigation was enforced by a custom rule, not by the DoS protection.

However, when you apply filters by rules and use the Rule Action (not Action Applied) dimension with a value of Deny, no results are returned. This is expected, as the request was denied by a custom rule and not by DoS protection.

Set conditions

You can select multiple dimensions and set specific conditions for each filter entry.

Click the Add filter condition button.
From the list that appears, choose a dimension by which to filter.
From the menu, select how you would like your box values to be treated by the filter (the selections available here will depend on which dimension you chose):
- Match Any. The filter matches any of the values you specify. It’s equivalent to an OR statement.
  Example: If for the IP address you choose Match Any and specify 1.1.1.1, 2.2.2.2, 3.3.3.3, the query returns the requests that originate from any of the IP addresses.
- Match All. The filter matches all of the values you specify. It’s equivalent to an AND statement.
  Example: If for the Attack Type dimension you choose Match All and specify Bot, WAF, Custom, the query returns the requests that had all three attack types triggered on them.
- Does Not Match Any. The filter excludes all of the values you specify. It’s equivalent to an not(OR) statement.
  Example: If for the Connecting AS Number dimension you choose Does Not Match Any and specify 100, 200, 300, the query returns the requests that didn’t originate from these three AS Numbers.
- Starts With Any. Filters on multiple starts with conditions to show any content that begins with the characters you specify.
  Example: If for the Hostname dimension you choose Starts With Any and specify e, www, qa, the query returns requests or triggered rules where the hostnames start with those strings, like example.com or qa-example.com.
- Does Not Start With Any. Filters on multiple does not start with conditions to exclude content that begins with the characters you specify.
  Example: If for the Hostname dimension you choose Does Not Start With Any and specify m, www, qa, the query excludes requests or triggered rules where the hostnames start with those strings, like example.com or qa-example.com.
- Ends With Any. Filters on multiple “ends with” conditions to show content that ends with the characters you specify.
  Example: If for the Hostname dimension you choose Ends With Any and specify com, security, io, the query returns requests or triggered rules where the hostnames end with those strings, like example.com or example.io
- Does Not End With Any. Filters on multiple “does not end with” conditions to exclude content that ends with the characters you specify.
  Example: If for the Hostname dimension you choose Does Not End With Any and specify com, security, io, the query excludes requests or triggered rules where the hostnames end with those strings, like example.com or qa-example.com.
- Contains Any. The filter matches content that contains any of the match conditions.
  Example: If for the Path dimension you choose Contains Any and specify pen, book, tablet, the query returns requests or triggered rules for paths where the specified values occur.
- Does Not Contain Any. The filter matches content that doesn’t contain any of the match conditions.
  Example: If for the Path dimension you choose Does Not Contain Any and specify pen, book, tablet, the query returns requests or triggered rules where the path those specified values do not exist.
- Greater Than. If you are creating a filter with the reputation score dimension, this selection lets you match scores that are greater than the values you enter.
- Greater Than or Equal To. If you are creating a filter with the Bot Score or the User Risk Score dimensions, this selection lets you match scores that are greater or equal to the values you enter.
- Less Than. If you are creating a filter with the reputation score dimension, this selection lets you match scores that are less than the values you enter.
- Less Than or Equal To. If you are creating a filter with the Bot Score or the User Risk Score dimensions, this selection lets you match scores that are less or equal to the values you enter.
- Exists. If you’re creating a filter for the following dimensions: Referer, API ID, API Resource Purpose Name, SDK Version, Native Mobile App Version, Bot Type, Bot Category, Bot Score Response Segment, Bot - Rule Combination, and you want to narrow down requests to search for certain types of anomalous requests.
  Example: If you search for requests that had an API Resource Purpose defined, but that Bot Manager Premier did not protect, you don’t necessarily care which API Resource Purpose it was, but you need to filter for traffic that had one. Then you would create the following condition: API Resource Purpose exists.
- Does not exist. If you’re creating a filter for the following dimensions: Referer, API ID, API Resource Purpose Name, SDK Version, Native Mobile App Version, Bot Type, Bot Category, Bot Score Response Segment, Bot - Rule Combination, and you want to narrow down requests that don’t include those dimensions.

📘
Tips

If you use the Contains Any or Ends With Any operators, limit the time range to 24 hours at maximum.

If the selected dimension is either Path or Query, click , to specify the case-sensitivity of the match condition.

If you select Case-Insensitive from the menu, limit the time range to 24 hours at maximum.

Enter criteria.
Options for entering specific criteria for each filter differ depending on the dimension you chose. For some, click to see a menu and make a selection. For others, enter a value. You can copy and paste comma- or tab-delimited values in this box.
To remove an item click its x.
To delete an entire dimension line, click the x to its right.
Click Save to apply conditions you set.
The filter appears in the filter area, and the display refreshes to present the filtered data.

As you view results, the filter box automatically collapses to grant valuable screen space to your data. If you want to return to the filter box and tweak settings, click anywhere in its gray box to expand it.