You can create entity rules that conditionally match entities using content criteria.

To get started with content criteria for entity rules:

Create or edit an entity rule.
In the Criteria selection section, select + Criteria.
From the drop-down menu, select Content criteria

This brings up the complex content criteria tool.

Complex content criteria tool

The complex content criteria tool allows you to add conditional content-based matches to your entity rules.

The Content criteria must evaluate to “true” to generate a match for the entity rule.

You can only have one Content criteria per entity rule.
Conditions are evaluated as “true” or “false”.
Groups are AND or OR groups of conditions.
- AND groups must have all conditions for the group to evaluate to “true”.
- OR groups just need one condition to be “true” for the group to evaluate to “true”.

Field name	Description
Path*	JSON path for an entity’s field to evaluate. Known issue: In 2.13.0 and earlier, predefined items in this drop-down list may not work. Instead, manually enter JSON paths for your content criteria.
MATCHES/DOESN’T MATCH	MATCHES: Condition evaluates to true if an entity has a Path whose value is equal to Value. DOESN’T MATCH: Condition evaluates to true if an entity has a Path whose value is not equal to Value.
Value*	Enter a value to evaluate.

images/download/attachments/86440859/content-criteria-02.png

JSON paths in content criteria

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:
  
  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.