This column’s question comes from a SecureAuth+Core Security customer who heard about some of the technologies we offer and was unfamiliar with the term Orphaned Account.  

 “What exactly is an Orphaned Account, how do they happen, and why are they dangerous to security?”

 Well, first let’s talk about how we define an “account” in the first place.  At their simplest, accounts are simply identifiers for a user and all of the associated information that supports that identity.  For example, a corporate Active Directory account would include a username, first name, last name, password, phone number, email address, and possibly some other information like what groups they belong to so they can access files and applications.  A website account may have a username, password, and subscription information.  Each type of Identity Database can contain different info for its accounts, but they all have accounts - one for each user, and administrator that has to access data, services, or applications.

 Accounts used only by a service or application to access other services or applications - called service accounts - also exist.  They don’t have phone numbers or user information, but typically have a collection of permissions and restrictions to ensure they are only used for the applications and services they apply to.  Even though these accounts aren’t used by humans, they are still accounts and have to be watched over in the same way as user accounts would be.

 Normally, the accounts are actively in use by users - possibly not on a day-to-day basis, but often enough that each account is accessed often.  Over time, though, users leave companies, change websites, stop using email addresses, and take other actions that mean their accounts are no longer required to be maintained in the system.  Service accounts eventually fall out of use when the applications they work with are upgraded, changed, or removed.  For a short time, these accounts are typically held onto by the company or provider that they’re assigned to; just in case the user decides to use them again or the service/application is needed again.  After that time period, they should get deleted and that information removed from all the systems that the account is assigned to.

 When that last bit of the process (the removal - or “de-provisioning” as it’s called in the Identity Governance world) doesn’t happen, you end up with Orphaned Accounts.  The account still exists in one or more systems that used it, but the user or application no longer accesses that system or service and is no longer using the account themselves/itself.  When Orphaned Accounts are present, they pose several security risks:

 

  •  The account still maintains access to resources; like email mailboxes, application logins, and sensitive data.  That means the user could potentially regain access to that information and those services even though they should no longer be using them, or an application could continue to operate when it is supposed to be decommissioned.  Imagine an Office Manager for your doctor still having access to medical records well after they have left that job, and you can see why this is a major problem.
  • Let’s say the former user of the Orphaned Account is an honest and upstanding person, and they, therefore, do not illegitimately attempt to re-use it to access things they should not.  In this case, the Orphaned Account still exists; and therefore is just sitting there without its password getting updated or changes made to it as things change in the organization.  Bad actors can attempt to use this Orphaned Account to gain access to systems illegally by attempting to guess the password.  If the password is weak, and since no one is updating that password when strong password requirements are put into place, the Orphaned Account becomes a very easy target for attack.
  • Finally, anyone else who that Orphaned Account was shared with can still use it to access services and data they may never have supposed to have access to in the first place.  Credential sharing is depressingly common, and that means not only does the original owner of the Orphaned Account need to be considered, but anyone they shared those credentials with.  Service accounts also fall victim to this, as other applications which had been using that account erroneously or just due to misconfiguration could continue to use them to access resources they should not.

 

As you can see, Orphaned Accounts - the result of user and service accounts that are no longer used for whatever reason - are a major problem for IT security.  Think of them as luggage that is traveling through the airline system, but has no passenger attached to it.  Might just be misrouted bags, might be a bomb; either way we need to know which one of those things it is and address it immediately.  Finding them and removing their access is a critical link in the security chain, which means you may be asked what you need access to, and why, when your company audits their user accounts.  This isn’t to explicitly remove any access you have; but rather to make sure that any accounts you control are in active use, are following all the company protocols, and haven’t found themselves orphaned along the way.

Want to learn more about orphaned accounts,  access reviews, and other struggles that come with an IGA program? Join us Wednesday, June 20th at 11 AM ET/8 AM PT for our Live Webinar "How to Solve the Top 3 IGA Struggles". Register here and save your seat!