There are a few terms in IAM that are so often misused that they become nomenclature. One of the first things I generally recommend for any team is to establish some knowledge sharing tools like confluence site, lunch and learns, etc. This builds teams with a common understanding, terminology, and approach.
An example of commonly poor nomenclature I really dislike is the term "privileged ID". I cannot count how many times I have come across people assuming any credential term “admin” in its name, is a “Privileged ID” without so much as checking what access is granted to the credential. Of course saying” a credential that is granted privileged access” is rather long-winded, but when the “admin” credential turns out to be associated with the identity of the team's projector and used to reserve this projector in the team calendar, it becomes clear it's not privileged. As the parable of the Blind Men and an elephant goes, it's important to gain context and perspective. As a side note, this is usually also why self-assessments fail, with the question's context often being understood differently by the self assessor as the development of the assessment.
Identity refers to a unique object. This can be human or not (projector, room, mailing list, non-people ID). The characteristics or attributes of that object in some combination, help you identify it as unique. For humans, I often hear a definition of identity as a beating heart. When we refer to a user and not a user account, we refer to the identity of the person using the system.
A persona, on the other hand, is something that either we choose to project or as others perceive you as. This is often due to some grouping of your identity with others by some shared attribute. Employee, client, banking, personal, cybersecurity specialist, malicious attacker, coffee drinker and so forth. It is a role or function that represents some subset of your entire identity. Each identity is usually made up of multiple personas.
Let's take Betty Banker Social Insurance Number 123456789. Betty has a master's degree in finance, is married, has children and works for a large enterprise bank. Betty probably has the persona of educated in finance, spouse, parent, a customer of the bank, an employee of the bank. Secretly Betty has developed her own ransomware under the pseudonym of di$gruntled and used her inside knowledge of the bank to introduce it. If we assume di$gruntled is an identity and not a persona for Betty Banker, we would never have a complete view on Betty Banker or di$gruntled. This is why insider threat programs need to focus on establishing all personas for an identity.
A credential is a digital representation of an identity. It usually contains a username and a secret (password, key, etc). Account (user account) or ID is often used instead of the term credential. Although in a theoretical world, we may think that every identity would only have 1 credential, in actuality you may have many similarly-named credentials that may or may not share the same secret. The reverse is also unfortunately true.
Let's say we give Betty Banker Social Insurance Number 123456789 a primary credential of bbanker@thebank.ca. This credential is created in the production active directory. Robert Banker (not related) goes by the name of Bob, but his primary credential is rbanker@thebank.ca (the same domain). The bank starts using a SaaS-based application, not connected to active directory, as such the credentials now are not linked to the domain @thebank.ca. The SaaS application is provisioned by the business, and not IT. During an audit, the credential bbanker is found in the SaaS application and assumes its Betty’s credential, when in fact, it is Robert (Bob) Banker’s. This is actually a very common problem in credential management, especially with short, common names. What would you say the chances are that if Bob called the help-desk, they would reset bbanker@thebank.ca password for him?
So technology today goes from 1000 of attributes enabling a high level of identity validation in the physical world to a digital representation of that identity (credential) with its own set of attributes, linked only by a few non-unique attributes. This is the “Identity Bottleneck” and is one of the two most common mistakes I see in managing access to digital content. Zero trust does not mean you trust the credential, but trust the actual identity of the user. For strong identity assurance, companies need to reduce this bottleneck and ensure sufficient attributes are used to link credentials with identity. That ALL identities and ALL credentials have a single common book of record, shared throughout the organization.
For this reason, an IBoR (Identity Book of Record) becomes a foundational component to build your corporate IAM infrastructure on, acting as a bridge between identity and credential or the physical world with the digital. While human resource systems can be your authoritative source for identity and are usually responsible for assuring the physical identity of the person, they are not an IBoR as they are usually focused only on HR and work personas. Neither is active directory an IBoR as is it offers no linking to other credentials in different systems not connected to the same domain.
For example, bbanker at thebank would have bbanker@thebank.ca for their primary credential, but perhaps bbanker@devbank.ca for their development account in the development domain. As a customer, they may have bbanker@home.street and for a hobby di$gruntled@darkweb.haha How would these credentials be linked in a single directory? Without an IBoR how would you know where to look to remove or view all access for Betty Banker. What happens when Betty left 6 months ago, and the credential bbanker@devbank.ca is found in the development directory? Who’s credential is it really? Perhaps it's now a Non-People ID (NPID) or service account for the bullion banking system and deleting it would set back the project for weeks.
The term key-chaining is sometimes used for what an IBoR is meant to do, linking identities to credentials with sufficient attributes to ensure the digital world can be assured of the credentials owners identity. Corporate IBoR’s are currently usually limited to linking identity with corporate credentials. There is also a lot of work going into this area at the moment, from block-chain based identity, BYOID and other forms of universal credentials and over time I would expect the persona layer to be added. More on this later.
No comments:
Post a Comment