Skip to main content

Responses are generated using AI and may contain mistakes.

Threat Detection ManagementThreat Detection Management Guide

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:

2. Import the analytics rule

After you create the analytics rule JSON file, import it into Threat Detection Management.

  1. On the Analytics Rules tab, click Import analytics rules A partial rounded blue square from which emerges an arrow curving downwards and to the left, both of which are set inside a blue square..

  2. 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.

  3. 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:

  1. Select the analytics rules you're enabling:

    • To select all analytics rules, click the checkbox in the header row.

      All listed analytics rule selected.
    • To select specific analytics rules, click the checkbox for each analytics rule.

      Three analytics rules selected.
  2. Click Enable:

    The enable action when you select multiple analytics rules highlighted in a red rectangle.

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.

  1. Under Engine Status, click View Changes.

    The Engine Status showing pending analytics rule changes waiting to be processed.
  2. 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 A blue eye.. To delete the change, click A blue trash can..

    To find specific rules, filter the rules by Update or Change columns.

  3. Select the rules to which you're applying pending changes:

    • To select all rules, click the checkbox in the header row.

      threatdetectionmanagement-updates-viewandupdate-selectall.png
    • To select specific rules, click the checkbox for each rule.

      threatdetectionmanagement-updates-viewandupdate-selectspecificrules.png
  4. 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.

  5. 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:

The detection reason for a Threat Center analytics rule detection.

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.

Optional

  • Must be a string

  • If the analytics rule trains 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 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.

Optional

  • 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.

Mandatory

  • 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.

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

  • 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:

The detection reason for a Threat Center analytics rule detection.

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

  • If the analytics rule trains 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 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.

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

  • 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:

The detection reason for a Threat Center analytics rule detection.

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.

Optional

  • Must be a string

  • If the analytics rule trains 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 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.

Optional

  • 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.

Mandatory

  • 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

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.

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

  • 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:

The detection reason for a Threat Center analytics rule detection.

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

  • If the analytics rule trains 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 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

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.

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

  • 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:

The detection reason for a Threat Center analytics rule detection.

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

  • If the analytics rule trains 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 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

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.

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

  • 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:

The detection reason for a Threat Center analytics rule detection.

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

  • If the analytics rule trains 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 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

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.