Skip to main content

Responses are generated using AI and may contain mistakes.

Threat Detection ManagementThreat Detection Management Guide

Create Analytics Rules Using a Builder

Create an analytics rule using a point-and-click builder directly in Threat Detection Management.

The builder guides you through the process of defining the detection logic, training logic, and other metadata required for the analytics rule to function.

You can also create an analytics rule by defining its configuration in a JSON file, then importing the JSON file into Threat Detection Management.

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.

Create a factFeature Analytics Rule Using a Builder

To detect well-defined risk signatures or security violations, create a factFeature analytics rule using a point-and-click interface.

You can also create a factFeature analytics rule by defining its configuration in a JSON file, then importing the JSON file into Threat Detection Management.

1. Enter basic information

  1. In the Analytics Rule tab, click + New Rule.

  2. Enter information about the analytics rule:

    • Under Rule Name, enter a name for the analytics rule.

    • Under Select rule type, select Fact.

  3. Click Save.

2. Define applicable events

Define the types of events the analytics rule evaluates by CIM fields. An event must contain at least one of the CIM fields 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.

  1. Under Select Field, select a CIM field.

  2. Under Value, enter a value for the CIM field. A CIM field in an event must contain this value for the analytics rule to evaluate the event.

  3. To define another CIM field an event must contain for the analytics rule to evaluate the event, click + Add.

  4. When you've defined all applicable events, click Save.

3. Define detection logic

Define the fields that determine which behaviors the analytics rule trains on and observes for anomalies:

  • Value – Enter an expression used to evaluate whether the conditions required for the rule to trigger are true. If all conditions are met when the analytics rule triggers, then expression is "true". For most analytics rules, the value of value is "true". To differentiate between triggers, enter an expression using valid syntax that defines the specific conditions required for the rule to trigger.

  • Suppress Scope – Enter 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.

    Ensure that you use valid syntax to define your expression.

  • Suppress Length – Enter how long the analytics rule is suppressed after it's first triggered. For example, if you set suppress length to two minutes, if the analytics rule triggers once, then triggers again within two minutes, the second trigger is suppressed.

    Must be a minimum of 1 minute and maximum of 10 minutes

When you have defined all detection logic parameters, click Save.

4. Define historical learning and training patterns

Define the fields that determine how the analytics rule triggers and trains on data:

  • Train on condition – Defines the events on which the analytics rule trains.

    • If the analytics rule trains on all events, select Always.

    • If the analytics rule trains on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule trains.

  • Act on condition – A high-level filter for the events on which the analytics rule triggers.

    • If the analytics rule triggers on all events, select Always.

    • If the analytics rule triggers on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule triggers.

When you have defined all historical learning and training parameters, click Next.

5. Review analytics rule configuration

Review the applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule. To edit any of these configurations, click A blue pencil overlaps the top-left corner of a blue square outline..

6. Finalize analytics rule details

  1. Enter information about the analytics rule:

    • Rule Description – Enter a description of the analytics rule.

    • Contextual Rule Definition – Enter a dynamic name describing the rule and why it triggered on a specific event. It elaborates on the analytics rule name 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.

      To customize the contextual rule definition to the event on which it triggered, insert dynamic variables for events, triggers, and entities:

      • To insert a dynamic variable for an event, click A blue plus sign centered on a white square with a faint shadow., navigate to the Event fields tab, then select an event field.

      • To insert a dynamic variable for data that causes a rule to trigger, click A blue plus sign centered on a white square with a faint shadow., navigate to the Trigger tab, then select a rule configuration field.

      • To insert a dynamic variable for an entity, click A blue plus sign centered on a white square with a faint shadow., navigate to the Entities tab, then select an entity attribute.

    • Rule Family – Select the analytics rule family to which the rule belongs.

    • Rule Group – Select the analytics rule group to which the rule belongs.

    • Template Id – Enter a unique identifier for the analytics rule. By default, <analytics rule type>-<rule name> is entered. After the analytics rule is created, C_ is automatically appended to the beginning of the template ID you enter.

    • Use Cases – Enter the Exabeam use case associated with the analytics rule.

    • MITRE TTPs – Enter the MITRE ATT&CK® tactics and techniques associated with the analytics rule.

  2. Under Summary, review the rule name, rule type, applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule.

  3. Click Save. The analytics rule is created in disabled status and automatically assigned the Medium severity by default. You can assign the analytics rule a different severity.

