• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Standard IAM Business Processes: Corporate / Intranet Deployment
 

Standard IAM Business Processes: Corporate / Intranet Deployment

on

  • 754 views

This document introduces best practices for managing users, identity attributes and entitlements in a typical "corporate" environment: ...

This document introduces best practices for managing users, identity attributes and entitlements in a typical "corporate" environment:

1. The focus is on organizations with 1,000 to 10,000 internal users, such as employees or contractors. They may be corporations or non-profit organizations such as government, healthcare or military entities.

2. Users in these environments are normally provisioned physical assets, such as a cubicle, desk, chair, phone, PC and building access badge.

3. Users in these environments are also provisioned logical access, such as an Active Directory login account, Exchange mail folder, Windows home directory and a variety of application security entitlements.

The objective of this document is to identify business processes that drive changes to users and entitlements in an organization that fits this description and to offer best practices for each process.

Organizations that are able to adopt best practices processes will benefit both from optimized change management and from reduced total cost associated with automating their processes on an identity and access management (IAM) platform.

Statistics

Views

Total Views
754
Views on SlideShare
754
Embed Views
0

Actions

Likes
0
Downloads
26
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Standard IAM Business Processes: Corporate / Intranet Deployment Standard IAM Business Processes: Corporate / Intranet Deployment Document Transcript

    • Standard IAM Business Processes Corporate / Intranet Deployment © 2014 Hitachi ID Systems, Inc. All rights reserved.
    • Contents 1 Introduction 1 2 Integrations and manual fulfillment 1 3 User schema 3 4 Unique identifiers and object location 4 5 Role-based access control 8 6 Onboarding new users 9 6.1 HR driven automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Manager initiated requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3 The role of security officers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7 Change authorization workflow process 11 8 Changes to user profiles and entitlements 12 8.1 Self service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2 Manager initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3 HR initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.4 IT security initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.5 No direct relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9 Managing membership in security groups and mail distribution lists 13 10 Role changes 13 11 Temporary and permanent access deactivation 14 11.1 HR initiated, scheduled termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.2 HR initiated, immediate termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.3 Manager requested, scheduled termination . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.4 Interactive, immediate termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.5 Clean-up of terminated user profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12 Returning users / rehire scenarios 16 i
    • Standard IAM Business Processes: Corporate / Intranet Deployment 13 Periodic access reviews 16 14 Self-service password management 17 15 Reports and alerts 18 © 2014 Hitachi ID Systems, Inc. All rights reserved.
    • Standard IAM Business Processes: Corporate / Intranet Deployment 1 Introduction This document introduces best practices for managing users, identity attributes and entitlements in a typical “corporate” environment: 1. The focus is on organizations with 1,000 to 10,000 internal users, such as employees or contractors. They may be corporations or non-profit organizations such as government, healthcare or military entities. 2. Users in these environments are normally provisioned physical assets, such as a cubicle, desk, chair, phone, PC and building access badge. 3. Users in these environments are also provisioned logical access, such as an Active Directory login account, Exchange mail folder, Windows home directory and a variety of application security entitle- ments. The objective of this document is to identify business processes that drive changes to users and entitlements in an organization that fits this description and to offer best practices for each process. Organizations that are able to adopt best practices processes will benefit both from optimized change management and from reduced total cost associated with automating their processes on an identity and access management (IAM) platform. 2 Integrations and manual fulfillment At a minimum, an identity and access management system should integrate with: 1. A data feed from human resources (HR) to trigger automatic setup, modification and deactivation processes. (a) It should not be assumed that all the data from HR is correct. Managers assigned to staff, department codes, contact information and more may be obsolete or simply wrong. (b) Changes to HR data and in particular adds and deletes, can generally be considered to be accurate and can be used to trigger changes. 2. Active Directory. 3. Exchange, for e-mail. 4. Windows file servers, for home directories. Here it is assumed that AD/Exchange/Windows are used, simply because these are by far the most common systems for directory, e-mail and filesystem services. Alternate products, such as Lotus Notes, should be managed where they are used. Initially, an IAM system can invite human system administrators to complete authorized changes on other applications. Over time, other systems should be integrated, in a sequence determined by the frequency of changes that they require. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 1
    • Standard IAM Business Processes: Corporate / Intranet Deployment Integration with an incident management system is also important and should support: 1. Automatically creating incidents to reflect events such as user creation and password resets, for con- solidated record keeping and analytics. 2. Allowing users to request access for new hires and initiate terminations through the incident manage- ment system. (a) Many organizations use a service catalog or incident management system as a portal for users to make common requests, such as to provision new-hires or deactivate departing staff. (b) This type of web portal includes options for hardware (e.g., what kind of PC or laptop should the new hire get), connectivity, office space and more. (c) This sort of portal can also trigger activity around asset collection – retrieving a departing user’s laptop, building access badge and more. (d) It is natural to extend such onboarding and deactivation forms to include requests to enable or disable logical access, with API-level integration forwarding the request details to the identity management system. (e) The identity management system should report back to the incident management system as it either completes or rejects sub-tasks. All these integrations are illustrated in Figure 1. Figure 1: Integrations between IAM system and AD, Exchange, Windows, HR and incident management © 2014 Hitachi ID Systems, Inc.. All rights reserved. 2
    • Standard IAM Business Processes: Corporate / Intranet Deployment 3 User schema User profiles typically contain the following information: 1. Primary login ID (e.g., as used on AD). 2. Employee number (if different from above). 3. First and last names. 4. Middle initial. 5. Work contact information: (a) Language preference (for multi-lingual organizations). (b) E-mail address. (c) Office phone number. (d) Mobile number. (e) Building code. (f) Floor / section. (g) Cubicle / office number. 6. Organizational information: (a) User type (e.g., E=employee, C=contractor, etc.). (b) Date of hire. (c) Department code. (d) Manager’s user identifier. Privacy-sensitive data may also be included, subject to access controls that limit who can see it: 1. Data that could be used to impersonate the user: (a) Primary citizenship. (b) Social security number / social insurance number. (c) Date of birth. (d) Mother’s maiden name. 2. Home contact information: (a) E-mail address. (b) Home phone number. (c) Mobile phone number. (d) Mailing address. User profiles may contain technical data, which should be hidden from users to avoid confusion and ques- tions: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 3
    • Standard IAM Business Processes: Corporate / Intranet Deployment 1. Home directory UNC path. 2. Mail server. 3. Home directory server. 4. Mail folder disk quota. User profiles may also contain data which is hidden from the user because it is confidential: 1. Scheduled termination date. 2. Scheduled reactivation date. 3. Actual termination date. 4. Rehire allowed (Y/N)? 5. Termination notes. 6. Previous termination date (this user was rehired). These profile attributes should be collected into groups, so that different access rights can be granted to different combinations of requester, recipient and category of data. 4 Unique identifiers and object location An identity management system must enforce a number of rules regarding the assignment of unique IDs, the placement of AD accounts in appropriate OUs, the placement of mail folders and home directory servers on appropriate servers, etc. While these rules really do vary from one organization to another, following are some suggested best practices: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 4
    • Standard IAM Business Processes: Corporate / Intranet Deployment Object / identifier Recommended process samAccountName (short, unique login IDs) 1. Assign new IDs to all new users – never reuse the ID of a former user. 2. If possible, assign IDs numerically. Name-based IDs may be more friendly, but they are costly to support when users’ names change. 3. Never base a user’s ID on their job code, as this may change but the ID should remain the same. 4. Where name-based IDs are used: (a) A suffix is often needed, to avoid collisions. (b) Plan for the process that will be used to change a user’s ID in response to a name change. This should be a carefully controlled and manual process, since it might break batch jobs, scheduled jobs, e-mail routing rules, etc. 5. Keep the ID short (8 or fewer characters) – this reduces typing effort for the user and enhances compatibility with legacy applications. 6. IDs should be considered to be case-insensitive – i.e., ABC123 and abc123 should be considered to be the same ID. A good policy is “first 4 letters of first name plus 4 digit sequence” – for example, the third “Michael” user would be MICH0003. Using first names is better than surnames as they are less likely to change. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 5
    • Standard IAM Business Processes: Corporate / Intranet Deployment Object / identifier Recommended process E-Mail address 1. The norm in most organizations is first.last@orgname. 2. Where required, a middle initial should be added for uniqueness: The norm in most organizations is first.initial.last@orgname. 3. Where adding middle initial is not sufficient to get a unique ID, adding a unique number before the @ sign is reasonable: The norm in most organizations is first.initial.last.num@orgname. 4. Never reuse old e-mail addresses – always assign new ones, even if the old ones are associated with long-gone individuals. This prevents the situation where an employee leaves and at some later date an e-mail is received by a different person containing sensitive information relating to the former employee – a potential liability problem for the corporation. 5. Consider changing the user’s e-mail address in the event of a future name change. This should be a carefully controlled, manual process since other data may depend on the old address. The old e-mail address should always be retained, as an alias for the new ID. Directory OU container 1. Most organizations use directory containers (OUs) to structure their user list. 2. Some organizations use a geographic hierarchy, departments or other variables to structure their directory. 3. A flat name space can also be used, so long as the number of users in a single directory container is not in the tens of thousands. 4. When implementing business logic to place users into an appropriate OU, include logic to move the user’s account to a new OU if key variables, such as the user’s location or department, change. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 6
    • Standard IAM Business Processes: Corporate / Intranet Deployment Object / identifier Recommended process Directory CN for the user 1. While multiple users may have the same CN in their fully qualified name, so long as their accounts are in different OU’s, assigning only locally-unique CNs is a mistake, as it can trigger problems when a user’s account is moved to a new OU. 2. The best practice is to make the CN the same as the user’s samAccountName - a short, globally unique identifier. Placement of mail folder 1. It is best to select a mail server that is physically near the user’s usual place of work. 2. If multiple mail servers match, if a central cluster of servers is used or if the local mail server is full, select a mail server based on available free disk space. 3. Move the user’s mailbox to a new mail server if the user moves to a new location in the future. 4. In Exchange 2010, the mail server itself can implement the above logic. Placement of home directory 1. It is best to select a file server that is physically near the user’s usual place of work. 2. If multiple file servers match, if a central cluster of servers is used or if the local file server is full, select a file server based on available free disk space. 3. Move the user’s home directory to a new mail server if the user moves to a new location in the future. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 7
    • Standard IAM Business Processes: Corporate / Intranet Deployment 5 Role-based access control Roles are collections of security entitlements – login accounts, membership in security groups and other roles. They can be used to more conveniently and efficiently manage what users can access. Role- based access control (RBAC) is a strategy for managing security entitlements by assigning collections of entitlements, rather than individual entitlements to users. Every organization will have its own roles, based on its business and structure. As a result, there can be no “standard set of roles” that apply to multiple organizations. When applying roles to user rights, it is helpful to consider some basic guidance: 1. Roles are most helpful if they can be applied to many users. A role that can only be used by one or two users does not add value, and most likely will lower efficiency. 2. As the number of roles grows, the cost of maintaining role definitions and rules that assign roles to users also rises. This cost can become prohibitive if the number of roles grows into the hundreds or thousands. 3. Most business users do not have the skills, time or inclination to assist in the definition of roles, so the cost of role maintenance realistically lies with the IT organization, who must consult with the business to perform this function, but cannot offload this function onto the business. 4. Roles can be combined with other mechanisms, such as user requests for individual entitlements. This means that it is not necessary to define a role for every user, or to include all of the security entitlements needed by a given user in that user’s role. With these considerations in mind, it makes sense to: 1. Begin with a small number of roles – say fewer than 20, and add gradually. 2. Use a hierarchy of roles where practical. This reduces the cost of ongoing administration as changes have to be made in fewer places. 3. Avoid a deep hierarchy of roles, as this can make it difficult to understand why a user was assigned an entitlement. 4. Focus on developing roles for large communities of users with identical security needs. Gradually expand the scope of RBAC to include role definitions for smaller user communities. 5. Avoid roles for users with one-of-a-kind job responsibilities. 6. When a few users within a community have unusual requirements as compared to their peers, con- sider handling this on an exceptional basis (user gets a role plus some additional entitlements) rather than defining a new role. The remainder of this document will only make passing reference to roles and RBAC, as the guidance offered applies regardless of RBAC adoption. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 8
    • Standard IAM Business Processes: Corporate / Intranet Deployment 6 Onboarding new users There are basically two processes for onboarding new users into a corporation: 1. Detect new hires in the HR data feed and automatically provision them. 2. Empower managers to request access for new hires. 6.1 HR driven automation This approach depends on the availability of accurate and timely data from HR. In organizations where HR data is either late or not reliable, this approach should not be attempted. Where such data is available, it should be used to: automatically create basic access rights for new users who appear in the HR data feed – typically this is limited to employees. The password for newly created accounts – on Active Directory and elsewhere – should be a random string, to prevent security compromise. This means that all new users will require a password reset before they can use their new accounts: 1. Where personally identifying information (PII such as mother’s maiden name, date of birth, etc.) is available, users can be required to authenticate with their PII before they can reset their initial pass- word. 2. Where PII data are not available but new employees’ managers are identified, the manager can be asked to set the employee’s initial password manually and communicate that password directly to the new hire. 3. Where neither PII data nor manager IDs are available, new hires should be required to physically visit an IT support individual to set the initial passwords. 6.2 Manager initiated requests Where HR data is not available, not trusted or not timely, managers should enter access requests for new hires. This is almost always the case for contractors, vendors and temporary workers, for example. In this scenario: 1. Only designated managers should be able to request the creation of new user profiles. 2. An approvals process is needed to authorize new user access. Who the authorizer should be depends on the requirements of each organization – there is no best practice here. Options include a contractor management group or someone in the management chain of the requester. 3. Managers may be subject to restrictions regarding the user profiles that they request. For example, the location code and/or department code may be automatically set to be the same as the manager, or the manager of the new hire may be automatically set to the identity of the requesting manager. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 9
    • Standard IAM Business Processes: Corporate / Intranet Deployment 4. If employees are automatically provisioned via an HR feed, the available status codes in the requests portal should be restricted so that requests cannot be used for employees. This restriction is to prevent an employee from being provisioned twice – once automatically from the HR feed and again, via request, due to an impatient manager. In many cases, the user’s manager is the sole authorizer for changes pertaining to the user. When this is the policy: 1. If the manager entered the change request, it should be auto-approved. 2. If a security officer or administrative assistant enters a request on behalf of the manager, the manager should still be invited to approve the change. This process can be used to help managers understand the system and to encourage them to enter requests directly. 6.3 The role of security officers Initially, the web portal intended for managers might be mostly used by security officers, who may submit change requests on behalf of managers. Engaging security officers to fill out change requests on the identity management system’s portal is helpful both initially and over time: 1. Initially, to prove out the system and work through any usability problems before inviting business users to use the portal. 2. Over time, to handle more complex use cases. It is important to transition the bulk of change request input away from security officers to managers, in order to realize cost savings from the system. Organizations should carefully manage this transition, since many managers will prefer to just call IT security and verbally ask for changes, rather than filling in forms on a request portal. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 10
    • Standard IAM Business Processes: Corporate / Intranet Deployment 7 Change authorization workflow process In a variety of scenarios, including the manager-initiated onboarding use case described above, one user or process will request a change and one or more additional users will have to review and either approve or reject that change. Since business users may be too busy to respond promptly and may not respond at all, a number of strategies should be considered to elicit prompt and reliable action: 1. Always invite more users than are strictly required to approve a change request. This shortens aver- age response time and improves the odds of getting a response at all. For example, if one person’s approval is required, invite two. If two are required, invite at least three, etc. 2. Invite all the relevant authorizers at the same time. Do not wait for one authorizer to approve a request before inviting the next. This substantially shortens the approvals process because the total time to approve a request will be the time required by by the single slowest authorizer to reply, rather than the total of response times of multiple authorizers. (a) Some organizations argue that sequential approvals are preferable because they shield subse- quent authorizers from the nuisance of requests that would otherwise have been rejected earlier. (b) In practice, most requests are approved – users are not likely to enter requests into a system where there is transparency and audit trails that would just be rejected. (c) In most organizations, the overwhelming majority of requests – typically over 90% – are ap- proved. This means that the maximum “nuisance” effect of late authorizers being bothered by invalid requests is small. (d) The requests which are rejected are almost always due to user input errors, rather than attempts to gain inappropriate access rights. This problem should be addressed as a usability problem, with form validation, on-screen help text, suitable resource names and so on. (e) All users prefer rapid response times, since requests are made in order to satisfy business needs and these are often urgent. Users generally prefer short SLA to occasional nuisance invitation e-mails. 3. Send non-responsive authorizers reminder e-mails. A reasonable policy is to send a reminder invita- tion to review a change request every 2 hours during the work day. 4. Invite alternate authorizers (escalation) when a primary authorizer fails to respond, despite being sent numerous reminders. A reasonable policy is to escalate after three reminder e-mails. 5. Escalate to the manager of the original authorizer. This ensures that the new authorizer will have the authority to approve the change request in question. This escalation path also motivates authorizers to respond promptly, because they know that failure to respond will trigger an e-mail to their manager. 6. Allow the original authorizer to respond even after escalation. If this happens, thank both the original authorizer and anyone invited via escalation, so they know that no further action is required. 7. Check authorizers’ out-of-office e-mail status. Authorizers who are known to be unavailable should be replaced immediately (pre-emptive escalation), rather than waiting for them to fail to respond. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 11
    • Standard IAM Business Processes: Corporate / Intranet Deployment 8 Changes to user profiles and entitlements 8.1 Self service Users should be able to update their own contact information, and in particular their home contact informa- tion. Some change requests, especially those without a security implication, should not require authorization. For example, a self-service update to a user’s home mailing address or phone number should not normally require approval. Users should be able to request access to new applications and security groups. 8.2 Manager initiated Managers should be able to modify work contact information for their direct and indirect reports and request changes to their application access and security groups Managers should be able to see and modify termination dates, but only for users that report to them. 8.3 HR initiated HR should be able to see and modify PII for all users, to set termination dates and to change user status (e.g., between employee, contractor, etc.). HR should also be able to modify home and work contact information, department code and manager ID. HR alone should be able to request changes in user names. HR initiated changes that modify the department code or manager ID should be authorized by the new department’s head or the new manager, respectively. HR initiated termination may require approval by the manager of record. 8.4 IT security initiated IT security should be able to directly manipulate user status, termination date, application access and group memberships, typically without waiting for approvals. 8.5 No direct relationship Where there is no direct link between two users, a requester should be able to see but not modify a recip- ient’s name, work contact information and organizational information. This enables the system to act as a directory of corporate user phone numbers, e-mail addresses and office locations. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 12
    • Standard IAM Business Processes: Corporate / Intranet Deployment 9 Managing membership in security groups and mail distribution lists By default, the identity management system should support user and manager requests for changes to membership in all groups on Active Directory. The default authorization for group membership changes should be each group’s owner. Where no group owner is defined, a single, global authorizer should be used – preferably someone with the ability to set the ownership on groups. 10 Role changes For users whose entitlements were originally granted as a result of the roles the user was assigned, a change in the user’s assigned business role should be modeled by adding one or more and removing one or more roles to the user profile within the identity management system. For users whose entitlements were not originally granted using roles, a change in business roles may be an opportunity to apply identity management roles to the user profile. Changes in a user’s business role often have to be modeled using, at least in part, individual entitlements since the user’s new business role may not have an associated identity management role definition. Role changes are often triggered by changes in the user’s location, department and/or manager. Role changes should normally support: 1. An effective date, so that the request can be submitted and approved before the change is actually needed. 2. A transition period, during which old entitlements are retained and new ones are added. 3. An end date, on which old entitlements are finally removed. A role change should trigger recertification of the user’s entitlements. This might happen just once – on the effective date of the role change (review to be performed by the new manager, to confirm that required new entitlements are granted), or twice – at the end of the transition period (second review to be performed by the old manager, to confirm that old entitlements are gone). © 2014 Hitachi ID Systems, Inc.. All rights reserved. 13
    • Standard IAM Business Processes: Corporate / Intranet Deployment 11 Temporary and permanent access deactivation Sometimes the logical access of a user needs to be deactivated temporarily. This happens because of extended personal time off, such as for maternity leave, sabbatical, short or long term disability, etc. In other cases, access is deactivated permanently. For example, an employee may retire, resign or be terminated, or a contractor may be concluded. Permanent deactivation is almost always performed in three steps: 1. Deactivate access, but leave accounts and other data in place. 2. Some time later, archive data such as home directories and mail folders. 3. Even later, permanently delete accounts and associated data. A reasonable best practice is to complete data archival in the first week after an account is disabled and to permanently delete accounts 90 days after they are disabled. Four mechanisms are normally implemented relating to access deactivation: 11.1 HR initiated, scheduled termination The HR data feed may specify scheduled termination dates for employees. When this happens, these dates should be automatically transferred to user profiles in the IAM system. A separate, regularly scheduled batch process should examine user profiles and automatically disable those whose expiration date has elapsed. The same job should permanently delete accounts that were disabled sufficiently long ago – for example, at least 90 days in the past. This allows time for managers, IT staff or others to archive important data – e-mail folders, home directory contents, etc. after an account is deleted. 11.2 HR initiated, immediate termination This process must be interactive, since a scheduled job will introduce a delay of up to a full day between when HR sets a termination date and when the user is actually disabled. To do this, HR staff must have both access to the identity management web portal to initiate deactivation and be trained to use it. HR initiated deactivation should be auto-approved, to ensure timely completion. Other than these two points, the process should be identical to scheduled deactivation. The batch job that processes these events should typically be scheduled to run at the end of each work day (e.g., 5PM). © 2014 Hitachi ID Systems, Inc.. All rights reserved. 14
    • Standard IAM Business Processes: Corporate / Intranet Deployment 11.3 Manager requested, scheduled termination This process will be performed on the identity management request portal, since managers do not generally have the ability to sign into an HR system. Managers should be able to sign in and set termination dates for their direct or indirect reports. Once a termination date has been set, the process is the same as the HR initiated, scheduled termination one above. Normally, the termination date is set from an HR feed but if a manager sets this value: 1. The manager-set value should take precedence. 2. An e-mail should be automatically sent to HR to notify them of the upcoming termination, at least if the user is an employee. 11.4 Interactive, immediate termination Security officers should also be able to sign into the web portal to trigger immediate deactivation, not subject to an approval process. This is identical to the HR initiated immediate termination process. 11.5 Clean-up of terminated user profiles After a user has been terminated, a variety of clean-up steps are required: 1. Delete the user’s objects on filesystems and mail servers some number of days (typically 90) after access was disabled. 2. Reassign resource ownership: (a) On Active Directory, groups normally have owners. (b) Within the identity management system, users may own groups, roles, template accounts, etc. 3. Re-route change requests: (a) If the terminated user was an authorizer on any open requests, or was invited to perform access certification, or was asked to manually implement a change, reassign those tasks to new users. 4. Find a new manager for all direct subordinates: (a) Update the “manager” attribute of all direct reports of the terminated user, on both Active Direc- tory and within the identity management system. In general, the terminated user’s manager will be assigned as a replacement manager, entitlement owner or workflow participant in each case. The manager should be sent an e-mail notifying him of this change, to give him an opportunity to request more appropriate updates. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 15
    • Standard IAM Business Processes: Corporate / Intranet Deployment 12 Returning users / rehire scenarios When onboarding new users, be it from an HR data feed or manager requests, it is important to determine whether the user is truly new, or a rehire. To do this, the new user’s information must be compared against data about all known users, including active users but also those who have been terminated at some point in the past: 1. Match on first name, last name and date of birth. 2. Match on private e-mail address. 3. Match on social security number or equivalent. Wherever a match is found: 1. Check the old profile’s rehire flag. A rehire of this individual may not be allowed, in which case the process should terminate and participants notified. 2. If a rehire is allowed, ask for security intervention, since the old profile should be reactivated, rather than creating a new user profile for the same person. Reactivating an old profile is preferable to creating a new one as it creates continuity in the audit record. The motivation here is the same as the motivation for not reassigning the IDs of terminated staff to new hires. 3. Allow security officers to override the match, indicating that a truly new person is being hired, but with profile data matching a former employee or contractor. 13 Periodic access reviews Users who remain with an organization for a long time tend to change jobs periodically. Whenever this hap- pens, users request and are granted new access rights – login accounts on applications and membership in security groups. Users never request access deactivation, so they tend to accumulate security entitle- ments over time. This can become a serious internal control problem as users acquire toxic or dangerous combinations of security rights. One way to address this is to leverage role-based access control. This way, a role change triggers both the addition of new and removal of old security entitlements. As mentioned in Section 5 on Page 8, full-scale and fine-grained RBAC can be cost prohibitive, so additional mechanisms are often required. Another approach used by many organizations and recommended by Hitachi ID Systems is to periodically invite managers and group owners to review security entitlements assigned to users and differentiate be- tween (a) those that remain appropriate and (b) those that should be removed. This process is called access certification. When implementing access certification: 1. Invite managers to review: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 16
    • Standard IAM Business Processes: Corporate / Intranet Deployment (a) The employment status of their subordinates, to catch cases where a termination in the real world did not, for whatever reason, trigger deactivation of the user’s profile. (b) The roles assigned to their subordinates. (c) The assignment of widely used security entitlements to subordinates. For example, it makes no sense for someone in IT to certify that a user should have a login ID on Active Directory – that’s more the manager’s function. 2. Invite application, group or data owners to review lists of users with access to their application, group or data, so long as the list is not too long (say under 100 users) and so long as they can be reasonably expected to personally know the users. 3. Whenever a user changes department, location or manager, this transition should trigger recertifica- tion of all of the user’s entitlements by the user’s new manager of record. 4. Extract entitlement data directly from target systems – do not infer that it has not changed since the last certification process. 5. Perform certifications regularly – every 6 or 12 months. 6. Automatically submit workflow requests to deprovision access whenever a certifier flags something for deletion. 7. Wherever a manager flags an item for removal, invite the application owner to approve the change. 8. Wherever an application owner flags an item for removal, invite the user’s manager to approve the change. 14 Self-service password management In most organizations, users sign into systems and applications with an ID and password. When users mis-enter their password, they can trigger an intruder lockout, which prevents them from signing in for a period of time. Users may forget their password, which also blocks their ability to sign on. A self-service password reset system should be deployed to help users more effectively manage their passwords and resolve login problems without having to contact the IT help desk. It should: 1. Invite users to fill in data that can be used to authenticate them in the event that they forget their password or trigger a lockout. This typically includes: (a) Answers to standard security questions. (b) Their own, personally created security question/answer pairs. (c) If possible, their mobile phone number. 2. Send automatic reminders to users to enroll this profile data. 3. Provide a web page where users can sign in with either their password or another trusted mechanism and subsequently change their password. 4. Enforce a password policy forbidding the use of easily guessed passwords: (a) Minimum length – e.g., 7 characters. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 17
    • Standard IAM Business Processes: Corporate / Intranet Deployment (b) Must include mixed case and digits. (c) Not based on the user ID, name or a dictionary word. (d) Not the same as any previously used password. 5. Remind users to change their passwords periodically – for example, via an e-mail sent every 90 days. 6. Support authentication of users who have a password problem using a combination of standard se- curity questions, user-defined security questions and a random PIN sent to the user’s mobile phone. 7. Provide a mechanism for users to access the password reset web page even if they are locked out of their Windows login prompt, including when the user is away from the office – i.e., over WiFi and a VPN if necessary. Where full disk encryption software is used, a mechanism should be provided, typically via a telephone user interface, for users to re-activate their PC after forgetting the disk encryption password. Where one time password (OTP) tokens or smart cards are used, a mechanism should be provided for users to reset a forgotten PIN, get an emergency access password or resynchronize their token clock. Where users have passwords on multiple systems or applications, their passwords should be synchronized, so that users have an easier time remembering them and are less incented to write them down. Fewer, stronger passwords are preferable to distinct but less secure passwords. 15 Reports and alerts Once an identity management system is in production, it should be monitored to ensure health and to verify that the workload it processes is in line with the volume of changes currently experienced by the organization. This requirement can best be met by scheduling a set of reports to run automatically and deliver their output to the system’s owner. Reports to schedule include: 1. Number of users, accounts, groups and group memberships, total. 2. Number of HR initiated adds and deletes detected, monthly. 3. Number of manager initiated adds and deletes, monthly. 4. Total number of requests submitted, approved and rejected, monthly. 5. Total number of password resets, monthly. 6. Groups or other resources that have no known owner. This should be used to drive an ongoing clean-up to assign appropriate owners to every object. An identity management system should send alerts – typically e-mails – to interested parties as a result of a variety of actionable or questionable events: 1. All terminations, since someone might have to archive files, mail folders, etc. 2. Unauthorized changes detected to membership in sensitive security groups, such as Administrators on AD. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 18
    • Standard IAM Business Processes: Corporate / Intranet Deployment 3. Too many changes detected at any one time in the HR feed (e.g., 1,000 new hires or 1,000 termina- tions on the same day). www.Hitachi-ID.com 500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com File: /pub/wp/documents/iam-saas/corporate/business-processes-1.tex Date: 2011-07-26