Modifying Detections with Inline Filters

Modify an existing rule without writing code

Overview

Inline filters are in open beta as of Panther version 1.54. Please share any bug reports and feature requests with your account team.

You can easily tune existing rules, including Panther-managed rules, by adding Inline Filters. An Inline Filter is a condition that must pass in order for the detection logic to then be run.

In the Panther Console, you can create Inline Filters using a no-code builder. In the CLI workflow, you can create Inline Filters by adding the InlineFilters YAML key. Note that Inline Filters are available only on rules, not scheduled rules nor policies.

A common use case for filters is to add an allowlist or denylist.

How Inline Filters work

Filter statements are evaluated before a detection's logic. A filter must return true (i.e., match the event) for the detection logic itself to then be run.

In both the Console and CLI workflow, filters can be grouped using AND or OR logic.

If an event does not contain the field the filter is evaluating, the filter will pass. If the field the filter is evaluating has a value of none, the filter will return false on positive comparators or on comparators that don't apply, and true for inverse comparators.

In the Console, filters are not available during new rule creation. In the CLI workflow, you can include InlineFilters on new rules.

While it is broadly discouraged to manage detection content using both CLI workflows and the Console simultaneously, it is possible to use Inline Filters in the Console alongside the CLI workflow. Filters created in the Console will not be overwritten or deleted when an update to detection content is made in the CLI workflow.

Creating filters in the Panther Console

You can add filters to a rule from its edit page, or within an alert triggered by that rule.

From a rule's edit page

Add filters from a rule's edit page

1. In the left-hand navigation bar of your Panther Console, click Build > Detections.

2. In the list of detections, click a rule's name to view its details page.

3. In the Detect section, find the Filters tile, and on its right-hand side, click Add New.

4. In the Filters form, provide values for the Key, Condition, and if applicable, value(s).

   • Run the unit tests to ensure they pass with the added filter(s).

   • If the values(s) field takes in an array, see the Inputting array values instructions below.

5. In the upper-right corner of the page, click Update to save your changes.

From an alert event

Inputing array values

If the Rule Filter operator you've selected requires the value field to take in an array (such as the is in operator), you'll input the array values in a modal that pops up when you click into the value field.

To add values to an array:

1. After selecting a Key and Condition for your Filter, click into the values field.

   

   • This will open the array input modal.

2. In the modal, enter the array value(s) in the input field.

   • If your input is comma-delimited, check the Values entered above are comma-delimited checkbox.

     • When this field is checked, the text inputted into the values field will be separated (using a comma delimiter) into multiple values. For example, entering "User 1,User 2,User 3" will result in three values added.

       

   • If your input is not comma-delimited, leave Values entered above are comma-delimited unchecked.

     • When this field is unchecked, you can add values that contain commas one at a time. For example, entering "1,000" will add just one value.

3. Click Add.

4. Repeat steps 2-3 as needed, until all values have been added to the array.

5. Click Apply.

Creating filters in the CLI workflow

In addition to creating no-code rule filters in the Panther Console, you can also create YAML filters on your rules written in YAML or Python.

Like the filters created in the Console, YAML filters are evaluated before the detection logic of a rule. If the filter returns true, the detection logic will be executed. If the filter returns false, the evaluation of the detection will stop, and the detection will return false altogether.

YAML InlineFilter syntax

A YAML filter is denoted by the InlineFilters key. Within InlineFilters, list one or more match expressions. See YAML Match Expression Reference to learn how to construct different types of match expressions.

Example:

InlineFilters: 
  - Key: environment
    Condition: StartsWith
    Value: "Sandbox"

Limitations of YAML Inline Filters

Some match expression functionality described in YAML Match Expression Reference is not possible in InlineFilters. These limitations include:

• InlineFilters cannot be used on scheduled rules or policies, only rules.

• The following match expression types cannot be used within InlineFilters:

  • Multi-key match expressions

  • List comprehension match expressions

  • Absolute match expressions

  • Enrichment match expressions

• The Key and DeepKey key specifiers cannot be used within InlineFilters—only KeyPath may be used.

• The OnlyOne and None combinators cannot be used within InlineFilters—only All and Any may be used.

