The purpose of a (textually based) Compliance Test is to check that certain statements are contained within a Device's configuration files to verify that the device is compliant with the rules and policies defined by the organization that manages the device.

If the device is non-compliant, the Compliance Test may optionally generate a remediation, which can be applied to the Device. The goal of the remediation is to change the Device's configuration so that after the remediation is applied, the Device becomes compliant.

Note: Previously, Preconditions and Check Patterns tabs were used in the Automation Library Editor when creating or customizing a RegEx Compliance test. Now, the Chained Compliance feature offers General, Scope, and Rule tabs contained within the Steps tab.

These new tabs take the place of the previous tabs. Using the Scope and Rule tabs allow you to quickly set the operators that qualify the configuration, prior to running the test, and assist you in further scanning the configuration to locate specific information from that file.

A Steps Compliance test consists of one or more Steps that are executed in order, from the first step to the last. Each Step, individually, has all the abilities of a RegEx test, including:

  • The ability to define a scope and disqualify the test if the scope is not met, or as an alternative, generate a remedy if the scope is empty

  • The ability to extract stanzas from the steps input for use in the Rule, or in subsequent steps

  • The ability to execute a Rule against the configuration

Each step in a test is logically divided into components, each of which is optional. However, you must define at least one step, and have content within either the Scope or Rule tab.

These are:

  • Scope Definition: which defines the textual scope to be used for the rule processing, and optionally passed to subsequent steps. Scope definition can be sub-divided into stanza extraction, stanza filtering, and the handling of an empty scope (as either a disqualified test or the generation of a remedy).

  • Rule Processing: which includes executing a Regular Expression (RegEx) Pattern against the stanzas generated by the steps Scope Definition (or against other selectable inputs); and Remedy Generation, which is executed if the rule processing for a step determines that the device is not compliant.

Several enhancements have been provided that give Step Compliance much more flexibility and power. They include:

  • The ability for a step to use the configuration text as input, or to take input from the stanzas generated in a previous step

  • The ability to iterate over the input stanzas, sub-dividing them into sub-stanzas

  • The ability to define a named variable that holds the values that matched a regular expression grouping for each sub-stanza

For additional information on the Compliance Steps, see The Chained Compliance Steps Design Overview.

Continue on with the General tab.