Version 2 of Windows Compliance Checks Available for Testing

Direct Feed and Security Center customers who use Nessus to perform configuration audits of their Windows computers can now beta test an upgrade of this technology. The upgrade provides enhanced auditing features, increased speed and is Tenable's foundation for compliance with NIST SCAP auditing requirements when auditing Microsoft platforms. This blog entry discusses the new features of the upcoming release, the release schedule for this update, how customers can participate in the beta test today.

Scope and Release Schedule

Plugin #21156 (named the compliance_check.nbin plugin) is used by Nessus Direct Feed and Security Center customers to audit the configuration of Windows systems. Version 1 of this plugin has been available for over a year. Version 2 adds many new features and is available immediately for beta testing.

Current Direct Feed or Security Center users are not required to take any action right now, however, on January 15th, 2008, version 2 of the compliance_check.nbin will be released for Direct Feed and Security Center customers. This will automatically upgrade the compliance_check.nbin plugin to version 2. At that time, any existing version 1 audit policy files will need to be replaced with version 2 audit policy files. Tenable made every effort to maintain backwards compatibility, however, to achieve 100% compliance with content generated from NIST SCAP XCCDF policies, several new functions were required.

All existing Windows configuration audit polices will be re-released with support for version 2. These include a variety of PCI, NIST SCAP and CIS polices. At the Tenable Customer Support Portal, all Windows policies are now available under both version 1 and version 2. Version 1 policies should continue to be used in production, and the version 2 policies are available for beta testing. All version 2 polices have a _v2 extension on them along with the same root name as before. 

New Audit Features in Version 2

New check_type header

All version 2 Windows audit policies now contain the following header information:

<check_type:"Windows" version:"2">

Previously, version 1 policies started out with:

<check_type:"Windows">

If you have written a custom audit policy, in order to run it under the new beta plugin, the 'check_type' value will need to specify version 2 as shown above.

As part of this beta, a new version of the i2a tool (version 2.0.0) is also available from the customer support portal. It generates version 2 compliant audit policies based on existing Windows GPO .inf files.

Clearer logic symbols

Previously in version 1 of the compliance checks, the pipe symbol "|", was used to delineate lists of potential values. In some checks, this symbol functioned like an AND and in others, an OR. In version 2.0, checks make use of the following conditional functions:

•   && - conditional AND
•   || - conditional OR
•   |  - Binary OR

A binary 'OR' is used for comparing windows access control lists.

If you have written custom policies using the POLICY_MULTI_TEXT or USER_RIGHTS_POLICY audits, under version 2, they should make use of the "double and" separator instead of the single pipe separator. In other words, replace all of your '|' characters for POLICY_MULTI_TEXT or USER_RIGHTS_POLICY audits with '&&'.

For example, here is a version 2 and version 1 audit section which looks for a combination of values for a particular registry setting:

version 2 format:

<custom_item>
type: REGISTRY_SETTING
description: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes"
value_type: POLICY_MULTI_TEXT
value_data: "COMNAP"&&"COMNODE"&&"SQL\QUERY"&&"SPOOLSS"&&"LLSRPC"&&"browser"
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
</item>

version 1 format:

<custom_item>
type: REGISTRY_SETTING
description: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes"
value_type: POLICY_MULTI_TEXT
value_data: "COMNAP" | "COMNODE" | "SQL\QUERY" | "SPOOLSS"|"LLSRPC"|"browser"
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
</item>

Forced Reporting

Audit polices can now be forced to output a specific result by making use of the 'report' keyword. Report types of PASSED, FAILED and WARNING can be used. Below is an example policy:

<report type: "WARNING">
description: "Audit 103-a requires a physical inspection of the pod bay doors Hal"
</report>

The text inside the 'description' would always be displayed in the report.

This type of reporting is useful if you wish to inform an auditor that an actual check being performed by Nessus can't be accomplished. For example, perhaps there is a requirement to determine that a specific system has been physically secured and we wish to inform the auditor to perform the check or inspection manually. This type of report is also useful if the specific type of audit required to be performed by Nessus has not been determined with an OVAL check.

