Remote Security Device Management

Overview

Remote Security Device Management (RSDM) is a service which collects and manages information about the device where the virtual credential on the device is managed by vSEC:CMS. It will also act as a messaging service where it provides the following functions:

• Trigger virtual or physical credential issuance on a device;
• Block issuance of credential on a device;
• Add device to blacklist;
• Trigger the removal of a virtual credential on a device.

An overview of the architecture is provided in the diagram below.

RSDM is a Windows native service. It communicates with the vSEC:CMS server component either through a SOAP interface or through a gRPC interface. It is recommended that you use gRPC as this has higher performance advantages over the more traditional SOAP protocol.

Installation

RSDM is packaged into an MSI installer. See the article Installing the vSEC:CMS MSI Client for details on how to use the MSI to install RSDM.

Configuration

If you will use RSDM then from Options - Device Management you will configure which features you wish to use.

Enable Enable automatic device registration checkbox if RSDM is to be used. If it will be required to check that the device that is to be managed has a UUID in Active Directory then enable the checkbox Verify computer UUID in AD. From the dropdown list select the AD that should be checked for the device UUID. This will result in the vSEC:CMS running the following LDAP query:

(&(objectClass=COMPUTER)(sAMAccountName=<COMPUTER-NAME>)(netbootGUID=<COMPUTER-UUID>))

Where <COMPUTER-NAME> is the name of the computer/device in AD as stored in the attribute sAMAccountName and <COMPUTER-UUID> is the UUID of the computer/device as stored in AD in the attribute netbootGUID. The UUID will be checked against the value stored on the client. The client UUID will be retrieved using Windows WMI command.

For the Trusted certificate(s) section enable Force collecting certificates checkbox if the device will have a machine certificate available whereby it is required that only devices with valid machine certificates will be allowed to be managed. Enable the Filter for key usage checkbox which will configure the vSEC:CMS to check the device certificate that is sent from the client to the server via the RSDM service. The certificate key usage can be checked to ensure specific key usage is set for the device certificate. For example, if the filter is set to 128 (decimal) in the Must have field this means that the certificate should have key usage of digital signature. It is possible to add the root or sub CA certificate of the issuer CA to validate that the device certificate is issued from the same CA. Click the Add button and select the root or sub CA to get the issuer information. The setting Import device certificates to vSEC:CMS managed certificates repository is for future functionality and shown here for information purpose only.

In the TPM section enable the Export endorsement key certificate if it is required to store the certificate for it to be used in the future for key attestation. Enter the full path on the vSEC:CMS server where these certificates will be stored in the Export to (server) field.

If it is required to not allow the issuance of a virtual credential where the TPM is vulnerable to the Return of the Coppersmith Attack, commonly referred to as ROCA, then enable the checkbox Blacklist devices with ROCA affected TPM for VSC enrollment. During the registration of the device if the TPM is vulnerable to ROCA then the device will be enabled as black listed. This will mean that it will not be possible to issue a virtual credential on the device while in this state. If it is required to allow the device to be issued then from Repository – Device Management – Managed Devices select the device and right click and select Edit Flags. Uncheck the flag Device is black listed to allow the device to be issued with a virtual credential.

In the Device name section, it is possible to configure specific information about the name for the device if required. If it is required to have a specific name for the specific device, where the device name is stored in registry on the device, enable the Read device name from registry checkbox and enter the path to the registry key. The registry key will need to be in HKEY_LOCAL_MACHINE. For example, if the device name registry key was:

HKEY_LOCAL_MACHINE\device\mydevicename

Then you would enter in the Registry key field: device\mydevicename

Where mydevicename is the key that stores the device name. This key should be of type String.

Alternatively, you can read the device name from the system environment variable. The variable needs to be a System variable in this case.

In the UDP Broadcast Setting enable the Use computer name which will result in the server side sending the UDP broadcast message only to the device hostname that was used during the registration of the device. Enable the Use broadcast address and enter an IP address in the field provided. It is possible to enter lists of IP addresses that you want the broadcast message to be sent to. For example, if your client devices are in a 192.168.0.255 and 172.16.0.255 range then all clients with an IP address of 192.168.0.XXX or 172.16.0.XXX will receive the broadcast message. In this case the IP addresses should be separated by ';' (semi-colon) character. If the Use computer name and Use broadcast address checkboxes are enabled the vSEC:CMS will first try to send a broadcast message to the computer device that is selected. If this fails for whatever reason then the vSEC:CMS will send a broadcast message to every computer device in the IP range configured in Use broadcast address. The broadcast packet will contain the device ID which each device will then check to see that the device ID matches their ID and only the device that has the corresponding device ID in the packet will send a response to the server requesting details on what it needs to perform.

