PDF

swipe to navigate

The intersection of process and integrations

IAM systems create, manage and deactivate/revoke accounts and entitlements on account repositories. They do this as a consequence of business process. The value of an IAM system is a product of the processes it automates and the integrated systems on which these processes have an impact.

Implementing too many things at once is risky, so it makes sense to prioritize both integrations (mainly with account repositories) and processes. Over time, more integrations are added and more processes are automated.

Types of processes

All changes to identities, entitlements and credentials are driven by business processes. These processes can be categorized by two main variables:

  1. The trigger. The options are mainly user input, inbound API calls or bulk data import.
  2. Participants and how they relate to one another. The main participants are a requester and recipient, but there are often also authorizers, certifiers, escalates/delegates (i.e., people acting on behalf of others) and implementers.

The most common processes implemented by an IAM system are:

SoR-driven automation
Process:

The IAM system monitors a system of record (SoR), such as an HR repository in a corporation or a student enrollment system at a college and automatically creates, modifies and deletes identities in response to changes in the SoR.
Triggers:

Bulk data feed, API call or periodic check of a transaction log.
Participants:

Requester is a virtual identity representing the automation process itself. Recipients are users whose records changed in the SoR.

Self-service requests
Process:

A user signs into the IAM system, typically using a web portal and makes a request where he is the recipient. For example, updating his own identity attributes (new phone number, etc.) or requesting new access rights.
Triggers:

User input on the IAM portal.
Participants:

The user is both requester and recipient

Delegated requests
Process:

A user signs into the IAM system and submits requests on behalf of others. For example, a manager may sign on and request the creation of an identity for a new contractor, or access rights for an existing subordinate.
Triggers:

User input on the IAM portal.
Participants:

Two distinct users, related in some fashion that allows one to make a request on the other's behalf.

Authorization
Process:

A user is invited to approve or reject an already requested change.
Triggers:

May be triggered by any request that is submitted to the IAM system.
Participants:

A requester, a recipient and at least one authorizer. The authorizer may be chosen based on the identity of the other recipients (e.g., manager of one of them), or because of a relationship to a requested entitlement, or because he is assigned to a policy or a risk-related process.

Certification
Process:

A user is invited to review the identity and entitlement data for one or more users and either accept it or ask for some items to be revoked.
Triggers:

A schedule (e.g., periodic, bulk reviews) or an event (e.g., a transfer).
Participants:

The certifier is related either to an entitlement (e.g., group owner) or to users being reviewed (e.g., manager, department security liaison, partner representative, etc.).

Manual fulfillment
Process:

A user is asked to manually complete a task that was already requested, validated and approved but could not be completed with automation (connector not yet deployed or not economical).
Triggers:

May be triggered by any request that is submitted to the IAM system for which no connector has been configured.
Participants:

The implementer is related to an entitlement or similar asset (e.g., building access badge, etc.). May in some cases be related to the recipient (e.g., verify completion of training, etc.).

Prioritizing processes

Most organizations try to maximize the impact of their IAM system while minimizing the number of users involved. This is because user engagement can be costly, due to training, awareness programs and support. Moreover, many users have low tolerance for problems with systems they use, and newly deployed systems typically experience a few problems when first deployed.

With this in mind, it's reasonable to begin with SoR-driven automation if possible. Next, depending on the business drivers (cost/service versus security/controls), the next phase may be delegated access management or access certification. Self-service access requests and profile updates are usually rolled out last.

Within the context of a request portal, most organizations deploy first to IT security staff, as they are a more tolerant community of users and may provide valuable feedback about problems, usability, etc. before the wider user community is invited to use the system. Next may be the entire IT group, for the same reason. Managers usually follow, as they make the most requests and are often invited to participate as authorizers. Users acting in a self-service capacity are usually engaged last, as they are the largest community, may require the most support and may have the lowest tolerance for problems.

Types of and priority of integrations

Just as there are multiple types of processes that an IAM system can automate, so there are many kinds of integrations that can be deployed.

Account repositories may include any of the following:

  1. Systems of record, such as PeopleSoft HR, SAP HCM or Ellucian/Banner.
  2. Directories, such as Active Directory or other LDAP implementations.
  3. Operating systems, including Windows, Unix, Linux, iSeries/OS400 or zOS/RACF-ACF2-TopSecret.
  4. ERP applications, such as SAP, Oracle eBusiness Suite or PeopleSoft.
  5. Database login accounts, such as Oracle, Microsoft SQL Server, DB2/UDB, Sybase ASE or MySQL.
  6. Applications where user, entitlement or credential data is stored in database tables (other than ERPs, already mentioned above, and other than database login IDs).
  7. Software as a service (SaaS) applications, such as Salesforce.com, Concur, WorkDay, WebEx, Google Apps or Microsoft Office 365.