7. Enable the analytics rule

When you create an analytics rule, it is created in disabled status. To allow them to trigger in your environment, you must enable it. For the change to take effect, ensure you apply the change to your environment.

You can further tune the analytics rule using exclusions.

Create a profiledFeature Analytics Rule Using a Builder

To detect when a user does an action they haven't done before for the first time, create a profiledFeature analytics rule using a point-and-click interface.

You can also create a profiledFeature analytics rule by defining its configuration in a JSON file, then importing the JSON file into Threat Detection Management.

1. Enter basic information

  1. In the Analytics Rule tab, click + New Rule.

  2. Enter information about the analytics rule:

    • Under Rule Name, enter a name for the analytics rule.

    • Under Select rule type, select Profiled.

  3. Click Save.

2. Define applicable events

Define the types of events the analytics rule evaluates by CIM fields. An event must contain at least one of the CIM fields 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.

  1. Under Select Field, select a CIM field.

  2. Under Value, enter a value for the CIM field. A CIM field in an event must contain this value for the analytics rule to evaluate the event.

  3. To define another CIM field an event must contain for the analytics rule to evaluate the event, click + Add.

  4. When you've defined all applicable events, click Save.

3. Define detection logic

Define the fields that determine which behaviors the analytics rule trains on and observes for anomalies:

  • Scope – Enter the event field on which the model for the analytics rule trains; typically an object or entity. The value of scope must be different from the value of feature. Ensure that you use valid syntax to define your expression.

  • Feature – Enter the event field on which the model for the analytics rule trains for the scope. For example, if scope is hostname and feature is process, the model trains on the behavior of processes executed on hostnames. The value of feature must be different from the value of scope. Ensure that you use valid syntax to define your expression.

  • Anomaly threshold – Enter the number of days 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.

    Must be a minimum of 1 day and maximum of 365 days

When you have defined all detection logic parameters, click Save.

4. Define historical learning and training patterns

Define the fields that determine how the analytics rule triggers and trains on data:

  • Train on condition – Defines the events on which the analytics rule trains.

    • If the analytics rule trains on all events, select Always.

    • If the analytics rule trains on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule trains.

  • Act on condition – A high-level filter for the events on which the analytics rule triggers.

    • If the analytics rule triggers on all events, select Always.

    • If the analytics rule triggers on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule triggers.

  • Check data maturity – Defines whether the rule learns more before triggering. Ensures the associated model has a good baseline for what's normal.

    • If the analytics rule should learn more about the scope field before triggering, select Scope maturity.

    • If the analytics rule should learn more about the feature field before triggering, select Feature maturity.

When you have defined all historical learning and training parameters, click Next.

5. Review analytics rule configuration

Review the applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule. To edit any of these configurations, click A blue pencil overlaps the top-left corner of a blue square outline..

6. Finalize analytics rule details

  1. Enter information about the analytics rule:

    • Rule Description – Enter a description of the analytics rule.

    • Contextual Rule Definition – Enter a dynamic name describing the rule and why it triggered on a specific event. It elaborates on the analytics rule name 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.

      To customize the contextual rule definition to the event on which it triggered, insert dynamic variables for events, triggers, and entities:

      • To insert a dynamic variable for an event, click A blue plus sign centered on a white square with a faint shadow., navigate to the Event fields tab, then select an event field.

      • To insert a dynamic variable for data that causes a rule to trigger, click A blue plus sign centered on a white square with a faint shadow., navigate to the Trigger tab, then select a rule configuration field.

      • To insert a dynamic variable for an entity, click A blue plus sign centered on a white square with a faint shadow., navigate to the Entities tab, then select an entity attribute.

    • Rule Family – Select the analytics rule family to which the rule belongs.

    • Rule Group – Select the analytics rule group to which the rule belongs.

    • Template Id – Enter a unique identifier for the analytics rule. By default, <analytics rule type>-<rule name> is entered. After the analytics rule is created, C_ is automatically appended to the beginning of the template ID you enter.

    • Use Cases – Enter the Exabeam use case associated with the analytics rule.

    • MITRE TTPs – Enter the MITRE ATT&CK® tactics and techniques associated with the analytics rule.

  2. Under Summary, review the rule name, rule type, applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule.

  3. Click Save. The analytics rule is created in disabled status and automatically assigned the Medium severity by default. You can assign the analytics rule a different severity.

