Database Configuration Keywords

The following table indicates how each keyword in the database compliance checks can be used:

Keyword

Example Use and Supported Settings

type

SQL_POLICY

description

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.

Example:

description: "DBMS Password Complexity"

info

This keyword is used to add a more detailed description to the check that is being performed such as a regulation, URL, corporate policy or other reason why the setting is required. 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.

Example:

info: "Checking that \"password complexity\" requirements are enforced for systems using SQL Server authentication."

sql_request

This keyword is used to determine the actual SQL  request to be submitted to the database. Arrays of data may be requested and returned from a SQL request by using comma-delimited request/return values.

Example:

sql_request: "select name from sys.sql_logins where type = 'S' and is_policy_checked <> '1'"

Example:

sql_request: "select name, value_in_use from sys.configurations where name = 'clr enabled'"

sql_types

This keyword has two available options:

  • POLICY_INTEGER: Numeric-based results.
  • POLICY_VARCHAR: Text-based results.

Example 1:

sql_types: POLICY_VARCHAR

For multiple return items, configure sql_types in a comma-separated list to accept the data types of each SQL return result. The following example indicates that the first return value from the SQL query is text-based and the second return value is an integer.

Example 2:

sql_types: POLICY_VARCHAR,POLICY_INTEGER

sql_expect

A comma separated list of the values, or regular expression, to evaluate the results from the SQL query. The values for each of the columns must match the types that are defined in the sql_types. The number of sql_expect items must match the number of sql_types.

Numbers do not need double quotes. For text values, surround the text in double quotes ("). If a returned text value can vary in what is returned, use the regular expression in the form of regex:"<expression>".

For cases where cases where no rows are returned, use NO_ROWS_RETURNED. This is more explicit than using check_option.

Example:

sql_expect: regex:"^.+(Failure|ALL)"

Example:

sql_expect: NULL

Example:

sql_expect: "clr enabled",0
check_option

Options that are used to adjust how to handle special cases. The most notable option is how to handle what happens when no results are returned.

  • CAN_BE_NULL: Will pass if no data is returned from the query.
  • CAN_NOT_BE_NULL: (Default) Will not pass if no data is returned from the query.

Usage

<custom_item>

type: SQL_POLICY

description: ["description"]

sql_request: ["sql statement to run"]

sql_types: [POLICY_VARCHAR|POLICY_INTEGER][,....]

sql_expect: ["text"|number|regex:"expr"]

(optional) check_option: [CAN_BE_NULL|CAN_NOT_BE_NULL]

</custom_item>