Role-Based Access Control Flawed in Actual Use

Long before computers existed, society wrestled with the problem of controlling the right to read or change a document. Two systems were created to deal with the problem: In government, access rights were controlled by the user’s level of security clearances, and in civilian life, the author of the document or his assigns, such as the publisher, retained the right to make the decisions.

By the early 1990s, the transition of businesses to computer networks had inspired a third system: defining access rights around user properties. These clusters of properties were called roles; thus, the new idea became known as Role-Based Access Control (RBAC).

Early on, it became clear that RBAC was enormously powerful, at least in theory, since almost any property could reside in a cluster. While “a position in the corporate table of organization” (meaning that an HR staffer would not be able to change and read documents that those working in the finance role could, and vice versa) might be the most obvious example, there were many more. Corporate authorities could define roles in terms of time, location, system resources, schedules, authorizations, access histories or just about anything else they liked.

This generality made RBAC far more than just a security technology. A permissions structure that connected users with just the resources they required for a particular task at a particular moment would also reduce the costs imposed by such routine wastes as inattentiveness, ignorance and confusion?any one of which is more damaging for most enterprises than classic security violations. It seemed to promise at least a partial answer to the major downside of computers, which is that they empower users to make larger mistakes faster. It held out the promise of integrating both network-based and physical assets into a single system (the same RBAC system that lets you use a printer near your desk would also control what entry doors you could use and when, for instance). Done right, such a structure would encode management intelligence right into the network.

We liked this idea and ran an article, “Lines of Defense,” endorsing the technology in our Feb. 15, 1994, issue. We weren’t alone. In 1996, Eric Davies, now founder and CEO of SparkSource, a high-tech PR firm in Lexington, Mass., was part of a team working on eRoom, a collaborative platform for small companies. “Most of our developers, though not all, thought very fine-grained, powerful access control would be an essential feature,” he remembers. “And when we talked with our potential customers, they thought so too.”

However, once eRoom shipped, Davies found that in real life, users kept their access control structure as simple as possible, usually paring it down to just two boxes: systems administrator and everyone else. In retrospect, Davies thinks the need to sit down and decide who was going to need what when was just too onerous; it required too much thought.

Ravi Sandhu, director of the Lab for Information Security Technology at George Mason University in Fairfax, Va., adds that there was often a political problem as well. While everyone thinks they know what terms like accounts payable mean, the definitions that organizations use in practice can vary. Implementing an RBAC system often requires that the company recognize that these differences exist, understand them and then standardize either on a single definition or on a role configuration language that allows systems to recognize and accommodate the differences. Basically, in its present state, RBAC requires managers to dip into their two most limited and important assets: the time needed for careful, disciplined, focused thought, and political capital. By and large, they have decided to simply avoid the issue.

Other technologies have been in comparable situations and escaped via what is sometimes called a training application, a pilot project that is simple enough to be feasible and close enough to a real market need to attract the capital necessary. (NASA first aimed at just getting into orbit, for instance, before it shot for the moon.) Fortunately, such a training application might be at hand for RBAC.

All IT managers know in their gut that multiple sign-on systems?in which people log on to their computer with one password, to their network with a second, to the corporate servers with a third or fourth, and so on?cannot endure. Users waste time and effort juggling all these tokens, and their companies lose real dollars creating the structure required to deal with lost, forgotten or changed passwords. Worse, these issues have no economies of scale: The costs are calculated simply by multiplying users by resources. Worse, the population of users and the number of resources they require is unlikely to stop growing anytime soon. As a result, reining in access costs will soon be a priority for IT managers everywhere. And we may already be close to that point: In a recent survey, Forrester Research found that three out of four companies in a sample of large international companies were trying to build?or had already built?integrated access control systems.

Almost by definition, single sign-on (SSO) systems will require some form of RBAC, which means that developing SSO systems will force designers to start taming the complex issues that have made RBAC such a demanding technology. The security issues are particularly daunting. Security guru Bruce Schneier says that losing a password to an SSO system is “the difference between losing a single credit card and your entire wallet.” In fact, since the whole idea is to allow systems to use each other’s sign-ons, the more accurate analogy is losing your wallet every time one of your colleagues does.

“Sooner or later,” Analyst Frank Prince dourly predicted in the Forrester report, “some Fortune 500 company’s system will fail because a criminal who knew the name of the finance VP’s dog will guess a password and wreak havoc on a dozen interconnected systems.”

Prince thinks that an RBAC implementation that can support a convenient, seamless SSO system?and do so securely?is going to need three new components: security-conscious middleware, network-resident security services and agreement on an XML security standard. He believes that pulling all these pieces into place might take years.

On the other hand, an SSO system has one great virtue as a goal: It is a tightly posed problem. Success is easy to define, recognize and measure. If the Y2K episode taught us anything, it is that Nature is as forgiving and generous to well-posed problems as she is sadistic and miserly to posers like artificial intelligence. In any event, whenever an SSO system is complete, society will have a working community of engineers and vendors with the training needed to push the promise of RBAC further down what looks like a very long road.