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 eventAny traffic or data exchange detected by AT&T Cybersecurity products through a sensor, or through external devices such as a firewall. or alarmAlarms 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:

  • The first match criteria for all rules should be the packet_type detail field. The available values are log for event-based rules and alarm for alarm-based rules.
  • If packet_type == log is used in the rule, the second rule match criteria should 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>’) .

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

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. Enter a name for the rule.
  6. Depending on the selected rule, you should fill in different fields.
  7. You have already suggested property values to create a matching condition, but you can add new property values by clicking Add Condition.
  8. Note: If the field is related to the name of a country, you should use the country code defined by the ISO 3166.

    Note: Keep in mind that 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.

  9. (Optional.) Click Add Group of Conditions to group your conditions.
  10. Note: See Operators in the Orchestration Rules for more information.

  11. (Optional.) Click the More link to include a multiple occurrence parameter.

    These 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 alarmAlarms provide notification of an event or sequence of events that require attention or investigation. for an unauthorized accessAn incident-type categorization that may be a precursor to other actions or stages of an attack. attempt when a failed SSHProgram to securely log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another through Secure Copy (SCP). loginLog 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. These are the two options that you can modify:

    • 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 window used to identify a match for multiple occurrences. Enter the number and choose a time-unit value of seconds, minutes, or hours.

      This duration identifies the amount of time that transpires from the first to last. 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.

  12. Click Save Rule.

To create an orchestration rule from the orchestration rules page

  1. Go to Settings > Rules, click Create Orchestration Rule, and select the rule you want to create:
  2. Enter a name for the rule.
  3. Depending on the selected rule, you should fill in different fields.
  4. You have already suggested property values to create a matching condition, but if you want to add new property values, click Add Condition.
  5. Note: If the field is related to the name of a country, you should use the country code defined by the ISO 3166.

    Note: Keep in mind that 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.

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

  8. (Optional.) Click the More link to include a multiple occurrence parameter.

    These 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 alarmAlarms provide notification of an event or sequence of events that require attention or investigation. for an unauthorized accessAn incident-type categorization that may be a precursor to other actions or stages of an attack. attempt when a failed SSHProgram to securely log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another through Secure Copy (SCP). loginLog 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. These are the two options that you can modify:

    • 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 window used to identify a match for multiple occurrences. Enter the number and choose a time-unit value of seconds, minutes, or hours.

      This duration identifies the amount of time that transpires from the first to last. 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.

  9. Click Save Rule.

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.