the cups blog

07-23-08

Some Usability Consideration in Access Control Systems

Elisa Bertino, Seraphin Calo, Hong Chen, Ninghui Li,Tiancheng Li, Jorge Lobo, Ian Molly, Qhiua Wang
The RBAC (role based access control) model: groupings of users with roles and then permissions, rather than direct assignment to each user. Been around a long time, fairly standardized.
Managing roles: In midsize enterprise with a few thousand employees, can have hundreds of roles and resources. Large enterprises -> thousands. Roles simplify management and improve security, but there is a high upfront role engineering cost to create these systems.
Two approaches to build systems from scratch: (1) top down, people perform analysis of business processes and derive roles. This is how it’s done right now, lots of human effort. (2) Bottom-up (role mining): still mostly research not practice. Use data mining to discover roles from existing system config data. Practical value is controversial: how do you mine roles with real-world meanings, they may not have natural sense, they may conform to a mathematically model instead.
Value of meaningful roles: sys mgrs add, remove, modify on a regular basis: dynamic users, roles, resources. If rule is #126, very hard to know the meaning: you want some semantic meaning. Optimize a snapshot of an RBAC system is very static, and that’s how many role-mining systems work today.
Top down has limitations too: expensive, time consuming, companies may not have the expertise for elicitation, and info may be confidential so consultants are not just clueless about your business and expensive, you’ve had to turn over vital business information to outsiders.
Want to build good RBAC systems. Problem 1: no standard or accepted metrics of a good system. Is this the structure, something about ease of use, how do you capture more than just a snapshot? Problem 2: orgs have trouble designing efficient and easy-to-manage RBAC systems by themselves using top-down. Automatic tools have great commercial value.
Idea: incorporate both approaches. Remember you need to maintain it and update it, RBAC is not static system.
Table: role mining roadmap, to use as much information as possible. See paper. Want to have semantic meaning after an automatic system is built. Use user attributes: name, job title, location, etc and feed that in. Where are resources located, logs of how the system is being used to learn new policies.
Managing evolving systems: need to deal with missing information as well as changes. Information may be incomplete, imprecise, have errors. Need to be able to recover from this and help improve the system. Companies merge, multiple legacy systems, etc.
Dynamic tools: limited research. Don’t know how to do this, just highlighting it’s an important area that is green, no real work here. Suggest a more holistic view of the system, apply learning techniques to generate RBAC system.
IBM has a set of products, ITIM Admin interface, one is web oriented. List of roles, see information about relationship between roles and resources. There’s also a GUI with graphs, not easy to see in the graph though.
Current support tools under evaluation to reduce configuration complexity.
Q: these roles get tangled and confused over time. Would be interesting to hear examples. A: company of 20,000 people buys a company of 3,000. Two systems, no what?
Q: people in the banking industry were using this back in the 1980s. Budgeted this as an infrastructure cost? Economics and business process may be key, e.g. cannot go live with a new service until RBAC updated. A: Yes. Companies would like RBAC but don’t have know-how and it’s very expensive.
Q: Total cost of ownership important. What about security issues wrt end user provisioning? What are the threats? A: Companies are asking for foolproof systems. Instead, assign some risk to how the system works. Measure how secure the system is and where to improve from 90% to 95%. When is it worth the money to improve?