"if, then and else" Logic

A powerful new feature of the version 2 compliance checks for Windows is the ability to have conditional tests based on existing conditions. The logic implements OR and AND logic and has the following type of structure:

<if>
  <condition type:"and/or">
      < Insert your audit here >
  </condition>
<then>
     < Insert your audit here >
</then>
<else>
     < Insert your audit here >
</else>
</if>

Below is an example that audits the password policy. Since the 'and' type is used, for this policy to pass the audit, both custom items would need to pass. This example tests for a very odd combination of valid password history policies to illustrate how sophisticated test logic can be implemented.

<if>
   <condition type:"and">

     <custom_item>
       type: PASSWORD_POLICY
       description: "2.2.2.5 Password History: 24 passwords remembered"
       value_type: POLICY_DWORD
       value_data: [22..MAX] || 20
       password_policy: ENFORCE_PASSWORD_HISTORY
     </item>

     <custom_item>
       type: PASSWORD_POLICY
       description: "2.2.2.5 Password History: 24 passwords remembered"
       value_type: POLICY_DWORD
       value_data: 18 || [4..24]
       password_policy: ENFORCE_PASSWORD_HISTORY
     </item>

   </condition>

   <then>

     <report type:"PASSED">
       description: "Password policy passed"
     </report>

   </then>

   <else>

     <report type:"FAILED">
       description: "Password policy failed"
     </report>

   </else>

</if>

The if/then/else logic is extremely powerful. In the above example, only the new 'report' type was shown, but the if/then/else structure supports performing additional audits within the 'else' clauses. Within a condition, nested if/then/else clauses can also be used. A more complex example is shown below:

<if>
<condition type:"and">
<custom_item>
    type: CHECK_ACCOUNT
    description: "Accounts: Rename Administrator account"
    value_type: POLICY_TEXT
    value_data: "Administrator"
    account_type: ADMINISTRATOR_ACCOUNT
    check_type: CHECK_NOT_EQUAL
</item>
</condition>

<then>
<report type:"PASSED">
   description: "Administrator account policy passed"
</report>
</then>

<else>

<if>
<condition type:"or">
<item>
   name: "Minimum password age"
   value: [1..30]
</item>
<custom_item>
   type: PASSWORD_POLICY
   description: "Password Policy setting"
   value_type: POLICY_DWORD
   value_data: 1
   password_policy: COMPLEXITY_REQUIREMENTS
</custom_item>
</condition>
<then>
<report type:"PASSED">
   description: "Administrator account policy passed"
</report>
</then>
<else>
<report type:"FAILED">
   description: "Administrator account policy failed"
</report>
</else>
</if>

</else>
</if>

This example implements the logic, if the Administrator account has not been renamed, then audit that the minimum password age is 30 or less. This audit policy would pass if the administrator account has been renamed regardless of the password policy and would only test the password age policy if the administrator account hadn't been renamed.

'info' field for each check

A new function that can be used to label each audit field with one or more external references is also available. For example, this field will be used to place references from NIST CCE tags as well as CIS specific audit requirements. These external references are printed out in the final audit performed by Nessus and will be displayed in the Nessus report, or through the Security Center's user interface.

The field is named 'info'. Below is an example password audit policy that has been augmented to list references to a fictitious corporate policy:

     <custom_item>
       type: PASSWORD_POLICY
       description: "Password History: 24 passwords remembered"
       value_type: POLICY_DWORD
       value_data: [22..MAX] || 20
       password_policy: ENFORCE_PASSWORD_HISTORY
       info: "Corporate Policy 102-A"
     </item>

If multiple policy references are required for a single audit, the string specified by the 'info' keyword can make use of the '\n' separator to specify multiple strings. For example, consider the following audit:

