Burton Group Catalyst Conference: Roles-Based Access Control Highlights

Today was the first day of the Catalyst Conference general sessions and a number of the sessions that I attended were focused on Identity Management and in particular RBAC. At Big Sky we have always asserted that Identity Management begins with defining the core business processes behind on-boarding and off-boarding users (employees, contractors, etc.) It’s nice to hear from the Catalyst presenters that organizations that have experience in implementing RBAC have a similar point of view; successful implementations start with the process and not by mapping system privileges. Begin at the top and drill down to the details. A summary of the key areas that need to be understood when defining roles:

1. What does each person do in their position? (e.g., DILO study of work processes)
   
2. How do we optimize the processes for that position? (What are the value-added decisions and activities), and then
   
3. Understand what applications that person needs to be effective within that process. (Determine how to best accomplish tasks and share information)

The roles definition will naturally fall out of this exercise and allow the business need to drive the IT implementation. After all, the effectiveness of the roles you define depends on properly matching the right entitlements with the right user in the right position.

Role-Based Access Control – Introduction – PART I

Knowledge and innovation are key factors contributing to growth and prosperity in a service economy and require an information framework that organizes and makes information available when and where it is needed. The challenge facing organizations is not just in managing organizational knowledge, but in determining who should be given access to that knowledge. This Blog entry offers an overview of the latest set of tools known as Role-Based Access Control (RBAC) that provide a security model to manage access to sensitive organizational information.

Historically, organizations have granted access to their applications and data through a security system that is based on application-level administration to grant and deny access to resources. Administrators had to maintain a list of rights for users known as Access Control Lists, or ACLs, to manage system access. As the number of applications and users grew so too did the administrative burden of maintaining ACLs. Furthermore, the security risks to the organization increased because administrators had no effective tools to promptly remove users who should no longer have access to systems. These problems are eliminated in an RBAC security model, where user access is administered dynamically through Roles.

As organizations have opened up their networks to the Internet, securing their information resources has become much more complex. It is a difficult balance to strike between protecting customers, employees and shareholders from potential risks or losses and the need to achieve organizational goals efficiently and effectively. While many would argue that the security is a cost of doing business, the increased expense and effort required to implement effective security models becomes daunting as information is made widely accessible beyond organizational boundaries. This challenge can be mitigated, however, by Role-Based Access Control, which allows organizations to automate security decisions about who has access to what.

A Role has a set of permissions and by placing a user in a Role, that user is granted access to the systems or resources associated with the Role. Users are assigned to one or more Roles, and each Role is associated with a permission or set of permissions to IT resources. In this way, a Role establishes the relationship between the users and the systems that they are authorized to access and provides a much more efficient way to decide who has access to what resources. Organizations no longer have to work at the application or system level, instead they can use roles to assign the appropriate permissions en masse. As a user’s responsibilities change (i.e., they are promoted or move divisions) they are removed from their old roles and placed in new roles based on their job title.

Let’s walk through a quick example. Bob is hired by ABC, Inc. as a Financial Analyst I and gets assigned to the Base User Role, which grants access to the network, email, and the time & expense system. Bob also gets assigned to the Financial Analyst Role as is granted access to specific financial systems and reports required for his position. A couple of years down the road, Bob moves to Accounting and takes a position as Accountant II. As his position changes, he is automatically removed from the Financial Analyst role and assigned to the Accountant role, losing access to those systems he no longer requires to perform his job and gaining access to the accounting systems that he now needs. The end result is that security is implemented more efficiently and effectively and administrative holes (e.g., removing users from systems they no longer require) are eliminated. The question is “What do we need to get there?” which will be the subject of my next entry.

Why Optimizing Decisions is the Most Important Thing You Can Do, Part III

In our last post in this series, we introduced a simple, four-step approach to optimize decisions that we call Decision-Centric Business Improvement. The critical decisions identified through that four-step process represent the resource-intensive turning points of every organization’s growth. These decisions are diverse; some are large: corporate acquisitions, multi-billion dollar procurements, and 5-year strategic goals. Some are smaller: choosing a commodity supplier, making a hiring decision, or choosing the functionality of a software solution. Some decisions are manual, while some are automated. Some require one person; some require groups or even multiple organizations.

The last step in Decision-Centric Business Improvement is optimizing decisions along three angles: strategic relevance, technique, and technology. When optimizing decisions, it is critical that an organization work through each of these angles to build a coherent, balanced approach to the decision in question. The figure below illustrates these three “angles” of decision making.


