MODEL - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM Administrator Guide

Cortex XSIAM
Creation date
Last date published
Administrator Guide

Learn how to write a MODEL section in a Data Model Rules file, and about the syntax to use in the file.

A MODEL section is used to define the mapping between a single dataset and the data model. The MODEL section is mandatory per dataset. A RULE section is optional, and is used to help organize the MODEL sections.

MODEL syntax is derived from Cortex Query Language (XQL), with a few modifications, as explained in Data Model Rules Syntax. In addition, MODEL sections contain the following syntax add-ons.

  • You can have multiple MODEL sections.

  • MODEL sections take parameters, and not names as RULE sections use, where some are mandatory and others are optional.

    [MODEL: dataset=<dataset>, content_id=<content_id>]
    <build the XQL logic>;

The parameter descriptions are explained in the following table.




The name of the dataset that contains the source data to apply the mapping on (mandatory).


Identifier of the content as defined in the content package from the Marketplace. This parameter is relevant only for Default Rules and is not available in User Defined Rules (optional).


[MODEL: dataset=panw_ngfw_traffic]
filter appid = "dns"
| alter dns_helper = json_extract(event, "$.dns")
| alter = to_integer(json_extract_scalar(dns_helper, "$.opcode"), = to_boolean(json_extract_scalar(dns_helper, "$.is_truncated")

Points to keep in mind when writing MODEL sections:

  • MODEL parameter names are not case-sensitive.

  • Cortex Data Model (XDM) System fields (_time, _insert_time, _vendor, _product) are mapped automatically from the dataset from the fields with the same names.

  • As section order is not significant, you do not have to declare a RULE before using it in a MODEL section.

  • Each field used in the MODEL and RULE sections is constructed using dot notation with a specific format. Each field must be part of the predefined field set of the data model's schema. However, temporary variables, which will not affect the modeling, may be used. For more information, see Field Structure.

  • A MODEL section can invoke a rule using the call stage.

    In this example, both the RULE and MODEL sections are provided, so you can see how the call stage invokes the rule.

    [RULE: common_ngfw_modeling]
    alter xdm.source.ipv4 = json_extract_scalar(actor, "$.client_ip")
    | alter = if(
    	proto = 6, XDM_CONST.IP_PROTOCOL_TCP,
    	proto = 11, XDM_CONST.IP_PROTOCOL_UDP,
    [MODEL: dataset=panw_ngfw_traffic]
    filter appid = "dns"
    | call common_ngfw_modeling
    | alter dns_helper = json_extract(event, "$.dns")
    | alter = to_integer(json_extract_scalar(dns_helper, "$.opcode"),
   = to_boolean(json_extract_scalar(dns_helper, "$.is_truncated")
  • You can use the config case_sensitive stage in the MODEL section to configure whether field values in the XDM are evaluated as case sensitive or case insensitive. The config case_sensitive stage must be added at the beginnning of the query. If you do not provide this stage in your query, the default behavior is false; case is not considered when evaluating field values.


    The SettingsConfigurationsXQL ConfigurationCase Sensitivity (case_sensitive) setting can overwrite this case_sensitive configuration for all fields in the application except for BIOCs, which will remain case insensitive no matter what this setting is set to. For more information on this setting, see Define XQL Configuration Settings.

  • Cortex XSIAM enables analytics to run on the following data:

    • All mapped network data to the network 5 tuple (source IP, source port, target IP, target port, IP protocol), automatically creating network stories for XDM network data.

    • All mapped authentication data, automatically creating authentication stories for XDM identity data when the xdm.event.type field is set to authentication and all of the following fields contain data:

      • xdm.source.ipv4

      • xdm.source.user.upn

      • xdm.event.original_event_type

      • xdm.event.outcome

      • xdm.event.outcome_reason

      • xdm.event.operation


      To maximize the variety of alerts that are retrieved based on the XDM authentication stories, we recommend that the following additional fields are populated:, xdm.logon.type, xdm.source.user_agent, and Should you decide to change the default XDM mappings, ensure that both the mandatory and recommended fields are populated and do not contain any empty values.


    We recommend that you do not configure the same data source in both Marketplace and using a Cortex XSIAM data collector. Yet, if you do, the following will happen:

    • For network data, all relevant logs from the different data sources are stitched to the same network story.

    • For authentication data, all relevant logs from the different data sources are stitched to the same authentication story as long as the logs contain the network 5 tuple (source IP, source port, target IP, target port, IP protocol). The rest of the logs, without the network 5 tuple, create duplicate authentication stories.