Requires Free Membership to View
SearchFinancialSecurity.com members gain immediate and unlimited access to in-depth technical advice, strategies, and expert guides for securing data in high-risk financial environments. Join me on SearchFinancialSecurity.com today!
Michael S. Mimoso, Editorial Director
|  | ||||||||||||||||
| |||||||||||||||||
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.
Implementation steps
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.
 |
||||
|
|
|||
|
||||
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.
This was first published in June 2008