Tip

Best practices: How to implement and maintain enterprise user roles

Andras Cser, Forrester Research

    Requires Free Membership to View

For more information
Have more questions about enterprise authentication? Check out this lesson.

Learn about good features to look for in access control software.
Enterprise role management is key in efficiently managing user access rights and enforcing access policies such as segregation of duties. Roles help companies group coarse- and fine-grained access rights (like access to and functionality within a financial accounts application) into groups, called enterprise roles. These enterprise roles map to job functions and are only allowed access rights that don't violate segregation of duties. For instance, a financial clerk role can't contain fine-grained access rights that allow someone in the role to access the accounts receivable and accounts payable parts of the financial application.

Forrester Conference Discount!

Get a $405 discount off the standard rate for Forrester's Security Forum 2009. SearchSecurity readers only. Conditions apply.
The processes and tools necessary for effective role management consist of role mining and design (automatic discovery and management of roles based on existing access rights and entitlements data), role recertification (a process performed typically every six months when a business role custodian certifies what access rights should belong to a role), and access recertification (a process performed typically every 3-6 months to ensure all user access is understood and was granted in an audited way).

To be successful, organizations should implement and maintain enterprise roles by:

  1. Establishing a closed-loop process -- If the organization wants to gain value from enterprise roles, it needs to use a closed-loop process to ensure roles are periodically updated based on current business requirements. (This is especially important after reorganizations; there may have been changes to a business process after a reorganization, and roles need to reflect those changes.) Forrester Research Inc. learned that enterprises iterate at least twice through a role-design cycle before they can build a solid foundation for role-based access control (RBAC). This cycle consists of seven phases:
    • Develop or update an RBAC vision -- Based on Forrester's initial discovery conversations, successful organizations define, refine and communicate widely why they are implementing RBAC and what their long-term RBAC plans are.
    • Gather requirements -- Interview executives and business leaders to understand their expectations and explain how it's to their benefit to support the process.
    • Onboard applications and organizations -- Organizations need to approach the owners and business users of the applications and conduct detailed interviews on how access is stored, granted and revoked, as well as what application-level roles exist.
    • Mine roles -- Mining roles (the automatic discovery of roles based on existing access rights and entitlements data) is the bottom-up discovery process of looking at what application access and entitlements within those applications an organization's employees have. The results are used to make recommendations for role adjustments. Role mining usually takes about two weeks per application.
    • Adjust roles -- Once the mining process has determined role suggestions, these roles need to be adjusted. This adjustment is essentially comparing the as-is situation for access with what the newly defined roles would yield.
    • Certify roles -- Once roles are adjusted and measures are taken to ensure excessive permissions aren't granted, the roles need to be certified by a role custodian. This is usually a member of the relevant business unit and not IT security. The role custodian has ongoing responsibility for ensuring the roles remain up to date and reflect realistic groupings of access rights and entitlements that map to business processes.
    • Certify access -- After the role structure goes live, the role management or user account-provisioning system sends email notifications to managers or application owners to request approval of their employees' and users' access rights and entitlements and the assignment of employees to roles.
  2. Pitfalls to avoid during enterprise role design -- Enterprise role design doesn't emerge based solely on results of role mining. There are existing repositories of information in the organization that RBAC should examine, reuse and extend:
    • Waiting for HR repository data quality to improve -- Some organizations will have to accept that data quality and quantity in their HR databases is insufficient to create roles. Many times HR records lack or do not carefully record enough critical user attributes, such as geographic location, job code, department code, reporting structure, floor location, etc. Sometimes RBAC can't be built on them because there is no unified HR database, or because HR databases are updated long after an actual event (especially transfer) takes place.
    • Automatically equating an application role with an enterprise role -- Those application roles that describe fine-grained sub-application level entitlements cannot be automatically rolled into a job role. Many applications roles are too granular or defined too cryptically to be equated directly with an enterprise role. A complicated Active Directory group name or an SAP collection of entitlements does not map to the financial clerk role.
    • Don't miss need-to-know info!

      Security pros can't afford to be the last to know. Sign up for email updates from SearchSecurity.com and you'll never be behind the curve!
      Using technology-heavy terms in role descriptions -- One message has been made resoundingly clear in our interviews: The purpose of an enterprise role system is to expose IT access management to business people in business-friendly terms (creating "telling" descriptions in tools that clearly describe the job functions of the employees that the roles are granted to).
    • Listening only to "onboarding" clerks and managers. Interviews with employees and managers who participate in requesting and revoking access rights for newly hired and terminated employees provided a wealth of information about how application access is granted.
  3. Target simple areas that yield high return -- Almost all of the organizations that Forrester interviewed in regard to role management (including banks, healthcare providers, transportation companies, energy and utility companies, colleges, etc.) followed a combination of these best practices when they identified the initial area for implementing enterprise RBAC:
    • Areas with high employee turnover -- These job responsibility areas require a lot of traditional IT administration effort and pose higher security risk. Ensuring that employees in these areas are provisioned quickly, but only given minimal access, and then de-provisioned just as promptly when appropriate, will resonate well with senior management.
    • Areas with relatively simple and standardized functions -- The fewer differences there are in people's access in that environment, the easier RBAC definition and implementation will be. In these organizations, you can expect to have hundreds or thousands of people in the same role.
    • Newly acquired organizations -- Sometimes it's easier to lead an IT integration and clean-up activity when focusing on a newly acquired company. Implementing enterprise roles in a pilot project at a newly acquired organization is an easier sell with senior management than impacting a legacy organization at the acquiring company.

Defining enterprise roles, even with automated mining, is not easy. To ease the burden, follow these best practices, and remember to work one-on-one with your business representatives, gain their support, and implement a carefully phased role implementation process.

About the author:
Andras Cser is a principal analyst at Forrester Research, where he serves security & risk professionals. He is a leading expert on identity and management. He is a featured speaker at Forrester's IT Forum, May 19-22 in Las Vegas.


This was first published in May 2009

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.