The Decision Strategy Angle
The first angle of effective decision making is how the decision influences advancement of the organizational strategy. To clearly understand this angle, an organization should isolate the most important strategic metrics of the organization and describe the decision in terms of those metrics. If a decision cannot be shown to have a measurable impact on strategic goals, there is little chance that the decision can be successful.

The right approach in this angle is not to develop a new strategy, but rather to understand the strategy (whether implicit or explicit) and to define a particular decision in the context of the strategy. Traditional strategic planning tools—such as SWOT analysis, multiple forces analysis, or Value Chain Analysis—may be useful in this angle but should be focused on the decision.

The Decision Technique Angle
The second angle of effective decision making is the selection and application of the right tool for the job. A carpenter wouldn’t use a sledgehammer to drive carpet tack; similarly, a good decision maker chooses the tool that is just complex enough—but no more complex—to do the job. In this angle, an organization must understand both the soft and hard aspects of the decision. Hard aspects include the required speed and frequency of a decision, as well as the number of variables involved and whether the decision requires descriptive (backward-looking) or predictive (forward-looking) results. Soft aspects invlude the level of organizational buy-in required, political consequences, human factors, and transparency requirements.

For an automated supply chain decision, an organization might choose to develop a sophisticated algorithm that completes on the fly multivariate analysis. For a one-time strategic decision at a board meeting, it might use a decision tree or a consensus building method. Hypothesis testing, analytic network process, analytic hierarchy process, real options are other approaches that might be used to aid decision making.

The Decision Technology Angle
The third angle of effective decision making is the application of appropriate technology to enable the decision. Most organizational decisions will benefit from better management and distribution of information aided by technology, but not all. Knowing if, when, and how to apply technology is the component of decision optimization least understood and most prone to error.
Good decisions result from a qualified decision maker armed with the right information, delivered at the right time in the right context.

Rather than selecting one-off technology solutions, an organization should understand their “Decision Architecture” – an architecture optimized for effective decision-making. In many cases, this architecture may be comprised of existing systems rather than expensive new ones. Effective organization and adaptation of organizational IT can transform decision-making capabilities in many organizations.

While “hard” decisions—those with many variables or high speed requirements—are the most obvious candidates for the application of technology, technology can be a critical enabler of softer decisions too. Collaboration tools, role-based access control, and innovative application of existing technology (like wikis) can be critical enablers of infrequent, collaborative decision-making. In every analysis of a critical decision, whether “hard” or “soft,” technology should be considered as a important enabler of long-term success.

First Steps with Identity Management: White Pages

Identity Management solutions are very complex and require collaboration across organizational boundaries, IT systems, and networks. Often times, identity data is assumed to be of sufficient quality (see our Blog entry “The Five Elements of Data Quality”) to provision users automatically, define roles, and develop workflows. Unfortunately, this assumption is often false and has severe consequences on any value that you hoped to get from your IdM solution.

One recommendation that we typically make to organizations that are just starting to build their IdM infrastructure is to release a white pages application as their first step. While the value to the organization is often low, so too is the risk if the application fails. This “low value, low risk” approach does offer significant insight, and value, to a small group of concerned individuals: the project team.

One of the nice things about the white pages application is that you can open it up to your end user community for self-service updates. User attributes like Hiring Manager, Department, phone number(s), and job title can all be opened up for editing. End users can update their own information using self-service tools and publish that information to the directory.

From this simple application we get the following benefits:

1. Visibility into all data stored in the directory
   
2. Ability to troubleshoot the Identity Management infrastructure (connectors, schema, namespace, self-service tools) in a production environment and develop a data remediation plan
   
3. Centralized tool to collect updates for user data
   
4. Validation of user data against standards and business rules before publication to the directory and synchronization with other systems
   
5. Improved data quality across all connected systems

Identity Management: Begin with the Process

In one of our earlier entries, "Identity Management: Observations from the Trenches", we discussed some of the pitfalls of rushing to implement an Identity Management solution without looking at data quality, data requirements, and starting with a point solution instead of an enterprise approach. I wanted to add to that discussion and emphasize the importance of knowing your processes before you implement identity management projects.

Many times a project can seem straightforward both technically and organizationally, but often there is something you don’t know that will send it to the scrap heap. Let’s look at the following example: a company wants to improve the time to provision new hires into their non-connected systems by sending an automated email as soon as the user’s identity is created in the directory. Based on the way the process runs today, the client believes they can save two weeks in new hire provisioning, and they are eager to cash in on this golden opportunity. Fair enough.

