Create observable rules#

Observable rules allow you to automatically run actions on observables that specified criteria.

A rule must be Enabled for it to take effect. See Manage observable rules.

Create an observable rule#

Note

Required fields are marked with an asterisk (*).

Start creating a rule:

From the left sidebar, select Data configuration > Rules > Observable.
Select +.

From the left sidebar, select + Create > Rules > Observable rule

Configure the rule#

In the Create observable rule view, fill out the following fields:

Field	Description
Rule name*	Name of rule.
Description	Short description. Should contain context and information on what this rule does.
Action*	Action to apply to observables that match this rule. Select one of the following options from the drop-down menu: Ignore: See Action: ignore Mark as safe: Observables that match this rule have their maliciousness set to “Safe”. Mark as malicious: Observables that match this rule have their maliciousness set to “Malicious”, and a confidence level set to the value set in the Confidence field. For more information on setting maliciousness values, Observable maliciousness.
Confidence*	Appears only if you select Mark as malicious in the Action field. Sets the confidence level of observables that match this rule. For more information on setting maliciousness values, Observable maliciousness.
Enabled	Select this to enable the rule immediately after saving.

Once done, set criteria for your rule.

Set criteria#

Rules will match observables according to criteria you set in the Criteria selection section.

To add criteria, select + Criteria. This displays a drop-down menu with the following options:

Criteria	Description
Entity types	Select one or more entity types that this rule runs against. This criteria matches observables that have a direct relation to an entity of these types.
Observable types	Select one or more observable types that this rule runs against.
Paths	See Criteria: Paths for more information.
Source	Select one source. This rule runs against observables that belong to this source.
Value matches	See Criteria: Value matches for more information.
Link name filter	Select one or more link names. This rule runs against observables with these link names. Select Include observables without a link name to also run against observables that have no link name. Note This filter only applies to bundled observables; that is, observables included inside entities. It does not apply to Enrichment observables. See Observable link types.

Once done:

Select Preview rule to preview matches for this rule.
Select Save to save this rule.
Select Save > Save and new to save this rule and start creating a new rule.
Select Save > Save and duplicate to save this rule and start creating a new rule using settings from this rule.

Action: Ignore#

Rules with the Ignore action:

Prevents matched observables from being ingested or extracted from all sources while the rule is enabled.
When manually run, permanently removes all matched observables from entity neighborhoods.

This means that these observables have been effectively removed from use in EclecticIQ Intelligence Center, but can still be found through Search > Observables.

You can enable the rule without running it to prevent new observables that match the rule from being ingested or extracted, but leave intact existing observables that match the rule.

If you want to delete and ignore an observable, see Ignore observables.

Note

A rule with an Ignore action may display existing observables that it matches in its Matches tab.

These observables will be removed from entity neighborhoods if you manually run the rule.

Criteria: Paths#

Select one or more predefined paths, or manually enter a JSON path to a field in EIQ JSON.

This checks fields in entities on EclecticIQ Intelligence Center, and returns observables directly related to it as matches.

If a Value matches criteria is set, the rule looks up this field in entities and returns its directly related observables as matches if the value of the field matches the value of Value matches.

If no Value matches criteria is set, the rule returns its directly related observables as matches if at least one of the paths is non-empty.

You can select one or more pre-defined paths from the drop-down menu, or enter a custom path by doing the following:

Select the Path field.
Start typing.
Press ENTER or select the Add … option that appears.

The following table describes available predefined paths:

Pre-defined path	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

Note

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.

Criteria: Value matches#

Uses a literal or regex to match observables.

If Paths are not specified, enter a value in the Value match field to match observables that contain that value.

If one or more Paths are specified, the rule attempts to match the contents of all paths to the value specified in Value match.

Specify multiple values by entering one value per line. An observable is matched if it matches at least one of these values.

The value can be a literal or regex.

Currently supported wildcards: * and ?
Escape character: \
Avoid starting a wildcard term with * or ? in search, as it may result in a slow-running query. This does not affect rule matching: rules run on RE2, which matches in linear time and is not slowed by a leading wildcard.

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 character, prepend a backslash \ to it.

Example: \{ \}

Note

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

The regex syntax used in the UI (search) is Elasticsearch regular expression syntax. The regex syntax used by the ingestion engine — for user-provided regular expressions such as content criteria and extraction rules — is RE2 (google-re2).

RE2 guarantees linear-time matching and is safe to run on untrusted input, but it does not support every feature found in other regex flavors. In particular, backreferences and look-around assertions (lookahead and lookbehind) are not supported. A pattern that uses these features is not valid RE2 and cannot be used in a rule.

In the vast majority of cases the difference between the two syntaxes does not cause problems, but if your rule is not matching the way you expect, this may be the reason.

Two differences commonly cause problems:
- Elasticsearch matches against the whole string, whereas RE2 matches anywhere within the string. For example:
Input

Pattern

Elasticsearch

RE2

Cert-BUND

ert

No match

Matches
- You do not need to add ^, \$, or a leading .* to match a value inside a longer string — RE2 finds it anywhere. Add ^ and/or \$ only when you specifically want to anchor the match to the start or end of the string.