They say that travel broadens the mind, and 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 key-pad on the door, and with the right combination you can enter.
Now this shouldn´t come as a surprise given our heightened security awareness these days, and that the Swiss are obviously very security conscious, and every restaurant proprietor will tell you that misuse of toilet facilities is an increasing problem – It must be otherwise why secure then with digital locks.
Of course this security feature raises new problems. For example you don´t want your clientele rushing to the toilet only to discover that they can´t get in because they don´t know the combination. This will just create all sorts of complaints. But the Swiss have addressed this problem 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 as you can appreciate the staff have more than enough on their plate than to spend all day keeping track of the code, and here´s where the system starts to fail. When I sat down in the restaurant I was facing the door into the kitchen and the first thing that caught my eye was a notice board, just where the staff entered the kitchen, with the inscription “WC Code 1213”. Further investigation – I asked the waiter – revealed that the code is changed every night, and that the same code is used for the ladies and the gents, possibly to avoid embarrassing situations.
Sp what is the point you might ask? Well if anything illustrates the problem of privileged access control – after all the toilets are for privileged users – customers – it´s the secure toilet. In the same way that the restaurant doesn´t simply want people walking in off the street using 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. So in the same way as the restaurant introduced the WC Code procedure, many companies talk about “Emergency Envelopes”, or “Break Glass” accounts. The concept is the same – since you can´t identify the user since they are called “administrator” or “root”, or some other manufacturer embedded account, 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. Firstly someone has to manually change the password on a regular basis. One or two toilets are fine, but if we´re now talking about every toilet in the city or in the country, I now need an army to do this. The same goes with passwords for embedded accounts – someone has to change these manually. Now the next problem is to ensure that the people changing the passwords don´t simply use the same password all over the place. You understand what I´m getting – If I have the code to one toilet, I´ve got them all – 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 may be the same, or all root passwords on every Unix server is the same, or all Oracle database embedded accounts are the same. Now it may be a complex code which no hacker in the world could figure out, but since it´s so complicated it probably means that I have to write it down and unless someone is going to change the password on every system immediately, my whole security has just gone down the toilet!
Now you might think that the problem might not be as acute as I´m stating. For example you could try to give everyone who needs access their own code. But then you need to be sure that every toilet can identify me 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 the problem. However what they fail to realize is that many of the embedded administrative accounts in systems and applications can not be assigned to individuals, so you´re left with identity of “customer” or in the IT world “administrator” “root” etc.
But why does the restaurant have a secure toilet. Obviously management only wants customers to have access, and this in turn raises the issue about how management ensure that this is working. The only effective way to do this 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! Again 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 did they get 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.
Most companies just like the restaurant can reduce the hazards of managing their passwords by introducing an effective policy which should include:
1. Centralised administration: Create a centralised policy, procedures and enforcement mechanism which covers all IT groups.
2. Secure storage: Securely store Administrative passwords in a way that offers strong authentication, granular access control, encryption and auditing.
3. Worldwide secure availability: With today´s distributed enterprises, administrators need access beyond network boundaries, where they can securely access and share passwords from anywhere.
4. A dual-control mechanism: Requiring two or more administrators to access passwords to the most sensitive servers.
5. Routinely change passwords and track history.
6. 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.
7. Disaster recovery plan: Look into technologies for automated, safe replication of vital administrative information that can guarantee the availability of those accounts in time of need.
Once you´ve rolled out a sensible and usable security policy you can also secure and manage your passwords using “safe havens” or “digital vaults” which addresses the problem of managing the whole lifecycle of embedded administrative accounts. The vault enables the administrative manager to securely archive, transfer and share among the required staff the passwords. It solves the problem that cannot be identified by conventional Identity Management systems, and ensures that organisations can very quickly implement regulatory and audit compliant controls to their privileged accounts. And as far as the restaurant goes, I think they need to move the notice board.