Policy Attribute Checks

Policies are made up of a series of sections and checks. Within those checks you can itemize specific attributes to be scanned as part of the policy's checks. Attribute checks are used to define an expected value or condition of an item, such as a version number or the presence (or absence) of a specific attribute. Then, when the node is scanned you can see whether the configuration item passed or failed the check for that particular condition. The following topic describes each of the attribute checks available to add to a policy. For more information on how to add attribute checks to an existing policy, see Attribute Checks.

Each attribute check has a different way of testing and defining the desired state of a configuration item. Below is a list of the available attribute check types and how they work.

Exact Match

The item to be checked must contain an exact match for the Expected attribute value (defined in the Expected field) otherwise the check will fail.

Note: The Semantic Equality and Case Insensitive fields are only displayed for certain attribute types, such as .ini and .xml files.

The following examples demonstrate how Guardian verifies whether an attribute string exactly matches a given string:

You can also use this check type for exact matches of version numbers:

Includes

The item to be checked must include the Expected attribute value (defined in the Expected field) otherwise the check will fail.

Note: If there is more than one expected value for the attribute, enter a comma-separated list in the Expected field. All the values entered must be included in order for the check to pass.

The following examples demonstrate how Guardian verifies whether one string is present within an attribute or not:

For example, assume the configuration item is for the members of a local Windows group, you can use this check type to confirm the correct users are accessing the node:

Excludes

The item to be checked must not include the Expected attribute value (defined in the Expected field) otherwise the check will fail.

Note: If there is more than one expected value for the attribute, enter a comma-separated list in the Expected field. None of the values entered may be present in order for the check to pass.

The following examples demonstrate how Guardian verifies whether one string is not present within an attribute:

For example, assume the configuration item is for the members of a local Windows group, you can use this check type to determine whether users are accessing the node incorrectly:

XPath

Find elements within an XML file (such as a web.config file) to verify that a path exists. Using the Value must be drop-down list, you can specify whether the path should be greater than, equal to, not equal to, or less than the Expected value. If the path does not match the expected value, the check will fail. The value of the element is not scanned as part of this check.

Tip: If you were to add a check for a setting within a file, such as an application's version number, you could use the Value must be settings to define whether the collected value should be greater or less than the current application number.

Assuming that the following attribute value was set in the Expected field:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="webpages:Version" value="3.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <authentication mode="None" />
    <compilation targetFramework="4.5.1" />
    <httpRuntime targetFramework="4.5.1" />
  </system.web>
  <system.webServer>
    <modules>
      <remove name="FormsAuthenticationModule" />
    </modules>
  </system.webServer>
</configuration>

The following examples demonstrate how Guardian would verify whether a path does or does not exist in the above file:

>, >=, <, <=

The item to be checked must be greater than, less than, equal to, etc. the Expected conditions for value attribute otherwise the check will fail. Here, you can specify if the attribute Value must be greater than, equal to, not equal to, or less than the collected value using the drop-down list provided.

The following examples demonstrate how Guardian verifies whether the collected value matches the criteria defined in the attribute check:

Regular Expression

Search for text within an attribute value using a regular expression. Define the criteria for the attribute check using the Expected conditions for value options. Here, you can specify if the attribute Value must be greater than, equal to, not equal to, or less than the collected value using the drop-down list provided.

The following examples demonstrate how Guardian verifies whether the collected value matches the criteria defined in the attribute check:

Regular Expression (Excludes)

Search for text that should not be present within an attribute value using a regular expression. Define the criteria for the attribute check using the Expected conditions for value options. Here, you can specify if the attribute Value must be greater than, equal to, not equal to, or less than the collected value using the drop-down list provided.

The following examples demonstrate how Guardian verifies whether the collected value matches the criteria defined in the attribute check:

Time Comparison

When running a policy check against a date or time, you can specify whether an attribute value should be less or more than the provided date or time (before or after). If the criteria is met, the policy will pass.

Assuming that the current date is 2024-12-05 (December 5th 2024), the following examples demonstrate how Guardian verifies whether the attribute value falls within the next 30 days (for certificate expiration). Any value that falls within the next 30 days fails the attribute check:

Tip: For more examples of the natural language dates you can use for this attribute check type, see the Chronic Project.

Version Comparison

When running a policy check against a version (such as v1.2.3, 4.5.6 or 7.8), you can specify if the attribute value should be less or more than the provided version. If the criteria is met, the policy will pass.

Allow/Deny

Check that a given value either matches any entry in a specified allow list and does not match an entry given in a specified deny list. As part of this check you can specify either only allowed items, only denied items, or a combination of both.

The following examples demonstrate a pass and fail condition for purely 'Allow' elements:

The following examples demonstrate a pass and fail condition for purely 'Deny' elements:

What if the Attribute Value is Missing Completely?

Many of these checks apply a particular condition to a collected value. There are cases, however, where a particular value isn’t collected as part of a node scan. By default, if a value isn’t collected the engine will fail the check as it doesn’t have enough information to perform a proper pass/fail check.

Note: By default, if the value is absent, Guardian fails the check in order to flag the abnormality and instigate corrective action. However, you can amend this function by selecting the Check should pass if attribute is absent check box. If selected, the attribute check will pass if the value is absent.