---
title: "Policy attribute checks"
description: "Every attribute check operator, from exact match to regular expressions."
product: "Guardian"
edition: "Classic"
type: "reference"
url: "https://docs.cloudhouse.com/guardian/classic/control/policies/policy-attribute-checks/"
---
# Policy attribute checks

[Policies](https://docs.cloudhouse.com/guardian/classic/control/policies/policies/index.md) 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. For more information on how to add attribute checks to an existing policy, see [Attribute Checks](https://docs.cloudhouse.com/guardian/classic/control/policies/build-custom-policy/index.md#attribute-checks).

Applies to: `Guardian Classic`

![Policy attribute checks](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/policy-attribute-checks.png)

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.

![Exact match](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/exact-match.png)

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `C:\Program Files\Guardian\Guardian.exe` | `C:\Program Files\Guardian\Guardian.exe` | `Pass` |
| `C:\Program Files (x86)\Guardian\Guardian.exe` | `C:\Program Files\Guardian\Guardian.exe` | `Fail` |

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `10.1.0` | `10.1.0` | `Pass` |
| `10.1.0-ubuntu` | `10.1.0` | `Fail` |

## 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.

![Includes](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/includes.png)

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `enable_secure_cookied=true` | `enable_secure_cookied=true; enable_httponly_cookied=true` | `Pass` |
| `enable_secure_cookied=true` | `enable_httponly_cookied=true` | `Fail` |

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:

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `Administrator, Guest` | `["Administrator","Guest","User1"]` | `Pass` |
| `Administrator, User2` | `["Administrator","Guest","User1"]` | `Fail` |

## 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.

![Excludes](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/excludes.png)

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `secret_git_password=UpGu4rd` | `secret_git_password=<dev to fill in>` | `Pass` |
| `secret_git_password=UpGu4rd` | `secret_git_password=UpGu4rd` | `Fail` |

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:

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `User2` | `["Administrator","Guest","User1"]` | `Pass` |
| `Administrator, User1` | `["Administrator","Guest","User1"]` | `Fail` |

## 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.

![Xpath](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/xpath.png)

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:

`configuration/system.web/compilation/@targetFramework`
:   `Pass`

`configuration/system.web/compilation/@debug`
:   `Fail`

## >, >=, <, <=

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.

![Greater lesser than](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/greater-lesser-than.png)

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `< 1000` | `100` | `Pass` |
| `1000` | `1200` | `Fail` |

## 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.

![Regex](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/regex.png)

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `^.+\.yml$` | `C:\Program Files\Guardian\.upguard\upguard.yml` | `Pass` |
| `^.+\.txt$` | `C:\Program Files\Guardian\.upguard\upguard.yml` | `Fail` |

## 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.

![Regex excludes](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/regex-excludes.png)

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `^.+\.txt$` | `C:\Program Files\Guardian\.upguard\upguard.yml` | `Pass` |
| `^.+\.yml$` | `C:\Program Files\Guardian\.upguard\upguard.yml` | `Fail` |

## 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.

![Time comparison](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/time-comparison.png)

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](https://github.com/mojombo/chronic#examples).

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `< in 30 days` | `2027-0l-01` | `Pass` |
| `< in 30 days` | `2025-01-01` | `Fail` |

## 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.

![Version comparison](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/version-comparison.png)

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `< 11.0` | `10.1.2` | `Pass` |
| `> 11.0` | `10.1.2` | `Fail` |

## 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.

![Allow deny](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/attribute-checks/allow-deny.png)

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `[+ alan] [+ mike]` | `alan` | `Pass` |
| `[+ alan] [+ mike]` | `greg` | `Fail` |

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

| Expected Value | Collected Value | Pass/Fail |
| --- | --- | --- |
| `[- alan] [- mike]` | `homer` | `Pass` |
| `[- virus.exe] [- malware.exe]` | `virus.exe` | `Fail` |

## 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.