Performance Considerations

File content auditing is a very resource intensive operation. All file systems need to be crawled, every directory visited, and every file of interest analyzed. There are several trade-offs that any organization needs to consider when modifying the default .audit files and testing them on live networks.

Start small and build up

When modifying a published audit, or creating a custom audit, it pays to start small. Starting small on a focused set of files eases the manual work, resources, and reduces the overall time it takes. Use the following steps:

1. Plant a file that should be found.

2. Place terms in the planted file that match terms that the policy expects.

3. Place the actual value that the policy regular expression should match.

4. Update the audit file to include only the path where you planted the file.

5. If there are multiple policies, make sure all policies include the path.

6. Run a scan with the new audit file to get it working to find the planted file.

7. Pull the include restriction back to get more directories scanned.

8. Repeat the scan.

This method helps with understanding what it takes to find files, and the resources and time it takes for a small scan to complete.

Which extensions should we search for?

The types of files being scanned is a factor in overall performance.

File types that are based on text encoding are the quickest and easiest to find content in. These file types tend to be text files, XML files, and JSON files.

File types that are compressed containers for other files must go through additional processing. Most productivity documents, such as Microsoft Word and Microsoft Excel, are collections of XML and other files in a zip archive. These complex documents must be uncompressed, and then evaluated. If any of the uncompressed parts of the document are too large, they may be skipped for evaluation.

Standard compressed archives, such as .zip and .gz, are not uncompressed and are not evaluated.

Binary file types are the hardest to work with. If there is a supported decoding of the binary data available in the file content plugins, there is a possibility for evaluation. If the binary files go beyond encoding and into encryption, it is not feasible to evaluate the files. The most notable of these types of files are PDF files, which have binary encoded objects for maintaining consistent presentation and security.

How much data should be scanned?

If a max_size is not specified, Tenable Nessus will attempt to retrieve entire files. Since these files traverse the network, there is more network traffic with these audits than with typical scanning or configuration auditing. By specifying a max_size in the audit files, the amount of data transferred over the network can be limited.

If multiple Tenable Nessus scanners are being managed by Tenable Security Center, the data only needs to travel from the scanned host to the scanner performing the vulnerability audit.

How many policies are being evaluated?

A single audit file is a container of one or more policies that the file content scans will evaluate. While it is tempting to "shoot the works" and add a bunch of audit files to a scan, it is also a hindrance that can suffer performance impact.

For each file that is found as a target to be evaluated, that file has to be compared against each policy that was added to understand if the file applies to the policy and if the content should be evaluated.

It is beneficial to select audits that are targeted to what you are evaluating.

Can an agent be used?

One of the largest bottle necks for file content scanning is the network communication and bandwidth. If the targets that are being scanned are able to have a Tenable Nessus Agent installed, then installing and using the agent for file content scanning will drastically speed up the scanning process. If agent scanning is not available in your environment, the Powershell File Enumeration would be another good option to reduce network traffic.