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 an action is done 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 count of unique values of an event, create a numericDistinctCountProfiledFeature analytics rule.
To track anomalies in the quantity associated with a behavior, 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:

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 The more options menu; three vertical dark grey dots on an off-white background. 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:
  1. Click Advanced Settings.
  2. 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.
  3. 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	Must be a string Maximum 128 characters For custom analytics rules, we recommend that you prefix the ID with C_.
name	The analytics rule name.	Mandatory	Must be a string Maximum 256 characters
description	A description of the analytics rule.	Optional	Must be a string Maximum 1024 characters
applicableEvents	The type of events the analytics rule evaluates.	Mandatory	Must be an array of objects. Each object is a condition an event must meet for the analytics rule to evaluate the event. Conditions define the Common Information Model (CIM) fields an event must contain for the analytics rule to evaluate the event. There is an or relationship between conditions; an event must meet at least one of, not all, the conditions for the analytics rule to evaluate the event. If an event doesn't meet any of the conditions, the analytics rule doesn't evaluate the event.
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 `name` field and adds detail specific to the specific event on which it triggered. It is displayed in Threat Center detections:	Mandatory	Must be a string Maximum 256 characters To customize the `detectionReason` to the event on which it triggered, insert dynamic variables for events, triggers, and entities: To insert a dynamic variable for an event, use the syntax `${event.field_name}`. To insert a dynamic variable for a trigger, use the syntax c`${trigger.fieldname}` To insert a dynamic variable for an entity, use the syntax `${entity.attribute_name}`
type	The analytics rule type.	Mandatory	Must be the string `"factFeature"`
mitre	The MITRE ATT&CK^® tactics and techniques associated with the analytics rule.	Optional	Must be an array of objects. Each object represents an ATT&CK technique and corresponding tactic. Each object must contain the following keys and their values: `techniqueKey` `technique` `tactic` `tacticKey` The value of `techniqueKey` must be an existing ATT&CK technique ID. It must correspond with the value of `technique`. The value of `technique` must be an existing ATT&CK technique name. It must correspond with the value of `techniqueKey`. The value of `tactic` must be an existing ATT&CK tactic name. It must correspond with the value of `tacticKey`. The value of `tacticKey` must be an existing ATT&CK tactic ID. It must correspond with the value of `tactic`.
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: Abnormal Authentication & Access Account Manipulation Audit Tampering Brute Force Attack Cloud Data Protection Compromised Credentials Cryptomining Data Access Data Exfiltration Data Leak Destruction of Data Evasion Lateral Movement Malware Phishing Physical Security Privilege Abuse Privilege Escalation Privileged Activity Ransomware Workforce Protection
trainOnCondition	The events on which the analytics rule trains.	Mandatory	Must be a string String must be `"true"`; factFeature analytics rules must train on all events
actOnCondition	A high-level filter for the events on which the analytics rule triggers.	Mandatory	Must be a string If the analytics rule triggers on all events, string is `"true"` If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule triggers. Ensure that you use valid syntax to define your expression.
value	The expression used to evaluate whether the conditions required for the rule to trigger are true.	Optional	Must be a string If all conditions are met when the analytics rule triggers, then string is `"true"`. For most analytics rules, the value of `value` is `"true"`. To differentiate between triggers, string can be an expression that defines the specific conditions required for the rule to trigger. Ensure that you use valid syntax to define your expression.
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 `suppressThreshold` to two minutes, if the analytics rule triggers once, then triggers again within two minutes, the second trigger is suppressed.	Mandatory	Must be a string Must be a minimum of 1 minute and maximum of 10 minutes
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	Must be a string String is an expression that defines the field value on which the analytics rule is suppressed from triggering. Ensure that you use valid syntax to define your expression.
scoreUnless	A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger.	Optional	Must be an array of strings Each string must be an analytics rule `templateID`.
familyId	The analytics rule family to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule family
ruleGroupId	The analytics rule group to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule group The analytics rule group must belong under the analytics rule family specified in the familyId field.
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 `severity` is not included in the rule configuration, the analytics rule is automatically assigned the Medium severity by default.	Optional	Must be a string String must be a valid severity level: None – Analytics rule is not used in risk scoring. Used for testing the analytics rule. Low – Reduces risk score. Medium – Doesn't adjust the risk score. High – Increases risk score. Critical – Significantly increases risk score and automatically creates a case.

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.

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	Must be a string Maximum 128 characters For custom analytics rules, we recommend that you prefix the ID with C_.
name	The analytics rule name.	Mandatory	Must be a string Maximum 256 characters
description	A description of the analytics rule.	Optional	Must be a string Maximum 1024 characters
applicableEvents	The type of events the analytics rule evaluates.	Mandatory	Must be an array of objects. Each object is a condition an event must meet for the analytics rule to evaluate the event. Conditions define the Common Information Model (CIM) fields an event must contain for the analytics rule to evaluate the event. There is an or relationship between conditions; an event must meet at least one of, not all, the conditions for the analytics rule to evaluate the event. If an event doesn't meet any of the conditions, the analytics rule doesn't evaluate the event.
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 `name` field and adds detail specific to the specific event on which it triggered. It is displayed in Threat Center detections:	Mandatory	Must be a string Maximum 256 characters To customize the `detectionReason` to the event on which it triggered, insert dynamic variables for events, triggers, and entities: To insert a dynamic variable for an event, use the syntax `${event.field_name}`. To insert a dynamic variable for a trigger, use the syntax c`${trigger.fieldname}` To insert a dynamic variable for an entity, use the syntax `${entity.attribute_name}`
type	The analytics rule type.	Mandatory	Must be the string `"profiledFeature"`
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: Abnormal Authentication & Access Account Manipulation Audit Tampering Brute Force Attack Cloud Data Protection Compromised Credentials Cryptomining Data Access Data Exfiltration Data Leak Destruction of Data Evasion Lateral Movement Malware Phishing Physical Security Privilege Abuse Privilege Escalation Privileged Activity Ransomware Workforce Protection
mitre	The MITRE ATT&CK^® tactics and techniques associated with the analytics rule.	Optional	Must be an array of objects. Each object represents an ATT&CK technique and corresponding tactic. Each object must contain the following keys and their values: `techniqueKey` `technique` `tactic` `tacticKey` The value of `techniqueKey` must be an existing ATT&CK technique ID. It must correspond with the value of `technique`. The value of `technique` must be an existing ATT&CK technique name. It must correspond with the value of `techniqueKey`. The value of `tactic` must be an existing ATT&CK tactic name. It must correspond with the value of `tacticKey`. The value of `tacticKey` must be an existing ATT&CK tactic ID. It must correspond with the value of `tactic`.
scopeValue	The event field on which the model for the analytics rule trains; typically an object or entity.	Mandatory	Must be a string Must be different from the value of `featureValue` Use valid syntax to define your expression
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	Must be a string Must be different from the value of `scopeValue`
trainOnCondition	The events on which the analytics rule trains.	Mandatory	Must be a string String must be `"true"`; factFeature analytics rules must train on all events If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule trains. Ensure that you use valid syntax to define your expression.
actOnCondition	A high-level filter for the events on which the analytics rule triggers.	Mandatory	Must be a string If the analytics rule triggers on all events, string is `"true"` If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule triggers. Ensure that you use valid syntax to define your expression.
scoreUnless	A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger.	Optional	Must be an array of strings Each string must be an analytics rule `templateID`.
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	Must be a string; for example, `"90 days"` Must be a minimum of 1 day and maximum of 365 days
checkScopeMaturity	Whether the rule learns more about the field defined in `scopeValue` before triggering. Ensures the associated model has a good baseline for normal behavior.	Optional	Must be a boolean value If true, you must include `maturityThreshold`
checkFeatureMaturity	Whether the rule learns more about the field defined in `featureValue`. Ensures the associated model has a good baseline for what's normal.	Optional	Must be a boolean value If true, you must include `maturityThreshold`
maturityThreshold	The duration of the training period for `checkScopeMaturity` and `checkFeatureMaturity`.	Optional	Include only if the value of `checkScopeMaturity` and/or `checkFeatureMaturity` is true. Must be a string; for example, `"14 days"` Must be a minimum of 1 day and maximum of 28 days
familyId	The analytics rule family to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule family
ruleGroupId	The analytics rule group to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule group The analytics rule group must belong under the analytics rule family specified in the familyId field.
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 `severity` is not included in the rule configuration, the analytics rule is automatically assigned the Medium severity by default.	Optional	Must be a string String must be a valid severity level: None – Analytics rule is not used in risk scoring. Used for testing the analytics rule. Low – Reduces risk score. Medium – Doesn't adjust the risk score. High – Increases risk score. Critical – Significantly increases risk score and automatically creates a case.

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.

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	Must be a string Maximum 128 characters For custom analytics rules, we recommend that you prefix the ID with C_.
name	The analytics rule name.	Mandatory	Must be a string Maximum 256 characters
description	A description of the analytics rule.	Optional	Must be a string Maximum 1024 characters
applicableEvents	The type of events the analytics rule evaluates.	Mandatory	Must be an array of objects. Each object is a condition an event must meet for the analytics rule to evaluate the event. Conditions define the Common Information Model (CIM) fields an event must contain for the analytics rule to evaluate the event. There is an or relationship between conditions; an event must meet at least one of, not all, the conditions for the analytics rule to evaluate the event. If an event doesn't meet any of the conditions, the analytics rule doesn't evaluate the event.
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 `name` field and adds detail specific to the specific event on which it triggered. It is displayed in Threat Center detections:	Mandatory	Must be a string Maximum 256 characters To customize the `detectionReason` to the event on which it triggered, insert dynamic variables for events, triggers, and entities: To insert a dynamic variable for an event, use the syntax `${event.field_name}`. To insert a dynamic variable for a trigger, use the syntax c`${trigger.fieldname}` To insert a dynamic variable for an entity, use the syntax `${entity.attribute_name}`
type	The analytics rule type.	Mandatory	Must be the string `"contextFeature"`
mitre	The MITRE ATT&CK^® tactics and techniques associated with the analytics rule.	Optional	Must be an array of objects. Each object represents an ATT&CK technique and corresponding tactic. Each object must contain the following keys and their values: `techniqueKey` `technique` `tactic` `tacticKey` The value of `techniqueKey` must be an existing ATT&CK technique ID. It must correspond with the value of `technique`. The value of `technique` must be an existing ATT&CK technique name. It must correspond with the value of `techniqueKey`. The value of `tactic` must be an existing ATT&CK tactic name. It must correspond with the value of `tacticKey`. The value of `tacticKey` must be an existing ATT&CK tactic ID. It must correspond with the value of `tactic`.
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: Abnormal Authentication & Access Account Manipulation Audit Tampering Brute Force Attack Cloud Data Protection Compromised Credentials Cryptomining Data Access Data Exfiltration Data Leak Destruction of Data Evasion Lateral Movement Malware Phishing Physical Security Privilege Abuse Privilege Escalation Privileged Activity Ransomware Workforce Protection
trainOnCondition	The events on which the analytics rule trains.	Mandatory	Must be a string String must be `"true"`; factFeature analytics rules must train on all events If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule trains. Ensure that you use valid syntax to define your expression.
actOnCondition	A high-level filter for the events on which the analytics rule triggers.	Mandatory	Must be a string If the analytics rule triggers on all events, string is `"true"` If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule triggers. Ensure that you use valid syntax to define your expression.
value	The specific piece of context data the analytics rule identifies.	Optional	Must be a string String must be a valid expression that defines the context data the analytics rule identifies. Ensure that you use valid syntax to define your expression.
scopeValue	The event field on which the model for the analytics rule trains; typically an object or entity.	Mandatory	Must be a string Must refer to an existing entity attribute Use valid syntax to define your expression
scoreUnless	A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger.	Optional	Must be an array of strings Each string must be an analytics rule `templateID`.
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	Must be a string; for example, `"90 days"` Must be a minimum of 90 days and maximum of 120 days
checkScopeMaturity	Whether the rule learns more about the field defined in `scopeValue` before triggering. Ensures the associated model has a good baseline for normal behavior.	Optional	Must be a boolean value If true, you must include `maturityThreshold`
maturityThreshold	The duration of the training period for `checkScopeMaturity`.	Optional	Must be a string; for example, `"14 days"` Must be a minimum of 1 day and maximum of 28 days
query	A query that retrieves the specific events that triggered the analytics rule. In many cases, `query` retrieves the same events defined under `applicableEvents`. The events retrieved using `query` are shown in the Threat Center Threat Timeline, under View All Logs.	Mandatory	Must be a string Use valid syntax to define your expression.
familyId	The analytics rule family to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule family
ruleGroupId	The analytics rule group to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule group The analytics rule group must belong under the analytics rule family specified in the familyId field.
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 `severity` is not included in the rule configuration, the analytics rule is automatically assigned the Medium severity by default.	Optional	Must be a string String must be a valid severity level: None – Analytics rule is not used in risk scoring. Used for testing the analytics rule. Low – Reduces risk score. Medium – Doesn't adjust the risk score. High – Increases risk score. Critical – Significantly increases risk score and automatically creates a case.

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.

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	Must be a string Maximum 128 characters For custom analytics rules, we recommend that you prefix the ID with C_.
name	The analytics rule name.	Mandatory	Must be a string Maximum 256 characters
description	A description of the analytics rule.	Optional	Must be a string Maximum 1024 characters
applicableEvents	The type of events the analytics rule evaluates.	Mandatory	Must be an array of objects. Each object is a condition an event must meet for the analytics rule to evaluate the event. Conditions define the Common Information Model (CIM) fields an event must contain for the analytics rule to evaluate the event. There is an or relationship between conditions; an event must meet at least one of, not all, the conditions for the analytics rule to evaluate the event. If an event doesn't meet any of the conditions, the analytics rule doesn't evaluate the event.
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 `name` field and adds detail specific to the specific event on which it triggered. It is displayed in Threat Center detections:	Mandatory	Must be a string Maximum 256 characters To customize the `detectionReason` to the event on which it triggered, insert dynamic variables for events, triggers, and entities: To insert a dynamic variable for an event, use the syntax `${event.field_name}`. To insert a dynamic variable for a trigger, use the syntax c`${trigger.fieldname}` To insert a dynamic variable for an entity, use the syntax `${entity.attribute_name}`
type	The analytics rule type.	Mandatory	Must be the string `"numericCountProfiledFeature"`
mitre	The MITRE ATT&CK^® tactics and techniques associated with the analytics rule.	Optional	Must be an array of objects. Each object represents an ATT&CK technique and corresponding tactic. Each object must contain the following keys and their values: `techniqueKey` `technique` `tactic` `tacticKey` The value of `techniqueKey` must be an existing ATT&CK technique ID. It must correspond with the value of `technique`. The value of `technique` must be an existing ATT&CK technique name. It must correspond with the value of `techniqueKey`. The value of `tactic` must be an existing ATT&CK tactic name. It must correspond with the value of `tacticKey`. The value of `tacticKey` must be an existing ATT&CK tactic ID. It must correspond with the value of `tactic`.
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: Abnormal Authentication & Access Account Manipulation Audit Tampering Brute Force Attack Cloud Data Protection Compromised Credentials Cryptomining Data Access Data Exfiltration Data Leak Destruction of Data Evasion Lateral Movement Malware Phishing Physical Security Privilege Abuse Privilege Escalation Privileged Activity Ransomware Workforce Protection
scopeValue	The event field on which the model for the analytics rule trains; typically an object or entity.	Mandatory	Must be a string Must refer to an existing entity attribute Use valid syntax to define your expression
trainOnCondition	The events on which the analytics rule trains.	Mandatory	Must be a string String must be `"true"`; factFeature analytics rules must train on all events If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule trains. Ensure that you use valid syntax to define your expression.
actOnCondition	A high-level filter for the events on which the analytics rule triggers.	Mandatory	Must be a string If the analytics rule triggers on all events, string is `"true"` If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule triggers. Ensure that you use valid syntax to define your expression.
scoreUnless	A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger.	Optional	Must be an array of strings Each string must be an analytics rule `templateID`.
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	Must be a string; for example, `"90 days"` Must be a minimum of 1 day and maximum of 120 days
checkScopeMaturity	Whether the rule learns more about the field defined in `scopeValue` before triggering. Ensures the associated model has a good baseline for normal behavior.	Optional	Must be a boolean value If true, you must include `maturityThreshold`
maturityThreshold	The duration of the training period for `checkScopeMaturity`.	Optional	Must be a string; for example, `"14 days"` Must be a minimum of 1 day and maximum of 28 days
countPer	What of the `scopeValue` the analytics rule counts. For example, you can use `countPer` to specify that the analytics rule counts the number of logins to a specific endpoint per user. In this case, `countPer` is a specific endpoint and `scopeValue` is a user entity. You use `countPer` as an additional `scopeValue` and to add more complexity to what the analytics rule counts.	Optional	Must be a string String is an expression that defines what of the `scopeValue` the analytics rule counts. Expression must follow valid syntax.
windowDuration	The duration of the counting period.	Mandatory	Must be a string; for example, `"1 day"` Must must be a minimum of 1 day and maximum of 90 days
windowPeriod	How often the rule evaluates events during the period defined in `windowDuration`; for example, every 12 hours.	Mandatory	Must be a string; for example, `"12 hours"` Must be a minimum of 12 hours and maximum of 45 days
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. `logBase` defines the next time the analytics rule triggers in relation to a previous trigger. In this example, if the `logBase` is 2, then the analytics rule triggers when at least two, four, eight, 16, 32 and so forth emails are sent; if the `logBase` is 6, then the analytics rule triggers when at least six, 36, 216, and 1,296 and so forth emails are sent. With a higher `logBase` value, the count must be ever higher for the analytics rule to trigger, the analytics rule triggers less often, and there is less chance of false positives. With a lower `logBase` value, the analytics rule triggers more often but there is a higher chance of false positives.	Mandatory	Must be a double data type (double-precision floating-point)
minOrderOfMagnitude	The count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the `logBase` value. For example, let's say the analytics rule counts number of emails a user sends. If the `minOrderofMagnitude` is 3 and `logBase` is 2, the analytics rule doesn't trigger until the user sends eight or more emails.	Optional	Must be an integer Must be a minimum of 1 and maximum of 4
query	A query that retrieves the specific events that triggered the analytics rule. In many cases, `query` retrieves the same events defined under `applicableEvents`. The events retrieved using `query` are shown in the Threat Center Threat Timeline, under View All Logs.	Mandatory	Must be a string Use valid syntax to define your expression.
familyId	The analytics rule family to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule family
ruleGroupId	The analytics rule group to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule group The analytics rule group must belong under the analytics rule family specified in the familyId field.
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 `severity` is not included in the rule configuration, the analytics rule is automatically assigned the Medium severity by default.	Optional	Must be a string String must be a valid severity level: None – Analytics rule is not used in risk scoring. Used for testing the analytics rule. Low – Reduces risk score. Medium – Doesn't adjust the risk score. High – Increases risk score. Critical – Significantly increases risk score and automatically creates a case.

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.

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	Must be a string Maximum 128 characters For custom analytics rules, we recommend that you prefix the ID with C_.
name	The analytics rule name.	Mandatory	Must be a string Maximum 256 characters
description	A description of the analytics rule.	Optional	Must be a string Maximum 1024 characters
applicableEvents	The type of events the analytics rule evaluates.	Mandatory	Must be an array of objects. Each object is a condition an event must meet for the analytics rule to evaluate the event. Conditions define the Common Information Model (CIM) fields an event must contain for the analytics rule to evaluate the event. There is an or relationship between conditions; an event must meet at least one of, not all, the conditions for the analytics rule to evaluate the event. If an event doesn't meet any of the conditions, the analytics rule doesn't evaluate the event.
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 `name` field and adds detail specific to the specific event on which it triggered. It is displayed in Threat Center detections:	Mandatory	Must be a string Maximum 256 characters To customize the `detectionReason` to the event on which it triggered, insert dynamic variables for events, triggers, and entities: To insert a dynamic variable for an event, use the syntax `${event.field_name}`. To insert a dynamic variable for a trigger, use the syntax c`${trigger.fieldname}` To insert a dynamic variable for an entity, use the syntax `${entity.attribute_name}`
type	The analytics rule type.	Mandatory	Must be the string `"numericDistinctCountProfiledFeature"`
mitre	The MITRE ATT&CK^® tactics and techniques associated with the analytics rule.	Optional	Must be an array of objects. Each object represents an ATT&CK technique and corresponding tactic. Each object must contain the following keys and their values: `techniqueKey` `technique` `tactic` `tacticKey` The value of `techniqueKey` must be an existing ATT&CK technique ID. It must correspond with the value of `technique`. The value of `technique` must be an existing ATT&CK technique name. It must correspond with the value of `techniqueKey`. The value of `tactic` must be an existing ATT&CK tactic name. It must correspond with the value of `tacticKey`. The value of `tacticKey` must be an existing ATT&CK tactic ID. It must correspond with the value of `tactic`.
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: Abnormal Authentication & Access Account Manipulation Audit Tampering Brute Force Attack Cloud Data Protection Compromised Credentials Cryptomining Data Access Data Exfiltration Data Leak Destruction of Data Evasion Lateral Movement Malware Phishing Physical Security Privilege Abuse Privilege Escalation Privileged Activity Ransomware Workforce Protection
scopeValue	The event field on which the model for the analytics rule trains; typically an object or entity.	Mandatory	Must be a string Must be different from the value of `featureValue` Use valid syntax to define your expression
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	Must be a string Must be different from the value of `scopeValue`
trainOnCondition	The events on which the analytics rule trains.	Mandatory	Must be a string String must be `"true"`; factFeature analytics rules must train on all events If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule trains. Ensure that you use valid syntax to define your expression.
actOnCondition	A high-level filter for the events on which the analytics rule triggers.	Mandatory	Must be a string If the analytics rule triggers on all events, string is `"true"` If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule triggers. Ensure that you use valid syntax to define your expression.
scoreUnless	A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger.	Optional	Must be an array of strings Each string must be an analytics rule `templateID`.
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	Must be a string; for example, `"90 days"` Must be a minimum of 1 day and maximum of 120 days
checkScopeMaturity	Whether the rule learns more about the field defined in `scopeValue` before triggering. Ensures the associated model has a good baseline for normal behavior.	Optional	Must be a boolean value If true, you must include `maturityThreshold` `maturityThreshold` in the configuration
maturityThreshold	The duration of the training period for `checkScopeMaturity`.	Optional	Must be a string; for example, `"14 days"` Must be a minimum of 1 day and maximum of 28 days
countPer	What of the `scopeValue` the analytics rule counts. For example, you can use `countPer` to specify that the analytics rule counts the number of logins to a specific endpoint per user. In this case, `countPer` is a specific endpoint and `scopeValue` is a user entity. You use `countPer` as an additional `scopeValue` and to add more complexity to what the analytics rule counts.	Optional	Must be a string String is an expression that defines what of the `scopeValue` the analytics rule counts. Expression must follow valid syntax.
windowDuration	The duration of the counting period.	Mandatory	Must be a string; for example, `"1 day"` Must must be a minimum of 1 hour and maximum of 1 day
windowPeriod	How often the rule evaluates events during the period defined in `windowDuration`; for example, every 12 hours.	Mandatory	Must be a string; for example, `"12 hours"` Must be a minimum of 30 minutes and maximum of 12 hours
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. `logBase` defines the next time the analytics rule triggers in relation to a previous trigger. In this example, if the `logBase` is 2, then the analytics rule triggers when at least two, four, eight, 16, 32 and so forth emails are sent; if the `logBase` is 6, then the analytics rule triggers when at least six, 36, 216, and 1,296 and so forth emails are sent. With a higher `logBase` value, the count must be ever higher for the analytics rule to trigger, the analytics rule triggers less often, and there is less chance of false positives. With a lower `logBase` value, the analytics rule triggers more often but there is a higher chance of false positives.	Mandatory	Must be a double data type (double-precision floating-point)
minOrderOfMagnitude	The count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the `logBase` value. For example, let's say the analytics rule counts number of emails a user sends. If the `minOrderofMagnitude` is 3 and `logBase` is 2, the analytics rule doesn't trigger until the user sends eight or more emails.	Mandatory	Must be an integer Must be a minimum of 1 and maximum of 4
query	A query that retrieves the specific events that triggered the analytics rule. In many cases, `query` retrieves the same events defined under `applicableEvents`. The events retrieved using `query` are shown in the Threat Center Threat Timeline, under View All Logs.	Mandatory	Must be a string Use valid syntax to define your expression.
familyId	The analytics rule family to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule family
ruleGroupId	The analytics rule group to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule group The analytics rule group must belong under the analytics rule family specified in the familyId field.
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 `severity` is not included in the rule configuration, the analytics rule is automatically assigned the Medium severity by default.	Optional	Must be a string String must be a valid severity level: None – Analytics rule is not used in risk scoring. Used for testing the analytics rule. Low – Reduces risk score. Medium – Doesn't adjust the risk score. High – Increases risk score. Critical – Significantly increases risk score and automatically creates a case.

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.

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	Must be a string Maximum 128 characters For custom analytics rules, we recommend that you prefix the ID with C_.
name	The analytics rule name.	Mandatory	Must be a string Maximum 256 characters
description	A description of the analytics rule.	Optional	Must be a string Maximum 1024 characters
applicableEvents	The type of events the analytics rule evaluates.	Mandatory	Must be an array of objects. Each object is a condition an event must meet for the analytics rule to evaluate the event. Conditions define the Common Information Model (CIM) fields an event must contain for the analytics rule to evaluate the event. There is an or relationship between conditions; an event must meet at least one of, not all, the conditions for the analytics rule to evaluate the event. If an event doesn't meet any of the conditions, the analytics rule doesn't evaluate the event.
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 `name` field and adds detail specific to the specific event on which it triggered. It is displayed in Threat Center detections:	Mandatory	Must be a string Maximum 256 characters To customize the `detectionReason` to the event on which it triggered, insert dynamic variables for events, triggers, and entities: To insert a dynamic variable for an event, use the syntax `${event.field_name}`. To insert a dynamic variable for a trigger, use the syntax c`${trigger.fieldname}` To insert a dynamic variable for an entity, use the syntax `${entity.attribute_name}`
type	The analytics rule type.	Mandatory	Must be the string `"numericSumProfiledFeature"`
mitre	The MITRE ATT&CK^® tactics and techniques associated with the analytics rule.	Optional	Must be an array of objects. Each object represents an ATT&CK technique and corresponding tactic. Each object must contain the following keys and their values: `techniqueKey` `technique` `tactic` `tacticKey` The value of `techniqueKey` must be an existing ATT&CK technique ID. It must correspond with the value of `technique`. The value of `technique` must be an existing ATT&CK technique name. It must correspond with the value of `techniqueKey`. The value of `tactic` must be an existing ATT&CK tactic name. It must correspond with the value of `tacticKey`. The value of `tacticKey` must be an existing ATT&CK tactic ID. It must correspond with the value of `tactic`.
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: Abnormal Authentication & Access Account Manipulation Audit Tampering Brute Force Attack Cloud Data Protection Compromised Credentials Cryptomining Data Access Data Exfiltration Data Leak Destruction of Data Evasion Lateral Movement Malware Phishing Physical Security Privilege Abuse Privilege Escalation Privileged Activity Ransomware Workforce Protection
scopeValue	The event field on which the model for the analytics rule trains; typically an object or entity.	Mandatory	Must be a string Must be different from the value of `featureValue` Use valid syntax to define your expression
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	Must be a string Must be different from the value of `scopeValue`
trainOnCondition	The events on which the analytics rule trains.	Mandatory	Must be a string String must be `"true"`; factFeature analytics rules must train on all events If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule trains. Ensure that you use valid syntax to define your expression.
actOnCondition	A high-level filter for the events on which the analytics rule triggers.	Mandatory	Must be a string If the analytics rule triggers on all events, string is `"true"` If the analytics rule triggers on specific events, string is an expression that defines the events on which the analytics rule triggers. Ensure that you use valid syntax to define your expression.
scoreUnless	A list of analytics rules. If any analytics rule in the list triggers, the given analytics rule doesn't trigger.	Optional	Must be an array of strings Each string must be an analytics rule `templateID`.
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	Must be a string; for example, `"90 days"` Must be a minimum of 1 day and maximum of 120 days
checkScopeMaturity	Whether the rule learns more about the field defined in `scopeValue` before triggering. Ensures the associated model has a good baseline for normal behavior.	Optional	Must be a boolean value If true, you must include `maturityThreshold`
maturityThreshold	The duration of the training period for `checkScopeMaturity`.	Optional	Must be a string; for example, `"14 days"`
countPer	What of the `scopeValue` the analytics rule counts. For example, you can use `countPer` to specify that the analytics rule counts the number of logins to a specific endpoint per user. In this case, `countPer` is a specific endpoint and `scopeValue` is a user entity. You use `countPer` as an additional `scopeValue` and to add more complexity to what the analytics rule counts.	Optional	Must be a string String is an expression that defines what of the `scopeValue` the analytics rule counts. Expression must follow valid syntax.
windowDuration	The duration of the summing period.	Mandatory	Must be a string; for example, `"1 day"`
windowPeriod	How often the rule evaluates events during the period defined in `windowDuration`; for example, every 12 hours.	Mandatory	Must be a string; for example, `"12 hours"` Must be a minimum of 12 hours and maximum of 45 days
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. `logBase` defines the next time the analytics rule triggers in relation to a previous trigger. In this example, if the `logBase` is 2, then the analytics rule triggers when at least two, four, eight, 16, 32 and so forth emails are sent; if the `logBase` is 6, then the analytics rule triggers when at least six, 36, 216, and 1,296 and so forth emails are sent. With a higher `logBase` value, the count must be ever higher for the analytics rule to trigger, the analytics rule triggers less often, and there is less chance of false positives. With a lower `logBase` value, the analytics rule triggers more often but there is a higher chance of false positives.	Mandatory	Must be a double data type (double-precision floating-point)
minOrderOfMagnitude	The count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the `logBase` value. For example, let's say the analytics rule counts number of emails a user sends. If the `minOrderofMagnitude` is 3 and `logBase` is 2, the analytics rule doesn't trigger until the user sends eight or more emails.	Mandatory	Must be an integer Must be a minimum of 1 and maximum of 4
query	A query that retrieves the specific events that triggered the analytics rule. In many cases, `query` retrieves the same events defined under `applicableEvents`. The events retrieved using `query` are shown in the Threat Center Threat Timeline, under View All Logs.	Mandatory	Must be a string Use valid syntax to define your expression.
familyId	The analytics rule family to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule family
ruleGroupId	The analytics rule group to which the rule belongs.	Mandatory	Must be a string Must refer to the ID of an existing analytics rule group The analytics rule group must belong under the analytics rule family specified in the familyId field.
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 `severity` is not included in the rule configuration, the analytics rule is automatically assigned the Medium severity by default.	Optional	Must be a string String must be a valid severity level: None – Analytics rule is not used in risk scoring. Used for testing the analytics rule. Low – Reduces risk score. Medium – Doesn't adjust the risk score. High – Increases risk score. Critical – Significantly increases risk score and automatically creates a case.

Threat Detection ManagementThreat Detection Management Guide

Table of ContentsTable of Contents