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.

More from Network

Beware of What Is Lurking in the Shadows of Your IT

This post was written with contributions from Joseph Lozowski. Comprehensive incident preparedness requires building out and testing response plans that consider the possibility that threats will bypass all security protections. An example of a threat vector that can bypass security protections is “shadow IT” and it is one that organizations must prepare for. Shadow IT is the use of any hardware or software operating within an enterprise without the knowledge or permission of IT or Security. IBM Security X-Force responds…

Beyond Shadow IT: Expert Advice on How to Secure the Next Great Threat Surface

You've heard all about shadow IT, but there’s another shadow lurking on your systems: Internet of Things (IoT) devices. These smart devices are the IoT in shadow IoT, and they could be maliciously or unintentionally exposing information. Threat actors can use that to access your systems and sensitive data, and wreak havoc upon your company. A refresher on shadow IT: shadow IT comes from all of the applications and devices your employees use without your knowledge or permission to get…

X-Force 2022 Insights: An Expanding OT Threat Landscape

This post was written with contributions from Dave McMillen. So far 2022 has seen international cyber security agencies issuing multiple alerts about malicious Russian cyber operations and potential attacks on critical infrastructure, the discovery of two new OT-specific pieces of malware, Industroyer2 and InController/PipeDream, and the disclosure of many operational technology (OT) vulnerabilities. The OT cyber threat landscape is expanding dramatically and OT asset owners and operators, all of whom understand the need to keep critical infrastructures running safely, need to be aware…

How to Compromise a Modern-Day Network

An insidious issue has been slowly growing under the noses of IT admins and security professionals for the past twenty years. As companies evolved to meet the technological demands of the early 2000s, they became increasingly dependent on vulnerable technology deployed within their internal network stack. While security evolved to patch known vulnerabilities, many companies have been unable to implement released patches due to a dependence on legacy technology. In just 2022 alone, X-Force Red found that 90% of all…