Sebery J.Cryptography.An introduction to computer security.1989

with some modi cations presents the most suitable algorithm for secure transactions, both in centralized and distributed databases.

These research conclusions represent initial steps towards the full understanding of the security requirements in distributed database systems. Such research provides the foundation on which further work and specialized designs can be done in the area of database security.

From the point of view of the use of cryptography for distributed database security, most of the protocols involving cryptography had communications and computer networks in mind (such as the work in [370], [516] and [264]), and they were not geared to solve other more complex security problems in distributed database systems. One notable initiative has been taken by Herlihy and Tyger [238] where the application of cryptographic secret sharing schemes to data replication in distributed systems has been considered. The parallel between secret sharing and quorum formation for the determination of updates to replicated data is very clear, but successful practical secret sharing algorithms suitable for distributed databases have yet to be found. Another notable work in cryptographic considerations for distributed systems is by Dolev and Wigderson [159], where the security of multiparty protocols in distributed systems is discussed.

Another approach from the point of view of design methodology has been taken by Bussolati and Martella [73, 72]. The work presents a multiphase methodology for the design of security systems in an integrated and aggregated distributed environment. The approach is a high-level initiative that is suitable for the expression of security policies governing the distributed database system. The use of views in distributed database systems has been considered by Bertino and Haas in [29]. Views over base relations represents a high-level approach to the security of database systems independent of any low-level physical design and constraints of the system. One can easily conclude that if the view approach at individual sites are secure, then views over the distributed database are also secure. However, the proofs and veri cation of the security of views at a high level does not necessarily eliminate the diÆculties and complexities in the underlying design and implementation of the views.

Another approach to secure distributed database would be to employ an underlying secure distributed operating system, with the database application running on top of the operating system at each site. This approach may prove rewarding since there may be many common mechanisms to control distributed

552 16 DATABASE PROTECTION AND SECURITY

processes in both distributed databases and distributed operating systems. An immediate consequence of this approach would be the increase in complexity in the distributed operating system due to the di erent nature of data in the two systems. These di erences include granularity, the life-span, and the sheer volume of data. Thus, it is probably more useful in the long term to design distributed database systems that infuses security in the whole design, rather than to depend on external components, such as a secure distributed operating system, to achieve a veri able level of security. The reader is directed to [172, 204, 539] for more interesting work towards the security of distributed databases and distributed systems.

16.7 Security in Object-Oriented Database Systems

Object-oriented systems have recently received increasing attention, and from the point of view of database research, many researchers have began to develop object-oriented database systems for various applications. Historically, the idea of objects as a programming construct came from the language Simula. The fact that it has a programming language background has resulted in the notations and meanings of the terms in object-oriented systems having programming connotations. Thus it is advantageous to maintain a loose de nition of object-oriented systems and to use more precise de nitions in more speci c contexts [376]. In this section the notation for object-oriented database systems will follow that by Banerjee et al. [12]. The reader is directed to this reference and to the work by Kim and Lochovsky [281] for more details on object-oriented systems.

Each entity in an object-oriented system is represented as an object. The information about the state of a given object is represented in the instance variables, while the behavior of an object is represented by messages to which the object responds. The values of the instance variables are objects themselves, and the recursive de nition only terminates when primitive objects are used. The primitive objects immediately represent their state (they do not have instance variables).

The behavior or actions de ned on objects are referred to as methods, and a given method performs its actions by sending messages to the objects. Methods themselves can be seen as some code that manipulates or returns the state of a given object, and methods are in fact part of the de nition of objects. Usually,

a message consists of the name of the method to be invoked, together with a list of objects involved. Thus, sending a message to an object means that the method is to be executed. Objects also communicate with each other using messages. The messages and object name arguments become the interface of the outside world to the objects. Primitive methods are used to represent simple actions that can be carried out without the need of messages.

To prevent the consummation of large storage space for objects with their own instance variables and methods, it is natural to group \similar" objects in a class. Objects that belong to one class or type are described by the same instance variables and methods, and they all respond to the same set of messages. Each object may have a di erent state, but the computation type, which is the result of a method activation, is uniform throughout the class. Thus, objects that belong to a class are instances of the class, and so a class describes the form (instance variables) of its instances and the applicable operations (methods) to its instances. Note that the class of an object is itself an object, and a class object can create new instances of its own type.

