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 asRULE
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.
Parameter | Description |
---|---|
| 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). |
Example
[MODEL: dataset=panw_ngfw_traffic] filter appid = "dns" | alter dns_helper = json_extract(event, "$.dns") | alter xdm.network.dns.opcode = to_integer(json_extract_scalar(dns_helper, "$.opcode"), xdm.network.dns.is_truncated = 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 aMODEL
section.Each field used in the
MODEL
andRULE
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 thecall
stage.In this example, both the RULE and
MODEL
sections are provided, so you can see how thecall
stage invokes the rule.[RULE: common_ngfw_modeling] alter xdm.source.ipv4 = json_extract_scalar(actor, "$.client_ip") | alter xdm.network.ip_protocol = if( proto = 6, XDM_CONST.IP_PROTOCOL_TCP, proto = 11, XDM_CONST.IP_PROTOCOL_UDP, proto );
[MODEL: dataset=panw_ngfw_traffic] filter appid = "dns" | call common_ngfw_modeling | alter dns_helper = json_extract(event, "$.dns") | alter xdm.network.dns.opcode = to_integer(json_extract_scalar(dns_helper, "$.opcode"), xdm.network.dns.is_truncated = to_boolean(json_extract_scalar(dns_helper, "$.is_truncated") );
You can use the
config case_sensitive
stage in theMODEL
section to configure whether field values in the XDM are evaluated as case sensitive or case insensitive. Theconfig 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 isfalse
; case is not considered when evaluating field values.Note
The
→ → → setting can overwrite thiscase_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 toauthentication
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
Important
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.target.resource_name
,xdm.logon.type
,xdm.source.user_agent
, andxdm.source.host.device_category
. 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.
Note
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.