OVALProject / Sandbox

The OVAL Language Sandbox
http://oval.mitre.org/language/sandbox.html
44 stars 36 forks source link

add capability: win-ntuser-test #69

Closed tannerdc closed 8 years ago

tannerdc commented 11 years ago

Currently there exists content with OVAL Registry tests that require checking information located in the HKEY_CURRENT_USER (HKCU) hive. However, unless the tool used to run these tests is written in such a way as to check all of the user accounts on the server or workstation only the user running the scanning program will be tested for compliance. OVAL does not currently include any requirements for determining which users should be evaluated with HKCU checks. This can lead to devices reporting compliance to OVAL tests when in fact they should have failed the tests. This is a well-known limitation in OVAL. To combat this problem, we are proposing a new OVAL NTUser Test that should be used in place of any Registry tests that require checking the HKCU hive. This proposal is consistent with the previous discussion of this issue at security automation developer days . It is a standardization of a proprietary checking process that has been in operational use on a federal government network for several years.

NTUSER_OBJECT: The object elements included in the ntuser_object are almost identical to those specified in the registry_object. The only change is in the behaviors element.
-behaviors: Optional behaviors similar to win-def:RegistryBehaviors will be required to properly support recursion.
-key (string): Required element from the original win-def:Registry Object. Defined identical to the same element in the registry_object. -name (string): Required element from the original win-def:Registry Object. Defined identical to the same element in the registry_object. -filter: Optional element for reducing the list of objects. Defined identical to the same element in the registry_object. NTUSER_STATE/ITEM: Items marked as new are different from the existing registry_state. Existing items are unchanged from the registry_state. -key (string): This element describes a registry key normally found in the HKCU hive to be tested. Optional. -name (string): This element describes the name of a value of a registry key. If the xsi:nil attribute is set to true, then the name element should not be used in analysis. Optional. -sid (string) (new): SID of the ntuser.dat file owner. Optional. Defined in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. -username (string) (new): The username of the ntuser.dat file owner in the form of domain\user or machine\user. Optional. -account_type (enum) (new): determines if user account is local or domain account (local or domain). Optional. -logged_on (bool) (new): determines if the user is currently logged on or not. Optional. -enabled (bool) (new): determines if user account is enabled or disabled. Optional. -date_modified (int) (new): last modified date of the ntuser.dat file (this is set when the user last logs off, when the current user makes a setting that writes to the registry, or when the current user locks/unlocks the session). Optional. -filepath (string) (new): The filepath element specifies the absolute path for the ntuser.dat file on the machine. A directory cannot be specified as a filepath. Optional. -last_write_time (int) (new): This entity is the last time that the key or any of its value entries were modified. The value of this entity represents the FILETIME structure which is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC). Last write time can be queried on a key or name. When collecting only information about a registry key the last write time will be the time the key or any of its entries was written to. When collecting only information about a registry name the last write time will be the time the name was written to. See the RegQueryInfoKey function lpftLastWriteTime. Optional. -type: The type entity allows a test to be written against the registry type associated with the specified registry key(s). Please refer to the documentation on the EntityStateRegistryTypeType for more information about the different valid individual types. Optional. -value: The value entity allows a test to be written against the value held within the specified registry key(s). If the value being tested is of type REG_BINARY, then the datatype attribute should be set to 'binary' and the data represented by the value entity should follow the xsd:hexBinary form. (each binary octet is encoded as two hex digits) If the value being tested is of type REG_DWORD or REG_QWORD, then the datatype attribute should be set to 'int' and the value entity should represent the data as an integer. If the value being tested is of type REG_EXPAND_SZ, then the datatype attribute should be set to 'string' and the pre-expanded string should be represented by the value entity. If the value being tested is of type REG_MULTI_SZ, then only a single string (one of the multiple strings) should be tested using the value entity with the datatype attribute set to 'string'. In order to test multiple values, multiple OVAL registry tests should be used. If the specified registry key is of type REG_SZ, then the datatype should be 'string' and the value entity should be a copy of the string. Note that if the intent is to test a version number held in the registry (as a reg_sz) then instead of setting the datatype to 'string', the datatype can be set to 'version'. This allows tools performing the evaluation to know how to perform less than and greater than operations correctly. Optional.

solind commented 8 years ago

We added this in 5.11.