Query's Federated Search Platform

Query’s search contract is the interface into its query engine and Query's federated search capabilities. It is the combination of the data model and filters allowed on that data.

Query views data through an OCSF lens: all of your data, regardless of source, are represented as OCSF events. Query Federated Search provides a view of these events narrowed based on your search criteria and selected connectors.

When you build a search request for Query, you select events and, optionally, attributes from the data model to be included in results. Filters can be specified for each desired event type to narrow the result set, and connections can be specified. Query requires that a time range be specified to avoid large scanning queries to data sources, and all events have a time property.

Filters describe characteristics of records to be included in the result set.

The most basic form of filters – predicates – describe an attribute (e.g. dns_activity.src_endpoint.ip), an operator (=, contains, etc.), and a value for comparison. The allowed filter operators for an attribute are determined by its data type, which is defined in the QDM.

Filters on lists or arrays – more formally known as quantifiers – can be thought of as a predicate that must be true for ANY or ALL elements in the list. We believe that ANY is the right default choice but support ALL for all lists, with some connector-specific exceptions. There are roughly 16,000 lists in OCSF 1.3, so this comes up more often than you might think.

The search contract also allows grouping filters with AND (all filters must match) or OR (at least one filter must match). It also supports negating filters, so that entire groups can be negated. This is different from using negated forms of operators, but can be used to the same effect.