Role AvailabilityRead-OnlyInvestigatorAnalystManager
USM Anywhere enables you to create and customize your own orchestration rules to conform with your company’s cybersecurity practice, but a poorly-written rule can easily overwhelm the sensor, fill up storage, or even crash the system. Therefore, LevelBlue recommends the following best practice guideline for creating orchestration rules.

​
General Guideline

When creating an orchestration rule, you must specify an item you want to match and your matching criteria. Depending on the type of rule, the matching item can be , logs (), configuration issues, vulnerabilities, system events, or console user events. Your matching criteria is called rule conditions in USM Anywhere. Each rule condition contains three parts: a field, an operator, and a value.
Ensure that all fields referenced by your rule are present in the item you are matching against; otherwise, your rule won’t be evaluated and, therefore, won’t be applied. See Orchestration Rule Validation for more information. Carefully decide whether to suppress alarms or events. Suppression rules are usefull for suppressing false positives, but you must take care not to suppress true positives. Once an alarm or event is suppressed, all subsequent correlation or orchestration rule activity is terminated for that event or alarm and will not trigger any notifications. Since alarms are raised from events, it’s more efficient to suppress events when they are deemed unimportant so that alarms won’t be generated. If you want to keep the events but don’t need the alarms, you can filter the alarms to prevent them from being processed any further.

​
Best Practice on Rule Conditions

As you add different conditions to your rule, USM Anywhere converts them into query strings and displays them in the same order as added under Current Rule.
When USM Anywhere evaluates these conditions, it processes them from left to right and stops whenever a condition evaluates to true or false. At that point, any rules criteria following this state are discarded, and the rule action is taken if true and dropped if false. For example, the following rule is always false: 
packet_type == ‘log’ AND source_username == ‘Bill’ AND source_username == ‘Bob’ AND...
On the other hand, depending on the packet type, the following is always true because the rule valuates true and the rule action is always taken: 
packet_type == ‘log’ OR ‘<any_criteria>’ is always true for every event item.
packet_type == ‘alarm’ OR ‘<any_criteria>’ is always true for every alarm item.
Consequently, LevelBlue provides the following best practice guideline for rule conditions:
  • To ensure efficient processing, all rules should contain at least two conditions, one for packet_type and the other for plugin. packet_type is the internal field name for the item you are matching against, while plugin is the internal field name for Data Source.
  • Place the most restrictive condition immediately after Data Source to save time processing the conditions.
  • Use Equals for string comparison (case sensitive) as much as possible because it consumes the least resources.
  • Evaluate your conditions carefully (from left to right) to make sure that it isn’t always true or always false. For example, the following rule is always false: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND access_control_outcome == 'Deny' AND source_username IN ('VALUE_1', 'VALUE_2', 'VALUE_3') AND access_control_outcome == 'Allow'
    On the other hand, a rule with the following conditions is always true: 
    packet_type == 'log' OR packet_type != 'log'
    Important: While always-true conditions are ineffective for most rules, they can be detrimental in Filtering Rules because the sensor will discard all the events when applying such a rule. Discarded events cannot be recovered. See How can I Test an Orchestration Filtering Rule? for more information on how to validate a Filter Rule before it is enabled.
  • Reduce the total number of rules. Avoid having multiple rules with the same conditions to reduce resource consumption. For example, if there are the following two rules: Rule 1: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND access_control_outcome == 'Deny' AND source_username == 'VALUE_1'
    Rule 2: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND access_control_outcome == 'Deny' AND source_username == 'VALUE_2'
    It’s better to combine them into one rule: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND access_control_outcome == 'Deny' AND source_username IN ('VALUE_1', 'VALUE_2')
  • Do not add extra fields or conditions in the rule that have no bearing on the result. For example: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND event_name == 'PAM authentication failure' AND access_control_outcome == 'Deny' AND authentication_type == 'pam_unix'
    The last condition is unnecessary because all SSH attempts use pluggable authentication modules (PAM) for authentication.

​
Best Practice on Rule Operators

USM Anywhere supports a wide range of operators when creating orchestration rules. Some operators require more resources to process than others; therefore, LevelBlue also provides some guidelines on choosing the best operators for your rules:
  • Always use case sensitive comparators where available. Equals, Not Equals, Contains, Assign or Equals, In, Match, In List, and Not In List offer both case-sensitive and case-insensitive comparisons.
  • If you want to match a specific string, use Equals instead of Contains. Use: 
    packet_type == 'log' AND plugin == 'Linux SSH'
    Do not use: 
    packet_type == 'log' AND plugin contains 'Linux SSH'
  • Use IN instead of multiple Equals and OR combinations for the same field. Use: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND access_control_outcome == 'Deny' AND source_username IN ('VALUE_1', 'VALUE_2', 'VALUE_3')
    Do not use: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND access_control_outcome == 'Deny' AND (source_username == 'VALUE_1' OR source_username == 'VALUE_2' OR source_username == 'VALUE_3')
  • Use a Correlation List and the In List operator where possible. For example: 
    packet_type == 'log' AND plugin == 'Linux SSH' AND access_control_outcome == 'Deny' AND source_username -> [[Values_List]])
    Note: You can’t use correlation lists in filtering rules.
  • If you want to match a field with no values, use the Is Empty operator. This is how the LevelBlue Generic Data Source events are identified. Search for events where the Data Source field is empty. The AlienVault Generic Data Source is not a valid data source name. Use it as plugin == “” for the Data Source Event field, which means that the data source is empty. See USM Anywhere Rules - Use of “AlienVault Generic Data Source” in Orchestration Rules for more information.
  • Use Contains instead of Match. The Match operator requires a valid regular expression (regex) as the value. Using a malformed regex to search a large raw log can cause performance degradation. If you have to use Match, form a simple regex and place this condition as the last one in your rule.
  • Avoid using OR, OR NOT, and AND NOT operators unless absolutely necessary. It’s very easy to create always-true or always-false conditions when using these operators.
  • Do not use packet_payload event detail for rule criteria because the rule will not validate as true. Use raw log event details if you need them, which consist of the packet syslog header followed by the packet payload data. The use of this event detail generates a warning message in the rules user interface (UI) views. Specify packet type==log to have a valid rule. Alarm rules do not have access to this data field and will never validate as true.
    Important: Don’t use packet type==alarm for a filter rule. Alarms can’t be filtered out. Use packet type==log.

​
Related Video Content

Related Video Content

To view other related training videos, click here.