Identity Management Fundamentals

 

 

Let’s level set. Experts can use the reminder, and novices need to learn. Understanding the basics of identity management is critical before diving into the deep end.

 

First, identity management (IM) is different than identity and access management (IAM), even though the majority uses these terms interchangeably. The confusion leads to poor practices and terrible results. I’ll explain.

 

In a system, there are subjects and objects. Subjects are active entities, objects are passive. Subjects operate (read, write, delete, etc.) on objects or other subjects. Subjects require an identity, a way to identify them in the system. Subjects are often associated with people, but not always. There are other active entities in the system that also require an identity, things like services and applications.

 

Sometimes it helps to put identity into context, which is where access management enters the fray.

 

If an identity were used by itself, it would result in chaos. Any subject could use any identity, and all subjects could use all identities. Identities could either do nothing in a system or do all things in a system. Compounding our problems is the fact that you wouldn’t know what was happening or even if anything was happening at all.

An identity is an element that exists by itself, but it needs other functions in order to work within a system. Identity is an identifier of a subject (user, application, service, etc.) in a system. The identifier is most often stored by the system as an account; user account, system account, etc. It’s safe to use identity and account synonymously.

 

 

• Authentication – Verification (or proof) that a subject is permitted to use an identity. This controls which subjects use which identities. Proof can come in several forms, or factors. The most traditional forms of authentication are:

•  Something you know – a password, PIN code, passphrase, etc.

•  Something you have – a cell phone (where a text can be sent), a computer, a token, an access card, etc.

•  Something you are – most often called a biometric; fingerprint, face (facial recognition), hand shape (hand geometry), etc. 

• Authorization – The things, permissions and privileges, that a subject is granted within the system while using an identity.

• Accountability – Evidence of what’s happening and what happened in a system. Logging is a common form of accountability.

 

The basics are beautiful. Without authentication, any subject could use any identity and all subjects could use all identities. Without authorization, an identity could either do nothing in a system or do everything in a system. Without accountability, we would have no idea what’s happening.

 

At a functional level; IM relates only to the identity; however, managing an identity must also include authentication. Authentication controls which subjects can access which identities. Identity management then is identity and authentication from our previous definitions.

 

At a functional level; IAM includes access, meaning what an identity is permitted to do; authorization. Identity and access management then includes identity, authentication, and authorization. Both IM and IAM benefit from accountability, so this function is added to both. This results in:

 

• IM = Identity + Authentication + Accountability

• IAM = Identity + Authentication + Authorization + Accountability

 

IA and IAM are in fact two functions that are integrated, not one single synonymous function. 

 

 

 

If you don’t get IM right, you’ll never get IAM right. Most organizations fail at IM, and don’t have a prayer in getting IAM correct. Over the past year, we’ve compiled the results of more than one hundred Active Directory user account audits. The results aren’t good.

 

On average, 42.4% of all accounts (user and service) are enabled, 54.19% of the accounts are disabled, and 3.41% of the accounts are expired. The table referenced here only accounts for enabled accounts. So, it’s safe to say that on average, 13.02% of enabled accounts were found to have not logged in within the past year and 17.69% had passwords that exceed the age of one year.

 

 

Things that are neglected fall apart. Like the decay of a neglected farm home, so becomes a user account database (e.g. Active Directory). There are three primary reasons for the decay:

 

1. Poor definition and formalization of identity lifecycle processes. There are four high-level processes that must be defined and formalized; Creation, Change, Deactivation (disable/delete), and Audit. There are several supporting processes under these headings. Processes must be defined and documented.

2. Poor understanding of the fundamentals and feeling overwhelmed. We know that IM and IAM are integrated, but different. Start with IM, and an identity audit. Validate every identity, and shore up authentication. A tedious exercise, but not an overwhelming one.

3. The work is tedious and uncomfortable. Tedious work isn’t appealing. People want easy buttons and blinky lights. The work can be uncomfortable because it will require coordination with the business. Coordination will be the only way you can effectively validate the identities.

 

 

 

 

No Easy Button Solution To Cybersecurity’s Skills Shortage: