Adding or editing a rule

Rules can be used to provision new devices and audit and enforce configuration best practices based on a set of rules. This topic describes how to configure a rule.

To add or edit a rule

1. Open the Rules page by navigating to Network > Scripts > Rules.
2. Perform one of the following actions:
   • To define a new rule, click Add.
     The Add Rule page is displayed.
   • To create a new rule by duplicating and editing an existing rule, click Copy.

   • To edit an existing rule, click Edit

     Tip

     To help you identify a rule that you want to copy or edit, you can view the summary of the attributes of a rule by clicking View.

     

3. On the Details tab, enter or modify settings in the following fields:

   Field	Description
   Name	Specify a unique name, up to 255 characters, for the rule.
   Annotation	(Optional) Describe the rule's purpose.
   Rule Set	Assign the rule to a rule set.
   Device Type	Specify the vendor and device type that the rule grammar supports; or choose to apply the rule to all device types. When you change the device type, all corrective actions are removed, since they might not be applicable to the new device type.
   Applicable Models	Specify one or more models that the rule grammar supports; or choose to apply the rule to all models. Note that the list of models to choose from are those discovered by the system associated with the currently selected vendor.
   (Applicable for only version 8.9.01 and later) Applicable OS Images	Enter the operating system versions to which the rule applies. Select one of the following options: Range: Enter the range of applicable versions delimited by a minimum and a maximum version. Enter * to specify any major, minor, or build version. Note: This option is available through Minimum OS Version and Maximum OS Version fields in version 8.9.00 of BMC Network Automation.  Pattern(s): Enter one or more regular expressions that match the desired target operating system versions.
   (Applicable for only version 8.9.00)  Minimum OS Version	Enter the minimal OS version for which this rule is compatible. Enter * to specify any major, minor, or build version.
   (Applicable for only version 8.9.00) Maximum OS Version	Enter the maximum OS version for which this rule is compatible. Enter * to specify any major, minor, or build version.
   Applicable Trails	Select one or more trails to which the rule applies.
   Security Context	When the selected device type supports multiple security contexts, select which type of context the rule applies to.
   Violation Severity	When auditing a rule for compliance, you can assign a risk factor to the rule. Compliance violation events are logged based on the assigned severity.
   Activation Date	(Optional) Specify the date on which the system should begin to monitor devices for violations for this rule.
   Deactivation Date	(Optional) Specify the date on which the system should clear violations for this rule and stop monitoring devices for violations for this rule. The period between the activation date and the deactivation date is called the activation window. For more information about this window, see Running automatic compliance checks in the activation window.
   CVE ID(s)	(Optional) Enter one or more CVE ID values to indicate that this rule is monitoring security vulnerabilities. A CVE ID must be formatted as CVE-dddd-dddd; that is, the uppercase string CVE followed by a dash, followed by a four-digit year, followed by a dash, followed by four or more digits.
   User Assigned Dynamic Fields	Assign values to the various required and optional dynamic fields. Note: The Category menu enables you to classify or organize your rules, You can use the dynamic field editor to tailor the values presented in this menu.

4. On the Grammar tab, specify the patterns that must be matched by the device to comply with this rule. For more information, see Defining rule grammar.

5. On the Spans tab, specify the network spans that you want to exclude from auditing and compliance enforcement by using the Add button. 
   
   You can apply a rule set to a large number of devices and then exclude a few devices or groups from the entire rule set or from specific rules. The excluded devices are thus ignored or skipped when auditing and enforcing the rule (that is, Deploy to Active with Configuration = Remediate With All Assigned).
   You can exclude the spans at the rule level, as follows:

   Span	Description
   Realm	Excludes the devices in a realm from applying the rule. You need to add realms one by one. You are limited to accessible realms.
   Group	Excludes the devices in a group from applying the rule. You need to add groups one by one. You are limited to groups in accessible realms.
   Device	Excludes one device from applying the rule. You need to add devices one by one. You are limited to devices in accessible realms.
   Group Filter	Excludes one or more groups matching a name from applying the rule. You can choose to look for groups in one particular realm, or you can choose to look for groups in any realm. You can use the wildcard character, asterisk (*) to search for groups. For example, you can enter Model_Cisco.176* in the filter criterion to exclude all the devices that belong to groups whose name starts with Model_Cisco.176, irrespective of the realm the groups belong to. The filtered groups include simple groups (both static and auto groups) only, not combo groups. If a new device is added to the system and if the device belongs to a group that satisfies the filter criterion, that device is excluded from the auditing and compliance enforcement automatically. Note: While choosing the excluded spans for a rule, the [Any] realm option is available for selection only if more than one realm exists in the system.

   In the following example, the group Vendor.Cisco group in the Default realm is being added to the excluded network spans. This span is ignored when BMC Network Automation audits and enforces the rule.
   
   

