Wednesday, April 28, 2010

A. Schaad, J. Moffett, J. Jacob. 2001. "The Role-Based Access Control System of a European Bank: A Case Study and Discussion"

RBAC research problems
  • Often research tools work with minimal testing datasets as no real figures for the number of users, roles and permissions in commercial systems have been published.
  • Companies that have successfully deployed access control systems are often unwilling to provide descriptions and figures for their role-based systems for security reasons.
  • As a consequence researchers use toy examples that fail to reflect the complexity of large industrial organizations.
  • This leads to a lack of credibility from the user side.


Dresdner Bank
  • 50,659 employees
  • 1,459 branches world-wide
  • main business: about 6.5 million private customers and 1,000 branches


FUB system
  • Applications cannot make access control decisions on their own. They grant access to data on the basis of a centrally provided security profile.
  • An application is launched by a user who first identifies and authenticates himself to it. Initially the application has no knowledge of any relevant access permissions the user might possess. It queries the FUB about the security profile of the current user in order to obtain this information.
  • Created in 1990. and thus much earlier than most of the published role-based access control discussion.
  • On average 42,000 security profiles per day are distributed by the FUB.
  • The time needed by the system to determine one individual security profile is approximately 85 ms.
  • The system’s availability rate is 99% per year.


FUB basic system architecture
  • The FUB is a role-based access control system. Roles are defined as a combination of the official position and job function.
  • A batch job runs between the human resources system and the FUB every night. Thus, the access control system has a very accurate image of the current organizational status and existing roles.
  • Within the FUB the data delivered by the human resources database are linked to applications. Access rights are assigned to applications.
  • When a user starts an application (through a role) the FUB delivers the security profile that tells the application which individual access rights the user possesses.
  • Employees belong to an organizational unit. Ideally each employee is only assigned to one role. However, in special circumstances an employee can be given up to four roles (e.g. in
    the case of illness of a colleague).









Application example
An existing bank client wishes to discuss his personal savings situation with the branch’s financial advisor.
  • The advisor identifies and authenticates himself to the machine using a smartcard and his password.
  • He launches an application that allows him to enter the records of his client which are stored on a central server.
  • When the application is launched it issues a request to the host, querying which rights the advisor has within the application domain.
  • The application request contains the personnel number, which was obtained during the identification and authentication process. Also the application identifier is submitted to obtain the relevant authorisation profile for the application.
  • Once the FUB has used these data to deliver the security profile, the application knows which access rights are assigned to the role of the user and allows him to execute his access rights accordingly.





The number of roles
  • 65 official positions
  • 368 different job functions
  • 65 * 368 = 23,920 possible roles
  • actual number of roles: 1300
    • These figures match an oral estimate that was given at the RBAC2000 Workshop, suggesting that the number of roles in a role-based system is approximately 3-4% of the user population.


Role administration and control principles
  • Human Resources Department - Role Definition and User/Role Assignment
    • A user is given a unique number that serves as his user identification number.
    • Also the roles are defined there, maintaining and combining functions and official positions.
    • A user is then assigned to a role.
  • Application Administration - Access Right Definition and Application/Access Right Assignment
    • The assignment of access rights to an application is done for each individual application through the application administrator.
    • This takes the form of assigning a set of numbers, representing specific access rights, to an application identifier (e.g. PKI = Private Customer Instruments).
    • The semantics of these numbers are only known to the application administrator (e.g. 203 = Create new account in the Private Customer Instruments Application).
    • The benefit of this is that it remains unknown to the FUB administrator responsible for the role/application assignment what access right a specific number represents within the application domain. (how is this an advantage)
    • Dual Control: One person can alter data, whereas a second person has to confirm these data.
  • FUB Administration - Role/Application Assignment


Administration problem
  • It has also to provide access control services to users which can not be considered as permanent staff. (third party consultants, temporary staff, freelancers)
  • Ideally, this group of users should always get a new account when starting work and their accounts should be deleted when leaving the project. However, this creates overheads.
  • Thus, information about this group is not held in the Human Resources database, but is locally administered by the FUB staff. User accounts are created once and are usually kept (de-activated) when a consultant leaves.
Revocation of role and permission assignments
  • By coupling the information delivered by the human resources department any user/role assignment ceases to exist when the user leaves the company.
  • Also any user/role, role/application assignment becomes invalid when the organizational structure changes.
  • This tight coupling bears certain dangers, because deleting a user from the human resources database will subsequently delete all his work when he ceases to exist in the system.
  • Additional controls and organizational measures are needed to prevent valuable work from being lost.



System development goals
Access right allocation
  • In the current system access rights can only be allocated to the combination of function/hierarchical position and organizational unit.
  • However, in the case of certain access rights (e.g. set of access rights representing the power of attorney for an employee) it is desirable to assign these directly to the user.
Grouping employees
  • A grouping mechanism will provide ease of administration as only the group needs to be assigned with a role and not each individual.
Grouping access rights
  • Example: grouping of access right 101 for create account, and 102 for delete account into a single group G1 for account manipulation.
  • These grouped rights will provide an easier assignment of access rights to applications.
Covering/Standing-in regulations
  • Regulations for the covering of one employee by another (e.g. holidays or illness) do not exist.
  • There are a variety of unresolved issues.
  • The ability to only partially delegate application-specific access rights is one of these.
  • Another problem considers the ability of one person to stand in for two others at the same time. This might violate any Separation of Duties requirements.
Competencies and Constraints
  • The current system does not allow the specification of competencies and constraints in the security profile (e.g. authorization to sign contracts up to DM 100,000 only).
Mapping of access control system to organizational structure
  • The current access control system does not provide the flexibility to meet these changes (constant change process in their structural and functional organization, unforeseen acquisitions or mergers) without a major administrative effort.
  • Certain strategies in the private customer business require that an employee can be related to a certain organizational structure. This could be in the form of branches or cost centers but also more abstract structures such as enterprise-wide working groups, task forces or projects. The access control system must be able to reflect these structures.



The FUB System and the RBAC Model
Access rights inheritance through a role hierarchy
  • Can be through:
    • hierarchy of official positions - financial analyst/Group manager > financial analyst/Clerk
    • hierarchy of functions - inspector/[Any position] > finance accountant/[Any position]
  • We do not have sufficient knowledge of the organization to know which would be the best choice. It would be necessary to study the organization's access control structure in detail, paying particular attention to the gained simplification in each case, and to the other issues.
Grouping
  • The Bank is considering introducing a mechanism for the grouping of employees. A grouping mechanism will provide ease of administration as only the group needs to be assigned to a role and not each individual.
  • The RBAC96 model does not allow for the assignment of groups to roles.
  • However, other approaches to RBAC have recognized the value of using the group as a basis for the definition of roles.
  • The concept of domains can also be used to provide a mechanism for grouping users.

No comments:

Post a Comment