Skip to content

Guardian Concepts

The following content describes some of the key concepts that comprise the functionality of the Cloudhouse Guardian (Guardian) appliance. For more comprehensive instructions on how to get started in Guardian, see the Guardian Getting Started Guide.

1 Architecture

The concepts below describe the architectural components of Guardian. These are the aspects of Guardian that require immediate set up.

1.1 Appliance

The Guardian appliance is the central location for all processing in the Guardian scanning process. Connection Managers and Agents will communicate with the appliance to get jobs and send scan results, and the appliance holds this information in a database. The appliance can be deployed either as an on-premises solution, or Cloudhouse-hosted.

For on-premises deployments, the Cloudhouse Guardian appliance is a virtual appliance deployed in a VMWare environment. For users, this appliance is a black box, and sign in is only permitted to Guardian Support. This is to ensure the stability of the platform and take the responsibility off of any internal team. For hosted deployments, the Cloudhouse Guardian appliance is managed by Guardian.

1.2 Agent

The Agent software is a service that runs on a node to run local scan jobs and send the data back to the Cloudhouse Guardian appliance.

1.3 Connection Manager

A Connection Manager is a stateless server that gathers jobs from the appliance, scans nodes Agentlessly, and sends scan results back to the appliance. Cloudhouse provide a built-in (default) Linux Connection Manager that is separate from the remote deployment solutions described below. The default Connection Manager is included as part of your Guardian instance's deployment. There is no set up required; no additional systems required to host it. It is available to scan any node types that specifically require an SSH connection protocol.

Tip: For users with a small number of non-Windows nodes, this can be used in lieu of installing a Linux Connection Manager. However, if you intend to scan over a hundred SSH nodes, it may be sensible to install multiple Linux Connection Managers and organize them into groups for more efficient scanning.

There are two additional types of Connection Manager available to deploy:

1.4 Node

The term 'node' in Cloudhouse Guardian (Guardian) is used to represent any scannable object in your environment. Anything with an IP address or a single cloud entity can be added to your environment as a node. You can set up node groups, policies, and benchmarks to monitor the configurations of your nodes and ensure that they are compliant with the specific parameters you have set. A node can be assigned one of two statuses: detected or monitored. For more information, see Nodes.

2 Organizational Units

The concepts below describe the organizational units of Guardian. Once your core architecture has been set up, you can begin to organize your assets into units. For more information on the location for storing and organizing your assets, see Monitored Nodes.

2.1 Node Groups

Node groups are used to organize nodes according to device type, operating system, applications, and any other combination of defining criteria. For example, you could have groups specifically for Windows, Linux, Databases, or IIS nodes. Node groups simplify the management of node-related settings for ignore lists, scan options, and policies. Once these settings are configured for a node group, they are applied to each node within that group. You do not have to apply those settings individually. A node can be added to any number of node groups. When set up correctly, the only consideration you need to make when adding a new node is that it is organized within the appropriate node group(s). The group-level settings will then take care of everything else. There are two types of node groups within Guardian, a standard (static) node group and a dynamic node group. For more information, see Node Groups.

2.1.1 Static / Dynamic Node Groups

There are two types of node groups you can create; a standard (static) node group or dynamic node group. Traditional node groups within Guardian are static in nature - without manual intervention, they will remain exactly as they were created until they're removed. This method requires you to manually add nodes to the group as required, it is a simpler method that works best for node types that aren't expected to change much over time. However, dynamic node groups are more flexible in nature.

Dynamic node groups are defined by a pattern or common attribute that is set via a dynamic group query. Rather than being statically assigned, any nodes that would be returned by the query are automatically assigned to the node group. Likewise, any nodes that may no longer satisfy the query will be removed from the group. Dynamic node groups were created as a solution to the ever-changing landscape of many enterprises, allowing the group to grow or shrink as the composition of the enterprise changes.

When creating a new node group, the only difference between a static and dynamic group, is the addition of a dynamic group query. Conversely, you can also use regular expressions to set rules for a dynamic or static node group. This will automatically add any nodes that meet the specified criteria to the node group.

2.2 Environments

Environments are the top-level organizational unit in Guardian, allowing you to organize nodes into groups that match your own infrastructure, such as development, staging, and production environments. However, if you do not want to organize your nodes according to a traditional release approach, you can organize your nodes according to any other combination of defining criteria, such as the region or operating system. For more information, see Environments.

2.3 Connection Manager Groups

Connection Manager groups are used to organize Connection Managers of the same type (Windows or Linux) into groups with similar properties and roles. For example, you could group your Connection Managers according to network topologies, time zones, or any other organizational property. Each node within your Guardian instance is then assigned to a Connection Manager group that is responsible for handling any requests, such as a node scan or integration sync, triggered by the assigned nodes. For more information, see Connection Manager Groups.

