The User Who Didn't Know He Was A Super(user)

Part 1:  Discovering Your Superman


What is a privileged user?  It should be a simple question to answer — the two words give you a big hint as to where the definition should end up. It’s a user, and, quite obviously, this user has one or several privileges enabling them to do “important stuff.”

So, I’m asking you: are YOU a privileged user? 

Well, let’s try to figure out the answer together, and see if the answer matches your first thought.

Let’s start with a simple definition of a privileged account, you noticed it immediately: I switched the words from “user” to “account.” I define the “user” as the physical identity; in other words, that is you. The “account” is the combination of a username/account and, eventually, other information that actually provides you the capability to get into “stuff” such as applications, your corporate network, servers, network devices, etc.   However, privileged accounts needn’t be linked to any “physical identity.” An example of this is an application account used to run tasks on a scheduled basis.

Therefore, a privileged account is one of these username/password/permissions “identities” with a level of access that puts the user in a position to be a threat to the organization---which ironically is what organizations try to mitigate by creating these accounts. 

In each company users have privileged and non-privileged accounts.  Non-Privileged Accounts are the “basic” accounts we all have that allow us to check email, surf the web, etc.  Privileged accounts give us the power over servers, devices, etc.  I like to refer to the Privilege Accounts a user will receive as Privilege Account by Heritage.  This refers to privilege accounts a user will receive because of their job function, title, department, rank, etc.  Some refer to these as Shared-Account Privileged Identities, however I like to break them up and put them into two different groups:

Shared Privileged Account (SPA)

  • Cannot be removed due their nature (built-in accounts such as root, administrator, system, etc.)
  • Cannot have their permissions lowered due their nature (i.e., in Active Directory, the built-in account administrator could be disabled but, in the end, at least one account in relevant domain groups such as the Schema Admin is needed)
  • Have the ability to edit, remove or delete logs everywhere due their status/model (administrator in AD, root on UNIX, etc.)

Named Privileged Account (NPA)

  • Can be removed, but, the operation would have a dramatic impact on customers (i.e., all the so-called “service accounts” that run services, applications, etc.)
  • Have specific permissions higher than the average admin account/users (i.e., domain admins)
  • Have the potential power to edit/delete/remove some logs from systems, but not everything from everywhere 

Keep in mind that one of the most dangerous practices often linked directly to SPA types of accounts is the use of the same password by multiple users, who actually use the accounts to improperly manage the ecosystem.

We’ll talk more about privileged accounts in the next edition of this blog.