Ball of Confusion: The Privileged User

Blogger: Mark Diodati

Recently, we have seen much confusion among vendors and customers regarding the definition of “privileged user”, including the conflation of that term with “privileged account”. It’s a ball of confusion, as Tina (and Ike) might say. The IdPS team will be talking a lot about privilege at this year’s Catalyst Conference.

The privileged user is a carbon-based life form. Examples of privileged users include system and database administrators and supervisors with access to confidential data. The privileged user may have many accounts (for example, mdiodati, markd, and w840411), but a one-to-one correspondence exists between the account and privileged user. In other words, each account is utilized by a single privileged user. Privileged users access systems via interactive protocols, including web, RDP, SSH, and telnet. Provisioning systems provide an approach for securing privileged user access; they assign the minimum necessary access rights for privileged users in target applications. Security systems (like web access management and operating systems) provide another approach by binding the privileged user to resources. In many cases, the two approaches are combined.

The privileged account is a silicon-based life form. The privileged account is typically created when the platform is installed. Examples include the Windows Administrator account, the UNIX root account, and the database ownership account. Many administrators use the same privileged account to perform their job functions. Privileged accounts present significant organizational risk because they are powerful and lack accountability. In addition to interactive access, privileged accounts are used programmatically–their passwords are embedded in script, startup, and configuration files. Programmatic access presents additional risk, as anyone with read access to the file can steal the password and generally use the privileged account for interactive access.

One approach to securing privileged accounts is limiting who can access the privileged account. Privileged account management products control access to the account password and also change the password frequently. Burton Group’s research on privileged account management products is published here (subscription required). Another approach to securing privileged account is limiting what the account can do. Examples include UNIX security products, which can restrict the rights of the privileged account, and delegate these rights to privileged users. Burton Group’s research on UNIX security products is published here (subscription required). Burton Group recommends that both approaches be used to secure privileged accounts.

The relationship between privileged users and privileged account management products can cause some unnecessary confusion. Conceptually, the privileged account management product is just another access control system, and the privileged accounts are resources. The privileged account management product grants privileged user access to privileged accounts.

Comments

[Radovan Semancik]

I think that the confusion originated from the similarity of "account of privileged user" and "privileged account". Maybe you should change the terminology to avoid generic term "privileged account" and use something like "shared privileged account" or "pre-configured privileged account" instead.

[Deborah Volk]

I think securing privileged accounts has to go beyond who/what as these two factors don't change that often. The when factor is very important, IMO but it's handled poorly by current generation of tools. More on my blog at http://bit.ly/c9ATU