For on-premises deployments, the UpGuard Core appliance is a virtual appliance deployed in a VMWare environment.
The appliance is the central location for all processing in the UpGuard Core 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.
For customers, this appliance is a black box, and access is only allowed by UpGuard employees. This is to ensure the stability of the platform and take the responsibility off of any internal team.
For hosted deployments, the UpGuard Core appliance is managed by UpGuard.
A connection manager is a stateless server that gathers jobs from the appliance, scans nodes agentlessly, and send scan results back to the appliance.
The connection manager comes in two forms:
- Windows, which handles WinRM and database (ODBC) scan jobs as well as Azure node scanning,
- Unix/SSH, which handles SSH scan jobs (for linux servers and network devices) and all other cloud services.
The Windows connection manager is a service running on any Windows Server in your environment, while the Unix connection manager is a black box (no logins permitted) virtual appliance that runs in VMWare.
The agent software is a service that runs on a node to run local scan jobs and send the data back to the UpGuard Core appliance.
A node is any scannable system in your environment. This could be any of the following:
- Windows Server
- Linux server
- Network Device (router, firewall)
- Component in a Cloud Service (AWS, GCE, Azure), for example an EC2 instance, a BigQuery configuration withing a GCP project.
A node group is a collection of one or more nodes that share some common property. They might all be Windows nodes, all nodes with a database installed, all nodes within a particular zone, etcetera.
Node groups provide the following roles and benefits:
- Easily locate nodes with a common property and list them together.
- Define common scan options for a particular grouping of nodes.
- Difference configuration within groups of nodes.
- Assign policies to a common group of nodes.
A node can belong to zero or more node groups with no limits. However, note that any node group that a node belongs to will inherit the scan options defined for that group.
An environment defines when a node will be scanned. A node can belong to one and only one environment, and each environment has a scan job automatically created (initially at a random time) when the environment is created.
A node is assigned into the Default Environment if not otherwise specified and can be moved between environments at any time. Common environments we see are
For more information on Environments, please view our guide on Environments.
A node scan is a snapshot of a node at a certain point in time. These can be done on demand through the UI, on demand through API calls, or through a scheduled environment scan.
The scan returns a list of configuration items that are divided into sections.
In the scan results (in the UpGuard Core UI), 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
ServiceKeys - depending on the node type.
A configuration item is a single piece of configuration on a node. For example, this could be:
- A file
- An environment variable
- A service
This is not an exhaustive list, and the list of configuration items returned will be different for each node type and the scan options defined for that node’s node groups.
Each configuration item has any number of attributes. For example, a file configuration item may have attributes for:
- Access permissions
- File contents
- Last modified time
- Owner information
A policy in UpGuard Core consists of a collection of checks to verify that a configuration is in a desired state.
As an example, you may want to know that your
C:\Windows\System32\drivers\etc\hosts file is in a specific state. You can setup a policy to verify that the checksum for this file matches a certain value, that the file
has the correct ownership and that it’s readable by the right user accounts. If attribute changes incorrectly, it will manifest as a policy failure (which you can be notified of).
A check is a simple confirmation that an attribute of a configuration item is in some state.
For example, the
status attribute of the
Internet Information Services service configuration item can be checked to confirm it is
Running. If the service is in any other state, this check will fail, which will subsequently fail the entire policy.
To see all of the possible checks for an attribute, see Policy Checks