1

Current Trends in Database Technology andTheir Impact on Security Concepts

Klaus R. Dittrich and Dirk Jonscher

Institut für Informatik, Universität Zürich, Winterthurerstr. 190, CH-8057 Zürich{dittrich,jonscher}@ifi.unizh.ch

Abstract

Research and development in the area of database technology during the past decade is characte-rised by the striving for better support for applications beyond the traditional world, where pri-marily high volumes of simply structured data had to be processed efficiently. As a result, fu-ture DBMS will include more functionality, and explicitly cover more real world semantics (invarious forms) that otherwise would have to be included in applications themselves.

Advanced database technology, however, is in a sense ambivalent. While it provides newand much-needed solutions in many important areas, these same solutions often require thor-ough consideration in order to avoid the introduction of new problems. One such area is data-base security.

In this paper, we consider three prominent areas of nonstandard database technology: ob-ject-oriented, active and federated database management systems. In particular, we show whichtypical security problems (with the focus on access control) have to be solved for these sys-tems. We also give some examples how, on the other hand, these kinds of DBMS and their un-derlying mechanisms, respectively, can beneficially be used to solve security problems. Fur-ther, we discuss the issue of secure design and construction of (special purpose) database man-agement systems in this context.

Keyword Codes: K.6.5; H.2.7; H.2.5Keywords: Management of Computing and Information Systems, Security and Protec-

tion; Database Management, Database Administration; Heterogeneous Data-bases

1. Introduction

Since the beginning of the eighties, a large part of research and development in the area of data-base management systems (DBMS) is being devoted to the issue of extending their functionali-ty. The general goal behind these efforts is to provide advanced data and information manage-ment services efficiently within standard software, thus avoiding the need for their repeated de-sign and incorporation into individual application programs. The basis of all such approaches is– compared with traditional (e.g. relational) systems – a more comprehensive and precise repre-sentation of real world semantics within the database system itself. In consequence, new gener-

2

ation DBMS are about to make database technology amenable to a much broader range of appli-cations than traditional products do.

However, this "greedy" expansion of database functionality makes it harder to define preci-sely what database technology is supposed to be. According to the nature of this paper, we willstick to a rather general definition:

Database technology covers all concepts, methods, tools and systems for the persis-tent, secure and application-independent management, and comfortable as well as flex-ible usage of large, integrated multi-user databases.

In the following, we will explain this definition in more detail.

– Persistent management of data means that the lifetime of data is independent from the life-time of the process that has created them.

– Secure management of data is the main advantage of database systems compared to file sys-tems. DBMS guarantee the consistency of data, even if they are concurrently accessed(transaction concepts). They support the integrity of data with respect to the real-world con-cepts represented by these data, implement recovery mechanisms to cope with system fail-ures, and control the access of applications to data. In other words, DBMS contribute tohigh quality data management.

– Application-independent management of data means that the DBMS implements its owndata model, allowing access to its data only via well-defined interfaces. Some of the data se-mantics is thus known to the DBMS, and no longer hidden in applications. Usually, thelogical representation of data is independent from their physical representation. Hence, ap-plications need not bother about physical reorganisations of the database. External schemaseven allow for protecting applications from modifications of the logical data organisation.This property is called data independence, simplifying the maintenance of applications.

– Furthermore, DBMS also provide for abstract high level interfaces supporting ad-hocqueries.

Database research fosters database technology in several directions. Besides improving theperformance of DBMS functionality already being available, the scope of research is broadenedto incorporate new concepts into database systems. In this paper we cannot consider the wholearea of new research directions like semantic data models, new transaction concepts, kernel ar-chitectures for database systems, database federations, expert system/database system coupling,knowledge base systems, active, deductive, extensible, heterogeneous, intelligent, multimedia,multiprocessor, object-oriented or parallel database systems, etc. According to our own compe-tence, and the importance of those systems for the market, we will look at three prominent ex-amples (without claiming to give a complete survey), namely object-oriented, active and feder-ated DBMS.

From the viewpoint of security, advanced DBMS concepts present both, new opportunitiesand new challenges. We will discuss the issues in both directions, focusing mainly on accesscontrol, and sketch some existing approaches.

The remainder of this paper is organised as follows. At first, we introduce a simple classifi-cation of access control concepts as a basis for subsequent sections. Afterwards, we discusssecurity issues for object-oriented (Section 3), active (Section 4) and federated DBMS (Section5). In Section 6, we look at the construction of DBMS. Design issues in the context of securityare briefly considered in Section 7, and the conclusions are drawn in Section 8.

3

2. Access Control Concepts 1

Database security deals with all issues to guarantee the confidentiality, integrity and availabilityof data stored within database systems. Access control, as a major aspect of database security,aims at ensuring confidentiality (the protection from unauthorised disclosure) and up to a degreealso integrity2 (the protection from unauthorised modification) of data.

Access rights are used to allow or forbid subjects (the active entities of a system, i.e. pro-cesses running on behalf of users) to execute a particular action (or operation) on a protectionobject (the assets to be protected from unauthorised accesses, e.g. relations, types or classes,tuples or objects, attributes, etc.). Access control comprises all system mechanisms that are re-quired to check whether a request, issued by a particular subject, is allowed or not, and allmechanisms that are required to enforce the corresponding decision. It is based on a chosenpolicy (a set of rules as authoritative regulations or directions determining what should be pro-tected using which principles). The same mechanisms can be used to enforce different policies,and the same policy can be enforced by different mechanisms.

The two main approaches to realise access control can be distinguished depending on howaccess rights are specified and enforced /Denn 82/.

Discretionary access control (DAC) is based on subject and protection object identities. Ac-cess rights are explicitly granted. An access right can be represented as a tuple (only the firstthree components are mandatory)

(grantee, protection object, action, kind of right, grantor, grant option)

indicating that the grantee3 is allowed (permission) or forbidden (prohibition) to execute theaction on the protection object. The grantor is the user who has granted that access right. Ifgrant option is set and the access right is a permission, the grantee is allowed to pass on that ac-cess right to other subjects.

This kind of access control is often combined with an ownership paradigm, where eachprotection object has an owner (a user) who is responsible for granting and revoking accessrights concerning this object. Since this happens at her discretion, the policy is called "discre-tionary". However, the same discretionary mechanisms can be combined with an administra-tion paradigm, where only the security administrator is allowed to grant and revoke accessrights. In this case, the policy is mandatory.

Depending on the access rights that can be granted, several kinds of discretionary systemscan be distinguished:

– positive systems:only permissions can be granted– negative systems:only prohibitions can be granted– mixed systems: permissions as well as prohibitions can be granted (in this case, a policy

to solve conflicts is required)

Usually, the authorisation base (the set of explicitly granted access rights) is not complete,i.e. there are some requests where neither a permission nor a prohibition applies. Hence, a clos-ure assumption is necessary:

1 This section is a revised version of the introduction in /JoDi 94/.2 Such an understanding of integrity must not be mismatched with semantic integrity of data (the correct rep-

resentation of real world concepts by the corresponding data within the database).3 The grantee usually is a particular user, a group of users, or a role. Roles are abstract users describing the

functional, organisational or social position of concrete users within the universe of discourse. Concreteusers can play a role. This way, users dispose of the rights that are granted to the corresponding role.

4

– closed world assumption:a request is forbidden unless an appropriate permission exists orcan be inferred

– open world assumption: a request is allowed unless an appropriate prohibition exists orcan be inferred

Meaningful combinations are:

– positive/mixed system with the closed world assumption– negative/mixed system with the open world assumption

Mandatory access control (MAC) policies were developed to enforce organisation-wide se-curity policies automatically. The most popular one is multilevel security (MLS) based on themodel of Bell and LaPadula /BeLa 75/. Multilevel security does not rely on explicitly grantedaccess rights; instead access decisions depend on so-called security classes (or labels) that areassociated with subjects (clearance levels) and protection objects (confidentiality levels). Securi-ty classes are organised as partial ordered sets. The main property of those models is that datanever flows from higher to lower security classes (unless the initiating subject is "trustwor-thy"). Thus, this model is inherently unidirectional with respect to data flows. The two mainrules for MLS systems are the following:

– simple property:A subject is allowed to read a data item if its clearance level dominates theconfidentiality level of the data item.

– *-property: A subject is permitted to write into a data item if its clearance level is domi-nated by the confidentiality level of the data item.4

In recent years, "nonstandard" policies have been proposed, which have some practical rele-vance outside the military world (for which MAC was originally conceived). The most impor-tant ones are the Clark/Wilson model /ClWi 87/ and the Brewer/Nash model /BrNa 89/ (Chi-nese Walls).

A more comprehensive classification of access control policies can be found in /Sand 90/.

3. Object-Oriented DBMS

3.1. Characterisation

An object-oriented DBMS is a database management systems implementing an object-oriented data model at the logical level.

Object-orientation suggests that the universe of discourse is modelled as a collection of co-operating, interrelated and distinguishable units, called objects, which are instances of types (orclasses) that are organised in type hierarchies supporting inheritance /Atki 89/. An object has anidentity independent of its value, and is an abstraction unit characterised by a state (its - usuallystructured - value) and behaviour (the requests an object is able to answer). Usually, objects areencapsulated, i.e. the state can only be observed and modified via a well-defined interface. Thisway, information hiding is ensured; other objects only see the behaviour of an object, whereasthe state is hidden (although there are systems supporting weaker forms of encapsulation).

Further, it is possible to define associations (interrelations) between objects, in particularso-called complex object relationships. Such a relationship is not only a pointer that can be used

4 In the database context, very often the restricted *-property is applied: A subject is permitted to write into adata item if its clearance level is equal to the confidentiality level of the data item.

5

for "pointer chasing", but also influences the semantics of operations. Complex object relation-ships allow for treating sets of objects, being declared as one complex object, as a single unit,i.e. operators applied to an object are propagated to all component objects, too.

Finally, object-oriented DBMS (as any DBMS) provide for schema information about thestructure of objects, and support collections of similar objects, i.e. they provide for a type (orclass) concept. Types, including the operations, can also be defined by users. Super-/subtyperelationships between these types are used to inherit properties from super- to subtypes, sup-porting the reuse of structure and code. Polymorphism, i.e. the ability to send the same requestto objects of different types (and getting a semantically meaningful answer), is implemented byoverriding, overloading and late binding.

Optionally, object-oriented DBMS support features like object versions and query lan-guages.

3.2. Security Issues

Access control for database systems obviously has to reflect the data units handled by the re-spective data model. Hence, known database access control features at least have to be adjustedto the notion of "object", i.e. the unit of access control - the protection object - has to coincidewith (complex) objects of the data model.

It has turned out that this is not that easy as might seem at first glance, particularly due toobject structures and their variety of semantics. Furthermore, if in DAC systems an ownershipapproach is applied, components of a single complex object may have different owners. Sharedcomponents cause additional problems to ensure a consistent authorisation state.

In MLS systems, the complexity of the arising problems depends on whether single-level ormulti-level objects are supported. In both cases, restrictions have to be identified that must beimposed upon complex object relationships5 (including the propagation of operators, in particu-lar the delete operator) according to the MLS rules without introducing covert channels.

Since access control mechanisms have to comply with the logical data model of the DBMS,encapsulation requires that access control is based on the actions of the data model, i.e. onmethods (and not on lower level read or write operations). Depending on how strict the encap-sulation principle is enforced within a concrete DBMS, basic access operations (like reading orwriting an attribute) have to be considered, too.

Encapsulation and a method-based authorisation imply the lack of generic access rights inDAC systems. In a relational DBMS, only select-, insert-, delete- and update-rights can bespecified for "basic accesses" to relations. It is thus easy to specify generic rights for sets ofprotection objects. In object-oriented systems, however, it is simply by chance (or due to in-tended polymorphism) that a right to execute method XYZ on type A makes also sense for typeB (with the exception of generic operators like copying or deleting an object). Access rights aretherefore type-specific, and additional concepts are required to define more abstract accessrights (e.g. for whole domains of protection objects). Moreover, it is conceivable that there aretypes providing for hundreds of methods. In this case, authorisation becomes a very cumber-some issue if rights can only be granted for individual methods. In order to support security ad-ministration, additional abstraction concepts are required.

The access control concept must fit to the inheritance paradigm. It would not be meaning-ful if the data model supports inheritance of structure and code, but the access control mecha-nisms require explicit authorisations for inherited methods (or do even prevent inheritance).This problem appears in both areas, DAC and MLS. In case of discretionary mechanisms,

5 Multilevel objects can be modelled as a complex object consisting of single-level components.

6

ownership restrictions may contradict inheritance (if two types in a super-/subtype-relationshiphave different owners). In MLS systems, constraints have to be imposed upon the classificationof sub- and supertypes, as well as upon their instances. This problem is very complicated, evenmore since there is not the inheritance paradigm. Several different kinds of inheritance can bedistinguished along a variety of dimensions:

– single vs. multiple inheritance– strict vs. default inheritance /MaMM 91/– inclusion, specialisation, substitution or constraint inheritance /Atki 89/– selective inheritance /MaMM 91/– type vs. object inheritance6

Additional problems are caused due to the lack of a powerful view concept for object-ori-ented DBMS (this is still a research issue; see /AbBo 91, Bert 92b, Daya 89, HeZd 90, Rund92, ScLT 91, ShSw 89, Wied 86/). Hence, value-based authorisations - if required - have to beenforced by the security mechanisms, and cannot be based on "ordinary" database mechanisms.

Polymorphism, in particular overloading, has interesting relationships with authorisation.Depending on the order between both tasks (binding and access control), the result may be dif-ferent /Ahad 92/.

On the other hand, if we can model the real world more precisely by using object-orienta-tion, we should also be able to fine-tune access control rules much better than otherwise. Inparticular, we can now much more exactly differentiate between the object operations to be al-lowed or denied for individual users, as those may carry much more real world semantics thanmere "read", "write" and similar ones. It is also possible to tailor methods to particular groupsof users. Moreover, encapsulation supports the integrity of data. Users cannot arbitrarily writeinto a data item, but have to use predefined methods. It is rather easy to integrate integritychecks into a method compared to enforcing such restrictions within the code of each applica-tion accessing the data. Note, however, that this does not mean that explicit integrity mecha-nisms (based on integrity definition languages, and perhaps enforced using active mechanisms)are no longer required in object-oriented DBMS.

Further, polymorphism can be exploited to adjust authorisation policies. In particular, it isalso possible to override generic methods like grant and revoke. Depending on the concernedprotection object, or even on who wants to execute these methods, they may behave differently,enforcing the appropriate policy for the object and user in question.

Analogously, constructors can be overridden, e.g. to attach the appropriate owner to a new-ly created object in DAC systems. This way, it is possible, e.g., to associate newly created ob-jects with "system" in a production environment (to enforce an administration paradigm), orwith the user who has created the object in a development environment (to enforce an owner-ship paradigm), even if both environments are integrated into a single system.

3.3. Existing Approaches

There already are too many papers on access control for object-oriented DBMS to give an over-view here. Consequently, we only provide for references in this section.

A lot of work has been done to develop - in parts very elaborate - DAC concepts for object-oriented database systems (/Ahad 92, BeOS 94, Bert 92a, Brüg 92, FaSp 91, FeGS 89, FeWF94, GaGF 93, GuSF 91, HuDT 94, JoDi 93b, LGSF 90, NyOs 92, NyOs 93, PfHD 88,

6 "Object inheritance" /Bane 87, KiBG 89/ still is somewhat esoteric, and means that values are inherited be-tween objects. As an example, a property of an object (like the colour of a car) can be inherited by its com-ponent objects (the colour of the doors, the wings, etc.). It is also possible to override such values.

7

RaWK 88, RBKW 91, Spoo 88, TiDH 92b, TiDH 92a, HuDT 93/). Some of these conceptshave been implemented in ITASCA (the commercial version of the ORION prototypes) andHP's Open OODBMS (based on the IRIS concepts). However, most of the systems which arenow on the market (like ObjectStore or ONTOS) do not provide for any access control mecha-nism at all beyond the operating system's mechanisms, which are (at best!) inappropriate fordatabase systems.

Some issues that are in our opinion still not completely solved concerning DAC (not even in/JoDi 93b/), are the incorporation of weaker forms of encapsulation into the security concepts,and the reconciliation of ownership on the one hand, and complex objects or inheritance on theother.

The situation is similar in the MLS area. Examples for existing approaches include /JaKo90, JaKS 92, KeTT 89, KeTs 90, Lunt 90, Lunt 92, MiLu 92, Morg 91, RWHT 94, SaTJ 92,ThSa 93, Thur 89, Thur 92/. It seems that the conceptual security aspects are somewhat easierhere compared to DAC concepts (as usual for level-based systems). However, appropriate ar-chitectures and protocols (e.g. for object deletion) to prevent covert channels are still under con-sideration /BeMJ 94/. A first attempt to incorporate MLS into a commercial object-orientedDBMS is presented in /SaWa 94/.

A good overview of both research directions is given in /BeJS 93/ (although focusing on themessage-filter approach /JaKo 90/ and the ORION concept /RBKW 91/ and its extensions /Bert92a/). A preliminary attempt to adapt the Clark/Wilson model for object-oriented DBMS is pre-sented in /Hern 94/. Additional ideas on how dedicated methods can be used to support accesscontrol can be found in /Ahad 92/.

4. Active DBMS

4.1. Characterisation

Active mechanisms are another promising concept that is now being integrated into commercialsystems (e.g. Sybase and Oracle 7). Whereas (classical) passive DBMS only react to user re-quests, active DBMS include a monitoring facility, allowing an automatic reaction of the systemin case of well-defined situations (see Fig. 1).

Active DBMS allow – beyond providing all regular DBMS-features – the recognitionof user-defined situations in the database, and the execution of user-defined reactionswhen such a situation occurs.

The most popular specification paradigm for active DBMS are so-called event/condition/ac-tion rules (ECA-rules) /Chak 89/

ON <event> IF <condition> DO <action>

which can be defined in addition to the regular database schema. When an event is detected bythe system, the condition is checked on the database and if it holds, the specified action is exe-cuted. The combination of an event and a condition specifies the situation when the rule has tobe fired.

