Normalized Event Filters

Filter out events after they're parsed by a log schema

Overview

You can use normalized event filters in Panther to filter out data after it has been classified—i.e., after it has been parsed according to a log schema.

Normalized event filters can be created as either inclusion or exclusion filters. Learn about the difference between inclusion and exclusion filters here.

Once you have enabled a normalized event filter, monitor its performance by viewing filtered event metrics.

Normalized event filters rely on the schema of the associated log type. If you change the schema, the filter may no longer be applicable—be sure to also update related filters as needed.

If you create multiple (inclusion or exclusion) normalized event filters, there is no guarantee of the order they will run in. Because of this, if you are creating multiple OR expressions for inclusion, it's recommended to package them within the same filter. If you instead create multiple separate inclusion filters, events you intend to include could be dropped if another filter that is evaluated first does not include them.

How to create a normalized event filter

To create a normalized event filter:

1. In the left-hand navigation bar of your Panther Console, click Log Sources.

2. Click the name of the log source you'd like to add a filter to.

3. Click the Filters tab.

4. On the right-hand side of the Normalized Event Filters tile, click Add Filter.

   
5. A new filter form will be expanded. Configure the filter:

   1. (Optional) Click the pencil icon () to edit the filter's name.

   2. In the Log Type dropdown, select the log type this filter should apply to.

   3. In the Condition dropdown, make a selection:

      • Exclude if: Choose this if you'd like to create an exclusion filter.

      • Include if: Choose this if you'd like to create an inclusion filter.

        • Note that in case of inclusion filters, everything not matching will be dropped and there will be no way of re-ingesting.

   4. Click Add Filter, then configure the filter:

      1. Select an event field from the dropdown. Only fields of the selected log type are shown.

      2. Select an operator from the dropdown menu.

         • The dropdown options will be limited to those applicable to the selected field's data type. See Supported field types and operators, below.

      3. Enter a value, if the selected operator requires one.

      4. If you would like to create another filter expression:

         • To create an AND filter, click outside the expression you just created (but within the same horizontal bar), or press TAB.

           • To create an OR filter, click + Add OR Condition.

         
   5. In the upper-right corner, click Save.

Enabling or disabling a normalized event filter

After an ingestion filter has been created, you can enable or disable it:

1. In the left-hand navigation bar of your Panther Console, click Log Sources.

2. Click the name of the log source you'd like to enable or disable a filter on.

3. Click the Filters tab.

4. Locate the filter you'd like to enable or disable, and set its toggle to Enabled or Disabled.

Viewing filtered event metrics

• See Viewing filtered event volume.

Supported field types and operator semantics

You can configure filters on event fields with data types in the "Field data type" column. The operators listed in the "Supported operators" column are a subset of the Search tool's supported operators.

Field data type	Supported operators	Notes
string	is / is not	null values are ignored. E.g.: If filter is "animal" IS "bear" , the payload {"animal": null} will not match. However, the filter "animal" IS NOT "bear" will also not match.
	is / is not empty (not the same as "is / is not null")	null values are ignored. E.g.: If filter is "animal" IS EMPTY , the payload {"animal": null} will not match. However, the filter "animal" IS NOT EMPTY will also not match.
	is / is not in list	Whitespace in filter tokens is ignored! E.g.: If filter is is in list ["text "] the "text" payload (no trailing space) will also match. The opposite is not true! Spaces are not ignored in payload values. E.g.: If filter is is in list ["text"] the "text " payload (trailing space) will not match.
	has / does not have substring	null values in payloads will not match in both has substring and in does not have substring E.g:. Both filters "animal" has substring "bear" and "animal" does not have substring "bear" will not match with payload {"animal": null}
	is / is not null	Explicit "null" string is also handled and considered matching
	is within CIDR
boolean	is true / is false
	is / is not null	Explicit "null" string is also handled and considered matching
number (int, bigint, smallint, float)	equals / does not equal
	is greater than or equal to
	is less than or equal to
	is / is not null	Explicit "null" string is also handled and considered matching
timestamp	is before / is after
	is / is not null	Explicit "null" string is also handled and considered matching
array	has / does not have	Filtering on nested fields is supported on a substring basis! E.g.: If filter is "animals" contains "wolf" , the payload {"animals": ["dog", "wolf"]} will match, however the payload {"animals": ["dog", "werewolf"]} will also match. Also, missing fields in payloads do not match with does not have filters. E.g.: A filter like "animals" does not have "bear", will not match a payload like {"irrelevant": "something-else"}. Furthermore, all nested fields are coerced into strings. E.g.: A filter like "animals" has "1", will match both of these payloads {"animals": ["1","2"]}, {"animals": [1,2]},
	is / is not null	Explicit "null" string is also handled and considered matching
object	contains / does not contain	Filtering on nested fields is supported on a substring basis, and both keys and values are considered! E.g.: If filter is "animal" contains "werewolf" , the payload {"animal": {"type": "werewolf"}} will match, however the payload{"animal": {"werewolf": {"age": 3}}} will also match.
	is / is not null	Explicit "null" string is also handled and considered matching
json	contains / does not contain	Filtering on nested fields is supported with the contains condition. This also works on a substring basis, and both keys and values are considered! E.g.: If filter is "animals" contains "wolf" , the payload {"animals": ["dog", "wolf"]} will match, however the payload {"animals": ["dog", "werewolf"]} will also match. JSON-type fields will display as object in the Normalized Filter UI.
	is / is not null	Explicit "null" string is also handled and considered matching