design for dynamic user-role-based security

Computers & Security, 13 (1994) 661-671

Design for dynamic user-role-based security lmtiaz Mohammed’ and David M. Dilts2* ‘Northern ?Plecom, ‘Ibronro, Canada “Department ofMana$ement Sciences, University of Waterloo, Waterloo, Ontario, Canada N2L3Gl. Tel:(+l) (519)888-4838. Fax: (+1)(519) 746-7252. Email: [email protected]

Preventing the disclosure, modification or destruction of information in a database has been the subject of considerable recent research (see, for example, [l-3]). While mandatory access control (MAC) assigns security clearance levels (e.g. top secret, secret) to all data for access control, discretionary access control (DAC) assigns privileges to users tailored to their responsibili- tics within an application. Roth of these mechanisms have the fundamental limitation that they are unable to deal with the changing roles of a user (based on the occurrence of an event) within an application. As a result, user-role-based security (U-S) has been proposed [4, 51.

This paper demonstrates how URBS can be used to augment the existing security mechanisms. First the URBS concept, originally proposed for the object-oriented model, is extended to the relational model. Second, the extended model is augmented with the capability to respond to dynamic cvcnts. Finally, an integrated method is presented for the design of a dynamic, user-role-based security system.

Keywords: Active database security, User-role-based security, Access control.

1. Introduction

I n 1993 the University of Waterloo’s School of Optometry analyzed the possibility of computer-

izing a letter-writing application which would use data from the low vision clinic (LVC) patient information base Among other issues, there was con-

*To whom correspondence should bc addressed.

0167-4048/94/$7.00 0 1994, Elsevier Science Ltd

tern that current database security technology was unable to facilitate the automatic transition of the roles of users within the proposed system. Speci- fically, read and write privileges are granted, and withdrawn, to individuals at different times in the process on the basis of their respective roles. These roles, as clinicians, interns, technicians and volunteers, require the USC of dynamic database access and update privileges.

Unfortunately, mandatory and discretionary access control are unable to deal with application- dependent dynamic constraints. A user-role-based security model, however, has been proposed by Ting [6] to allow for application-dependent constraints. Likewise, active database theory allows for dynamic database changes by developing the con- ccpt of ‘triggers’ [7]. Our research combines these two models to build a dynamic user-role-based security (dURBS) model which allows for the active transformation of database security based on triggers and predefined user roles. The model takes into account the changing roles of a user and utilizes data manipulation language (DML) modification to provide discretionary security at the cell level. The result is a dynamic, event-driven, uscr- role-based security model. This paper presents how such a model can be designed, using the low vision clinic as a case in point.

661

I. Mohammed and D.M. DiMDesign for dynamic URBS

In the next section, past research efforts in database security arc rcvicwed. Section 3 gives additional details about the security issue and its motivation. Section 1 discusses the dynamic user-role-based security (dURBS) d CSI n ‘g concept and illustrates how it can bc applied in the relational model. Finally, Section 5 draws conclusions and offers suggestions for further study.

2. Review of the literature

There arc two fundamental streams of research which arc combined in dURBS: user-role-based security and active databases. Both will be addrcsscd in turn, but WC begin with a brief review of more traditional access control techniques.

2.1 Mandatory access control (MAC)

The need for mandatory access control arises when a multilcvcl database system proccsscs scnsitivc information with diffcrcnt security classifications whcrc all users arc not allowed to access the full set of data 12, 3, 8- 1 I]. The Bell and LaPadula model [lo], which d. ‘d 1111 cs information into distinct arcas

