Host Audit Data Analysis

When scanning assets with Tenable Audit files, the finding returned is slightly different than a vulnerability finding. The first step in analyzing audit results is to first understand the source.

Key Data Fields

The audit file is an XML like file, which consists of several configuration checks. When the Tenable Research team examines the various benchmarks, for example Center for Internet Security (CIS), each CIS benchmark is broken into profiles (Level 1 and Level 2) and each profile is an item. The Tenable Audit files convert the “items” into XML like elements <item> or <custom_item> which then becomes an audit check name in Tenable Vulnerability Management or Tenable Security Center. From this point forward, <item> or <custom_item> in audit files are referred to as an audit check name, and the presence of an audit check name on an asset is called a finding.

More information on audit files can be found here:

The description line becomes the audit check name, the other key field is the “reference” line, also known as the Cross Reference or XREF. The XREF is a mapping of this respective check to several compliance standards and benchmarks. Customers are able to search using the XREF in different methods based on the product, see below:

Product Search Term

Example
t.io

800-53 ACCESS CONTROL

 Compliance Framework= 800*53 Compliance Family= ACCESS CONTROL
t.sc 800-53 ACCESS CONTROL Cross Reference = 800-53|AC*

To help customers verify the audit checks authority in the benchmark, the “see_also” field provides the location a customer can download the benchmark from the provider. This benchmark is used to consolidate audit checks by the correct benchmark and version.

https://workbench.cisecurity.org/files/2449

When an asset is scanned using an audit file, and a check becomes a finding, the finding is returned in one of the following states: PASSED, FAILED, ERROR, WARNING. The state is converted into a severity level for use with Tenable Security Center, and for Tenable Vulnerability Management the state is retained. The color coding for the state coincides with the color for the severity levels as displayed on the following table.

State Tenable Security Center Severity

Tenable Vulnerability Management State

 Descriptions
PASSED

Informational

 Passed The audit check was within the tested parameters.
FAILED High Failed The audit check was not within the tested parameters.
ERROR Medium Error The audit check is not supported on the asset.
WARNING Medium Warning The audit check was successful, however compliance cannot be determined and needs to be reviewed manually.

Data Fields Explained

Now that we understand the key fields used for analysis there are a few other fields used to enhance search behaviors and are commonly used in the compliance dashboards and reports. In this section a detailed review of all the fields and how they work together are provided.

Audit File

The name of the Audit file the scanner used to perform the audit. Audit files are XML-based text files that contain the specific configuration, file permission, and access control tests to be performed. The audit file can be customized and should be changed if the customer edits the audit file. For example if the audit flee provided by Tenable is named “CIS_AlmaLinux_OS_8_Server_v3.0.0_L1.audit” and the customer edits the parameters of the audit file, then the customer might change the name to be “ACME-Mar24-CIS_AlmaLinux_OS_8_Server_v3.0.0_L1.audit." This name suggests that the ACME corp added this audit file in March of 2024. In doing this, analysts are able to easily find the audit files edited by the organization and apply the filters correctly.

While changing the name of an audit file is not required, here is helpful information to consider if choosing to do so. Note that the names of the audit file are not to be confused with benchmark. Tenable names the audit files to coincide with the benchmark, but the name is just a name. When choosing the name for the audit files, consider the operating system the audit file is intended for, the benchmark (including the version) used to create the audit file, and the date the audit file is added. Note that audit files that are custom, meaning imported by the customer, are not updated and therefore need to be maintained.

Tenable Vulnerability Management:

  • Using the audit file name is supported in both the group-by options in the widget and in the filters.

  • In the Bar Chart example, the bars represent the count of findings by the respective audit file. Other factors for example state, date, or etc. are not included.

Tenable Security Center:

  • Analysis using an Audit Files is only available in a filter.

  • Organizations can use this filter to focus the results using charts and tables, however the audit file is not displayed, only the display columns based on the selected tool.

  • Dashboard component documentation is found here.

Audit Check Name

The name Tenable assigned to the audit, as previously mentioned see figure 1, is the value in the description field in the audit file. In some cases, the compliance control may be listed as the prefix within the name. This is often combined with a nomenclature from the benchmark. In CIS benchmark, the name is prefixed with a number and DISA uses the STIG-ID. Just note that regardless of the benchmark used to create the audit file, review the descriptions that are provided in the audit file for a list of possible audit check names.

Using grep or similar tool, the user can search audit files and return all the descriptions which are converted into the audit check name: grep -E '\s+description(\s):' *.audit

  • CIS Example: "4.5.3.3 Ensure default user umask is configured"

  • DISA Example : "WG050 W22 - The web server service password(s) must be entrusted to the SA or Web Manager."

Tenable Vulnerability Management:

  • The audit check name is available using group by and filtering similar to the audit file above.

  • Use the “*” or wild card and the end of the string to search for all the audit check names that match the pre-fixed pattern. All the patterns below find audit check names with the relative pattern. Note, when using the * as the first character in the search you will match any pattern. The samples below match each of the examples shown above.

Pattern Result
4.5.*

Strings that begin with 4 <period> 5 <period> and followed by any character
WG* Strings that begin with WG (case insensitive)
*W22* String that begins with any character but contain W22 within the string, followed by any other characters
W*W22* Strings that begin with “W” and contain W22

Tenable Security Center:

  • Audit Check Names become the plugin name. When an audit file is imported and used in a scan or filter, Tenable Security Center creates plugins for each of the <items> or <custom_items> in the audit file. The plugins have an ID > 1,000,000 and the plugin ID will be unique to the installation. Also note, if an audit file is updated and re-added, new plugins are created, this is another reason why it's often a good idea to name the audit file during import.

  • The plugin name field supports regex patterns allowing for very complex and flexible pattern matching, here are some examples:

Pattern Result
^4\.5.*

Strings that begin with 4 <period> 5 <period> and followed by any character
^[Ww][Gg].* Strings that begin with WG (case sensitive, but account for both upper and lower case)
^.*[Ww]22.* String that begin with any character but contain W22 within the string, followed by any other characters
^[Ww].*[Ww]22.* Strings that begin with “W” and contain W22

Benchmark

Benchmarks are published best practices released from source authorities, such as Center for Internet Security (CIS), United States Defense Information Systems Agency (DISA), and Microsoft. This filter provides a list of the supported benchmarks and the version of the benchmark. Tenable used the URL of the Benchmark to distinguish to which benchmark the audit file is mapped. The URL is stored in the SEE_ALSO element found in the audit file.

  • CIS: https://workbench.cisecurity.org/benchmarks/12695

  • DISA: https://iasecontent.disa.mil/stigs/zip/U_Apache_2-2_WIN_V1R13_STIG.zip

  • Microsoft: https://blogs.technet.microsoft.com/secguide/2018/04/30/security-baseline-for-windows-10-april-2018-update-v1803-final

CIS Benchmarks are linked directly with See Also URL, in this example CIS Windows Server 2016 version 2.0.0 can be accessed via https://workbench.cisecurity.org/benchmarks/12695. Each of the audit files that support the benchmark are focused on the different role or functions of the asset. In this example the DC is the domain controller, and MS is a member server. The L1 and L2 describing the level 1 or level 2 checks depicted in the benchmark. To obtain full coverage with a benchmark all audit files from the specific role needs to be added to the targeted scan. Be careful not to scan a domain controller with a member server audit file, and there are different checks and some coverage could be mis-represented. This benchmark is covered by 6 audit files:

  • CIS_Microsoft_Windows_Server_2016_Benchmark_v2.0.0_DC_NG.audit

  • CIS_Microsoft_Windows_Server_2016_Benchmark_v2.0.0_L1_DC.audit

  • CIS_Microsoft_Windows_Server_2016_Benchmark_v2.0.0_L1_MS.audit

  • CIS_Microsoft_Windows_Server_2016_Benchmark_v2.0.0_L2_DC.audit

  • CIS_Microsoft_Windows_Server_2016_Benchmark_v2.0.0_L2_MS.audit

  • CIS_Microsoft_Windows_Server_2016_Benchmark_v2.0.0_MS_NG.audit

For a DISA STIG, there can be situations where there are more that one version of an Audit file that makes the STIG. For example, DISA STIG Apache Server 2.4 Unix in the URL https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_Apache_Server_2-4_Unix_Y23M07_STIG.zip, contains several version files in version 2.4.0 and 2.6.0. Listed below are the audit files that comprise the STIG, much like the aforementioned CIS benchmark there can be different roles and the appropriate audit files should be deployed to targeted assets.

  • DISA_STIG_Apache_Server-2.4_Unix_v2r6.audit

  • DISA_STIG_Apache_Server-2.4_Unix_v2r6_Middleware.audit

  • DISA_STIG_Apache_Site-2.4_Unix_v2r4.audit

  • DISA_STIG_Apache_Site-2.4_Unix_v2r4_Middleware.audit"

After scanning with appropriate audit files here are examples on how to find the relevant data.

Tenable Vulnerability Management:

  • In this field the benchmark name and version are combined into one string. Using regular search terms, the search can be limited to only the desired content.

    Pattern Result
    CIS *

    Strings that begin with CIS<space> followed by any other character.
    CIS P*9* Strings that begin with CIS<space>P followed by any other character but must contain a 9 in the string. Ex: CIS Palo Alto Firewall 9 v1.1.0
    *v1.0.0* Strings that begin with any character but contain v1.0.0 within the string, followed by any other characters

  • For benchmarks that are no longer supported by Tenable, the “Deprecated <prefix> Benchmark” is available

    • Example: Deprecated CIS Benchmark

  • DISA_STIG_Apache_Site-2.4_Unix_v2r4.audit

    • CIS, DISA, MSCT, NetApp, TNS

  • Custom audit files are also supported however the benchmark name will be “Custom”