7. Enable the analytics rule

When you create an analytics rule, it is created in disabled status. To allow them to trigger in your environment, you must enable it. For the change to take effect, ensure you apply the change to your environment.

The change is added to a batch of pending updates. You must now apply the change to your environment for the change to take effect.

Create a contextFeature Analytics Rule Using a Builder

To identify a single piece of context data describing an important characteristic in events, create a contextFeature analytics rule using a point-and-click interface.

You can also create a contextFeature analytics rule by defining its configuration in a JSON file, then importing the JSON file into Threat Detection Management.

1. Enter basic information

  1. In the Analytics Rule tab, click + New Rule.

  2. Enter information about the analytics rule:

    • Under Rule Name, enter a name for the analytics rule.

    • Under Select rule type, select Context.

  3. Click Save.

2. Define applicable events

Define the types of events the analytics rule evaluates by CIM fields. An event must contain at least one of the CIM fields 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.

  1. Under Select Field, select a CIM field.

  2. Under Value, enter a value for the CIM field. A CIM field in an event must contain this value for the analytics rule to evaluate the event.

  3. To define another CIM field an event must contain for the analytics rule to evaluate the event, click + Add.

  4. When you've defined all applicable events, click Save.

3. Define detection logic

Define the fields that determine which behaviors the analytics rule trains on and observes for anomalies:

  • Value – Enter the specific piece of context data the analytics rule identifies. Ensure that you use valid syntax to define your expression.

  • Suppress Scope – Enter 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.

    Ensure that you use valid syntax to define your expression.

  • Suppress Length – Enter how long the analytics rule is suppressed after it's first triggered. For example, if you set suppress length to two minutes, if the analytics rule triggers once, then triggers again within two minutes, the second trigger is suppressed.

When you've defined all detection logic parameters, click Save.

4. Review analytics rule configuration

Review the applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule. To edit any of these configurations, click A blue pencil overlaps the top-left corner of a blue square outline..

5. Finalize analytics rule details

  1. Enter information about the analytics rule:

    • Rule Description – Enter a description of the analytics rule.

    • Contextual Rule Definition – Enter a dynamic name describing the rule and why it triggered on a specific event. It elaborates on the analytics rule name 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.

      To customize the contextual rule definition to the event on which it triggered, insert dynamic variables for events, triggers, and entities:

      • To insert a dynamic variable for an event, click A blue plus sign centered on a white square with a faint shadow., navigate to the Event fields tab, then select an event field.

      • To insert a dynamic variable for data that causes a rule to trigger, click A blue plus sign centered on a white square with a faint shadow., navigate to the Trigger tab, then select a rule configuration field.

      • To insert a dynamic variable for an entity, click A blue plus sign centered on a white square with a faint shadow., navigate to the Entities tab, then select an entity attribute.

    • Rule Family – Select the analytics rule family to which the rule belongs.

    • Rule Group – Select the analytics rule group to which the rule belongs.

    • Template Id – Enter a unique identifier for the analytics rule. By default, <analytics rule type>-<rule name> is entered. After the analytics rule is created, C_ is automatically appended to the beginning of the template ID you enter.

    • Use Cases – Enter the Exabeam use case associated with the analytics rule.

    • MITRE TTPs – Enter the MITRE ATT&CK® tactics and techniques associated with the analytics rule.

  2. Under Summary, review the rule name, rule type, applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule.

  3. Click Save. The analytics rule is created in disabled status and automatically assigned the Medium severity by default. You can assign the analytics rule a different severity.

6. Enable the analytics rule

When you create an analytics rule, it is created in disabled status. To allow them to trigger in your environment, you must enable it. For the change to take effect, ensure you apply the change to your environment.

You can further tune the analytics rule using exclusions.

Create a numericCountProfiledFeature Analytics Rule Using a Builder

To detect anomalies in how frequently a behavior happens over a given period, create a numericCountProfiledFeature analytics rule using a point-and-click interface.

You can also create a numericCountProfiledFeature analytics rule by defining its configuration in a JSON file, then importing the JSON file into Threat Detection Management.

1. Enter basic information

  1. In the Analytics Rule tab, click + New Rule.

  2. Enter information about the analytics rule:

    • Under Rule Name, enter a name for the analytics rule.

    • Under Select rule type, select Profiled Numeric Count.

  3. Click Save.

2. Define applicable events

