Security Posture Checking

  • 17 November 2022
  • 0 replies
  • 381 views

Userlevel 4

Security Posture Checking

 

by Robert Plamondon

Last updated on September 5, 2023 by Robert Plamondon

 

To ensure that it is running on a device that meets your organization's security standards, the Workspot Windows Client can perform an optional security posture check before allowing an end-user to connect to remote Workspot desktops and apps. This Posture Check is set in Workspot Control as part of a Security Policy. 

 

 

Posture Check Capabilities

 

The Windows Client can check for compliance with the following requirements:

  • Windows version: The minimum release number for Windows 10 and 11.
  • Windows Update: How out of date the operating system is compared to the latest Microsoft Update patch.
  • Antivirus Enabled: Whether an antivirus package is currently running.
  • Firewall Enabled: Whether a firewall is currently enabled.
  • Connected via Wi-Fi: Some organizations allow only wired network connections.
  • Running in a VM: Some organizations do not allow end-users to run Windows in a virtual machine. (Also, the Workspot Windows Client is not supported on virtual machines.)
  • Connection Origin (Geolocation): Whether the Client seems to be running in an allowed (or disallowed) country. (Note: this feature is not currently available.)
  • Domain Joined: Whether Windows is joined to a mandatory AD domain.
  • Processes/Services: Whether specific processes and services are running.
  • Custom Script: Whether an optional custom script reported success.

 

Posture Check Limitations

  • Posture Check is supported only on the Workspot Windows Client.
    • Windows 5.1 adds the ability the check a list of processes and services and to run a custom script to perform your own tests.
    • Geolocation is visible but grayed out in the Control UI. It is planned for a future release.
  • Posture check adds tens of seconds of delay to the sign-in process.

 

How it Works

When an end-user signs into the Workspot Windows Client and launches a desktop or app, the client performs a posture check as the first step of the sign-in process. This is shown in the connection progress popup:

 

If the check succeeds, the Client connects the user to the remote resource. If it fails, it gives a warning or failure popup, depending on whether the Security Policy is configured to warn the user or deny access. The warning popup looks like this, and pressing "Continue" connects the user to the Workspot desktop/app normally:

 

The failure message is similar, but the user cannot connect:

 

 

Configuring Posture Check in Workspot Control

 

"Windows Posture Check" is near the bottom of the Security Policy page in Workspot Control.

  • To edit an existing Security Policy, go to "Policies > policyname." The opens the Edit Policy page.
  • To create a new Security Policy, go to "Policies > "Add a New Policy." This opens the Add Policy page, which is functionally identical to the Edit Policy page.
    • Give the policy a name and select "Security" from the "Policy Type" field. This will reveal the Posture Check options.
  • Posture checking is disabled by default. For it to perform any checks, you must set the master Enable to "Yes" and enable at least one of the individual checks. See the screen image below:

 

 

Windows Version

This lets you set a minimum version number (build number) for Microsoft Windows 10 and 11. Checks for the two operating systems are configured independently.

  • Allowed states: Don't Check, Warn, and Deny.
  • Build number: For instance, Microsoft Windows 10 version 22H2 has build number 19045.2311. Posture Checking uses only the integer part of the build number (19045). See Microsoft's Windows release health page for build numbers for other Windows 10 and 11 releases.
  • Message: You can change the Warn/Deny message if desired.

The build number specifies the lowest-numbered version the Workspot Windows Client will accept without complaint. If an end-user attempts to connect to Workspot desktops or apps on a Windows system running an earlier build, the Client will give a warning popup if the version check is set to "Warn" and will give an error popup if it's set to "Deny."

Windows Update

The Windows Update option lets you warn or deny users running a version of Windows that was released more than the specified number of days ago. 

Antivirus and Firewall

The Client checks with Windows to see if antivirus and firewall protection are active.

 

 

Client Environment (Miscellaneous Checks)

 

Additional, more specialized tests are also available:

  • Connected via Wi-Fi. Used this if you wish to discourage or forbid users from connecting over anything but wired network connections.
  • Running in a VM. If you don't allow users to connect from a virtual machine, you can enforce this here. The Client can detect most popular VM types.
  • Geolocation (connection origin): Not yet supported as of Windows Client 5.1.0. Checks the apparent location of the Client. Use this if you wish to allow connections only if they appear to originate in certain countries or to forbid a list of countries. This feature uses three-letter ISO codes such as "USA". Separate multiple entries with commas.

Note: lowercase letters and whitespace are not allowed.

  • Domain joined: Use this if you only recommend/allow end-users to connect via Windows computers that are connected to an approved AD domain. This can help prevent random computers from connecting to your Workspot desktops.

Process/Service Checks

Note: These checks are the only occurrences of horizontal scroll bars in the Control UI. The mandatory “Machine Type” field and the optional “Message” field may not be visible until you scroll.

Starting with Workspot Windows Client 5.0, you can also check to see if specified processes and services are running, and setting actions either for when they are running or when they are not. 

Only system processes and those owned by the current user are checked. (The current user is, of course, the account the Workspot Client user just signed into.)

This is not as flexible as specialized malware-detection packages, so the preferred solution is to install such a package and use Process/Service checks to verify that it is running.

Custom Script

Starting with Workspot Windows Client 5.0, you can specify a custom PowerShell script for the Client to download and run, with success/failure determined by its exit status. Upload the script to Control via the “Upload File” link and provide the script’s SHA256 checksum. The Client will run these tests along with whatever other posture-check tests you specify.

 


0 replies

Be the first to reply!

Reply