Role based access control (RBAC) allows financial services firms to provide access controls based on roles, not users. Each user has a role assigned and then permissions to each role for access to resources, applications and services that support role based access control. The role may represent job functionality or organizational hierarchy.
Role based access control was first proposed by the National Institute of Standards and Technology (NIST) in 2000. With further refinements the model was adopted by the American National Standards Institute, International Committee for Information Technology Standards as ANSI INCITS 359-2004. In May 2008, a draft was created based on INCITS RBAC CS1.1 Implementation Standard to address the complexity of managing security administration in large networks.
When implementing role based access control, the ultimate goal is to easily add, review, update and delete permissions. To achieve this, financial firms should use the standard NIST model to build the role based access control system. This model consists of four levels in which each higher level includes the functional capabilities from the levels below it.
Flat RBAC provides few requirements, including roles, user-role assignment and role-privilege assignment. The number of roles for each user and the privileges for each role is kept to a minimum.
Hierarchical RBAC requires support for defining roles in a hierarchy. A role can be senior (e.g. supervisory cashier) on down, with the senior roles inheriting all the privileges of the junior roles. Security administrators can use role hierarchy to map between two RBAC-based domains.
Constrained RBAC requires separation of duties primarily to avoid fraud. It allows administrators to enforce dynamic separation of duty to prevent a user assigned two roles to act simultaneously in a single session. For example, the role as a cashier must be closed before the role as a supervisor can be open to access an account, although the user is allowed perform each role in a different session.
Symmetric RBAC adds a permission-role review requirement, similar to the user-role review requirement in the flat RBAC. Symmetric RBAC allows identification of the permissions assigned to existing roles and vice versa. For example, by identifying permissions of a user leaving the company, the administrator revokes all of that user's permissions, and then reassigns the role to another user with same or different set of permissions.
This four-step sequence for large networks of diverse platforms, multiple applications and location separation may not always be applied in practice. Firms may opt for the alternate model in which the features of later steps may be adopted prior to adopting features of earlier steps.
Patents and products
To reduce time, cost and complexity of implementing role based access control systems, financial services firms can choose to develop role based access control system products. In product development, the firms can apply their own role based access control patents. Financial firms in compliance with Sarbanes-Oxley may opt to buy a role based access control-based product and a license that comes with it. Organizations wishing to develop or buy a product of Web applications that use role based access control services should ensure the product vendor is using OASIS XAMCL (eXtensible Access Control Markup Language) v2.0 standard.
Implementing the standard NIST role based access control model in a four-step sequence can be a challenge for a financial services firm. Developing your own role based access control patents or getting a license to use a role based access control patent can make the job easier.
About the author:
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide system, database technologies, application development, network management, computer security, information assurance, financial, RFID technologies and project management.