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.

[ RogerGrimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]

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.