AWS Keywords

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


Example Use and Supported Settings


The keyword type specifies the API we are tapping into to pull back the information (in this case IAM).


The “description” 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 that 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.


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 lines within a single info field is supported, as well as additional info fields 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 regular line breaks after each line (as with the enter key), use "\n" to create a new line, or add additional "info" tags as needed.


info: "Review the list of interfaces"

info: "Disable unused interfaces"


This keyword specifies the Amazon API action we are running against the AWS setup.


This keyword gives you a way to define the XSL Transform that will be applied on the XML file you get back after running the API request.


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


regex: " set system syslog .+"

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.


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.

If regex, expect, and not_expect are not specified, it will report the entire output from the API query.