5 Ways to Gain Access

Please don't let any auditors read this one! Just think of the issues if you have not built controls around all 5 means of granting access. 

Usually, an organization has a "standard" approach and often ignore the other 4. These are then used by people trying to get around the controls as "back doors around security". When people talk automation, they consider it as a means to optimize something, but a second benefit is that of consistency. Only 1 or 2 of these ways will usually be partly automated, but all are probably used if manual provisioning is still in place.

The following is a standard 1 application reference model. The credential and group may be abstracted in a directory like Active Directory or local to the application.

1. Identity - The user or "beating heart"
2. Credential - The digital representation of the user
3. Group - an object to which entitlements are mapped rather than mapping entitlements directly to users. Groups create standardization while reducing complexity and provisioning tasks.
4. Entitlement - entitlements are what access is granted. for example, read this table or edit this field.
5. Application - The system or platform to which the entitlements are for.

Simple when there is one identity's, one credential, one group, one set of entitlements and one application. But what about an organization with 100,000 users, with 3000 applications each with say 5 application roles (entitlements)?

1) Multipurpose groups

Sometimes you already have a team all sitting in a group and want to give the team additional access. Creating a new group, then adding each user to this new group, with all the required approvals, etc, can seem daunting, so why not just change the entitlements associated with the group by giving it access to a new application. Reuse/repurpose after all!

In a larger organization, the application teams usually don't have provisioning access to Active Directory (AD), where security has built controls and audit monitors closely for compliance. The application admin though may be able to assign new entitlements for their application to an existing group in AD without those controls getting in the way. So since I want to give this team access and they all in an existing group already...
Its a point in time view, that can become impossible to manage and control. In no time, you have a single group giving access to multiple systems and the entitlements of group membership are only half-known. Then someone wants to revoke one of the members of the group from only one of the entitlements and it all falls apart.
Changes to groups and the entitlements are usually stored in an entitlement or role catalog and when controls are not in place to manage these changes, access, approval and certification systems can all be bypassed.

2) Direct to Credential

This is often for the same reasons as above, but when you want to give access only to one person. Rather than assigning the access to a group, then put the credential in the group, the application administrator can grant the entitlements directly to the credential locally or in AD.

When anyone looks at the group memberships of the credential to establish what access that credential has they probably will not notice this direct access. The only way to see this direct access is in the application. This is very common with MS SQL, where a credential can be given access at the database level, instance level, OS level or AD level directly. 

The result looks something like spaghetti, which rapidly becomes impossible to manage in all but the smallest organizations. One of my engagements had approval limits (entitlement) mapped directly to thousands of people over 15 years. Since each was assigned independently, the dollar value of the approval limits was nearly as different between credentials as there were credentials.

3) Creating a New Credential

In some cases, this is required due to system or infrastructure limitation or purpose-built design. An example would be if someone needed access to a preproduction environment that is on a different domain.
This is also the basis of most PAM programs today. Where a user is given temporary access to a privileged credential to use and entitlements are not assigned to the same credential.

The negative aspect of this approach comes when a shared account or some NPID (non-people) is used to grant access outside of controls like a PAM program. Not only is this access then invisible, but a user that leaves the organization often still retains the access as they know the credential and password.

While changes to entitlements to groups are usually a change in the entitlement catalog, identity to credential mapping is done in the IBoR for legitimate reasons for this approach at least. That said, a combination of 2 and 3 is a fairly common "pattern" for malicious intent.

4) Creating a New Persona

This may be for privacy, organization, convenience or malicious. Many times this is hidden under the name of "Service Account" which actually turns out to be a shared credential or some personal secondary credential. This can generally be considered malicious at the point the user tries to hide their identity behind one or more of their credentials.

Insider threat programs often need to focus on this approach. Bob may be a medical health records admin with impeccable work ethic, but selling health information after hours as DeathW1$h using the credential ftptransport.

5) Creating a New Group

The last is what most common people expect to happen and what is usually has controls and automation around. Create a new group, map the new entitlement to the group then follow the standard request process to get access to the group.

With the same credential added to the new group representing the new entitlement, although it remains a 2 step process of updating the entitlement catalog and then requesting access, with minimal IDM infrastructure a view off all access for the identity is easily established.

So how many of these does your organization have controls in place to deal with?

The "Identity Bottleneck"

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.

So what is (digital) Identity?

What is identity is a philosophical question that's foundational in many areas of study for centuries. There are quite literally thousands of books on the subject with amazon showing over 60,000 hits. By definition, identity is “The distinguishing character or personality of an individual” according to Merriam-Webster. Something “distinguishing” means there is some single or grouping of “attributes” that can be used to separately identify one object from another. Therefor to be distinguishing, it needs to be both measurable and known attributes.

