Privileged user accounts: the security issues

Once upon a time, I never had to look for the telephone. It was always in the hall. Now, we have this wonderful DECT system in the house with handsets in all of the key locations (including my daughter's bedroom, where that particular handset usually resides beneath an Everest-like mountain of clothes!).

No matter how often we've agreed that the last person to use a given 'phone should put it back in its rightful place, it still appears to be the case that every time the telephone rings the hunt is well and truly on.

Personally, I think the policy of returning a telephone to its ‘home' is a good one. My only problem is enforcement... I need to go to work to earn a living to pay for our DECT ‘special', so any desire for 24/7 monitoring is simply out of the question!

My story of domesticity can be likened to a situation that arises in many corporate organisations today. One of the biggest issues they face is the need to eliminate bad practice in relation to the use - and abuse - of privileged accounts. Unrealistic policies may be in place. Those policies may even be bypassed. Alternatively, there may be no policy at all, and thus little or no control.

Typically, system user accounts have ‘super user' or administrative rights. In general, an organisation should never allow any user account to have privileged access. In many companies, the IT staff will create user accounts with administrative rights. This is frequently the case when UNIX systems are involved, and where the unit is not remotely accessible from the system.

The problem with this approach is that the actual user will frequently tend to employ their specific user account for general access. This results in serious problems for members of the IT Security Team at audit time when faced with the difficulty of trying to decipher which log-ins were for general access and which were intended for administration tasks. In certain environments (particularly Windows), this practice can also expose the system to Trojan horse attacks.

Since it will always be necessary to have shared accounts in place for services such as access to UNIX environments - and, in some cases, Windows environments - the password for such accounts should be kept in a secure location. The number of user accounts with privileged access must be rationed to a bare minimum, and passwords for these accounts changed on a regular basis.

Access to the password for the shared account and the administrative/root/service passwords should only be made available on a ‘need to have' basis (which ought to be stated in the IT security policy). By default, any access to these passwords must have an audit trail.

Further, each shared account has to be designated an account owner who is then responsible for controlling access to the account. This should allow for contingency procedures whereby any member of the responsible group may be authorised to release the password.

Sharing privileged passwords

The all-too-common practice of sharing the same privileged passwords necessarily means that systems are grouped according to categories. All systems will indeed share the same privileged passwords. This is very common in Windows environments where - on a frequent basis - all service accounts will share the same password. Having ascertained the password for one specific service account, all such accounts are then accessible.

Our recommendation to solve this problem? Every privileged account should have its own unique password, and that ought to be configured to change at least every 30 days.

Access to the password for the shared account and the administrative/root/service passwords should only be made available on a ‘need to have’ basis (which ought to be clearly stated in the IT security policy). By default, any access to any of these passwords must have an audit trail

A service account - such as the account designated to manage an active directory - will be used on a regular basis, and represents a serious security risk for any organisation. Often, administrators will use their privileges to set up service accounts and, when members of staff leave the company, these accounts may be overlooked. Although service accounts can ensure that a specific user is only allowed the privileges necessary to perform their function, these accounts must either be assigned to specific users (if at all possible) - resulting in much additional IT security administration - or shared among a group of privileged users.

Here, the simple thing to remember is that service account passwords ought to be kept securely and changed on a very frequent basis.

Non-expiring passwords

A situation where accounts have passwords that don't expire is commonly found in two scenarios - either when administrative or service accounts are set to non-expiry, or in embedded accounts (which are coded in scripts in relation to database applications).

In both cases, these accounts represent a major security flaw since they are distinctly vulnerable to password cracking tools. In the case of embedded accounts, all personnel involved with the development and maintenance lifecycle have knowledge of the account detail. Using an embedded account is a relatively easy way for someone to access sensitive data without ever being traced.

All non-expiring accounts should be altered so that passwords are modified on a regular cycle. Additionally, as these accounts allow privileged access, no single individual should be permitted to change the passwords on a manual basis.

What if company policy is not applied to users on a universal basis? It is not uncommon for organisations to apply different standards to different members of staff. For example, managers will usually have root access to all servers, while developers and testers enjoy root access to all development servers. It is imperative the host company applies a consistent policy for all members of staff, regardless of their function or position.

The use of any privileged account must have the accompanying audit trail. Consideration should be given to differing policies for development and production systems. For example, privileged access to a production system should only be possible with dual control, whereas a development system password may be accessible - within certain environments - without the need for dual control. Both production and development systems should be changed on a regular basis.

Universal policy applications

Sometimes, corporate concerns will not have a consistent procedure between different groups. This results in various departments - databases, UNIX, Windows, mainframe and networking, etc - functioning as independent entities without a universal security policy. All groups, regardless of responsibility or location, should adhere to a common policy. This implies that policies related to how passwords are released - and the frequency of change - should apply across the board.

Many of today's blue chip companies depend on outsourced or contracted-in staff. Failing that, they might enjoy technical support from vendors who require privileged access to specific systems. In fact, there should never be any reason to define a Guest Privileged Account. Access should use the default account, and passwords ought to be re-set on completion of a given task.

If the company is going to protect its interests, clear IT policies and standards must be in place to manage and control exactly who has administrative access. The best approach is to ensure that the number of privileged accounts on systems is kept to an absolute minimum

For practical reasons, it's never possible to completely isolate direct access to systems. On occasion, however, privileged users will be required to access a system from the system console. In this case, the user can always employ the root or administration accounts. Put simply, the password must only be released under strict controls. Policy in place must state that the password is changed after each use.

Emergency envelope accounts

Emergency envelope (or ‘Firecall') accounts are specifically designed for use in emergency situations. In many instances, the procedure to be adopted is a manual one that requires a password to be placed in an envelope. Based on the company security policy, access to that envelope is then strictly controlled.

Each deployment of this procedure should require that a designated member of every team is responsible for reporting all usage to the IT and Security Departments. The password should be changed within a minimum time period after the user has finished the necessary task. If possible, those responsible for releasing the passwords should not be able to know what those new passwords are. Also, a daily audit report should be drawn up to capture the use of any Firecall accounts.

Speaking of Best Practice, this really is vital. If the company is going to protect its interests, clear IT policies and standards must be in place to manage and control exactly who has administrative access. Ultimately, the most effective approach is to ensure that the number of privileged accounts on systems is kept to an absolute minimum. This will significantly ease the administrative burden and, with effective password management, access may be controlled at the entrance.

The more user accounts defined with privileged access, the closer the auditors are going to look at the policies (and, in particular, adherence to them). Other areas to consider include assurances that users are only afforded access if all the conditions are correct... are they ‘on duty', and in an appropriate location (releasing privileged passwords to the user in the Internet Café with Virtual Private Network access isn't appropriate policy no matter how urgent the situation)?

Changing passwords regularly is a necessity, and not repeating passwords within certain time periods is a ‘must'. In addition to this, it becomes critical to maintain old passwords in a secure location. You never know when a system may need to be recovered.

On a ‘need to use' basis

The security specialist should allocate system access privileges on a restricted basis - such as on an event basis - and keep a detailed record regarding exactly what privileges have been granted to whom, when and for what purpose, where the person was when permission was granted and who exactly approved the request. That should happen for every single event.

There are countless situations regarding the use of privileged accounts, and there are many technical solutions which have been created to try and protect the privileged systems and applications such that they're in no way vulnerable. However, it's nigh on impossible to ensure that an infrastructure can be built that's 100% secure. Therefore, it becomes imperative that the strictest controls possible are applied for providing access to the passwords that effectively act as the necessary ‘keys' for opening each and every privileged account.

At the end of the day, the challenge to be answered is: "How might we make sure company requirements in relation to this issue are enforced?" The only way to deal with this matter is to deploy a password management technology which enables the most repetitive processes to be automated, at the same time allowing the IT and Security Departments to rigidly enforce their own security policies.

As for the family telephone, I'm now of the mind that a piece of string and some Super Glue might well be the answer!