FAQL

How are references to attributes that don’t exist handled?

In attribute selectors they’re quietly dropped. For instance, in the case of something like http_activity.*.ip, all attributes of http_activity that are not objects with an ip attribute will be ignored.

But when a search filter is specified for an attribute that is only in some of the selected attributes, the events and objects it does not apply to will still be requested. For instance, QUERY #network.* WITH *.user_agent CONTAINS ‘Mozilla’ will request all events in the network category but only apply the user agent filter to http_activity events.

How are follow up queries specified?

Follow up queries (FUQs) are how Query follows relationships between events and objects.

In FSQL, follow up queries are as easy as dot notation:

• http_activity.src_endpoint - follow up from http_activity to its src_endpoint relationship, a network_endpoint object.
• http_activity.*.* - all available follow up queries to three levels deep
• http_activity//*:primitive - All primitive (non-object) attributes of http_activity at all levels without following recursive relationships.

How are observable searches performed?

FSQL provides the % observable operator to add all observables of a given name or identifier to an attribute selection. For example, network_activity.%ip expands to over 20 attributes of the network_activity event.

But those with a deep technical understanding of Query know that some connectors are optimized for searches on an event’s observables attribute. You can take advantage of this optimization by writing queries as follows:
QUERY ssh_activity.*
WITH ssh_activity.observables.value = '192.168.0.1'
AND ssh_activity.observables.type_id = 'IP Address'