Expected behavior with Xshield agents

The following sections list the expected behavior when you manage Xshield agents.

Xshield agents (both Microsegmentation and User Access) are not built to manage Dockers or similar Containers (at any depth) in nested virtualization environments. All Xshield features are designed to work only at the first level of virtualization. Although the agent may collect some telemetry data at other levels and display it on the Xshield UI, this data may be inaccurate.

CPU usage on agents running Xshield depends on the resources available on the agent. The CPU utilization can momentarily increase up to 50% while enforcing the policies on agents low on resource. For example, agents with single CPU and 2 GB RAM might have high CPU utilization. The CPU utilization will be minimum if the agents are not low on resource.

For Windows assets that use Xshield agent versions 8.5.0.49 and older, the agent files are stored at C:\Windows\System32. When such assets are subjected to Windows Update, the update service deletes the Config folder located at C:\Windows\System32.
If you Upgrade the Xshield agent to version 8.5.2.6 or newer on Windows-updated assets, the existing Xshield policy configuration is not restored. You must manually add the Xshield policy configuration to the native firewall on the assets.

From the Xshield agent version 8.5.2.6 version onward, on Windows assets, the agent files are stored at C:\Program Files\ColorTokens\LGM and not C:\Windows\System32. So, if you downgrade the agent from version 8.5.2.6 (say 8.5.0.49) and decommission the asset, the older uninstaller does not delete the LGM folder C:\Program Files/ColorTokens. You must manually delete the LGM folder.

Introducing a Web proxy server to relay communication from newly added workloads (using agents of version 8.6.0.7 and later) or workloads that were upgraded (proxy parameters were added manually) before explicitly enforcing the Web proxy port rules on the workloads moves the workloads to the Suspended state. The workloads are not reachable to the Xshield instance until the Web proxy port rules are enforced on the workloads. The Web proxy port rule corresponds with the Web proxy port number you specify to install the Xshield agent or update the proxy parameters on an existing agent.
On instances that use a Web proxy server to relay communication from workloads, the agents capture the traffic flow records between them and the Web proxy server. For such instances, the traffic flow details you see on the Visualizer and Flow Explorer page include traffic flow records between the agents and the Web proxy server. The relevant widgets on the Dashboard page and the reports also display some additional data.

Currently, User assets cannot leverage the Web proxy support feature for Xshield agents. You can install the agents with proxy parameters (using user agents of agent version 8.6.0.6) or upgrade existing user assets (add proxy parameters manually). User assets can be successfully managed from Xshield; however, the agents do not relay communication to the instance through the Web proxy server.

Xshield evaluates a Policy Tampering attempt at the workload level and not the interface on the workload. So, if an Xshield policy rule is enforced on multiple interfaces of a workload and the rule is tampered with on One or most of the interfaces on the workload, Xshield does not report this as a ‘Policy Tampering attempt’ on the workload’s fly panel on the UI. However, Xshield auto-reverts the tampered policies on the workload to the original policies.
Xshield reports a Policy Tampering attempt on the UI only when the rule is modified or deleted on all the interfaces on the workload.
The agent manages the rules in the native firewall on the workload. The agent adds Xshield rules to the rules that existed in the native firewall when the agent was installed. This 'existing rules' snapshot is always from the time when the agent was installed.
The agent is designed to use the 'existing rules' snapshot as the rules that existed on the native firewall when it recovers from an unexpected stop/crash and when the workload is moved to the Observe mode from the Enforce mode. You will lose any local rules you added to the native firewall after the agent was installed.

When enforced workloads encounter a high volume of network traffic (especially Blocked traffic), and the CPU utilization goes above 60%, host firewalls cannot log all of the Blocked traffic to the workloads. Because the Xshield agent depends on the host firewall logs for reporting the policy action on traffic, the agent flags the Blocked traffic that the native firewall did not log as Unauthorized traffic.
So, although the traffic that was not logged by the host firewall is blocked on the workloads, on the Xshield UI, Visualizer and Flow Explorer display this traffic as Unauthorized.
When Windows Defender Firewall is turned OFF on enforced workloads, the workloads are not protected with the enforced Xshield policies. Windows Defender Firewall must always be turned ON on the enforced workloads.