<custom_item>
type: CHECK_ACCOUNT
description: "Accounts: Rename Administrator account"
value_type: POLICY_TEXT
value_data: "Administrator"
account_type: ADMINISTRATOR_ACCOUNT
check_type: CHECK_NOT_EQUAL
info: 'Ron Gula Mambo Number 5\nCCE-60\nTenable Best Practices Policy 1005-a'
</item>

When run with the nasl command line tool, this audit function produces the following output:

[root@kingghidora ~]# /opt/nessus/bin/nasl -t 192.168.20.16 ./compliance_check.nbin

            Windows Compliance Checks, version 2.0.0(Beta2)

Which file contains your security policy : ./test_v2.audit
SMB login : Administrator
SMB password :
SMB domain (optional) :
"Accounts: Rename Administrator account": [FAILED]

Ron Gula Mambo Number 5
CCE-60
Tenable Best Practices Policy 1005-a

Remote value: "Administrator"
Policy value: "administrator"

'check_type' option

Audit functions can now make use of a field named 'check_type' which implements a variety of flexible logic to test the results of an audit. Below is an example audit to check to make sure that the account name "Guest" does not exist for any Guest account.

<custom_item>
  type: CHECK_ACCOUNT
  description: "Accounts: Rename guest account"
  value_type: POLICY_TEXT
  value_data: "Guest"
  account_type: GUEST_ACCOUNT
  check_type: CHECK_NOT_EQUAL
</item>

If any other value besides "Guest" is present, the test will pass. If "Guest" is found, the audit will fail.

The 'check_type' option can accept the following values which implements the following types of logic:

• CHECK_EQUAL compare the remote value against the policy value (default if check_type is missing)
• CHECK_EQUAL_ANY checks that each element of 'value_data' is at least present once in the system list.
• CHECK_NOT_EQUAL checks the remote value is different than the policy value
• CHECK_GREATER_THAN checks the remote value is greater than the policy value
• CHECK_GREATER_THAN_OR_EQUAL checks the remote value is greater or equal than the policy value
• CHECK_LESS_THAN checks the remote value is less than the policy value
• CHECK_LESS_THAN_OR_EQUAL checks the remote value is less or equal than the policy value
• CHECK_REGEX checks that the remote value match the regular expression in the policy value (only works with POLICY_TEXT and POLICY_MULTI_TEXT)
• CHECK_SUBSET checks that the remote access control list (ACL) is a subset of the policy ACL. (This check only works with ACLs)

The following custom item checks that 'lsarpc' is in the 'NullSessionPipes' list.

<custom_item>
description: "CHECK_EQUAL_ANY"
type: REGISTRY_SETTING
value_type: POLICY_MULTI_TEXT
value_data: 'lsarpc'
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
check_type: CHECK_EQUAL_ANY
</item>

The following custom item checks that 'lsarpc' and 'browser' are in the 'NullSessionPipes' list.

<custom_item>
description: "CHECK_EQUAL_ANY"
type: REGISTRY_SETTING
value_type: POLICY_MULTI_TEXT
value_data: 'lsarpc' && 'browser'
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
check_type: CHECK_EQUAL_ANY
</item>

Support for Signed, Unsigned and Hexadecimal Numbers

Numbers can now be specified with plus or minus to indicated their 'sign'. Number can also be specified as hexadecimal values. Hex and signs can be combined. The following are valid examples (without the corresponding label in parentheses) within a REGISTRY_SETTING audit for a POLICY_DWORD:

value_data: -1  (signed)
value_data: +10  (signed)
value_data: 10 (unsigned)
value_data: 2401649476 (unsigned)
value_data: [MIN..+10]  (signed range)
value_data: [20..MAX] (unsigned range)
value_data: 0x800010AB (unsigned hex)
value_data: -0x10 (signed hex)

Value data can also make use of parentheses to specify ranges of valid data values. For example, the example below  would accept valid data in non-discrete ranges:

value_data: ( ([20..MAX] || 18) && (32 || 18) )

Minor Features and Differences

The following is a list of other features and differences between version 1 and version 2:

