Role Based Access Control: How-to Tips and Lessons Learned from IT Peers

Role Based Access Control: How-to Tips and Lessons Learned from IT Peers Wisegate community members discuss key considerations and practical tips for managing a successful RBAC program WISEGATE COMMUNITY VIEWPOINTS

Introduction One of the toughest challenges in managing large networks is the complexity of security administration. According to the National Institute of Standards and Technology (NIST), role based access control (RBAC) has become the predominant model for advanced access control for large enterprises. In addition to the security benefits of RBAC, when done right, RBAC can deliver cost savings from reduced employee downtime, more efficient provisioning, and more efficient access control policy administration. In this report, you ll get the practical RBAC advice that Wisegate members usually only share privately with each other as participants of the invitation-only Wisegate Identity and Access Management micro-community. These tips provide key insights into how senior CISOs and security management professionals from Fortune 1000 companies are tackling the complexity of network security administration. This report provides a snapshot view of the valuable information shared between CISOs and senior security management professionals online at wisegateit.com and during invitation-only community events. If you are a senior IT professional and IT security topics are important to you and your organization, we hope you ll join the conversation with these leading information security experts on Wisegate. To learn more about Wisegate or to submit your request for membership visit wisegateit.com/request-invite/. RBAC Key Considerations In RBAC there are several key points to consider in the context of your own organization:» Build in RBAC when your identity and access management (IAM) program is mature. Implementing RBAC too early is what leads to a high failure rate of RBAC projects. Knowing and understanding how you administer access today is a key first step in the process.» If you are doing attestation of privileges and onboarding applications to a framework, use the opportunity to make sure you understand what the access does. Tie it to a good business description of the entitlement. This will be helpful later when you want to build roles for your users.» Utilize role mining before you try to do role management. Invest and spend some time in the role mining space to understand what you are currently doing today. This will give you something to build on. Role Based Access Control: Tips and Lessons Learned 2

» Roles can be used for many purposes beyond provisioning. Business roles tied to basic privileges are what a lot of companies are after with RBAC. Roles also have huge value in the attestation of privileges.» Keep it simple when you first get started. Most project failures stem from companies trying to do too much at once. Definitions Just to be sure we are on common ground with this complex topic, here are some frequently used terms and definitions for the context of this report. Business role a function of an individual s job (for example, an equity trader or a sales manager). IT role an entitlement; what a person holds in terms of access to business systems. With regards to IT job functions (for example, a UNIX systems administrator), they are really business roles in the business of IT. RBAC the marriage between the business role and one or more IT roles. RBAC is related to provisioning linking a person s business life to the privileges he or she has. In true RBAC, provisioning roles are often linked to automation of privileges based on an identity event (for example, a new hire event for an equities trader will provision 5 trading applications, a Blackberry device, and a market data terminal). Role mining the process (more of an art, really) of discovering the set of entitlements that groups of people have in common specifically related to their job function. There are tools to automate this process. Role management system (RMS) a solution that enables the creation and lifecycle management of enterprise job roles. It can be something integrated into an identity access management solution, an in-house build, a commercial off-the-shelf product, a standalone or other hybrid application. A well-thought-out RMS includes a number of functions enabling the enterprise to build, consume and maintain roles (a single centralized solution incorporating workflow, attestation of role functions, and memberships tied to identity events so roles stay current). Wisegate Community Viewpoints 3

Polyarchies the collection of roles an individual holds across different hierarchies or relationships (for example, Tom holds an approval role for his cost center and everyone in it, Tom is also the compensation manager for Lisa, Tess and John, and Tom is the direct manager of Tess and John). Rules, Roles, or both roles can (optionally) carry a set of rules with them. In a more mature RBAC program, rules are sometimes applied at the time of role assignment, often protecting against separation of duty violations or excess privileges (for example, you cannot be a cost center approver if you don t work in that cost center. You cannot request a Research Analyst role if you are an Equities Trader as it would be an information barrier violation). Role Inheritance and RBAC Principles Figure 1 below depicts a mature role management program. Figure 1: Role Inheritance and RBAC Principles Research Analyst Role Business Applications + Physical Assets App 1 Laptop Employee Role App 2 Credit Card Windows NT Desktop Phone Core Infrastructure Accounts + Basic Privileges Role Based Access Control: Tips and Lessons Learned 4