so that a multilevel relation will appear differently to users with diffcrcnt security clearances, is con- sidcrcd to be the best known and most widely acccptcd model for designing mandatory database security. To protect scnsitivc data elcmcnts from intcrfcrcncc, sanitization tcchniqucs arc often used to relcasc non-sensitive statistics computed over aggrcgatcd sensitive data [ 11.

MAC implements a policy that is created by a higher authority, which means that the relationship between subjects and objects is not changcablc by the object owner [la]. But the modification of classification levels can be rather arbitrary, as thcrc is uncertainty as to who dctcrmincs when information is sufficiently sanitized for a particular security classification. In addition, limiting access, based on the need-to-know principle for a particular application or task requirement, is difficult to imple- ment complctcly cffcctivcly [ 131. The critical limitation of MAC for this research is that the

MAC approach does not take into account an individual’s potentially changing responsibility within an application over the horizon of potential cvcnts.

2.2 Discretionary access control (DAC)

A complementary approach, DAC, uses a richer set of access modes to identify particular types or categories of data and those individuals with a need-to-know for the data. This approach allows the owner of an object to provide other users with access to data objects [ 11. DAC models arc typically rcprcsentcd using the access matrix model dcvclopcd by Lampson and rcfincd by Graham and Dcnning [lb]. The DAC model consists of three basic components, namely: (1) objects: files, records, data fields and programs; (2) subjects: cntitics that rcqucst access to objects; and (3) access types: read, write, insert, dclctc and update access [9].

The access matrix model supports name-dcpcndcnt access, but it must bc cxtcndcd using prcdicatcs to manage content-dependent access. A prcdicatc is a condition which must be true bcforc access can bc granted. Extensions to the model allow additional authorization rcquircmcnts and rcqucst validation [l S] and proccdurcs to bc pcrformcd during or after the request validation [ 131.

DAC security differs from MAC security in that it implements the us&s decisions in the access control and is closely linked to the database application [4]. DAC is not a replaccmcnt for MAC; rather, it provides for a finer granularity of control within the overall constraints of a MAC policy. Howcvcr, neither MAC nor DAC reflects the changing roles of a user within an application.

2.3 A user-role-based security approach

In an effort to focus on application-dependent security constraints, a user-rolebased security (URBS) approach has been proposed by Ting [6] to permit the expression and cnforccmcnt of application-dependent security constraints within the framework of a database system [I 61. URBS is intcndcd to provide a security cnvironmcnt scnsitivc to, and semantically rich for use by, users in

662

Computers & Security, Vol. 13, No. 8

performing their tasks within the boundary of security rcquircmcnts.

As stated by Ting [6 (p. 201)]:

“the exists little discussion on the analysis of application-dependent security constraints. Conse- quently, no appropriate methods J;w the ia’entijkation and analysis elf-application-dependent security constraints are available.”

Ting suggests that this type of control can bc incorporated and cncapsulatcd within the database view model or the object-oriented data model. To access data, users must specify the application and their role within that application. Such user-rolc- based access controls can bc rcprcscntcd in a set of well formed transactions (WFTs) which control the data access operations and dcterminc the data objects which arc legitimate for the unspecified role.

An extension to URBS prcscnts an analytical framework for USC of the specification in an objcct- oriented design model [ 171. The framework incorporate security rcquircmcnts obtained during the design process of an application, and furnishes feedback to the dcsigncr on the security semantics. In addition, it provides a set of analysis techniques to identify conflicts and/or problems. This approach has the potential of providing more precise and consistent security specifications. How- cvcr, Ting et al. [ 171 stress that URBS definition and analysis should be an integral part of the database design process, and not an activity that is dcferrcd until the system is implcmcntcd, when end-users begin to rcqucst access to the database.

The idea of user-roles has also been suggcstcd by others. Jensen [ 181 limits roles to the system sccur- ity officer (SSO) and the database administrator (DBA). Lochovsky and WOO [ 161 also SW the need to consider finer-graincd classifications of users, based on the roles they play in the organization. Howcvcr, they discuss user roles only in terms of an object-oriented DBMS.

Using the concept that a user can have certain roles, access to the database can bc spccificd using thcsc roles. Kolcs and data can then bc rcprcscntcd as objects which allow the DBMS to control and manage operations performed on the data, as well as the types of access to the data itself. Our research extends this idea in a relational database system. Before the model is prcscnted, however, a brief rcvicw of rcscarch into dynamic, or active, databases is nccdcd.

2.4 Active databases

Traditional databases arc passive in the scnsc that they do only what is explicitly rcqucsted in the user’s query operation [19, 201. The active database model allows a database to react in an intclligcnt way to an external input by executing database operations (tither user-defined or temporal) which arc required to prescrvc invariants associated with the database. Bckich [21 (p. 63)] d&m an active database (ADB) as “a database whose DBMS makes it possible for a user to specify actions that arc to proceed automatically without user intcrvcntion when certain situations appear”.

Critical to the implcmcntation of an ADB is the USC of alertcrs, triggers and events. For example, the alerter “Notify the inventory manager if the stock of any blood type falls below IO units” is triggered when the event (“below 10 units”) occurs. An alcrtcr is a program which monitors the database for a specific condition [IX?]. Triggers arc composed of a condition (an cvcnt) under which the trigger is cxecutcd and an action that is taken when the trigger fires. Triggers can bc simple, sensitive only to the individual tuplc being modified, or complex, monitoring the contents of several relations simul- tancously.

Triggers arc central to any active database and can bc traced back to the late 1970s [7]. Trigger functions, easily implctncnted by a rncchanism standard for ADBs, may bc rather cumbersornc to implcmcnt in a non-ADB [20, 211. Unfortunately, the structured query language (SQL) standard dots not

663


include alcrtcrs; hence triggers at the SQL level must be implcmcntcd in a subsystem [23].

Events activate a trigger and can bc dcfmcd as “a happening of interest” [7]. Events arc divided into three catcgorics:

l Rusic events arc those that each event spccifica- tion must support. For example, “cvcry n time periods” (temporal) or “immcdiatcly after a trans- action” (event driven).

l A lu~+~l cvcnt is a basic event qualified with a mask. The mask is a predicate used to hide or mask the occurrcncc of an cvcnt. If the event specification “large” is implcmcntcd as the function: &~t withdraw(sum:int) G Gsum > 1000, the logical event of “large” is more than 1000 with the mask sum > 1000.

l Composite events arc a combination of logical cvcnts. Unlike basic and logical events, which occur at specific points in time, a composite cvcnt is said to occur at the point of occurrcncc of the last logical event that was needed to make it happen. For cxamplc, if the combination of El and E2 rcprcscnts a composite cvcnt, and El occurs before E2, then the occurrence of E2 indicates the occurrence of the composite event.

Our model proposes to have user-roles dynami- cally change given the occurrcncc of certain cvcnts. In order to accomplish this, alertcrs and triggers must bc prcspccificd within the design of the security system. Hcncc, the need for the design

clcmcnt of a dynamic, user-role-based security system. To aid in clarity, the design of the dynamic user-role-based security model is prcscntcd in the context of the LVC cxamplc. Before turning to the specifics of the model, it is appropriate to further discuss the clinic cnvironmcnt.

has numerous groups of individuals with disparate rcsponsibilitics, c.g. clinicians, interns, technicians and volunteers. For instance, a clinician’s respon- sibilitics (as primary care provider) arc diffcrcnt from that of an intern (secondary cart provider and student) and should bc rcflcctcd in the privilcgcs that arc granted. In the LVC, a clinician, accom- panicd by an intern, performs an cxtcnsivc low vision examination to cxposc and quantify all hidden or visual impairments which contribute to the rcportcd disabilities 1241. As part of the asscss- mcnt, lcttcrs may be sent to the patient’s physician, parent, school and/or funding agcncics. It is intended that thcsc lcttcrs bc maintained in the LVC patient database. Before the lcttcr is disbursed, the intern is in an attending role and is allowed to update the lcttcr as required. After the lcttcr is distributed, the intern can no longer update the lcttcr but should bc allowed r-cad privileges, for cxamplc if follow-up statistics arc required. Because of this, the role of the intern changes with rcspcct to the particular lcttcr when the cvcnt “distribution” occurs.

In a relational database, such a cell lcvcl of security is not fcasiblc using currently implcmcntcd rcla- tional DBMS security technology. Specifically, rcla- tional I>BMSs can provide security up to the attribute lcvcl (i.c., an attribute can have cithcr read or write access) but do not allow read access in some cells and write access in others.

One possible solution is to provide the intern with two database accounts, one for update which can be used in the attending role and another with display privilcgcs to bc used in the statistician role. The problem with this solution is that interns can continue to update the lcttcr at a time when they should not bc allowed to (i.e. after the lcttcr has been distributed) by simply using the view with update privileges. As a result, control is not

3. Background of the low vision clinic and the security issue

achieved.

This type of security problem is common. For The low vision clinic (LVC) is an appropriate setting to illustrate user-role-based security since it

,I I I cxamplc, professors can read and write grades on all courses they arc currently teaching but should

664


bc allowed only to read the grades of courses taught in previous terms. The cvcnt that results in the change of privileges is the change of the term. 111 a manufacturing situation, production supcr- visors cntcring the production quantity for the current week would have read/write privilcgcs, but should have only read privilcgcs for data about production for previous weeks. The cvcnt in this cast is again a temporal one: the change of the week.

4. Design of dURBS

4.1 Architecture The overall URBS design model, with both the design and cxccution aspects, is shown in Fig. 1. It includes the steps that must bc taken by both the

application and security dcsigncrs in dcvcloping the user-role-based security rcquircmcnts for an application. The interactions bctwccn the application design, the URBS definition and the URI3S analysis arc both incrcmcntal and itcrativc. Appli- cation design conccntratcs on the specifics of the security need and trigger cvcnts for the particular application. UWS analysis cvaluatcs the rcquirc- mcnt of the application. Finally, the URBS formally dcfincs the user-roles and the cvcnt trig- gcrs. Once the dURBS has been complctcly d&cd, the next phase, that of implcmcntation, can commence.

Execution of the dUREKS begins with a user rcqucst, which is cvaluatcd by the dUKsS subsystem to verify authorization to access the data. The dynamic SQL module then adds the rclcvant

Design L .,.,,,,, x ,,,,,,,,,,,,, - ,ll,,lll.,,lll..,.,lll.~~ x 11,---11.-11-111...1111. “>

: Application ; Design

URBS Analysis

URBS Definition

$ 2

Execution

request , ._............... . . . . . . . . . . .

dURBS Subsystem Module

authorized / request

Dynamic SQL Module

i I 2

$

L ,,,..,.,,,,, _ ,,..,, __,XIX 111,,,,,.1^,

C

Data

f response

Fig. I. Ovcrvicw of dynamic UWS.

665


prcdicatc or condition to the initial query and transmits the modified SQL request to the DBMS. With the execution of the request, the dUKsS automatically evaluates whether the event has occurred. In our example, the event would bc the mailing of the letter by the LVC.

The strengths of the URBS approach arc realized when a user has more than one role in an application. There arc four possible combinations of users and roles: user-role (l-l), user -role (m-l), user - role (1 -WI), and user ++rolc (m-m). The l-l and m-1 relations can bc dealt with in conventional RDBMS environments. However, the l-m and m-m relationships arc cases not managed by the traditional view mechanisms. Specifically, these arc situations where a particular user has different roles in an application. Because an m-m relationship can bc converted into a scrics of 1 -WI relationships [23], WC shall conccntratc on the l-m case.

In our model, 1-m case control can be achicvcd. First, the URBS is redefined for the relational model. As part of the new definition, the application designer is rcquircd to identify both the attributes in an entity for which a user’s privilege changes and the cvcnts that cause the change. The entity-relationship model is then extended by making the idcntificd attributes into new entities (‘protected entities’). In the final step of this phase of dURBS, the cvcnts that change users’ privilcgcs arc amassed into specially dcsigncd security tables.

In specifying UKBS for the object-oriented design model, Ting et al. [ 171 and Dcmurjian et al. [5] USC

a user-role definition hierarchy (URDH) to prcscnt the diffcrcnt methods to diffcrcnt users. The UKDH has the capability of specifying the privilcgcs for each user on the basis of the roles hc or she can occupy in an application. The modified URDH dcmonstratcs the diffcrcnt views nccdcd by disparate users on the basis of their diffcrcnt roles. Our model combines the relational concept of a view and the programming language concept of an object to product a URDH. Furthcrmorc, the application dcsigncr will bc rcquircd to identify

both the attributes whose access privileges change and the events rcsponsiblc for triggering the changes.

In model dynamic user-roles (cell lcvcl security), the cvcnts that are rcsponsiblc for changing the roles must bc addressed. The roles should changc- ideally in an automatic manner-depending on the occurrence of some event. In our example, the distribution of a patient’s letter signals that an event has occurred and thcrc is an automatic modification of intern roles.

4.2 Defining user-role-based security

The user-role definition hierarchy (UKDH) [5] is mod&cd in dURBS to define the various views that arc needed by diffcrcnt users on the basis of their roles. The LVC example is not intcndcd to be a complctc characterization of all possible user types and user roles in the clinic hierarchy; rather, it is used to illustrate how such a UKDH may be d&cd.

Some additional definitions are necdcd for dUKsS design. A user-class is a group of users in an organization. A user-type is a person in a user-class who can have one or more user-roles. A user-r& is a specific job or function of a user-type within a user-class. User-privilqr refers to the type of data access (c.g. read, write or read/write) that is granted to a user-role on a particular datum item. A view, defined in relational database literature, is that part of the database that is seen by a particular user-type [25]. Finally, a no& is that part of a URDH that rcprescnts a particular user-class, uscr- type, user-role or user-privilcgc. Graphically, the relationship among the various levels is shown in Fig. 2.

4.3 User-role definition hierarchy

The UlU>H is used to establish and cnumcratc possible user-classes, user-types, user-roles and their associated user-privileges. The hierarchy cnablcs the security dcsigncr to group the diffcrcnt kinds of individuals who will rcquirc access privilcgcs to a given application. Marc importantly,

666

Computers & Security., Vol. 13, No. 8

User-Class

User-Type User-Type User-Type

User- Privilege

User-Role

User- Privilege

User-Role

User- Privilege

User-Role I

User- Privilege I

Fig. 2. URBRS user groups.

URDHs can bc used rcgardlcss of the application

bccausc, in any database application, thcrc arc groups of individuals who have rclatcd rcsponsi-

bilitics.

Figure 3 shows a simplified version of a URDH for the LVC and the relationships between the four diffcrcnt groups, namely user-class, user-type, user-role and user-privilcgc. User-roles arc allotted certain privilcgcs. Roles arc combined to form a user-type and types arc combined to form uscr- classes. A combination of all the user-classes yields the cntirc application architccturc.

By using gcncralization and specialization (a con- tainment relationship that exists bctwccn a highcr- lcvcl entity set and one or more lower-level entity sets), accurate views that satisfy a user’s needs can be generated. 0 n the one hand, gcncralization is used to cmphasizc the similarities among lower- lcvcl entity types and to hide their diffcrcnces. On the other hand, specialization has the ability to cmphasizc the distinction between high-level and lower-lcvcl entity sets [23, 251.

Using the process of specialization (top-down definition) and gcncralization (bottom-up dcfini- tion) the user-rglcs arc d&cd. From a top-down pcrspcctive thcrc arc two user-classes, Medical Staff and Support-Staff, and five user-types in the LVC: Clinician, Intern, Social Worker, Hi-Tech Tcch- nician, and Support. It can bc seen that most uscr- types have more than one role. For cxamplc, the user-roles for Clinician arc: Tcachcr, Medical Provider and Manager. Finally, the user-privileges arc specified.

4.4 Steps in dURBS design

The design phase of the dURBS method is composed of tight steps.

Step 1: Build initial URDH

The security system analyst should USC the application requirements obtained from the application designer to dctcrminc the user-class, user-types and user-roles in a top-down fashion (i.c., using the idea of specialization) to product the URDH. The application requircmcnts arc obtained during the analysis phase of a system development lift cycle.

667


User Classes

ISA -

User

Types Clinician

A IS A IS A IS A

User I\\ Roles

User Privileges Read all patient info.

Read/Write letters before ~bmitta!

Read letters after submittal

IS A IS A IS A IS A

I \ I I U Trainee-Advisor

Read all patient info.

Read/Write letters before correction

Read letters after submittal

Fig. 3. Low vision clinic UIWH (sitttplifkd version).

During this phase, the analyst should consider the system needs of the different dcpartmcnts (i.c. uscr- classes), the individual users within a department (i.c. user-types), and the diffcrcnt roles each user plays (i.c. user-roles) in an organization. Figure 3 shows the UKDH for the LVC.

Step 2: Develop node descriptions

Nodes in a UKDH arc used to indicate all uscr- classes, user-types, user-roles and user-privilcgcs. The notion of a node profile is used to assign the capabilities or the privileges granted to each node of the UKDH. It contains a node description and the privilcgcs both allowed and disallowed.

Using the UKDH dcvclopcd in step 1, product node descriptions for each node. In the LVC, cxamplc node descriptions arc:

IS A

IS A IS A

Volunteer-

l user-classes: {Medical-Staff, Support-Staff]

l user-types: {Clinician, Intern, Social Worker, Hi-Tech Technician, Support}

l user-roles: {Teacher, Medical Provider, Man- ager, Student, Trainee, Counscllor, Advisor, Volunteer, Security}

Step 3: Analyze node descriptions

From a strictly informational pcrspcctivc, the security dcsigncr can aggrcgatc or summarize the node descriptions for a chosen URDH node to cheek whcthcr the written descriptions correspond to his or her intcrprctation of the node’s rcsponsibilitics, and to update the node profiles if ncccssary [k, 51. The security dcsigncr can then USC this summary to verify that the hierarchy has been

668


correctly structured as rcflcctcd in the aggregate descriptions.

Each of these descriptions can be supplied while the security designer is creating the URDH with its roles, types and classes. They may bc r&cd and mod&cd as needed. This procedure (i.c. node description analysis) has been effected on the LVC data.

Step 4: Assign privileges

Once the URDH has been specified, the security dcsigncr assigns the privileges based on his or her understanding of the security requircmcnts to the user-roles. Figure 3 shows the privileges that arc assigned to the Medical Provider and Trainee. In the LVC example, the following privileges arc assigned to the Medical Provider: read all patient information; read and write patient letters before submittal; and read lcttcrs after they arc distributed.

As indicated, the actual users are at the user-type lcvcl. In order to provide the appropriate database view to a user, a mapping of all the user-roles to their appropriate user-type is needed. This mapping of user-roles to user-type provides the ability to assign views based on roles.

Step 5: Analyze privileges

Similarily, the security designer performs an analysis by obtaining a summary or aggregate of the privilege assignments to dctcct any conflicts and inconsistencies. When the privileges which have been granted to a URDH node are in conflict, the security designer must take action to resolve the identified problems. Such action may involve reassigning of access privileges.

Whenever node descriptions and privilege assignments arc updated, steps 3, 4 and 5 should be repeated to identify conflicts and correct problems. For example, if the user type is “intern” and the role is “Trainee”, then the corresponding user privileges are supplied: read all information about a patient; read and write letters to a patient before the

letters are distributed; and read only patient information after letters arc distributed. These descriptions show that the trainee role has varying privileges that arc triggered by the mailing of letters to patients (read/write bcforc letters arc senr, read only after).

Step 6: Verie consistency

Begin by dctcrmining the attributes or entities that would satisfy each of the user-role requircmcnts. Then, moving up the URDH to the type level, form the union of the roles to produce a user view. Similarly, at the class level, form the union of the user views to produce a class view. Finally, the union of the views of the class level is formed to establish the overall application view.

For example, a volunteer will have mad access on part of patient biographical information, security will have read access on appointment information, and support and support-staff will have read access on both patient biographical and appointment information. As a check for the view allocations, the designer can start with the application view and work downwards to the user-roles, producing sub- views to cnsurc consistency. This analysis (spcciali- zation and generalization) on the URDH provides feedback to the security designer for dctccting possible conflicts and inconsistencies in the views needed by users. Although the privilcgc assignments in the LVC include cmployec and budget information, WC will concern oursclvcs only with the clinical information.

Step 7: /den tify critical events

Bcforc proceeding, the following additional definitions arc needed: a “protcctcd-entity” E, is defined as a three tuplc (Entityname, {A}, F, T) whcrc Entitynamc uniquely idcntifics the protcctcd_- entity; A is the set of attributes which maps protcctcd-entities of the same type (a protcctcd_cntity set) into a domain; F is the status attribute which is used to lock and unlock the entity; and T is the trigger/cvcnt attribute.

669

I. Mohammed and DA4 DiMDesign for dynamic URN

A is defined as a set of unique attribute name and type pairs, where the type may bc primitive (e.g. intcgcr, float, character, etc.). F is defined as a status attribute for a unique A. T is defined as a trigger/ cvcnt attribute for a unique A and F. A locked attribute is an attribute that does not permit any further updates (e.g. F = “Locked”). An unlocked attribute is an attribute that permits update (c.g. F = “Unlocked”).

At this step, the cvcnts T that activate a change (unlocked -locked) in a status attribute F arc idcntiflcd. The cvcnts may bc incident-driven (“after event x lock the data”), temporal (“at time t lock the data”) or user-defined (“lock the data”). Triggers and events allow the system to proceed automatically without user intervention when certain situations appear. In our example, the cvcnt WC arc concerned with is the distribution of lcttcrs.

Step 8: Identify protected-entities

Develop the initial entity-relationship (ER) diagram and normalize all relations to at least the third normal form. The attributes whose access privileges change, based on the occurrence of each event from step 7, arc then identified. Make each of the above attributes a protected-entity and include a status attribute F and a triggcr/cvent attribute T in the relation table. In the LVC cxamplc, the ‘lcttcr’ attribute access privilege changes when a letter is distributed and is made into a protcctcd-entity.

4.5 Summary

To summarize, the tight steps in the design of a dURBS model arc:

l Step 1: Build initial URDH.

l Step 2: Dcvclop node descriptions.

l Step 3: Analyze node descriptions.

l Step 4: Assign privilcgcs.

l Step 5: Analyze privileges.

0 Step 6: Verify consistency.

l Step 7: Idcntifj events.

l Step 8: Identify protcctcd-entities.

By completing this methodology the security designer has prepared all the information necessary to implcmcnt dynamic, event-dcpcndcnt, uscr- role-based security. User-roles have been identified and verified, as have cvcnt triggers. And the application ER models have been mod&cd to allow for dynamic role changes. Even if a dURBS is not implemented, the steps provide security designers with a clear and consistent method of analyzing and understanding the roles and security needs of their users.

5. Conclusions

As database technology grows, it is important that database security technology should parallel this expansion. While MAC and DAC have served and will continue to scrvc as useful access control mechanisms, our research prcscnts user-role-based security as a framework for new and more flexible access control mechanisms to handle the varied and complex requircmcnts of many organizations.

In this rcscarch, WC have prcscntcd the rcquircmcnts, capabilities and functionalitics of dynamic, cvcnt-driven, user-role-based security. The goals of the research were to red&c and expand uscr- role-based security for the relational design model, and to include the active database capability of cvcnts-driven DB modification. The goals wcrc accompli&d by using a user-role definition hicr- archy (URDH) to identify user-classes, user-types, user-roles and user-privilcgcs. A node profile was then used to assign privileges to each node of the URDH, and a set of analysis techniques was prescntcd to understand, r&tie and fine-tune the URBS specifications. The analysis tcchniqucs used arc consistent with the relational model, its con-

670


ccpts and its principles, and have resulted in a succinct characterization of user-rolc-bascd security. The roles that change and the events that cause thcsc changes arc then analyzed and idcntificd as key components to bc used in the implcmcntation.

The use of dynamic user-role-based security has several potential important contributions to make. First, cxtcnding the URE3S concept to relational databases greatly incrcascs the number of databases which can use URBS. Second, by blending URBS and active database concepts, the dURsS maintains security under dynamic conditions. Finally, the model provides a procedure to ensure consistency in data security cvcn if the complctc dURsS model is ncvcr implcmcntcd.

References

[‘I

PI

PI

PI

I 51

[hl

PI

PI

Pl

T. Anderson, Saf; G Secure Computing Systems, Blackwell

Scientific Publications, Oxford and London, I Y8Y.

T.F. Lunt, Current issues iu statistical database security, in

C.E. Laudwehr and S. Jajodia (eds.), Database Security, V: Status and Prospects, North-Holland, 1992, pp. 381-385. T.F. Lunt, Security in database systems: a research pcr-

spectivc, Gmpul. &cur., 1 l(1) (1992) 4 l-50.

S.A. Dcmurjian, T.C. Ting and M.Y. Hu, An Analytical Framework fbr User-Role Based Security SpeciJi’cation in an Object-Oriented Des@ Model, Computer Science and

Engineering Department. University of Connecticut,

lYY2. S.A. Dernurjian, T.C. Ting and M.Y. Hu, A Sprc$cation Metllodolo~yy &r User-Role Based Security in an O&t- Orierrted Dcs<yn Model, Cotnputcr Science and Engineering

Departnmx, University of Connecticut, 1992.

T.C. Ting, A user-role based data security approach, in C.

Landwchr (ed.), Database Security: Status and Prospects, North-Hollaud, I Y87.

N.H. Gchani, H.V. Jagadisha and 0. Shmucli, Event Specij- cation in an Active Object-Oriented Database, AT&T Bell Laboratories, Murray Hill, NJ, 1992.

Denning et a/., Views for rnultilevcl database security, Pm.

IEEE Symposium on Security and Privacy, 1986. K. Dirtrich, M. Hartig and H. Pfcffcrle, Discretionary

1’11

1’21

[‘31

1’41

1’51

114

1171

1’81

[“)I

PI

12’1

PI

P31

PI

PI

access control in structurally object-oriented systems, in D. Spooncr and C. Landwchr (cds.), Database Security, 111: Status and I’rospects, North-Holland, 1 YXY. D.E. Bell aud L.J. LaPadula, Secure computer systems:

unified expositions and rnultics interpretation, Technical

Report ESD-TR-75-306, The Mitrc Corp., Bedford, MA,

March 1 Y76. F.A. Manola, A personal view of DBMS security, iu

C. Landwchr (ed.), Database Security: Status and Prospects, North-Holland, 1 Y87.

I.M. Olson and M.D. Abranls, Computer access control

policy choices, Comput. &cur., Y(8) (1 YYO) OYY-7 14.

G. Steinke, Design aspects of access control in a know-

lcdgc base system, Comput. Secur., 10(7) (1991) 612-025.

T.F. Luut and ES. Fernandcz, Database security, SIG-

MOD Rec., lY(4) (Dec. IYYO).

E.B. Fernandez, R.C. Summers and C. Wood, Database Security and Integrity, Addison-Wesley, 1Y81.

F.H. Lochovsky and CC. Woo, Role-based security in

database management systems, in C. Landwehr (cd.), Data- base Security: Status and Prospects, North-Holland, 1987. T.C. Ting, S.A. Detnurjian and M.Y. Hu, Requirerncnts,

capabilities aud functionalitics of user-r& based security

for au object-oriented dcsigu model, in C. Laudwehr and

S. Jajodia (cds.), Database Security, V: Status and Prospects, North-Holland, 1992, pp. 27552Yh.

N.R. Jcnscn, System security officer functions in the Al

secure DBMS, in C. Landwehr (cd.), Database Security, II: Status and Prospects, North-Holland, 1988. G.M. Lohaman, B. Lindsay, H. Pirahesh and B.K. Schicfcr,

Extensions to Starburst: objects, types, functions, and

rules, Commun.ACM, 34(1(I) (Oct. lY91) 94-109.

D.R. McCarthy, The architecture of an active database

management system, in Proceedings of‘ACM SICMOD ‘89, Portland, OR, May 198Y, pp. 2 15-224.

Z. Bekich, Active databases: an analytical survey, Pro- ~ramminX and Computer Sofrware (English translation of

Pro~qrammirovanie), 16(5) (July 199 1) 202-208.

P.O. Buncman aud E.K. Clctnons, Effcicutly monitoriug

relational databases, ACM Z’rans. Database Systems, 4(3) (Sept. 1979) 368-382. H.F. Korth and A. Silberschatz, Database System Concepts, McGraw-Hill Cotnputcr Scicucc Scrics, USA, 1 YY 1.

G.J. Strong, R.J. Pact and AD. Plotkin, Low vision

services: a model for sequential intervention and rehabili- tation, Can. J. Pub/it Health, 79 (May/June 1988) S50-S54.

C.J. Date, An Introduction to Database Systems, Vol. I, Addison-Wesley, CA, 1900.

671

design for dynamic user-role-based security

Documents