Related to the idea of a class is the notion of a class hierarchy and inheritance of properties (which are the instance variables and messages) following along the hierarchy. A class and its subclass (or superclass) are related through a is-a relationship. Subclasses of a class inherit all properties de ned for the class and, in addition, can have their own local properties. Another possible relationship is the is-part-of hierarchy that is used to de ne composite objects, which can consist of objects from di erent classes [12, 273]

The area of object-oriented systems is a relatively new one, and only very recently has attention been given by researchers to the security needs of objectoriented systems. In discussing the security of object-oriented database systems it is important to realize that security is very diÆcult or impossible to achieve without an underlying mandatory security kernel. This fact refers more to the implementation aspects of object-oriented database systems rather than to the conceptual and high-level use of objects in a database system.

The work by Lunt [312] and by Lunt and Millen [315] represents an e ort to investigate the problems in de ning the meaning of security as applied to objectoriented database systems. Security classi cation as described in the work by Lunt [312] are associated with objects and classes. An alternative way to look at the classi cation of objects is to take the classi cation itself as being applied to the fact that an object or class exists in the database with that given security

554 16 DATABASE PROTECTION AND SECURITY

classi cation. Similarly, the security classi cation of the properties (or facet in [312]) of an object, which consists of instance variables, messages, methods, and constraints, does not actually apply to the properties themselves, but more to the association that exists between the property and the object.

The \read-down-write-up" rule or \?-property" of the Bell-La Padula security model [19, 20] can be transferred quite readily to the object-oriented model of database systems. The following points de ne more precisely the \read-down- write-up" rule for objects and classes (where L denotes the security classi cation) [312]:

