NetApp compliance checks are bracketed in custom_item encapsulation and CONFIG_CHECK. This is treated like any other .audit files and work for systems running the NetApp Data ONTAP system. The CONFIG_CHECK check consists of two or more keywords. Keywords type and description are mandatory, which are followed by one or more keywords. The check works by auditing the “options” command output.


The following table indicates how each keyword in the NetApp Data ONTAP compliance checks can be used:


Example Use and Supported Settings


“CHECK_CONFIG” determines if the specified config item exists in the NetApp Data ONTAP “show configuration” output.


This keyword provides the ability to add a brief description of the check that is being performed. It is strongly recommended that the description field be unique and no distinct checks have the same description field. Tenable uses this field to automatically generate a unique plugin ID number based on the description field.


description: "1.0 Require strong Password Controls - 'min-password-length >= 8'"


The info keyword is used to add a more detailed description to the check that is being performed. Rationale for the check could be a regulation, URL with more information, corporate policy, and more. Multiple info fields can be added on separate lines to format the text as a paragraph. There is no preset limit to the number of info fields that can be used.

Note: Each info tag must be written on a separate line with no line breaks. If more than one line is required (e.g., formatting reasons), add additional info tags.


info: "Enable palindrome-check on passwords"


The severity keyword specifies the severity of the check being performed.


severity: MEDIUM

The severity can be set to HIGH, MEDIUM, or LOW.


The regex keyword enables searching the configuration item setting to match for a particular regular expression.


regex: "set snmp .+"

The following meta-characters require special treatment: + \ * ( ) ^

Escape these characters out twice with two backslashes “\\” or enclose them in square brackets “[]” if you wish for them to be interpreted literally. Other characters such as the following need only a single backslash to be interpreted literally: . ? " '

This has to do with the way that the compiler treats these characters.

If a check has “regex” tag set, but no “expect” or “not_expect” or “number_of_lines” tag is set, then the check simply reports all lines matching the regex.


This keyword allows auditing the configuration item matched by the regex tag or if the regex tag is not used it looks for the expect string in the entire config.

The check passes as long as the config line found by regex matches the expect tag or in the case where regex is not set, it passes if the expect string is found in the config.


regex: "set password-controls complexity"

expect: "set password-controls complexity [1-4]"

In the above case, the expect tag ensures that the complexity is set to a value between 1 and 4.


This keyword allows searching the configuration items that should not be in the configuration.

It acts as the opposite of expect. The check passes as the config line found by regex does not match the not_expect tag or if the regex tag is not set, it passes as long as not_expect string is not found in the config.


regex: "set password-controls password-expiration"

not_expect: "set password-controls password-expiration never"

In the above case, the not_expect tag ensures that the password-controls are not set to “never”.


The following is an example of using CONFIG_CHECK against a NetApp Data ONTAP device:



description: "1.2 Secure Storage Design, Enable Kerberos with NFS - 'nfs.kerberos.enable = on'"

info: "NetApp recommends the use of security features in IP storage protocols to secure client access"

solution: "Enable Kerberos with NFS"

reference: "PCI|2.2.3"

regex: "nfs.kerberos.enable[\\s\\t]+"

expect: "nfs.kerberos.enable[\\s\\t]+on"