Query Syntax

Secure60 Platform has a simple and flexible query language that is used in various parts of the platform. The query syntax allows selection of specific fields, matching of partial text, regex and vairous comparison operators. The syntax also allows grouping of conditions to achieve sophisticated matching rules.

Query sytax is used in the following key system components:

• Search Page - All searches are in the query syntax format specified below. Search also provides a guided query builder that constructs this syntax for you field-by-field.
• Rule Conditions - Rules that execute in the Secure60 platform are written with a condition statement that is a query in the Secure60 query syntax

Open Search

Secure60 supports flexible open search functionality that allows you to search for terms across multiple fields without specifying individual field names. This provides a quick and intuitive way to find relevant events.

Open Search Syntax

Single Term Search:

• error - Searches for “error” across all default fields

Multiple Terms (AND logic):

• error timeout - Searches for events containing both “error” AND “timeout” across all default fields

Exact Phrase Search:

• "disk full" - Searches for the exact phrase “disk full” across all default fields

Combining with Field Queries:

• error AND user_name = 'admin' - Combines open search with specific field queries
• (login failed) OR ip_src_address = '192.168.1.100' - Uses grouping with open search

Default Search Fields

By default, open search queries are executed across the following fields for optimal performance:

• message_text - Log message content
• host_name - Source hostname
• ip_src_address - Source IP address
• ip_dst_address - Destination IP address
• user_name - Username associated with the event

Configuration Options

On-premise and custom deployments have additional configuration options available:

• All Fields Search - Search across every field in the event data
• Custom Field Sets - Define specific fields to include in open search queries
• Disable Open Search - Fall back to traditional field=value queries only

Contact your system administrator for information about available configuration options in your deployment.

Query elements

Secure60 supports two main query types:

1. Open Search (described above) - Search terms without field specification
2. Traditional Field Queries (described below) - Explicit field, operator, and value combinations

A basic traditional field query looks like: fieldname operator value

• An example of a query might be: ip_src_address = '43.53.63.62'

Multiple basic query elements can be joined together with a keyword

• An example of a multiple field query might be: ip_src_address = '43.53.63.62' AND host_name = 'testserver4.example.com'

Query component evaluation can be controlled by using grouping

• An example leveraging grouping fields might be: (ip_src_address = '43.53.63.62' AND host_name = 'testserver4.example.com') OR (ip_src_address = '8.8.8.8')

Query element using regex and searching in a case insensitive manner

• An example might be: ip_geo_city_name ~ '(?i)melbourne'

Element reference

fieldname

• Any alphanumeric value

operator

• = Exact match
• != Not match
• : Contains - Partial text match, case insensitive

  • A plain value is a substring search on its own: app_name : 'sshd' matches anywhere in the field. You do not need to surround it with %.

  • Case is ignored, so app_name : 'SSHD' and app_name : 'sshd' return the same rows.

  • (Polling Rules Only) Expression can contain normal characters and the following metasymbols:

    • % indicates an arbitrary number of arbitrary characters (including zero characters).
    • _ indicates a single arbitrary character.
    • \ is for escaping literals %, _ and \ — see Quoting and escaping a value

  • Supplying your own % at the start or end anchors the match instead of adding to it:

    Written	Matches
    field : 'value'	anywhere in the field (the default)
    field : 'value%'	field starts with value
    field : '%value'	field ends with value
    field : '%value%'	anywhere in the field (same as the plain form)

  • (Streaming Rules) Expression matches text provided exactly (no wildcards). Never use % in a streaming rule — it is matched as a literal percent sign.

• !: Not Contains - Partial text not match, case insensitive. Follows the same anchoring rules as :.
• < or <= Less than or Less than equal to
• > or >= Greater than or Greater than equal to
• ~ Regex search (Not available in Streaming Rules)
  • Google RE2 syntax
  • Use for smaller time periods (minutes to hours) as will be lower performance across large datasets

value

• Any alpha numeric along with special or escape characters
• When operator is an exact match (eg =) text only, and the comparison is case sensitive
• When operator is a text match (eg :) the value is matched anywhere in the field and case is ignored. Add a % at the start or end only when you want to anchor the match to the end or the start of the field
• When operator is regex match (eg ~) then can include re regex syntax

Quoting and escaping a value

A value is written between single quotes ('…') or double quotes ("…"), and \ is the escape character inside both.

Written	Means
\%	a literal percent sign, not a wildcard
\_	a literal underscore, not a wildcard
\\	a literal backslash
\'	a literal single quote
\"	a literal double quote

Two consequences are worth stating outright, because Windows paths run into both:

• A value that ends in a backslash must write it as \\. process_image : '%C:\Windows\\' is correct; '%C:\Windows\' reads the final \' as an escaped quote, leaves the literal unterminated, and is rejected with Unterminated string literal in query.
• A backslash in front of anything other than the characters in the table above is an ordinary backslash, so a path segment such as '%\rundll32.exe' needs no escaping at all. Escaping it anyway ('%\\rundll32.exe') matches the same rows.

The other quote character is available whenever escaping would be noisier than switching: user_name = "O'Brien" and user_name = 'O\'Brien' are the same query.

Streaming rules resolve the same escapes, so one rule means one thing in both engines — but they match the resulting text exactly, with no wildcards, so a % that survives escaping is matched as a percent sign.

Functions

Instead of a fieldname we make a number of functions available to enhance query feature set

Usage of a function is to state the function, if data evaluates to true then results from this function will be included

Function List (Not available in Streaming Rules):

• isField('fieldname') - Used to look for the presence of a specific field (with any value)
  • fieldname - Any valid Secure60 fieldname
  • Applies to Event and Signal data types