• Many Condition values cannot be used within InlineFilters. Only the following values may be used:

  • Equals

  • DoesNotEqual

  • IsGreaterThan

  • IsGreaterThanOrEquals

  • IsLessThan

  • IsLessThanOrEquals

  • Contains

  • DoesNotContain

  • StartsWith

  • EndsWith

  • IsIPAddressInCIDR

  • IsIPAddressNotInCIDR

  • CIDRContainsIPAddresses

  • CIDRDoesNotContainIPAddresses

  • IsIn

  • IsNotIn

  • IsIPAddressPublic

  • IsIPAddressPrivate

  • IsNullOrEmpty

  • IsNotNullOrEmpty

How to create an Inline Filter in the CLI workflow

To create an Inline Filter in the CLI workflow in either a Python or YAML rule, in the detection's YAML file, include the InlineFilters key. Within InlineFilters should be one or more match expressions.

Working with failed unit tests with filters

For Panther-managed rules with filters, you currently cannot add or edit unit tests. You cannot save a rule if the unit test does not pass.

If a unit test fails, take the following steps:

1. Clone the Panther-managed rule.

2. Add your filter(s) to the cloned rule.

3. Edit the unit tests for the cloned rule so that they pass.

Inline filter reference

Refer to the below operators and value types when building out your filters in the Console.

Supported Console operators

Operation	Usage guidelines	Supported field types	Examples
is / is not	Valid for a single value. Results include only events where the field matches/ does not match the value in the filter.	string, ip, bool, int	username is “root”
is in / is not in	Valid for multiple values. Results include only events where the field matches/does not match an entry in the list of values in the filter.	string, int	username is in [ “root”, “admin” ] port is in [25, 553]
is empty	Valid for an event where the field's value is not specified. The operator tests only for the absence of data.	string, int array, ip array, float array, bool array, string array	errors_list is empty
is not empty	Valid for an event where the field's value is specified. The operator tests only for the presence of data.	string, int array, ip array, float array, bool array, string array	errors_list is not empty
contains	Valid for an event that contains a specific single value or multiple values. Results include only events where at least one of the values is in the filter.	string, int array, ip array, bool array, string array	domain contains “.google.com” p_any_port contains 22
does not contain	Valid for events that contain a specific single value or multiple values. Results include only events that do not contain any of the values in the filter.	string, int array, ip array, bool array, string array	domain !contains “.google.com” p_any_port !contains 22
starts with	Valid for events that begin with a value.	string	role starts with “admin_”
ends with	Valid for events that end with a value.	string	domain ends with “.cc”
is greater than	Valid for a single value. Results include only events where the field is greater than the value in the filter.	int, float	port > 1023
is less than	Valid for a single value. Results include only events where the field is less than the value in the filter.	int, float	port < 1024
is greater than or equal	Valid for a single value. Results include only events where the field is greater than or equal to the value in the filter.	int	count ≥ 1
is less than or equal	Valid for a single value. Results include only events where the field is less than or equal to the value in the filter.	int	count ≤ 100
is private	Valid for private IPs	IP	dst_ip is_private
is public	Valid for public IPs	IP	src_ip is_public
is in CIDR / is not in CIDR	Valid for addresses within a CIDR (Classless Inter-Domain Routing) block. Results include only events where the field is/is not in the CIDR block in the filter.	IP	src_ip in_cidr 192.168.0.0/16
does not contain IP in CIDR	Valid for an array of IPs that does not contain any IP address within a CIDR block. Results include only events where the field does not contain any IP address within the CIDR block in the filter.	ip array	p_any_ip_address !contains_ip 8.8.0.0/16 p_any_ip_address !contains_ip 1.1.1.1/32
contains IP in CIDR	Valid for an array of IPs containing any IP address within a CIDR block. Results include only events where the field contains at least one IP address within the CIDR block in the filter.	ip array	p_any_ip_address contains_ip 8.8.0.0/16 p_any_ip_address contains_ip 1.1.1.1/32

Supported value types

Value types	Description
string	A string value
int	A 32-bit integer number in the range -2147483648, 2147483647
float	A 64-bit floating point number
boolean	A boolean value true / false
array	A JSON array where each element is of the same type
ip	A single valid IPv4 or IPv6 address
CIDR	A classless inter-domain routing block