{All system-de ned classes should be classi ed at system-low.

{If object O1 is a superclass of O2 , then L(O1) L(O2).

{If V is a property (facet) of an object O, then L(V ) L(O). This is true for all properties of that object.

{If property (facet) V2 of object O2 is inherited from object O1 with the corresponding property (facet) V1, then L(V2) L(V1).

{If two or more of an object's classes have a property (facet) named V , then the object must inherit the property (facet) V having the lowest security classi cation.

{If a subject S sends a message m to an object O to execute method M, then L(S) L(M ) L(O) and L(S) = L(m).

{Assume that class O1 has property (facet) V (which is inherited by its subclasses). If object O2 belongs to class O1 and if L(V ) in O1 is dominated by L(O2), then L(V ) in O2 must be dominated by L(O2). This is to prevent inference when V in O1 is visible, yet V in O2 is invisible, implying that L(V ) in O2 dominates L(O2).

The above rules show that the notion of security and its associated ideas are applicable to object-oriented database systems. The reader is directed to the following references for further discussion on this area:

{The work by Keefe, Tsai and Thuraisingham [273] presents the SODA (Secure Object-Oriented Database System) model.

{The work by Fernandez, Gudes and Song [179] discusses an authorization model for object-oriented database system.

{The work by Thuraisingham [507] gives a multilevel secure object-oriented data model called SO2.

{The work in [12, 280, 279] and the work in [186, 185, 531] present two implementations of object-oriented database systems, namely the ORION and Iris object-oriented database systems respectively.

An overview of research on access control in object-oriented databases can be found in [14].

16.8 Security in Knowledge-Based Systems

The area of arti cial intelligence and the application of expert systems has received an explosion of interest in the last decade. Various expert systems have been designed, from research prototypes to commercial versions to be used in real life situations. Both the business community and the military have found increasing uses of expert systems in daily tasks.

One aspect of expert systems and knowledge-bases in general which has received hardly any attention is that of the security of such systems. Although the di erences between the security of knowledge-base systems and database systems are not immediately obvious, further consideration into the di erent nature of the data in both systems and the use of rules in knowledge-base systems will indicate that it presents a somewhat more complex and unresearched problem compared with database systems.

The term production systems is best used to represent a model that partitions intelligent processes into rules, data and a control strategy [28]. Thus, in a multilevel secure production system both data and rules need to be classi ed, which in turn may require modi cations to be done on the existing control strategy.

The work by Berson and Lunt [28] and by Morgenstern [353] represents one of the earlier attempts to consider the application of multilevel security concepts to production systems and knowledge bases. In [28] Berson and Lunt analyze the use of the noninterference condition rst proposed by Goguen and Meseguer [205] to production systems. The condition requires that besides higher level data being invisible to lower clearance users, the e ects of the actions, such as the ring of rules, by higher level users, should also be invisible to lower clearance users. From this condition emerges four important points that must be taken into consideration when designing secure production systems [28]:

556 16 DATABASE PROTECTION AND SECURITY

{Rules and data that are classi ed at a high level must be invisible to lower clearance users and their lower level processes.

{The inference engine should function independently of the security classi - cation of the rules and data. Thus, the inference engine should function at a given security level with only the available rules and data of the same (or lower) security level without the need to reference or know of the existence of higher level rules and data.

{To satisfy knowledge engineering requirements the rules must be created such that they are complete and make sense to any user with a given security clearance. Thus, the user must not be aware of the existence of other rules that have higher security classi cation. Immediately related to this point is the need for the lower level subsets of rules to be closed so that users or processes cannot infer the existence of higher level rules.

{Any intermediate results of the ring of rules by a user must be classi ed at the same level as the user's clearance.

The above discussion only represents an introductory note and an example of the direct application of multilevel security policies in database systems to knowledge-based systems. The reader is directed to other studies such as [353] and to the e orts by Garvey and Lunt [194, 195] for more works in multilevel security for knowledge-based systems.

16.9 Oracle8 Security

Oracle8 is a commercial database based on the relational model and developed by Oracle Inc. Oracle8 is designed for relatively small applications while its version called Oracle8 Enterprise Edition targets high-volume on-line transaction systems or query-intensive data warehouse applications. SQL (structured query language) is used in Oracle for data manipulation. We are going to describe security features implemented in Oracle8. In particular, the following security aspects are studied:

{user authentication

{resource management (access control)

{Oracle Security Server (OSS)

The reader seeking more details is referred to the Oracle web site http://www.oracle.com or to [254].

16.9.1 User Authentication

Authentication provides assurance that the alleged identity of a party who wishes to access one or more Oracle database servers is valid. Oracle uses passwords to authenticate users. To enhance the security, the following features are introduced:

{account locking

{password aging and expiration

{password history

{password complexity veri cation

Account locking is activated if a user exceeds a designated number of failed login attempts. The number is controlled by the Database Administrator (DBA) via the variable FAILED LOGIN ATTEMPTS. The user account is frozen for speci c period of time or permanently. The time is determined by the variable

ACCOUNT LOCK TIME. In the later case when ACCOUNT LOCK TIME UNLIMITED, the security oÆcer must manualy unlock the account. The variables used to control passwords are de ned by the DBA in the CREATE PROFILE statement. An example of user smith pro le is given bolow.

CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 4 ACCOUNT_LOCK_TIME 30;

ALTER USER smith PROFILE prof;

It means that the user account is locked for 30 days after 4 failed login attempts. The variable PASSWORD LIFE TIME can be used to specify how long the password can be used. When the password life-time has passed, user enters the so-called grace period. At the grace period, warning messages urging users to change their passwords, are displayed every time users login to their accounts. If a user ignores the warnings, then the password eventually will expire and

after that the user is unable to use the account. For example,

CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 4 ACCOUNT_LOCK_TIME 30 PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 3;

ALTER USER smith PROFILE prof;

558 16 DATABASE PROTECTION AND SECURITY

It means that the user Smith is able to use his password for 90 days. After 90 days, he is given 3-day grace period for his password change. The password eventually expires (after 93 days).

Oracle restrict reusing passwords by two variables: PASSWORD REUSE TIME and PASSWORD REUSE MAX. The rst varable indicates for how long the current password is not allowed to be reused. The second variable determines the number of times the password must be changed before the current password can be reused.

Oracle also screens passwords for weaknesses and accepts a new password only if it

{is at least 4 characters long,

{is not obvious, i.e. a password must be di erent from the userid and does not match simple words such as welcome, account, database, or user,

{contains at least one alpha, one numeric, and one punctuation mark,

{di ers from the old password by at least 3 letters.

Users may login to their Oracle accounts

{Directly via an Oracle database. In this case Oracle preforms both the identi-cation and authentication of users using their passwords. This is a preferred option from the security point of view as Oracle does not rely on any (trusted) itermediary.

{Indirectly via an external service (either external host or external network service such as Oracle Advanced Networking Option (ANO)). The external service is responsible for user password administartion and user authentication.

{Via the Oracle Security Service (OSS). This option is available in Oracle8 Enterprise Edition. The user authentication is done by OSS and is shared among multiple Oracle database servers.

16.9.2 Access Control

Authorization assures that a given party can only operate according to privileges that have been de ned for that party by an administrator. To access Oracle resources, users must run database applications and be identi ed by their valid usernames. A security administrator (SA) is the only person who can create users. To do this, the SA calls CREATE USER system privilege that speci es the

new user default and temporary segment tablespaces, tablespace quotas, and pro le. For instance,

CREATE USER OPS$smith

IDENTIFIED EXTERNALLY

DEFAULT TABLESPACE data_ts

TEMPORARY TABLESPACE temp_ts

QUOTA 100M ON test_ts

QUOTA 500K ON data_ts

PROFILE clerk;

The user smith is identi ed externally and the pre x OPS$ indicates the name of the host (operating system) responsible for the identi cation. If the user creates a schema object and does not specify any tablespace for storing it, the default tablespace is used. A temporary tablespace is used when a user executes a SQL statement that requires storage for segment processing. Oracle stores the requested segments in temporary tablespace. The quotas impose the restrictions on the available space. The last line indicates the pro le of the user. Pro les are used to control access to Oracle resources.

A pro le is a named set of resource limits. Pro les can be

{created { the creator must hold CREATE PROFILE privilege.

{assigned to a user { done by using either CREATE USER or ALTER USER privileges.

{altered { done by using ALTER PROFILE privilege.

{dropped { executed by DROP PROFILE privilege.

The following statement creates the pro le clerk.

CREATE PROFILE clerk LIMIT

CPU_PER_SESSION unlimited

CPU_PER_CALL 6000

LOGICAL_READS_PER_SESSION unlimited

LOGICAL_READS_PER_CALL 100

IDLE_TIME 30

CONNECT_TIME 480;

All uspeci ed resource limits are set by the DEFAULT pro le. Note that all limits in the DEFAULT pro le are initially set to UNLIMITED.

560 16 DATABASE PROTECTION AND SECURITY

A privilege in Oracle is de ned as a right to execute a particular type of SQL statement or a right to access another user object. Oracle uses 80 system privileges each performing a speci c database operation. The system privileges are grouped into 23 categories:

{analyze { analyze any table, cluster, or index in the database.

{audit { AUDIT ANY audits any object in the database and AUDIT SYSTEM turns on/o the privilege audit options.

{ cluster { CREATE CLUSTER, CREATE ANY CLUSTER, ALTER ANY CLUSTER, DROP ANY CLUSTER.

{database { ALTER DATABASE adds les to the operating system via Oracle and DATABASE LINK creates private database links in own schema.

{ index { CREATE ANY INDEX, ALTER ANY INDEX, DROP ANY INDEX.

{library { CREATE LIBRARY and DROP LIBRARY create/drop callout libraries in own schema. CREATE ANY LIBRARY and DROP ANY LIBRARY create/drop callout libraries in any schema.

{privilege { GRANT ANY PRIVILEGE grants any system privilege.

{procedure { CREATE PROCEDURE, CREATE ANY PROCEDURE, ALTER ANY PROCEDURE, DROP ANY PROCEDURE, EXECUTE ANY PROCEDURE.

{pro le { CREATE PROFILE, ALTER PROFILE, DROP PROFILE, ALTER RESOURCE COST.

{public database link { CREATE PUBLIC DATABASE LINK, DROP PUBLIC DATABASE LINK.

{rollback segment { CREATE ROLLBACK SEGMENT, ALTER ROLLBACK SEGMENT, DROP ROLLBACK SEGMENT.

{ session { CREATE SESSION, ALTER SESSION, RESTRICTED SESSION.

{sequence { CREATE SEQUENCE, CREATE ANY SEQUENCE, ALTER ANY SEQUENCE, DROP ANY SEQUENCE, SELECT ANY SEQUENCE,

{snapshot { CREATE SNAPSHOT, CREATE ANY SNAPSHOT, ALTER ANY SNAPSHOT, DROP ANY SNAPSHOT.

{ synonym { CREATE SYNONYM, DROP SYNONYM. { system { ALTER SYSTEM.