Where do we begin with an Identity Governance project? Perhaps the goals have already been established by your key stakeholders. Possibly it's a compliance initiative for regulations such as PCI DSS, SOX, HIPAA, or GDPR. Or you know that access permissions have accumulated and it's time to get to a state of least-needed access.

The outcome of your Identity Governance program should be the ability to prove that your risks are identified and managed. Here are seven areas to consider in your Identity Governance Goals and Objectives.

Let's start with two prerequisite goals that will set you up for success --

IAM Lifecycle

A thorough Identity & Access Management (IAM) lifecycle will give you the capability of zero-day start, change, and stop for user account access.

• New accounts are on-boarded and provisioned with proper permissions for the job role.
• Accounts moving to different job responsibilities have appropriate access added and unneeded access removed.
• Accounts that enter a not-active employee status (termination, on leave, retirement, other) are disabled, or permissions are removed as needed.

Linked Accounts

Linking all secondary and non-user accounts to specific owners will reduce your risk of unaccounted-for access.

• Administrative accounts are identified to their specific owner - and processed accordingly for lifecycle events. For example, these accounts are disabled when the primary user account becomes inactive.
• Service accounts must be identified and linked to a specific user/owner. Typically, this account would transition to another owner for IAM lifecycle events.
• Privileged accounts should be individually-owned and linked (as above), or governed by a Privileged Access Management (PAM) solution.
• Off-premises accounts for Cloud administration follow the same requirements.

Within Identity Governance itself, there are goals that will move you from (just) reviewing access to governing access --

Identification of Permissions

The names of the access permissions held by an account are generally not descriptive enough for a Reviewer to determine if the access is necessary. Effective descriptions for each permission will permit Reviewers to know what they are evaluating and make informed decisions. Permission descriptions also support role mining efforts.

Compliance-based Reviews - PCI DSS / SOX / HIPPA / GDPR / Other

If you’re holding sensitive data, you must identify the data and its permissions and specify the level of risk. There will be administrative & privileged account access to these items, and all access in any manner may form your requirement for certification reviews. Once identified, you certify the access around this specific data.

Roles

Roles are groupings of permissions to coincide with job responsibilities. This container-grouping reduces the burden of the review process and increases accuracy. Achieving Roles requires Role Modeling in which access permissions are grouped, reviewed, and approved for the specific job duties.

By using Roles, permissions granted that are outside the role are visible for scrutiny during Certification reviews. Periodic review and adjustment of all Roles are a requirement for keeping a least-privilege access model.

Risk-based Reviews

Risk-based Reviews are certifications that are performed upon the accounts and permissions posing a certain level of risk to the business. Taking a risk-based approach requires upfront identification of sensitive data and access and scoring its risk level. During periodic certifications, reviews are performed for the accounts exceeding a risk threshold.

• Administrator or other accounts with elevated levels of access
• Permissions to sensitive data
• Access to applications and servers holding sensitive data
• Any other factors that increase risk

Policies

An Identity Governance solution should incorporate the use of Policies to identify risk situations (Separation of Duties (SoD) or excessive access) and generate an Exception Review for the conflict. The Review process should enable the reviewer to permit the exception (with a mitigation plan) or to remove the access.

Writer: Jim Marshall