Reference: Remote authenticated scanning

General best practices

The following sections provide recommendations for setting privileges for the Tanium Scan Engine (TSE) so Comply can perform remote authenticated scans with optimal results and minimal errors.

Background: The Tanium Scan Engine

The Tanium Scan Engine (TSE) is designed to collect all the information required to evaluate SCAP rules and OVAL definitions. When the TSE encounters an issue that prevents it from collecting required information, for example an access control issue or other error, that issue will be reflected in the results. This can mean "unknown" or "error" results for rules in some cases. In other cases, these errors may not impact the evaluation of a specific rule at all. The result always depends on a combination of the state of the machine being scanned and the construction of the rule logic.

Background: Privileges

When planning privilege levels, the principle of "least privilege" directs you to only grant the exact rights required to perform a designated task. But in the context of vulnerability and configuration compliance scanning, the "least" privilege required to collect every conceivable piece of configuration data is total access to everything. This means unrestricted root-level access on Unix, and Administrator-level access on Windows. The practical reasons for this general conclusion are discussed below for each supported operating system.

You are free to use more restricted accounts for scanning with the TSE, but in doing so you must accept that this can (and in most cases will) result in at least some of the aforementioned unknown and error rule results. Therefore, a best practice for avoiding unknown and error results is for the TSE to be run using the highest privilege level available.

Microsoft Windows

On Windows, remote authenticated assessments should be configured using an account that is a member of the target machine's built-in Administrators group (S-1-5-32-544). For remote access questions, see Troubleshooting remote login issues on Windows.

While it is theoretically possible to create Windows accounts with very fine-grained access controls and with only the exact permissions the scan engine requires without being a member of the Administrators group, this has never been accomplished in the field despite many attempts by Tanium, the engine vendor (Joval), and OEM customers. Therefore, the TSE now checks for the presence of the Administrator role in the runtime user principal to determine whether the scanner has the necessary privileges to attempt certain actions, such as mounting user registry files or reading runtime environment data from running processes.

Unix/Linux/macOS

On Unix-type operating systems, the super-user (root) account has access to all resources on the machine. This is the account that should be used to invoke remote authenticated scans. For remote scanning purposes, the TSE can use either sudo or the su command to gain root access since the root account is not typically permitted to have login rights via SSH. The selection of sudo or su is chosen when creating the credential.

It is possible to use a sudoers file on Linux to control which commands certain users are permitted to employ when using sudo. Tanium recommends not attempting to use this mechanism to restrict the commands available to the TSE for scanning purposes. The TSE dynamically constructs complex commands based on a combination of the SCAP content and detected configuration data on the system itself at scan-time. It wraps them inside invocations of ‘/bin/sh -c’ (for a number of reasons), which would render such an allow list meaningless.

Although the TSE only reads configuration data (and only ever writes to temporary files), it must invoke certain commands that can be used to either get or set configurations. Even though Unix filesystem extended permissions could theoretically make it possible to create a user with execute permissions only in the Tanium Scan Engine's command vocabulary, at a practical level, the architecture of the Unix operating system makes creating such a user highly impractical.

Cisco

Cisco operating systems feature configurable levels of access control up to "level 15," which is the highest level of access control. Administrators can configure the OS to allow different commands and sub-commands at different privilege levels. When a command is invoked that is configured for a privilege level higher than the current login context, the Cisco operating system behaves as if the command does not exist.

There is no way of knowing why a command does not run as expected on Cisco operating systems. It could be because of a privilege level issue. It could also be because the command does not exist on the version of the OS or because some feature is not enabled. Cisco commands do not even have exit codes.

For this reason, the TSE cannot obtain definitive findings on an arbitrarily configured Cisco device unless it has level 15 access privileges. Comply is not able to make representations about the accuracy of rule results when run with lower privilege levels.

Technically, it should be possible to create a privilege level that has permissions to run all the show commands that the TSE requires, in addition to the pwd and terminal commands, and such an account could be used for the purpose of scanning with the Tanium Scan Engine. However, such an account would need to enter this privilege level by default because its elevation implementation is currently written to only request level 15 privileges.

VMware and ESXi

