UIM best practices for secure environments
Article ID: 111575
Updated On:
Products
Issue/Introduction
The following document contains security-related recommendations/best practices for providing additional layers of security for CA UIM environments.
Security Administrators with an interest in adding additional layers of security to a CA UIM installation may wish to implement one or more of these recommendations depending on your specific business needs.
Environment
Release:
UIM 9.x or higher
Resolution
1. Use common firewall and IT table best practices to disallow or block communication between hosts and ports in your environment where communication would not typically be expected or authorized. In general, all traffic to and from all ports should be disabled by default, only enabling traffic between hosts you know to be valid. In the case of CA UIM, traffic should be allowed between a hub and its robot on ports 48000-48030, but as leaf node robots are not expected to freely communicate, those ports should be blocked between hosts where robots are installed. More information on the ports that the CA UIM requires to be open can be found here:
General information on firewall best practices can be found here:
2. Carefully protect privileged and/or administrator level access to any system where CA UIM is running by following the standard industry best practices. Recommendations include:
a. Limiting the distribution of privileged access to any server where CA UIM is running as a privileged user.
b. Enforcing policies for the strength and longevity of privileged access passwords.
c. Ensuring that the privileged access passwords are not reused between hosts.
3. Use CA UIM hub to hub tunnels between all hubs out with or between secure data centers.
a. Ensure that encryption is enabled, and that a medium or high-level cipher which supports TLS 1.2 is chosen.
b. The use of X.509 certificates generated for a specific IP address is recommended, if it is important, to prevent unauthorized hubs from joining the CA UIM deployment.
c. If necessary, use the CA UIM hub to hub tunnel Access List functionality to whitelist and/or blacklist CA UIM communication from any untrusted portions of your CA UIM deployment.
HUB IM GUI Reference
...for more information. This is an advanced-level functionality for customers to restrict the usage of CA UIM commands that allows the information flow between hosts in their deployment. For example, it can be used to ensure only monitoring data (via hubpost for example), and essential routing information (nametoip) flow from an edge node hub to the rest of the deployment and that edge node robots may be implicitly denied access beyond their own hubs. This complements the firewall best practices and is only recommended for users with a deep understanding of CA UIM operation.
4. Carefully protect the CA UIM installation and its files using file system privileges to prevent access beyond CA UIM processes, and trusted administrators. Particularly, the directories where CA UIM configuration files are kept (for example: /opt/nimsoft/robot) should only be writable/ readable by the user CA UIM processes run under, or other trusted users.
5. In untrusted portions of your CA UIM deployment, consider installing and running the CA UIM robot and monitoring probes under non-privileged users or a user who is granted only specific privileges to perform monitoring (for example, process monitoring). Running as a non-privileged user is supported, and information on how to do this can be found in the robot installation guide.
Functionality may vary on a monitoring probe by monitoring probe basis, but most probes do not require privileged user access to perform correctly.
6. In untrusted portions of your UIM deployment, use UIM robots in passive mode in preference to active mode. Passive mode robots only receive commands from specific hubs, and cannot proxy to send commands to the rest of the CA UIM infrastructure. For further information please refer to:
Connect a Passive Hub to a Robot
Passive mode robots are a good choice for hosts on which only basic monitoring is performed. They are not able to support high-volume monitoring probes such as VMware and are not suitable for running infrastructure components such as WASP, discovery agent, UMP, and so on.
7. For hubs that only manage passive mode robots, or do not manage robots at all, consider limiting access to them using the “No login” or “Local machine only” login control options. More information can be found here:
HUB IM GUI Reference
A hub which is set to “No login” cannot manage active robots, and therefore cannot be the entry point for UIM commands to be passed to other points in the deployment. This is a good choice for edge node hubs in untrusted network segments.
8. In addition to passive mode, again, in the untrusted deployment segments, use UIM robots in proxy mode. Proxy mode filters access to UIM probes through a single port, and provides additional protection. For more information please refer to:
Bulk Robot Deployment with an XML File/Robot Attribute Reference
Additional Information
If you are unable to follow these best practices, or feel that they are insufficient for your specific security needs, then it is possible to install the UIM security enhanced message bus in vulnerable or untrusted parts of your UIM deployment. Please note that while this version of the message bus has additional security measures (such as encrypting all UIM traffic from robot to hub) it has additional prerequisites (such as requiring user-provided and signed X.509 certificates) and may have limited functionality compared to the standard message bus at this time as a result of this increased security.
Feedback