Define the types of events the analytics rule evaluates by CIM fields. An event must contain at least one of the CIM fields 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.

  1. Under Select Field, select a CIM field.

  2. Under Value, enter a value for the CIM field. A CIM field in an event must contain this value for the analytics rule to evaluate the event.

  3. To define another CIM field an event must contain for the analytics rule to evaluate the event, click + Add.

  4. When you've defined all applicable events, click Save.

3. Define detection logic

Define the fields that determine which behaviors the analytics rule trains on and observes for anomalies:

  • Scope – Enter the event field on which the model for the analytics rule trains; typically an object or entity. The value of scope must be different from the value of feature. Ensure that you use valid syntax to define your expression.

  • Count per – Enter an expression that defines what of the scope the analytics rule counts. For example, if count per is a specific endpoint and scope is a user entity, you can use the analytics rule to count the number of logins to a specific endpoint per user. Ensure that you use valid syntax to define your expression.

  • Anomaly threshold – Enter the number of days 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.

    Must be a minimum of 1 day and maximum of 120 days

  • (Optional) Score Unless – If any analytics rule you select in the list triggers, the given analytics rule doesn't trigger.

When you have defined all detection logic parameters, click Save.

4. Define historical learning and training patterns

Define the fields that determine how the analytics rule triggers and trains on data:

  • Query – Enter a query using valid syntax that retrieves the specific events that triggered the analytics rule. In many cases, query retrieves the same events defined as applicable events.

    The events retrieved using query are shown in the Threat Center Threat Timeline, under View All Logs.

  • Train on condition – Defines the events on which the analytics rule trains.

    • If the analytics rule trains on all events, select Always.

    • If the analytics rule trains on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule trains.

  • Act on condition – A high-level filter for the events on which the analytics rule triggers.

    • If the analytics rule triggers on all events, select Always.

    • If the analytics rule triggers on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule triggers.

  • Check data maturity – Defines whether the rule learns more before triggering. Ensures the associated model has a good baseline for what's normal.

    • If the analytics rule should learn more about the scope field before triggering, select Scope maturity.

  • Advanced Settings – Fine-tune how the analytics rule evaluates events and the mathematical thresholds that determine when behavior counts transition from normal to anomalous.

    • Window duration – Enter the duration of the counting period.

      Must must be a minimum of 1 day and maximum of 90 days

    • Window period – Enter how often the rule evaluates events during the period defined in window duration; for example, every 12 hours.

      Must be a minimum of 12 hours and maximum of 45 days

    • Minimum order of magnitude – Enter the count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the log base value.

      For example, let's say the analytics rule counts number of emails a user sends. If the minimum order of magnitude is 3 and log base is 2, the analytics rule doesn't trigger until the user sends eight or more emails.

      Must be a minimum of 1 and maximum of 4

    • Log base – Enter 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. Log base defines the next time the analytics rule triggers in relation to a previous trigger. In this example, if the log base is 2, then the analytics rule triggers when at least two, four, eight, 16, 32 and so forth emails are sent; if the log base 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 log base 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 log base value, the analytics rule triggers more often but there is a higher chance of false positives.

      Must be a minimum of 2 and maximum of 10.

When you have defined all historical learning and training parameters, click Next.

5. Review analytics rule configuration

Review the applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule. To edit any of these configurations, click A blue pencil overlaps the top-left corner of a blue square outline..

6. Finalize analytics rule details

  1. Enter information about the analytics rule:

    • Rule Description – Enter a description of the analytics rule.

    • Contextual Rule Definition – Enter a dynamic name describing the rule and why it triggered on a specific event. It elaborates on the analytics rule name 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.

      To customize the contextual rule definition to the event on which it triggered, insert dynamic variables for events, triggers, and entities:

      • To insert a dynamic variable for an event, click A blue plus sign centered on a white square with a faint shadow., navigate to the Event fields tab, then select an event field.

      • To insert a dynamic variable for data that causes a rule to trigger, click A blue plus sign centered on a white square with a faint shadow., navigate to the Trigger tab, then select a rule configuration field.

      • To insert a dynamic variable for an entity, click A blue plus sign centered on a white square with a faint shadow., navigate to the Entities tab, then select an entity attribute.

    • Rule Family – Select the analytics rule family to which the rule belongs.

    • Rule Group – Select the analytics rule group to which the rule belongs.

    • Template Id – Enter a unique identifier for the analytics rule. By default, <analytics rule type>-<rule name> is entered. After the analytics rule is created, C_ is automatically appended to the beginning of the template ID you enter.

    • Use Cases – Enter the Exabeam use case associated with the analytics rule.

    • MITRE TTPs – Enter the MITRE ATT&CK® tactics and techniques associated with the analytics rule.

  2. Under Summary, review the rule name, rule type, applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule.

  3. Click Save. The analytics rule is created in disabled status and automatically assigned the Medium severity by default. You can assign the analytics rule a different severity.