For ESXi endpoints, when you configure the assessment, you target the IP address of VMware vCenter managing the ESXi hosts. You cannot connect directly to an ESXi host. Once the scan completes, the Endpoint Statistics will show the ESXi endpoints. Comply does not know about those ESXi endpoints until the scan is run. For best results, it is recommended that the account being used for the scan have the Administrator role to ensure that all rules/checks can evaluate as expected.

Troubleshooting remote login issues on Windows

There are several possible reasons a remote authenticated assessment may fail on a Windows target:

You have provided an incorrect password.
You are attempting to log in as a user who is not a member of the “Administrators” or “Remote Management Users” groups. In most cases, only members of these groups are able to log in via WS-Management.
The target machine is configured to disallow the “Negotiate” authentication method. To view permitted authentication methods on the target, run the command: winrm get winrm/config/Client/Auth
In certain situations, when the target machine is joined to a domain, logging in using a local machine account is disabled. This problem has been observed after upgrading from Windows Management Framework 1.0 to 2.0; for example, on a Windows 2008 (non-R2) Server machine.

To enable local account logins in this situation, you must create the following:
- LocalAccountTokenFilterPolicy registry value:Key Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- Value Name: LocalAccountTokenFilterPolicy
- Type: DWORD
- Value: 1
Ensure the necessary firewall rules are in place to allow the satellite to connect to the remote target using WinRM on TCP port 5985. WinRM must be enabled on the remote target.
Review the Host and network security requirements for unmanaged endpoints.

Security best practices

While performing remote authenticated scans (RAS), it is necessary for IT and security organizations to maintain the necessary level of visibility and control as these scans carry more risk than local scans.

When a new, unmanaged endpoint is detected on a network, there is currently no way for a program to determine whether this endpoint is legitimate or belongs to an attacker. If a tool attempts to perform an authenticated scan against an attacker-controlled endpoint, the attacker could potentially learn credentials that are valid on other endpoints and use them to pivot from a network-based position to gain unauthorized access to endpoints targeted by the scanner. See https://www.atredis.com/blog/2020/1/26/flamingo-captures-credentials for information on how IT/Security products spray credentials.

Tanium has implemented several mitigating controls within Comply to enable customers to use this feature while limiting the risk they are exposed to. The following section documents the security best practices when using remote authenticated scans and how users may configure RAS to best mitigate risk.

First and foremost, Tanium recommends that customers prefer local scans over remote scans. If an endpoint can be managed by the Tanium Client, installing the Tanium Client on this endpoint is the preferred and most secure way.
When setting up credentials for RAS assessments, it is recommended you select SSH Key as opposed to Password when possible. The risk associated with a malicious actor stealing a public key is negligible compared to stealing a password. Currently, SSH authentication is only available for non-Windows endpoints.
When using SSH Keys and password credentials (non-Windows) for RAS assessments, it is recommended you also use fingerprint comparison enabled using the Trust on First Use check box on the assessment page. With this feature, Comply trusts an endpoint on the first connection and collects the SSH fingerprint. The endpoint must then present the same SSH fingerprint on every future connection or Comply will log an error that the fingerprint has changed and the endpoint may be compromised. Endpoints with fingerprint mismatch errors are not scanned.
You should regularly rotate passwords used for remote authenticated scans, but do not reuse those credentials for endpoints that are not targeted by RAS to limit the extent of horizontal pivot.
Avoid attempting a large number of authentications against individual endpoints (the kitchen sink approach). If there is one malicious endpoint on your network, and you have an assessment that contains 100 password credentials, the scan could potentially try all those credentials against the malicious endpoint and then all 100 of those credentials are compromised. This approach could also have performance implications. Instead, plan your assessments in a logical, purposeful way that uses a targeted, limited number of credentials for each scan. For example, you could group routers together in one assessment, configure one credential list for the group, and not use this list for other assessments.
Avoid usage of the Include newly discovered endpoints on recurring scans option when feasible. By default, if scans are recurring, Comply only scans endpoints that were reachable during the initial scan. If new endpoints come online, they are not scanned unless you change the assessment's targeting or select to automatically include new endpoints. This means that even if an attacker gains unauthorized network access, Comply scans will not automatically send credentials to the attacker controlled endpoint unless a Tanium user instructs it to do so. While this option has the benefit of not having to change the configuration if a new endpoint comes online, it introduces a significant risk as you are going to authenticate against an attacker’s endpoint and compromise your credentials.