Many details have to be considered in such systems, including, e.g., the kinds of events,conditions and actions that are supported. In particular, the power of active DBMS is highly de-pendent on the event model, which may include the occurrence of database operations (accessesto data, or transaction events), but also externally raised events, time events, and various com-binations thereof. In many research prototypes (e.g. HiPAC /Chak 89/, Ode /GeJS 92/, SA-

8

MOS /GaDi 94/ or Sentinel /CKAK 94/) so-called complex events can be specified, which areiteratively built from basic events, using predefined constructors like sequence, conjunction,disjunction, closure or even the negation of events ("non-occurrences" of situations).

schema

operations results

schema

operations

ECA-rules

events

results

actionsDBMS DBMS

facts ECA-rules

Figure 1: Passive vs. active DBMS

Furthermore, rule processing has to be incorporated into transaction processing. Nestedtransactions /Moss 81/ (which are now also available in some commercial database systems,e.g. ObjectStore) have proven to be a viable concept for integrating both technologies into a co-herent system. Usually, it is possible to specify coupling modes to declare when a fired ruleshould be executed /Chak 89/:

– immediate mode: The triggering transaction is suspended until the fired rule has been fin-ished (including rules which are transitively fired). Each rule is executed within a subtrans-action of its own.

– deferred mode: The triggering transaction is not suspended, but is completely executed untilit reaches its commit point. All rules which are fired by this transaction are queued and notexecuted before the triggering transaction is ready to commit. At this "precommit point", allfired rules are executed (in subtransactions of their own) and if they have successfully beenfinished, the triggering transaction is committed.

– decoupled mode: The fired rules should neither interrupt the triggering transaction nor bedelayed until this transaction reaches its commit point. In this case, rules are processed intop-level transactions of their own, which are concurrently scheduled as any other transac-tion within the system.

4.2. Security Issues

Obviously, active rules and their execution have to be subject to security, too. Two aspectshave to be taken into consideration. On the one hand, rules as elements of the database are pro-tection objects. It thus has to be determined who is permitted to define, modify, enable/disableor delete a rule, as well as to query the set of defined rules. This is a rather simple question, be-cause rules can be represented as "ordinary" database objects. Hence, the usual mechanisms ofa DBMS can be used to restrict which user can access a rule.

9

On the other hand, if a rule is fired, it issues several accesses (during the evaluation of thecondition and the execution of the action) which have to be checked by the access control sys-tem. The problem arises which access rights should be used to evaluate the accesses issued bya rule. Three solutions are possible (and combinations thereof):

1. A rule inherits the access rights/clearance level from the subject that has defined the rule.

2. The rule inherits the access rights/clearance level from the subject that has fired the rule.

3. A rule is a subject of its own, and access rights can thus be granted/revoked to/from the rule(or a clearance level can be associated with a rule) as for any other subject within the sys-tem.

The second approach is rather odd considering that rules are usually used for change propa-gation (to enforce integrity constraints), for monitoring purposes, etc. Usually, the subject,having fired the rule, will not even notice that it has done so. Thus, it will usually not have theaccess rights/clearance level required to execute the rule successfully.

The first solution so far is the prevailing one. However, it also has several disadvantages, inparticular in DAC environments. If rules are used for change propagation, it is necessary togive the user who has defined the rule the rights to access the affected objects arbitrarily, al-though only a very restricted (and well-defined) access via the rule would be required. There-fore, we firmly recommend the third solution, which is in our opinion not only the most power-ful but also the most natural one.

All three schemes require considerable extensions of existing access control concepts.Moreover, the tight connection of rule and transaction processing has to be kept in mind. Sup-posing, e.g., the coupling mode "immediate" is applied, and a rule does not have the rights ofthe triggering subject. In this case, the transaction needs to be executed in a different securitycontext (in MLS systems, it has to change its clearance level, and in DAC systems, it needs toget a new access control identifier). Even more important, it has to be ensured that the originalcontext is restored if the rule processing is finished, and the transaction resumes. It obviouslyhas to be investigated which coupling modes are tolerable in MLS systems if a rule has to beprocessed at a higher level than the triggering transaction. In case of the coupling mode "im-mediate", e.g., it would be necessary to decrease the level of the process executing the transac-tion when the rule processing is finished, which contradicts the usual MLS philosophy.

Another important question is which events are visible to a rule in MLS systems. Event oc-currences may be triggered by transactions running at higher (or incompatible) levels than theclassification of a rule being defined based on this event. None of the existing approaches forcomplex event detection takes this issue into account.

In DAC systems the question arises how rules can be combined with a role concept. Thisproblem occurs if rules are executed with the access rights of the user who has defined the rule(and the system supports a role concept, where roles can be activated and deactivated). If therule is fired, the defining user may not be logged on, and thus would not have activated a role.7

The problem gets even worse if activation conflict relationships between roles can be defined/JoMD 94/. This precludes the simple assumption that all potential roles have been activated bythe user who has defined the rule. Obviously, the problem does not occur if rules are authorisa-tion units of their own.

On the other hand, ECA-rules also allow for the flexible and dynamic specification of rathersophisticated security policies, either by direct use or by acting as a target mechanism for somesort of security specification language. In the following, we give three examples:

7 This is the reason why access rights granted to roles never apply for triggers in Oracle 7 (according to a hintof Amit Jasuja who has been involved in the implementation of the Oracle access control mechanisms).

10

– Rules allow for implementing so-called deontic rights /Jons 93/ (or normative rights). Suchrights are used to model situations where the execution of an action is not only permitted,but even mandatory in order to ensure a smooth operation of an organisation, and the actionrequires human interaction. Such a "duty" is specified by a situation that triggers the duty,an action that has to be executed to fulfil the duty, and a second situation (the so-called "an-nulling situation"), determining when the duty has to be fulfilled relatively to the triggeringsituation. A rule can be used to monitor the fulfilment of a duty. In case that the user doesnot obey his duty (a sequence of the triggering situation and the annulling situation, wherebetween both situations the action has not successfully been executed), an automatically ex-ecutable contingency action can be fired.

– The Brewer/Nash model /BrNa 89/ can be implemented using rules. At the very beginning,a user is permitted to access all data in the system. Depending on her access behaviour,rights to access data from conflict-of-interest domains can selectively be revoked (or over-ridden by prohibitions). This requires, of course, that conflict-of-interest domains havebeen defined. Rules monitor accesses to data in these domains, and revoke access rightsconcerning their other (still non-accessed) elements.8

– Several applications (in particular if billing of the accessing user is necessary) require that anaccess right can only be used for a predefined number of times. Once the specified numberof accesses has been done, the access right should be "consumed". Such rights can be re-alised by granting "ordinary" rights to the corresponding user, and defining a monitoringrule, counting the number of successful accesses (based on a corresponding complex event,or a counter), and revoking the access right if the threshold value has been reached.

4.3. Existing Approaches

In the context of DAC systems, very little has been done so far. The approach of Oracle 7 isquite simple. System privileges are required to define rules (called triggers in case of Oracle:"create trigger" to define rules for own relations, "create any trigger" as a wildcard for definingrules for any relation within the system). The user who has defined a rule becomes its owner.Only the owner (or a user having the "alter any trigger"/"drop any trigger" system privilege) canmodify/delete a rule. It is not possible to grant access rights concerning rules to other users. Anexception concerns the enabling/disabling of rules, because this is also possible for users hav-ing the "alter table" privilege for the relation the rule is attached to. Rules are always executedusing the access rights which were directly granted to the owner.

The Starburst mechanisms /WiCL 91/ are a bit more elaborated. There is an explicit "con-trol"-right for relations which allows for authorisations concerning this relation (which usuallyis only in the possession of the owner). In order to create a rule, "attach"- and "read"-rights arerequired for the relation the rule should be attached to. Having a "control"-right for the rule, oran "attach"- as well as a "control"-right for the relation allows for deleting a rule. Modifying arule requires an explicit "alter"-right for the rule itself (but not for the relation). Analogously,explicit "activate/deactivate"-rights are required to enable/disable a rule. Similar to Oracle, a rulealways has the access rights of its owner.

Much more has been done in the MLS area. In /SmWi 92a/ and /Smit 92/, a successful com-bination of the active data model (of Starburst) with MLS has been found, addressing questionslike which events are visible to a rule. These concepts have been extended in /Smit 94/ to con-sider the integration of multi-level secure rules into a transaction paradigm.

8 Another (and even simpler) implementation of Chinese Walls using MLS concepts is given in /Sand 93/.

11

5. Federated DBMS

5.1. Characterisation

Another very active area of database research is the integration of existing "information islands"into coherent systems. Since legacy applications have to be preserved (in most cases, it is eco-nomically infeasible to re-code them for using a new system), very particular requirements haveto be met. Database federations are considered as being a promising approach for solving thearising problems.

A federated DBMS (FDBMS) provides for the interoperation of (probably heteroge-neous) component DBMS (CDBMS) under one "common roof", by preserving localautonomy.