At this point, the development team is ready to start building something immediately. The core infrastructure is already in place, we just need to slap in some workflow with emails and we are golden, right? Not so fast. It turns out upon further evaluation, that the organization did not clearly understand their onboarding processes. The assumed bottleneck, that staff were not receiving notifications of a new hire promptly, was not really the problem. Instead, the delay in the process was caused by the manual assignment of the user’s id by another department. This id was required for all provisioning activities, including creation of the user’s identity in the IdM system, which means that system-generated emails buy us nothing; they simply automate a part of the process that is already working fine.

So what are our lessons learned?

a)Bring key stakeholders (business owners, corporate staff, etc.) into the early planning meetings and touch base with them regularly

b) Start by mapping out your processes from recruiting through creation of the user identity in the directory (work with your stakeholders to complete this analysis)

c) Identify key data that are needed (user id, etc.) to support the project, where the data reside, and when they become available along the process

d) Validate your process maps with your stakeholders. Step everyone through the process and discuss:

a. the process steps (Are they correct? In the right sequence?)

b. process timing (How long does each step take?)

c. data flow (What data are available when?)

d. process bottlenecks (What are the slow points in the process? Rank them in terms of time consumed.)

e. process dependencies, and identify any process changes that will be required (Can we get people into the ERP system sooner? Can key data fields be entered earlier? Do we need to change the way approvals occur in the process?)

Identity Management: Observations from the Trenches

Identity Management is often treated as an IT project, when in reality it is a combination of business process redesign, regulatory compliance, and IT infrastructure. We find that our clients are increasingly taking on identify management as a strategic initiative of the business, and making smart decisions about IDM strategy is critical.

Identity Management begins with a proper foundation Identity Management has been around for several years offering organizations the benefits of reduced IT administration, improved security, and efficient auditing and reporting tools to meet regulatory requirements like those dictated by Sarbanes-Oxley. Although the benefits of Identity Management are compelling, many organizations struggle to develop a solid infrastructure before jumping ahead to pursue more high value projects. It’s like building a house before your foundation has been properly completed; this is always a bad idea.

What brought us here in the first place…
Organizations experiencing rapid growth often find that their existing manual processes and tools are no longer adequate to get the job done. For large organizations, the IT staff will create, delete, and modify accounts for tens of thousands of people a year. Are these the kinds of activities your IT staff should be spending the bulk of their time on?

Worse yet, Sarbanes-Oxley compliance requires the ability to audit your systems and know who has access to what accounts. In many cases, contract labor or additional IT staff are hired to comb through systems and remove orphan accounts, revoke access to unauthorized users, and ensure that generic and admin accounts have not been misused. At the end of the day, throwing more bodies at these issues isn’t going to solve the underlying problem – manual processes don’t scale.

This is not just another IT project
Unlike a server consolidation project, or upgrading an email platform, Identity Management (IdM) has a broad scope that affects both business processes and IT systems. Partnerships will have to be built across internal IT silos (networking, security, UNIX, mainframe, user applications, help desk, etc.) as well as with the business. The most important relationship on the business side of the house is with Human Resources, which controls all employee data (job title, department, manager, location, contact information, etc) and owns the hire and termination processes that affect the account management lifecycle.

Identity Management relies on triggers in the enterprise ERP system to create, modify, disable, and delete accounts in all connected systems according to well-defined business rules. Thus, an employee hire will automatically create a user identity, assign the user appropriate accounts, and rights, for their role and then turn around and remove that identity and delete accounts when the employee leaves. Clearly, there is a lot more complexity involved here than simply slamming in a new application and training a few users.

Doing it right the first time
A common problem with Identity Management projects is that organizations want to jump ahead to realize the benefits of IdM, without having built the foundation required to support the solution in the first place. This is tactical approach that attempts to cherry pick the high value projects, without building the fundamental components of the solution first.

One common shortcut to this end is placing a special purpose directory in the position of metadirectory. The special purpose directory is one intended to support a particular system, say your SendMail application. Its user objects, schema, namespace, and architecture are tuned to manage accounts and user data for that application, but are not designed to perform the same function across multiple systems. In the end, organizations run into issues with data quality, application integration, and scalability. They often find that the directory structures that worked well to support an application are not fit for an enterprise class solution.

“Doing it right” means having the discipline to build out your core IdM infrastructure before tackling high value initiatives like provisioning, single sign on, and automated workflows. Big Sky Associates recommends establishing an Identity Management strategy and road map and having the discipline to follow it.