Click the Test button to perform a test UDP message. This can be useful when troubleshooting a communication issue. For example, if a device that was registered as MYPC.MYDOMAIN.local then enter this value in the Hostname field and enter the port number that the client is configured to listen on in the Port field.

On clicking Ok if the message is successfully sent you will see a success dialog.

On the client device in the event viewer you should see Source entries from vSEC:CMS RSDM indicating that the communication channel is functional as required.

In the Secure Device Management Setting section, you can configure the management around the behavior when a device is managed through the RSDM mechanism. By default, a device that is managed through the RSDM mechanism will be automatically set to a blocked state once an issuance request has been sent from the server side to the managed device. Therefore, the setting Automatically block devices for new issuance after issuance has been performed will be enabled. An operator will need to reset the blocked flag if it is required to send a new issuance command to the device. If it is required to not use this feature then uncheck this setting. If it is required to check that the user on the device is assigned as the primary user of that device in an attribute in AD then enable Verify primary user assignment in AD when issue credentials checkbox. Select the AD to be used from the available list of ADs in the drop-down box.

How RSDM Works

In this section we will explain in detail how RSDM works if used in your environment.

Registration

When a client device has RSDM installed on it, the RSDM client service will send a message to the backend RSDM service informing it that it wants to register as a device. Depending on what was configured on the server-side from Options - Device Management various checks will be made and when these have been successful you will see the device as registered under Repository - Device Management - Managed Devices. Additionally during the registration process further information about the local device will be sent and stored on the server side. The information sent will be:

• Details on the TPM on the device;
• Details on WHfB if this is deployed on the device;
• Details on the vSEC:CMS software installed on the device.

During the registration process the client will determine how it will communicate with the server. This will result in the RSDM client either polling for messages on the server or the server pushing messages to the devices.

Push Mechanism

If UDP is configured the RSDM client will ask the server to send it a test UDP message to see whether it can communicate through UDP broadcast messaging at startup. If the client does not receive the message within 5 seconds then it will determine that UDP is failing and it will fall back to polling on the server. If UDP is to be used then the client will sit and wait for messages to be sent from the server-side.

The RSDM service on the client device will then need to be configured to listen on a port for UDP broadcasts from the server. The registry key name that needs to be set is rsdm.msg.notify.broadcast.port and it is a DWORD (decimal) value that should be the port number that the client device will listen on. The key should be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_RSDM\Service]

When the system is configured in this way you will see information in the Details section for a selected device from Repository - Device Management - Managed Devices. The Online status will show that the current device is configured to use push mechanism. In the Message transport parameter you will see that the polling mechanism is disabled and in the Listening on UDP port you will see the port number that the client device is configured to listen on.

Polling Mechanism

By default, RSDM clients will poll the server in order to check if any messages are available to execute. This RSDM service will send a message to the server every configured millisecond (ms) to the server. The polling configuration can be seen from the Repository - Device Management - Managed Devices page and selecting a managed device and right clicking to select the Details option. The values displayed for Message transport parameter indicate what is configured for the polling frequency.

For example, if the Message transport parameter had a value of 100, 10 / 600000 / 60000, 2 ms ENABLED. The meaning of each value here is described below:

100, 10

This means that the client device will send a message every 100 ms to the server asking if there are any execute messages waiting on the server for this device. When the server gets this message, it will wait 10 ms to see if it receives any execute commands from an operator in that 10ms window. If an execute operation is sent, say within 5 ms, then the server will respond to the client with the execute message. If there is no execute message sent within the 10 ms then the server will respond to the client informing them that there is no execute message to be processed.

/ 600000 /

This is the period in ms that the polling settings 100, 10 (above) will be performed for. After this period the settings 60000, 2 will be in effect.

60000, 2

