Contributed to OUT-LAW by
CalumMacleod, European Director,
Cyber-Ark
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.
So 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, i.e. 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 when 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 are 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 realise is that many of the
embedded administrative accounts in systems and applications cannot
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 ensures 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:
- Centralised administration: Create a centralised policy,
procedures and enforcement mechanism which covers all IT
groups.
- Secure storage: Securely store Administrative passwords in a
way that offers strong authentication, granular 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 change passwords and track 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: 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.
Contact: calum.macleod@cyber-ark.com