7. Enable the analytics rule

When you create an analytics rule, it is created in disabled status. To allow them to trigger in your environment, you must enable it. For the change to take effect, ensure you apply the change to your environment.

You can further tune the analytics rule using exclusions.

Create a numericDistinctCountProfiledFeature Analytics Rule Using a Builder

To detect anomalies in the total number of times a behavior happens, create a numericDistinctCountProfiledFeature analytics rule using a point-and-click interface.

You can also create a numericDistinctCountProfiledFeature analytics rule by defining its configuration in a JSON file, then importing the JSON file into Threat Detection Management.

1. Enter basic information

  1. In the Analytics Rule tab, click + New Rule.

  2. Enter information about the analytics rule:

    • Under Rule Name, enter a name for the analytics rule.

    • Under Select rule type, select Profiled Numeric Distinct Count.

  3. Click Save.

2. Define applicable events

Define the types of events the analytics rule evaluates by CIM fields. An event must contain at least one of the CIM fields 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.

  1. Under Select Field, select a CIM field.

  2. Under Value, enter a value for the CIM field. A CIM field in an event must contain this value for the analytics rule to evaluate the event.

  3. To define another CIM field an event must contain for the analytics rule to evaluate the event, click + Add.

  4. When you've defined all applicable events, click Save.

3. Define detection logic

Define the fields that determine which behaviors the analytics rule trains on and observes for anomalies:

  • Scope – Enter the event field on which the model for the analytics rule trains; typically an object or entity. The value of scope must be different from the value of feature. Ensure that you use valid syntax to define your expression.

  • Feature – Enter the event field on which the model for the analytics rule trains for the scope. For example, if scope is hostname and feature is process, the model trains on the behavior of processes executed on hostnames. The value of feature must be different from the value of scope. Ensure that you use valid syntax to define your expression.

  • Count per – Enter an expression that defines what of the scope the analytics rule counts. For example, if count per is a specific endpoint and scope is a user entity, you can use the analytics rule to count the number of logins to a specific endpoint per user. Ensure that you use valid syntax to define your expression.

  • Anomaly threshold – Enter the number of days 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.

    Must be a minimum of 1 day and maximum of 120 days

  • (Optional) Score Unless – If any analytics rule you select in the list triggers, the given analytics rule doesn't trigger.

When you have defined all detection logic parameters, click Save.

4. Define historical learning and training patterns

Define the fields that determine how the analytics rule triggers and trains on data:

  • Query – Enter a query using valid syntax that retrieves the specific events that triggered the analytics rule. In many cases, query retrieves the same events defined as applicable events.

    The events retrieved using query are shown in the Threat Center Threat Timeline, under View All Logs.

  • Train on condition – Defines the events on which the analytics rule trains.

    • If the analytics rule trains on all events, select Always.

    • If the analytics rule trains on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule trains.

  • Act on condition – A high-level filter for the events on which the analytics rule triggers.

    • If the analytics rule triggers on all events, select Always.

    • If the analytics rule triggers on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule triggers.

  • Check data maturity – Defines whether the rule learns more before triggering. Ensures the associated model has a good baseline for what's normal.

    • If the analytics rule should learn more about the scope field before triggering, select Scope maturity.

    • If the analytics rule should learn more about the feature field before triggering, select Feature maturity.

  • Advanced Settings – Fine-tune how the analytics rule evaluates events and the mathematical thresholds that determine when behavior counts transition from normal to anomalous.

    • Window duration – Enter the duration of the counting period.

      Must must be a minimum of 1 hour and maximum of 1 day

    • Window period – Enter how often the rule evaluates events during the period defined in window duration; for example, every 12 hours.

      Must be a minimum of 30 minutes and maximum of 12 hours

    • Minimum order of magnitude – Enter the count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the log base value.

      For example, let's say the analytics rule counts number of emails a user sends. If the minimum order of magnitude is 3 and log base is 2, the analytics rule doesn't trigger until the user sends eight or more emails.

      Must be a minimum of 1 and maximum of 4

    • Log base – Enter 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. Log base defines the next time the analytics rule triggers in relation to a previous trigger. In this example, if the log base is 2, then the analytics rule triggers when at least two, four, eight, 16, 32 and so forth emails are sent; if the log base 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 log base 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 log base value, the analytics rule triggers more often but there is a higher chance of false positives.

      Must be a minimum of 2 and maximum of 10.

