- Get Started with Threat Detection Management
- Analytics Rules
- Analytics Rule Classifications
- Create an Analytics Rule
- Manage Analytics Rules
- Tune Analytics Rules
- Share Analytics Rules
- Troubleshoot Analytics Rules
- Analytics Rules Syntax
- Advanced Analytics Rule Syntax vs. Analytics Rule Syntax
- Logical Expressions in Analytics Rule Syntax
- String Operations Using Analytics Rule Syntax
- Integer Operations Using Analytics Rule Syntax
- Time Operations Using Analytics Rule Syntax
- Network Operations Using Analytics Rule Syntax
- Context Operations Using Analytics Rule Syntax
- Entity Operations Using Analytics Rule Syntax
- Correlation Rule Operations Using Analytics Rule Syntax
- Analytics Engine Status
- Correlation Rules
- Threat Scoring
Create an Analytics Rule using JSON
Create analytics rules by defining the analytics rule configuration in a JSON file, then importing the JSON file into Threat Detection Management.
The JSON file defines which events the analytics rule detects, what fields the analytics rule detects in an event, and adds other metadata about the analytics rule.
To create an analytics rule by defining its configuration in a JSON file, you:
To create an analytics rule directly in Threat Detection Management, you can use a point-and-click builder.
You can create an unlimited number of analytics rules, but there is a limit to the number of custom analytics rules you're allowed to enable.
1. Define the analytics rule
Analytics rules are configured in a JSON file that defines which events to detect and what fields to detect in an event and adds other metadata about the analytics rule.
Before you author an analytics rule JSON configuration, ensure you're familiar with the different analytics rule types. Depending on the threat you're detecting, you author an analytics rule of a specific type:
To detect when a user does an action they haven't done before for the first time, create a profiledFeature analytics rule.
To detect well-defined risk signatures or security violations, create a factFeature analytics rule.
To identify a single piece of context data describing an important characteristic in events, create a contextFeature analytics rule.
To detect anomalies in how frequently a behavior happens over a given period, create a numericCountProfiledFeature analytics rule.
To detect anomalies in the total number of times a behavior happens, create a numericDistinctCountProfiledFeature analytics rule.
To track the rate of a specific event or activity over time, create a numericSumProfiledFeature analytics rule.
Each rule type requires different fields in their JSON configuration. As you author your analytics rule, review an example JSON configuration for the rule type you're authoring and ensure you include all necessary fields for your analytics rule to work as you expect:
Review an example JSON configuration and fields for a profiledFeature rule.
Review an example JSON configuration and fields for a factFeature rule.
Review an example JSON configuration and fields for a contextFeature rule.
Review an example JSON configuration and fields for a numericCountProfiledFeature rule.
Review an example JSON configuration and fields for a numericDistinctCountProfiledFeature rule.
Review an example JSON configuration and fields for a numericSumProfiledFeature rule.
2. Import the analytics rule
After you create the analytics rule JSON file, import it into Threat Detection Management.
On the Analytics Rules tab, click Import analytics rules
.
Click Select File, then select a JSON file containing no more than 50 rules and is no larger than 4 MB.
Threat Detection Management validates the analytics rules in the file to ensure you're not importing duplicate analytics rules that already exist in your environment and there are no syntax errors in the analytics rules. Analytics rules that are successfully validated have a green check mark. Troubleshoot any warnings or errors you encounter.
After the analytics rules are validated, click Import Rules.
Imported analytics rules are automatically disabled. The analytics rule author is the account that imported the rule. The analytics rule Created time is the date and time the rule was imported.
After you import the analytics rule, you can further tune the analytics rule using exclusions.
3. Enable the analytics rule
An imported analytics rule is automatically disabled. To activate it and allow it to trigger in your environment, you must enable it. You can enable an individual analytics rule or multiple analytics rules at once.
To enable an individual analytics rule, click the More menu or right-click the analytics rule, then select Enable.
To enable multiple analytics rules:
Select the analytics rules you're enabling:
To select all analytics rules, click the checkbox in the header row.
To select specific analytics rules, click the checkbox for each analytics rule.
Click Enable:
4. Apply the analytics rule to your environment
After the analytics rule is enabled, it's added to a batch of pending changes. To apply the new analytics rule to your environment, you must apply the changes.
Under Engine Status, click View Changes.
Review all rules with pending changes:
Name – The name of the rule with pending changes.
Update – The nature of the change. Update indicates that the change modifies the rule. Obsolete indicates that the change removes the rule.
Change – The nature of the change. Updating indicates that the change modifies the rule. Deleting indicates that the change deletes the rule.
Actions – View rule details or delete the change. To view rule details, click
. To delete the change, click
.
To find specific rules, filter the rules by Update or Change columns.
Select the rules to which you're applying pending changes:
To select all rules, click the checkbox in the header row.
To select specific rules, click the checkbox for each rule.
Determine whether the analytics engine re-trains on past events using the rule changes:
To apply rule changes without re-training the analytics engine on past events, select Apply Changes Without Training.
Consider applying changes without training if you want to apply the changes immediately, minimize disruptions to other Exabeam applications, ensure the analytics engine continues to run in real time, and ensure you don't use any of your entitled training days.
Keep in mind that applying changes without training increases the risk of false positives and limits the analytics engine from adapting to evolving patterns in entity behavior.
To re-train the analytics engine on past events with the rule changes, select Apply Changes and Re-train. By default, the analytics engine begins training using the rule changes on the past 21 days of event data. After the analytics engine finishes training, analytics rules continue to trigger on incoming events in real-time.
To change the start date of events the analytics engine uses to re-train:
Click Advanced Settings.
Under Training Start Date, click the date field, then select a date using the calendar. You can re-train the analytics engine on up to 30 days of events, with a recommended minimum of 14 days of events.
Click Confirm.
Click Apply Rule Changes. If you selected Apply Changes and Re-train, the analytics engine temporarily stops processing incoming events to re-train on past events using the rule changes.
factFeature Analytics Rule JSON Configuration
As you define a factFeature analytics rule, review the structure and required fields for a factFeature analytics rule.
Let's look at an example JSON configuration for a factFeature analytics rule:
{ "version":"1", "ruleDefinitions": [ { "templateId": "DM-Fact-BPM-Public-AccessBlock", "name": "Public access block was removed from an AWS bucket", "description": "The public access block of a bucket or an account in AWS was modified to remove public access prevention. This activity enables the bucket or the entire account to become public to all users.", "applicableEvents": [ { "activity_type": "bucket-accessblock-modify", "platform": "AWS" } ], "detectionReason": "The public access block of bucket ${event.bucket_name} was removed", "type": "factFeature", "mitre": [ { "techniqueKey": "T1530", "technique": "Data from Cloud Storage", "tactic": "Collection", "tacticKey": "TA0009" } ], "useCases": [ "Cloud Data Protection" ], "trainOnCondition": "true", "actOnCondition": "containsAny(toLower(operation), 'putbucketpublicaccessblock', 'putaccountpublicaccessblock') && (toLower(restrict_public_buckets)='false' || toLower(block_public_policy)='false' || toLower(block_public_acls)='false' || toLower(ignore_public_acls)='false')", "value": "true", "suppressThreshold": "10 minutes", "suppressScope": " "scoreUnless": [ "Prof-WinSC-E-O-DE" ], "familyId": "bucket-permission-modification-activity", "ruleGroupId": "bpm-public-group" } ] }
An analytics rule is a JSON object that includes two mandatory fields: version
and ruleDefinitions
.
version
indicates the layout version. It tracks the layout version if there are any updates to the layout or the New-Scale Security Operations Platform. Currently, the version is 1
.
ruleDefinitions
contains one or more rule definitions. The value of ruleDefinitions
is an array. The array contains an object, and each object is a rule definition. The rule definition contains the fields that define an analytics rule and how it functions. Some fields are mandatory for the analytics rule to function while other fields are optional.
Ensure you include all necessary fields for your analytics rule to work as you expect and ensure all field values meet the requirements for a factFeature rule:
Field | Description | Mandatory or Optional | Value Requirements |
---|---|---|---|
templateId | A unique identifier for the analytics rule. | Mandatory |
|
name | The analytics rule name. | Mandatory |
|
description | A description of the analytics rule. | Optional |
|
applicableEvents | The type of events the analytics rule evaluates. | Mandatory |
|
requiredFields | The Common Information model (CIM) fields that must exist in an event for the analytics rule to trigger. Outcomes Navigator uses requiredFields to determine whether an analytics rule is satisfied and to calculate coverage. | Optional | Threat Detection Management automatically generates the value for requiredFields. It is not recommended that you enter a value for requiredFields. |
detectionReason | A dynamic name describing the rule and why it triggered on a specific event. It elaborates on the ![]() | Mandatory |
|
type | The analytics rule type. | Mandatory |
|
mitre | The MITRE ATT&CK® tactics and techniques associated with the analytics rule. | Optional |
|
useCases | Exabeam use case associated with the analytics rule. | Optional | Must be an array of strings. Each string must be an existing Exabeam use case:
|
trainOnCondition | The events on which the analytics rule trains. | Optional |
|
actOnCondition | A high-level filter for the events on which the analytics rule triggers. | Optional |
|
value | The expression used to evaluate whether the conditions required for the rule to trigger are true. | Mandatory |
|
suppressThreshold | How long the analytics rule is suppressed after it's first triggered. When a rule over-triggers, it creates noise, can indicate it's detecting false positives, and cause alert fatigue. To prevent the analytics rule from over-triggering, you can suppress the rule from triggering repeatedly. For example, if you set | Mandatory |
|
suppressScope | The field value on which the analytics rule is suppressed from triggering. To prevent the analytics rule from over-triggering, you can suppress the rule from triggering repeatedly on the values of a specified field. For example, you can suppress the rule from over-triggering on a specific user or an entire network. When the analytics rule is suppressed, it triggers on the first event with a specific field value but is suppressed for all subsequent events with the same field value. | Optional |
|
scoreUnless | A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger. | Optional |
|
familyId | The analytics rule family to which the rule belongs. | Mandatory |
|
ruleGroupId | The analytics rule group to which the rule belongs. | Mandatory |
|
severity | The severity of the threat that triggers the analytics rule. Analytics rule severity is one of the business factors Threat Center uses to calculate a case or alert risk score. Each severity, from low to critical, has a corresponding weight that reduces or increases the risk score. The none severity doesn't affect risk scoring and can be used to test the analytics rule. When Threat Center calculates a risk score, it considers the highest severity of all analytics rule associated with detections grouped under the case or alert. If | Optional |
|
profiledFeature Analytics Rule JSON Configuration
As you define a profiledFeature analyics rule, review an example JSON configuration and the required fields for a profiledFeature analytics rule.
Let's look at an example JSON configuration for a profiledFeature analytics rule:
{ "version":"1", "ruleDefinitions": [ { "templateId": "DM-Prof-WinSC-E-DE-DZ-test", "name": "First service creation on this endpoint for this destination zone", "description": "This is the first time a service creation has been observed on this endpoint for this destination network zone.", "applicableEvents": [ { "activity_type": "service-create", "platform": "Windows" } ], "detectionReason": "First service creation on ${entity.device.dest} for network zone ${trigger.feature_value}", "type": "profiledFeature", "mitre": [ { "techniqueKey": "T1543", "technique": "Create or Modify System Process: Windows Service", "tactic": "Privilege Escalation", "tacticKey": "TA0004" } ], "useCases": [ "Malware" ], "scopeValue": "EntityId('type: Device && direction: Dest')", "featureValue": "dest_zone", "trainOnCondition": "true", "actOnCondition": "true", "scoreUnless": [ "Prof-WinSC-E-O-DE" ], "anomalyThreshold": "90 days", "checkScopeMaturity": true, "checkFeatureMaturity": true, "maturityThreshold": "14 days", "familyId": "windows-service-creation-activity", "ruleGroupId": "wsc-dest-endpoint-access-group" } } }
An analytics rule is a JSON object that includes two mandatory fields: version
and ruleDefinitions
.
version
indicates the layout version. It tracks the layout version if there are any updates to the layout or the New-Scale Security Operations Platform. Currently, the version is 1
.
ruleDefinitions
contains one or more rule definitions. The value of ruleDefinitions
is an array. The array contains an object, and each object is a rule definition. The rule definition contains the fields that define an analytics rule and how it functions. Some fields are mandatory for the analytics rule to function while other fields are optional.
Ensure you include all necessary fields for your analytics rule to work as you expect and all field values meet the requirements for a profiledFeature rule:
Field | Description | Mandatory or Optional | Value Requirements |
---|---|---|---|
templateId | A unique identifier for the analytics rule. | Mandatory |
|
name | The analytics rule name. | Mandatory |
|
description | A description of the analytics rule. | Optional |
|
applicableEvents | The type of events the analytics rule evaluates. | Mandatory |
|
requiredFields | The Common Information model (CIM) fields that must exist in an event for the analytics rule to trigger. Outcomes Navigator uses requiredFields to determine whether an analytics rule is satisfied and to calculate coverage. | Optional | Threat Detection Management automatically generates the value for requiredFields. It is not recommended that you enter a value for requiredFields. |
detectionReason | A dynamic name describing the rule and why it triggered on a specific event. It elaborates on the ![]() | Mandatory |
|
type | The analytics rule type. | Mandatory |
|
useCases | Exabeam use case associated with the analytics rule. | Optional | Must be an array of strings. Each string must be an existing Exabeam use case:
|
mitre | The MITRE ATT&CK® tactics and techniques associated with the analytics rule. | Optional |
|
scopeValue | The event field on which the model for the analytics rule trains; typically an object or entity. | Mandatory |
|
featureValue | The event field on which the model for the analytics rule trains for the scopeValue. For example, if scopeValue is hostname and featureValue is process, the model trains on the behavior of processes executed on hostnames. | Mandatory |
|
trainOnCondition | The events on which the analytics rule trains. | Mandatory |
|
actOnCondition | A high-level filter for the events on which the analytics rule triggers. | Mandatory |
|
scoreUnless | A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger. | Optional |
|
anomalyThreshold | The period of time the model for the analytics rule remembers and trains on an observed data point. After this period, the model forgets the data point and the analytics rule can trigger on the data point again. | Mandatory |
|
checkScopeMaturity | Whether the rule learns more about the field defined in | Optional |
|
checkFeatureMaturity | Whether the rule learns more about the field defined in | Optional |
|
maturityThreshold | The duration of the training period for | Optional |
|
familyId | The analytics rule family to which the rule belongs. | Mandatory |
|
ruleGroupId | The analytics rule group to which the rule belongs. | Mandatory |
|
severity | The severity of the threat that triggers the analytics rule. Analytics rule severity is one of the business factors Threat Center uses to calculate a case or alert risk score. Each severity, from low to critical, has a corresponding weight that reduces or increases the risk score. The none severity doesn't affect risk scoring and can be used to test the analytics rule. When Threat Center calculates a risk score, it considers the highest severity of all analytics rule associated with detections grouped under the case or alert. If | Optional |
|
contextFeature Analytics Rule JSON Configuration
As you define your own contextFeature analytics rule, review the structure and required fields for a contextFeature analytics rule.
Let's look at an example JSON configuration for a contextFeature analytics rule:
{ "version":"1", "ruleDefinitions": [ { "templateId": "DM-Cntx-PC-Critical-Sniffer", "name": "Process is a sniffing tool: True\\False", "description": "Process is a sniffing tool: True\\False", "applicableEvents": [ { "activity_type": "process-create" } ], "detectionReason": "Process is a sniffing tool: ${trigger.value}", "type": "contextFeature", "mitre": [ { "techniqueKey": "T1040", "technique": "Network Sniffing", "tactic": "Credential Access", "tacticKey": "TA0006" }, { "techniqueKey": "T1040", "technique": "Network Sniffing", "tactic": "Discovery", "tacticKey": "TA0007" } ], "useCase": [ "Compromised Credentials" ], "trainOnCondition": "true", "actOnCondition": "true", "value": "ContextListContains('Net Sniffer Processes', toLower(process_name))", "familyId": "process-creation-activity", "ruleGroupId": "pc-critical-process-context-group" } ] }
An analytics rule is a JSON object that includes two mandatory fields: version
and ruleDefinitions
.
version
indicates the layout version. It tracks the layout version if there are any updates to the layout or the New-Scale Security Operations Platform. Currently, the version is 1
.
ruleDefinitions
contains one or more rule definitions. The value of ruleDefinitions
is an array. The array contains an object, and each object is a rule definition. The rule definition contains the fields that define an analytics rule and how it functions. Some fields are mandatory for the analytics rule to function while other fields are optional.
Ensure you include all necessary fields for your analytics rule to work as you expect and ensure all field values meet the requirements for a contextFeature rule:
Field | Description | Mandatory or Optional | Value Requirements |
---|---|---|---|
templateId | A unique identifier for the analytics rule. | Mandatory |
|
name | The analytics rule name. | Mandatory |
|
description | A description of the analytics rule. | Optional |
|
applicableEvents | The type of events the analytics rule evaluates. | Mandatory |
|
requiredFields | The Common Information model (CIM) fields that must exist in an event for the analytics rule to trigger. Outcomes Navigator uses requiredFields to determine whether an analytics rule is satisfied and to calculate coverage. | Optional | Threat Detection Management automatically generates the value for requiredFields. It is not recommended that you enter a value for requiredFields. |
detectionReason | A dynamic name describing the rule and why it triggered on a specific event. It elaborates on the ![]() | Mandatory |
|
type | The analytics rule type. | Mandatory |
|
mitre | The MITRE ATT&CK® tactics and techniques associated with the analytics rule. | Optional |
|
useCases | Exabeam use case associated with the analytics rule. | Optional | Must be an array of strings. Each string must be an existing Exabeam use case:
|
trainOnCondition | The events on which the analytics rule trains. | Optional |
|
actOnCondition | A high-level filter for the events on which the analytics rule triggers. | Optional |
|
value | The specific piece of context data the analytics rule identifies. | Mandatory |
|
scopeValue | The event field on which the model for the analytics rule trains; typically an object or entity. | Mandatory |
|
scoreUnless | A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger. | Optional |
|
anomalyThreshold | The period of time the model for the analytics rule remembers and trains on an observed data point. After this period, the model forgets the data point and the analytics rule can trigger on the data point again. | Mandatory |
|
checkScopeMaturity | Whether the rule learns more about the field defined in | Optional |
|
maturityThreshold | The duration of the training period for | Optional |
|
query | A query that retrieves the specific events that triggered the analytics rule. In many cases, The events retrieved using | Mandatory |
|
familyId | The analytics rule family to which the rule belongs. | Mandatory |
|
ruleGroupId | The analytics rule group to which the rule belongs. | Mandatory |
|
severity | The severity of the threat that triggers the analytics rule. Analytics rule severity is one of the business factors Threat Center uses to calculate a case or alert risk score. Each severity, from low to critical, has a corresponding weight that reduces or increases the risk score. The none severity doesn't affect risk scoring and can be used to test the analytics rule. When Threat Center calculates a risk score, it considers the highest severity of all analytics rule associated with detections grouped under the case or alert. If | Optional |
|
numericCountProfiledFeature Analytics Rule JSON Configuration
As you define a numericCountProfiledFeature analytics rule, review an example JSON configuration and the required fields for a numericCountProfiledFeature analytics rule.
Let's look at an example JSON configuration for a numericCountProfiledFeature analytics rule:
{ "version":"1", "ruleDefinitions": [ { "templateId": "DM-NumCP-DSOW-EC-UD", "name": "Abnormal number of directory service write events for users in this department", "description": "An abnormal number of directory service write events have been observed for users in this department. Directory services typically manage various types of objects to organize and administer resources within a network environment.", "applicableEvents": [ { "activity_type": [ "ds_object-create", "ds_object-modify" ] }, { "landscape": "directory service", "activity": [ "create", "modify" ] } ], "detectionReason": "Abnormal number (${trigger.numeric_value}) of directory service write events for users in department ${trigger.scope_value}", "type": "numericCountProfiledFeature", "mitre": [ { "techniqueKey": "T1484", "technique": "Domain Policy Modification", "tactic": "Privilege Escalation", "tacticKey": "TA0004" }, { "techniqueKey": "T1484", "technique": "Domain Policy Modification", "tactic": "Defense Evasion", "tacticKey": "TA0005" } ], "useCases": [ "Account Manipulation" ], "scopeValue": "EntityAttribute('type: User && direction: Source', 'department')", "trainOnCondition": "true", "actOnCondition": "true", "scoreUnless": [ "NumCP-DSOW-EC-O" ], "anomalyThreshold": "120 days", "checkScopeMaturity": "true", "maturityThreshold": "14 days", "countPer": "EntityId('type: User && direction: Source')", "windowDuration": "1 day", "windowPeriod": "12 hours", "logBase": 2, "minOrderOfMagnitude": 2.0, "query": "(activity_type = (\"ds_object-create\",\"ds_object-modify\") AND landscape = \"directory service\" AND activity = (\"create\",\"modify\")) AND (source_user_entity_id = \"${event.source_user_entity_id}\")", "familyId": "directory-service-object-write-activity", "ruleGroupId": "dsw-event-count-magnitude-group" }, } ] }
An analytics rule is a JSON object that includes two mandatory fields: version
and ruleDefinitions
.
version
indicates the layout version. It tracks the layout version if there are any updates to the layout or the New-Scale Security Operations Platform. Currently, the version is 1
.
ruleDefinitions
contains one or more rule definitions. The value of ruleDefinitions
is an array. The array contains an object, and each object is a rule definition. The rule definition contains the fields that define an analytics rule and how it functions. Some fields are mandatory for the analytics rule to function while other fields are optional.
Ensure you include all necessary fields for your analytics rule to work as you expect and all field values meet the requirements for a numericCountProfiledFeature rule:
Field | Description | Mandatory or Optional | Value Requirements |
---|---|---|---|
templateId | A unique identifier for the analytics rule. | Mandatory |
|
name | The analytics rule name. | Mandatory |
|
description | A description of the analytics rule. | Optional |
|
applicableEvents | The type of events the analytics rule evaluates. | Mandatory |
|
requiredFields | The Common Information model (CIM) fields that must exist in an event for the analytics rule to trigger. Outcomes Navigator uses requiredFields to determine whether an analytics rule is satisfied and to calculate coverage. | Optional | Threat Detection Management automatically generates the value for requiredFields. It is not recommended that you enter a value for requiredFields. |
detectionReason | A dynamic name describing the rule and why it triggered on a specific event. It elaborates on the ![]() | Mandatory |
|
type | The analytics rule type. | Mandatory |
|
mitre | The MITRE ATT&CK® tactics and techniques associated with the analytics rule. | Optional |
|
useCases | Exabeam use case associated with the analytics rule. | Optional | Must be an array of strings. Each string must be an existing Exabeam use case:
|
scopeValue | The event field on which the model for the analytics rule trains; typically an object or entity. | Mandatory |
|
trainOnCondition | The events on which the analytics rule trains. | Mandatory |
|
actOnCondition | A high-level filter for the events on which the analytics rule triggers. | Mandatory |
|
scoreUnless | A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger. | Optional |
|
anomalyThreshold | The period of time the model for the analytics rule remembers and trains on an observed data point. After this period, the model forgets the data point and the analytics rule can trigger on the data point again. | Mandatory |
|
checkScopeMaturity | Whether the rule learns more about the field defined in | Optional |
|
maturityThreshold | The duration of the training period for | Optional |
|
countPer | What of the For example, you can use You use | Optional |
|
windowDuration | The duration of the counting period. | Mandatory |
|
windowPeriod | How often the rule evaluates events during the period defined in | Mandatory |
|
logBase | The log base value used to calculate the minimum count of a given behavior considered anomalous in relation to a previous trigger. The analytics engine uses an exponential function to determine when the count of a given behavior is considered anomalous. With an exponential function, the count of a given behavior must be ever increasing to be considered anomalous. For example, let's say the analytics rule counts number of emails a user sends. The analytics rule triggers when a user sends 10 emails. If the user sends 12 emails, you may not want the analytics rule to trigger again because 12 emails is not unusual compared to 10 emails. However, if the user sends 30 emails, you may consider this behavior anomalous, and you may want the analytics rule to trigger again. With a higher With a lower | Mandatory |
|
minOrderOfMagnitude | The count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the For example, let's say the analytics rule counts number of emails a user sends. If the | Optional |
|
query | A query that retrieves the specific events that triggered the analytics rule. In many cases, The events retrieved using | Mandatory |
|
familyId | The analytics rule family to which the rule belongs. | Mandatory |
|
ruleGroupId | The analytics rule group to which the rule belongs. | Mandatory |
|
severity | The severity of the threat that triggers the analytics rule. Analytics rule severity is one of the business factors Threat Center uses to calculate a case or alert risk score. Each severity, from low to critical, has a corresponding weight that reduces or increases the risk score. The none severity doesn't affect risk scoring and can be used to test the analytics rule. When Threat Center calculates a risk score, it considers the highest severity of all analytics rule associated with detections grouped under the case or alert. If | Optional |
|
numericDistinctCountProfiledFeature Analytics Rule JSON Configuration
As you define a numericDistinctCountProfiledFeature analytics rule, review the structure and required fields for a numericDistinctCountProfiledFeature analytics rule.
Let's look at an example JSON configuration for a numericDistinctCountProfiledFeature analytics rule:
{ "version":"1", "ruleDefinitions": [ { "templateId": "DM-NumDCP-EL-DEC-SE-DE", "name": "Abnormal number of unique destination endpoints observed in successful endpoint login events from this endpoint", "description": "An abnormal number of unique destination endpoints have been observed in successful endpoint login events from this endpoint. These events may include interactive Window logins and other (interactive or not) OS logins.", "applicableEvents": [ { "activity_type": "endpoint-login", "outcome": "success" } ], "detectionReason": "Abnormal number (${trigger.numeric_value}) of unique destination endpoints observed in successful endpoint login events from ${entity.device.source}", "type": "numericDistinctCountProfiledFeature", "mitre": [ { "techniqueKey": "T1078", "technique": "Valid Accounts", "tactic": "Defense Evasion", "tacticKey": "TA0005" }, "useCases": [ "Abnormal Authentication & Access", "Lateral Movement" ], "scopeValue": "EntityId('type: Device && direction: Source')", "featureValue": "EntityId('type: Device && direction: Dest')", "trainOnCondition": "((platform = 'Windows' && inList(login_type, '2', '10', '11', '12')) || !platform = 'Windows')", "actOnCondition": "true", "anomalyThreshold": "90 days", "checkScopeMaturity": "true", "maturityThreshold": "14 days", "windowDuration": "1 day", "windowPeriod": "12 hours", "logBase": 2, "minOrderOfMagnitude": 2.0, "query": "(activity_type = \"endpoint-login\" AND outcome = \"success\") AND (source_device_entity_id = \"${trigger.scope_value}\") AND ( dest_device_entity_id = \"${trigger.feature_value}\") AND ((platform = \"Windows\" AND login_type = (2, 10, 11, 12)) OR NOT (platform = \"Windows\"))", "familyId": "endpoint-login-activity", "ruleGroupId": "el-dest-host-count-magnitude-group" } } }
An analytics rule is a JSON object that includes two mandatory fields: version
and ruleDefinitions
.
version
indicates the layout version. It tracks the layout version if there are any updates to the layout or the New-Scale Security Operations Platform. Currently, the version is 1
.
ruleDefinitions
contains one or more rule definitions. The value of ruleDefinitions
is an array. The array contains an object, and each object is a rule definition. The rule definition contains the fields that define an analytics rule and how it functions. Some fields are mandatory for the analytics rule to function while other fields are optional.
Ensure you include all necessary fields for your analytics rule to work as you expect and ensure all field values meet the requirements for a numericDistinctCountProfiledFeature rule:
Field | Description | Mandatory or Optional | Value Requirements |
---|---|---|---|
templateId | A unique identifier for the analytics rule. | Mandatory |
|
name | The analytics rule name. | Mandatory |
|
description | A description of the analytics rule. | Optional |
|
applicableEvents | The type of events the analytics rule evaluates. | Mandatory |
|
requiredFields | The Common Information model (CIM) fields that must exist in an event for the analytics rule to trigger. Outcomes Navigator uses requiredFields to determine whether an analytics rule is satisfied and to calculate coverage. | Optional | Threat Detection Management automatically generates the value for requiredFields. It is not recommended that you enter a value for requiredFields. |
detectionReason | A dynamic name describing the rule and why it triggered on a specific event. It elaborates on the ![]() | Mandatory |
|
type | The analytics rule type. | Mandatory |
|
mitre | The MITRE ATT&CK® tactics and techniques associated with the analytics rule. | Optional |
|
useCases | Exabeam use case associated with the analytics rule. | Optional | Must be an array of strings. Each string must be an existing Exabeam use case:
|
scopeValue | The event field on which the model for the analytics rule trains; typically an object or entity. | Mandatory |
|
featureValue | The event field on which the model for the analytics rule trains for the scopeValue. For example, if scopeValue is hostname and featureValue is process, the model trains on the behavior of processes executed on hostnames. | Mandatory |
|
trainOnCondition | The events on which the analytics rule trains. | Mandatory |
|
actOnCondition | A high-level filter for the events on which the analytics rule triggers. | Mandatory |
|
scoreUnless | A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger. | Optional |
|
anomalyThreshold | The period of time the model for the analytics rule remembers and trains on an observed data point. After this period, the model forgets the data point and the analytics rule can trigger on the data point again. | Mandatory |
|
checkScopeMaturity | Whether the rule learns more about the field defined in | Optional |
|
maturityThreshold | The duration of the training period for | Optional |
|
countPer | What of the For example, you can use You use | Optional |
|
windowDuration | The duration of the counting period. | Mandatory |
|
windowPeriod | How often the rule evaluates events during the period defined in | Mandatory |
|
logBase | The log base value used to calculate the minimum count of a given behavior considered anomalous in relation to a previous trigger. The analytics engine uses an exponential function to determine when the count of a given behavior is considered anomalous. With an exponential function, the count of a given behavior must be ever increasing to be considered anomalous. For example, let's say the analytics rule counts number of emails a user sends. The analytics rule triggers when a user sends 10 emails. If the user sends 12 emails, you may not want the analytics rule to trigger again because 12 emails is not unusual compared to 10 emails. However, if the user sends 30 emails, you may consider this behavior anomalous, and you may want the analytics rule to trigger again. With a higher With a lower | Mandatory |
|
minOrderOfMagnitude | The count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the For example, let's say the analytics rule counts number of emails a user sends. If the | Mandatory |
|
query | A query that retrieves the specific events that triggered the analytics rule. In many cases, The events retrieved using | Mandatory |
|
familyId | The analytics rule family to which the rule belongs. | Mandatory |
|
ruleGroupId | The analytics rule group to which the rule belongs. | Mandatory |
|
severity | The severity of the threat that triggers the analytics rule. Analytics rule severity is one of the business factors Threat Center uses to calculate a case or alert risk score. Each severity, from low to critical, has a corresponding weight that reduces or increases the risk score. The none severity doesn't affect risk scoring and can be used to test the analytics rule. When Threat Center calculates a risk score, it considers the highest severity of all analytics rule associated with detections grouped under the case or alert. If | Optional |
|
numericSumProfiledFeature Analytics Rule JSON Configuration
As you define a numericSumProfiledFeature analytics rule, review the structure and required fields for a numericSumProfiledFeature analytics rule.
Let's look at an example JSON configuration for a numericSumProfiledFeature analytics rule:
{ "version":"1", "ruleDefinitions": [ { "templateId": "DM-NumSP-EMR-Bytes-DU-Bytes", "name": "Abnormal amount of bytes received in incoming emails for this user", "description": "An abnormal amount of bytes have been received in incoming emails for this user.", "applicableEvents": [ { "activity_type": "email-receive", "outcome": "success" } ], "detectionReason": "Abnormal amount (${trigger.numeric_value}) of bytes received in incoming emails for ${entity.user.dest}", "type": "numericSumProfiledFeature", "mitre": [ { "techniqueKey": "T1566", "technique": "Phishing", "tactic": "Initial Access", "tacticKey": "TA0001" } ], "useCases": [ "Phishing" ], "scopeValue": "EntityId('type: User && direction: Dest')", "featureValue": "bytes", "trainOnCondition": "exists(bytes, vendor)", "actOnCondition": "true", "anomalyThreshold": "90 days", "checkScopeMaturity": "true", "maturityThreshold": "14 days", "windowDuration": "1 day", "windowPeriod": "12 hours", "logBase": 2, "minOrderOfMagnitude": 17.0, "query": "(activity_type = \"email-receive\" AND outcome = \"success\") AND (dest_user_entity_id = \"${trigger.scope_value}\") AND (NOT bytes = null)", "familyId": "email-receive-activity", "ruleGroupId": "emailr-bytes-sum-magnitude-group" } } }
An analytics rule is a JSON object that includes two mandatory fields: version
and ruleDefinitions
.
version
indicates the layout version. It tracks the layout version if there are any updates to the layout or the New-Scale Security Operations Platform. Currently, the version is 1
.
ruleDefinitions
contains one or more rule definitions. The value of ruleDefinitions
is an array. The array contains an object, and each object is a rule definition. The rule definition contains the fields that define an analytics rule and how it functions. Some fields are mandatory for the analytics rule to function while other fields are optional.
Ensure you include all necessary fields for your analytics rule to work as you expect and ensure all field values meet the requirements for a numericSumProfiledFeature rule:
Field | Description | Mandatory or Optional | Value Requirements |
---|---|---|---|
templateId | A unique identifier for the analytics rule. | Mandatory |
|
name | The analytics rule name. | Mandatory |
|
description | A description of the analytics rule. | Optional |
|
applicableEvents | The type of events the analytics rule evaluates. | Mandatory |
|
requiredFields | The Common Information model (CIM) fields that must exist in an event for the analytics rule to trigger. Outcomes Navigator uses requiredFields to determine whether an analytics rule is satisfied and to calculate coverage. | Optional | Threat Detection Management automatically generates the value for requiredFields. It is not recommended that you enter a value for requiredFields. |
detectionReason | A dynamic name describing the rule and why it triggered on a specific event. It elaborates on the ![]() | Mandatory |
|
type | The analytics rule type. | Mandatory |
|
mitre | The MITRE ATT&CK® tactics and techniques associated with the analytics rule. | Optional |
|
useCases | Exabeam use case associated with the analytics rule. | Optional | Must be an array of strings. Each string must be an existing Exabeam use case:
|
scopeValue | The event field on which the model for the analytics rule trains; typically an object or entity. | Mandatory |
|
featureValue | The event field on which the model for the analytics rule trains for the scopeValue. For example, if scopeValue is hostname and featureValue is process, the model trains on the behavior of processes executed on hostnames. | Mandatory |
|
trainOnCondition | The events on which the analytics rule trains. | Mandatory |
|
actOnCondition | A high-level filter for the events on which the analytics rule triggers. | Mandatory |
|
scoreUnless | A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger. | Optional |
|
anomalyThreshold | The period of time the model for the analytics rule remembers and trains on an observed data point. After this period, the model forgets the data point and the analytics rule can trigger on the data point again. | Mandatory |
|
checkScopeMaturity | Whether the rule learns more about the field defined in | Optional |
|
maturityThreshold | The duration of the training period for | Optional |
|
countPer | What of the For example, you can use You use | Optional |
|
windowDuration | The duration of the summing period. | Mandatory |
|
windowPeriod | How often the rule evaluates events during the period defined in | Mandatory |
|
logBase | The log base value used to calculate the minimum count of a given behavior considered anomalous in relation to a previous trigger. The analytics engine uses an exponential function to determine when the count of a given behavior is considered anomalous. With an exponential function, the count of a given behavior must be ever increasing to be considered anomalous. For example, let's say the analytics rule counts number of emails a user sends. The analytics rule triggers when a user sends 10 emails. If the user sends 12 emails, you may not want the analytics rule to trigger again because 12 emails is not unusual compared to 10 emails. However, if the user sends 30 emails, you may consider this behavior anomalous, and you may want the analytics rule to trigger again. With a higher With a lower | Mandatory |
|
minOrderOfMagnitude | The count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the For example, let's say the analytics rule counts number of emails a user sends. If the | Mandatory |
|
query | A query that retrieves the specific events that triggered the analytics rule. In many cases, The events retrieved using | Mandatory |
|
familyId | The analytics rule family to which the rule belongs. | Mandatory |
|
ruleGroupId | The analytics rule group to which the rule belongs. | Mandatory |
|
severity | The severity of the threat that triggers the analytics rule. Analytics rule severity is one of the business factors Threat Center uses to calculate a case or alert risk score. Each severity, from low to critical, has a corresponding weight that reduces or increases the risk score. The none severity doesn't affect risk scoring and can be used to test the analytics rule. When Threat Center calculates a risk score, it considers the highest severity of all analytics rule associated with detections grouped under the case or alert. If | Optional |
|