A measurable attribute can involve 1 or more inputs to your 5 senses of sight, sounds, smell, taste or touch in incredibly complex combinations. It could also be calculated or known. Aka they always order vanilla or employees over 1 year. It can also be in context or relation. The one you spoke with or the one behind that one. Just like a visually impaired person may prefer to use voice tone to distinguish the identity of someone over the shape of their nose, digital identity generally places different values on distinguishing characteristics than the physical world. For decades security folks have used something you are, have or know as the basis of authentication, but there are many contextual (e.g. in the office), calculated (e.g. PKI) and possibly other attributes that could be used.

 

The usual nature of identity is that these same attributes that make us unique, can be used to group individuals. Grouping users by attribute allows for simplification of policy and assignment. Along with grouping comes the risk of assumed bias. This can be to the group as a whole or the understanding of the grouping. 

For example, I may group all people in over 5 feet tall or under 5 feet tall (not very practical perhaps). But is this sitting down or standing up, fully grown or include those still growing (how is that measured??). I may also have a personal unreasonable fear of anyone over 5 feet tall, resulting in this attribute to be used as a general negative to anyone in this category. Treating 1000,000 customers as 100% unique, maybe impractical, but grouping them too widely, by the incorrect attribute or with bias would lessen the value of the grouping.

Identity is not only about humans, as we use the same principals of using distinguishing characteristics to identify any object. It is a dog, that black cat, the yellow bike, the house next to mine. Digitally, it can be extended to applications, servers, physical devices, buildings, virtual devices, fields, data, IP addresses and anything else you may need to reference. Identity is used for everything, either to include or exclude it, individually or as a group.

Even in the physical world, there are many opportunities to mistake someone's identity, when there may be an absence in the accuracy or number of distinguishing attributes. You may see a shape in a dark living room, and due to the lack of available attributes and a dose of bias, assume it is your spouse. The human shape, the height, smell, location, context (since your spouse stood there last), experience (it's usually your spouse in the living room) leading you to assume incorrectly. Only to discover the second the person spoke (new attribute) that it was actually not your spouse, but their parent. Whew, good thing you did not mention last Thanksgiving turkey again! “Identity assurance”, is used to express the level of confidence that you have correctly identified the person by validating the known attributes that make up their identity. 

While in the physical world, we often have thousands of attributes available, in the digital world this is often reduced to a few fields of data (see the Identity Bottleneck). Companies often expend immense effort in knowing attributes about their customers, employees, market, and partners. Every day you hear of huge digital projects and hype around analytics, big data, AI, building supply chains or building their brand. Only to then use a username and single secret (e.g. pa$$w0rd) as the only attribute before giving access. This is probably a relic from the first computer systems, that assumed attributes from context. If Bob is one of 20 users on the mainframe and uses terminal 5. We just need an attribute to know out of the 20 users, that this is Bob. In today’s world, there are billions of connected people, accessing systems scattered across the world from multiple devices, yet for the most part, the industry still relies on the same approach to identify a user. It worked for 50 years after-all – well at least kind of worked, as few today have not wondered why technology battles with security incidents like they do.

Identifying attributes change at different rates. The one you own may be the one I lost tomorrow, but my name probably remains the same for some period of time. I am logged in from the office, then go home and continue to work. If location and IP address were used as attributes to identify the user, although the user's identity did not change, the digital system may not be aware that it is the same user. Rapidly changing attributes can also be red flags, for example, Anne accessed one system at 4pm from Toronto and another at 5pm from Moscow. From these examples, we can see that the change in attributes, can be used as an attribute in identity. Changes in attributes can also kick-off events or tasks. A change in Anne's employment status attribute could trigger the removal of access. A change in IP address could trigger the need to re-authenticate.

In our real lives, we require different levels of identity assurance for different tasks. Anti-money laundering policies require banks to “Known Your Customer” (KYC) and you may need an ID if you near of age to get into a bar. You would probably bulk though if someone needed to know more than that you are a paying customer when buying coffee (how many use a fake name at Starbucks?). Depending on the risk of access, the level of identity assurance may vary. NIST special publication 800-63 spends a considerable about of effort discussing this idea of adapting identity assurance levels, depending on what is being accessed.

Balancing privacy with identity assurance may seem in conflict, but this is were the selecting and storing of the attributes and the relationship with the user become important. Whenever I do an assessment, I like to ask what the organization uses for an Identity Book of Record (IBoR) and what attributes are stored for each identity. So often the response is the HR system or Active directory. In these cases the “HR System” is usually a basic report sent to security, strictly scrubbed for privacy, with a couple of fields, many which are useless to establish digital identity. Active directory is usually, outdated, partial and credentials, not identities. With anonymous dating profiles often having more stored identifying attributes than IBoR’s! With HR, marketing, sales, asset management, service catalogue etc all operating in isolation to IT and security, how can anyone be surprised when malicious parties take advantage?

What are you doing to build a more capable IBoR and attributes are you collecting for your users to improve your identity assurance levels?