Queries and Alert Filters

Queries and alert filters are constructed using similar components from the Lucene search engine library. They are covered in the two main sections below:

• Using Queries and the Query Builder

• Using Alert Filters and the Filter Builder

Using Queries and the Query Builder

Queries are requests for data from the Stellar Cyber database. You can build and execute a range of queries from simple to complex that you can use immediately and save for use and reuse in the future. Over time, you might build a library of queries to use when gathering information for analysis.

Unlike the Search tool, which looks for a search term everywhere, a query lets you specify a field to search, greatly increasing the speed. For example, instead of searching for china and getting every place where that term appears, you can build a query for srcip_geo.countryName: china and get a list of only places where the source IP address country is China.

Query builders are located in the Query and Filter Manager in System | Queries and Filters and on various feature pages throughout the interface. Instructions for creating queries in the Query and Filter Manager and on feature pages are provided below.

• Use the Query Builder in the Query and Filter Manager

• Use the Query Builder on Feature Pages

• Query Builder Parameters

• Change Query Access between Root Tenant and All Tenants

While basic query and filter creation is available on individual feature pages throughout the UI, the Query and Filter Manager provides a single workspace where all queries and alert filters are gathered. The Query and Filter Manager also provides advanced options that let you test queries and work with multiple query and filter variations at once. The convenience of having all the queries and filters together plus its robust capabilities make the Query and Filter Manager a powerful tool for managing complex database searches and alert filters.

Possible changes in query behavior after upgrading to 5.3.0 – In 5.3.0, there are subtle differences in the new query builder from that in previous releases. Although all new queries that you create in 5.3.0 will automatically be in the new format, all queries that existed before you upgraded to 5.3.0 will remain in the legacy format. If you load an existing query into the query builder to look at it and run the query but do not alter the syntax by making any changes to a field, operator, or value, then the new query format will not be applied and the legacy format will be retained. However, if you edit and save an existing query after upgrading to 5.3.0, it will be converted into the new format. This conversion occurs whether you use the query builder in the Query and Filter Manager (System | Queries and Filters) or a query builder on one of several feature pages throughout the Stellar Cyber interface. Because this might introduce some behavior changes that produce unexpected results, use the Run tool to first verify the query and make sure you're getting the type of results you expect before saving it.

When there are queries in the legacy format with rules that might produce different results if their syntax was converted into the new format, Stellar Cyber displays a notification about this above the queries table in the Query and Filter Manager. If you see this notification, view the flagged queries and use the Run option to test them individually before converting them to the new format.

Although the filter builder is similar to the query builder, the format of alert filters created in previous releases is not affected when upgraded to 5.3.0.

Use the Query Builder in the Query and Filter Manager

The Query and Filter Manager (System | Queries and Alert Filters) includes a query and filter builder that operates in two modes—one to create queries and another to create alert filters. When it's set for queries, you can build simple, compound, and complex queries to retrieve data you want from the Stellar Cyber database. (For instructions on using the query and filter builder to build alert filters, see Use the Filter Builder in the Query and Filter Manager below.) The Stellar Cyber query builder provides a graphical interface with options to select indices, define conditions, and create groups, generating the required query syntax and grammar behind the scenes for you.

The Query and Filter Manager consists of the following components:

To construct queries in the Query and Filter Manager:

1. Log in to the Stellar Cyber user interface (UI) and select System | Queries and Filters (under Configurations).

2. Select Create.

   The Query and Filter Builder appears in Query mode. (To switch to Alert Filter mode, select Query Mode | Alert Filter Mode.)

   The options used in query construction are also relevant when working with filters. Both involve defining conditions, applying logic, and using structured syntax to retrieve or filter data. For information about the different settings and options in a query, see Query Builder Parameters.

3. Choose the indices in which you want to run the query.

   If you create a query for a single index, you can set the time range up 1 month (this past month). If you choose two or more indices, the maximum time range can be up to 1 day (last 24 hours).

