This page includes orchestration rules examples that you can use as guide when you create your own orchestration rules. The examples use the allowed operators in USM Anywhere. See
Rules processing is a Boolean query of rules operators. Processing is performed left to right until the rule is either validated (the stated rule action is taken), or invalidated (the processing terminates). The entire rule does not have to be processed and any additional query operators after this point are discarded.
Example 1: Use the OR Boolean Operator
A Boolean query is a type of search enabling you to combine keywords or phrases with operators such as AND, NOT and OR to further produce more relevant results. Keep in mind that the format of this example will match against all events processed by the rule, so it causes the rule to always be triggered.
(packet_type == ‘log’) OR <any additional match criteria>
Once the rules processor hits the OR operator, it validates the rule criteria and performs the rule action. Any match criteria that follows the OR is not seen.
You can get different results depending on the type of rule you create:
- If it is an alarm rule, every event creates an alarm.
- If it is a suppression rule, every event is suppressed. Keep in mind that suppressed events are not correlated for alarms. See
Suppression Rules from the Orchestration Rules Pagefor more information.
- If it is a notification rule, every event causes a notification action.
- If this is a filter rule, every event is filtered and discarded from your environment. You can't recover these events.
Example 2: Use the Same Criteria in Two Different Rules
When you create a rule, ensure that the rule doesn't match criteria with additional operators of a different rule. For example, look at these two rules:
(packet_type == 'log' AND event_severity == 'ERROR' AND event_category == 'System' AND event_subcategory == 'Microsoft-Windows-WindowsUpdateClient')
(packet_type == 'log' AND event_severity == 'ERROR' AND event_category == 'System' AND event_subcategory == 'Microsoft-Windows-WindowsUpdateClient' AND source_username == 'SYSTEM' AND source_ntdomain == 'NT AUTHORITY')
If the second rule is triggered, the first rule is also triggered, which causes duplicate rule actions. The second rule is basically the first rule but with a few more operators.
Example 3: Merge Rules with the Same Format
When you have multiple rules with the same format, you can merge rules and match the difference. For example, instead of having two separate rules:
(packet_type == 'log' AND access_control_outcome == 'Deny' AND source_username == 'VALUE_1')
(packet_type == 'log' AND access_control_outcome == 'Deny' AND source_username == 'VALUE_2')
You can merge these rules into this one:
(packet_type == 'log' AND access_control_outcome == 'Deny' AND (source_username == 'VALUE_1' OR source_username == 'VALUE_2'))
Or your can merge the rules into this one:
(packet_type == 'log' AND access_control_outcome == 'Deny' AND source_username in ('VALUE_1','VALUE_2'))
Example 4: Don't Use Rules Criteria of the Same Value Type
Don't use rules criteria of the same value type because they are basically one and the same in the rule definition. Each "rule_attack_id" item in this format will have "rule_attack_tactic" and "rule_attack_technique" values that are unique to it. By specifying the single detail of "rule_attack_id == 'T####' ", the other match details can be safely removed for rules clarity and rules processing efficiency. Note that the creation of the three match criteria is a normal action of the rules generator.
For USM Anywhere, this rule:
(packet_type == 'alarm' AND rule_id == 'Windows New service installed' AND source_ntdomain == 'FINICITY' AND rule_attack_id == 'T1050' AND rule_attack_tactic in ('Persistence', 'Privilege Escalation') AND rule_attack_technique == 'New Service')
is better to write as follows:
(packet_type == 'alarm' AND rule_id == 'Windows New service installed' AND source_ntdomain == 'FINICITY' AND rule_attack_id == 'T1050')
Example 5: Avoid the Use of the regex "match" (~) Criteria
Don't use the regex "match" (~) operator because it can cause a performance issue with the server using it.
Instead of this rule:
(packet_type == 'log' AND event_name == 'PowerShell: EventID 400' AND log ~ /C:\\Scripts\\script.ps1/)
You can use this rule:
(packet_type == 'log' AND event_name == 'PowerShell: EventID 400' AND packet_payload contains 'C:\\Scripts\\script.ps1')
Or you can use this rule:
(packet_type == 'log' AND event_name == 'PowerShell: EventID 400' AND log contains 'C:\\Scripts\\script.ps1')
For data ingestion from syslog sources, the "raw_log" is the entire syslog packet received for processing. This is the syslog format:
<PRI> date/timestamp device hostname/IP address event message/packet payload
The "event message/packet_payload" is the information with the headers stripped off.
For processing purposes, both rules are almost equivalent but packet_payload is the preferred detail to use. Network-based intrusion detection system (NIDS) traffic inspection does not use syslog.
Example 6: Simplify Your Rules
When you have a rule that uses the same operator multiple times, you can simplify it. Look at this example:
(packet_type == ‘log’ AND ( event_name == ‘Value1 OR event_name == ‘Value2’ OR event_name == ‘Value3’))
You can simplify the rule by removing the “OR” operator:
(packet_type == ‘log’ AND event_name in (‘Value1’, ‘Value2’,‘Value3’))
(alarm_source_countries in ('US', 'CA')
USM Anywhere doesn't validate a rule in the case of matching the same event detail information against different match values.
(alarm_source_countries == 'US' AND alarm_source_countries == 'CA')
The event detail has a single set value in the normalized event. It can never validate against multiple values when using the AND operator.
You can use one of these two rules:
(alarm_source_countries == 'US' OR alarm_source_countries == 'CA')
Or this rule:
(alarm_source_countries in ('US', 'CA')
Example 7: Boolean Operators Read from Left to Right
Boolean Operators read from left to right, for example look at this rule:
(packet_type == 'log' AND event_category == 'acl_change' AND (event_action == 'Create User' OR event_action == 'change_user_access') AND (file_permission != 'shared_internally' OR file_permission != 'private') AND destination_username != 'firstname.lastname@example.org')
Keep in mind that the form of (file_permission != 'shared_internally' OR file_permission != 'private') gives the result of true if either of the operators are true. In the example, the expression is validated as true even though the portion file_permission != 'private' is false. The rule operator is using the match operator of not equal (!=), so that rule portion is always true.
Example 8: Values Separated by a Comma
When there are two values separated by a comma in an alarm or an event detail, the match criteria will fail if it's matching against only a portion of the detail item value. The rule will incorrectly auto-populate using the in operator and not the equals (==) operator. This is due to the comma found in the detail data field. The correct operator to use is the equals (==) operator.
See this example from the alarms detail page:
RULE ATTACK TACTIC Persistence,Privilege Escalation
This match criteria is incorrectly auto-populated with the in operator and will always fail:
rule_attack_tactic in ('Persistence','Privilege Escalation')
The comma has separated the match string into two unique values that can never validate. The actual match value is a single string, with the comma included.
It should read like this:
rule_attack_tactic == ('Persistence,Privilege Escalation')
Note that the single quotes establishes it as a single string value and are automatically added by the rules generator.