Versions

See the latest version and change history for the CrowdStrike Parsing Standard (CPS) to ensure proper data normalization in Next-Gen SIEM.

Overview

This document describes the standard for the CrowdStrike Parsing Standard (CPS) data format as parsed in Next-Gen SIEM. It is based on Elastic Common Schema (ECS), with all deviations and clarifications noted by version.

Versions

See the latest version for the most recent changes to the CrowdStrike Parsing Standard.

Version 1.2.0

Compared to the previous version, the CrowdStrike Parsing Standard (CPS) is changed in the following ways:

• Removes limitations on event.code mapping
• Removes limitations on the related.* namespace
• Adds a list of current observer.type field values
• Specifies a default event.severity value of 50 in alerts

Version 1.1.0

Compared to the previous standard, the CrowdStrike Parsing Standard (CPS) uses the latest 9.x version of ECS and has changed in the following ways:

• Adds rule of keeping original Vendor. field when normalizing to ECS
• Adds event.severity mapping rules
• Updates the rules and explanation for parser versioning
• Adds rule of using array:append with event.category and event.type
• Adds rule to lowercase all *.email field values
• Adds rule that event.kind := "alert" should only be set when event.category, event.type, and event.severity fields are present and set

Tagged fields

As of this version, the following fields are tagged:

• Cps.version
• Vendor
• ecs.version
• event.dataset
• event.kind
• event.module
• event.outcome
• observer.type

Populated fields for events

As of this version, the following fields are always populated for all events unless there is no applicable ECS value:

• Event categorization fields (kind, type, category, outcome)
  • event.outcome is only assigned when an event can logically contain an outcome.
  • event.type and event.category are assigned as LogScale arrays utilizing array:append() function.
• ecs.version
  • This field contains the version of ECS that is followed by the parser.
• Cps.version
  • This field contains a MAJOR, MINOR, or PATCH version number through semantic versioning.
  • The version denotes the version of this standard, which was targeted by the parser during ingest.
• Parser.version
  • This field contains a MAJOR, MINOR, or PATCH version number through semantic versioning.
  • This version number is specific to the parser which parsed the event, and not related to the version of the package the parser may be installed from.
  • The rules for updating the version number, based on MAJOR, MINOR, or PATCH:
    • MAJOR
      • Modification or removal of one of the key ECS or tagged fields. For example, event.kind, event.module, event.dataset, event.category, or event.type.
      • Modification of five or more unique existing fields, for example name or value changes, in the dataset.
      • Major overhauls or design changes to the parser.
    • MINOR
      • Modification of four or less unique existing fields that are not a patch or error fix. For example, fixing a misspelling or small accidental issues.
      • Additional features or fields that don’t meet the threshold of a major change.
    • PATCH
      • Modifications to existing fields or architecture that have minimal impact on the parser. For example, updating ecs.version.
• Vendor
  • If the event was parsed with a parser from a package, the vendor name used here matches the vendor name used in the package scope. For example, fortinet for Fortinet FortiGate.
  • If a parser sets any of the following fields, those are consistent with vendor names used in other CPS-compliant parsers:
    • observer.vendor
    • vulnerability.scanner.vendor
    • device.manufacturer
  • Note: For guidelines on which vendor name to use, see Vendor guidelines.
• event.kind
  • This field contains a value representing the type of information the incoming event contains.
  • If assigning event.kind := "alert", the following fields are required:

    • event.category[]

    • event.type[]

    • event.severity

      • This field always maps to a value within the range 1-100. The detections logic interprets numerical severities in the following ranges:

        Vendor severity	Range
        Informational	1-19
        Low	20-39
        Medium	40-59
        High	60-79
        Critical	80-100

    • Note: This adheres to the Common Information Model mappings and is required for proper detections logic. If these fields are not available, then the event is set to event.kind := "event" and not event.kind := "alert".

• event.module
  • Contains the name of the product or service that the event belongs to.
  • Existing event.module values are reused whenever appropriate. For more guidelines, see the Module Guidelines.
• 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.

  • Note: If this field doesn’t exist, that is because it doesn’t contain any information beyond what is present in event.module.

  • Example combinations of these fields:

    Vendor	event.module	event.dataset
    microsoft	azure	azure.entraid
    zscaler	zia	zia.web
    cloudflare	zero-trust	zero-trust.network-session

Field deviation

As of this version, for any given data source, the author of the parser determines, on a best-effort basis, which domain-specific fields are applicable to the data.

The following fields are the only fields in the ECS which parsers can deviate from:

• Fields used as tags which have their names prefixed with #.
• event.original is not present as @rawstring is used instead.
• event.ingested is not present as @ingesttimestamp is used instead.
• @timestamp contains a Unix timestamp, rather than a human-readable timestamp.
• event.code is not present for the moment as it’s planned to be tagged in the future.
  • Note: The value from event.code is still available to use in a vendor-specific field. For example Vendor.event_type.
• Related fields are not present. For more info, see Related fields.
• The following fields all have their values lowercased using the en-us locale:
  • *.address
  • *.domain
  • email.*.address
  • host.hostname
  • *.hash.*
  • event.module
  • event.dataset
  • Vendor
  • *.email

Parsers strive to make all fields in a log event available as actual LogScale fields, even if they don’t match a field in ECS. Fields from the event which do not exist in ECS have their name prefixed with the string literal Vendor. This gives the ECS fields the root namespace, while vendor specific fields can always be found with the Vendor. prefix.

Always keep the original Vendor. field when normalizing third-party fields to ECS. When vendor specific field names are not present in the logs, take these actions:

• If vendor documentation provides field names, map values to both Vendor. and ECS fields.
• If vendor documentation does not provide field names:
  • Try to map to an appropriate ECS field.
  • If the ECS field doesn’t exists, create a descriptive Vendor. field name.
• Maintain original field names from vendors.
  • Keep Vendor. field names and values unchanged to ensure direct correlation with source logs.
  • Important: One exception is to replace spaces with underscores (_) in field names. For example, Vendor.User Name should become Vendor.User_Name.

When adding new fields to this standard, all fields which are not taken directly from ECS must have a capital letter from the point where they differ from the schema.

• Using capital letters for field names follows the guidance from ECS about how to add event fields outside the schema. For more info, see Custom fields.
• Example of fully custom field: Parser.version is similar to ecs.version, but the Parser namespace is used by CrowdStrike, so it must start with a capital letter.
• Example of extending ECS with custom field: observer.Fictional_field where observer is an existing namespace in the schema, but Fictional_field is a CrowdStrike field inside the namespace.

Version 1.0.0

The CrowdStrike Parsing Standard was previously maintained in a Package Standards document in the Next-Gen SIEM Packages repo. The parsing standard is now extracted to reference outside of packages.

Compared to the previous standard from the Package Standards document, the CrowdStrike Parsing Standard is changed in the following ways:

• Adds new fields to tag
• Removes the Product field, replaced by guidelines for event.module and event.dataset
• Removes the event.code field to be reinstated later
• Removes the related fields
• Normalizes values for a range of new fields