CPS-Compliant Parsers

CPS-compliant parsers use scripts written in CrowdStrike Query Language (CQL) to transform incoming data into searchable events that trigger detections in Next-Gen SIEM.

You can use default parsers to parse incoming data from common formats provided by vendors. To parse incoming data from other formats, create and manage your own custom parsers. For more info about creating and managing custom parsers, see Manage Parsers.

CPS differs from ECS in a number of ways that build on the specifics of the LogScale core architecture. For example, parsers following CPS make all fields in a log event available as actual LogScale fields, even if they don’t match a field in ECS. For more info about the differences, see Differences between CPS and ECS parser fields.

For any given data source, when developing a parser, you can decide which domain-specific fields are applicable to the data.

To use CPS-compliant parsers:

Use CPS-compliant parser tags:
- #Cps.version
- #ecs.version
- #event.dataset
- #event.kind
- #event.module
- #event.outcome
- #observer.type
- #Vendor
Your parsers must populate the CPS-compliant parser fields. For more info, see CPS compliant parser fields.
Manage any fields that don’t match ECS fields. For more info, see Managing non-ECS fields.
Add any additional fields you need beyond the standard fields. For more info, see Adding fields to CPS.

CPS compliant parser fields

This table defines the CPS-compliant fields that are created during parsing

Fields	Descriptions
Event categorization fields	`event.outcome` is only assigned when an event can logically contain an outcome. `event.type` and `event.category` are assigned as LogScale arrays. The arrays can be empty. For more info about event categorization fields, see ECS Categorization Fields.
`#Cps.version`	Contains a `MAJOR.MINOR.PATCH` version number following semantic versioning. This version denotes the version of the standard that the parser targeted during ingestion.
`#ecs.version`	Contains the version of ECS that is being followed by the parser.
`#event.dataset`	Contains the specific name of the dataset within the module described by `#event.module`, prefixed by the value of `#event.module` with a dot in between. This field is only created if it contains information that is not already present in `#event.module`. An example combination of the possible fields in a parser: `#Vendor` = `microsoft`, `#event.module` = `azure`, `#event.dataset` = `azure.entraid`. Note: After ingest, all the fields in LogScale are prefixed with `#`.
`#event.kind`	Contains a value representing the type of information the incoming event contains. If assigning `event.kind:= "alert"`, these fields are required: `event.category[]`, `event.type[]`, `event.severity`. This adheres to the Common Information Model mappings and is required for proper detections logic. If these fields are not available then the event should be set to `event.kind := "event"` and not `event.kind:= "alert"`. `event.severity` must map to a value in the range 1-100. This detections logic interprets numerical severities as follows: Informational (1-19), Low (20-39), Medium (40-59), High (60-79), Critical (80-100). `event.severity` has a default value of 50 if not specified in the raw event.
`#event.module`	The name of the product or service that the event belongs to. Reuse existing values when possible.
`#observer.type`	This field defines the type of observer that the data is originating from.
`Parser.version`	Contains a `MAJOR.MINOR.PATCH` version number following semantic versioning. This version number is specific to the parser that processed the event and is not related to the version of the package from which the parser was installed. The version number is updated according to these rules: Any change to an existing field, whether large or small, is a breaking change. This requires a new major version. If new fields are added, then a new minor version is usually enough to reflect the change. Patch versions are for parser changes that do not affect which fields are output by it, such as performance optimizations, bug fixes, and so on.
`#Vendor`	If the event was parsed with a parser from a package, the vendor name used here must match the vendor name used in the package scope. For example, `fortinet` is used for `fortinet/fortigate`. If a parser sets any of the following fields, those must be consistent with vendor names used in other CPS-compliant parsers: `observer.vendor`, `vulnerability.scanner.vendor`, `device.manufacturer`.

Differences between CPS and ECS parser fields

CPS-compliant parser fields deviate from ECS in these ways:

Fields that parsers use as tags have their names prefixed with # during ingestion.
The field event.original is only present when ingested bulk events are split into multiple events.
The field event.ingested is not present because LogScale uses @ingesttimestamp instead.
The field @timestamp contains a Unix timestamp, rather than a human-readable timestamp.
The following fields have lowercase values:
- *.address
- *.domain
- email.*.address
- host.hostname
- *.hash.*

For more info about ECS fields, see ECS Categorization fields. For more info about metadata fields, see Event Fields.

Managing non-ECS fields

CPS-compliant parsers make all log event fields available as LogScale fields, even if they don’t match an ECS field.

If there are fields from events that don’t exist in ECS, their names are prefixed with Vendor.
- This approach gives ECS fields the root namespace, while vendor-specific fields are consistently prefixed with Vendor.
If a field can exist as both an ECS field and a vendor-specific field, the following logic applies:
- When an ECS field and a vendor-specific field have identical values, the ECS field is preserved and the vendor-specific field is discarded.
- If the value of the fields differ, both fields are preserved. For example, an ECS field might require its value be lowercase, but the original log has mixed casing. In that event, the vendor-specific field contains the original, mixed-case value.

Adding fields to CPS

When creating or editing a custom parser, you can add new CPS-compliant fields.

All fields not directly from ECS must have a capital letter starting at the point where they differ from the schema. For more info about creating and managing custom parsers, see Manage parsers.
- Using capital letters for field names follows ECS guidance about how to add event fields outside the schema. For more info, see Custom Fields in ECS.
  - For example, Parser.version is a fully custom field that is similar to #ecs.version, but it includes the CPS-specific prefix Parser, which requires a capital letter.
  - An example of extending ECS with a custom field is observer.Fictional_field. Here, observer is an existing namespace in the schema, but Fictional_field is a custom CPS-specific field within that namespace.