The architecture of an FDBMS is shown in Figure 2. Note that the FDBMS has its own datamodel (possibly different from any data model used by the involved CDBMS). It may also haveits own database. Autonomy means that CDBMS retain a separate and independent control overtheir data, even if they join a federation. In a sense, the FDBMS is an "ordinary" applicationfrom the local systems' point of view.

AP

“integration layer”

application programs

FDBMS

CDBMS

component databases havingdifferent data models (DM)

DBMS1 DBMS2

DM1 DM2 DM int

Figure 2: Architecture of a database federation

The FDBMS provides a uniform interface to global users, ensures location transparency,hides heterogeneity, and offers the usual DBMS functionality (like transaction processing,query languages, etc.). In particular, it has to care for the mapping between the global and thelocal data models. There are several ways to achieve this. One possibility is to apply the 5-levelschema architecture /ShLa 90/, where export schemas of component systems are translated intogeneric schemas according to the global data model. Afterwards, the generic schemas are inte-grated into the global schema of the FDBMS. A simpler, and currently more practical approach,if heterogeneous CDBMS have to be integrated, is based on object-oriented technologies. Glob-al types are presented to global users, and the integration of component systems is buried

12

("hard-wired") within the code of global methods /HäDi 92/ (operational integration). In eithercase, integration is a tedious job.

FDBMS may also help to allow the introduction of, e.g., an object-oriented DBMS into anenvironment where a more traditional DBMS already is in use, and where both kinds of sys-tems have to interoperate.

5.2. Security Issues 9

Since database federations are special cases of interoperable systems connected by a network,network security issues have to be taken into consideration (for tightly coupled as well as forloosely coupled federations /ShLa 90/). Database federations need strong and reliable mecha-nisms to identify and authenticate remote users (including mutual authentication and continuousauthentication), as well as to encrypt sensitive data which are transmitted between the FDBMSand CDBMS. This does not mean that the required mechanisms have to be implemented by theFDBMS itself. It is also possible to apply security services offered by the network or by spe-cialised systems like Kerberos. A typical aspect, however, is that access rights may depend onthe kind of connection of the user requesting the data (local, remote, dial-up, etc.).

. . .

. . .

FDBMS

RM

RM Reference Monitor(/Ande 72/)user access

CDBMS

RM

CDBMS

RM

Figure 3: Reference monitor architecture for FDBMS

Most of the additional security problems only arise for tightly coupled systems, providingfor a global integration layer and a global authority to enforce a global security policy. Globalaccess control is enforced by an independent reference monitor that is integrated into theFDBMS and has to cooperate with local reference monitors (two-level access control, see Fig.3). An access control system at the global layer is essential due to several reasons:

– Integrated systems aggravate security problems. This is quite obvious in case of personaldata. The more data are available about humans, the better they have to be protected againstmisuse.

– Several new protection objects "emerge" at the global layer, e.g. global relationships be-tween data of different component systems (in particular aggregated data). Their proper pro-

9 More detailed descriptions of our view of the security issues in database federations have been published in/JoDi 93a/ and /JoDi 94/.

13

tection can only be ensured by the FDBMS, since no component system alone is aware ofthese protection objects.

– The FDBMS usually has a storage area of its own. At least data which are stored there haveto be protected by global mechanisms.

The problems we are faced with mainly stem from the heterogeneity and autonomy ofCDBMS. The FDBMS has to cope with heterogeneous local security policies and mechanisms(besides heterogeneity with respect to data models, semantic heterogeneity, different query lan-guages, different transaction mechanisms, etc.). Consequently, the FDBMS needs at least tounderstand the local concepts in order to cooperate with the local systems in a meaningful way.

In case of MAC systems, the following problems can arise:

– Local systems use different security classes (semantic differences).

– Local systems may have defined different partial orderings between their security classes.Some systems may even only support total orderings.

– Different classification granules may be supported (single-level vs. multi-level protectionobjects; e.g. tuple classification vs. attribute classification).

