Many IT security professionals still regard role-based access and identity management as hopelessly complex because the predominantly manual approach used to review and manage roles is not scalable and the dynamic nature of roles themselves often get out of sync with reality.
The challenge of discovering established roles, defining new roles, connecting roles to IT infrastructure, ensuring roles meet compliance requirements and managing roles through their natural life cycles has 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 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:
1. The people who manage roles should understand them. Role definitions should describe, in business terms readily intelligible to any IT security, audit/compliance or business manager within your organization, what a person assigned to that role does.
2. Roles should simplify users’ view of access. Everyone 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).
3. Roles should make the management of access more effective. Roles should speed up access delivery because adding a user or making a change to user access is now expressed by what roles the 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:
* Engage key 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 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.
* Determine the existing access entitlements of all users. It is critical to have an automated access-governance system that can collect data from every possible repository of user entitlements, normalize and aggregate the data, and then put it into a user-friendly business context.
* 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 (such as application roles, system roles and network roles). This hybrid approach enables top-down business roles to be linked to detailed 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. 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.
* 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, and those that contain only a handful of users should be candidates for elimination.
* 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.
* 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.
* 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.
* 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. You also should have a process for fine tuning roles by combining or adjusting them based on factors such a: 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.
* 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 be moved out of IT and driven into the business. Having business units maintain their own roles is appropriate, since business managers best understand what access is required for a particular job or process and how changes within the business should be reflected in role changes.
* Continuously manage roles over their life cycle. 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.
* 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 business process realities, they 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.
Taneja is the founder, president and CTO of Aveksa.