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:
OR
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:
|
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 sources. 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. |
Once done:
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 |
|
All |
Information source, References |
|
All |
Title |
|
All |
Affected assets, Properties affected |
|
Incident |
Observables |
|
Indicator |
Sightings |
|
Indicator |
Raw events |
|
Sightings |
Security control, Identity |
|
Sightings |
Security control, References |
|
Sightings |
Resources, Infrastructure |
|
TTP |
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.