Built-in Cluster Analysis

A cluster analysis report identifies groups of users who:

  1. have the same values for selected identity attributes; and
  2. have some minimum number of shared entitlements; and
  3. meet a minimum threshold for the number of matching entitlements; and
  4. meet a minimum threshold for the number of matching users.

Such clusters represent the intersection of a proposed user class and a proposed role to assign those users. This kind of search for viable clusters is shown in Figure [link].

    Cluster analysis of identities and entitlements: search

A summary run of the cluster analysis report, as shown in Figure [link], identifies possible clusters.

    Cluster analysis of identities and entitlements: summary output

Once a cluster of interest has been identified, the same report run in detailed mode shows the entitlements included in that cluster, as shown in Figure [link].

    Cluster analysis of identities and entitlements: detailed output

Role analysts can then map what they see in the cluster analysis to role and user class definitions.

Cleaning up Excess Entitlements

Hitachi ID Identity Manager can be used to clean up old, no-longer-needed entitlements. This is often done before undertaking role development. Entitlement cleanup can include the following steps:

  1. Construct user profiles from accounts on every authoritative system, such as Active Directory or HR.

  2. Map accounts on all other systems to these user profiles, either by assuming that their IDs are consistent (often true), by mapping other attributes, such as employee numbers or by inviting users to attach their own accounts to their profiles.

  3. Identify orphan accounts, not attached to any user profile:
    1. Some should be attached to users -- an oversight by their owners.
    2. Others are non-human accounts, for example used to run services. They should be marked as such and assigned to business owners, for example the people responsible for systems or applications where they are used.
    3. Others can (and should) be disabled or deleted.

  4. Map the org-chart, to identify supervisors for every user / subordinates for every manager:
    • This data is useful for IAM automation, used in processes such as change authorization and access certification.
    • Identify orphan users, with no known manager. Either delete their profiles and accounts or mark them as necessary, for example as non-human accounts or legacy data archival.
    A simple way to clean up the org-chart is to invite managers to review and correct lists of their subordinates.

  5. Collect last-login-date attributes for all accounts on systems and applications that capture this. Use this to identify dormant accounts and dormant user profiles (those that contain only dormant accounts):
    • Examine these accounts and classify how they are used -- are they business login accounts that are no longer required or place-holders that came pre-installed on a system, or are they actually used by an unattended process which does not update the last-login-date?
    • Disable or delete the accounts that are really not required.

  6. Orchestrate access certification, where:
    • Managers review and correct a list of their subordinates.
    • Managers review their subordinates' entitlements, marking items to revoke.
    • Application and data owners review lists of users with access within their scope of authority and mark users to remove.

  7. Define segregation of duties rules and look for violations:
    • Mark needed policy violations as approved.
    • Decide which entitlements in unneeded violations should go and revoke those.

This cleanup will reduce the volume of inappropriate entitlements and ease subsequent role definition.

Built-in Entitlement and Role Analytics

Identity Manager includes extensive analytics relating to existing roles, user classes and entitlement assignments. These are intended to support development and ongoing maintenance of a role model:

  1. Find clusters of users who have shared identity attributes and shared entitlements, as these are potential user classes and roles.
  2. Identify roles with overlapping entitlements -- should they be merged?
  3. Identify user classes with materially overlapping user populations -- should they be merged?
  4. Identify roles with too few users -- perhaps they should be retired.
  5. Identify roles with too many users -- perhaps they are too coarse-grained.
  6. Identify users with too many entitlements -- they could cause technical problems on end systems and probably represent high business risk.
  7. Identify users with too few entitlements -- do they still need access to systems or applications at all?
  8. Identify entitlements that are included in too many roles -- perhaps they should be attached to a base role, which is then nested into higher level roles.
  9. Identify entitlements not included in any role -- should they be?
  10. Identify users not assigned any role -- should they be? Are they members of a large enough community for this to be economical?
  11. Identify users assigned too many roles -- do they have too many access rights? Do new, higher-level roles have to be defined?
  12. Do any roles violate SoD policies internally (i.e., entitlements in the role are mutually exclusive)? This can happen when SoD policies are defined after the roles and should be remediated -- illegal combinations should not be so easily requested.
  13. Which roles have many users that, in turn, have many out-of-role entitlements? How many out-of-role entitlements do users assigned each role have, on average? This suggests either incomplete role definitions (add entitlements) or users that do not fit well into a role model.