6. On the Corrective Actions tab, specify the span action that can be run to correct or remediate a violation of this rule. For each applicable trail, you might define a corrective action, where you enter parameters for either a Deploy to Active, Deploy to Stored, Deploy OS Image, or custom action. A rule with no corrective actions cannot be remediated. By default, a new rule has no corrective actions.
   
   In the Action column, click  to add a corrective action for the trail. Once added, you can edit or delete it. For example, to remediate a violation to the running trail, you might define a corrective action, Deploy to Active as follows:
   
   The options available here are very similar to the options when adding the same type of span action to a job. For more information, see the applicable topics under Creating a span job. The Deploy to Active and Deploy to Stored span actions include a new configuration option, Complying With This Rule. When you select this option, the system computes the configuration that complies with this rule, and when applicable, passes it through SmartMerge to yield an incremental merge script. The initial configuration for computing a compliant configuration is the current running configuration (for a Deploy to Active action) or the current startup configuration (for a Deploy to Stored action). Therefore, this option is available only for those trails in those actions.
   
   The corrective action defines the span action options that are to be used when remediating. You can remediate by running a job with a Remediate, Deploy to Active, or Deploy to Stored span action. Note that the same options in a Deploy to Active or Deploy to Stored action are configurable in the corrective action and also in the job or policy's span action editor. In the job or policy's span action editor, you can choose which set of options are to take effect – either the ones in the job or policy, or the ones from the corrective action for the rule. That is, you can choose to override the options defined in the corrective action.
7. When you have finished performing the configuration on the various tabs, click Save to save the rule.

The following video (6:45) explains how to define corrective actions using BMC Network Automation version 8.9.00.

https://www.youtube.com/watch?v=vU5TGKDvzM4

Remediation considerations

When the domain for a rule is OS Image Name, use caution when choosing the trails and creating associated corrective actions. The system associates the same image version with configurations of every trail. So, flagging violations in many trails is redundant and not recommended. You should apply the rule to a single trail (the running or other main configuration) and define a single corrective action for that trail.

Running automatic compliance checks in the activation window

The system checks for compliance violations only if a rule is active. A rule is active only within its activation window based on the current date of the BMC Network Automation web server. The following table lists various combinations of activation and deactivation dates that determine whether a rule is within its activation window.

While a rule is active, the system performs compliance checking of that rule when configuration changes are detected. Under certain circumstances (for example, when you add a new rule, edit a rule's grammar, or change the devices assigned to a rule set), you must perform a manual Refresh Device Status action to update the existing violations. But, the system performs an automatic refresh when a rule becomes active – that is, when the current time reaches the rule's activation date. The system also automatically clears violations when the current system time reaches a rule's deactivation date. These automatic refreshes are performed daily at the time specified in the Perform Daily Rule Activation/Deactivation At system parameter.

The automatic activation check is also done when you add a new rule that is within its activation window, or edit an existing rule such that it is now within its activation window. Since the automatic check is at a specified time, you do not immediately see violations. If you do not want to wait for this automatic check to find the violations, you should run the manual Refresh Device Status action.

For example, if you add a new rule whose activation date is February 15 and deactivation date is May 31, and today is March 1, the rule is considered to be active and the system performs an automatic compliance check at the scheduled time. On May 31, the rule is no longer active and the system clears its violations at the scheduled time.

If you edit a rule such that an active rule is no longer active, the system clears the violations when you save the rule. For example, if the rule initially had no deactivation date, and you assigned a deactivation date of yesterday, the violations are cleared at save time.

For a sample rule grammar that utilizes the activation window to run automatic compliance checks, see Device End of Life. 

BMC Network Automation is installed with a set of canned rules. These rules have no activation or deactivation dates, so they are within their activation windows. However, they belong to disabled rule sets, so no violation checking is performed by default.

When you upgrade to version 8.9.x, all existing rules are assigned null activation and deactivation dates, so that they are within their activation windows. But since these are pre-existing rules that were already "active", it is assumed that you have maintained their violation states properly. These rules do not undergo an automatic compliance check.

Related topic

Managing system parameters