Hi Everyone,
I’ve seen a lot of questions lately about the usage of constant ENUMs in Cortex XDR/XSIAM, especially after Unit42 released some IOC detection queries. These queries often contain clauses like:
| filter agent_os_type = ENUM.AGENT_OS_WINDOWS and event_type = ENUM.PROCESS and event_sub_type in (ENUM.PROCESS_START, ENUM.PROCESS_STOP)
Many analysts wonder: Where does something like event_type = ENUM.PROCESS actually come from? Palo Alto hasn’t provided much public documentation on this, which can be confusing
.
event_typeFor event_type, there is a relatively simple mapping. Each event type is assigned a unique identifier, for example:
| NUM Constant | Numeric Value | Description |
|---|---|---|
| ENUM.PROCESS | 1 | Process events |
| ENUM.NETWORK | 2 | Network events |
| ENUM.FILE | 3 | File events |
| ENUM.REGISTRY | 4 | Registry events |
| ENUM.INJECTION | 5 | Injection events |
| ENUM.LOAD_IMAGE | 6 | Image load events |
| ENUM.USER_STATUS_CHANGE | 7 | User status changes |
| ENUM.TIME_CHANGE | 8 | Time change events |
| ENUM.THREAD | 9 | Thread events |
| ENUM.CAUSALITY | 10 | Causality events |
| ENUM.HOST_STATUS_CHANGE | 11 | Host status changes |
| ENUM.AGENT_STATUS_CHANGE | 12 | Agent status changes |
| ENUM.INTERNAL_STATISTICS | 13 | Internal statistics |
| ENUM.PROCESS_HANDLE | 14 | Process handle events |
| ENUM.EVENT_LOG | 15 | Windows Event Log events |
| ENUM.EPM_STATUS | 16 | EPM status events |
| ENUM.METADATA_CHANGE | 17 | Metadata changes |
| ENUM.SYSTEM_CALL | 18 | System call events |
| ENUM.DEVICE | 19 | Device events |
| ENUM.HOST_FIREWALL | 23 | Host firewall events |
These are standardized in the Cortex XDR Data Model, so when you use event_type = ENUM.PROCESS, you’re matching all events that have been normalized as process events, regardless of the original log source.
event_sub_typeThe tricky part comes with event_sub_type. There isn’t a single, fixed list you can use, because the valid values for event_sub_type depend on the event_type. For example, if event_type is PROCESS, then event_sub_type might be PROCESS_START or PROCESS_STOP. If event_type is FILE, then event_sub_type could be FILE_CREATE_NEW, FILE_WRITE, etc.
These relationships are defined in the Data Model Rules, the logic that maps raw telemetry from endpoints, firewalls, and other sources into the normalized fields and ENUMs you use in XQL queries.
If you look at the data model rules, you’ll see logic like:
alter xdm.event.operation = if(
event_type=ENUM.PROCESS and event_sub_type=ENUM.PROCESS_START, XDM_CONST.OPERATION_TYPE_PROCESS_CREATE,
event_type=ENUM.PROCESS and event_sub_type=ENUM.PROCESS_STOP, XDM_CONST.OPERATION_TYPE_PROCESS_TERMINATE,
...
)
This means that the valid event_sub_type values are conditional on the event_type. The data model ensures that, for each event, the correct ENUMs are assigned based on the raw log content and context.
When you use a filter clause in XQL, subsequent suggestions in the query builder (autocomplete) are dynamically adjusted based on the data that remains after your filter.
event_type = ENUM.PROCESS, the next time you type event_sub_type =, the suggestions will only include subtypes relevant to process events (like PROCESS_START, PROCESS_STOP), not file or registry subtypes.
If you see a yellow underline under an ENUM constant in the XQL editor, it means:
event_type = ENUM.FILE but then try to use event_sub_type = ENUM.PROCESS_START, the editor will warn you because PROCESS_START is not a valid subtype for FILE events.| What You Do in Query | What Happens Next in Suggestions |
|---|---|
filter event_type = ENUM.PROCESS |
Only process-related subtypes are suggested |
filter event_type = ENUM.FILE |
Only file-related subtypes are suggested |
| Use an invalid ENUM | Yellow underline warns you of a mismatch |
If you have any questions, fell free to discuss it!