4. Set the scope of the query among Stellar Cyber tenants.

   About the Scope of Configured Objects

   When using the Stellar Cyber Platform, you can configure objects such as charts, correlations, and Automated Threat Hunting (ATH) rules that can be queried. In fact, even the queries that you create are objects. Root-level users can set the scope of these objects to be All Tenants or a specific tenant on the Stellar Cyber Platform. If a root user creates an object for All Tenants, then the object is available for every tenant to see and use, whereas if a root user creates an object for a specific tenant, then the object is available for just that one tenant. Partner-level users can create objects whose scope is a tenant in their tenant group, and tenant-level users can create objects whose scope is their own tenant, but only root-level users can create objects whose scope is All Tenants.

   When the object to be queried has a scope of All Tenants, then the scope of any query about this object must also be All Tenants. If the queried object has a scope of a specific tenant, then the query can be either All Tenants or the same specific tenant.

   When partner- and tenant-level users query objects that a root-level user created for All Tenants, they only see data that’s within the sphere of their own tenant group (for partners) or tenant (for tenant users); they don’t see data that belongs to any other tenant group or tenant. From the perspective of partners and tenant users, all the data retrieved from a query pertains only to their own tenant group or tenant, regardless of the scope used when creating and querying the object.

   In summary:

   • Root users can create objects with the scope of All Tenants or the scope of a specific tenant.

   • Partners can create objects with the scope of an individual tenant that’s in their tenant group.

   • Tenant users can create objects whose scope is their own tenant.

   • Although partners and tenant users cannot create or modify objects whose scope is All Tenants, they can see and use these objects, as well as clone* them.

   • If an object to be queried has All Tenants as its scope, then the scope of the query must also be All Tenants. It cannot be that of a single tenant.

   • If an object to be queried has a scope of a specific tenant, then the scope of the query can be either All Tenants or the specified tenant.

   • When partner- and tenant-level users query an object with a scope of All Tenants, they retrieve only data pertaining to their tenant group (for partners) or tenant (for tenant users).

     (* Partners and tenant users can clone an object that has a scope of All Tenants and save the object with the scope of an individual tenant. Then they can edit it and create queries for it.)

5. Set a time range for the data to query.

   If you're querying a single index, the time range can be up to this past month. If you're querying two or more indices, the time range can be up to the last 24 hours. Stellar Cyber uses the time range you set when you select Run to check if the query produces results as expected.

   The time range is not saved with the query itself; when you run a query later, Stellar Cyber automatically uses the currently active time range on the feature page where you run the query, up to the maximum allowed for querying a single index or multiple indices.

6. Add one or more conditions or string conditions.

   Conditions

   A condition is a specific criterion or set of criteria that data must meet to be included in the result set. Conditions are used to filter and refine data, ensuring that only relevant data is returned. Conditions are the building blocks of queries and filters, defining the criteria that data must meet to be returned (in response to queries) or excluded (in response to alert filters).

   The term condition is flexible and refers to an overall set of one or more subconditions as well as to the individual subconditions themselves. The overall condition can be composed of several subconditions grouped together using the logical operators AND, OR, or NOT. At the same time each subcondition is also considered a condition individually as well.

   • Simple conditions: A simple condition involves a single group in which the criterion or criteria of a query is defined as one or more conditions or string conditions.

     • A condition consists of a field (drop-down list), an operator (drop-down list), and one or more values (list or text field). The operator defines how the field relates to the value with operators like matches, greater than, and starts with.

       To know which values to enter, refer to the data you have and choose or enter values accordingly.

       When the operator is contains, does not contain, is, or is not, you can select + to the right of the value field and enter additional values.

       When you see the Aa icon at the left of a condition, you can select it to toggle case sensitivity on and off. By default, new queries and existing queries created in releases prior to 5.3.0 and upgraded are case insensitive.

     • A string condition defines a query with a free-form text string that uses Lucene query syntax. For example, enter the following to search for log entries where the event_description field contains the word malware or virus but excludes entries that include test: 

       event_description: (malware OR virus) AND NOT test

       If a search string is a phrase with spaces in it, the order of the words in the phrase is respected. For example, if you enter firewall security policy rules, you will get results with these four words in exactly the same order. You won't get results with the same four words but in a different order such as firewall policy security rules or security firewall policy rules. Respecting word order in this way enables more predictive results.

     The group-level operator (AND, OR, or NOT) determines the logical relationship between individual conditions within the group. The logical operator between groups is always OR.

   • Compound conditions: A compound condition combines two or more groups to create a series of conditions. Like compound sentences, compound conditions are made up of multiple, independent simple conditions combined together into groups, each of which could stand alone. In Stellar Cyber, the logical relationship between groups in a compound condition is always OR.

   • Complex conditions: A complex condition combines multiple simple conditions into a group and then nests if inside another condition, allowing you to create more nuanced queries by combining different criteria hierarchically. Complex conditions, like complex sentences, involve a primary condition with additional, subordinate conditions that add depth and complexity to the logic.

7. Run the query and check the results at the bottom of the page.

   If necessary, make changes to any of the settings and run it again. Keep making changes and testing the query until you're satisfied with the types of results you're getting.

   If you defined a query for the Alerts index, you can change it to an alert filter by selecting Query Mode | Alert Filter Mode and then saving it as an alert filter.

8. Select Save | Save As, give the query a meaningful name, optionally add notes, and then Save.

   Stellar Cyber saves the query and displays it in the same tab with its new name.

9. To add another query or an alert filter, select the Plus icon ( + ) to the right of the active tab and select New Query or New Alert Filter.

   Stellar Cyber keeps the tab for the first query open, creates a new tab next to it, and switches to the new tab. You can leave both the first and second tabs open and switch back and forth between them as you work.

   You can have up to ten tabs open simultaneously. They can be all queries, all alert filters, or a mix of both.

Use the Query Builder on Feature Pages

A version of the query builder that's in the Query and Filter Manager appears on pages throughout the Stellar Cyber interface wherever there's data that can be affected by search results:

• Investigate | Threat Hunting | Correlation Search | for New query in the Configure section

• Respond | Automation | Create to add a new playbook or ("Edit this row" icon) to edit an existing playbook | New Query

• Respond | Reports | Filters | Queries | ("Open Query Builder" icon) | New Query

• Visualize | Charts | Create to add a new chart or ("Edit this row" icon) to edit an existing chart | New Query on the Query step in the chart builder

• Visualize | XDR Kill Chain | Filters | Queries | ("Open Query Builder" icon) | New Query

• Alerts | View for an Alert Type | ("More info" icon) for an alert event | Actions | Add an Alert Filter

The query builder on these pages is a more compact version of the one in the Query and Filter Manager but contains many of the same options: a list of saved queries for selection, the ability to edit (but not delete) saved queries, and an option to create new ones. When you select a saved query, Stellar Cyber executes it immediately and updates the page with the query results.

The None query at the top of the list is a special case that removes any effect of a query on the search results. It's selected by default.

Create a New Query in the Query Builder on a Feature Page

To create a new query:

1. Navigate to one of the feature pages with a query builder and select New Query.

   The Query Builder dialog box appears.

2. Enter a name for the query.

   Special characters are not permitted in name fields for Queries, Lookup lists, Reports/Dashboards. Letters, underscores, spaces, dashes, numbers and periods are permitted.

3. Choose a Condition Type: AND, NOT, or OR.

   These logical operators determine the relationship between multiple conditions within the group.

   For information about the different settings and options in a query, see Query Builder Parameters.

4. Add Condition and enter a field, operator, and value to define a simple query.

5. Add more your conditions, string conditions, and inner groups to the group as necessary.

