Keys to Use in Your Queries
Also referred to as fields, keys define the data in your logs. Each event type generally uses the same set of keys, though some keys are optional and may not appear in every event. Keys are the constant, while the values of a key can vary.
This topic contains the list of keys that occur in each standard event type in SIEM (InsightIDR). This is known as the schema; the data structure that allows data to be read by the application.
It is helpful to know which keys you want to search in Log Search, so that you can create queries on the key-value pair and easily find the data you need for your investigation.
It is also helpful to know which type of data the values are presented in–are they strings, timestamps, or numbers, for example–so that you can create precise queries to search them.
Most event types are sent to both Log Search and the Detection Engine, though some are used only for detections. In some cases, the Detection Engine payload also includes additional fields, such as subMethods and detection_context. Some schemas do not have associated event types and are instead part of the Audit Log.
Log Search and detection-based event types
All event types contain keys that can be referenced in your Log Search queries. The lists under each event type display one key on each line and the format of its corresponding value.
All event types contain keys that can be referenced in your Log Search queries. The schema displays each key name, description, and format of its corresponding value.
For example, "action": "STRING" refers to a field or key named ‘action’ and the type of data it contains is a string of alphanumeric characters.
When you know which key you want to investigate, you can find the corresponding log set to select in Log Search.
This section contains the event types and keys that correspond to the log sets that are visible in Log Search. It also includes the event types and keys that inform the logic on which Detection Rules are created.
In the user interface, the Rules Logic tab of the Detection Rules screen specifies the source event type that the detection rule will monitor. For example, look at the from parameter in the rule logic.
from(
event_type = "third_party_alert"
)Use entry_id to help with querying
Each log line includes entry_id, which is a unique identifier assigned to every log line ingested into Log Search. It serves as a reliable reference point, allowing you to quickly locate, correlate, and act on specific events across your environment. By including the entry_id in search queries or automation workflows, you can efficiently trace alerts back to individual log lines, reduce investigation time, and maintain consistent references in audit trails or incident documentation.
The order of keys in the list
This documentation lists the event type keys in alphabetical order for easy reference. The user interface may show them in a different order.
The keys are presented in a list format, which shows parent fields and child fields where they exist. This can help you to search keys by using the query syntax where(parentfield.childfield="value"), for example, where(service_info.alert_name="my-critical-alert").