Many corporate IT security professionals still regard roles-based access and identity management as hopelessly complex. This is because the predominantly manual approach many organizations have taken to review and manage roles is typically not scalable, and the dynamic nature of roles themselves—including constant changes in people, functional responsibilities, departments, and information assets—can quickly cause role definitions to get out of sync with the everyday realities of the business. The challenge of discovering established roles, defining new roles according to business need, connecting roles properly to the IT infrastructure, ensuring that they meet all compliance requirements, and managing roles through their natural lifecycles has, until now, proved to be too complicated and cumbersome to be practical. As a result, many have written off the roles concept as a failure. But roles are essential for sound governance, and the right roles-based access governance systems can actually simplify an IT security manager's job.
There are three key objectives to keep in mind for determining the success of any roles-based access and identity management initiative:
The best way to accomplish these objectives and establish the best role set for your organization is to follow these steps:
1. Engage key stakeholders. The first step in developing roles should be to engage the key business stakeholders who are involved with governing user access. Their input is essential to create a framework that drives what business abstractions will form the basis for representing access to information resources as well as for role discovery and modeling. These abstractions are tied to either business context, such as job context, process context and compliance context or technical context scoped to a subset of the IT infrastructure. Collaboration on a role framework and role design between IT security teams and the business will ensure the best chance of success when roles are put into production.
2. Determine the existing access entitlements of all users. For this purpose, it is critical to have in place an automated access governance system that can collect from or process data from every possible repository of user entitlements among your information resources, normalize and aggregate the data, and then put it into a user-friendly business context.
3. Effective role design: combining business and technical roles. An effective approach for modeling roles requires the creation of business roles (job roles, process or procedural roles) that are then layered over technical roles (e.g. application roles, system roles, network roles, etc.). This hybrid approach enables top-down business roles to be linked to granular entitlements within various information resources, which creates a common language for access that can be clearly understood by all stakeholders in the access governance process (IT security, business, compliance and audit teams).
As you begin the process, bear in mind that having fewer roles usually yields greater efficiency.
Also, eliminating out-of-role entitlements altogether is not necessary; it is usually easier to manage a limited number of exceptions than to manage the number of roles required to do away with them. The goal should not be to eliminate out-of-role entitlements, but to use them judiciously as a means of consolidating and minimizing the number of roles.
Don't worry about trying to get it right the first time. Assemble your first roles model based on the stakeholders' input and move on to testing it by reconciling the roles to the reality of access that the users in that role actually have. The idea is to learn as you go, not to achieve perfection immediately. The sooner you start modeling and testing, the sooner you'll get where you want to go.
4. Examine the results. An automated role modeling system is essential for this. When you are able to see the pattern into which your users are arranged by your set of role definitions, you can start the process of reviewing each role with these considerations in mind:
There is no equation that will calculate what's right for your enterprise.
Judging which role-set is best requires the right metrics combined with common sense input from the business and IT managers who will be using the system.
5. Repeat as necessary with revised role definitions. Role modeling is an iterative process. Even if the results of your initial models are not ideal, you will be learning with each round what works and what does not. Although there may be some disagreements between various stakeholder groups over what constitutes the best set of role definitions, these can usually be worked out quickly and easily. But you should have a process for engineering roles whereby they can be fine tuned by combining or adjusting them based on different factors such as; the number of members within a given role, the number of entitlements that are out-of-role, the inherent risk level of the role and simplification of administrative complexity of roles.
6. Establish ownership. By transforming a technical view of access into a business view through the language of business roles, responsibility and accountability for maintaining as well as certifying roles can now be moved out of the IT security organization and driven into the business. Having business units maintain their own business roles is appropriate since business managers within each business area best understand what access is required for a particular job function or business process and how changes within the business area should be reflected in changes to the role model or role structure.
7. Continuously manage roles over their lifecycle. It is essential to understand that role management is not a project with a beginning and an end, but a continuing process. There will be frequent changes in the organization, the technology it employs, and the general business climate in which it operates, and the language of roles and the role definitions themselves must change along with these variables to ensure that roles reflect the current reality at any given time.
Roles can follow a variety of lifecycle paths: some live longer than others, most change over time in ways that require regular updates, and new roles will be needed over time as well. Your enterprise should review its role-set on a regular basis and update it as needed.
A metrics-driven approach can prove to be very useful in role lifecycle management. Using key performance metrics to track the effectiveness of a role provides the understanding of where change is occurring and alerts role owners and IT to determine if a role needs to modified, combined with another role or retired. Measuring role quality provides the decision support that keeps roles working effectively.
8. Keep it simple. Real-world attempts to implement roles-based systems have shown that unless roles fit into a context that ties together existing entitlements, company policies, regulatory requirements, and current business process realities, they simply don't work. Without this context, the result is a system that can't keep pace with changing business-user requirements, and that can leave the organization open to unacceptably high levels of risk.
By keeping your roles initiative within the scope of the steps outlined above, you will maximize your chances of developing a role-set that lowers your organization's user access-related risk level, gains wide acceptance throughout the enterprise, and reduces the burden on the IT security organization.
Deepak Taneja is the founder, president and CTO of Aveksa Inc. (www.aveksa.com), the market-leading provider of enterprise access governance solutions. Previously, he was CTO and VP of engineering at Netegrity, where he was instrumental in establishing the company as a market leader in Identity and Access Management prior to its acquisition by CA.
There are three key objectives to keep in mind for determining the success of any roles-based access and identity management initiative:
- The people who manage roles should understand them. Role definitions should describe, in business terms readily intelligible to any business unit, IT security, or audit/compliance manager within your organization, what a person assigned to that role does.
- Roles should simplify users' view of access. Every business manager, IT security team member, and audit/compliance professional that uses the roles-based access governance system should be able to see easily who has access to what and understand whether that access is appropriate (entitlements fit the role or are out-of-role or create a compliance violation).
- Roles should make the management of access more effective. Roles should speed up access delivery as on-boarding a user or making a change to user access is now expressed by what role(s) a person has, which simplifies administration. Additionally, leveraging roles makes compliance easier because clear visibility exists for what is appropriate and inappropriate access. When entitlements are added to a role, or roles are combined, decision support is provided to proactively identify potential compliance violations or risks.
The best way to accomplish these objectives and establish the best role set for your organization is to follow these steps:
1. Engage key stakeholders. The first step in developing roles should be to engage the key business stakeholders who are involved with governing user access. Their input is essential to create a framework that drives what business abstractions will form the basis for representing access to information resources as well as for role discovery and modeling. These abstractions are tied to either business context, such as job context, process context and compliance context or technical context scoped to a subset of the IT infrastructure. Collaboration on a role framework and role design between IT security teams and the business will ensure the best chance of success when roles are put into production.
2. Determine the existing access entitlements of all users. For this purpose, it is critical to have in place an automated access governance system that can collect from or process data from every possible repository of user entitlements among your information resources, normalize and aggregate the data, and then put it into a user-friendly business context.
3. Effective role design: combining business and technical roles. An effective approach for modeling roles requires the creation of business roles (job roles, process or procedural roles) that are then layered over technical roles (e.g. application roles, system roles, network roles, etc.). This hybrid approach enables top-down business roles to be linked to granular entitlements within various information resources, which creates a common language for access that can be clearly understood by all stakeholders in the access governance process (IT security, business, compliance and audit teams).
As you begin the process, bear in mind that having fewer roles usually yields greater efficiency.
Also, eliminating out-of-role entitlements altogether is not necessary; it is usually easier to manage a limited number of exceptions than to manage the number of roles required to do away with them. The goal should not be to eliminate out-of-role entitlements, but to use them judiciously as a means of consolidating and minimizing the number of roles.
Don't worry about trying to get it right the first time. Assemble your first roles model based on the stakeholders' input and move on to testing it by reconciling the roles to the reality of access that the users in that role actually have. The idea is to learn as you go, not to achieve perfection immediately. The sooner you start modeling and testing, the sooner you'll get where you want to go.
4. Examine the results. An automated role modeling system is essential for this. When you are able to see the pattern into which your users are arranged by your set of role definitions, you can start the process of reviewing each role with these considerations in mind:
- How well does the role simplify the view of access? Consider how many users are assigned to the role. Any roles with zero users should be eliminated, of course, and those that contain only a handful of users should be candidates for elimination, with their unique access entitlements handled as out-of-role entitlements.
- How accurate is the role? It should have a low number of missing entitlements. Look for users whose role assignment, according to your definition, doesn't seem to be a good fit with their job functions, or who don't use the access given to them by the role. Within a bank, for example, a loan officer who shows up among the users assigned to “Teller” is clearly in the wrong role. This could either be the result of an overly broad role definition or of inappropriate access entitlements; a quick investigation will tell you which.
- Is the role unique? If there are other roles with similar user sets or that describe similar access, you may want to collapse them into a single role definition. Could the role be expanded? Look for users who could be added to the role, and consider whether there is new common access that should be added when numerous members of the same role have new entitlements showing up that weren't originally included in the role.
- How many out-of-role entitlements does your model yield? While trying to eliminate them altogether usually leads to excessive role proliferation, too many out-of-role entitlements create unnecessary work. Look for a healthy balance. You may also want to consider the use of “sub-roles”– role variations by geographic location or functional area – when trying to minimize both the number of roles and out-of-role entitlements your system will include. Like roles, sub-roles can be programmed into the access request infrastructure so, for example, bank managers in Cincinnati and San Francisco may see “Teller” with slight regional differences.
There is no equation that will calculate what's right for your enterprise.
Judging which role-set is best requires the right metrics combined with common sense input from the business and IT managers who will be using the system.
5. Repeat as necessary with revised role definitions. Role modeling is an iterative process. Even if the results of your initial models are not ideal, you will be learning with each round what works and what does not. Although there may be some disagreements between various stakeholder groups over what constitutes the best set of role definitions, these can usually be worked out quickly and easily. But you should have a process for engineering roles whereby they can be fine tuned by combining or adjusting them based on different factors such as; the number of members within a given role, the number of entitlements that are out-of-role, the inherent risk level of the role and simplification of administrative complexity of roles.
6. Establish ownership. By transforming a technical view of access into a business view through the language of business roles, responsibility and accountability for maintaining as well as certifying roles can now be moved out of the IT security organization and driven into the business. Having business units maintain their own business roles is appropriate since business managers within each business area best understand what access is required for a particular job function or business process and how changes within the business area should be reflected in changes to the role model or role structure.
7. Continuously manage roles over their lifecycle. It is essential to understand that role management is not a project with a beginning and an end, but a continuing process. There will be frequent changes in the organization, the technology it employs, and the general business climate in which it operates, and the language of roles and the role definitions themselves must change along with these variables to ensure that roles reflect the current reality at any given time.
Roles can follow a variety of lifecycle paths: some live longer than others, most change over time in ways that require regular updates, and new roles will be needed over time as well. Your enterprise should review its role-set on a regular basis and update it as needed.
A metrics-driven approach can prove to be very useful in role lifecycle management. Using key performance metrics to track the effectiveness of a role provides the understanding of where change is occurring and alerts role owners and IT to determine if a role needs to modified, combined with another role or retired. Measuring role quality provides the decision support that keeps roles working effectively.
8. Keep it simple. Real-world attempts to implement roles-based systems have shown that unless roles fit into a context that ties together existing entitlements, company policies, regulatory requirements, and current business process realities, they simply don't work. Without this context, the result is a system that can't keep pace with changing business-user requirements, and that can leave the organization open to unacceptably high levels of risk.
By keeping your roles initiative within the scope of the steps outlined above, you will maximize your chances of developing a role-set that lowers your organization's user access-related risk level, gains wide acceptance throughout the enterprise, and reduces the burden on the IT security organization.
Deepak Taneja is the founder, president and CTO of Aveksa Inc. (www.aveksa.com), the market-leading provider of enterprise access governance solutions. Previously, he was CTO and VP of engineering at Netegrity, where he was instrumental in establishing the company as a market leader in Identity and Access Management prior to its acquisition by CA.