• !isField('fieldname') - Used to exclude a specific field (with any value)
• isIPAddressInRange('fieldname', 'prefix')
  • fieldname - Any valid Secure60 fieldname
  • prefix - String IP address with subnet (Eg. 127.0.0.0/24)
• !isIPAddressInRange('fieldname', 'prefix') - Used to exclude an IP address from matching
• isInList('list_id', 'fieldname') - Applies filtering logic to the query to only return results that have a match between the fieldname provided and a List Item in the list_id provided.
  • fieldname - Any valid Secure60 fieldname
  • list_id - Any valid List ID
• !isInList('list_id', 'fieldname') - Applies filtering logic to the query to exclude results that have a match between the fieldname provided and a List Item in the list_id provided.
  • fieldname - Any valid Secure60 fieldname
  • list_id - Any valid List ID
• isEntity('entity_name') - Returns all activity belonging to a registered entity, matched across every identifier recorded against it.
  • entity_name - The entity’s name, exactly as shown on the Entities page (e.g. Host 2)
  • Applies to Event data types
• isEntityGroup('group_name') - Returns all activity belonging to any member of an entity group.
  • group_name - The group’s name, exactly as shown on the Entities page
• !isEntity('entity_name') / !isEntityGroup('group_name') - Exclude all activity belonging to that entity or group.
• isOlderThanDays('days') - Returns records whose timestamp is at least days old.
  • days - A whole number of days
  • Measured against the record’s own timestamp, so it applies to events, signals, entities and threats alike. The unit is days, and deliberately only days: a week or month comparison counts calendar boundaries crossed rather than elapsed time, so a record described as “one month old” could be only a few days old.
• isNewerThanDays('days') - Returns records whose timestamp is less than days old.
• !isOlderThanDays('days') / !isNewerThanDays('days') - The inverse of each.
• isBusinessHours('start_hour', 'end_hour', 'timezone') - Returns records that fall on a weekday between the two hours, in the timezone given.
  • start_hour, end_hour - Whole hours, 0 to 23. The start hour is inclusive and the end hour is exclusive, so ('08', '18', ...) covers 08:00:00 until 17:59:59 and treats 18:00:00 as outside business hours.
  • timezone - An IANA timezone name, for example Australia/Sydney. Log timestamps are stored in UTC, so the timezone is what makes the result mean anything locally.
• !isBusinessHours('start_hour', 'end_hour', 'timezone') - Returns records outside those hours: any weekend, or any weekday before the start hour or at and after the end hour. This is the form to use for after-hours detections.
• isWeekend('timezone') - Returns records that fall on a Saturday or Sunday in the timezone given.
• !isWeekend('timezone') - Returns records that fall Monday to Friday.
• isHourBetween('from_hour', 'to_hour', 'timezone') - Returns records that fall within an hour window on any day, in the timezone given. The window may cross midnight: ('22', '02', ...) covers 22:00 to 02:59.
• !isHourBetween('from_hour', 'to_hour', 'timezone') - Returns records outside that window.

Notes on the time functions:

• There is no NOT keyword in the query language, so each function is registered with its own ! form. !isBusinessHours(...) is a true complement of isBusinessHours(...) over the same arguments: every record matches exactly one of the two.
• The timezone is an argument rather than an account setting, so the same rule can be deployed to estates in different countries by changing one value.
• These functions are evaluated at query time, so they apply to data already stored as well as to data arriving now.
• An hour comparison cannot use a data-skipping index. Combine these functions with a time range or another field filter rather than relying on them as the only condition of a query spanning many days.

Notes on isEntity:

• The value is the entity’s name, not one of its identifiers. isEntity('Host 2') is correct; isEntity('192.1.2.44') will not match, even if that IP is one of its identifiers.

• The point of the function is that you do not need to know how an entity happens to be recorded in each log. A host registered with a hostname and an IP is matched by both host_name='web-01' events and ip_src_address='10.1.2.3' events from a single isEntity('Web 01').

• Matching is done against the identifiers you register on the entity, compared against these log fields:

  Entity type	Fields matched
  Host	host_name, ip_src_address
  User	user_name
  Application	app_name

  An identifier only matches if its value appears in one of those fields. Registering a MAC address or an FQDN identifier, for example, will only match where that value is present in host_name.

• Entity names are not required to be unique. If two entities share a name, activity for both is returned.

• Newly created entities, and new identifiers added to an existing entity, take up to a minute to become searchable.

Notes:

• isInList can also be applied via the parameters list_allow_field and list_allow_id for example. See:
  • Lists for a List overview
  • Rules Documentation for Rule specific information
  • Consult the full API specification for additional detail

Notes on usage

Query Type Selection

Use Open Search when:

• Doing exploratory searches across logs
• Looking for general terms or phrases
• Unsure which specific field contains the data
• Want fast, intuitive searching similar to Google or Kibana

Use Traditional Field Queries when:

• Need precise field-specific filtering
• Require exact matches or specific operators (>, <, !=)
• Building complex rule conditions
• Need maximum query performance for known field searches

Examples

Open Search Examples:

• failed login - Find any events mentioning failed logins
• "connection timeout" - Find exact phrase across all fields
• malware AND ip_src_address = '10.0.0.1' - Combine approaches

Traditional Field Query Examples:

• user_name = 'admin' - Exact user match
• event_count > 100 - Numeric comparison
• ip_src_address : '192.168.%' - IP subnet search with wildcards

Technical Notes

• Regex values (~) are the one exception to the escaping table above: they are passed to the regex engine with their backslashes still to be resolved, so a backslash the pattern needs has to be written twice over.
  • Example
    • To make this statement match: process_target_image ~ '\lsass.exe$'
    • A double escape is required: process_target_image ~ '\\\lsass.exe$'