In the example presented in Figure 1, the Employee role has some core infrastructure accounts like Windows, as well as some physical assets including a desktop computer and phone. If the Employee role is the first role you develop as part of your RBAC program, you might try to simplify it by only putting a Windows accounts in it, but over time you will add assets. In this example the Employee role has three basic assets (Windows account, desktop and phone). Once basic roles are established, you may want to add Business roles. For instance, within the research business unit you may add a Research Analyst role. Since there is already a role called Employee, you can reuse that role for every employee who is a Research Analyst. The arrow pointing up from the Employee role to the Research Analyst depicts a parent/child relationship therefore the Research Analyst inherits the three assets of the Employee role. There can be many roles in that grouping, but Figure 1 provides a simplistic view on how role inheritance works with RBAC. You may have other assets that you tie to roles that many people share. The point is that you can reuse the assets and you can identify common relationships. If you look at the Research Analyst role itself, the business applications that are related to that position would be attached to that role. Optionally, you can include additional physical assets, like a laptop and corporate credit card. Within the applications themselves, the provisioning of those applications would require information such that if it is going through your identity management system or whatever you are using today to provision privileges at the IT level that information would be contained within that role. When the identity management system picks this up, it basically says, I see Joe coming into the research department. I ve picked up his cost center, his attributes related to where he works, and what business unit he is in. Now you can fire off, dynamically, a provisioning event that assigns him into this role. Followed by all the activity that actually gets Joe the access that he needs. This is a simplified view; you can add complicated approval flows as necessary, but this provides an overview of the kind of assets and privileges that you can attach to roles. Example of Business Role Models and Polyarchy Figure 2 on the next page provides an example of business role models and demonstrates the concept of polyarchy, which is the collection of roles an individual holds across different hierarchies or relationships. Wisegate Community Viewpoints 5

Figure 2: Business Role Models and the Concept of Polyarchy Organization-Based NA Desk Head Polyarchy People-to-People Direct Manager Cost Center 1234 NA Trading Bill Sox Approver Trading BU People-to-People People-to-people roles are direct relationships. In Figure 2, Bill is identified as the Direct Manager of the cost center North American Trading (represented by the blue box in the lower left portion of the diagram), and he has three individuals working for him Moe, Larry and Curly. Bill is also a SOX Approver for his trading business unit (represented by the blue box in the lower right section of the diagram). That is a very explicit people-to-people role, because in a SOX program, often the Certifiers and the SOX Approvers are spread throughout the company and they may or may not have any relationship to your organization, and what you do on a day-to-day basis. As shown in the top half of the diagram, Bill has a third role North American Desk Head. This is different than his role as Direct Manager and SOX Approver because it is an organization-based role. Based on levels of your hierarchy whether you are using HR cost centers or other types of directory structures where roles are assigned at an organizational level this depicts that relationship as well. Role Based Access Control: Tips and Lessons Learned 6

If Bill transfers or leaves the company, you need the role management system to recognize that identity event. Once you know Bill is leaving, you need to source a new Direct Manager and a new SOX Approver, and you need to assign a new North American Desk Head role. When you are tying roles to provisioning and you have a comprehensive program around this approval workflow, issues will arise when people aren t assigned to the roles that approve assets or sign off on something. Examples of Business Role Models Here are a few examples of business role models:» Organization-based roles are generally used to assign roles to a particular node in a hierarchy structure (for example, HR cost center + region) and often relate to specific approval functions or highly-elevated privilege sets.» People-to-people based roles indicate a direct relationship between two or more individuals (for example, a Direct Manager role to a subordinate, or a SOX Approver to a SOX Certifier).» Approval-based roles generally either use a combination of organization and threshold (for example, the people who have authority to approve expenses over $100K in cost center 1234), or are specifically tied to an asset being requested (for example, the person who can approve Susan s request for a tablet computer).» Other role models may be needed if you have very distinct approvers for certain assets or privileges. Within your provisioning program you may have a very mature role management system that ties business roles to those IT roles, and gets people those privileges. But in the workflow to get those privileges, you may need to have certain approvers sign off on them. This again would go back to the role management system and source these approval roles so that that workflow can happen cleanly. Top RBAC Questions and Answers Regardless of where you are at with RBAC program, you probably have questions that your peers, those with similar titles and working within relevant industries, would be able to insightfully answer based on their experiences. In this section, we share Wisegate members valuable perspectives on the top RBAC questions and answers based on their own in-the-trenches experiences and lessons learned. Wisegate Community Viewpoints 7