6. To create a compound query, select Add new group and repeat the previous steps.

7. Save the query.

   Stellar Cyber saves the query for future use on the page where you created it, on all feature pages with query builders,a nd in the Query and Filter Manager.

Edit a Previously Saved Query

To edit a previously saved query:

1. Select a query from the Saved Queries list.

   If you start typing the query name, Stellar Cyber narrows the queries accordingly. When you select the query, the display changes to show the query in its structured form.

2. Select Edit to open the Build a Query dialog box.

3. You can change the name and description of the query.

   Special characters are not permitted in name fields for Queries, Lookup lists, Reports/Dashboards. Letters, underscores, spaces, dashes, numbers and periods are permitted.

4. You can add, modify, and delete conditions.

5. Save the query when you're done with your changes.

If the query tool has a saved query selected and you select Open Query Builder to the right, the Query Builder dialog box opens with the selected query in edit mode.

Delete a Previously Saved Query

To delete a previously saved query:

1. Select System | Queries and Filters (under Configurations), and check the In Use column in the Queries table to see the number of places where the query you want to delete is being used.

2. Hover your cursor over the number to see a pop-up list of the features using the query.

3. Remove the query from use in these features and then return to the Queries table.

   When the In Use column has 0 entries, the Delete icon appears in the Actions column.

4. Select Delete and then select Yes to confirm the query deletion when prompted.

Query Builder Parameters

The following are details about the various parameters in the query builder.

Query Name

Choose a name that makes the query easy to find again later.

Special characters are not permitted in name fields for Queries, Lookup lists, Reports/Dashboards. Letters, underscores, spaces, dashes, numbers and periods are permitted.

Condition Type

The options are AND, NOT, and OR. These boolean operators are applied when the new condition is entered.

Condition Type does not apply for the first condition.

Add Condition

Adds a new condition to the query. The condition includes a field, operator, and value.

• Field

  The field is the data object in the Interflow record to be tested by the condition. There can be a large number of objects in an Interflow record, and the drop-box provides some of them. You can also enter the field name.

  See the Interflow overview page for more information on possible field selections.

