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 navigation, select Data configuration > Rules > Observable.
Select +.

From the left navigation, 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 dropdown 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 dropdown 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 > Go to search and browse > 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 dropdown 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 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 character, prepend a backslash \ to it.

Example: \{ \}

Note

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

Although the regex syntax used in the UI of the Intelligence Center is that of ElasticSearch, the regex syntax used by EclecticIQ 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.