Security management tools allow users to perform security-related actions on many servers using a centralized management system. For example, patches may be installed on servers managed by the tool, or health checks can be configured to let the endpoint management operator know when a security-related setting, such as the password strength criteria or file permissions, on a managed server has changed.

Security management tools are great, but they are extremely powerful and must be carefully controlled to ensure they are used only by authorized personnel for their intended purposes.

Most companies take great care to ensure system administrators have the correct level of access they need to perform authorized actions on the servers they support. Often, organizations invest significantly in securing the server itself from users who are actively logging in, including the use of mechanisms to enforce password strength, limit the commands a user can run (for example, using “sudo” configuration files on UNIX servers) and monitoring to detect suspicious activity.

What is often overlooked is that administrators of system and security management tools also have the ability to access and perform actions on servers managed by the tool. This is often done using administrator or root authority. Therefore, it is important to take time to secure the tool itself.

Deciding Duties

The first consideration is who will use the tool. Will the tool be used by system administrators who already have administrative or root access to the servers that will be managed? Or will the users have restricted access or no access to the actual servers? By giving these restricted users access to the management tool, you may effectively negate any controls put in place on the servers themselves, since they can simply use the management tool to execute commands on the server. If there are other types of users, it is important to document exactly which activities they will perform using the tool. Then, you can design and implement the correct security controls to ensure they will only be able to perform these actions.

Access Levels in Security Management

The second consideration is what level of access each user should have. This includes the functions a user can perform and the server or servers on which they can be performed. It is important to maintain a detailed inventory of each server managed by the tool, including who can access that server for which functions. For example, you may have one person responsible for configuring and managing health checks on 50 servers in the environment. This person should be given access only to perform the health check function and only to the 50 servers they support. He or she must also be effectively prohibited from performing any other action, which can sometimes be a challenge, depending on the level of granularity that is required for various operators and functions.

Security management tools bring a tremendous level of efficiency to organizations. When access is controlled properly and the tools are used correctly, they can result in a great productivity boost and help automate routine activities. But first, time must be spent defining and implementing the correct security model and controls for the tool itself.

I hope this post has been a helpful reminder to allocate time to protect your security management tools. Please tweet me at @LisaChavez111 if you have any tips or stories of how you secured your managed environment.