Other systems which should be managed, but may not have login accounts include:

  1. On-premises e-mail systems, such as Microsoft Exchange or Lotus Notes -- to create and manage mail folders and aliases.
  2. Filesystems -- to create and manage home directories.
  3. Strong authentication frameworks, such as RSA ACE/SecurID or Duo Security -- to assign credentials to new users and revoke access when people leave.
  4. Building access badge systems (many types, few standards) -- to grant and revoke facility access.

Most organizations prioritize integrations based on some combination of user population (the more widely used a system, the higher its integration priority) and change frequency (higher priority for account repositories whose user populations change rapidly). For example, AD and SAP may be integrated in a first phase, followed by systems with fewer users, such as iSeries or Linux.

Integrations that do not manage accounts or entitlements

Most integrations in an IAM system are user-centric. They include account repositories and systems that house other user-assigned assets, such as home directories, e-mail folders or authentication services.

Some IAM systems are also required to integrate with systems where no user-assigned assets will be managed. This includes:

  1. E-mail systems, in the sense of sending notifications and invitations to users, rather than in the sense of managing mail folders.
  2. Incident and request management systems, such as ServiceNow or Remedy. These integrations are typically to create matching records on these systems, denoting activity that already took place on the IAM system, so that reports run on these systems include IAM-managed user service events.
  3. Security information and event management (SIEM) systems, also to record incidents that happened on the IAM system on common infrastructure.

Small account repositories

The account repositories mentioned above are assumed to each house logins for a sizable subset of an organization's total user community. For example, most corporate users have an AD account, a mail folder, etc. More generally, in a typical organization there are a small number (normally well under 100) of systems and applications that each contain a sizable user population.

At the same time, most organizations also have a large number of much smaller account repositories. These may be specialized applications accessed by very small user communities or IT infrastructure -- laptops, servers, network devices, etc. where only shared administrator accounts exist.

The relative sizes of various types of account repositories are illustrated in Figure [link].

Relative sizes of account repositories

Relative sizes of account repositories

For business user login accounts on small, specialized applications, integrations are often uneconomical (e.g., 3 days of consulting fees to automate integration with an application that only has 10 users). Instead, it makes sense to bulk-load data into the IAM system regarding applications and their owners, to ask owners to enter accounts lists into the IAM system and to require owners to complete changes to accounts and entitlements manually. This way, there is a single system to request and manage access to all business applications (large and small), but tasks are completed automatically or manually, based on what makes economic sense.

Integrations with all IT assets

IT assets where there are only a small number of accounts and where the accounts are more often shared/generic rather than belonging to individual business users include:

  1. Operating system images, typically running Windows or Linux. These are often just the runtime platform for databases or applications, where users may have accounts. Local accounts are administrator or service accounts, rather than personal user IDs.
  2. Hypervisors, hosting the above -- VMWare, Xen, Hyper-V, etc.
  3. Database servers -- Oracle, Microsoft SQL Server, IBM DB2/UDB, etc.
  4. Network devices -- routers, switches, load balancers, etc.

While this is rarely an early priority, eventually some IAM systems grow to include integrations to all IT assets, including the above.

Such integrations are first the responsibility of a privileged access management (PAM) system, whose function is not to create/delete accounts or assign/revoke entitlements, but rather to connect authorized users to pre-existing, shared, privileged accounts on these systems. Eventually, organizations may expand the PAM functionality to include:

  1. Lifecycle management for application or service accounts -- i.e., developers or application teams requesting the creation of database connection accounts, application service accounts, etc.
  2. Managing the lifecycle of the ownership of systems and service accounts.

Since the number of integrations can be very large -- e.g., thousands of systems of each type -- infrastructure borrowed from privileged access management systems is required:

  1. Automatic discovery of systems, for example based on data in a configuration management database (CMDB) or directory.
  2. Automatic, policy-driven onboarding and removal of managed endpoints.

Automatic onboarding and deactivation of IT assets, to support lifecycle management of service and embedded accounts is illustrated in Figure [link].

Auto-discovery of managed systems

Auto-discovery of managed systems

PDF

Comment via LinkedIn