Need a way to control network access? Government already has it.
Role-based authorization has become a standard for protecting large organizations' resources
- By William Jackson
- Apr 04, 2011
Role-based access control has saved the U.S. economy more than $6 billion during the past 16 years, according to a study sponsored by the National Institute of Standards and Technology, and RBAC has become the standard for managing access to IT resources in industry and government.
RBAC was formally proposed by NIST scientists in 1992 and adopted as an industry consensus standard in 2004. A study conducted by RTI International estimated that NIST’s work hastened the adoption of the access control scheme and cut development costs, accounting for about $1 billion of the savings.
“We had no idea where it was going to go,” said NIST computer scientist David Ferraiolo, who, along with Rick Kuhn, authored the first formal RBAC model. Now, more than half of all organizations that have more than 500 employees use RBAC for at least some access control, and government agencies routinely use it. “There is no mandate for it,” Ferraiolo said. “It is all market driven.”
The initial $2.6 million that NIST spent on RBAC turned out to be a good investment, producing a return of 249 to 1.
Access management is an essential element of cybersecurity because access to resources opens them to intentional or accidental misuse or exposure. To protect those resources, many systems authenticate a user's identity with some form of ID management before granting access to certain resources. RBAC is one scheme for describing what a user is authorized to do.
Keys to access control: visibility, granularity, 'set it and forget it'
The value of access control is easy to demonstrate
“Although RBAC is not the perfect solution, it enables greater shared responsibility and more effective and efficient permissions management for IT and business operations,” the RTI study states.
The RBAC work evolved from a 1991 NIST study that found agencies were not getting all the security solutions they needed. In the early 1990s, the standard of care for access or privilege control was Access Control Lists, which are specific for each system or application. They are high maintenance because rapid turnover in large organizations means someone must constantly update them.
“The Access Control List is a very low-level control,” Ferraiolo said.
RBAC is intuitive
Instead, a scheme for assigning access privileges based on a person’s role in an organization seems intuitive, and Kuhn and Ferraiolo say the idea was not original. “The concept of role has been around for a very long time,” Ferraiolo said. “What was lacking was any kind of formal description.”
“What we wanted to do was define a comprehensive access control model that was formally specified and could be used more as a layer separate from large applications instead of being hard-coded into them,” Kuhn said.
Unlike other schemes, in which permissions or access is tied to an individual, group or application, RBAC permissions are tied to the role, and users are then associated with different roles. The role links multiple users with multiple permissions. That can simplify management because the roles in an organization tend to remain stable, while personnel and permissions can change quickly.
The initial challenge in RBAC — and one that almost proved fatal — is the task of defining roles, a process called role engineering. Early in its adoption, a common complaint was that organizations could end up with as many roles as employees, if not more.
“There were some miserable results early on,” Ferraiolo said. “But as experience was gained, there were better practices” in role engineering.
The RBAC model was refined, and well before the American National Standards Institute and International Committee for IT Standards adopted it in 2004, the industry was incorporating it in products. In 1997 and 1998, Sybase, Secure Computing and Siemens announced RBAC products based on the model, and Secure Computing incorporated it into the Defense Department’s Global Command and Control System in 1997.
RBAC adoption continued slowly from 1995 until 2004, when about 12 percent of users' permissions were managed by RBAC in IT-intensive industries. Usage spiked after the adoption of the ANSI/INCITS standard and has continued to climb through 2010, when the percentage topped 50 percent, according to the RTI study.
The principal economic benefit from the adoption of RBAC came from efficiency in maintaining and certifying access control policies. More than 80 percent of the respondents in the RTI study reported greater efficiencies in managing their access policies by using RBAC. Other areas of savings include more efficient provisioning and reduced employee downtime.
All told, an estimated 18 million employees were being managed through RBAC by 2009, and organizations saw a net savings of $1.1 billion that year. Total savings since 1994 total $11 billion, which, when offset by the $5 billion cost of implementation, produces a net savings of about $6.1 billion.
Best fit for government
“RBAC is not necessarily for every enterprise,” Ferraiolo said. For smaller organizations, groups or Access Control Lists might be just as effective. It is best suited for large, transaction-based organizations, such as those in the financial services industry, where roles are likely to be well defined.
“We think it works very well for government organizations,” said Kuhn, because they also tend to be larger and have well-defined roles.
Although RBAC is not required, it has been valuable in meeting demands for security controls in regulations under legislation such as the Sarbanes-Oxley Act and the Health Insurance Portability and Accountability Act. Among federal agencies, it can help to streamline compliance with requirements for security controls in the Federal Information Security Management Act.
RBAC takes up little of developers’ time these days. “We’re doing a little bit, a few hours a month,” Kuhn said.
But it is by no means complete, Ferraiolo said. “RBAC has made a major contribution in this space, but there is a lot of work remaining to be done,” he said. “RBAC is very good at provisioning users,” but it is not so strong in adding new resources and applications to privileges lists.
It also needs to be more agile in reviewing and changing permissions for people assigned to roles. Toward that end, ANSI/INCITS is considering a draft revision of the 2004 standard that would add some elements of rule- and attribute-based access control management to the scheme. RBAC would specify the maximum set of privileges available in a role, but those could be further refined, depending on individual specifics.
William Jackson is freelance writer and the author of the CyberEye blog.