About Content criteria

The key/value pairs in Content criteria accept the following input formats:

Path: the key field input format is a JSON path.
It points to the entity field in the entity structure that holds the relevant data for the content filter.
Value: the value field input format is a regex.
It specifies the data pattern the content filter uses to detect matches.

Path

JSON paths are relative to the top-level data field. The the top-level data field is the implicit root of a JSON path.
For example, to point to the title or to the description fields of an entity, specify title or description, instead of data.title or data.description.
JSON paths are strings pointing to specific JSON fields in a JSON data structure.
They define locations in the entity structure where the rule looks for data values matching specified data patterns.

The JSON path format is a string where dots ( . ) define parent-child relationships in the JSON data structure.
Do not include square brackets ( [ ] ) in the path input: they are stripped during execution.
Therefore, you cannot use square brackets to point to array members through their array index values.

The available options map to corresponding JSON paths in the JSON data structure representing entities in the Intelligence Center.

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

To specify selection criteria pointing to entity data outside the predefined data root JSON object, you can define a different root element than data.
For example, you may want a rule to return matches based on specific tags, metadata, or observable attributes.

To set a JSON path defining a field name other than data as a root field, prefix the field name with raw.:

raw. must be the first element in the JSON path defining the field name.
The second element in the JSON path after raw. becomes the designated JSON path root element for the specified path.

Example

`raw.` prefix	Custom root field	Targeted entity data
`raw.tags`	`tags`	Enables accessing entity tag field values through searching, filtering, and rules.
`raw.extracts.kind`	`extracts.kind`	Enables accessing observable type field values through searching, filtering, and rules.

You can select one or more predefined JSON paths from the available options, or you can enter custom, user-defined JSON paths by typing them in the input field.

If you manually type user-defined JSON paths, they must be valid JSON paths pointing to existing fields in the entity JSON structure.
If you enter invalid JSON paths or valid JSON paths pointing to non-existing fields, they are silently ignored.

To examine the JSON data structure of an entity:

Open the entity detail pane and click the JSON tab.

Alternatively:

In the open entity detail pane, click the menu icon , and from the drop-down menu select Export > JSON to download and save the entity in JSON format.

Value

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 character, 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 Intelligence Center is that of ElasticSearch, the regex syntax used by the Intelligence Center'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.