– Different security policies may be applied (support for polyinstantiation with different op-erational semantics (/LuHs 90, JaSa 90, SmWi 92b/), support for trusted subjects or dy-namic changes of a process' clearance level, etc.).

MLS systems can only be used in practice if they support trusted subjects, because almostno real information system can only be based on unidirectional information flows. Databasefederations will thus probably require global trusted subjects. However, can global trusted sub-jects be supported without violating local autonomy, and if not, up to which degree needs theautonomy of CDBMS be sacrificed?

Heterogeneity of local classifications requires a reclassification of - at least some - localdata at the global level (a design problem). However, which reclassification schemes should besupported by ensuring local autonomy and preventing overclassification? Which trade-offs be-tween both contradicting objectives are meaningful?

DAC systems are mainly faced with the following aspects of heterogeneity:

– CDBMS can support different kinds of access rights (permissions, prohibitions or evenboth, with different conflict resolution policies in the latter case), and can apply different clo-sure assumptions (open vs. closed world assumption).

– Different authorisation units may be supported (users, groups, nested groups, roles withdifferent role paradigms, role hierarchies, subject domains, etc.).

– The protection object granules are usually different (databases, protection object domains,types/classes/relations or objects/tuples, etc.), and different actions are supported to accessthese objects (relational operators, methods, etc.).

– Some systems may support value-dependent access rights (either via a view concept /GrWa76/ or by applying another technique like query modification /Ston 75/).

– The local systems can enforce different authorisation paradigms (centralised vs. decen-tralised authorisation, ownership vs. administration paradigm), and in case that decen-tralised authorisation is supported, it may be based on different mechanisms (grant optionsvs. explicit grant permissions).

The situation becomes even more complicated if multiple CDBMS have to be integratedwhere some only support DAC, whereas others only support MLS. Hence, access control fordatabase federations needs a formal foundation, i.e. a canonical security model subsumingDAC and MLS.

14

In our opinion, it is very important for dynamic database federations ("dynamic" means thatthe global schema is often subject to changes) to support decentralised authorisation. Other-wise, the global security administrator who is responsible for the global authorisation state incase of a centralised authorisation, will be a bottleneck of the whole system.

The global security policy should be adaptable. The global security administrator needs, forinstance, mechanisms to control how decentralised authorisation can happen, i.e. to restrictwho is permitted to grant which access rights to whom. The Griffith/Wade approach /GrWa 76/is too liberal for many applications. Furthermore, global decentralised authorisation should becoordinated with local decentralised authorisation (if supported by the CDBMS). Usually, itdoes not make sense to permit a global authorisation if the global grantee later cannot make useof the global access right, because the required local accesses are rejected by the involvedCDBMS. This problem is related to local autonomy of CDBMS. If CDBMS insist on full au-thorisation autonomy /JoDi 94/ (a special case of association autonomy according to /ShLa90/), i.e. if local access decisions are based on the - locally verified - identity of global users, aglobal authorisation requires the corresponding local authorisations, too. The problem does notarise if CDBMS are satisfied with low authorisation autonomy, i.e. if local access decisions arebased on the identity of the FDBMS itself. In the latter case, the set of local access rights im-plicitly defines a kind of "export schema", and the data are freely delivered to the FDBMS. Ad-ditional restrictions are only enforced at the global layer. Low authorisation autonomy requiressome trust of CDBMS into the federation's security policy and mechanisms, as well as cooper-ation between both access control layers to ensure accountability (local systems need a reliableway to get the information from the FDBMS which global user has accessed their data). Differ-ent CDBMS can choose a different scheme within the same federation.

Considering global authorisation, the FDBMS should probably support both, a pessimisticapproach (global authorisations are only accepted if they comply with the global security policyand the affected local systems agree /JoDi 94/), and an optimistic approach (global authorisa-tions are accepted if they comply with the global security policy). The pessimistic approach re-quires that global access control concepts are mapped on - usually less powerful - local mecha-nisms by preserving local autonomy up to the degree required by the corresponding CDBMS/JoDi 94/.

Database federations also create design problems. The proper protection of objects "emerg-ing" at the global layer can only be supported by the FDBMS' mechanisms, but requires appli-cation-dependent authorisations, taking these global objects into account. The situation getseven worse if different Chinese Walls (Brewer/Nash model /BrNa 89/) have to be enforced inCDBMS and there is some redundancy between data kept by the local systems. When buildinga secure database federation and choosing the appropriate degree of local autonomy, it has to betaken into consideration that security is a property of the system in its entirety (and neither ofthe federation nor the CDBMS alone). In particular, it has to be considered whether globalusers are also able to access local systems directly, without using the interface of the FDBMS.Unfortunately, this is the usual case. If local systems then insist on full authorisation auton-omy, the FDBMS can neither ensure a proper protection of global protection objects nor en-force global Chinese Walls; an notification mechanism (either directly between the CDBMS, orvia the FDBMS) between the affected CDBMS is required. Active mechanisms can be used forthis purpose.

It is interesting to note that this problem does not occur if low authorisation autonomy hasbeen chosen. In this case, only the FDBMS needs the local rights to access sensitive data fromconflict-of-interest domains, and users can only get access to these data via the FDBMS. TheFDBMS can then enforce the security policy of the whole system. Sacrificing local autonomycan thus help to increase the security of the system in its entirety. The proper trade-off has to benegotiated between the local and global authorities, when a database system is to join a federa-tion, and depends upon the amount of trust between the involved parties.

15

Information flow control is required if the FDBMS is allowed to store data of componentsystems in its own data storage areas or in other component database systems. Probably, thisproblem can only be solved using classification-based techniques.

The opportunities database federations offer for solving security problems are not that ob-vious. If access control is more important than performance, it is possible to integrate aCDBMS offering either no or only very restricted security mechanisms into a secure databasefederation. This way, the FDBMS acts as a secure interface to the data kept by an insecureDBMS. Furthermore, tightly coupled federations can be used to enforce system-wide securitypolicies. Note that both examples require low authorisation autonomy for CDBMS to preventusers from circumventing the FDBMS.

5.3. Existing Approaches

MLS for database federations has so far not been considered in much detail. The results of apanel discussion on security issues for database federations were published in /MLTS 92/ (alsoincluding some notes on DAC).

An approach for tightly coupled federations has been presented in /IdQG 94/ and /IdGC94/. During the integration process, data from component systems are reclassified - if needed -to get a consistent global schema. Since this reclassification tends to overclassification, the au-thors do not only consider "static security" (the classification of subjects and protection objectsis static), but also describe some ideas to support "dynamic security". The latter means that agroup of subjects is able to get a higher clearance level (resulting in the ability to access moresensitive data) under predefined circumstances. This approach is based on Shamir's scheme ofsharing a secret /Sham 79/ (or so-called "shadow keys" according to /Denn 82/). A predefinednumber of users has to combine their shares in order to get temporarily a higher clearance.

A scheme for loosely coupled database federations has been presented in /Oliv 94/. This ap-proach is very interesting, because it introduces the notion of trust between sites being involvedin a database federation. CDBMS can selectively decide which other sites are allowed to accesstheir data.

The first attempt to develop a canonical security model for database federations comprisingMLS as well as DAC has been presented in /Pern 92/. Local systems can apply a discretionarypolicy, a mandatory policy or a combination of both. The global canonical model comprises thefunctionality of local systems and allows for defining additional access restrictions at the globallevel.

Concerning DAC for federations, most approaches that have so far been developed focus ontraditional database technology (mostly relational technology) and are based on view concepts/ShLa 90, Pern 92/.

The first DAC concept for database federations has been implemented in Mermaid /TeLW87/, which is a front-end system to integrate multiple homogeneous relational DBMSs by en-suring distribution transparency. Authorisation autonomy has been preserved. Access rights areindividually granted at the global level, but do not imply any right for involved CDBMSs (i.e.the corresponding local rights have to be granted explicitly). Access control is based on accesscontrol lists which are associated with certain schemas. A user having an entry within such anaccess control list is allowed to carry out the corresponding relational operator for any relationthat belongs to this schema. Local access validations are carried out independently. Mermaidprovides for a two-level access control and supports full authorisation autonomy.

In /WaSp 87/ an access control mechanism for heterogeneous federations (supporting rela-tional and network CDBMS) has been described, which is based on views and an ownershipparadigm. Authorisation autonomy is achieved by providing only snapshots of local data toglobal users. Thus, global write accesses are not supported.

16

Recently, a discretionary scheme for tightly coupled federations has been presented /JoDi94/, supporting the integration of heterogeneous CDBMS, different degrees of local autonomy(within the same federation), and decentralised authorisation based on a pessimistic protocol.

Since federations are special cases of interoperable systems, the efforts of the OMG (and re-lated committees like the ODMG) have to be taken into consideration. For the OMG CORBA/OMG 91/, some security issues have been considered /OMG 93/, which have so far concen-trated on network security issues like authentication and encryption services. However, it isalso planned to define a security service for CORBA environments, probably including accesscontrol.

6. DBMS Construction

In the past, many applications requiring very fast access to rather complex data (e.g. CAD sys-tems) have been built upon dedicated file systems. New database concepts and more powerfulhardware have made it possible to use database technology for such applications, too. In manycases, however, general purpose DBMS are not able to fulfil all needs of these applications, orto react quickly enough to changing user requirements. Therefore, special purpose DBMS arebeing developed, fitting best to particular classes of applications. But building a full-fledgedDBMS from scratch is a very expensive process; moreover, it often is a waste of resourcessince the required basic functionality (storage systems, access paths, etc.) are simply reimple-mented. Hence, the design and basic functionality of DBMS should be reused.

DBMS construction is the process of designing and implementing full-fledged DBMSbased on reusable, generatable and/or adaptable units.

Obviously, this means to apply state-of-the-art software engineering principles - an issuethat by the way has been largely neglected in the past - resulting in a construction methodologyfor DBMS. Such an approach also has several other advantages. New or enhanced databaseconcepts can quickly be exploited in real products, by avoiding a lot of boring ground work ormaintenance of redundant functionality in multiple systems.

Several extensible DBMS and DBMS construction systems based on configuration and gen-eration techniques have been suggested (cf. /GeDi 94/ for a more detailed discussion): kernelsystems like WISS /CDKK 85/ or DASDBS /Paul 87/, customisable systems like STAR-BURST /Haas 90/, toolkit systems like EXODUS /Care 86/, Open OODBMS /WeBT 92/ orDOMS /GeHK 93/, or generator systems like GENESIS /BaLW 88/.

In particular, it seems to be promising to regard a DBMS as a collection of resource man-agers that cooperate under the control of some sort of broker /Gepp 94/. In such a view, it hasto be determined where various security mechanisms fit in to meet all requirements. Althoughwork in this direction is still in its infancy, it can be expected that some basic security function-ality will be required in the broker, while most others can nicely be organised into a variety ofsecurity managers (either as subcomponents of the managers providing for some DBMS func-tionality, or as managers of their own, interoperating with the other DBMS components viawell-defined interfaces).

The problems to be solved are manifold. Security mechanisms are not orthogonal to the ar-chitecture and the functionality of a DBMS; just the opposite, they are highly dependent onboth. The functionality determines, e.g., the kinds of protection objects to be dealt with, andthe actions that can be executed upon those objects. Moreover, the architecture determines - be-sides other issues - how data can be accessed. The latter is even more serious in MLS systems,where the absence of covert channels has to be proven.

17

It has to be investigated which security mechanisms must be supported by "generic" compo-nents of a DBMS, and how these components can be integrated into - perhaps provable - secureoverall systems (the hook-up problem10 is somewhat related). It can be expected that a refer-ence architecture, a design methodology for building secure DBMS based on reusable andadaptable components, and a framework for implementing such systems need to be developed.

Furthermore, the required design and implementation framework has to support several se-curity policies in order to tailor the target DBMS to the application's requirements, whereas sys-tems that are now available let the user live (or die) with hard-wired policies. It can hardly beexpected that these objectives can completely be achieved over the next ten years.

7. Security Design

Allowing for more comprehensive modelling of the real world by means of data models, activerules, etc., will improve the quality and maintainability of software systems, as well as the effi-ciency of the software development process. However, as real world systems we want to auto-mate are usually rather complex, the use of advanced modelling facilities is unfortunately com-plex, too. In consequence, it is also everything but straightforward to apply advanced securityfeatures in the appropriate way (more elaborate security policies require more complex securitymechanisms). It is thus not sufficient (though very important!) to provide the technical meansfor realising powerful and effective security policies. In addition, security administrators needsupport in their job by appropriate design methodologies and tools which allow them to formu-late their requirements. Security design in the database context can follow the conceptual de-sign, when the data and functionality have been modelled and the protection objects and actionsto be applied upon these objects are known. Additional tools can help to map the resulting secu-rity design onto the set of available security mechanisms within the system, relieving the securi-ty administrator (or designer) from the need to fuss around with low-level DBMS features.Such a mapping can again be supported by active mechanisms, specifying which abstract con-cepts fit how to which mechanisms at the logical DBMS level.

On the other hand, the initialisation of a system usually is - although sometimes very com-plicated and time-consuming - not the major part of administering a secure system. The require-ments of users change over time, new users want to access the data, etc. This problem is accel-erated due to the increasing interconnections between existing applications, perhaps eventuallyresulting into world-wide information systems. Accordingly, the number of users accessingdata of a particular system becomes larger and larger. It can hardly be expected that these userscan be administered appropriately by only using "anonymous log-in". Hence, the number of ac-cess rights which are required for administering more users is increasing, too, and the authori-sation bases become bigger. However, the greater the number of rights in a system, the moredifficult it is to assess the consequences of the current authorisation state. Consequently, notonly abstraction mechanisms (like role concepts) to reduce the required number of access rightsare required, but also powerful tools to analyse the authorisation state (who can access a partic-ular sensitive protection object; which access rights has a particular user accumulated, etc.). Incase that the current authorisation state does not comply with the security policy to be enforcedand the system makes heavy use of implicit rights /FeSW 81/, the security administrator mayneed some help how the set of explicit access rights has to be changed to adjust the authorisa-tion state appropriately.

10 The hook-up problem basically concerns the question under which constraints the combination of securecomponents results into a secure overall system (verified secure systems according to the TCSEC /DoD85/).

18

Some ideas for developing methodologies for the design of secure database applications canbe found in /Fugi 88, HuDT 93, PeWT 93/.

8. Conclusions

As we have already indicated, the mentioned areas of technology development are interrelated.For example, object-oriented technologies are used to implement active DBMS or to integrateDBMS into database federations, and active mechanisms can beneficially be applied to integratesystems (for change propagation and several other purposes). Frameworks for DBMS con-struction can be used to develop special purpose active or object-oriented DBMS, and may alsohelp to implement database federations.

In our opinion, active mechanisms are the most promising technology for solving problemsin many areas of software systems in general, in particular also in database security. Althoughthe technology is still pre-mature and not very well understood, it may turn out to trigger a rev-olution in the design, construction and maintenance of software systems. Depending on theevent model and the expressiveness of the conditions, very complex situations within a comput-er system can be monitored (which can also be used for intrusion detection /Denn 86, LuJa 88/)and an appropriate reaction can be triggered. Moreover, since active rules subsume deductiverules /Wido 93/, they can also be applied to represent knowledge about any kind of application(e.g. how to map abstract concepts onto concrete mechanisms). If we are able to master thecomplexity of this technology (in particular problems concerning the interaction between rules,and questions like the termination of rule execution chains /BaCW 93, BaWi 94/), we will havea tool at hand whose usefulness we are just beginning to understand.

In a more general view, it can be expected that the current trend to represent a variety of dif-ferent kinds of information explicitly in the database system will go on. Database systems sup-port the controlled and integrated inspection and modification of such information. Standardmechanisms are provided that can be used by several applications, so that even the reuse offunctionality is supported. As a side-effect, numerous calls to the DBMS often can be saved.11

The applications "simply" send very abstract requests to the DBMS, and powerful servers (notnecessarily mainframes, but perhaps "clusters" of high-end workstations) where these DBMSare running on process the data locally. Only the results the applications are really interested inhave to be transmitted over the network.

In summary, current trends in database technology do indeed have considerable impact onsecurity concepts, in terms of both, better solutions that can be supported, and new problemsthat need to be solved. Unfortunately, commercial products in this area are – once again! – veryslow to incorporate security features that are as advanced as the rest of the system from the verybeginning. At best, they are going to retrofit them to the system in later releases. The securitycommunity is thus challenged not only to device and evaluate appropriate concepts, but also topush for and foster the necessary technology transfer to DBMS builders and users. Organisa-tions like the OMG in case of object-oriented technology can support the transmission of know-how from the research community to software industry.

11 This is even more important, since communication costs are decreasing much slower than local processingand storage costs /Lewi 94/.

19

References

/AbBo 91/ Abiteboul, S.; Bonner, A.; Objects and Views; Proc. 1991 ACM SIGMOD Int. Conference onManagement of Data, Denver, May, 1991, 238-247

/Ahad 92/ Ahad, R. et al.; Supporting Access Control in an Object-Oriented Database Language; Proc.EDBT '92, Vienna; Lecture Notes in Computer Science, 580, Springer-Verlag, 1992, 184-200

/Ande 72/ Anderson, J.P.; Computer Security Technology Planning Study; ESO-TR-73-51 (AD-758206),J.P. Anderson Co., Oct. 1972

/Atki 89/ Atkinson, M.; Bancilhon, F.; DeWitt, D.; Dittrich, K.; Maier, D.; Zdonik, S.; The Object-Ori-ented Database System Manifesto; 1st International Conference on Deductive and Object-Orient-ed Databases, Kyoto, Dec. 89

/BaCW 93/ Baralis, E.; Ceri, S.; Widom, J.; Better termination analysis for active databases; Proc. of the1st Int. Workshop on Rules in Database Systems, Edinburgh, Aug. 1993, 163-179

/BaLW 88/ Batory, D.S.; Leung, T.Y.; Wise , T.E.; Implementation Concepts of an Extensible Data Modeland Data Language; ACM Transactions on Database Systems, 13:3, 1988

/Bane 87/ Banerjee, J.; Chou, H.-T.; Garza, J.F.; Kim, W.; Woelk, D.; Ballou, N.; Kim, H.-J.; Data Mod-el Issues for Object-Oriented Applications; ACM Transactions on Office Information Systems,Vol. 5, No. 1, Jan. 1987, 3-26

/BaWi 94/ Baralis, E.; Widom, J.; An Algebraic Approach to Rule Analysis in Expert Database Systems;Proc. of the 20th VLDB, Santiago, Chile, Sep. 1994, 475-486

/BeJS 93/ Bertino, E.; Jajodia, S.; Samarati, P.; Access Control in Object-Oriented Database Systems -Some Approaches and Issues; Adams, N.R.; Bhargave, B.K. (eds.); Advances in Database Sys-tems, Chapter 2, Lecture Notes in Computer Science, 759, Springer-Verlag, 1993

/BeLa 75/ Bell, D.E.; LaPadula, L.J.; Secure Computer Systems: Unified Exposition and Multics Interpre-tation; MTR-2997, (AY/W 020 445), The MITRE Corporation, Bedford, MA, Jul. 1975

/BeMJ 94/ Bertino, E.; Mancini, L.; Jajodia, S.; Collecting Garbage in Multilevel Secure Object Stores;1994 IEEE Symp. on Research in Security and Privacy, Oakland, CA, May 1994

/BeOS 94/ Bertino, E.; Origgi, F.; Samarati, P.; A New Authorization Model for Object-Oriented Data-bases; IFIP WG 11.3 8th Int. Conference on Database Security, Bad Salzdetfurth, Aug. 1994

/Bert 92a/ Bertino, E.; Data Hiding and Security in Object-Oriented Databases; Proc. 1992 Int. Confer-ence on Data Engineering, IEEE Computer Society Press, Phoenix, Feb. 1992, 338-347

/Bert 92b/ Bertino, E.; A View Mechanism for Object-Oriented Databases; 3rd Int. Conference on Extend-ing Database Technology EDBT, Vienna, Austria, Mar. 1992

/BrNa 89/ Brewer, D.F.C.; Nash, M.J.; The Chinese Wall Security Policy; IEEE Symp. on Security andPrivacy, Oakland 1989, 206-214

/Brüg 92/ Brüggemann, H.H.; Rights in an Object-Oriented Environment; Jajodia, S.; Landwehr, C. (eds.);Database Security, V: Status and Prospects, Elsevier, IFIP, 1992

/Care 86/ Carey, M.J.; DeWitt, D.J.; Frank, D.; Graefe, G.; Muralikrishna, M.; Richardson, J.E.; The Ar-chitecture of the EXODUS Extensible DBMS; Proc. of the 1986 International Workshop on Ob-ject-Oriented Database Systems, IEEE Computer Science Press, 1986

/CDKK 85/ Chou, H.-T.; DeWitt, D.J.; Katz, R.H.; Klug, A.C.; Design and Implementation of the Wiscon-sin Storage System; Software - Practice and Experience, 15:10, 1985

/Chak 89/ Chakravarthy, S. et al.; HiPAC: A Research Project in Active, Time-Constraint Database Man-agement; Technical Report XAIT-89-02, 1989

/CKAK 94/ Chakravarthy, S.; Krishnaprasad, V.; Anwar, E.; Kim, S.-K.; Composite Events for ActiveDatabases: Semantics, Contexts and Detection; Proc. of the 20th VLDB, Santiago, Chile, Sep.1994, 606-617

/ClWi 87/ Clark, D.D.; Wilson, D.R.; A Comparison of Commercial and Military Computer SecurityPolicies; Proc. IEEE Symp. on Security and Privacy, Oakland, Apr. 1987, 184-194

20

/Daya 89/ Dayal, U.; Queries and Views in an Object-Oriented Data Model; Proc. of the 2nd Int. Work-shop on Database Programming Languages, 1989

/Denn 82/ Denning, D.E.; Cryptography and Data Security; Addison-Wesley, Reading Massachusetts,1982

/Denn 86/ Denning, D.E.; An Intrusion Detection Model; IEEE 1986 Symp. on Security and Privacy, Oak-land, CA, Apr. 1986

/DoD 85/ Department of Defence; Trusted Computer System Evaluation Criteria; DOD 5200.28-STD,Department of Defence, Dec. 1985

/FaSp 91/ Faatz, D.B.; Spooner, D.L.; Discretionary Access Control in Object-Oriented EngineeringDatabase Systems; Database Security, IV: Status and Prospects; Jajodia, S.; Landwehr, C. (eds.);Elsevier, IFIP, 1991

/FeGS 89/ Fernandez, E.B.; Gudes, E.; Song, H.; A Security Model for Object-Oriented Databases; 1989IEEE Symp. on Security and Privacy, Oakland, CA, May 1989

/FeSW 81/ Fernandez, E.B.; Summers, R.C.; Wood, C.; Database Security and Integrity; Addison-Wesley,Reading Massachusetts, 1981

/FeWF 94/ Fernandez, E.B.; Wu, J.; Fernandez, M.H.; User Group Structures in Object-Oriented DatabaseAuthorization; Proc. IFIP WG 11.3 8th Int. Conference on Database Security, Bad Salzdetfurth,Aug. 1994

/Fugi 88/ Fugini, M.; Secure Database Development Methodologies; Landwehr, C.E. (ed.); Database Se-curity: Status and Prospects, Elsevier, IFIP, 1988

/GaDi 94/ Gatziu, S.; Dittrich, K.; Detecting Composite Events in Active Databases Using Petri Nets;Proc. of the 4th Int. Workshop on Research Issues in Data Engineering: Active Database Sys-tems (RIDE-ADS), Houston, TX, Feb. 1994

/GaGF 93/ Gal-Oz N.; Gudes, E.; Fernandez, E.B.; A Model of Methods Access Authorization in Object-Oriented Databases; Proc. of the 17th VLDB, Dublin, Aug. 1993, 52-61

/GeDi 94/ Geppert, A.; Dittrich, K.R.; Constructing the Next 100 Database Management Systems: Likethe Handyman or Like the Engineer?; SIGMOD RECORD, Vol. 23, No. 1, Mar. 1994, 27-33

/GeHK 93/ Georgakopoulos, D.; Hornick, M.; Krychniak, P.; An Environment for the Specification andManagement of Extended Transactions in DOMS; Proc. of the 3rd Int. Workshop on ResearchIssues in Data Engineering: Interoperability in Multidatabase Systems (RIDE-IMS), Vienna,Austria, Apr. 1993

/GeHS 92/ Gehani, N.H.; Jagadish, J.V.; Shmueli, O.; Composite Event Specification in Active Data-bases: Model & Implementations; Proc. of the 18th VLDB, Vancouver, Canada, Aug. 1992,327-338

/Gepp 94/ Geppert, A.; Methodical Construction of Database Management Systems; PhD Thesis, Univer-sität Zürich, Institut für Informatik, 1994

/GrWa 76/ Griffith, P.P.; Wade, B.W.; An Authorization Mechanism for a Relational Database System;ACM Transactions on Database Systems, Vol. 1, No. 3, Sep. 1976, 242-255

/GuSF 91/ Gudes, E.; Song, H.; Fernandez, E.B.; Evaluation of Negative, Predicate, and Instance-basedAuthorization in Object-Oriented Databases; Jajodia, S.; Landwehr, C. (eds.); Database Securi-ty, IV: Status and Prospects; Elsevier, IFIP, 1991

/Haas 90/ Haas, L.M.; Chang, W.; Lohman, G.M.; McPherson, J.; Wilms, P.F.; Lapis, G.; Lindsay, B.;Pirahesh, H.; Carey, M.J.; Shekita, E.; Starburst Mid-Flight: As the Dust Clears; IEEE Transac-tions on Knowledge and Data Engineering, 2:1, 1990

/HäDi 92/ Härtig, M.; Dittrich, K.R.; An Object-Oriented Integration Framework for Building Heteroge-neous Database Systems; Proc. of the IFIP DS-5 Conference on Semantics of Interoperable Data-base Systems, Lorne, Australia, Nov. 1992

/Hern 94/ Herndon, W.R.; An Interpretation of Clark-Wilson for Object-Oriented Database ManagementSystems; Keefe, T.; Landwehr, C.E. (eds.); Database Security, VII: Status and Prospects, Else-vier, IFIP, 1994, 65-85

21

/HeZd 90/ Heiler, S.; Zdonik, St.; Object Views: Extending the Vision; 6th Int. Conference on Data Engi-neering, Los Angeles, 1990, 86-93

/HuDT 93/ Hu, M.-Y.; Demurjian, S.A.; Ting, T.C.; User-Role Based Security Profiles for an Object-Ori-ented Design Model; Thuraisingham, B.M.; Landwehr, C.E. (eds.); Database Security, VI: Sta-tus and Prospects, Elsevier, 1993, IFIP, 333-348

/HuDT 94/ Hu, M.-Y.; Demurjian, S.A.; Ting, T.C.; User-Role Based Security in the ADAM Object-Ori-ented Design and Analysis Environment; Proc. IFIP WG 11.3 8th Int. Conference on DatabaseSecurity, Bad Salzdetfurth, Aug. 1994

/IdGC 94/ Idris, N.B.; Gray, W.A.; Churchhouse, R.F.; Providing Dynamic Security Control in a Federat-ed Database; Proc. 20th VLDB Conference, Santiago, Chile, Sep. 1994, 13-23

/IdQG 94/ Idris, N.B.; Qutaishat, M.A.; Gray, W.A.; Integration of Secrecy Features in a Federated Data-base Environment; Keefe, T.; Landwehr, C.E. (eds.); Database Security, VII: Status and Pros-pects, IFIP, Elsevier, 1994, 89-108

/JaKo 90/ Jajodia, S.; Kogan, B.; Integrating An Object-Oriented Data Model With Multilevel Security;1990 IEEE Symp. on Security and Privacy, Oakland, CA, May 1990, 76-85

/JaKS 92/ Jajodia, S.; Kogan, B.; Sandhu, R.; A Multilevel-Secure Object-Oriented Data Model; Techni-cal Report, George Mason University, 1992

/JaSa 90/ Jajodia, S.; Sandhu, R.; Polyinstantiation Integrity in Multilevel Relations; IEEE Symposiumon Security and Privacy, Oakland, CA, 1990

/JoDi 93a/ Jonscher, D.; Dittrich, K.R.; Access Control for Database Federations; a discussion of thestate-of-the-art; Proc. DBTA Workshop on Interoperability of Database Systems and DatabaseApplications, Fribourg, Switzerland, Oct. 1993, 156-178

/JoDi 93b/ Jonscher, D.; Dittrich, K.R.; A Formal Security Model based on an Object-Oriented Data Mod-el; Technical Report No. 93.41, Institut für Informatik der Universität Zürich, Nov. 1993

/JoMD 94/ Jonscher, D.; Moffett, J.D.; Dittrich, K.R.; Complex Subjects; or: The Striving for Complexityis Ruling our World; Keefe, T.; Landwehr, C.E. (eds.); Database Security, VII: Status and Pros-pects, Elsevier, IFIP, 1994, 19-37

/JoDi 94/ Jonscher, D.; Dittrich, K.R.; An Approach for Building Secure Database Federations; Proc. ofthe 20th VLDB, Santiago, Chile, Sep. 1994, 24-35

/Jons 93/ Jonscher, D.; Extending access control with duties - realized by active mechanisms; Thuraising-ham, B.M.; Landwehr, C.E. (eds.); Database Security, VI: Status and Prospects, Elsevier, 1993,IFIP, 91-112

/KeTT 89/ Keefe, T.F.; Tsai, W.T.; Thuraisingham, M.B.; SODA: A Secure Object-Oriented DatabaseSystem; Computer & Security, Vol. 8, No. 6, 1989

/KeTs 90/ Keefe, T.F.; Tsai, W.T.; Prototyping the SODA Model; Spooner, D.L.; Landwehr, C. (eds.);Database Security, III: Status and Prospects, Elsevier, IFIP, 1990

/KiBG 89/ Kim, W.; Bertino, E.; Garza, J.F.; Composite Objects Revisited; SIGMOD RECORD, Vol. 18,No. 2, Jun. 1989

/Lewi 94/ Lewis, T.G.; Where Is Computing Headed?; IEEE Computer, Vol. 27, No. 8, Aug. 1994, 59-63

/LGSF 90/ Larrondo-Petrie, M.M.; Gudes, E.; Song, H.; Fernandez, E.; Security Policies in Object-Orient-ed Databases; Spooner, D.L.; Landwehr, C. (eds.); Database Security, III: Status and Prospects,Elsevier, IFIP, 1990

/LuHs 90/ Lunt, T.F.; Hsieh, D.; Update Semantics for Multilevel Relational Database Systems; Proc. ofthe 4th IFIP WG 11.3 Workshop on Database Security, Halifax, England, Sep. 1990

/LuJa 88/ Lunt, T.F.; Jagannathan, R.; A Prototype Real-Time Intrusion-Detection System; 1988 IEEESymp. on Security and Privacy, Oakland, CA, Apr. 1988

/Lunt 90/ Lunt, T.F.; Multilevel Security for Object-Oriented Database Systems; Spooner, D.L.; Land-wehr, C.E. (eds.); Database Security, III: Status and Prospects, Elsevier, North-Holland, 1990

/Lunt 92/ Lunt, T.F. (ed.); Research Directions in Database Security, Springer-Verlag, Berlin, 1992

22

/MaMM 91/ Mattos, N.M.; Meyer-Wegener, K.; Mitschang, B.; Grand Tour of Concepts for Object-Orienta-tion from a Database Point of View; SFB 124, Technical Report No. 23/91, University of Kai-serslautern, Department of Computer Science, 1991

/MiLu 92/ Millen, J.K.; Lunt, T.F.; Security for Object-Oriented Database Systems; 1992 IEEE Symp.on Research in Security and Privacy, Oakland, CA, 1992

/MLTS 92/ Morgenstern, M.; Lunt, T.F.; Thuraisingham, B.; Spooner, D.L.; Security issues in federateddatabase systems: panel contributions; Jajodia, S.; Landwehr, C.E. (eds.); Database Security, V:Status and Prospects, IFIP, Elsevier, 1992, 131-148

/Morg 91/ Morgenstern, M.; A Security Model for Multilevel Objects With Bidirectional Relationships;Jajodia, S.; Landwehr, C. (eds.); Database Security, IV: Status and Prospects, Elsevier, IFIP,1991

/Moss 81/ Moss, J.E.B.; Nested Transactions: An Approach to Reliable Distributed Computing; PhDThesis, MIT, Cambridge, MA, 1981

/NyOs 92/ Nyanchama, G.M.; Osborn, S.L.; Database Security Issues in Distributed Object OrientedDatabases; Proc. of the Int. Workshop on Distributed Object Management, Edmonton, Canada,Aug. 1992

/NyOs 93/ Nyanchama, M.; Osborn, S.; Role-Based Security, Object Oriented Databases & Separation ofDuty; SIGMOD RECORD, Vol. 22, No. 4, Dec. 1993, 45-51

/Oliv 94/ Olivier, M.S.; A Multilevel Secure Federated Database; Proc. IFIP WG 11.3 8th Int. Confer-ence on Database Security, Bad Salzdetfurth, Aug. 1994

/OMG 91/ The Common Object Request Broker: Architecture and Specification, Document Number91.12.1 Revision 1.1, Object Management Group and X Open

/OMG 93/ OMG White Paper on Security; OMG Security Working Group, Draft 0.0, Nov. 1993

/Paul 87/ Paul, H.-B.; Schek, H.-J.; Scholl, M.H.; Weikum, G.; Deppisch, U.; Architecture and Imple-mentation of the Darmstadt Database Kernel System; Proc. ACM SIGMOD Int. Conference onManagement of Data, 1987

/Pern 92/ Pernul, G.; Canonical Security Modeling for Federated Databases; Proc. IFIP DS-5 Confer-ence on Semantics of Interoperable Database Systems, Lorne, Australia, Nov. 1992

/PeWT 93/ Pernul, G.; Winiwarter, W.; Tjoa, A.M.; The Entity-Relationship Model for Multilevel Securi-ty; Proc. 12th International Conference on the Entity-Relationship Approach, Dallas, TX, Dec.1993

/PfHD 88/ Pfefferle, H.; Härtig, M.; Dittrich, K.; Discretionary Access Control in Structurally Object-Oriented Database Systems; Proc. IFIP 11.3 Workshop on Database Security, Kingston, Onta-rio, Canada, Oct. 1988

/RaWK 88/ Rabitti, F.; Woelk, D.; Kim, W.; A Model of Authorization for Object-Oriented and SemanticDatabases; Proc. EDBT '88, Venice, Italy, Mar. 1988

/RBKW 91/ Rabitti, F.; Bertino, E.; Kim, W.; Woelk, D.; A Model of Authorization for Next-GenerationDatabase Systems; ACM Transactions on Database Systems, Vol. 16, No. 1, Mar. 1991, 88-131

/Rund 92/ Rundsteiner, E.A.; MultiView: A Methodology for Supporting Multiple Views in Object-Orient-ed Databases; Proc. of the 18th VLDB Conference, Vancouver, Canada, Aug. 1992, 187-198

/RWHT 94/ Rosenthal, A.; Williams, J.; Herndon, W.; Thuraisingham, B.; A Fine-grained Access ControlModel for Object-Oriented Database Management Systems; Proc. IFIP WG 11.3 8th Int. Con-ference on Database Security, Bad Salzdetfurth, Aug. 1994

/Sand 90/ Sandhu, R.S.; Mandatory Controls for Database Integrity; Spooner, D.L.; Landwehr, C. (eds.);Database Security, III: Status and Prospects; Elsevier, 1990, IFIP, 143-150

/Sand 93/ Sandhu, R.S.; Lattice-Based Access Control Models; IEEE Computer, Nov. 1993, 9-19

/SaTJ 92/ Sandhu, R.S.; Thomas, R.; Jajodia, S.; Supporting Timing-Channel Free Computations in Mul-tilevel Secure Object-Oriented Databases; Jajodia, S.; Landwehr, C. (eds.); Database Security,V: Status and Prospects, Elsevier, IFIP, 1992

23

/SaWa 94/ Schaefer, M.; Wade, S.; Trusted ONTOS Prototype - Preliminary Considerations; Proc. IFIPWG 11.3 8th Int. Conf. on Database Security, Bad Salzdetfurth, Aug. 1994

/Sham 79/ Shamir, A.; How to Share a Secret; Communications of the ACM, 22(11):612-613, 1979

/ShLa 90/ Sheth, A.P.; Larson, J.A.; Federated Database Systems for Managing Distributed, Heteroge-neous, and Autonomous Databases; ACM Computing Surveys, Vol. 22, No. 3, Sep. 1990, 180-236

/ScLT 91/ Scholl, M.; Laasch, Ch.; Tresch, M.; Updatable Views in Object-Oriented Databases; Proc. ofthe 2nd Int. Conference on Deductive and Object-Oriented Databases, Munich, FRG, Dec. 1991

/ShSw 89/ Shilling, J.; Sweeney, P.; Three Steps to Views: Extending the Object-Oriented Paradigm;Proc. OOPSLA '89, Oct. 1989, New Orleans, 353-361

/Smit 92/ Smith, K.; Managing Rules in Active Databases; Ph.D. Thesis, University of Illinois, ReportNo. UIUCDCS-R-92-1732, Sep. 1992

/Smit 94/ Smith, K.; Execution Ordering for Multilevel Secure Rules; 4th Int. Workshop on Issues inData Engineering, RIDE-ADS, Houston, TX, Feb. 1994, 98-104

/SmWi 92a/ Smith, K.; Winslett, M.; Multilevel secure rules: integrating the multillevel secure and activedata models; Thuraisingham, B.M.; Landwehr, C.E. (eds.); Database Security, VI: Status andProspects, Elsevier, 1993

/SmWi 92b/ Smith, K.; Winslett, M.; Entity Modeling in the Multi-Level Secure Relational Model; Proc.of the 18th VLDB Conference, Vancouver, Aug. 1992, 199-210

/Spoo 88b/ Spooner, D.L.; The Impact of Inheritance on Security in Object-Oriented Database Systems;Proc. IFIP WG 11.3 Workshop on Database Security, Kingston, Ontario, Canada, Oct. 1988

/Ston 75/ Stonebraker, M.; Implementation of Integrity Constraints and Views by Query Modification;Proc. of the ACM SIGMOD Conf. on Management of Data, San Jose, CA, May 1975, 412-418

/TeLW 87/ Templeton, M.; Lund, E.; Ward, P.; Pragmatics of Access Control in Mermaid; Data Engineer-ing, Vol. 10, No. 3, Sep. 1987 (Special Issue on Federated Database Systems), 33-38

/TiDH 92a/ Ting, T.C.; Demurjian, A.; Hu, M.-Y.; Requirements, Capabilities, and Functionalities ofUser-Role Based Security for an Object-Oriented Design Model; Jajodia, S.; Landwehr, C.E.(eds.); Database Security, V: Status and Prospects, Elsevier, IFIP, 1992

/TiDH 92b/ Ting, T.C.; Demurjian, S.A.; Hu, M.-Y.; On Information Hiding for Supporting User-RoleBased Database Security in the Object-Oriented Paradigm; Jajodia, S.; Landwehr, C. (eds.);Database Security, V: Status and Prospects, Elsevier, IFIP, 1992

/ThSa 93/ Thomas, R.K.; Sandhu, R.S.; Implementing the Message Filter Object-Oriented Security Mod-el without Trusted Subjects; Thuraisingham, B.M.; Landwehr, C.E. (eds.); Database Security,VI: Status and Prospects, Elsevier, 1993, IFIP, 15-34

/Thur 89/ Thuraisingham, M.B.; Mandatory Security in Object-Oriented Database Systems; Proc. OOPS-LA 1989, 203-210

/Thur 92/ Thuraisingham, M.B.; Multilevel Secure Object-Oriented Data Model - Issues on non-compos-ite objects, composite objects & versioning; JOOP, SIGS Publication, 1992

/WaSp 87/ Wang, C.-Y.; Spooner, D.L.; Access Control in a Heterogeneous Distributed Database Man-agement System; IEEE 6th Symp. on Reliability in Distributed Software and Database Systems,Williamsburg, VA, Mar. 1987, 84-92

/WeBT 92/ Wells, D.L.; Blakeley, J.A.; Thompson, C.W.; Architecture of an Open Object-Oriented Data-base Management System; IEEE Computer 25:10, Oct. 1992

/WiCL 91/ Widom, J.; Cochrane, R.J.; Lindsay, B.G.; Implementing Set-Oriented Production Rules as anExtension to Starburst; Proc. of the 17th VLDB, Barcelona, Sep. 1991, 275-285

/Wied 86/ Wiederhold, G.; Views, Objects, and Databases; IEEE Computer, Vol. 19, No. 12, Dec. 1986,37-44

/Wido 93/ Widom, J.; Deductive and Active Databases: Two Paradigms or Ends of a Spectrum?; Proc. ofthe 1st Int. Workshop on Rules in Database Systems, Edinburgh, Aug. 1993