When you have defined all historical learning and training parameters, click Next.

5. Review analytics rule configuration

Review the applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule. To edit any of these configurations, click A blue pencil overlaps the top-left corner of a blue square outline..

6. Finalize analytics rule details

  1. Enter information about the analytics rule:

    • Rule Description – Enter a description of the analytics rule.

    • Contextual Rule Definition – Enter a dynamic name describing the rule and why it triggered on a specific event. It elaborates on the analytics rule name 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.

      To customize the contextual rule definition to the event on which it triggered, insert dynamic variables for events, triggers, and entities:

      • To insert a dynamic variable for an event, click A blue plus sign centered on a white square with a faint shadow., navigate to the Event fields tab, then select an event field.

      • To insert a dynamic variable for data that causes a rule to trigger, click A blue plus sign centered on a white square with a faint shadow., navigate to the Trigger tab, then select a rule configuration field.

      • To insert a dynamic variable for an entity, click A blue plus sign centered on a white square with a faint shadow., navigate to the Entities tab, then select an entity attribute.

    • Rule Family – Select the analytics rule family to which the rule belongs.

    • Rule Group – Select the analytics rule group to which the rule belongs.

    • Template Id – Enter a unique identifier for the analytics rule. By default, <analytics rule type>-<rule name> is entered. After the analytics rule is created, C_ is automatically appended to the beginning of the template ID you enter.

    • Use Cases – Enter the Exabeam use case associated with the analytics rule.

    • MITRE TTPs – Enter the MITRE ATT&CK® tactics and techniques associated with the analytics rule.

  2. Under Summary, review the rule name, rule type, applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule.

  3. Click Save. The analytics rule is created in disabled status and automatically assigned the Medium severity by default. You can assign the analytics rule a different severity.

7. Enable the analytics rule

When you create an analytics rule, it is created in disabled status. To allow them to trigger in your environment, you must enable it. For the change to take effect, ensure you apply the change to your environment.

You can further tune the analytics rule using exclusions.

Create a numericSumProfiledFeature Analytics Rule Using a Builder

To track the rate of a specific event or activity over time, create a numericSumProfiledFeature analytics rule using a point-and-click interface.

You can also create a numericSumProfiledFeature analytics rule by defining its configuration in a JSON file, then importing the JSON file into Threat Detection Management.

1. Enter basic information

  1. In the Analytics Rule tab, click + New Rule.

  2. Enter information about the analytics rule:

    • Under Rule Name, enter a name for the analytics rule.

    • Under Select rule type, select Profiled Numeric Sum.

  3. Click Save.

2. Define applicable events

Define the types of events the analytics rule evaluates by CIM fields. An event must contain at least one of the CIM fields 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.

  1. Under Select Field, select a CIM field.

  2. Under Value, enter a value for the CIM field. A CIM field in an event must contain this value for the analytics rule to evaluate the event.

  3. To define another CIM field an event must contain for the analytics rule to evaluate the event, click + Add.

  4. When you've defined all applicable events, click Save.

3. Define detection logic

Define the fields that determine which behaviors the analytics rule trains on and observes for anomalies:

  • Scope – Enter the event field on which the model for the analytics rule trains; typically an object or entity. The value of scope must be different from the value of feature. Ensure that you use valid syntax to define your expression.

  • Feature – Enter the event field on which the model for the analytics rule trains for the scope. For example, if scope is hostname and feature is process, the model trains on the behavior of processes executed on hostnames. The value of feature must be different from the value of scope. Ensure that you use valid syntax to define your expression.

  • Count per – Enter an expression that defines what of the scope the analytics rule counts. For example, if count per is a specific endpoint and scope is a user entity, you can use the analytics rule to count the number of logins to a specific endpoint per user. Ensure that you use valid syntax to define your expression.

  • Anomaly threshold – Enter the number of days 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.

    Must be a minimum of 1 day and maximum of 120 days

  • (Optional) Score Unless – If any analytics rule you select in the list triggers, the given analytics rule doesn't trigger.

