This article can also be found in the Premium Editorial Download "Information Security magazine: Nine tips to guarding your intellectual property."
Download it now to read this article plus other related content.
An Attractive Model
Understanding the limitations of ACL and group policies, NIST established an RBAC standard (http://csrc. nist.gov/rbac/draft-rbac-implementation-std-v01.pdf) as a guideline for
Moving toward this standard approach requires vendors and administrators to become more familiar with the RBAC model and the types of security that it can provide for different environments. The model is made up of the following components:
- Core RBAC: This is the foundation of the model, and will be integrated in every RBAC implementation. Users, roles, permissions, operations and sessions are defined and mapped according to security policy. It defines many-to-many relationships among individual users and privileges; it describes how a session is a mapping between a user and a subset of assigned roles and accommodates traditional but robust group-based access control.
- Hierarchical RBAC: This allows the administrator to set up an RBAC model that maps to the organizational structures and functional delineations required in a specific environment. This is very useful, since businesses are already set up in a personnel hierarchy. In most cases, the higher you are in the chain of command, the more access you will likely have.
- Static separation of duty: Constraining incompatible combinations of privileges is a critical concept to prevent abuse of authority, including fraud. An obvious example would be that an employee cannot be a member of both the cashier and accounts receivable groups.
- Dynamic separation of duties: Deter fraud/conflicts of interest by constraining the combination of privileges that can be activated in the same session (See Figure 1). For example, if I am in the groups cashier and cashier supervisor, I only have the access rights and work within the security context of the particular role I log in under. I do not have the aggregate privileges of both roles during one session.
Here's how it works. Many users can belong to many groups with various privileges outlined for each group. When the user logs in (this is a session), the various rights assigned to roles and groups that he is a member of are available to him during this session. So if I am a member of the accounting, R&D and administrative groups, I can use any or all of the accumulated privileges assigned to each group.
For example, the nurse role can access certain files and the lab technician role can access another set of files. The doctor role inherits the permissions and access rights of these two roles and has more elevated rights already assigned to it.
This was first published in May 2007