• Operator

  The operator defines the relationship between the field and the value.

  Lucene Operators

  1. is	11. greater than
  2. is not	12. greater than or equal to
  3. contains	13. less than
  4. does not contain	14. less than or equal to
  5. matches	15. in range
  6. does not match	16. within
  7. field exists	17. not within
  8. field does not exist	18. is in lookup
  9. starts with	19. is not in lookup
  10. ends with

   

  1. is

  Behavior: The is operator looks for an exact match of the value in a specified field.

  Definition: Returns results when the field contains a value that exactly matches the specified search term. When you enter multiple search tokens (individual words and numbers), the search preserves their order and returns results only if they appear in the same order.

  You can toggle case sensitivity on and off.

  Field type: Text string, number, date, boolean

  Example: To find a specific value in the event_name field in network logs:

  event_name is Impossible Travel Anomaly

  This query searches for events when the value in the event_name field is exactly Impossible Travel Anomaly, meaning events when a user appears to be in two locations within a timespan that would be physically infeasible, which suggests a potential security threat such as account compromise.

  When you define a query with a time field and a value that includes milliseconds, it’s not recommended to use is or is not as the operator. Use one of the following operators instead: greater than, greater than or equal to, less than, less than or equal to, or in range.

   

  2. is not

  Behavior: The is not operator excludes results when the field value matches the given term exactly.

  Definition: Returns results when the field does not exactly match the specified value. When you enter multiple search tokens, the search preserves their order and returns results only if they appear in the same order.

  You can toggle case sensitivity on and off.

  Field type: Text string, number, date, boolean

  Example: To find events that are not classified as impossible travel anomalies:

  event_name is not Impossible Travel Anomaly

  This query excludes any logs when the value in the event_name field is Impossible Travel Anomaly while returning events classified as other types of security incidents.

  When you define a query with a time field and a value that includes milliseconds, it’s not recommended to use is or is not as the operator. Use one of the following operators instead: greater than, greater than or equal to, less than, less than or equal to, or in range.

   

  3. contains

  Behavior: The contains operator looks for a match with the value in a specified field.

  Definition: Returns results when a field contains the given value regardless of the exact order of the terms found in a full text search.

  You can toggle case sensitivity on and off.

  Field type: Text string

  Example: To find events when the value in the xdr_event.description field contains the term malware anywhere within the text:

  xdr_event.description contains malware

  This query matches any log when the value of the xdr_event.description field contains the term malware at any position in the text, such as malware detected or possible malware activity.

   

  4. does not contain

  Behavior: The does not contain operator excludes results when the value of a specified field contains the specified value.

  Definition: Returns results when a field does not include the given search term or terms as part of its value regardless of the exact order of the terms found in a full-text search.

  You can toggle case sensitivity on and off.

  Field type: Text string

  Example: To exclude events when the xdr_event.description field contains the word malware:

  xdr_event.description does not contain malware

  This query finds logs when the value in the xdr_event.description field does not contain malware anywhere in the text.

   

  5. matches

  Behavior: The matches operator finds results that match a specific pattern in the value of a specified field.

  Definition: Returns results when the field value matches a given pattern, which can be an exact pattern found in a full-text search; that is, the search might match phrases containing the search terms even if they are in a different order or separated by other words.

  Field type: Text string

  Example: To match all XDR event descriptions that include application and traffic:

  xdr_event.description matches application traffic

  This query finds logs when the value in the xdr_event.description field includes application and traffic, even when the tokens application and traffic are not adjacent as written as the value.

   

  6. does not match

  Behavior: The does not match operator excludes results that match a specific pattern.

  Definition: Returns results when the field value does not match the specified pattern found in a full-text search; that is, the search might match phrases containing the search terms even if they are in a different order or separated by other words.

  Field type: Text string

  Example: To exclude events when the xdr_event.description field includes application and traffic, even when the tokens application and traffic are not adjacent as written as the value:

  xdr_event.description does not match application traffic

  This query returns all logs when the value of the xdr_event.description field does not include application and traffic.

   

  7. field exists

  Behavior: The field exists operator checks if a specific field is present. The field name must be an exact match. There is no value for this operator.

  Definition: Returns results when the specified field is present (even if it's empty).

  Field type: All field types

  Example: To find all logs where the event_name field exists:

  event_name field exists

  This query returns all logs when the event_name field exists, meaning there is an event name associated with the logs.

   

  8. field does not exist

  Behavior: The field does not exist operator checks if a specific field is missing from a log. The field name must be an exact match. There is no value for this operator.

  Definition: Returns results when the specified field does not exist.

  Field type: All field types

  Example: To find all logs where the event_name field does not exist:

  event_name field does not exist

  This query returns logs when the event_name field does not exist, meaning there is no event name associated with the logs.

   

  9. starts with

  Behavior: The starts with operator checks for a match at the beginning of the value for a specified field.

  Definition: Returns results when the field value starts with the specified value.

  You can toggle case sensitivity on and off.

  Field type: Text string

  Example: To find all logs where the event_name field value starts with port:

  event_name starts with port

  This query returns all logs when the value of the event_name field starts with port, such as port_scan or port_block.

   

  10. ends with

  Behavior: The ends with operator checks for a match at the end of the value in a specified field.

  Definition: Returns results when the field value ends with the specified value.

  You can toggle case sensitivity on and off.

  Field type: Text string

  Example: To find all logs where the event_name field value ends with scan:

  event_name ends with scan

  This query finds logs when the value of the event_name field ends with scan, such as port_scan or network_scan.

   

  11. greater than

  Behavior: The range query using the greater than operator checks for values greater than a specified value.

  Definition: Returns results when the field value is greater than the given threshold.

  Field type: Number, date

  Example: To find critical events, which have a severity level of 75 or higher:

  event_score is greater than 74

  This query finds events when the value in the event_score field is greater than 74, capturing only critical events.

  Another way to perform the same kind of search using different Lucene query syntax is event_score:{74 TO *}. Both methods are valid in Lucene.

   

  12. greater than or equal to

  Behavior: The range query using the greater than or equal to operator checks for values greater than or equal to a specified value.

  Definition: Returns results when the field value is greater than or equal to the given value.

  Field type: Number, date

  Example: To find events where the severity is greater than or equal to 75:

  event_score is greater than or equal to 75

  This query finds logs when the value in the event_score field is greater than or equal to 75, capturing only critical events.

  Another way to perform the same kind of search using different Lucene query syntax is event_score:[75 TO *]. Both methods are valid in Lucene.

   

  13. less than

  Behavior: The range query using the less than operator checks for values less than a specified value.

  Definition: Returns results when the field value is numerically less than the given value.

  Field type: Number, date

  Example: To find events where the severity level is less than 25:

  event_score is less than 25

  This query finds events when the severity is less than 25, capturing alerts with a severity classified as “notice”.

  Another way to perform the same kind of search using different Lucene query syntax is event_score:{* TO 25}. Both methods are valid in Lucene.

   

  14. less than or equal to

  Behavior: The range query using the less than or equal to operator checks for values less than or equal to a specified value.

  Definition: Returns results when the field value is less than or equal to the given value.

  Field type: Number, date

  Example: To find events where the severity is less than or equal to 24:

  event_score is less than or equal to 24

  This query finds events when the severity is less than or equal to 24, capturing alerts with a severity classified as “notice”.

  Another way to perform the same kind of search using different Lucene query syntax is event_score:[* TO 24]. Both methods are valid in Lucene.

   

  15. in range

  Behavior: The in range operator searches for values that fall within a specified range of numbers or dates.

  Definition: Returns results when a field value falls between two specified values (inclusive), represented by [a TO b], when a is the lower bound and b is the upper bound. The query matches if the value is greater than or equal to a and less than or equal to b.

  Field type: Number, date

  Example: To find events where the event_score falls between 50 and 74 inclusive, which categorizes them as major alerts:

  event_score is in range (from) 50 (to) 74

  This query matches logs when the event_score is between 50 and 74, including 50 and 74.

   

  16. within

  Behavior: The within operator looks for IP addresses that fall within a specified IP address range or netmask.

  Definition: Returns results when an IP address is within the given range or subnet defined by an IP address and netmask. The query matches IP addresses that are within the specified network block.

  Field type: IP addresses and IP addresses with netmasks

  Example: To find events where the srcip is within the subnet 192.168.1.0/24:

  srcip is within 192.168.1.0/24

  This query matches logs when the source IP address falls within the 192.168.1.0/24 subnet, which covers IP addresses from 192.168.1.0 to 192.168.1.255.

   

  17. not within

  Behavior: The not within operator excludes IP addresses that fall within a specified IP address range or netmask.

  Definition: Returns results when an IP address is not within the given range or subnet. The query excludes any IP addresses within the defined network block.

  Field type: IP addresses and IP addresses with netmasks

  Example: To exclude events where the dstip is within the subnet 10.0.0.0/8:

  dstip is not within 10.0.0.0/8

  This query excludes logs when the destination IP address falls within the 10.0.0.0/8 subnet, which covers IP addresses from 10.0.0.0 to

  10.255.255.255.

   

  18. is in lookup

  Behavior: The is in lookup operator checks whether the value of a specified field matches any entry in a predefined lookup list.

  Definition: Returns results when the value of the given field is found in a lookup list. The query matches if the field value exists in the list.

  You can toggle case sensitivity on and off.

  Field type: Text string, number, date, IP address

  Example: To find events where the srcip is in a lookup list of known malicious IP addresses:

  srcip is in lookup malicious_ips_lookup

  This query matches logs when the source IP address appears in the malicious_ips_lookup list.

   

  19. is not in lookup

  Behavior: The is not in lookup operator excludes results when the value of a specified field matches an entry in a predefined lookup list.

  Definition: Returns results when the value of the given field is not found in a lookup list. The query excludes any logs when the field value exists in the list.

  You can toggle case sensitivity on and off.

  Field type: Text string, number, date, IP address

  Example: To exclude events where the dstip is in a lookup list of trusted IP addresses:

  dstip is not in lookup trusted_ips_lookup

  This query excludes logs when the destination IP address appears in the trusted_ips_lookup list.

   

• Value

  The value the condition field will be tested against.

Add String Condition

A string condition consists of a free-form text string using Lucene query string operators and syntax.

Add Inner Group

More complex queries might require inner groups. Inner groups are multiple conditions evaluated as a unit. They are equivalent to parenthetical terms in mathematics.

Selecting this adds an inner (or child) group within the outer (or parent) group, with its own set of conditions.

There can be a maximum of ten layers of nested inner groups in a query + the outer group that encompasses all the inner groups.

Remove This Group

This button appears inside an inner group. Selecting this removes the inner group.

Remove

This button appears to the right of the condition parameter. Selecting it removes the condition.

Using Alert Filters and the Filter Builder

Alert filters ignore events that don't interest you so that you only receive alerts about those events on which you want to focus. Because Stellar Cyber suppresses filtered alerts, they don't appear in the Alerts index. You can create alert filters in the Queries and Filters Manager on System | Queries and Filters or from alert event details at Alerts | View for an Alert Type | ("More info" icon) for an alert event | Actions | Add an Alert Filter.

• Use the Filter Builder in the Query and Filter Manager

• Use the Filter Builder in Alert Event Details

• Add Conditions and Groups

• Alert Filtering Examples

Use the Filter Builder in the Query and Filter Manager

To create an alert filter in the Query and Filter Manager:

1. Select System | Queries and Filters (under Configurations) and on the Alert Filters tab select Create.

   The query and filter builder appears in Alert Filter mode. (To switch to Query mode, select Alert Filter Mode | Query Mode.)

   The options used in alert filter construction are also relevant when working with queries. Both involve defining conditions, applying logic, and using structured syntax to filter or retrieve data.

2. If you are logged in to Stellar Cyber at the root level, choose an individual tenant or All Tenants. This sets the scope of its availability.

   About Share Scope

   You can configure objects such as alert filters to exclude alerts from the Alerts index. Root-level users can set the scope of these alert filters to be All Tenants or a specific tenant on the Stellar Cyber Platform. If a root user creates an alert filter forAll Tenants, then it's available for every tenant to see and use, whereas if a root user creates an alert filter for a specific tenant, then it's available for just that one tenant. Partner-level users can create alert filters whose scope is a tenant in their tenant group, and tenant-level users can create alert filters whose scope is their own tenant, but only root-level users can create alert filters whose scope is All Tenants.

   When partner- and tenant-level users use alert filters that a root-level user created for All Tenants, they only filter alerts that are within the sphere of their own tenant group (for partners) or tenant (for tenant users); they don’t filter alerts that belong to any other tenant group or tenant. From the perspective of partners and tenant users, all alert filters pertain only to alerts within their own tenant group or tenant, regardless of the scope used when creating them.

   In summary:

   • Root users can create alert filters with the scope of All Tenants or the scope of a specific tenant.

   • Partners can create alert filters with the scope of an individual tenant that’s in their tenant group.

   • Tenant users can create alert filters whose scope is their own tenant.

   • Although partners and tenant users cannot create or modify alert filters whose scope is All Tenants, they can see and use them, as well as clone* them.

   • When partner- and tenant-level users use alert filters with a scope of “All Tenants”, they only filter alerts pertaining to their tenant group (for partners) or tenant (for tenant users).

     (* Partners and tenant users can clone an alert filter that has a scope of All Tenants and save it with the scope of an individual tenant. Then they can customize the cloned alert filter to better suit their needs.)

3. Set the operator (AND, OR, or NOT) to determine the relationship between conditions in the group.

4. Select Add condition.

   For details about defining conditions and adding more conditions, inner groups, and new groups of conditions, see Add Conditions and Groups and the other sections later in this topic.

   You can change an alert filter to a query by selecting Alert Filter Mode | Query Mode and then saving it as a query.

5. Select Save | Save As, give the alert filter a meaningful name, optionally add a note about it for future reference, and then Save.

   Stellar Cyber saves the alert filter and displays it in the same tab with its new name.

   As soon as you save an alert filter, Stellar Cyber immediately applies it to alerts and the filtered alerts do not appear in the Alert index. You don't need to apply alert filters manually; upon their creation, Stellar Cyber applies them automatically.

6. To add another alert filter or a query, select the Plus icon ( + ) to the right of the active tab and select New Alert Filter or New Query.

   Stellar Cyber keeps the tab for the first alert filter open, creates a new tab next to it, and switches to the new tab. You can leave both the first and second tabs open and switch back and forth between them as you work.

   You can have up to ten tabs open simultaneously. They can be all alert filters, all queries, or a mix of both.

Use the Filter Builder in Alert Event Details

To create an alert filter from the alert event details:

1. Select Alerts | View for an Alert Type | ("More info" icon) for an alert event.

   Select More Info for an event.

2. Select Actions | Add an Alert Filter.

   

   The Add an Alert Filter dialog box appears with fields pre-populated based on the selected alert.

3. Enter a Name for the filter.

   The name can be up to 100 characters long including spaces

4. Set the operator (AND, OR, or NOT) to determine the relationship between conditions in the group.

5. Select Add condition to start defining your condition.

   For details on defining a condition and adding more conditions, inner groups, and new groups, see the next section, Adding Conditions and Groups, and the other sections later in this topic.

6. (Optional) Add Notes about the alert filter for future reference.

7. Submit.

   As soon as you submit the alert filter, Stellar Cyber immediately applies it to alerts and the filtered alerts do not appear in the Alert index. You don't need to apply alert filters manually; upon their creation, Stellar Cyber applies them automatically.

Add an Inner Group and a New Group

To add an inner group to a group, select Add inner group. Once you do, the original group becomes the outer group. You can add up (up to 10 inner groups). This lets you nest conditions, which allows for more nuanced filtering by combining different criteria.

Use the following group operators to define the logical relationship between conditions within a group—the conditions within an outer group and the conditions within an inner group:

• AND – retrieves results that satisfy all the conditions

• OR – retrieves results that satisfy at least one of the conditions

• NOT – excludes results that satisfy the conditions

Select Add new group to add a new group of conditions and inner groups. The relationship between two or more outer groups is always OR.

Keep Track of Per-Tenant Alert Filter Statistics

By default, the Alert Filters table displays a Hit Count column that helps you keep track of how many alerts have been excluded by an alert filter on a per-tenant basis. Use this feature as follows:

1. Select System | Queries and Filters (under Configurations) | Alert Filters.

2. Locate the Hit Count column.

   If it does not appear, you can add it from the column picker to the left of the table.

3. Select in the Hit Count column header to sort the table by the number of alert filters with the most hits.

4. After sorting the table so you can see entries with non-zero values in the Hit Count column, select any entry in the column to see the number of alerts excluded by the filter broken out by tenant.

Alert Filtering Examples

The following example filters out a vulnerability scanner from triggering port scan alerts.

The following example filters specific tenants. After selecting All Tenants, you can add a condition, search for the tenant_name field, then enter one or more values for specific tenant names.