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.

Dangers of Scores in Decision Making -- From James Taylor

James Taylor, who we've referenced on this blog on several occasions, shared his thoughts today on the dangers of scores in decision making. He provides a great example: the Body Mass Index (BMI), which is fraught with issues but is nonetheless used inappropriately by companies and health officials alike.

I've seen the misuse of scores or other numbers in some of the organizations served by Big Sky. When a model is developed that produces a number or a score -- such as with Analytic Hierarchy Process, Statistics that measure strength of relationships, or even simple weighted averages -- there are many who focus too narrowly on the number without context, or fail to realize its limitations. For example, we will often help clients use quantitative methods to prioritize budgets, but the numbers that "pop out" are really nothing more than measures of preference; they are not truth. In many cases, they aren't useful measures outside of the model, and can't even be compared to previous analyses using the same method.

Scores must be balanced with other factors -- which James correctly points out can be codified in rules and often automated. For those decisions that can't be automated because they are inherently more political or are subject to other unpredictable factors, the limitations of "scores" should be carefully and frequently communicated to all stakeholders to avoid confusion or misuse.

Thanks to James for a great post.

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.