---
title: "Build a custom policy"
description: "Define the configuration you expect with sections, checks and attribute checks."
product: "Guardian"
edition: "Classic"
type: "workflow"
url: "https://docs.cloudhouse.com/guardian/classic/control/policies/build-custom-policy/"
---
# Build a custom policy

Define the configuration you expect with sections, checks and attribute checks. Policies are made up by a series of sections and checks, with each section used to organise the policy and define the hierarchy of checks within it. Once you have organised your sections in a custom policy, you can begin to define what checks you want to be run. Optionally, you can include specific attributes to be checked too. For more information on policies, see [Policies](https://docs.cloudhouse.com/guardian/classic/control/policies/policies/index.md).

Applies to: `Guardian Classic`

![Screenshot of the policies tab, with 'All Policies' selected and displayed.](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/policies-tab.png)

To build a custom policy, complete the following steps:

1. In the Guardian web application, navigate to the **Policies** tab (**Control** > **Policies**).
2. Click the **Build Policy** button. The **Build Custom Policy** dialog is displayed.

    ![Build policy border](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy-border.png)

3. Enter a **Policy Name** in the field provided.

    ![Build custom policy dialog](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/build-custom-policy-dialog.png)

4. Optionally, you can select a value from the **Add to node group** drop-down list. If selected, the policy is applied to the node group and run against each of the nodes that match the policy's criteria.

    !!! note

        If you leave this field blank, you are still required to assign the policy to a node group in order for it to be run. Otherwise, it will remain inactive.

5. Once complete, click to **Start Building** your custom policy. The policy builder page is displayed.

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

Here, you can begin building your custom policy by adding [Sections](#sections), [Checks](#checks), and then [Attribute Checks](#attribute-checks). See below for more information on each aspect of the process.

!!! tip

    Alternatively, at this point, you could choose to import an existing policy. For more information, see [Import a Policy](https://docs.cloudhouse.com/guardian/classic/control/policies/export-import-policy/index.md#import-a-policy).

## Sections

Policies are comprised of sections. Within each section, you can add the checks that you want to be run. The purpose of a section is to define the hierarchy for those checks. You can re-organise that hierarchy at any time by dragging and dropping a section at a time.

![](../../assets/images/guardian/control/policies/build-policy/sections.png "Screenshot of the Policies tab. The custom policy builder is displayed, with the 'Add Section' menu highlighted with a red border.")

In the example above, no sections have been created. To add a new section, click the **Add Section** button (![Add section](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/buttons/add-section.png)) and enter a **Section Name** in the field provided. Then, click **Done**. Repeat as required, then you can begin adding checks.

!!! note

    If you are editing an existing policy, make sure that the **Type of addition** drop-down list is set to 'Section'.

## Checks

Checks are the crux of a policy. When a policy is run, it is the checks that are displayed within the node scan results as either 'Passed' or 'Failed'. In the example below, a check is being added to the 'Cert. Expiry' section. For more information on the node scan results page, see [Node Scan Results](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/nodes/node-scan-results/index.md).

![](../../assets/images/guardian/control/policies/build-policy/checks.png "Screenshot of the custom policy builder, with the 'Add check' menu highlighted with a red border.")

To add a check to a section, complete the following steps:

1. Within an existing section, click the gray **Add Check** button (![Add](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/buttons/add.png)) directly beneath it.

    ![Add check](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/add-check.png)

2. Select 'Check' from the **Type of addition** drop-down list.

    ![Select check](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/select-check.png)

3. Select the **Type of check** you want to add from the drop-down list provided.

    ![Select type of check](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/select-type-of-check.png)

4. Enter a value in each of the required fields.

    ![Enter values](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/enter-values.png)

    !!! note

        Depending on the type of check you selected, the fields displayed here vary. In the example above, the 'web' check has been selected.

5. Once complete, click **Done** to add the check to the section.

After defining the item to be checked, you can stipulate what you want Guardian to check for when scanning the item. By default, Guardian runs a check to determine whether the item you defined is `Present` during the scan. To configure that default value, see below. Additionally, you can add an [Attribute Checks](#attribute-checks) to define a different `expected value` to be checked during the scan.

## Attribute checks

When you add a check, you define the item that you want to be scanned as part of the policy. Attribute checks are used to define an expected value or condition of the 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 example, the default attribute check Guardian runs for all policies is to determine whether the item(s) you defined are **present** on the node during the scan.

![Check added](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/check-added.png)

You can set the expected value to be 'true' – meaning that it should be present – or 'false' – meaning that it should not be present during the scan. If the item matches the expected value, it will 'Pass' the check or 'Fail' if it does not. For more information on the available attribute checks, see [Policy Attribute Checks](https://docs.cloudhouse.com/guardian/classic/control/policies/policy-attribute-checks/index.md).

!!! note

    By default, this attribute is set to 'true'. You can change this value at any time by clicking the **Edit** button (![Edit](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/buttons/edit.png))and changing the **Expected** field value to 'false'.

**In addition to the default check, you can add an attribute check by completing the following steps:**

1. Within an existing section, select the check that you want to add an attribute check to. A side panel is displayed.

    ![Add attribute check](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/add-attribute-check.png)

2. Click the **Add Attribute Check** button. Several fields are displayed.

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

3. The following options are displayed, enter a value in each of the relevant sections:

**Attribute name** field
:   The name of the attribute to be checked. Select a value from the drop-down list or enter the name of the attribute exactly as it appears.

    !!! warning

        If the attribute name is typed incorrectly, the check may become redundant.

**Type of check?** drop-down list
:   The type of check to be run. The following options are available to select from the drop-down list:

    !!! tip

        For more information on each of the check types described below, see [Policy Attribute Checks](https://docs.cloudhouse.com/guardian/classic/control/policies/policy-attribute-checks/index.md).

    - '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.
    - 'Includes' – The item to be checked must include the **Expected** attribute value (defined in the **Expected** field) otherwise the check will fail.

    !!! note

        You can provide a comma-separated list of values to check.

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

    !!! note

        You can provide a comma-separated list of values to check.

    - 'XPath' – Find elements within an XML file (such as a `web.config` file) to verify that a path exists. If the correct path is not present, the check will fail.

    !!! note

        The value of the element is not scanned as part of this check.

    - '>, >=, <, <=' – 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.
    - '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 define whether the **Expected** collected value should be greater than or less than the attribute value.
    - 'Regular Expression (Excludes)' – Define text that should be excluded from an attribute value using a regular expression. Define the criteria for the attribute check using the **Expected conditions for value** options. Here, you can define whether the collected value should be greater than or less than the **Expected** attribute value.
    - 'Time Comparison' – 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.
    - 'Version Comparison' – 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' – Specify if the attribute value should or should not match an entry within a specific list. If the criteria is met, the policy will pass.

    !!! tip

        Alternatively, select the **Check should pass if attribute is absent** check box to have the check pass if the **Expected** attribute is not present during the scan.

**Expected** field
:   The expected value of the attribute. Enter the value of the attribute that you want to define a check for.

    !!! note

        This field is not displayed for '>, >=, <, <=', 'Time Comparison', 'Version Comparison', or 'Allow/Deny' check types. Instead, the **Expected conditions for value** options are displayed.

**Expected conditions for value** options
:   Option to define the acceptance criteria for the expected attribute value.

    !!! note

        These options are not displayed for the 'Exact Match', 'Includes', or 'Excludes' check types.

    Here, the following options are displayed:

    - **Value must be** drop-down list – Select one of the following values:
        - '>' – Greater than the expected value.
        - '>=' – Greater than, or equal to, the expected value.
        - '<' – Less than the expected value.
        - '<=' – Less than, or equal to, the expected value.
        - '=' – Equal to the expected value.
        - '!=' – Not equal to the expected value.
    - **Value must be** field – The value you want to define a check for (the 'expected value').

**Allow/Deny** options
:   Option to define whether the expected attribute value should or should not match an entry within the list.

    !!! note

        This option is only displayed for the 'Allow/Deny' check type.

    Here, the following options are displayed:

    - **Allow/Deny** drop-down list – Select 'Allow' or 'Deny' from the list to define whether the expected value should be present or not.
    - **Allow/ Deny** field – The value you want to define a check for (the 'expected value').

**Remediation** field
:   Option to provide instructions on what to do if the policy is failing. The text provided here will be displayed on the node scan results page, if the policy is selected. This is not a command that will be run.

    !!! tip

        Providing instructions for policy failure remediation can enable users to resolve issues independently and more efficiently.

**Background** field
:   Option to provide an explanation for the check, such as the purpose it serves. The text provided here will be displayed on the node scan results page, if the policy is selected. This is not a command that will be run.

    !!! tip

        Providing background information for policy checks makes it easier to understand the purpose that each policy serves, without needing to assess the individual checks each time.

4. Once complete, click the **Add** button.

The attribute check is added and displayed on the policy. For more information on each of the check types, see [Policy Attribute Checks](https://docs.cloudhouse.com/guardian/classic/control/policies/policy-attribute-checks/index.md). Alternatively, for information on how to use wildcards within your policy checks, see Wildcard Policies.

!!! note

    Next you can begin adding node groups to your policy, see [Add Benchmark / Policy to Node Group](https://docs.cloudhouse.com/guardian/classic/control/benchmarks/actions/add-benchmarkpolicy-to-node-group/index.md) for more information.

## Wildcard policy

When building a custom policy, you can use wildcards to customise your checks. For example, you could create a policy that monitors all the files retrieved from a defined directory, or directories. If you experience a password leak, for example, you could configure Guardian to scan all files (within a specified directory) to see if they contain the leaked password.

To add the above wildcard attribute check to an existing policy, complete the following steps:

!!! tip

    The following process specifically checks files within a directory. To ensure that the correct files are collected during a scan, make sure that the correct **File and Directory** paths are set within the [Scan Options](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/scan-options/scan-options/index.md) and that the **Contents** option is selected for each scan option. For more information, see [Files](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/scan-options/scan-options/index.md#categories).

1. Within an existing section, select 'other' from the **Type of check** drop-down list.

    ![Other type of check](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/wildcard/other-type-of-check.png)

2. In the **CI Path** field, type 'files' and click **Enter**.
3. Then, type '\*' and click **Enter**.
4. Once more, type '\*' and click **Enter**.

    !!! note

        This will match all configuration items collected under a node scan from the **Files** section.

5. Once complete, click **Done**.

    ![Done fields](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/wildcard/done-fields.png)

The wildcard check is then added to the policy. Next, you need to add an additional attribute check to further define the policy's acceptance criteria. In this scenario, we want to add an attribute check to make sure that a leaked password is not present within the file directories we stipulated in the previous section.

To add an additional attribute check for the above use case, complete the following steps:

1. Within the above section, select the check that you want to add an attribute check to. This should be the check that you just created. A side panel is then displayed.

    ![Step 1](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/wildcard/step-1.png)

2. Click the **Add Attribute Check** button. Several fields are displayed.

    ![Step 2](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/wildcard/step-2.png)

3. In the **Attribute Name** field, type 'raw'.
4. In the **Type of check?** drop-down list, select 'Excludes'.
5. In the **Expected** field, enter the text you want Guardian to search for. In this example, you would enter the leaked password. For example, 'ceoPassword123'.
6. Optionally, you can add a set of **Remediation** steps as well as some context in the **Background** field.
7. Once complete, click **Add**.

    ![Steps done](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/control/policies/build-policy/wildcard/steps-done.png)

The attribute check is then added to the policy. Once complete, you have successfully created a custom policy that uses wildcard syntax to monitor all of the files retrieved from a defined directory.