Custom Policy Builder

The Custom Policy Builder allows you to create, edit, and customize policy checks for your specific needs that extend beyond the standard benchmarks. The Custom Policy Builder also increases your visibility into policy and policy test details.

Benefits

With the Custom Policy Builder you can:

• Modify an existing policy for use on a newer OS before an official benchmark is available from CIS or DISA
• Enable or disable rules to align with your organization’s goals
• Customize rule types, operators, and expected values to meet your environments configurations

In this article, you will learn how to:

• Access the Custom Policy Builder
• Copy and Edit an Existing Policy
• Save a Policy
• Delete, Disable, and Enable Policy Rules

Requirements

Before starting, confirm that you meet system requirements and are an InsightVM user whose console is connected to the Insight platform.

Access the Custom Policy Builder

The Custom Policy Builder is accessed through the Security Console through the copy and edit button.

1. Log into the Security Console.
2. Click the Policies icon in the left navigation bar.
3. Check the box next to the policy you want to copy.
4. Click the copy button. Within a few seconds, you will be redirected to the Custom Policy Builder (located on the platform).

Copy and Edit an Existing Policy

To copy an existing policy, you’ll follow the same steps used to access the Custom Policy Builder.

Edit a Policy

After the Custom Policy Builder launches, you will be taken to the policy’s details page. You can edit the policy’s details by clicking the pencil icon. Editable information includes:

• Policy name
• Version
• Platform
• Description
• Rules

Delete, Disable and Enable Policy Rules

1. Click the name of the policy you wish to edit on the policy list page.
2. Check the box next to the policy rule you want to edit. You can check an individual box or you can check all of the boxes.
3. Click Actions after checking the rule(s) you want to edit. A dropdown menu will display with 3 options:
   • Delete Rule(s) - Removes the rule from the policy permanently
   • Disable Rule(s) - Disables the rule during scanning but leaves it in the policy. It will be shown as Skipped in the Custom Policy Builder.
   • Enable Rule(s) - Enables a rule during scanning that was previously disabled

4 Select the action you want to apply to the policy rule.

Save a Policy

After you build or edit a custom policy, click the Save and Close button to immediately sync it to the Security Console console. Add your custom policy to a new or existing scan template so you can measure compliance in your environment. You need to Sync and Save new custom policies so that they show up and are accessible in the console for later modification. Clicking Save will save them only to the platform and can not be synced to the console later, essentially getting suck in the cloud.

Add a custom policy to a scan template

1. In the Security Console, go to Scan Template Configuration > Policy Manager.
2. Check the box next to the custom policy you want to add to the scan template. The scan template will now be included in your custom policy during the next assessment.

Use Cases

We’ll outline some examples of common use cases for the Custom Policy Builder:

• Customize a Complex Policy
• Edit Common Platform Enumeration (CPE) Policy
• Edit a Shell Command
• Add a File Content Policy

Customize a Complex Policy

Here is an example on how to use our Custom Policy Builder to create a complex policy check. In this example, we will create a password policy check for two different types of hosts: one with a weaker requirement on password length but shorter password age and the other with a stronger requirement on password length and longer password age.

To accomplish this, you’ll need to create a complex policy check consisting of 2 subgroups that contain 2 tests.

Each subgroup will contain 2 tests that check the password length and password history. In this example, one subgroup will be for a password length of 8 or more characters, but the password will need to be remade in 30 days. For the second subgroup, password length needs to be at least 12 characters, but the password will need to be remade in 90 days. In order to pass the test, at least one of these subgroups must be met.

First, you’ll build 2 tests based on password length, and then add the password history tests to those password length-based tests to create subgroups.

Task 1 - Build the Test for Password Length that is at Least 8 Characters

To create a test for password length to be 8 characters or greater. This test will become the first subgroup:

1. Navigate to the policy that you want to include in these tests.
2. Click the + button.
3. Complete the fields in the Add New Test screen with the following:
   • Test Title - Enter test title. For example, “password len >= 8”
   • Operator - Select OR
   • Type - Select passwordpolicy_test
   • Password Type - Select min_password_len
   • Value - 8
4. Click Save New Test.

Task 2 - Build the Test for Password Length that is at Least 12 Characters

Next, we’ll build the second test for password length to be 12 characters or greater. This test will become the second subgroup:

1. Click the + button next to OR.
2. Complete the fields in the Add New Test screen with the following:
   • Test Title - Enter test title. For example, “password len >= 12”
   • Operator - Select OR
   • Type - Select passwordpolicy_test
   • Password Type - Select min_password_len
   • Value - 12
3. Click Save New Test.

Task 3 - Build the Test for Password Duration of 30 Days

Next, you will create a second test in the first test you created (Task 1, the 8 characters or greater subgroup). This test will check to see if the password history is greater or equal to 30 days:

