Configuration policies

A policy defines a standard configuration that you can check against de-facto configurations. Policies are a powerful tool to check if your systems are actually configured they way they should be, no matter if it comes to cyber security patches, software versions, or hardware configuration.

Defining a policy

In order to define a policy, go to WORKFLOW/AUDITS. There you see the list of existing policies.

• In order to define a new policy from scratch, click on "Add".
• In order to define a new policy based on an existing policy, select the baseline that you want to use as a template and click on "Clone".
• In order to modify an existing policy, click on "Edit".

Thereafter, the add/edit policy dialog pops up.

You can use the following sections and fields to define your policy:

Policy tab

Name
The name of the policy. You must assign a unique name to each policy.

Description
Specify what this policy is about, such a a configuration standard for engineering stations.

Device Assignment
Here you specify which devices are subject to the policy. You can assign a policy to individual devices in the device inventory. You can also assign a policy to all devices. The most useful and efficient setting is, however, to use a saved search to identify devices subject to your policy. This allows you to do a rule based assignment where devices that meet a certain set of criteria are linked to the policy, rather than a predefined set of devices.

Comments tab

Allows you to add a more verbose description of the policy.

Hardware tab

Here you can define any specific hardware products that must be used for devices covered by this policy, such as specific computer models. If you specify more than one hardware product, a device is considered compliant with the policy if it uses any of these products (since a given device can only use one hardware product).

Modules tab

The hardware modules that must be present for a device compliant with this policy, such as specific interface cards. A device will only be considered compliant if all modules are present. Obviously, adding modules here only makes sense for control system racks.

Required Software tab

Software products that are mandatory in order for a device to be compliant. For embedded devices, you can also specify firmware versions. If you specify multiple software/firmware products, all these products must be present in order for a device to be compliant.

Prohibited Software tab

Software products that must not be installed on a device. An example would be software that is known to be prone to security vulnerabilities, such as Adobe Flash Player.

Any Required Software tab

Software products that are mandatory in order for a device to be compliant, however only one of the products listed must be installed. This allows you to specify alternatives.

Reference tab

Here you can specify a reference system from which a default configuration is taken (see below).

Sometimes you want to model a policy around an existing configuration. In this case you don't have to specify all the required software products etc. from scratch.

Instead, click on the Reference tab and select the device that shall act as the reference system. In the drop-down list that is opened after clicking the down arrow of the edit field, you can filter the device list by entering characters in the filter bar, as in the following example.

After having specified a reference system, hardware, modules, and required software will be set to the values of the reference system. You can still edit all list to remove or add items.

If the configuration of your reference system has changed and you want to see the changes reflected in the baseline, you need to click the "Refresh" button next to the reference system's ID.

Files tab

Here you can attach any files that could be helpful, such as configuration guidance, software images, etc.

Using Wildcards

For defining configuration items you can also use wildcards. You can use this feature when defining required software, prohibited software, or any required software.

As an example, you may want to specify a policy that prohibits the installation of Adobe Flash, no matter which version. Without using wildcards, this wouldn't be possible. Using a wildcard, you could define a policy that prohibits to use any software product by vendor Adobe%, with the product name %Flash%. This will make sure that all Adobe Flash products are caught, no matter which version, and no matter what the exact product name might be.

It might be a good idea to test your wildcard filter strings in the inventory, to make sure that they work as intended.

Policy compliance in device profiles

After you have associated a device with a policy, a new Compliance section will appear in the device profile that informs you about

1. the name of the policy that is associated with the device
2. if the device is compliant with the policy or not
3. any reasons for non-compliance.

In the following example, it is indicated that the device is non-compliant because it is running the wrong firmware version.

Policy profiles

You can launch the profile of a policy by selecting the policy in the policy list and then click on "Profile", or by clicking on the policy's name in a device profile.

The policy profile contains all the information that you have specified in the policy definition. It also shows you which devices have been associated with this policy, and their compliance or non-compliance with the policy.

Note: For default policies that apply to all devices, only non-compliant devices are listed.

Compliance reports

OTbase Inventory automatically creates compliance reports for your policies that you can access on the REPORTS page after selecting POLICIES in the sidebar. The benefit of a compliance report, compared to a policy profile, is that it comes with a couple of charts and a timeline. The timeline exposes the number of compliant and non-compliant devices over time and thus gives you a good indication of your progress in getting rid of non-compliant configurations.

You can also assign policy reports to dashboard widgets. In this case, the number of non-compliant devices is shown, either as an absolute number or as a percent value (non-compliant out of total number of devices).

Note that it may take up to 24 hours initially until your report data is available.

Exposure of compliance data via the REST API

The REST API includes compliance information, which allows you to post-process and visualize such information via custom applications or third party tools.

For individual devices, compliance data is exposed in the new compliance object, which is a list of all policies that apply for a given device, along with their description and the compliance status (Boolean true or false). You must specify the modifier include=compliance, or include=all in the URL in order to see compliance data.

Another way to see compliance status is to query the compliance endpoint, which yields a list with all defined policies, along with lists of compliant and non-compliant devices, identified by their device IDs.