Whether assessing systems against your organization’s own security policy or industry benchmarks and standards, configuration auditing is critical to compliance. Security policies are defined via .audit files. This blog post will help you get the most accurate and complete information when using .audit files.
Trying to determine if your organization’s systems are configured in accordance with your organization’s security and compliance policy – or if they adhere to third-party standards, such as CIS or DISA?
Tenable® products have a feature built in for configuration auditing, using a wide range of predefined policies for auditing against benchmarks and guides from organizations like CIS and DISA. In addition to the predefined policies, you can download, modify and scan using customized audits.
The security policy is defined using a file format called an .audit. To quickly customize an .audit file to match an environment, variables are used during the assessment. When using an .audit file, the variable updating is handled as a part of the scan policy.
What are audit variables?
When we develop .audits for configuration auditing, we use variables to easily customize the configuration checks to the customer's accessed environment. One notable example is IP addresses for services in the environment, such as NTP Servers. Because the audit is developed by Tenable, the customer’s IP address is not known in the environment to be accessed. Thus, the audit writer will use a variable to allow the customer to easily replace that value in the audit.
For example, the audit writer would use a variable named NTP_SERVER with a description of Network Time Server and assign a default value of 10.0.0.2. When the audit is selected in a scan policy, the policy should prompt for a value for the Network Time Server, and provide a value of 10.0.0.2.
If the network time server in the environment to be accessed is 192.168.0.2, the customer can enter the real value in the policy. When the scan happens, all instances where @[email protected] is used will be replaced with the value entered into the Network Time Server, and evaluated with the new address.
An example line found in an .audit file could be:
The line would be changed to look like this:
regex : "^[\\s]*server[\\s]+192.168.0.2"
And the output in the compliance result could look like this:
How Tenable uses variables
The variables are located in the audit file in a special section used to help enhance the user experience of Tenable products. If you look at the definition of the variables, they appear to be a commented section that could be uncommented and usable.
This section is commented out from the rest of the audit and only used when published through a Tenable product. If the audit is used as a custom audit and uploaded into the policy, this section is currently ignored. Uncommenting the variable would cause an error when the audit is evaluated, if not on upload.
Additionally, audits published on Tenable Audit Downloads are processed by having variables replaced with default values. This allows the audits to be downloaded and immediately used. If the variables values were not replaced in an .audit file, the worst case is the .audit is broken and will not scan. Best case, it will produce unreliable results.
When downloading audits for a custom .audit, the process that replaces the variables with default values also adds comments to identify where the variables were used and with what value they’ve been replaced with. This can help to manually go through the audit and update all the values with the environment-specific values.
How to work with variables
The best way to work with variables in audits is to use the UI to update the value before scanning. This should provide the highest quality in published audits. But, this ignores the power and flexibility of using downloaded and custom audits to adjust to the policies and configurations of the accessed environment.
By using a downloaded audit or creating a custom audit, you can update an audit for special situations, such as:
- Commenting out checks that don’t make sense for the environment
- Forcing unique values for checks due to special cases in the environment
- Forcing a result of a check due to accepted risks in the environment
- Creating new checks for configurations important to the environment
The only way to adjust values in the current custom audit files is to open the file in a text editor, search for comments on where a variable is replaced and change the value in the line below the comment.
For best results, use Atom, Sublime or VS Code as the editor. Atom and Sublime have packages that can be added to enable syntax highlighting for NASL and .audit files.
- Atom package: https://atom.io/packages/language-nasl
- Sublime package: https://github.com/tenable/sublimetext-nasl
Another way to make the variable replacement easier is a script published on GitHub at Replace Variables. Although this python script doesn’t eliminate the need for a text editor, it limits the edits that need to be made to only the variable definition. The steps to update the variable values in this script are:
- Update the audit file variable definition with the value required in your environment.
- Run the script against the audit file to create an updated audit.
- Import the audit into your scanning policy and scan.
You can find an example execution of the script on the GitHub page.
Where do we go from here?
So, how do we improve the use of variables? With Tenable.io, you can quickly make and share improvements, such as:
- Auditing variables processed on import
- Auditing writer workbench to assist in the build and use of audits
- Auditing check library to work with a workbench to copy and modify current checks
And like Bill Kurtis from Wait Wait...Don't Tell Me! would say... Well, if any of that happens, we're going to tell you about it here on the blog.