- Only enable User-ID on trusted zones
By only enabling User-ID on internal and trusted zones, there is no exposure of these services to the Internet, which helps to keep this service protected from any potential attacks. If User-ID and WMI probing are enabled on an external untrusted zone (such as the Internet), probes could be sent outside your protected network, resulting in an information disclosure of the User-ID Agent service account name, domain name, and encrypted password hash. This information has the potential to be cracked and exploited by an attacker to gain unauthorized access to protected resources. For this important reason, User-ID should never be enabled on an untrusted zone.
- Specify included and excluded networks when configuring User-ID
The include and exclude lists available on the User-ID Agent as well as agentless User-ID on PAN firewalls can be used to limit the scope of User-ID. Typically, administrators are only concerned with the portion of IP address space used in their organization. By explicitly specifying networks to be included with or excluded from User-ID, we can help to ensure that only trusted and company-owned assets are probed, and that no unwanted mappings will be created unexpectedly.
- Disable WMI probing in high security networks
WMI, or Windows Management Instrumentation, is a mechanism that can be used to actively probe managed Windows systems to learn IP-user mappings. Because WMI probing trusts data reported back from the endpoint, it is not a recommended method of obtaining User-ID information in a high security network. It is also usually not necessary. In environments containing relatively static IP-user mappings, such as those found in common office environments with fixed workstations, active WMI probing is not needed. Roaming and other mobile clients can be easily identified even when moving between addresses by integrating User-ID using Syslog or the XML API, and can capture IP-user mappings from platforms other than Windows as well. On sensitive and high security networks, WMI probing increases the overall attack surface, and administrators are recommended to disable WMI probing and instead rely upon User-ID mappings obtained from more isolated and trusted sources, such as domain controllers. If you are using the User-ID Agent to parse AD security event logs, syslog messages, or the XML API to obtain User-ID mappings, then WMI probing should be disabled. Captive portal can be used as a fallback mechanism to re-authenticate users where security event log data may be stale.
If WMI probing is used, it should not be enabled on external untrusted interfaces, as this would cause WMI probes to be sent outside of your network that contain sensitive information such as the username, domain name, and password hash of the service account configured for use by the User-ID agent. This information could potentially be exploited by an attacker that could then penetrate the network to gain further access.
- Use a dedicated service account for User-ID services with the minimal permissions necessary
User-ID deployments can be hardened by only including the minimum set of permissions necessary for the service to function properly. This includes DCOM Users, Event Log Readers, and Server Operators. If the User-ID service account were to be compromised by an attacker, having administrative and other unnecessary privileges would expose the enterprise to additional risk of destruction or theft of sensitive data. Domain Admin and Enterprise Admin rights are not required to read security event logs and consequently should not be granted.
- Deny interactive logon for the User-ID service account
While the User-ID service account does require certain permissions in order to read and parse Active Directory security event logs, it does not require the ability to log on to servers or domain systems interactively. This privilege can be restricted using Group Policies, or by using a Managed Service Account with User-ID (See Microsoft Technet for more information on configuring Group Policies and Managed Service Accounts.) If the User-ID service account were to be compromised by a malicious user, the potential attack surface would be greatly reduced by denying interactive logon.
- Deny remote access for the User-ID service account
Typically, service accounts should not be members of any security groups that are used to grant remote access. If the User-ID service account credentials were to be compromised, this would prevent the attacker from using the account to gain access to your network from the outside using a VPN.
- Configure egress filtering on outbound internal traffic
Prevent any unwanted traffic (including potentially unwanted User-ID Agent traffic) from leaving your protected networks out to the Internet by implementing egress filtering on perimeter firewalls. In sensitive environments, white listing trusted and business essential applications diminishes the possibility of allowing unwanted traffic, and also helps reduce possible vectors that could be used to exfiltrate data.