This article is about “identity.”
However, this is explicitly not about user accounts and what some may call “digital identities”. It’s also not about non-human identities (NHIs), workload, service, machine-to-machine, or customer accounts.
There are a lot of great articles already written on each and every one of these identity types by thought leaders, so I’d like to address the neglected others.
So, if this article is about identities, but none of the above, then what’s this article about? This is about other constructs that are fundamental to all Identity and Access Management programs, and to their related tools and applications. I’m referring to the identities of constructs like groups, applications, policies, networks, etc.
Identity Constitution
Allow me to simplify the constitution of ‘Identity’ into having three parts:
- An identifier (as unique as possible)
- Attributes, which provide further differentiation, context, etc.
- Relationships (e.g., “belongs to”), which can be documented as part of #2
“My dog’s name is Lola” ← These five words already encompass the three parts above:
- Her identifier: Lola
- Attributes: type: Dog
- Relationships: owner: Me (although, if Lola could talk, she’d tell you her human is my wife)
An example of a non-living object is “my lucky t-shirt”. I’ve had this t-shirt for years, and it’s green, and it has a print of mountains with “Colo ‘rad’ o” written above (I’m a dad, I love it). At home, I may say, “have you seen my lucky t-shirt?”, and in the context of my family, chances are they’d know which one I’m talking about. If my daughter is not sure which t-shirt I’m talking about, she may ask, “what color is it?” (It’s green, an attribute). Life gives us an extensible schema to define any number of attributes to identify objects.
In the examples above, I shared the ‘Identities’ of two objects. The point is to ‘identify’ them.
If we turn to IAM-related objects, we can look at groups as in immediate need of proper identification. A group’s system identifier may be “xyz123”, attributes may include Group Name = “App X Users” (this may be considered the identifier, to the human eyes at least), and Group Description = “Accounts with access to App X”. Is this sufficient? Perhaps initially you’ll think “absolutely”. I’d argue that there’s a rich group identity hidden behind the ID, Name, and Description for this group.
The IAM systems I’m most familiar with allow me to define a rich, extensible schema for accounts with many different attributes and even different attribute-types (string, Boolean, array, etc). This is excellent and much needed. In the last few years, the ‘group schema’ became available, so I may now define a Boolean value ‘For SSO’, ‘For SCIM Provisioning’, or ‘For Policy’. In addition, I want to define ‘Pushed to App’ as a Boolean value, and if TRUE, then ‘App’ (string type, as I can’t define an App object relationship).
But, there’s no extensible schema for ‘Apps’, or for ‘Group Rules’, or ‘Policies’, or ‘Networks’, etc. Lots of opportunities here to elevate the schemas of other objects to a whole new level.
The CMDB is an Identity Management system
It follows that the system of record for constructs such as applications, systems, and perhaps groups is actually an IAM system, but for constructs other than accounts.
A proper CMDB will contain the creation date for any of its configuration items (CIs), its reason for being, its location, and, importantly, its relationships to other CIs.
A Source of Truth
One way to make your IAM system compliant and elevate its security is to delegate account creation to the correct source of truth. HR-driven provisioning is one example of this. If the IAM system delegates employee account creation to a correlated HR record, and the permissions to create accounts are removed from humans, a bad actor would have to shift their tactics to the HR system in order to create an account, which would likely require creating a role requisition, an applicant account, and then a hire/onboarding process.
Similarly, if the base attributes for a group, application, or other IAM construct are established and properly governed by the right source of truth, then the entire identity fabric will be more secure and compliant, but it’ll be like a self-maintaining organism, keeping the parts that are needed and auto-shedding those that have come to the end of their useful existence.
Naming Conventions Don’t Work
You’ve likely implemented or have seen many naming conventions implemented to address this very topic. In my experience, a naming convention typically encodes attributes into the name (perhaps into a `Description`) with the intent to give more context to the object. This may work in some situations and it may help humans visually inspect the object. The problem begins when these existing encoded dimensions change or no longer capture the entirety of the object’s schema. When faced with this challenge, proper hygiene means renaming all existing objects, or, in the more common scenario, breaking the naming convention altogether. The end result is heterogeneous names and paralysis due to confusion and the need to research.
Suggested Actions
If you have access to an extensible schema for your objects, use it. Give those objects a rich identity that empowers a complete lifecycle of the object, from creation to decommissioning.
In the case of our Lola, she has her tag on her collar with her name and our cell phone numbers. However, she also has a microchip that extends the schema of her attributes to include our details, her vaccinations, etc. in case she gets lost and loses her collar.
If you’re building or managing IAM software, expand the universe to enable rich schemas in the system. Some of us may want to have a “lucky” group/policy/agent, and we certainly want better ways to identify and protect our Lola’s.
Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.
About the author
Pablo Valarezo is an Identity practitioner building and modernizing secure IAM programs over the last decade. His primary focus has been in the workforce side of IAM. He came to Information Security via system administration, project management, and audit and compliance.