• Performance Increase on Low Latency Networks - The new logic implemented in this update is more efficient. In some lower latency networks, a speed increase of more than two times has been observed.
• Strings can be specified with single or double quotes - Escaped characters such as \n, \r, \\, \', \t, \", ... are only evaluated in strings specified with single quotes.
• USER_RIGHTS_POLICY is now case sensitive - In all of the new version 2 audit policies, the USER_RIGHTS_POLICY has been updated to the correct string and case. For example, previously, many polices included a test for "setcbprivilege" and now with version 2, the string SeTcbPrivilege is used without any quotes.
• REGISTRY_SETTING 'reg_type' field - This field is now automatically converted to the given 'value_type' policy of the audit.

Obtaining and Testing the new compliance_check.nbin beta Plugin

To obtain the new compliance_check.nbin file, log into the Tenable Customer Support Portal, click on the 'Downloads' button, and then click on the 'Download Compliance Checks Tools' button. On this page is a link for the beta of the new plugin as well as version 2.0.0 of the i2a tool.

On UNIX systems, you can download the plugin to someplace other than the Nessus plugins directory and use the nasl command line tool to test it out. If you are not familiar with the nasl command line tool, we've blogged about its usage previously before, including an example of how to perform tests with Direct Feed auditing files.

Here is an example running the new plugin with an older, incompatible version 1 policy.

[root@kingghidora ~]# /opt/nessus/bin/nasl -t 192.168.20.16 ./compliance_check.nbin

            Windows Compliance Checks, version 2.0.0(Beta1)

Which file contains your security policy : ./FDCC_Desktops_v90.audit
SMB login : Administrator
SMB password :
SMB domain (optional) :
Parse error line 99 - unknown token 'setcbprivilege'

This older audit file failed because previously, the USER_RIGHTS_POLICY was case insensitive. In version 2, the case is important. The older version 1 policy had a line which tested the string "setcbprivilege' whereas in version 2, the more specific 'SeTcbPrivilege' has been specified.

Here is a second, truncated example running version 2 of the same policy:

[root@kingghidora ~]# /opt/nessus/bin/nasl -t 192.168.20.16 ./compliance_check.nbin

            Windows Compliance Checks, version 2.0.0(Beta1)

Which file contains your security policy : FDCC_Desktops_v90_v2.audit
SMB login : Administrator
SMB password :
SMB domain (optional) :
"Minimum password age": [FAILED]

Remote value: 0
Policy value: [1..MAX]

Testing with Nessus Direct Feed Scanners

If you would like to replace your compliance_check.nbin in your Nessus plugins directory, you can make use of the new beta directly from Nessus. Simply move the current compliance_check.nbin file to a safe place to be able to revert to it, and replace it with the new compliance_check.nbin file. Any scan policies you test with should be performed with version 2 polices.

If your Nessus scanner is set to update plugins, keep in mind that the compliance_check.nbin file will be overwritten with the older version 1 plugin. Once the new plugin is in place, on Windows systems, the plugins should be rebuilt by running the build.exe command. On UNIX systems, a Nessus service restart will work, or it can be forced from the command line with the command:

/opt/nessus/sbin/nessusd -t -D

Testing with the Security Center

If you place the compliance_check.nbin file in your /opt/sc3/admin/nasl directory, the Security Center will push this plugin out to all of your managed Nessus scanners within the next hour. If you are impatient, you can force this by placing the plugin and then restarting the Security Center.

From within the Security Center, you should place any desired version 2 test polices also in the /opt/sc3/admin/nasl directory and then perform your testing.

Keep in mind that if the Security Center performs a plugin update during its nightly process, it will obtain the older version 1 of this plugin and will overwrite it on each of your managed Nessus scanners.

Providing Feedback

We appreciate any positive or negative feedback, as well as bug reports. Tenable customers should send email to [email protected] or open up a ticket through the support portal if any issues have been found.

Any updates to the available beta will be posted on the support portal, as well as the Nessus Compliance RSS feed.