USM Anywhere™

Orchestration Rules Best Practices

USM Anywhere enables you to create and customize your own orchestration rules to add specific policies for a particular event Any traffic or data exchange detected by AT&T Cybersecurity products through a sensor, or through external devices such as a firewall. or alarm Alarms provide notification of an event or sequence of events that require attention or investigation.. A rule is made of these three items:

Note: All rules should have at least two match criteria for efficient processing.

Recommendations for Creating an Orchestration Rule

Use these recommendations when creating an orchestration rule:

  • If packet_type == log is used in the rule, the second rule match criteria must be the data source plugin name (plugin == ‘plugin_name’) used to normalize the event details. This enhances rules processing efficiency. If possible, the third match criteria should be the event name (event_name == ‘<event_name>’) .

  • Avoid using the case-insensitive version of rule match operators. Some rule fields do not accept this as a valid operator and will return a rule status warning when your rule is created.

Note: Correlation lists are not valid for use with filtering rules.

  • Rules operate by using Boolean logic, and are processed from left to right of the formulated rule data. Use the most restrictive match criteria up front to minimize rules processing for failed matches. If your rule includes the packet_type and plugin_device fields, these should always occur first in the orchestration rule.
  • Minimize the number of match criteria used for simplicity.
  • Consolidate rules into a smaller number of rules.
  • In order of precedence, the equals (==) operator is better than the contains operator.
  • Avoid using the regular expression (regex) based on the match (~) operator, because it is not very efficient and can cause performance issues. Properly formatted rules using the contains operator provides equivalent functionality. If this operator is required, make it the last set of criteria in the rule.
  • For all rules based on events, do not create a rule format where the first operator in the rule is the or operator. All events will validate against the rule. For example, don’t do this:

    (packet_type == “log” OR <any other match criteria.>

    The use of the or operator in the rule matches every event normalized and causes the rule type to always be processed. For filtering rules, all processed events are deleted or discarded. This action is terminal and all deleted or discarded data by the rule can't be recovered by USM Anywhere.

  • Suppression of an event or alarm terminates correlation actions of subsequent rules. This means that suppressed events will not correlate against alarm or notification rules, so alarms and notifications will not be generated. Suppressed alarms will not correlate against alarm notification rules either, so notifications will not be generated.

  • The use of filter rules does not reduce processing load on the sensor. Filter rules are only intended to reduce network traffic to the control node and event data storage in the service tier.

    All events received via syslog by a sensor are processed to create the full event details of the event. Correlation of filtering rules is done at the last stage of this process, at which time events that match a filter rule are discarded. Events that do not match a filter rule are sent to a sensor back-end process that uploads event information to the control node. To reduce the impact of additional processing of these events on a sensor node, it is important to be specific in configuring what messages are sent from sources such as firewall, network switches, or routers. Configure these devices to filter out unnecessary raw log information at that stage of events.

  • An excessive number of orchestration filter rules on a sensor node will have a negative effect on the sensor node’s resource usage. Every event processed by a sensor node must be matched up against all filter rules until a rule matches (and, therefore, the event is discarded) or all rules fail to match (in which case the event is post-processed for upload to the control node). All sensors get the same copies of filter rules from the control node regardless of sensor type. The use of the plugin data source name early in the rule helps minimize event processing under these conditions. Combine multiple rules into a single rule to reduce the number of items processed.

  • Alarm Suppression rules have limited visibility to the event details of the events that triggered the alarm. Use of event details in match criteria may disable the ability of the rule to validate true. As an example, the use of event packet payload information (packet_payload contains ‘<some string>’) will not produce a true condition; therefore, the rule will not trigger an alarm suppression.

  • All user roles can view the rules page. Users with manager and analyst roles can create, edit, enable, and disable orchestration rules and correlation lists. Orchestration rules and correlation lists can only be deleted by the user who created the rule or the list.

  • Keep in mind, when you use the syntax event_field >> variable that the event field can't be empty. If the event field is empty, there will be false positives.

Orchestration Rules Creation

Before creating an orchestration rule, it is necessary to understand what an orchestration rule is, the different orchestration rules you can create, and how an orchestration rule operates. See Orchestration Rules and Orchestration Rules Workflow before creating an orchestration rule.

There are two ways of creating an orchestration rule:

To create an orchestration rule from an alarm or an event

  1. Go to Activity > Alarms or Activity > Events.
  2. Locate the alarms or events you want to include in the rule.
  3. Click an alarm or event to see its details.
  4. Click Create Rule:
    • If you are displaying an alarm, you can choose between a suppression or a notification rule.
    • If you are displaying an event, you can choose between an alarm, filtering, notification, or suppression rule.
  5. You have already suggested property values to create a matching condition, but you can add new property values by clicking Add Condition.
  6. Note: If the field is related to the name of a country, you should use the country code defined by the ISO 3166.

    Note: The Sources or Destinations field needs to match the universally unique identifier (UUID) of the event or alarm. You can use the Source Name or Destination Name field instead.

    Important: Instead of using the equals and equals, case insensitive operators for array fields, AT&T Cybersecurity recommends the use of the in or contains operators.

    Note: If you need to add a property value that maps with a property key, you need to know the mapping of the field. See Determining the Mapping of a Field for more information.

  7. (Optional.) Click Add Group to group your conditions.
  8. Note: See Operators in the Orchestration Rules for more information.

    Note: The current rule box shows you the syntax of your rule, and the rule verification box checks that syntax before saving the rule.

  9. Click Next.
  10. Rules Verifications Dialog Box

    Important: A dialog box opens if there are warning messages. Click Cancel to review the warning messages, or click Accept to continue creating the rule.

  11. Enter a name for the rule.
  12. (Optional.) Enter a description for identifying this rule.
  13. Depending on the selected rule, you should fill in different fields.
  14. Modify these two options:

    • Occurrences: Specify the number of event occurrences that produce a match on the conditional expression to trigger the rule. You can enter the number of occurrences or use the arrow to scroll the value up or down. You need to enter a number between 1 and 100.
    • Length: Specify the length of the timespan used to identify a match for multiple occurrences. Enter the number and choose a value of seconds, minutes, or hours.

      This duration identifies the amount of time that transpires from the beginning to end of the occurrence. If the number of occurrences is not met within this period, the rule is not a match.

      Specify multiple occurances to match for the rule

      In this example, the rule applies when the configured conditions happen five times every three hours.

    These two options function together to specify the number of occurrences within a time period that will produce a match for the rule. For example, you can define a rule to trigger an alarm Alarms provide notification of an event or sequence of events that require attention or investigation. for an unauthorized access An incident-type categorization that may be a precursor to other actions or stages of an attack. attempt when a failed SSH Program to securely log into another computer over a network, execute commands in a remote machine, and move files from one machine to another through Secure Copy (SCP). login Log in (verb): Process in which an individual gains access to a computer system after providing sufficient credentials to authenticate their unique identity. Login (noun): User credentials, typically a username and matching password. occurs three times within a five-minute window.

  15. Click Save.

    The created rule displays in the list of rules. You can see it from Settings > Rules > Orchestration Rules. See Orchestration Rules for more information.

  16. Important: It takes a few minutes for an orchestration rule to become active.

To create an orchestration rule from the orchestration rules page

  1. Go to Settings > Rules > Orchestration Rules, click Create Orchestration Rule, and select the rule you want to create:
  2. Click Add Conditions and select the property values you want to include in the rule to create a matching condition.
  3. Note: If the field is related to the name of a country, you should use the country code defined by the ISO 3166.

    Note: The Sources or Destinations field needs to match the universally unique identifier (UUID) of the event or alarm. You can use the Source Name or Destination Name field instead.

    Important: Instead of using the equals and equals, case insensitive operators for array fields, AT&T Cybersecurity recommends the use of the in or contains operators.

    Note: If you need to add a property value that maps with a property key, you need to know the mapping of the field. See Determining the Mapping of a Field for more information.

  4. (Optional.) Click Add Group to group your conditions.
  5. Note: See Operators in the Orchestration Rules for more information.

    Note: The current rule box shows you the syntax of your rule, and the rule verification box checks that syntax before saving the rule.

  6. Click Next.

    Rules Verifications Dialog Box

    Important: A dialog box opens if there are warning messages. Click Cancel to review the warning messages, or click Accept to continue creating the rule.

  7. Enter a name for the rule.
  8. (Optional.) Enter a description for identifying this rule.
  9. Depending on the selected rule, you should fill in different fields.
  10. Modify these two options:

    • Occurrences: Specify the number of event occurrences that produce a match on the conditional expression to trigger the rule. You can enter the number of occurrences or use the arrow to scroll the value up or down. You need to enter a number between 1 and 100.
    • Length: Specify the length of the timespan used to identify a match for multiple occurrences. Enter the number and choose a value of seconds, minutes, or hours.

      This duration identifies the amount of time that transpires from the beginning to end of the occurrence. If the number of occurrences is not met within this period, the rule is not a match.

      Specify multiple occurances to match for the rule

      In this example, the rule applies when the configured conditions happen five times every three hours.

    These two options function together to specify the number of occurrences within a time period that will produce a match for the rule. For example, you can define a rule to trigger an alarm Alarms provide notification of an event or sequence of events that require attention or investigation. for an unauthorized access An incident-type categorization that may be a precursor to other actions or stages of an attack. attempt when a failed SSH Program to securely log into another computer over a network, execute commands in a remote machine, and move files from one machine to another through Secure Copy (SCP). login Log in (verb): Process in which an individual gains access to a computer system after providing sufficient credentials to authenticate their unique identity. Login (noun): User credentials, typically a username and matching password. occurs three times within a five-minute window.

  11. Click Save.

    The created rule displays in the list of rules. You can see it from Settings > Rules > Orchestration Rules. See Orchestration Rules for more information.

  12. Important: It takes a few minutes for an orchestration rule to become active.

Orchestration Rule Validation

When orchestration rules are active, USM Anywhere inspects and validates them to show you how well the rule is working. The rule status is indicated by an icon next to the name of an active orchestration rule.

Active orchestration rules display an icon indicating their validation

Be sure to check your rule's validation, and make recommended or necessary changes to optimize the rule based on the validation status.

Orchestration Rules Processing

All orchestration rules, including event filter rules, are processed on the control node. A sensor node will only process orchestration filter rules. Event filter rules are reapplied on the control node because event enrichment for the event on the control node can modify or add to event details with items not found on the sensor node during normalization.

See Orchestration Rules Workflow to learn more about the specific order that USM Anywhere applies to orchestration rules.