Tenable Security Center:

  • For notes on how to search for specific elements in Security Center, review this section Tenable Security Center Compliance Elements:

  • To locate the benchmark using the Vulnerability text for contains “cisecurity” or other relevant string, and then copy the link shown under the See Also, as shown below.

  • When the “cisecurity.org” link is copied, this would be the string that is collected.

    • https://workbench.cisecurity.org/benchmarks/12695

  • The Vulnerability Test filter example: <cm:compliance-see-also>https://workbench.cisecurity.org/benchmarks/12695</cm:compliance-see-also>

    • https://workbench.cisecurity.org/benchmarks/12695

  • Add the string with <cm:compliance-see-also>URL-HERE</cm:compliance-see-also> to the Vulnerability Text field.

Benchmark Specification Name

The benchmark name is the same as previously described but does not contain the version. Using only the benchmark name in the search merges the data collected using all versions of the respective benchmark.

After scanning with appropriate audit files here are examples on how to find the relevant data.

Tenable Vulnerability Management:

  • Tenable Vulnerability management supports widgets using a “Group By” using the Benchmark Name, as shown below, the chart quickly shows the benchmarks in use, allowing for more filtering options.

  • Note that when a benchmark becomes deprecated and is no longer supported by the benchmark name is changed to Depreciated <TYPE> Tenable. By adding the filter Benchmark Specification Name = “*deprecated*”, you can see the use check found with deprecated audit files.

Tenable Security Center:

  • Use the same approach as before with Tenable Security Center, use the Vulnerability Text field and add the Benchmark Name.

  • <cm:compliance-benchmark-name>some text here</cm:compliance-benchmark-name>

Benchmark Version

The benchmark version should only be used with the Benchmark Specification Name filters, and the version is unique to each benchmark and provider. For example, version 2.0.0 on a CIS Benchmark could be the latest version on one benchmark and a deprecated version on another.

Tenable Vulnerability Management:

  • Use a string with or without wildcards just as other text-based search patterns

Tenable Security Center:

  • Use the same approach as before with Tenable Security Center, use the Vulnerability Text field and add the Benchmark Version.

  • Note that if you search using a regex to combine the benchmark name and version, the regex pattern must include the match for the version to come before the name and after the name. The order of the CM elements in the Vulnerability text is not consistent, so both possible patterns should be searched.

  • <cm:compliance-benchmark-version>some text here</cm:compliance-benchmark-version>

Compliance Framework

Tenable audits configuration compliance with a variety of standards including GDPR, ISO 27000, HIPAA, NIST 800-53, PCI DSS, and so on. This filter allows searching based on the respective framework.

Tenable Vulnerability Management:

  • Creating a custom widget using a table or bar chart, you can quickly see the number of compliance frameworks identified by the audit files used in the scans.

  • By adding other fields as filters, such as audit file, result, or benchmark, you are able to focus on the data returned.

Tenable Security Center:

  • The “Maintaining Data Protection Controls” Cyber Exposure Study has a good section that describes how to use the Cross Reference field.

    • /cyber-exposure-studies/data-protection/Content/VerifyingDataProtectionControls.htm

  • Tenable audit checks contain a reference field that points to specific controls in a standard (ISO 27001), framework (NIST Cybersecurity Framework), or regulation (HIPAA) and is used by nearly all plugins. Any external reference can be identified using the Cross References field. References can be used to search or filter in Tenable Security Center. For example, the following References define requirements for the encryption of data at rest:

    • 800-171 - 3.13.16

    • 800-53 - SC-28

  • Searching with the Cross Reference Field as described in the study allows for mapping controls to the respective benchmarks. In the example below, the search pattern is 800-53|* for all audit checks for the framework NIST 800-53r4. By clicking on the Plugin ID, a window on the right is displayed showing plugin details, including the cross references.

  • As mentioned in the Key Data Fields section and “Maintaining Data Protection Controls” Cyber Exposure Study, the search needs to be the full cross reference, as shown below.

Compliance Family Name

There are a series of designations within compliance frameworks that Tenable calls control. For example: ISO/IEC-27001:A.12.4.1, or CSF:DE.CM-1. This filter groups the controls into families for easier and more efficient queries. For example: A12 - Operations security or CSF:Detect. Use this filter in conjunction with the Compliance Framework filter.

Tenable Vulnerability Management:

  • Listed in this section is a list of the supported frameworks and the corresponding families. Much like the Compliance Control filters, the Compliance Family Name should be used with framework filters.

  • This example shows the benefit of combining the various aspects of the compliance filtering, and illustrates how Tenable Vulnerability Management is able to track the compliance with several frameworks and benchmarks at the same time.

Tenable Security Center:

  • As mentioned in the Key Data Fields section and “Maintaining Data Protection Controls” Cyber Exposure Study, searching for families is accomplished by using wildcard patterns in the Cross Reference search.

  • In this search example we are using “ISO/IEC-27001|A.12*” to search for the family ISO/IEC-27001: A12 - Operations security.

/vulnerability-management/Content/Explore/Findings/FindingsFilters.htm