When you've defined all detection logic parameters, click Save.

4. Define historical learning and training patterns

Define the fields that determine how the analytics rule triggers and trains on data:

  • Query – Enter a query using valid syntax that retrieves the specific events that triggered the analytics rule. In many cases, query retrieves the same events defined as applicable events.

    The events retrieved using query are shown in the Threat Center Threat Timeline, under View All Logs.

  • Train on condition – Defines the events on which the analytics rule trains.

    • If the analytics rule trains on all events, select Always.

    • If the analytics rule trains on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule trains.

  • Act on condition – A high-level filter for the events on which the analytics rule triggers.

    • If the analytics rule triggers on all events, select Always.

    • If the analytics rule triggers on specific events, select Logical expression, then in Type your Condition here, enter an expression using valid syntax that defines the events on which the analytics rule triggers.

  • Check data maturity – Defines whether the rule learns more before triggering. Ensures the associated model has a good baseline for what's normal.

    • If the analytics rule should learn more about the scope field before triggering, select Scope maturity.

  • Advanced Settings – Fine-tune how the analytics rule evaluates events and the mathematical thresholds that determine when behavior counts transition from normal to anomalous.

    • Window duration – Enter the duration of the summing period.

    • Window period – Enter how often the rule evaluates events during the period defined in window duration; for example, every 12 hours.

      Must be a minimum of 12 hours and maximum of 45 days

    • Minimum order of magnitude – Enter the count of a given behavior up to which the analytics rule considers normal and never triggers, as a factor of the log base value.

      For example, let's say the analytics rule counts number of emails a user sends. If the minimum order of magnitude is 3 and log base is 2, the analytics rule doesn't trigger until the user sends eight or more emails.

      Must be a minimum of 1 and maximum of 4

    • Log base – Enter 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. Log base defines the next time the analytics rule triggers in relation to a previous trigger. In this example, if the log base is 2, then the analytics rule triggers when at least two, four, eight, 16, 32 and so forth emails are sent; if the log base 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 log base 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 log base value, the analytics rule triggers more often but there is a higher chance of false positives.

      Must be a minimum of 2 and maximum of 10.

When you have defined all historical learning and training parameters, click Next.

5. Review analytics rule configuration

Review the applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule. To edit any of these configurations, click A blue pencil overlaps the top-left corner of a blue square outline..

6. Finalize analytics rule details

  1. Enter information about the analytics rule:

    • Rule Description – Enter a description of the analytics rule.

    • Contextual Rule Definition – Enter a dynamic name describing the rule and why it triggered on a specific event. It elaborates on the analytics rule name 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.

      To customize the contextual rule definition to the event on which it triggered, insert dynamic variables for events, triggers, and entities:

      • To insert a dynamic variable for an event, click A blue plus sign centered on a white square with a faint shadow., navigate to the Event fields tab, then select an event field.

      • To insert a dynamic variable for data that causes a rule to trigger, click A blue plus sign centered on a white square with a faint shadow., navigate to the Trigger tab, then select a rule configuration field.

      • To insert a dynamic variable for an entity, click A blue plus sign centered on a white square with a faint shadow., navigate to the Entities tab, then select an entity attribute.

    • Rule Family – Select the analytics rule family to which the rule belongs.

    • Rule Group – Select the analytics rule group to which the rule belongs.

    • Template Id – Enter a unique identifier for the analytics rule. By default, <analytics rule type>-<rule name> is entered. After the analytics rule is created, C_ is automatically appended to the beginning of the template ID you enter.

    • Use Cases – Enter the Exabeam use case associated with the analytics rule.

    • MITRE TTPs – Enter the MITRE ATT&CK® tactics and techniques associated with the analytics rule.

  2. Under Summary, review the rule name, rule type, applicable events, detection logic and conditions, and historical learning and training patterns you defined for the analytics rule.

  3. Click Save. The analytics rule is created in disabled status and automatically assigned the Medium severity by default. You can assign the analytics rule a different severity.

7. Enable the analytics rule

When you create an analytics rule, it is created in disabled status. To allow them to trigger in your environment, you must enable it. For the change to take effect, ensure you apply the change to your environment.

You can further tune the analytics rule using exclusions.