Parsing Rules file structure and syntax - The Parsing Rules file consists of multiple sections of three types, which also represent the custom syntax specific to Parsing Rules. - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

INGEST: This section is used to define the resulting dataset.

COLLECT (Optional): This section defines a rule that enables data reduction and data manipulation at the Broker VM to help avoid sending unnecessary data to the Cortex XSIAM server and reduce traffic, storage, and computing costs. In addition, the COLLECT section is used to manipulate, alter, and enrich the data before it’s passed to the Cortex XSIAM server. While this rule is optional to configure, once added this rule runs before the INGEST section.

CONST (Optional): This section is used to define strings and numbers that can be reused multiple times within Cortex Query Language (XQL) statements in other INGEST sections by using $constName.

RULE (Optional): Rules are part of the XQL syntax, which are tagged with a name, and can be reused in the code in the INGEST sections by using [rule:ruleName].

EXTEND (Optional): This section is used to chain your Parsing Rules logic to extend your existing default RULE sections, which are added by a Content Package you installed from the Marketplace. An EXTEND section runs immediately after the default RULE section that it extends and enables data manipulation without overriding or interfering with the existing vendor Parsing Rules.

A statement never starts with a dataset or preset selection. The query's data source is meaningless. It is transparent to the user where the raw logs are coming from, fully handled by the system.

Only the following XQL stages are permitted: alter, fields, filter, and join. In addition, a new call stage is supported, which is used to invoke another rule.

Only the following XQL functions are permitted in all sections: parse_timestamp, parse_epoch, and regexcapture.

No output stages are supported.

A Rule object can only contain a single statement.

A join inner query is restricted to using a lookup as a data source and is only supported in XQLp stages.

There is no default lookup, so all join inner queries must start with dataset=<lookup> | ....

CONST reference ($MY_CONST) is supported.

An IN condition can only take a sequence list, such as device_name in (“device1”, “device2”, “device3”) and not another XQL or XQLp inner queries.

You can't create parsing rules for Next-Generation Firewall (NGFW) datasets that are in the format panw_ngfw_<text>_raw, and the Observability dataset called panw_observability_raw.