Role-Based Access Control – Where to Begin - Part II

In Part I of this series we discussed the benefits of implementing Role-Based Access Control. In order to realize these benefits, we need to understand what applications their employees use to be productive in their jobs.

Question: How does someone go about developing a coherent and consistent definition of Roles across the information systems?

Answer: Application Portfolio Management (APM) and Application Rationalization

Application rationalization can help address the following:

• Identify users that do not need access to the application
• Establish a baseline for each position and how they use the information in applications
• Identifies types of access required for each job/position
• Prioritizes applications and identifies best candidates for RBAC implementation

Application Rationalization Step 1 - Eliminate the obvious

A good starting point to cleaning up this mess is to reach out to the application owners for the most sensitive/risky applications and show them the departmental positions that use the application and ask if those positions have the appropriate access. The application owners provide the first cut, eliminating those users in positions (and departments) who should never have access to the application.

Application Rationalization Step 2 -Identify the real needs

The next step is to go to the business managers in each respective department and get their approval as to which information and applications are required for each position.

• Remove user from applications they no longer need access to or use.
• Align information access with job responsibility/position.
• Prioritize applications that will benefit the most from RBAC automation

At the end of this exercise, you will have cleaned up the application environment – having both removed departments and users who are in job functions that should never have access, and having eliminated users who should no longer have access based on their current job responsibilities.

Application Rationalization Step 3 - Final Step

• Obtain buy-in from stake holders: Managers, Application owners and users.

Now all people in the same position will have access to the same applications. Determining the access each position requires makes it much easier to define roles and determine what applications a person should have access to and at what level. And that will be the focus of Part III of our RBAC series.

Coming soon: Role Based Access Control – Building your Role Library - Part III

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.