Last updated at Thu, 31 Aug 2017 14:17:17 GMT

Rapid7 has made it a priority to support security industry standards, including the Open Vulnerability and Assessment Language (OVAL).  Those of you who use Nexpose to measure policy compliance, either by using the built-in CIS, DISA, and USGCB policies, or by writing your own custom policies, are using OVAL for these policies.

A decision by the National Institute of Standards and Technology (NIST) has made it necessary for us to make changes in our OVAL implementation.  These changes affect policies written for Microsoft Windows systems.  Previously, Nexpose would convert case-sensitive comparators for certain objects and states to case-insensitive comparators, in order to support the case-insensitive behaviour of Windows.  This was a convenient function when uploading third-party policies, which would sometimes be written with default case-sensitive comparators, leading to false positives.

In order to comply with NIST's requirements for OVAL, it will now be necessary to honour the comparators exactly as written, meaning that comparators will now default to being case-sensitive on Windows systems.  This will not have any effect on policies that have already been imported into Nexpose, nor will it have any effect on the current set of built-in policies.

However, this change will affect:

  1. Newly uploaded custom policies
  2. Custom policies created by copying built-in content
  3. Custom policies created by copying previously uploaded custom policies

As an example, consider the following registry object:

<registry_object xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"   
id="oval:nist.validation.winRegistry:obj:19" version="1">  
    <hive>HKEY_LOCAL_MACHINE</hive>  
    <key>SOFTWARE\Microsoft\MSMQ\SCAP_Validation_Tests\win_reg\exists</key>  
    <name operation="equals">vQwordLE</name>  
</registry_object>

The name element in that object has an 'operation = "equals"' attribute.  Previously, this attribute would have been automatically converted to be 'operation = "case insensitive equals"'.  With the new change, this will no longer be the case: there will be no conversion, and the attribute will remain as 'operation = "equals"'.  This is also the default behaviour: when no operation is specified, the operation will be "equals".

As a result, a policy rule that would have passed regardless of whether the name field in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\SCAP_Validation_Test\win_reg\exists were "vqwordle", or "VQWORDLE", or "vQwordLE", will now only pass when the value in the name field is exactly "vQwordLE".

To change the behaviour of the object to match its previous behaviour, you would need to change:

<name operation="equals">vQwordLE</name>

to be:

<name operation="case insensitive equals">vQwordLE</name>

The following objects and states will be affected by this change:

  • accesstoken_object, accesstoken_state
  • environmentvariable_object, environmentvariable_state
  • environmentvariable58_object, environmentvariable58_state
  • fileauditedpermissions_object, fileauditedpermissions_state
  • fileauditedpermissions53_object, fileauditedpermissions53_state
  • fileeffectiverights_object, fileeffectiverights_state
  • fileeffectiverights53_object, fileeffectiverights53_state
  • file_object, file_state
  • group_object, group_state
  • registry_object, registry_state
  • sid_sid_object, sid_sid_state
  • sid_object, sid_state
  • user_object, user_state

Depending on your requirements, you may need to rewrite your custom policies to reflect these changes.  It will also be necessary to evaluate the functionality of any new policies that you create by copying previously imported policies.  We regret that this change might be disruptive, but it is necessary to ensure full compatibility with industry security standards.