UpGuard Core can be configured to alert when rarely changing configuration items change.

UpGuard Core can be used to track for wanted and unwanted changes across nodes and can alert when a change is detected. This guide focuses on how to track and be alerted on a subset of configuration items that rarely change.

Node Level

A slightly related topic is alerting on any change to a node. To set up alerting for any changes, you can set up a custom event view with a query like this:

type=Node Scanned AND variables.diffs=true

CI type Level

If you want to track for any changes that happen for specific types of Configuration Items, you can also make use of the Node Changes event type. For example, you might not care that the files and packages on your server change often (so would not care for the whole node approach above), but you could track for any user account changes by using a query like this:

type=Node Changed AND variables.user_diffs=true

You can also modify this type of query to track for only added and removed user accounts. In the example below we are looking for Node Changed events where there are differences, but those differences are not the modified type (i.e. either added or removed).

type=Node Changed AND variables.user_diffs=true AND variables.user_modified=false

For more information on creating custom event views, please refer to our guide on Events.

If there is a small subset of items collected during a node scan that change often, you can also add those more transitive items to an ignore list, so that you can focus on important and unexpected changes. For more information about ignore lists, please refer to our guide on Ignore Lists.

Tracking Changes of Particular Types of Configuration Items

In this example, we are going to assume that the list of user accounts detected on a particular node rarely changes and that we would like to be notified if any user accounts are added, modified or removed. Other configuration items collected during a node scan of this node may change frequently, but we’re only concerned about the Users section of a scan.

Here we are going to:

  • Make sure we have a baseline node scan of a node with a proper set of users,
  • Create a policy based on the user list from this scan,
  • Create a custom event view to track when this particular policy changes, and
  • Briefly cover attaching an action to this event view so we can be alerted upon a change via a policy failure.

Locating a Baseline

First you should locate a node that has a complete and correct list of users you want to enforce for this node and potentially other nodes that should match. If you want to also detect changes in the properties of user accounts, please also confirm that the attributes are correct.

w800

Creating a Policy

Next, we need to create a policy that both enforces that the current set of users and attributes will always be present, but also that any additional user accounts are not allowed. To begin building a policy, right click on a user and select Add to Policy, select the node group you want to assign the policy to and then click New Policy. In this example, we happen to have placed all of our Ubuntu 16 nodes into a common node group, so we’re going to create the policy against that node group.

w800

Assign your new policy a name and click Build. For each subsequent user you want to add to the policy, right click the username and the select Add to Policy, select the same node group and then select your newly created policy from above. Adding each user will help enforce that both each user exists on future scans, but also each of the configuration item for each user matches the scan you currently have in the baseline.

The second step is to create a policy check that contains a whitelist of all current usernames so that if any additional usernames are suddenly detected on a node scan, then the policy will fail. Here you will have to note down your current set of usernames.

You will then need to navigate to the policy details page for your new policy. You can either navigate there by clicking on the policy name in the left hand panel under the Policies section, or by searching for your new policy by name from the Control > Policies menu.

When viewing the policy, click the + symbol to add a new check, then select the new type as Check, the Type of check as other. For the CI Path section in this case type users then press enter, then type linux then press enter, then type * and press enter. This should generate a 3 part path to all user records in a scan and the parts of this path match the category headers found on the original node scan. For all Linux based node scans, this 3 part grouping will always match All Users. For the Description field, leave a good note to describe what this check is doing. When finished, click Done.

w800

Next, we are going to add each of the usernames to a whitelist attribute check. If the right-hand details panel is not visible, click on the check you just created. Next, click on the blue Add Attribute Check button. In this particular case, we want to check for the user’s username, which is stored under user node scan records as the name attribute. Select the whitelist type of check and then start listing each of the usernames you want to whitelist. In the screenshot below, we’re already added root, lpr and backup and are about to click add on the ubuntu user.

w400

When you have listed all usernames you want to whitelist, scroll to the bottom of the right panel and click the final Add button. This should save your attribute check. Now that the policy is assigned to the node (via the node group), every time this node gets scanned in the future, this policy will also be executed. On failed policies, the account owners and administrators should be notified via email.

Creating an Event View and Alerting on Change

By default, policy failures are reported to users via email. However, you may also want to notify other channels or automation tools around these particular type or rare changes. Here you would set up a custom event view to listen for when this particular policy fails. Navigate to the events page by clicking on Control > Events.

If we had named our policy from above Master Ubuntu Users List then we would search for events using the following query:

type=Policy Ran AND variables.success=false AND variables.policy=Master Ubuntu Users List

For more information around creating an Event View and assigning an alerting Action to this type of event, please refer to our guide on Event Views.

But I have hundreds of users…

Please contact UpGuard Support and we can work on an automated solution to setting up this type of policy. If there is enough demand will will publish some sample scripts here for common languages.

What Next?

We have used the Users category of a Linux scan here as an example, but you can also apply this type of check to any subset of a scan, for example files, ports or packages. Please contact UpGuard Support if you require assistance adapting this use case to your own requirements.

Tags: