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?