When should we introduce RBAC into our access management program? Build in RBAC when your identity and access management (IAM) program is mature. Implementing RBAC too early leads to a high failure rate (over 70%) of RBAC projects. Start first with very basic provisioning of core assets, and make sure you understand your entitlement structures and your applications. If you are doing IAM and rolling out a commercial product from Oracle or CA or another vendor, make sure that you understand what you are trying to solve. If you are trying to get automation around basic privileges, do that first before you start doing roles. You may have a very aggressive attestation program that you are trying to meet because of either deficiencies in audit findings or fed reviews. Most likely there will be other things to take care of before you tackle roles. How do we get started? Thousands of roles exist with all of these privileges and you probably have no idea what most of them do. Where to start? First spend some time looking at what people hold. Use a role mining tool or simply take dumps of privileges, and work with your application teams that own those privileges to understand what those roles are giving people. Then you can start to reengineer them from the ground up. This is not an easy task. It can take months or even years to do. Another option is to start cleanly. You can start building from scratch, not necessarily worrying about what is there, and think about how you can start fresh. Work with your applications, one by one, until you understand their entitlements model and then attach them to roles. Then start to provision new people as they come into the organization using that model. What is the simplest way to start with RBAC? One option is to start with Employee and Consultant roles and then build on top of that the business roles and the marriage of the two types of roles. Over time you can add more applications, more assets, and more roles. Start small with one business unit or very basic privileges, depending on your organization, and grow it from there. Can contents of a role be reused in other roles? Can a role own other roles? The short answer is yes. The example relationship between the Research Analyst and the Employee contained in Figure 1 depicts this parent/child relationship. You might also have slight nuances of regional based roles. For example, you can create an Employee role and attach rules to it based on the region of the employee. This provides some slight variances on the provisioning flow to grant different types of desktops to someone who is in EMEA, versus someone who is in New York. You can get a lot of use out using roles and rules together. Reuse is great, and parent/child relationships are something that you want to define. Role Based Access Control: Tips and Lessons Learned 8

What comes first, role mining or role management? Mining comes before management. Invest and spend some time in the role mining space. Understand what you are doing there, what you are currently doing today. Find what is broken about the roles and then start thinking about role management. Should the creation of roles and their associated management be centralized or decentralized? Who owns the roles you create? This just depends on the organization. In some cases there is a centralized group of people, whether they sit in the security team or risk management within your identity and access management team it might be the model that works best for you. And all the businesses and application teams are going to need to work with you to support and implement role management in that centralized function. In other cases, particularly in larger organizations, the process can be decentralized, where business roles are owned by the business. Every organization is different, so you really need to think about what works for you and go from there. How often should we validate the contents of roles and what it enables? Perform this validation at least once a year if not more frequently. It is just like when you certify privileges for the higher risk SOX programs, SAS-70 or PCI applications or other types of attestation functions. You are doing it twice a year, quarterly or once a year. Go out and look at your roles, whether they are in a role management system or if they are done off to the side. Understand the privileges they grant and the rules that are associated with them and sign off on them. In that centralized model, that is going to fall within the ownership of the role management team. In a decentralized model, it is going to fall on the business groups that own those roles. We want to build a Direct Manager tree as our organization does not have a source of who works for whom, and we want to use this approval structure for many asset requests. It seems simple, but how do we manage all the changes of personnel? If you have a direct manager tree within your organization and it is maintained and kept current, you are very lucky. Many, many organizations do not have one. The value of having this type of a tree is huge. You can use it for many different things, including provisioning of assets and attestation of privileges. Keeping it current is the challenge. It s great to have a direct manager tree tied to identity events, such as when people come into the organization they get placed in that tree, and when they transfer or leave the organization they get removed from that tree. It is a very simple concept, but it is very difficult to implement. It s a real challenge to get the right people to own it and support it, making sure that the workflows are right and the resolution of exceptions is handled in a timely manner. Wisegate Community Viewpoints 9

Are roles just for provisioning? You can use roles for many different things in addition to provisioning. Business roles tied to basic privileges is what a lot of people are after with RBAC. In a comprehensive role management system you will have other types of roles like approval roles, you may have a direct manager tree, you may have a compensation manager, you may have sign-off authorities tied to organizations, and many others. Another place of huge value is in the attestation of privileges. When you are onboarding applications for your attestation framework, you spend a lot of time working with the application groups, understanding what the application entitlements do. Something that is called ABC4J makes no sense to a business person who is trying to sign off on the privilege. So you spend a lot of time not only working with the app team, but also working with the business team to label the entitlement so that in an attestation that he or she knows what they are signing off on. Once you clean up the application, you will understand what the privileges grant, and you understand what they mean. Verify that the business person cannot just hold a hand over his eyes and hit enter to say, yes, I certify it without really knowing what was being certified. Now you can start to think about grouping that into roles, or reusing your role management system that might be tied to provisioning to do role based attestations. Instead of hundreds of entitlements coming from an application, you might only get a few that are coming at a role level. For example, if Tom holds 10 different applications and privileges within all 10 of them, why should the manager have to sign off on each of those 10 apps, and each one of those privileges? If you can tie that to a role, it is a huge value for the business. So that is another place where the business people will be asking for roles. How many roles should we deploy? There really is no short answer to this question; however, follow the rule less is more. Consider that over 70% of organizations that try to do RBAC fail, and often the cause of failure is that they create too many roles. Instead of trying to boil the ocean, keep it simple and go after a common set of entitlements that a group of people hold. If there are 100 people in the organization, you don t need 100 roles. You have to start small and you will know, if you build it from the ground up, what feels right and works right. In a decentralized model, where the businesses own the maintenance of these roles and own the reattestation of these roles, they will also feel the pain. Do as much as you can to find what works for the business and for the people that need to certify and maintain the roles. If you are in a 40,000 member organization, you may know that 10,000 roles are not right. Are 1,000 roles right? Are a few, 100 right? It is more towards the latter; you probably want to start small to be successful. And go slowly. Role Based Access Control: Tips and Lessons Learned 10

