Ionut Pruteanu

Not so straight-forward results of PC UDCs

Discussion created by Ionut Pruteanu on Jul 11, 2019
Latest reply on Jul 15, 2019 by Hariom Singh

I encountered some strange results when some UDCs were assessed in the PC module:


1) First control:
    .... Ensure that a registry is set to 'Disabled'

> Expected: "equal to 0"
> Actual: "No data found"
    =>> RESULT: Passed


Question: "The logic behind Qualys seems to be the one in which controls are considered PASSED if expected_value is 0 and the registry DOESN'T EXIST, as -indeed- not having set at all a registry that enables a service may be considered as "Disabled". Is this the intended (and documented) way things should work?"


2) Rule:
Ensure "X registry paths' contains no other entries that:
    - 'path_1'
    - 'path_2'
['path_1', 'path_2'] will be treated as a whitelist, so these values do not need to be present in order to accomplish this rule in an assessment.

> Expected: matches ['path_1', 'path_2']
> Actual: table: 1a2b345
    =>> RESULT: Passed
Question: "The actual paths in the registry are a sub-set of the expected ones, so the control should pass. What's that >TABLE< value and how is it computed, in order to use it for automated checks?"


3) Rule:
    Ensure the NullSessionPipes list contains a NULL value.
> Expected: matches []
> Actual:      
    =>> RESULT: Failed
Question: " So, register exists, but has no value defined, which is the default behavior.

However, the control failed. When compared to Rule 1), this approach is not consistent. Do I miss anything here?"