Skip paths

The option Skip paths enables defining specific entity fields, that is, specific locations in the entity JSON data structure whose data values you want to exclude from the outgoing feed.

Any values related to the paths you define in this field are ignored.

To skip paths: from the drop-down menu, select one or more options to define which fields and related values in the entity data structure you want to exclude from the outgoing feed content.

The available options represent and map to corresponding JSON paths in the JSON data structure representing entities in the platform.

The JSON path root is the top-level data field, and it is implicit in the JSON paths the menu options map to.

The option Skip paths defines the place in the entity data structure where you want to look for specific data values that you do not want to publish with the outgoing feed.

The platform searches for the specified entity fields and the corresponding values, and it strips the data before publication.

This action applies to all entities published through the outgoing feed.

From the drop-down menu, select the entity field(s) to ignore:

Replace paths

This feature enables defining specific entity fields and specific data patterns related to those fields that the rule should replace with user-defined values, before publishing the data through the outgoing feed.

To replace values in one or more entity fields with other values that are suitable for publication:

1. Click + Add or + More to add a filtering option.

2. From the Path drop-down menu, select an option to define which field in the entity data structure you want to search for values in.

   The available options represent, and map to, corresponding JSON paths in the JSON data structure representing entities in the platform.

   The JSON path root is the top-level data field, and it is implicit in the JSON paths the menu options map to.

   The Path option defines the place in the entity data structure where you want to look for a specific data value that you want to exclude from publishing.

   This option works together with a specified regex to set the data pattern the rule should use to retrieve the desired matching value in the field defined in Path.

   From the drop-down menu, select the entity field(s) to ignore:

   Path option	JSON path	Entity type
   Information source, Identity	information_source.identity.name	All
   Information source, References	information_source.references[]	All
   Title	title	All
   Affected assets, Properties affected	affected_assets[].nature_of_security_effect_properties_affected	Incident
   Observables	observable	Indicator
   Sightings	sightings	Indicator
   Raw events	raw_events	Sightings
   Security control, Identity	security_control.identity.name	Sightings
   Security control, References	security_control.references[]	Sightings
   Resources, Infrastructure	resources.infrastructure.type	TTP
   Resources, Persona	resources.persona	TTP

3. In the Pattern field, define a regex to specify the data pattern the rule should apply to search for the desired data value you want to replace.

   • Currently supported wildcards: * and ?

   • Escape character: \

   • Avoid starting a wildcard query term with * or ?, as it may result in an extremely slow-running query.

     Search and rules use literal values and regex patterns to look for matching values assigned to the corresponding JSON path fields.

   The regex syntax this field accepts is the Elasticsearch regular expression syntax.

   The main peculiarities of the Elasticsearch DSL query syntax are:

   • Anchors – ^ and $ – are implied at the beginning and at the end of the regex.

     Do not include them in the regex pattern input.

   • If you insert explicit anchor characters in the value input field, they are interpreted as literal values.

   • Escape special characters:

     ( . ? + | { } [ ] ( ) " \ / )

     To escape a special characters, prepend a backslash \ to it.

     Example: \{ \}

     At the moment, Elasticsearch regular expression syntax optional operators are not supported.

     Although the regex syntax used in the UI of the platform is that of ElasticSearch, the regex syntax used by the platform’s ingestion engine is Python regex. In the vast majority of cases this does not lead to conflicts, but if your discovery rule is not working the way you want it to, this may be the reason.

     Here are two differences that commonly cause problems:

     • ElasticSearch searches for whole strings, while Python searches everywhere in a string. For example,

       Input: Cert-BUND

       Pattern: ert

       ES result: <none>

       Python: will match

     • ElasticSearch regex syntax requires you to leave out anchors, whereas Python regex syntax requires you to include them.

     If you are experiencing problems in this area, contact Customer Support for help in writing the discovery rule you want.

4. In the Value field, enter the literal value that should replace the string matching the regex data pattern in the outgoing feed.

   This is the actual value that is published through the outgoing feed.

5. Click + Add or + More to add new rows/new input fields as needed.

Example

// Path: where to look for the values to replace
// Option: Resources, Persona
data.resources.persona

// Pattern: value(s) matching the regex are replaced
\[Aa\]l\?ateleco\*

// Value: value replacing the original value matching the regex
The Swedish Chef