Superuser Access & Permissions

When it comes to crashing your enterprise systems, destroying data, deleting or creating accounts and changing passwords, it’s not just malicious hackers you need to worry about. Anyone inside your organization with superuser privileges has the potential to cause similar havoc, either through carelessness, incompetence or perhaps through malicious intent.

Superuser privileges bring inherent risks with them, yet you can’t run a corporate IT system without granting some people the privileges to do system-level tasks. There are ways, however, to minimize the impact.

Perhaps less seriously, they may well also have access to confidential information and sensitive personal data that they have no business looking at, thus breaching regulatory requirements and risking a rebuke from auditors — at the very least.

The trouble is that accounts with superuser privileges, including shared accounts, are necessary: You can’t run a corporate IT system without granting some people the privileges to do system-level tasks.

So what’s the best way to manage personal and shared accounts with superuser privileges in a controlled and auditable manner? That was a key question Research Vice President Ant Allan addressed at the Gartner Information Security Summit 2009 in London back in September.

When it comes to best practices for managing personal accounts with superuser privileges, Allan recommended creating three types of accounts:

• Personal accounts with full, permanent superuser privileges
• Personal accounts with full (or restricted) temporary superuser privileges
• Personal accounts with limited, temporary superuser privileges

Superuser activity on any of these accounts should be monitored, logged and reconciled, Allan recommended. The first two types are intended for full-time system administrators, and the number of these accounts should be minimized. However, it’s important not to make the number too small, Allan warned. Otherwise there might not be enough people available at a given time to take required action when it is needed. It’s also prudent to consider limiting the scope of the superuser privileges across the organization’s infrastructure by asking yourself: Does a given administrator need to be a superuser on all the systems in the organization?

The third type of account, the one with limited, temporary superuser privileges, is intended for application developers and database administrators. The superuser privileges of these accounts should be limited to the applications or other areas that they might reasonably need to access.

Allan recommended using superuser privilege management (SUPM) tools to control these three account types. SUPM tools can be used to manage superuser privileges:

• By privilege (e.g., by regulating the commands available)
• By scope (by resources or systems, perhaps)
• By time (either by providing privileges for a fixed time period or by time windows)

The model for these tools is the Unix sudo application, which allows permitted users to execute certain commands as if they were a superuser (or another user) as specified in a configuration file. However, proprietary tools from the likes of Applecross, CA, Fox Technologies, Centrify and Symark/Beyondtrust can actually be more effective than sudo, Allan said.

As for shared accounts with superuser privileges, most organizations use two types, which are usually necessary despite presenting a security risk:

1. Shared superuser accounts, including all the system-defined default accounts (such as the Active Directory administrator) used by system administrators
2. Firecall accounts, intended for after-hours support and used by system and database administrators and application developers

The trouble with shared accounts, however, is that shared passwords cause problems:

• If there is no way to store or communicate passwords securely then they are bound to be compromised, presenting a serious security risk.
• There is usually no way of knowing who is using a shared account at a particular time, so there is no audit trail, no user record to merge with event logs, and therefore no accountability.
• If a secure system for controlling shared passwords is in place, the time delays it can cause may have serious negative consequences in terms of productivity. In emergency situations, time wasted accessing passwords before problems can be mitigated or dealt with could be extremely costly.

The solution is to devise a system that does not require passwords to be shared at all, Allan said. This requires the use of shared-account password management (SAPM) tools.

There are many types of SAPM tools, but essentially they all involve a process similar to this: A user makes a request for a password, an approval request may optionally be sent to a manager to green light, and the password is then sent to the user so he can sign in. Alternatively, the system can automatically sign in the user without ever actually seeing the password. Important extra features include automatic periodic password changing and audit logging.

SAPM tools are offered by a small group of vendors including, Lieberman Software, Cyber-Ark Software and Symark/Beyondtrust — which also makes SUPM tools. Symark/Beyondtrust is unusual in this respect, but Allan predicted a general convergence of SUPM and SAPM in the coming months.

Inappropriately managed or unmanaged superuser privileges are increasingly being recognized as a significant security risk for many organizations. Most enterprises should take steps to address this risk, Allan said. SUPM and SAPM tools are likely to be key to any efforts to minimize risk and assure accountability associated with personal and shared superuser accounts, he concluded.

Paul Rubens is a journalist based in Marlow on Thames, England. He has been programming, tinkering and generally sitting in front of computer screens since his first encounter with a DEC PDP-11 in 1979.

Follow ServerWatch on Twitter