About the Query Data Model

The Query Data Model is based on the Open Cyber Security Schema Framework (OCSF). OCSF is an open standard with backing and broad participation from the biggest and best brands in security like Splunk, AWS, Broadcom, Cloudflare, CrowdStrike, IBM Security, Okta, Palo Alto Networks, Rapid7, Sumo Logic, Tanium, Trend Micro, and Zscaler.

All search results in Query are represented as events. Events can represent observability data like network and process activity, but also alerts, detections, findings, remediation activities, and even queries to systems of record. Events are grouped into categories. For a complete list of events, see the Event Categories page.

Events have attributes. Attributes can be primitive data types – strings, numbers, boolean values, etc. But attributes can also be objects: compound, reusable attributes with attributes of their own. Some key objects include User, File, and Device. See the Objects section for a complete list. Finally, attributes can be arrays (plural) or scalar (singular).

Events and attributes can be described as paths through the schema in dot notation, e.g. <event>[.<attribute>[.<attribute>[...]]]. All events and attributes have an internal machine-friendly name – all lowercase letters with underscores – and a human-friendly caption with mixed case letters and spaces.

Enumerations (enums for short) are coded attributes. Their value must be one of a list of possibilities (as in a drop-down box). They are very useful for normalizing things like status codes across data sources. Enumeration members have an identifier (usually an integer) and a caption. QDM defines a machine-friendly name as an uppercased caption with underscores substituted for spaces.

Entities (also known as observables) are aliases to multiple attributes across the schema. Entities usually lead to attributes that represent key facts or indicators of compromise. For instance, it’s not uncommon for an event to have half a dozen possible IP addresses associated with it, and remembering all of the paths to an IP in the schema can be cumbersome. Searching for the IP Address observable provides a shortcut to searching for each of those IP addresses explicitly. These are powerful time savers, and especially useful when you want to run broad searches for a specific IOC. A few key entities are IP Address, Email Address, Username, MAC Address, Hostname, and CVE; for a complete list, see the Observable reference page.

OCSF Profiles, Requirements, and Constraints

If you're familiar with OCSF, you may wonder how Query handles profiles. Query enables all OCSF profiles, but does not enforce OCSF field requirements or constraints. We attempt to maximize the amount of data we provide, and some sources just don't provide enough to satisfy all of the requirements for a valid OCSF record.

Representing Time

All events in OCSF have three time attributes: time, start_time, and end_time. Query always provides a value for event time. Most systems of record have only one timestamp for events; in these cases, start_time and end_time will be empty. When you change the value of the time picker in the search bar, you're changing a filter on the time field.