1. Click the + button in the password len>=8 test.
2. Complete the fields in the Add New Test screen:
   • Test Title - Enter test title. For example, “password history len >= 30“
   • Operator - Select AND
   • Type - Select passwordpolicy_test
   • Password Type - Select password_hist_len
   • Operator - Select greater than or equal
   • Value - 30
3. Click Save New Test.

Task 4 - Build the Test for Password Duration of 90 Days

Next, you will create a second test under the second test (Task 2, the 12 characters or greater subgroup.) This test will check to see if the password history is less or equal to 90 days:

1. Click the + button in the password len>=12 test.
2. Complete the fields in the Add New Test screen:
   • Test Title - Enter test title. For example, “password history len >= 90”
   • Operator - Select AND
   • Type - Select passwordpolicy_test
   • Password Type - Select password_hist_len
   • Operator - Select less than or equal
   • Value - 90
3. Click Save New Test.

To save your tests and subgroups, click the carat next to the policy title to return to the Policy Details page and click Save.

Configuring Tests with a Pattern Match (Regex) Against a Windows Registry

1. Click the Edit Test button to begin test configuration.
2. In the target field that you want to use a regex pattern match on, change the Operator to Pattern Match.
3. Select the target field and adjust the regular expression as required.
4. Click Save.
5. In the policy, click Save.

Edit a Common Platform Enumeration (CPE) Policy

Next, we’ll walk you through the steps of creating a policy based on similar rules for an existing policy, so you can still conduct policy compliance scans on the latest edition, even though CIS has not released it yet. If CIS has not released a new benchmark for the latest macOS version, simply make a few edits on the existing policy, as that most of the rules from their previous version are applicable to the latest platform. To accomplish this, you’ll need to modify the CPE check-in OVAL/XCCDF XML files, which can be tedious and error-prone. In Custom Policy Builder, the CPE check is a shellcommand_test type that uses a shell command and a regex pattern match to check for the OS.

In the following example, we’ll teach you how to assess the existing OSX 10.13 version policy on 10.15 version of the operating systems:

1. Navigate to the existing version policy in the Security Console. In this example, the version OSX 10.13.
2. Select the check box next to the policy.
3. Click Copy to be redirected to the Custom Policy Builder.
4. Click the pencil icon in the Platform specification section to edit the CPE.
5. Click Edit Test to enable the fields to be editable.
6. Change the Stdout Line field to ^10\.15.*
7. Save the test and then save the policy.

You can now run this custom policy on a Macbook with OSX version 10.15, so all included rules will be assessed against the 10.15 asset.

Edit a Shell Command Policy

A shell command test uses keyboard commands (shells) to check assets and assess the output of these commands for certain patterns. In this example, we’ll use CIS Amazon Linux 2 Benchmark Level 2 v1.0.0 to add a shell command policy.

1. Navigate to the CIS Amazon Linux 2 Benchmark Level 2 v1.0.0 policy in the Security Console.
2. Check the box next to the policy to select it.
3. Copythe policy to be redirected to the Custom Policy Builder.
4. Navigate to rule 1.1.1.1 (Initial Setup > Filesystem Configuration > Disable unused filesystems > 1.1.1.1 Ensure mounting of cramfs filesystems is diabled).
5. Click Edit Test to edit these fields:
   • Command
   • Line Selection
   • Stdout line
6. Save the test and then save the policy.

Add a File Content Policy

You can use a file content test to determine if a particular file (usually a configuration) is compliant by matching the file’s content against a specific pattern in a given file.

A file is identified by:

• The file path
• The file path and file name

In this example, we’ll use CIS Amazon Linux 2 Benchmark Level 2 v1.0.0 to add a file content policy.

1. Navigate to the CIS Amazon Linux 2 Benchmark Level 2 v1.0.0 policy in the Security Console.
2. Check the box next to the policy to select it.
3. Copy the policy to be redirected to the Custom Policy Builder.
4. Navigate to rule 4.2.1.3 (Logging and Auditing > Configure Logging > Configure rsyslog > 4.2.1.3 Ensure rsyslog default file permissions configured )
5. Click Edit Test to edit these fields:
   • Filepath
   • Pattern
   • Instance

6 Save the test and then save the policy.

Acceptable File Naming Convention for Policy Builder

The following naming formats are acceptable when creating files for policy editor uploads.

• XCCDF(singletonList(compile(".*-xccdf.*\\.xml"))),
• CPE_DICT(singletonList(compile(".*-cpe-dict.*\\.xml"))),
• OVAL(asList(compile(".*-oval.*\\.xml"), compile(".*-patch.*\\.xml"))), This intentionally covers cpe-oval. -patch are PATCH type oval definitions.
• DATASTREAM(singletonList(compile(".*-datastream.*\\.xml"))),