3 Scans

Scans are the heart of Guardian. Regular scanning of your assets allows you to track configuration changes over time and can be used for rich configuration differencing. If something goes wrong with one or more nodes, you can check your node(s) scan history to identify exactly where and when the issue occurred. Scans can be triggered via the UI, API , or job schedule. For more information on the different methods available, see Scan Nodes.

3.1 Scanning Services

To begin scanning your nodes, you must first determine what service you want to use for scanning: the Agent or Agentless Connection Manager. For more information on the pros and cons of each service, see Agent-Based or Agentless?

3.2 Scheduling Node Scans

It's important to regularly scan your assets in Guardian. Schedule a job scan of a node, node group, or environment to run according to a specified schedule. For more information, see Scan – Job Type.

3.3 Node Scan Results

A node scan is a snapshot of a node at a certain point in time. When a node is scanned, the results are presented in a visual and interactive display, with a list of all configuration items divided into sections. Here, you can customize the data to output information related to policy compliance, scheduled jobs, other node scans, and more. For more information, see Node Scan Results.

3.3.1 Sections

In a node's scan results, all configuration items are grouped into sections. These sections are built-in and cannot be modified, and they vary between node types. Examples of common sections include Users, EnvVars, and ServiceKeys.

3.3.2 Configuration Item

A configuration item is a single piece of configuration on a node, as displayed in a node's scan results. For example, this could be a file, a registry setting, a software package version, or more.

Tip: Configuration items are different for each node type. Likewise, they are defined according to the Scan Options for the node’s assigned node groups.

3.3.3 Attribute

Each configuration item has any number of attributes. For example, a file configuration item may have attributes for:

  • Access permissions
  • Checksum
  • File contents
  • Last modified time
  • Owner information.

Tip: Checks for specific attributes can be defined within a policy and run against a node group to uphold a desired configuration state, see Attribute Checks for more information.

3.4 Configuration Differencing

Generate a difference report for the scans of multiple nodes or node groups to access the complete set of configuration data present on each node. Within the report, you can filter the results by scan date, differences, and commonalities, all of which can be critical to uncovering and understanding inconsistencies within your node set. For more information, see Configuration Differencing.

3.5 Scan Options

Scan options allow you to customize the scans of your node groups. Essentially, to specify particular areas of interest that ought to be scanned and monitored, outside of your standard configuration. For example, you could specify particular files or directories that you want to be scanned. For more information, see Scan Options.

4 Benchmarks and Policies

A policy in Guardian is essentially a configuration baseline for the security and maintenance of a system. Policies confirm compliance. There are two types of policies in Guardian: Custom (created) and Public (default). A custom policy is a manually created set of checks used to accommodate an individual user or company's needs, these are commonly referred to as policies. A public policy is an industry-standard policy, as stipulated by the Center for Internet Security (CIS). In Guardian, these are known as benchmarks.

4.1 Benchmarks

The Benchmarks tab (Control > Benchmarks) contains a list of industry-standard, best-practise policies, stipulated by the CIS to ensure the security of a target system. Benchmarks are an incredibly powerful tool provided by Guardian that can be applied to a node, or group of nodes, to evaluate whether they are compliant with the parameters stipulated by the CIS.

4.2 Policies

The Policies tab (Control > Policies) displays all of the policies that are presently configured within your Guardian instance, both custom and public. Policies are an excellent resource in Guardian that allow you to define a desired configuration state at the node or node group level. For example, you could create a policy to ensure that a set of roles and features are installed on a node, or that certain environment variables are set. The policy checks are then run each time the node is scanned, with the results indicating whether the checks passed or failed. A node group can contain multiple policies that are applied to the same or a different set of nodes.

Note: Policies in the Guardian appliance offer slightly different functionality from the Policy API. For more information on the API, see the Guardian API (V2) Policies documentation.

5 Additional Configurations

The concepts below describe additional functionality you can configure to automate or improve various aspects of the Guardian user journey. Whilst they are not a requirement, they are very useful.

5.1 Variables

Variables are used as placeholders that are replaced with relevant data allowing you to conveniently store and retrieve values when needed. The Variables tab (Control > Variables) displays the variables that have been created within your Guardian instance.

5.2 Real-Time Forwarder

The real-time forwarder allows for up-to-the-minute monitoring of specific file paths on a given node. This allows you to see changes that occur between regularly scheduled node scans. For more information, see Real-Time Forwarder.

5.3 Tagging

Tagging in Guardian means attaching an identifier to a node scan or policy, allowing you to easily distinguish scans or policies from others. For example, after a deployment, you could tag the associated node scan results as 'Post-deployment' to identify the significance of the scan. For policies, you could tag a particular policy version as 'Prod' to distinguish the purpose of each policy version. For more information, see Tagging.