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

Cortex XSIAM Documentation
Product
Cortex XSIAM
Creation date
2024-03-06
Last date published
2024-10-13
Category
Administrator Guide
Abstract

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 file structure and sSyntax. 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:

Parameter

Description

dataset

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

content_id

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 99. 
[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 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.

    Example 100. 

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

    Note

    The Settings → Configurations → XQL Configuration → Case 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 XQL Configuration.

  • 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

      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, and xdm.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.