Functional Considerations for a Role Management System Whether you are looking to build or buy a role management system, here are some highlevel functional requirements according to Wisegate members. User Interface (UI) with Sphere of Control (SOC)» UI enables administrators to view and maintain role memberships, and perform general role administration (views by org, explorer based)» Functionality such as what if change events, delegation abilities, and a fully integrated workflow to your IAM system are key components to consider Role Distribution / Consumption» The ability to integrate with consumers (typically application teams) via standard API s / Web Services for the consumption of roles, as well as act as a distribution hub for other authoritative sources of roles Role Resolution Services» Consider context based, user specific, organization specific, and custom attributes when building or implementing a role resolution service. Answer sets may require rules to be fired, and resolution can be based on a scoring technique to consider the best fit when traversing many possible members of the set Auditing / Temporality» Fully temporal data model (past, present, future) control length of role memberships or administrative privileges based on from/to dates. Setup roles in advance, research role memberships in past» Fully auditable controls for all event changes (identity, UI) every change event, action, or transaction event is logged and fully auditable» Consumer transactions logged and auditable every request by a consumer app is tracked and recorded Reporting» Export capabilities and event based reporting triggered by identity or change events along with management dashboards Wisegate Community Viewpoints 11

Maintenance and Administration Models» Self-managed for a decentralized approach utilizing business / organization teams, or centrally managed Rule-based Role Membership» Functional needs may include static granting of memberships, real-time evaluation to criteria limit role memberships based on attributes of an individual s characteristics (white page info, job codes, accounts managed, region, etc.). Dynamic granting of memberships, background processing automatic granting (and removal) of roles based on rules and the ability to link rules with roles (for example, tie a specific rule to a specific role for automated provisioning events) Role Mining and Discovery» Discover and associate new roles utilizing existing stores, such as Active Directory, and the ability to perform mining using graphical tools and show like sets as well as exceptions to the population threshold selected (for example, show me all members of a group who share 85% or more of the same entitlements) Additional Resources NIST Computer Security Division This online resource provides RBAC references and background information, FAQs, and case studies, as well as role engineering and RBAC standards information. Visit http://csrc.nist.gov/groups/sns/rbac/ for more information. LinkedIn Role Based Access Control Executive Forum Group members comment and provide general knowledge related to any role-based initiatives currently underway ("build" and vendor-based). Visit http://www.linkedin.com/groups?gid=82229 for more information. Wisegate Identity and Access Management Micro-Community Seasoned CISOs and senior identity professionals swap war stories, share lessons learned, and provide in depth perspectives on what it takes to run successful RBAC projects, as well as share useful information on other identity related topics. Access to this resource requires membership approval. Visit http://wisegateit.com/request-invite/ to learn more and find out if you qualify. Role Based Access Control: Tips and Lessons Learned 12

In Closing We could go on and on with sharing member tips and best practices. In fact, we do online at www.wisegateit.com. Wisegate is the invitation-only community where senior IT professionals meet to openly exchange knowledge and solve problems with their peers. It is Wisegate s ambitious mission to make our members job less stressful and more productive by providing the forum professionals need to collaborate and share experiences with a closed community of highly qualified IT peers. By enforcing strict membership guidelines, which exclude vendors from joining, Wisegate is able to provide members with unmatched access to senior-level IT professionals and quality content. Would you like to join us? Go to wisegateit.com/request-invite/ to learn more and to submit your request for membership. 300 Beardsley Lane, Suite C201 Austin, Texas 78746 PHONE 512.763.0555 EMAIL info@wisegateit.com www.wisegateit.com 2012 Wisegate. All rights reserved. Wisegate Community Viewpoints 13