Office Memo 21

Home > Office Jotter > Office Memos > Office Memo 21

Time for a snack at Office Jotter?

Office Memo 21

23 November 2005

Security - Down the Pan?

They say that travel broadens the mind. I have recently discovered a new phenomenon - the secure toilet. On a recent trip to Switzerland, I visited a restaurant that secures the toilets with a digital lock. Both the ladies' and the gents' have a keypad on the door, and with the right combination you can enter.

This potentially raises a problem - you don't want your customers unable to get into the toilet because they don't know the combination. The Swiss have dealt with this by placing signs all around the restaurant that refer you to the “WC Code”, with instructions to ask a member of staff for the code. So far so good, but the staff have more than enough to do without keeping track of the code.

Here is where the system starts to fail. When I sat down in the restaurant, I was facing the door into the kitchen. The first thing that caught my eye was a noticeboard, just where the staff entered the kitchen, with the inscription “WC Code 1213”. Asking the waiter revealed that the code is changed every night. The same code is used for the ladies and the gents, possibly to avoid embarrassing situations.

This all illustrates the problem of privileged access control - after all, the toilets are for privileged users, the customers. In the same way as a restaurant doesn't want people walking in off the street just to use the toilets, companies can't simply allow anyone to access privileged accounts or information in their organisation. And since it is not possible to provide access based on user identity, some mechanism has to be put in place to control this.

In the same way as the restaurant introduced the WC Code procedure, many companies therefore talk about 'emergency envelopes' or 'break glass' accounts. The idea is the same. You can't identify the user - since he or she is called “administrator”, “root” or similar - so you protect the password.

This concept is fine on paper (and usually that's where the passwords are) but in practice it doesn't work. If you compare it to the toilet analogy, security staff have to follow similar procedures. First, someone has regularly to manually change the password. One or two toilets are fine, but if we're now talking about every toilet in a city or country, one needs an army to do this. The same goes with passwords for embedded accounts - someone has to change these manually.

The next problem is to ensure that the people changing the passwords don't simply use the same password all over the place. If I have the code to one toilet, I've got them all - the same goes with the passwords. You would be amazed at the number of organisations that use one password for hundreds of embedded accounts. For example, all domain passwords might be the same, or all root passwords on every Unix server, or all Oracle database embedded accounts.

The password or phrase might be a complex code that no hacker in the world could figure out. This very complexity probably means users have to write it down. Also, unless someone is going to change the password on every system immediately, my whole security has just gone down the toilet!

You might think that the problem might not be as acute as I'm stating. For example, you could try to give his or her own code to everyone who needs access. But then you need to be sure that every toilet can identify that person as an individual and not simply as “customer”.

Many companies think that an identity management system or some kind of token-based authentication system solves this problem. They fail to realize that many of the embedded administrative accounts in systems and applications cannot be assigned to individuals. They are left with identity of “customer” or, in the IT world, “administrator”, “root” and so on.

But why does the restaurant have a secure toilet? Obviously, the managers want only customers to have access. How do the managers ensure this is working? The only effective way would be to have some kind of `audit compliant control' in place, otherwise you never know if the system is effective. For example, is the code changed frequently? It might even need to be a one-time code if you don't want customers using the toilet all day just because they bought one cup of coffee!

Auditors have the same requirement in the business world. They need to know who has accessed, when they accessed, why they accessed, what they accessed, where did they access it from, and how they got access. Also, they want to be able to see beyond the shadow of a doubt that the password has been changed according to the policy they have defined. Simply encrypting passwords in some spreadsheet is not enough, unless you want to hire an army of password managers.

Just like the restaurant, most companies can reduce the hazards of managing their passwords by introducing an effective policy. This should include:

Centralised administration: create a centralised policy, procedures and enforcement mechanism that covers all IT groups.

Secure storage: securely store administrative passwords in a way that offers strong authentication, suitable access control, encryption and auditing.

Worldwide secure availability: with today's distributed enterprises, administrators need access beyond network boundaries, where they can securely access and share passwords from anywhere.

A dual-control mechanism, requiring two or more administrators to access passwords to the most sensitive servers.

Routinely changing passwords and keeping track of their history.

Intuitive auditing: as passwords are used or changed, organisations will need to routinely audit and track access to vital systems to comply with new regulations.

Disaster recovery plan: looking into technologies for automated, safe replication of vital administrative information that can guarantee the availability of those accounts when needed.

Once you've set up a sensible and usable security policy, you can also secure and manage your passwords. 'Safe havens' or 'digital vaults' handle the problem of managing the entire lifecycle of embedded administrative accounts. The vault enables the administrative manager securely to archive, transfer and share passwords among the required staff. It solves the problem that cannot be identified by conventional identity management systems. Also, it ensures that organisations can very quickly implement regulatory and audit compliant controls to their privileged accounts.

As for the restaurant, I think it needs to move the noticeboard.

***

Calum Macleod, European Director at Cyber-Ark, contributed this article. Our thanks go to him. For further information contact Calum on 0031 621 827253 or email calum.macleod@cyber-ark.com .

About Office Memos

An Office Memo is an extended comment on what is happening in the world of the electronic business and elsewhere. Some memos will have appeared in Office Jotter; others are simply referred to in it.

You are free to disagree with, amplify or even agree with anything that appears in Office Jotter or an Office Memo. Of course, the rest of us will never know this unless you write in with your views, so please comment, in the blog or with an Office Memo*.

Content from Office Jotter or Office Memo may be circulated freely, so long as you remember to credit its source.

Thanks,

Roger Whitehead

Publisher and editor

*No more than 1,000 words at a time, please. I edit material for publication but as lightly as possible.

Copyright Roger Whitehead, 2005. I hereby assert and give notice of my right under section 77 of the Copyright, Designs and Patents Act 1998 to be identified as the author of these publications.