Rock around the clock
by Deborah Volk on June 11th, 2009

As the summer descends upon us, so have various industry conferences. With that raison d'etre, a rising tide of interesting discussions is sweeping across blogs and other assorted outlets of identity and access management sound and fury. Mark Diodati from the Burton Group weighed in on the ontological issue of privileged accounts and people who (ab)use them. The linguistic conundrum seems to be in differentiating Privileged Accounts from Privileged Users. The secret sauce of securing privileged accounts according to Burton is based on managing two ingredients: WHO has access to the accounts and WHAT the accounts can do.
In my experience, the WHO/WHAT (WW) aspects are important to know and manage with respect to Privileged Accounts...but they (aspects, that is) don't change often. If you give a storage administrator access to all storage servers on a particular production cluster via a privileged account, you don't want to restrict the capabilities of this account or the storage admin may not be able to do his job. This would leave all those database-hungry customers in a bind (pleeeeeease, Dear Sir/Madam storage admin, could I have another 50 GB of space on your Most Blessed SAN array today and 50 more tomorrow). Nor would the storage admin ever share his account with anyone outside the usual few people in the storage admin group, so the WHO essentially does not change. What is truly important to manage (choke with a kung-fu grip) is the WHEN of the privileged account. When is the storage admin allowed to make production changes? (If you answered 'anytime', remove yourself from these Internets).

Solutions from vendors such as Passlogix and Cyber-Ark attempt to address the when by limiting the check-out of the password to the privileged account owner. This works well if the privileged account is not the sole account of a user on that system. Unfortunately, this is not always the case. Let's take our happy storage admin as an example. He has an account BOBW on storage array He monitors various storage parameters on a regular basis via a few shell commands, so he needs read access every day. Unless you're looking at your CEO's paycheck, read access is not considered an elevated privilege by auditors. But anytime the byte-hungry database hosted on the storage array goes through a planned change, Bob needs to run a series of scripts to snapshot the database, create copies of certain storage volumes and clean-up the previous snapshots by moving them offline.

He now needs the ability to read files, create files, perform various storage array operations and eventually delete files. He only needs this access during the planned change window. At this point, you can either create a second account for Bob that has these specific privileges, but Bob can only use this account during the appropriate period (a password vault solution can work here), or you can grant the appropriate access and then revoke it after a given time period. The third approach is just to give him the access and to trust him.
The first approach, letting Bob have two accounts, would work, except now your audit processes have to deal with two accounts. If you have implemented an identity management solution and you had the amazing foresight to provide for this possibility, you will have both accounts show up as belonging to Bob, one temporarily belonging. There are organizations who elect to take this approach. They would rather keep the privileged accounts separate from the day-to-day, 'normal' accounts. The disadvantage of this option is that it increases the work that auditors and attesters have to do. They also have to have a razor-sharp knowledge of storage administrator group processes to recognize that account BOBW1 is the 'normal' account and 'BOBW2' is the privileged account.

The second approach (timeboxing the account use) truly mimics what the business case calls for but there's a technology catch. If you don't have an automated system that can enforce timeboxing, it would quickly become an administrative nightmare. Now, you might be thinking to yourself "isn't this the WHAT of an account?" In part it is, because you are changing what a person can do. But an equally or perhaps more than equally important factor is what the person can do relative to the context the person is in (the WHEN). Situationists of the world, rejoice.

All dreaming of cookies and milk aside, the third approach seems to be the one we encounter the most in the bright-lights world of IT. Mainstream adoption of sophisticated access management technology and business/IT change of related processes just aren't where they need to be at this point in human history. Thanks to Burton's opening shot in this novel, perhaps the software vendors will feel the anguish of security professionals and start developing products to help lock down access without jeopardizing the work that needs to be done.

...or perhaps the old ruler on the knuckles approach needs to be explored as an enforcement alternative. Contact us, we can help. (We'll bring our own rulers while supplies last).

Posted in Access Management, Passlogix v-GO    Tagged with privileged accounts


Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)