This means that the client-side device will send a message every 60000 ms to the server asking if there are any execute messages waiting on the server for this device. When the server gets this message, it will wait 2 ms to see if it receives any execute commands from an operator in that 2ms window. If an execute operation is sent, say within 1 ms, then the server will respond to the client with the execute message. If there is no execute message sent within the 2 ms then the server will respond to the client informing them that there is no execute message to be processed.

ENABLED

This means that the polling mechanism will be enabled and constantly performed as per the configuration. It is possible to disable the polling mechanism (see below) and then you would see DISABLED.

The default settings can be changed on the server via registry key. The registry name is rsdm.msg.notify.settings and it is a String value and needs to be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]

Therefore if you wanted to change the default settings to, for example, 200, 10 / 600000 / 60000, 2 ms ENABLED then the value that you should set in the registry key should be 200,10,600000,60000,2,1. If you wanted to disable the polling then you would set it to 200,10,600000,60000,2,0. 

Manage Credential on Device

When deciding on how to issue your credentials on the device 3 different approaches are possible.

Centralized Management

In a centralized management approach an operator will need to manually select the device in the repository table from Repository - Device Management - Managed Devices and send an issuance message to the device informing it that the device can now be created and issued with a credential (either virtual or physical credential).

See the article RSDM Centralized Management for further details on how this would be configured and used.

Non-Centralized Management

In a non-centralized management approach the end user will start the issuance themselves from the vSEC:CMS User Self-Service (USS).

See the article Manage Virtual Credentials using vSEC:CMS User Self-Service for details on how this would be configured and used.

Automatic Credential Issuance

In automatic credential issuance approach the credential issuance will be automatically launched when the end user logs onto their device.

See the article RSDM Automatic Credential Issuance for further details on how this would be configured and used.

Batch Operations

It is possible to perform batch operations from Repository - Device Management - Managed Devices. The batch operations that can be performed are issue, retire, delete and synchronize. It is recommended to limit the size of batch operations to a maximum of 100 as putting too high a number of batch operations will put additional load on the server side which could have adverse effects.

Selections can be manually selected from the table or an input file can be used. If an input file is used the details inside the input file will need to match the contents of a column in the table. For example, if it is required to batch select based on the Device ID in the table then right click on the header for Device ID and select Add selection item(s) by “Device ID”. You will then be prompted to select the input file. If the Device IDs that are to be batch selected are, for example, 4-0091789 and 4-0091790, then the input file should contain the entries as below:

4-0091789

4-0091790

Each line in the input file should correspond to a Device ID in this example. These entries will then be automatically selected and the batch operations of issue, retire, delete and synchronize could be performed.

Invalidate RSDM Messages

RSDM issuance messages can be configured to timeout after a configurable period of time. For example, clients, for whatever reason, may not always perform the actual issuance when the issue command is sent from the server. Then there may be a considerable buildup of clients who potentially could start issuing concurrently which in turn could result in heavy load being put on the server. By configuring RSDM messages to expire gives the operators more control during the deployment stage.

In order to configure this feature a registry of type DWORD named rsdm.msg.expiry.enabled and a value of 1 needs to be set here on the server:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]

Additionally, the period of time in seconds that the message should stay valid for needs to be set through registry in the same location. This is a DWORD named rsdm.msg.expiry.period.sec and the value set as decimal. For example, if you want the message to expire after 1 minute then you would enter a decimal value of 60. If a client is then sent an issue command from the server the status flag for the message will be in Issuing state if the client is online. If after 1 minute the client does not act on the issuance command the server will invalidate the message on the server. If the client after this period then tries to start the issuance command the message status flag on the server will be in an IssuingBlocked state and the client will not be able to issue the credential.

In parallel on the client device side it is possible to configure an expiry timeout. In order to configure this feature a registry of type DWORD named msg.expiry.sec and a decimal value in seconds should be entered for the period after which the client should invalidate the message. On a 64-bit OS the value should be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Versatile Security\vSEC_CMS_RSDM\Service]

On a 32-bit OS the value should be set here:

[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_RSDM\Service]

If this is configured on the client, and the client is online, and the server sends an issuance command but the client does not actually start the issuance within this configured period on the client then if the client attempts to start the issuance after this the actual issuance will fail. On the server side the device flag status will be put into an IssuingBlocked state.