Go RBAC now

Implement role-based access control for stronger security in your environment

Good computer security is driven by role-based, least-privilege access control. Each user should be given only the access that is necessary to perform their job — no, make that the specific task they are performing at a specific point in time.

Unfortunately, even though RBAC (role-based access control) was formally introduced in 1992, it is still in its infancy on most platforms. There are many role-based management tools that work in Windows, Linux, and other OSes, but the most popular products work with only a few large products (that is, SAP, PeopleSoft, and so on) or just haven’t been widely adopted. For example, Microsoft has formally supported the RBAC model since it released Authorization Manager and a role-based API in Windows Server 2003. But it is rare that I run into a system admin or developer who has heard of it, much less worked with it. If you haven’t heard of Authorization Manager, go to any Windows 2003 or later Windows server and type Azman.msc in the Run command line. There’s lots of information on it if you do an Internet search.

Linux has long had RBAC capabilities. Nearly any decent Linux distro will allow you to add an RBAC security module. Many versions, such as SELinux (Security Enhanced Linux), come with RBAC by default. If you don’t have SELinux, there’s still a good chance your Linux supports RBAC already. Just look for the MAC module and read the man pages. There are also many developing RBAC initiatives, such as the OASIS XML-based RBAC effort for Web-based content (PDF).

Reasons for RBAC

Why investigate RBAC solutions? They’re a good way to implement stronger security in your environment, and often it is required. Many industry-wide regulations, such as the Payment Card Industry Data Security Standard (PCI DSS), require role-based security (PDF). If you’re required to support PCI DSS in your environment, review section 7. Hospital and health-care-related entities are already aware that Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandates use RBAC to protect patient information.

The vision of RBAC security is this: No one knows better what security permissions or rights should be needed by a particular end-user when performing a particular task than the developer of the application. Unfortunately, this particular assumption is largely untrue. In general, most developers don’t have a clue about the security needed to run their application. They just know the application runs perfectly fine when given Administrator or root privileges. This attitude is changing, with Windows Vista’s User Account Control (UAC), Linux’s sudo, and better development tools that allow needed security to be measured and defined.

Let’s assume that application developers do know exactly what permissions are needed for each task in their application — and this is indeed true of any application developed with RBAC in mind. The developers create application-specific groups that mimic the various roles that an end-user would perform in their application.

For example, in a payroll application, you might have the payroll data entry clerk, the accounting and general ledger associate, the check publisher, and the payroll manager. The application developer defines the various roles and ties each role to various tasks needed to perform the role (called transaction authorization in RBAC terminology).

When the application is installed, the application manager assigns the various users or groups to their needed roles (called role authorization). Then the end-user can perform only the tasks assigned to their role (rule assignment).

A great benefit of role-based security is dynamic access control. When the end-user is not performing a particular task, they don’t have any access permissions to the underlying resources. For example, when a payroll data entry clerk is logged into a RBAC application performing their normal duties, they have read and write access to the appropriate fields of the payroll database. When they come out of that particular task — say, to a main menu — their access to the database is removed altogether.

This is a great improvement over other access control implementations. Consider how access control works on most systems today. The payroll clerk is probably given read and write permissions to the entire database file in perpetuity until their user account is disabled or deleted. Unbeknown (hopefully) to the payroll clerk, they could probably delete or overwrite the entire database file if they accessed it directly using a file share instead of through the application view (called view-based access control). Our security is based on obscurity and the hope that our employees don’t want to harm the company. What’s to stop the employee from downloading the entire database to gazillion-gigabit USB drives and taking it to a competitor?

Time to start

If you don’t have a role-based security model, you should start researching it and strive to move to RBAC, if only a tiny step at a time. You can start by defining your access control security groups by roles instead of departments. Don’t designate HR, IT, and accounting security groups; instead, create security groups for each department based on their roles. Look to your company’s organizational chart or job descriptions if you need a beginning point.

Start investigating software that uses an RBAC model. Look at the RBAC tools in your OS, whether it’s Windows, Linux, Unix, OS X, Solaris, or something else. Investigate software that can bring role-based access control to your environment. Just use the keywords role-based access control or role-based management in your favorite Internet search engine.

Ask your software vendors what they are doing to facilitate RBAC in your environment with their products. Educate your vendors if they have never heard of it. When the vendor hears it enough or if you have enough dollar votes alone to make it happen, the vendor will become a RBAC proponent. Then everybody wins.

Implementing a RBAC model is a lot of work and a lot of groups, but anything less means you aren’t truly implementing least privilege in your environment. Until you have RBAC, least privilege is just something you repeat over and over as a mantra, but can’t really accomplish.