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
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.
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 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:
The table displays previously configured queries and displays columns for each query name, tenants for which the query is available, query conditions, and (not shown by default) description. It also shows when the query was created and updated and by whom. There's a column showing where the query is in use and an Actions column with options to Edit and Delete it.
The In Use column identifies how many features are using a query before you consider modifying or deleting it. An entry of zero indicates a query is not in use. Hovering your cursor over a usage count causes a pop-up panel to appear with a list of all the features that are using it. Any change you make to a query affects all associated features. If you want to delete a query, you must first remove it from all associated features.
The table displays previously configured alert filters and displays columns for each filter name, tenants for which the filter is available, filter conditions, and its status as active or inactive. It also shows when the filter was created and updated and by whom and any notes about the filter and who wrote them. There's a column showing the hit count, which indicates the number of alerts that have been suppressed by the filter, and an Actions column with options to Edit and Delete the filter.
The query and filter builder is a robust tool that not only lets you construct complex searches and exclusion filters—as the query builders and filter builders on individual feature pages also do—but it also includes Run and Save As functions. The Run option lets you test queries before applying them, ensuring you get expected results without leaving the page. The Save As function lets you make copies of queries and filters and adjust settings, working on up to ten variations in tabbed dialog boxes simultaneously.
To construct queries in the Query and Filter Manager:
-
Log in to the Stellar Cyber user interface (UI) and select System | Queries and Filters (under Configurations).
-
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.
-
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).
-
Set the scope of the query among Stellar Cyber tenants.
About the Scope of Configured ObjectsWhen 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.)
-
-
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.
-
Add one or more conditions or string conditions.
ConditionsA 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 wordmalware
orvirus
but excludes entries that includetest
: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 asfirewall policy security rules
orsecurity 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.
-
-
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.
-
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.
-
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
You can use the query builder in different ways that improve threat detection and operational efficiency. Use queries to define parameters that filter the data you retrieve from the database. Integrate them into automation rules to set conditions that determine when to perform automated tasks. Include them in charts to control the data that appears in dashboards. Additionally, you can save, reuse, and share queries among team members.
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:
-
Navigate to one of the feature pages with a query builder and select New Query.
The Query Builder dialog box appears.
-
Enter a name for the query.
Special characters are not permitted in name fields for Queries, Lookup lists, or Reports/Dashboards. Letters, underscores, spaces, dashes, numbers and periods are permitted.
-
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.
-
Add Condition and enter a field, operator, and value to define a simple query.
-
Add more your conditions, string conditions, and inner groups to the group as necessary.
-
To create a compound query, select Add new group and repeat the previous steps.
-
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:
-
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.
-
Select Edit to open the Build a Query dialog box.
-
You can change the name and description of the query.
Special characters are not permitted in name fields for Queries, Lookup lists, or Reports/Dashboards. Letters, underscores, spaces, dashes, numbers and periods are permitted.
-
You can add, modify, and delete conditions.
-
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:
-
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.
-
Hover your cursor over the number to see a pop-up list of the features using the query.
-
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.
-
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, or 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 OperatorsBehavior: 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 exactlyImpossible 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 avalue
that includes milliseconds, it’s not recommended to useis
oris not
as theoperator
. Use one of the following operators instead:greater than
,greater than or equal to
,less than
,less than or equal to
, orin range
.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 isImpossible Travel Anomaly
while returning events classified as other types of security incidents.When you define a query with a time
field
and avalue
that includes milliseconds, it’s not recommended to useis
oris not
as theoperator
. Use one of the following operators instead:greater than
,greater than or equal to
,less than
,less than or equal to
, orin range
.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 termmalware
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 termmalware
at any position in the text, such asmalware detected
or possiblemalware activity
.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 wordmalware
:xdr_event.description does not contain malware
This query finds logs when the value in the
xdr_event.description
field does not containmalware
anywhere in the text.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 includesapplication
andtraffic
, even when the tokensapplication
andtraffic
are not adjacent as written as the value.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 tokensapplication
andtraffic
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 includeapplication
andtraffic
.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.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.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 withport
:event_name starts with port
This query returns all logs when the value of the
event_name
field starts withport
, such asport_scan
orport_block
.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 withscan
:event_name ends with scan
This query finds logs when the value of the
event_name
field ends withscan
, such asport_scan
ornetwork_scan
.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.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.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.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.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]
, whena
is the lower bound andb
is the upper bound. The query matches if the value is greater than or equal toa
and less than or equal tob
.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.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.
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.
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.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.
Change Query Access between Root Tenant and All Tenants
When Stellar Cyber is deployed as a Managed Security Service Provider (MSSP), the root tenant is the MSSP itself and the sub-tenants are its customers. Each customer of the MSSP is assigned its own logically isolated environment so that security events, logs, configurations, and activities of one tenant are not accessible to another. However, the root tenant has overarching control and visibility into all tenant environments.
When you are logged in to the root tenant, you can create queries that can be used by the root tenant only, by a specific sub-tenant, or by all tenants. When you set the share scope for a query as All Tenants, then all tenants can access the query to see data in charts, dashboards, and Automated Threat Hunting (ATH) rules. When you set the share scope as Root Tenant, then only the root tenant can use the query. Finally, if you are logged in as a sub-tenant user, any queries you create are only accessible within your environment.
It's possible to edit a query created by a root tenant to change its share scope from All Tenants to Root Tenant, and from Root Tenant to All Tenants, even if the query is currently in use.
To see a list of all configured queries, navigate to System | Configuration | Queries.
To change the share scope of a previously configured query, select the Edit icon in the Actions column. If the existing query has a share scope of Root Tenant, you can change it to All Tenants, which allows the root tenant and all sub-tenants that the MSSP manages to access the query. If the existing query has a share scope of All Tenants, you can change it to Root Tenant.
This revokes access to it by the sub-tenants. If the query is in use by one or more tenants, a confirmation prompt appears, explaining that the query is in use and that the change will impact existing charts and reports and that ATH rules using the query will no longer function. To continue with the change of scope, select Confirm.
Using Alert Filters and the Filter Builder
Alert filters exclude 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
To create an alert filter in the Query and Filter Manager:
-
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.
-
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 ScopeYou 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.)
-
-
Set the operator (AND, OR, or NOT) to determine the relationship between conditions in the group.
-
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.
-
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.
-
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:
-
Select Alerts | View for an Alert Type | ("More info" icon) for an alert event.
Select More Info for an event.
-
Select Actions | Add an Alert Filter.
The Add an Alert Filter dialog box appears with fields pre-populated based on the selected alert.
-
Enter a Name for the filter.
The name can be up to 100 characters long including spaces
-
Set the operator (AND, OR, or NOT) to determine the relationship between conditions in the group.
-
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.
-
(Optional) Add Notes about the alert filter for future reference.
-
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 Conditions and Groups
In Stellar Cyber, queries and alert filters are constructed using Lucene Lucene was developed by the Apache Software Foundation. It consists of a search engine library whose software components and functionalities enable the efficient indexing and searching of datasets. It also includes a Lucene query language whose syntax and rules allow you to interact with the data set to search, filter, and retrieve specific data based on the criteria you define. syntax (conditions and groups) that define criteria for matching data. A group consists of one or more conditions and can also contain inner groups to build complex logical expressions. When there are multiple outer groups, each one operates independently and is connected by an "OR" relationship, meaning that if the conditions defined in any outer group are true, the overall query or alert filter condition is satisfied. Within each group, the logical relationships among individual conditions and inner groups can be defined using "AND," "OR," or "NOT" to specify how the conditions should interact. Conditions within a group using "AND" must all be true for the group to match, "OR" allows any condition within the group to trigger a match, while "NOT" excludes any condition within a group from triggering a match. By combining these elements, you can create alert filters that suppress only the alerts matching your criteria so you can focus on more relevant security events.
When building an alert filter, you can add conditions, inner groups, and new groups. There is no maximum number of components that you add to an alert filter. However, the maximum number of layers of nested inner groups is ten (not counting the outer group that encompasses the nest of ten inner groups within it).
Add a Condition
A condition is a specific criterion or set of criteria that data must meet to be included in the result set.
To add a condition to a group, select Add condition and then define its components: field, operator, and value (in some cases multiple values). You can add as many conditions as you like. The operator defines the relationship between the field and the value. The following is a descriptive list of all the operators that Stellar Cyber supports.
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
.
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
.
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
.
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.
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.
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
.
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.
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.
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
.
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
.
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.
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.
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.
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.
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.
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.
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.
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.
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.
When there are multiple conditions, you can drag and drop them to rearrange their order.
Reordering conditions inner groups within their outer group doesn't affect their logical relationship or the results of a query or filter. It simply lets you organize multiple conditions and inner groups within a group as you prefer, such as placing all the conditions at the top and all the inner groups at the bottom.
The following are some points to know when creating conditions:
-
When the Aa icon appears at the left of a condition, you can toggle context-sensitivity on and off. By default, case-sensitivity is off. When case-sensitivity is on, there will only be exact matches to the case of a value. For example, if case sensitivity is off and the value is
test
, all of these are matches:test
,Test
, andTEST
. If case sensitivity is on, then onlytest
matchestest
. -
To know which field name to choose from the Field drop-down list, check the field names that show up in event details such as those at Alerts | View for an Alert Type | ("More info" icon) for an alert event | JSON. Then start typing the field name into the text box. Stellar Cyber uses a predictive search to dynamically narrow down the available options based on your input until you spot the one you want. You can also supplement the predictive search by using the scroll bar to find the field name in the alphabetically ordered list.
To create a condition with a field name that isn't in the Field drop-down list, type in the complete field name. Stellar Cyber displays a new drop-down list between Field and Operator with the following choices of value types: boolean, date, ip, number, and string. Choose the value type, then the operator, and finally enter a value.
-
The values are validated as they are entered. An error message appears if, for example, the value should be an IPv4 address (such as
10.1.1.1
) but it was not formatted in dotted decimal notation. -
When the operator is is, is not, contains, or does not contain, the ("Plus") icon appears, and you can enter multiple values. The relationship between the values is OR.
-
When the Value field doesn't present a calendar and clock for you to select a date and time, manually enter them in UNIX Epoch format The UNIX Epoch format refers to a way of representing time as the number of seconds that have passed since January 1, 1970, 00:00:00 UTC (Coordinated Universal Time)., in seconds.
-
IP addresses with subnet masks are supported.
-
There is no Value for the operators field exists and field does not exist. Simply choose the field that you want to filter alerts for if it exists in an Interflow record or does not exist.
-
The is in lookup and is not in lookup operators let your condition reference a reusable, dynamic list of values. Instead of configuring the same list of values over multiple filters, you can instead reference a lookup (see Working with the Lookups Table ). If you want to add or remove values, you just need to modify the lookup instead of modifying each filter.
-
Invalid conditions—for example, duplicate conditions—are underlined in red and an error icon appears at the end of the condition. Select the error icon to display an error message. Either select Remove duplicate to allow Stellar Cyber to remove the duplicate condition automatically or select Dismiss to correct the duplicate condition yourself.
-
If there are two or more alert filters with the same condition, such as a filter for All Tenants and other filters for specific tenants, Stellar Cyber applies the All Tenants filter first, then the specific tenant filters. This tenant override behavior allows an MSSP admin to set up some general settings for All Tenants, then fine-tune with more refined settings for each tenant.
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 at least one of 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:
-
Select System | Queries and Filters (under Configurations) | Alert Filters.
-
Locate the Hit Count column.
If it does not appear, you can add it from the column picker to the left of the table.
-
Select in the Hit Count column header to sort the table by the number of alert filters with the most hits.
-
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.