Who rated this post

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

.

The Source of event_type

For 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.

  The Challenge of event_sub_type

  The 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.

  For Example:

  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.

How Filtering Affects Suggestions

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.

• Example:
  If you filter for 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.
• This is because the data model rules define which subtypes are valid for each event type, and the UI leverages this context to help you write valid queries.

Why Do You See a Yellow Line Under ENUM?

If you see a yellow underline under an ENUM constant in the XQL editor, it means:

• The value you typed does not meet the current filter conditions.
• For example, if you filter 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.
• This is a real-time validation to help you avoid writing queries that will return no results due to incompatible conditions.

Summary Table

If you have any questions, fell free to discuss it!