towards generating a data integrity standard · pdf filetowards generating a data integrity...

Towards generating a data integrity standard

Moshe Zviran a,*, Chanan Glezer b

a Information Science Department, Claremont Graduate University, 130 E. Ninth St., Claremont, CA 91711, USAb Department of Industrial Engineering and Management, Ben-Gurion University of the Negev, P.O. Box 653, Beer-Sheva 84105, Israel

Received 26 October 1998; received in revised form 21 June 1999; accepted 7 August 1999

Abstract

The tremendous growth in size, complexity and value of the organizationÕs data resources has given rise to an urgent

need for a data integrity standard that will provide a consensus de®nition, a common measure and a set of tools for

evaluating the various models and mechanisms in this domain. This paper attempts to pave the way for such a data

integrity standard. It discusses various de®nitions of data integrity and indicates the one that best serves as a common

de®nition. It then provides a description and assessment of two prominent data integrity models: the Biba model, and

the Clark±Wilson model. Next, a framework for evaluating these models is proposed and operationalized. The ®nal

section discusses conclusions and makes some practical recommendations that derive from the comparison of the

models. Ó 2000 Elsevier Science B.V. All rights reserved.

Keywords: Data security; Data integrity; Protection

1. Introduction

Data security is composed of three major factors: secrecy, availability and integrity [17]. Datasecrecy focuses on preventing unauthorized disclosure; data availability deals with methods ofpreventing denial of authorized access; and data integrity refers to preventing unauthorizedmodi®cation of data.

Basic data security techniques were developed early in the history of computer-based systems toprotect the data resource. Elementary password controls became associated with the protection ofdata ®les to maintain their secrecy and integrity. In addition, data integrity elements were installedin batch processing systems of the 1950s and 1960s to minimize the error content in the data.Check digits, radix checks, range checks and content checks were extensively applied, particularlyas part of the e�ort to prevent transcription errors from corrupting the data [22].

With the rapid advance of information technology, greater emphasis has been placed on secrecyand availability. The sophisticated control mechanisms that have been developed in these domains

Data & Knowledge Engineering 32 (2000) 291±313www.elsevier.com/locate/datak

* Corresponding author. Present address: Faculty of Management, The Leon Recanati School of Business Administration, Tel Aviv

University, 69978 Tel Aviv, Israel. Tel.:+972-3-6-409671; fax: +972-3-6407741.

E-mail address: [email protected] (M. Zviran).

0169-023X/00/$ - see front matter Ó 2000 Elsevier Science B.V. All rights reserved.

PII: S 0 1 6 9 - 0 2 3 X ( 9 9 ) 0 0 0 4 2 - 7

have proved e�ective in limiting and preventing unauthorized disclosure while minimizing denialof service to authorized users [23]. However, as the organizationÕs data resources grow in size,complexity and value, an urgent need arises for models and mechanisms to prevent unauthorizedmanipulation or modi®cation of data by users, and for a data integrity standard that will providea common measure and a set of tools for evaluating the various models and mechanisms in thisdomain [3,18]).

Examining previous computer security standards, however, reveals the fact that none of themprovides comprehensive coverage of the data integrity issue. Aspects of integrity are mentionedas part of other standards (e.g., connection integrity in the ISO 7498 standard, DoD TCSEC[12]) but no adequate standard to protect the integrity of the data resource has yet been pro-posed. Consequently, from the data integrity view, a top priority is to generate a standard thatwill de®ne the issue and establish an acceptable set of mechanisms to provide the necessarysecurity services.

To cope with the need to establish a data integrity standard, two major issues need to beaddressed. The ®rst is the lack of a commonly accepted de®nition for data integrity. Severalde®nitions have been proposed and widely discussed in the literature. However, each tacklesvarious aspects of data integrity and none of them is considered to be acceptable as a commonground for articulating the issues associated with data integrity. Another problem that stemsfrom the lack of a consensus de®nition and uni®ed interpretation of data integrity is that each ofthe integrity models is based on its own de®nition, making their evaluation extremely di�cult[2].

A second issue is the absence of a standard data integrity model. Two major models have beenproposed, the Biba model and the Clark±Wilson model, neither of which, however, has become anindustry standard. Moreover, even a framework for evaluating and comparing these models hasnot yet been de®ned. Consequently, a confusion appears to exist with respect to the practicalinterpretation and application of popular integrity in real systems. Finally, there is no realguidance on the notion of `external security requirements' for systems that focus on counteringintegrity threats.

This paper addresses the voids mentioned above and present an initial framework for a dataintegrity standard. First, it discusses the various de®nitions of integrity and attempts to identify acommon and comprehensive de®nition. It then provides a description and an assessment of twoprominent data integrity models: the Biba model, which is based on the hierarchical lattice ofintegrity levels [7] and the Clark±Wilson model, which is based on certi®cation and enforcementrules that preserve integrity by taking the system from one valid state to another [10]. A frame-work for evaluating the models is proposed and operationalized for comparing the two. The ®nalsection discusses conclusions and makes some practical recommendations that derive from thecomparison of the models. It is, however, important to keep in mind that since each model wasdeveloped in a di�erent environment and with di�erent aims, there is no common ground forraising one of them as a universal standard.

2. De®ning integrity

Many de®nitions of integrity in the context of computer systems have been proposed in theliterature, focusing on various aspects of the issue and attempting to achieve di�erent goals. The

292 M. Zviran, C. Glezer / Data & Knowledge Engineering 32 (2000) 291±313

de®nitions either focus on a single element or a group of several elements. They can be dividedinto three major clusters: single-element data-focused de®nitions, single-element non-data-focusedde®nitions, and multi-element focused (comprehensive) de®nitions.

For the data-focused de®nitions, Fernandez et al. [13] view data integrity as a complement todata security rather than an integral ingredient. These authors suggest that data integrity isconcerned with the correctness of the database content and that it can be compromised byfailures originating in user, program or system actions. Thus, data integrity is to be treated as amultifaceted concept consisting of semantic integrity, concurrency control and recovery mech-anisms.

Clark and Wilson [10] speak in terms of ``data that are free from unauthorized manipulation''.Ceri and Garziotti [9] present an approach where the designer of the consistency constraintsspeci®es a set of repair actions for each constraint. Once a consistency violation is detected, thesystem automatically selects one of the repair actions for one of the violated constraints, performsit, and restarts the consistency check. Ceri et al. [8] further describe a speci®c architecture forconstraint de®nition and enforcement. The components of the architecture include a ConstraintsEditor for introducing constraints by the end-users, a Rule Generator for producing a set of activerules (called a maximal rule set) that enforce the constraints, a Rule Analyzer to determine thepartial order on the constraints, a Rule Selector for postoptimization by excluding redundantrules for non-critical constraints, and ®nally a Run-Time System that executes user-suppliedtransactions.

Motro [16] suggests that database integrity has two complementary components: validity,which guarantees that all false information is excluded from the database, and completeness,which guarantees that all true information is included. In order to ensure these components, theauthor proposes using two types of constraints: validity constraints and completeness constraints.The constraints are stored in a set of meta-relations that mirror the actual database relations.Whenever a query is issued to a relational database both the data and the constraints are re-trieved. The model uses the constraints to certify the integrity of the answers as fully or partiallyvalid and fully or partially complete.

Moerkotte and Lockemann [15] use the term consistency as an equivalent to integrity. Theyde®ne a database to be consistent if its current state, and perhaps the transition that led to it, obeya given set of conditions that re¯ect laws governing states and transitions in the miniworld.Consistency is achieved in part by utilizing concepts o�ered by the DBMS data model, and byproper design of the database schema that determines the use of these concepts (data model andschema consistency are collectively referred to as internal consistency). Laws that are not coveredin this way must be explicitly formulated in the form of conditions called consistency constraints(external consistency). To implement their ideas the authors propose an architecture for a systemthat supports a user in an environment where he or she issues a transaction that violates one ormore consistency constraints. The goal is to automatically identify symptoms of inconsistencies,then derive the causes of these inconsistencies and ®nally suggest repair transactions that areappended to the userÕs transaction in order to regain consistency of the database. Comparableintentions have been reported for relational databases.

Awad and Gotterer [1] de®ne the property of integrity as ``a situation where data in a databaseis correct at all times''. Date [11] provides a more detailed de®nition that views data integrity inthe context of accuracy, correctness and validity. The challenge is to guard a database against

M. Zviran, C. Glezer / Data & Knowledge Engineering 32 (2000) 291±313 293

invalid updates and prevent undesired modi®cation of data caused by concurrent execution ofvalid transactions. Such manipulation or modi®cation can be caused by accidental mistakes,system malfunctions or by malicious manipulation.

According to Bertino [6], data integrity is jointly ensured by an access control mechanism andby semantic integrity constraints. Whenever a user tries to modify some data, the access controlmechanism veri®es that the user has a right to modify the data, whereas the semantic integritysubsystem veri®es that the updated data are semantically correct. Semantic correctness is veri®edagainst a set of conditions, or predicates, that the database state must verify.

For the second cluster of de®nitions, Biba [7] claims that integrity does not imply guaranteesconcerning the absolute behavior of a computer system. He considers a computer system topossess the property of integrity if it can be trusted to adhere to a well-de®ned code of behavior andtherefore perform as it was intended to perform by its creator. No a priori statement as to theproperties of this behavior are relevant.

Terry and Wiseman [20] adopt the approach of de®ning security as the simple real world re-quirement that a job is carried out with respect to secrecy considerations, in a correct manner, andthat it is done only if it is in some sense appropriate. In their paper they speak of three aspects ofsecurity: con®dentiality, integrity and appropriateness. They de®ne integrity as a property of state;a correctness. In their model of a state machine, all states need to be correct for the machine to becorrect overall.

For the third cluster of de®nitions, Henning and Walker [14] o�er a comprehensive de®nition ofintegrity covering six areas:

a. How correct the information is thought to be.b. Level of con®dence that the information is from the original source.c. Correctness of the functioning of the process using the information.d. Level of correspondence of the process function to the designed intent.e. How correct the information in an object is initially.f. Con®dence that the information in an object is unaltered.This de®nition appears to be more comprehensive than the previous ones since it provides

coverage of all the areas that logically fall under the title of integrity.Ruthberg and Polk [19] discuss the de®nition developed by the integrity working group

(IWG) of the Invitational Workshop on Data Integrity, which seems to be the most compre-hensive:

Integrity ± a property that data, an information process, computer equipment and/or soft-ware, people, etc. or any collection of these entities meet an a priori expectation of qualitythat is satisfactory and adequate in some circumstance. The attributes of quality can be gen-eral in nature and implied by the context of the discussion, or speci®c and in terms of someintended usage or application.

This de®nition addresses many issues that are commonly associated with the notion of dataintegrity while remaining broad enough to be applied to many environments. The broad rangeprevents restriction of the de®nition to data integrity alone and makes it a good tool for com-parison. The axiom here is that the broader the standard, the greater the number of de®nitionsthat can be measured against it.


A closer examination of the goal reveals that it is composed of the following key elements:1. A priori expectation. This term emphasizes that there must be a goal or desired outcome (i.e.,

expectation) for the element being studied for integrity.2. Quality. This term refers to the attributes that characterize the element being studied. The most

common attributes contained within the heading of quality are accuracy, timeliness, consisten-cy, and completeness. Ruthberg and Polk state that integrity is not quality but rather the ``ex-tent to which the qualities (i.e., accuracy, precision, timeliness, etc.) taken together areconsidered adequate for a given purpose''.Fig. 1 summarizes and synthesizes the integrity de®nitions mentioned above in a two-dimen-

sional format: one refers to the scope of the integrity de®nition (e.g., systems, data, process) andthe second focuses on the goals which the de®nition aims to maintain or achieve.

As evident from Fig. 1, the IWG de®nition is the most comprehensive one. It addresses manyaspects that are commonly associated with the notion of data integrity while remaining broadenough to be applied to many environments. Consequently, due its ¯exibility and completeness,this de®nition can best serve as a standard for comparing other de®nitions of data integrity.Nevertheless, for the same reasons the IWG de®nition is also the most di�cult one to implementand achieve. The IWG de®nition is mostly suitable for groupware applications, work¯ow man-agement systems and project management systems such as CASE tools. These systems encapsulatemechanisms to protect the complex relationship among processes, entities, documents and people,in an attempt to achieve a standard of quality in terms of timeliness, accuracy and precision.

Another example of an architecture that implements the broad scope of the IWG de®nition isTrusted Oracle 7 (www.oracle.com) which is a high security database server product based directlyon Oracle 7 technology. In addition to the range of features and functionality of Oracle 7, TrustedOracle 7 includes enhanced data security capabilities for processing sensitive, proprietary and evenclassi®ed information. Trusted Oracle 7 automatically labels all data and enforces a centralizedsecurity policy, enabling storage and processing of data in di�erent levels of sensitivity on a singlemachine ± without risk of compromise. Trusted Oracle 7 provides integrity using mechanisms thatsupport system integrity and mechanisms that enforce relational database integrity.

System integrity ensures that a data item inserted into the system is the same in content when itis subsequently retrieved. It is achieved by using several mechanisms that enable concurrency andserializability of transactions, as well as discretionary and mandatory access control which pre-vent unauthorized modi®cation and deletion of data by users.

Relational database integrity is supported by the use of declarative entity and referential in-tegrity constraints as de®ned in the ISO/ANSI SQL89 standard. Trusted Oracle 7 enables theenforcement of cross-level integrity and cross-level con®dentiality. In cases where con®dentialitycon¯icts with integrity, Trusted Oracle 7 enables to specify which of the two takes precedence(e.g., polyinstantiation ± allowing a new record at a lower security level to have the same primarykey value as a higher level record, in order to conceal the existence of the higher level record fromthe end-user).

3. The Biba integrity model

The Biba model for system integrity [7] is the outcome of a research project prepared for the USAir Force by the MITRE Corporation. Biba developed his integrity model on the basis of the


assumption that integrity is the dual of secrecy, presenting several policies for protection of in-tegrity and tailoring each policy for implementation in a Multics environment.

BibaÕs model [7] is based on a hierarchical lattice of integrity levels. Several basic elements areused in the model:

Fig. 1. Comparing the data integrity de®nitions.


· Subjects (S): Active system information processing elements of a computing system.· Objects (O): Passive information repository elements of a computing system.· Integrity levels (I): A set of levels with a relation (leq) de®ning a partial order (`less than or

equal'). Integrity levels are directly analogous to those used for security level assignments.· il: A function de®ning the integrity level of each subject and object.· o: A relation (subset of S ´ O) de®ning the capability of a subject to observe an object.· m: A relation (subset of S ´ O) de®ning the capability of a subject to modify an object.· i: A relation (subset of S ´ S) de®ning the capability of a subject to invoke another subject.

Integrity is evaluated at a subsystem level where a subsystem is some subset of a systemÕssubjects and objects isolated on the basis of function or privilege. A computer system is de®ned tobe composed of any number of subsystems.

Biba classi®es integrity threats to the intended performance of a subsystem into the followingtwo dimensions: source and type. Threat source can be either external or internal. In an externalthreat, one subsystem attempts to change the behavior of another by supplying false data orimproperly invoking functions. Internal threats arise if a component of a subsystem is maliciousor incorrect. Biba notes that internal threats are addressed by program veri®cation techniques.

Threat type can be either direct or indirect. Direct threats involve only a subject and an ac-cessed data object, whereas indirect threats refer to a much larger scenario in which a data objectis corrupted through a transfer path of corrupted procedures and data.

The Biba model elements support two classes of integrity policies: mandatory and discretion-ary. They di�er in the manner in which a protection policy, once made, may be changed. Amandatory integrity policy is a protection policy which, once de®ned for an object, is un-changeable and must be satis®ed for all states of the system (as long as the object exists). On theother hand, a discretionary policy is one which may be dynamically de®ned by the user (during theexistence of an object).

3.1. Mandatory integrity controls

Mandatory integrity control policies cannot be bypassed, avoided, or altered by users. Eachpolicy in this category must meet two requirements: it must identify the objects that requireprotection and it must determine when requests to access data are permissible. This is the accesscontrol for the system. Each of the three policies presented by Biba meets these criteria. Thepolicies use di�erent constraints to limit data access while identifying protected objects for thesystem.

The Low-Watermark Policy is based on the premise that integrity level of a subject is dynamicand will change depending on his or her previous behavior: speci®cally, the integrity level of thesubject will be determined by the integrity level of the most recently accessed object. The integritylevel of the objects in the system will not change; the data in the objects remain at a constant level,with the collection of subjects permitted to access those objects constantly changing.

Under this policy it is possible for subjects to downgrade their own integrity level to the lowestlevel in the system, hence the name low-watermark. The main drawback of the policy is thataccess to the lowest level objects will decrease the integrity level of the subject to the lowest level.Subjects can be reinitialized in order to restore their original level of integrity. However, this isobviously not an event that should occur frequently. The policy allows for altering integrity levelsdownward but it does not allow subjects to increase their integrity level. In addition to changing


the integrity level of subjects, Biba [7] introduces a version of this policy called the Low-WaterMark for Objects, where the integrity level of modi®ed objects may change.

The Low-Watermark Policy is depicted in Fig. 2. In this ®gure, the subject (S1) possesses aHigh integrity level before it accesses object O2. This means that S1 is authorized to access objectsthat are labeled High (such as O1). When S1 expands its domain and attempts to access O2 thefollowing sequence occurs. First, access is granted and second, S1 is assigned an integrity level ofMedium. This results from the fact that the level of O2 is Medium. S1 has downgraded its ownintegrity level from High to Medium by requesting and being granted access to O2. O1 is now outof S1's domain and cannot be accessed by S1. Any subsequent actions by S1 to access objects withlower integrity levels than O2 (i.e., Low) will result in the integrity level of S1 being further re-duced. The goal of this policy is to prevent the indirect sabotage of object integrity by subjects.

The Ring Policy is designed to address attempts by subjects to directly modify objects. Thispolicy ®xes the integrity levels of both subjects and objects to a constant level. Modi®cations areallowed only to objects of less or equal integrity level. This policy increases the ¯exibility of thesystem by allowing observation (reading) of objects at any level. Subjects are allowed to observeany object, even those which possess a higher integrity level than the subject. The trade-o� forincreased ¯exibility is decreased integrity assurance. Observation of all objects by all subjectsincreases the possibility of contamination of data contained in high-level objects.

The Strict Integrity Policy can be considered the complement or dual of the security policypresented by Bell-Lapadula [5]. It consists of three axioms that provide the same functions as the

Fig. 2. The Low-Watermark Policy.


Low-Watermark Policy but without allowing change in the integrity level of a subject. Whereasthe Low-Watermark Policy prevents contamination of high-integrity objects by changing theintegrity level of subjects to that of the object most recently accessed, the Strict Integrity Policyforbids access by lower level subjects to a higher level object.

The three axioms used in the policy are the Simple Integrity Condition, the Integrity *-propertyand the Invocation Property. The Simple Integrity Condition states that a subject cannot observeobject of lesser integrity. This rule constrains the use of objects (data or procedures) to those towhose non-malicious character (by virtue of their integrity level) the subject can attest; thoseobjects having an integrity level greater than or equal to that of the subject. Biba considers executeaccess to be equivalent to obsaccess, so objects must have an integrity level greater than or equalto that of the requesting subject in order to be executed.

The Integrity *-property states that a subject cannot modify objects of higher integrity. Thisrule ensures that objects may not be directly modi®ed by subjects possessing insu�cient privilege.The Invocation Property states that a subject may not send messages to subjects of higherintegrity. Since invocation is a logical request for a service from one subject to another, it isa considered a special case of modi®cation and therefore follows directly from the Integrity*-property.

The Strict Integrity Policy is depicted in Fig. 3. Subject S1 possesses an integrity level ofMedium. This gives S1 the ability to observe objects at the High level, modify objects at the Lowlevel and modify/observe objects at the Medium level. In this case, S1 can observe objects O1 and

Fig. 3. The Strict Integrity Policy.


O4 and modify O2. O3 is at the same level as S1 and therefore can be both modi®ed and observed.S1's level will not change even though it may modify lower level objects. This constant subjectintegrity level is the di�erence between the Strict Integrity Policy and the Low-Water Policy.

All in all, a basic premise of the Biba model is the concept of ``no-write-up, no-read-down''.Low-level data are more open to unauthorized manipulation and can therefore be contaminated.High-level data can likewise be contaminated if low-level data are allowed to enter into a processusing the high-level data. The restrictions presented by Biba prevent a user with low-level au-thorization from possibly destroying the integrity of high-level data.

3.2. Discretionary integrity controls

Discretionary controls can be modi®ed by a user, or group of users, who are placed on anauthorization list which speci®es the ability to alter discretionary controls. A user has the abilityto de®ne his or her own integrity controls after access to an object is made, thereby making thecontrols discretionary. Two discretionary policies discussed by Biba are Access Control Lists(ACL) and Rings.

An access control list is a de®ned set of subjects authorized to access a speci®c object. Eachobject within the system has its own access control list. This mechanism is discretionary becausethe list of subjects can be modi®ed by an authorized user. Certain users, such as system admin-istrators, have the authorization to dictate which subjects are allowed access to which objects.This is based on the present integrity levels of both the subjects and the objects.

Fig. 4. Rings.


The use of access control lists creates the problem of identifying those subjects authorized tomodify the ACL. This problem can be solved by externally de®ning those subjects with modi®-cation authority and maintaining this list of authorized subjects at a minimum level. Fewersubjects with modi®cation authority means less opportunity for either inadvertent or malicioussabotage.

The ring policy described here is similar to the ring policy used in mandatory controls with theexception that the access privileges of subjects can be modi®ed. As illustrated in Fig. 4, the in-tegrity of objects is protected by allowing modi®cation only by subjects within a speci®ed integrityring (domain) which is established for each subject.

The subjects can observe or modify only those objects that are within their respective ring. The®gure shows that the rings may overlap, as O1 is within the rings of both S1 and S2. Objects thatare outside a subject's ring are not accessible by that subject.

4. The Clark±Wilson integrity model

The Clark±Wilson integrity model [10] makes a comparison between military and commercialsecurity policies and takes the ®ndings of this comparison to formulate a model that can be usedto preserve data integrity. The authors clearly distinguish between the needs of the military andcommercial environments concerning data integrity and use the DoDÕs Trusted Computer SystemEvaluation Criteria [12] to set standards for their model.

Clark and Wilson de®ne `data integrity' as meaning that data are free from unauthorized ma-nipulation and in a valid state. Free from unauthorized manipulation means that unauthorizedusers have not altered the data in any way. Valid state suggests that data protected meet therequirements of the integrity policy.

The concept of validity means that the data are in the same unaltered condition that they werein when they were received. Separation of duty and well-formed transaction mechanisms are usedto ensure this validity. Separation of duty attempts to ensure the external consistency of dataobjects: the correspondence between a data object and the real-world object it represents. Thiscorrespondence is ensured indirectly by separating all operations into several subparts and re-quiring that each subpart be executed by a di�erent person. A well-formed transaction is struc-tured so that a user cannot manipulate data arbitrarily, but only in constrained ways that preserveor ensure the internal consistency of the data.

The Clark±Wilson integrity model is built on the premise that ensuring integrity is a two-partprocess, consisting of certi®cation and enforcement. Both of these terms are used in reference todata that must be protected against manipulation. The model begins by identifying constraineddata items (CDIs), the items that need to be covered by the model and to which the model isapplied. Veri®cation that CDIs are within the constraints of the data integrity model is ac-complished by Integrity Veri®cation Procedures, or IVPs, which ensure that the data are in avalid state before any operations are performed. Transformation procedures (TPs) move CDIsbetween valid states and are used to change the collection of CDIs that correspond to each validstate. Moving from one valid state to another changes the applicable CDIs and this change isperformed by a TP or set of TPs. The TP is used in the sense of a well-formed transaction in acommercial integrity model. By allowing only TPs to change CDIs, the integrity of each CDI isensured.


The term CDI is derived from the requirement that only a TP can alter the data. When theCDIs meet the requirements of the integrity policy then a condition known as a `valid state' arises.CDIs will be continuously in a valid state if they are altered only by TPs. The TPs take the CDIsfrom one valid state to another and thereby maintain data integrity.

Enforcement of the requirement that only TPs manipulate CDIs can be accomplished by thesystem. The validity of the initial IVP, which con®rmed that the CDIs met the integrity policyrequirements, and the validity of the TPs can only be accomplished by a trusted user (i.e., a se-curity o�cer). This veri®cation is done by comparing the IVP and each TP against the integritypolicy that is in use. This two-step process is the basis of the Clark±Wilson model. Enforcement ofthe TP requirement by the system and certi®cation of each TP by the security o�cer are the twosteps in the model.

Clark and Wilson developed a set of rules for both the certi®cation and enforcement re-quirements. There are ®ve rules concerning certi®cation and four rules concerning enforcement.The certi®cation rules are labeled C1±C5 and enforcement rules are labeled E1±E4. They are givenin order of implementation.

These three rules are concerned with the internal consistency of the CDIs. The requirementsspeci®ed by these rules are met by the proper functioning of the system. Enforcement is alsoaccomplished by the system.

These rules develop the requirement for each user to be identi®ed upon initial access to thesystem so that only appropriate TPs are available. This limits access to TPs and, therefore, CDIsto authorized users.

Rule C4 establishes an audit trail for each TP. Pertinent information about each TP is capturedso that independent reconstruction of the TP is possible. This creates a log to serve as a documentfor audit.

(C1) IVPs are required to ensure that all CDIs are in valid states when an IVP is executed.(C2) All TPs must be able to take a CDI from one valid state to another valid state,

thereby ensuring integrity of the CDI.(E1) The system must ensure that only TPs are allowed to manipulate CDIs. It must also

allow a relationship to be created to identify a user with the TPs that are available forthat user, as well as the CDIs that the TPs are allowed to access (access triple).

(E2) The relations developed in E1 must be stored by the system so that users are onlycapable of accessing those TPs for which they are authorized.

(C3) The relations that are created by E1 and stored by the system in E2 must meet therequirements of the integrity policy.

(E3) The system must be capable of identifying each user and verifying that users areallowed to use only those TPs for which they are cleared.

(C4) All TPs must be capable of writing to a write only CDI the information that isnecessary to reconstruct the TP if required. This creates a `log' to record theoccurrence of each TP as well as the design of the TP itself.


The next rule (C5) addresses a component of the model that has not yet been mentioned. Thiscomponent is the unconstrained data item (UDI), which is a data item not covered by the integritymodel. UDIs are important because they represent the most common method for entering newdata into the system. Clark and Wilson give the example of a user typing information at a key-board. This shows that a TP can accept unconstrained data as input and then alter the value ofcertain CDIs based on these UDIs. Rule C5 is, therefore, necessary to provide for certi®cation ofUDIs.

The ®nal rule (E4) prevents a user from creating a TP and then executing that TP without anycerti®cation taking place. Enforcement of this rule prevents bypassing the certi®cation require-ments.

This combination of rules forms the basis of the system. The enforcement rules, which cor-respond to the application-independent security functions, and the certi®cation rules, whichcorrespond to application-speci®c de®nitions for integrity, de®ne the system. The authors en-deavor to place as much responsibility as possible on the enforcement rules, thereby limiting thecerti®cation requirements. This is desirable because of the complexity of the certi®cation processcompared to the enforcement capability of the system.

The Clark±Wilson model has been acknowledged as a new approach to de®ning and main-taining data integrity. There has been a great deal of follow-on work which takes the basics of theClark±Wilson model and attempts to re®ne it for implementation with speci®c computer systems.This follow-on work has served to highlight some of the strengths of the model.

The Clark±Wilson model described above was further extended by Abrams et al. [2], whopropose several more powerful mechanisms that support external integrity. They claim that thesenew mechanisms need to support objectives such as external consistency, separation of duties,internal consistency, and error recovery. As an example, to achieve separation of duties, theyadopt the ideas of Primary CDIs and enabling sequences as a complementary measure to theaccess triples in the Clark±Wilson model.

The enabling sequences must ensure that changes to the primary CDI have the necessarycorroboration. The idea of primary CDIs and enabling sequences allows one to focus attention onwhich CDIs require separation of duties and whether this separation is adequately supported byenabling sequences of events.

5. Comparison of the data integrity models

Each of the data integrity models described above addresses the issue from its unique per-spective. Thus, in order to compare and assess the models, a generic framework needs to beapplied. Such a framework must provide a common ground for evaluation so that each of the

(C5) A TP must be capable of taking a UDI as input and transforming it into a valid stateCDI. If this cannot be done then the UDI must be rejected by the TP.

(E4) An individual with the ability to certify IVPs or TPs must not be capable of executingthose same IVPs or TPs.


models can be evaluated individually. The proposed framework consists of three domains thatcover the underlying de®nition of integrity, the concepts used in the model and the relative ad-vantages and limitations of the model. The domains and the detailed characteristics used in theframework are depicted in Fig. 5. After applying the framework, recommendations concerningacceptance of each model can be formulated.

5.1. De®nition of integrity used in model

The de®nition of integrity used in each model is examined for the purpose of determiningits adequacy, completeness, and assumptions. The de®nitions are measured against the stan-dard set by the de®nition which has been adopted as a benchmark, namely the IWG de®-nition.

5.1.1. Adequacy/completenessAdequacy, as stated in the IWG standard, is concerned with the areas of integrity that are

addressed by the de®nition. The IWG standard de®nition itself is both adequate and complete asit addresses many of the areas frequently associated with data integrity. Analysis of the modelsproduces the following results.

Biba on adequacy/completeness: The Biba de®nition treats integrity as a relative rather than anabsolute measure. There is no a priori statement concerning the performance speci®cations of thesystem. Rather, the system need only perform to the designer's intent, whatever that intent may be[21].

This perspective makes the Biba de®nition extremely broad. It places the responsibility forintegrity on the ability of the creator to design a system in which integrity can actually beachieved. Because of this, the Biba de®nition is lacking in speci®c detail and is general enough tobe applied to almost any system or subsystem. It relates to ¯exibility but standardization ismissing. The conclusion from this is that the Biba de®nition of integrity is adequate but notcomplete.

Fig. 5. A framework for comparing the data integrity models.


Clark±Wilson on adequacy/completeness: The Clark±Wilson integrity de®nition is based onprevention of unauthorized manipulation of data. Data that are in a valid state are maintained inthat valid state, thereby ensuring integrity, only if authorized manipulations are performed on orwith the data. This de®nition is broad enough to be applied to many di�erent environments. Itdoes not address the issue of determining whether the data is initially in a valid state. The validstate concept serves to isolate the data and label them as being worthy of protection. This isessential in setting limits to the items that need protection.

The de®nition used in Clark±Wilson is more useful because of its applicability to many types ofenvironments. It is complete in respect to the IWG standard and as a result is quite adequate.

The conclusion reached in this section is that the Biba and Clark±Wilson integrity de®nitionsare adequate in accordance with the IWG standard.

5.1.2. AssumptionsThe assumptions made concerning the integrity de®nition in each model are analyzed to de-

termine if the de®nition is realistic. Assumptions may be so great that they make the integrityde®nition, and possibly the entire model, potentially unacceptable for implementation in any real-world environment. Because of this, caution should be exercised when making assumptions toaccompany any data integrity de®nition.

Biba on assumptions: The assumptions made in BibaÕs de®nition are:1. The system being evaluated is designed in such a way that integrity can actually be achieved.2. External veri®cation is performed on the system to ensure that it is functioning properly.3. Classi®cation labels exist for integrity levels. These classi®cation labels are quite similar to the

levels attached to the security classi®cations used for military information.Each of these assumptions is based on sound reasoning. The design of the system is irrelevant

from the perspective of BibaÕs model. Likewise, the external veri®cation is a realistic condition toexpect before implementation of integrity controls. The existence of integrity classi®cation labelsis quite necessary and not an unreasonable expectation. The conclusion after examining theseassumptions is that the Biba de®nition rests on assumptions that are both necessary and rea-sonable.

Clark±Wilson on assumptions: The Clark±Wilson integrity de®nition incorporates three as-sumptions:1. Data are initially received in a valid state. There is no mechanism available within the model to

test for validity, it is simply assumed.2. The initial integrity veri®cation procedure (IVP), which con®rms that the data items requiring

protection meet certain conditions, is assumed to be a valid process itself.3. It is assumed that the data item and the real-world object that it represents correspond closely.

Each of these assumptions is acceptable, with the possible exception of the assumption con-cerning the integrity of data upon receipt. The assumption that data are in a valid state, specif-ically that they are correct and in their original form, creates a precondition that is not easily met.It is somewhat unrealistic to assume that all data are received in a correct state. Many things canhappen to data to change either their format or content. Designing a system based on an integrityde®nition that requires received data to be in a valid state is probably not the best approach toaddressing the data integrity problem.


The conclusion is that each of the models is based on sound, reasonable assumptions in thisdomain that do not damage its credibility. The necessary assumptions are not liabilities for any ofthe models.

5.2. Concepts on which the model is based

This section examines the central theme of the model and its relation secrecy. It describes theinternal building blocks that serve as the foundation of each model and the modelÕs externalrelationship with the issue of secrecy. These criteria are useful in helping to determine compati-bility with the objectives of the DoDÕs Trusted Computer System Evaluation Criteria.

5.2.1. Central themeThe basic theme of each model should be based on sound, provable principles that make the

model practical rather than simply theoretical. A thorough evaluation of each model's basicconcepts is necessary before a decision can be made concerning acceptance and implementation.The central theme of the model is also important for determining compatibility with DoD re-quirements.

Biba on central theme: The central theme of the Biba model is the development of a hier-archical lattice with the ``no-write-up, no-read-down'' restrictions which is used to identifyauthorized users and separate users by type. This system is e�ective in preventing modi®cationsby unauthorized individuals. Biba implements his ``no-write-up, no-read-down'' restrictionsthrough both mandatory and discretionary controls. Integrity classi®cations with either military-oriented or commercial-oriented labels assign data to di�erent levels. The use of mandatory anddiscretionary controls along with the assignment of classi®cation labels support the centraltheme of this model.

Clark±Wilson on central theme: The Clark±Wilson model is built on two premises: the well-formed transaction and separation of duties. A well-formed transaction is designed so that itallows only authorized modi®cations of data. This transaction will prohibit unauthorized ma-nipulation, thereby preserving the integrity of the data. There is a requirement that the transac-tion, or process, be designed in such a way that the well-formed label may be applied. This is not atrivial matter, especially in large-scale systems.

The separation of duties premise is necessary to preserve a correspondence between data ob-jects and the real-world objects that they represent. This separation prevents unauthorized ma-nipulation by breaking down an operation into several subparts and requiring that each of thesubparts be executed by di�erent individuals. In this way, no one user can execute an entireoperation. Unless there is collusion among users, this will prevent malicious tampering with thedata.

The conclusion of this section is that the central theme of the Biba and Clark±Wilson models islargely practical, thereby making implementation possible.

5.2.2. Relation to secrecyThe second question to be answered in this section concerns the relationship between the

data integrity model and secrecy. This issue is important because of the possible incorporation


of the model into a complete security policy that addresses both disclosure and manipulation.An examination of the two data integrity models in this work and their relationship to secrecywill determine whether they can possibly be incorporated into the TCSEC to ®ll the existingvoid.

Biba on relation to secrecy: Of the two models analyzed, the Biba model has the strongest re-lation to secrecy. Biba takes the Bell±LaPadula model and creates its dual for integrity. Themechanisms in the Bell±LaPadula model are incorporated into Biba thereby allowing for im-plementation of both models simultaneously. The requirement for integrity classi®cation labels inBiba is matched perfectly with the security labels developed in Bell±LaPadula. This ties an in-tegrity policy to a security policy, thereby creating a complete protection policy for access controland modi®cation control of data.

Clark±Wilson on relation to secrecy: The Clark±Wilson model relates to secrecy in that it hasthe ability to limit the data that a user can access. This is a method of disclosure control. Themodel uses separation of duties and well-formed transactions to prevent one user from having theability to execute all steps of one speci®c process. This helps to preserve the integrity of the datawhile at the same time establishing an access control mechanism. Because of this feature, Clark±Wilson has a strong relation to secrecy and also to the requirement for access control thatcharacterizes a secure military system.

The conclusion drawn from the analysis in this area is that the Biba model has a strongerrelation to secrecy.

5.3. Advantages and limitations

The advantages and limitations of each data integrity model must be evaluated and understoodbefore selecting a model for implementation. This section will look at the advantages and limi-tations of each model. An examination of these areas will help determine the suitability of themodel for di�erent applications. It will also help verify whether the weaknesses of the model canproscribe its acceptance.

5.3.1. Description of strengths and weaknessesThe strengths of each model are important for performing an analysis of the bene®ts to be

achieved by accepting the model. This will determine what voids in the current security policy themodel can ®ll. While noting strengths is important, the emphasis in this section is on limitations.This is because the limitations of each model will be the deciding factor in determining whether itcan be accepted and implemented as a standard. If the model has limitations that make it un-acceptable and these limitations cannot be corrected, then the model will be inappropriate, re-gardless of its strengths. If the limitations can be corrected then the model can be considered foracceptance.

Biba's strengths and weaknesses: The main strength of the Biba mode was its attempt to identifyintegrity as the dual of secrecy. Biba used the Bell±LaPadula [5] model, which is concerned withthe unauthorized disclosure of information, and created a similar model to address unauthorizedmanipulation of information. In so doing, Biba was a pioneer in identifying integrity as a topicseparate from secrecy.

A second strength of the Biba model is that it o�ers a variety of policies for both mandatoryand discretionary controls. This variety increases the probability of successful integration of an


integrity policy as part of a security plan. Each of the policies has di�erent requirements andspeci®cations which may or may not ®t into the design of a security plan. The designer of the planhas more than one option available when deciding on an appropriate integrity policy.

Nevertheless, the Biba model su�ers from several weaknesses. It is designed for implementationin systems featuring ring architecture, especially the Multics kernel system. The policies are tai-lored for this system and are not applicable for implementation using other systems.

While approaching integrity as the dual of secrecy, the Biba model ignores the topic of secrecy.Since the Bell±LaPadula model [5], on which the DoD secrecy policies are based, does notcompletely address integrity, Biba attempted to ®ll this void. In doing so, however, he completelyignores a discussion of secrecy. In addition, BibaÕs Strict Integrity Policy does not specify how toassign appropriate integrity labels comparable to the criteria used by government classi®cationsystems for assigning disclosure levels.

Based on the above, the policies presented by Biba are not ¯exible enough for implementationin real-world applications. The policies are not only too Multics speci®c but are also not capableof being altered to ®t into systems that do not conform to the particular policy speci®cations.

Clark±Wilson's strengths and weaknesses: The de®nition of integrity used in the Clark±Wilsonmodel relates to integrity as a concept within the context of a computer system. The model o�ers aworking de®nition that is applied e�ectively to the area of computer data, supports the de®nitiono�ered, and builds a framework that is targeted at maintaining integrity within the scope of thede®nition.

A second advantage of the Clark±Wilson model is that it identi®es the features of a computersystem in which integrity is the main goal. The model provides a blueprint for nine basic rules thatmust be established and implemented in systems that are used to maintain integrity. Adherence tothe rules established in the model will allow the construction of a valid, working integritymechanism.

Several criticisms have been leveled at the Clark±Wilson model. One is its inability to have theintegrity controls strictly internal [19]. The dual process of certi®cation and enforcement takesinto account the environment both internal and external to the system. The enforcement is ac-complished internally by the system itself, while the certi®cation is performed externally by asecurity o�cer. This means that the system will maintain the integrity of data that have beenveri®ed externally before being entered; it may accept data that have been entered incorrectly,whether accidentally or maliciously. External veri®cation declares the data to be in a valid stateand the system then accepts the data and maintains their integrity.

A second criticism of the Clark±Wilson model is that, by requiring IVPs, the model needlesslycomplicates the certi®cation process. As mentioned earlier, it is desirable to shift as much of theveri®cation responsibility to enforcement because enforcement can be done by the system. Sincean IVP is essentially a special type of TP the requirement for IVPs is redundant. This redundancyruns counter to the authorsÕ desire to use minimal certi®cation rules because of the level ofcomplexity and the manual work necessary for certi®cation.

A third criticism of the Clark±Wilson model is that it is applicable only at a single level ofgranularity, which is the size and resolution of the protected system elements. Badger [4] hasdeveloped rules concerning integrity policies and how they relate to the level of granularity. Thedominant rule developed is that at each level of granularity, the integrity policy should specifyhow the state may change in terms of the next lower level of granularity. As it is presented, the


Clark±Wilson model is designed for use at a single granularity level. The inability of the model tobe implemented in a multi-granular environment limits its range of applicability.

5.3.2. Correction of de®cient areasThis section examines the noted weaknesses of the model and attempts to determine whether

they can be corrected. An acceptance decision must be based on a thorough evaluation of themodel's weaknesses. If the weaknesses cannot be overcome then the options available to thedecision maker are limited. The option of accepting the model with modi®cation is eliminated. Ifcorrections can be made, then analysis of the feasibility of making these corrections must be done.The corrections may involve processes which excessively complicate the model and actually createanother weakness while solving the original weakness.

Biba on correction of de®cient areas: As noted, the main weakness of Biba is its heavy orien-tation to ring architecture systems, which makes it somewhat in¯exible. The feasibility of appli-cation to systems featuring other types of architecture must be determined. The principles of themodel are valid for application to any type of system, even though the speci®c details are not, andindeed it can be adapted to other architectures without major modi®cations. In order to addressthe missing issue of secrecy, a plan for integrating an integrity policy into a secrecy policy isneeded to create a security policy that can be considered complete.

Clark±Wilson on correction of de®cient areas: The requirement of Clark±Wilson that certi®-cation is needed for those procedures that access protected data is its main limitation and must bedealt with before acceptance. There is a real need in this model for the procedures to be certi®edfor proper functioning. The assumption that the data were received in a valid state and are,therefore, worthy of protection is acceptable for the data but not for the certi®cation of theprocedures. This limitation cannot be overcome without adversely a�ecting the proper func-tioning of the mechanisms in the Clark±Wilson model.

The analysis performed allows for recommendations to be made concerning the suitability ofthe two data integrity models. The models presented in this paper are suitable candidates for®lling the void described in Section 1. Fig. 6 summarizes the comparison of the two models usingthe evaluation framework, eliciting the following conclusions:1. The Biba data integrity model is capable of implementation in a ring architecture system, but

the integrity de®nition and practical concepts on which it is based are inadequate.2. The Clark±Wilson data integrity model o�ers an adequate integrity de®nition and is based on

sound, provable concepts. With the added capability of integrity label attachment, this is prob-ably a more practical model for acceptance as a standard.

6. Conclusions and recommendations

In their fragmented state, data may appear meaningless, but when viewed in total can con-stitute one of the most critical assets of an organization, and, as such, should be adequatelymanaged and secured. Basic data security techniques have been developed to protect the dataresource, but the emphasis has been placed mainly on secrecy and availability, rather than in-tegrity. Nevertheless, as the organizationÕs data resources grow in size, complexity and value, an


urgent need arises for models and mechanisms to prevent unauthorized manipulation or modi-®cation of data, and for a data integrity standard that will provide a common measure and a set oftools for evaluating the various models and mechanisms in this domain.

The framework proposed in this paper attempts to lay the groundwork for establishing a dataintegrity standard, comprising two elements: the IWG de®nition as a commonly accepted de®-nition for data integrity and the Clark±Wilson model as a recommended data integrity model.Analysis of each model within the guidelines of the framework gives rise to the following con-clusions:

1. While the IWG de®nition of integrity is accepted as a standard for application within theframework, there is no agreement in either the military or commercial environment on a singleacceptable de®nition to serve as a standard. The primary reason for this is the lack of researchin the area of data integrity. Because there exist situations in which unauthorized manipulationmay be more harmful than unauthorized disclosure, data integrity is very much a concern intoday's computer-based information systems.

2. The Clark±Wilson data integrity model is the most appropriate for incorporation into theTCSEC as an integrity standard. It is recommended for the following reasons:

a. The integrity de®nition used in the Clark±Wilson model is both adequate and complete inrespect to the IWG standard and is more appropriate. It is su�ciently broad for applicationin many di�erent environments including the military, surpassing the Biba integrity de®ni-tions in terms of range and applicability.

Fig. 6. Comparison of the data integrity models.


b. The Clark±Wilson model has a strong relation to secrecy. The ability of the model to limitthe data a user can access serves to perform the function of disclosure control. The separationof duties and well-formed transaction concepts limit the ability of any one user to perform allsteps in a process. This has the e�ect of preserving the integrity of the data involved in theprocess.c. The Clark±Wilson model identi®es the features of a system in which integrity is the pri-mary goal. It presents nine rules to implement in order to safeguard the integrity of data usedin the system, as a blueprint for building an e�ective integrity enforcement system.d. The Clark±Wilson model has the potential for integrity labeling similar to military infor-mation classi®cation labeling. At present, it does not have the capability to attach integritylabels, but due to its ability to limit the data that each user can access through the separationof duties and well-formed transaction concepts, the addition of this capability is possible.The Biba model is actually more suitable than Clark±Wilson in this speci®c area in that ithas a greater potential for the successful implementation of labeling. This is due to the rela-tionship of the Biba model to the Bell±LaPadula model for security.e. The Clark±Wilson model has no major limitations. No areas of the model are de®cient en-ough to overshadow its advantages or to prohibit its acceptance. The framework applicationprovides the results which can be used to actually select a single data integrity model for im-plementation within military computer environments.

Based on the conclusions stated in the above section, the following recommendations are made:1. The Clark±Wilson data integrity model should be accepted as the basis for an integrity policy

to be incorporated into the TCSEC.2. A useful implementation of the Clark±Wilson model must include more than TPs, IVPs and

their management and control to ensure integrity of the enterprise. Additional considerations,including speci®c organizational policies for separation of duties and the goals and techniquesassociated with integrity validation, must in¯uence systems analysis and design to ensure thatsystem-implemented and administratively-handled mechanisms interact appropriately to en-sure higher-level integrity objectives [2].

3. The Clark±Wilson model captures a fundamental view of integrity for a trusted system. Ab-rams et al. [2] suggest the following re®nements to the model:

· External consistency and user roles-reserved CDIs encapsulated within vendor supplied TPs.· Separation of duty-primary CDIs and enabling sequences of TPs.· Integrity applied to the mechanisms that implement integrity encapsulate the audit mecha-

nism and provide an append-audit kernel call.· External consistency and I/O device. Ensuring a trusted path for input from a keyboard or

from a terminal associated with a printer, and treating output devices as CDIs.4. The TCSEC and Clark±Wilson model should adopt a data integrity labeling scheme similar to

the scheme which is currently in use for data secrecy. There should be separate levels of integ-rity classi®cations, with all applicable data properly classi®ed. These integrity classi®cationsshould restrict both manipulation and modi®cation with mechanisms in place to allow only au-thorized individuals such privileges. While the integrity labels do not need to be exactly thesame as the Top Secret, Secret, and Con®dential used for security purposes they do need tohave a similar pattern. Labels such as High, Medium, and Low are acceptable provided thatthe mechanism that enforces integrity is capable of determining authorized access requests


from unauthorized requests. There should be three data integrity levels to correspond to thethree data security levels.

5. More research is needed to adapt the Clark±Wilson model to preserve integrity in object-ori-ented database systems. The revised authorization model should be able to support the seman-tic richness of object-oriented data models and the constructs used in these models such asclasses, object instances, versions, and encapsulation.

References

[1] E.M. Awad, M.H. Gotterer, Database Management, Boyd and Fraser Publishing Company, 1992.

[2] M.D. Abrams, E.G. Amroso, L.J. LaPadula, T.F. Lunt, J.G. Williams, Report on an integrity research study group, Computers

and Security 12 (7) (1993) 679±689.

[3] L.K. Barker, L.D. Nelson, Security standards ± government and commercial, AT&T Technical Journal, 1988, pp. 9±18.

[4] L. Badger, A model for specifying multi-granularity integrity policies, in: Proceedings of the 1989 IEEE Symposium on Security

and Privacy, April 1989, pp. 84±91.

[5] D.E. Bell, L.J. LaPadula, Secure Computer Systems: Mathematical Foundations and Model, The Mitre Corporation, Bedford,

MA, November 1973.

[6] E. Bertino, Data security, Data & Knowledge Engineering 25 (1998) 199±216.

[7] K.J. Biba, Integrity Considerations for Secure Computer Systems, The Mitre Corporation, Bedford, MA, April 1977.

[8] S. Ceri, P. Fraternali, S. Paraboschi, L. Tanca, Automatic generation of production rules for integrity constraints, ACM

Transactions on Database Systems 19 (3) (1994) 367±422.

[9] S. Ceri, F. Garziotti, Speci®cation and management of database integrity constraints through logic programming, Polytechnic di

Milano, Technical Report 88-025, 1988.

[10] D.D. Clark, D.R. Wilson, A comparison of commercial and military security policies, in: Proceedings of the 1987 IEEE

Symposium on Security and Privacy, April 1987, pp. 184±194.

[11] C.J. Date, An introduction to Database Systems, sixth ed., Addison-Wesley, New York, 1995.

[12] DoD, Trusted Computer System Evaluation Criteria, US Department of Defense, National Computer Security Center, August

1983.

[13] E.B. Fernandez, R.C. Summers, C. Wood, Database Security and Integrity, Addison-Wesley, New York, 1981.

[14] R.R. Henning, S.A. Walker, Data integrity vs data security: a workable compromise, in: Proceedings of the 10th National

Computer Security Conference, October 1987.

[15] G. Moerkotte, P.C. Lockemann, Reactive consistency control in deductive databases, ACM Transactions on Database Systems,

1991, pp. 52±64.

[16] A., Motro, Integrity� validity + completeness, ACM Transactions on Database Systems, 1989, pp. 480±502.

[17] C. P¯eeger, Security in Computing, second ed., Prentice-Hall, Englewood Cli�s, NJ, 1997.

[18] J.E. Roskos, S.R. Welke, J.M. Boone, T. May®eld, Integrity in the Department of Defense Computer Systems, IDA Paper P-2316,

Institute of Defense Analysis, 1990.

[19] Z.G. Ruthberg, W.T. Polk, Report of the Invitational Workshop on Data Integrity, Government Printing O�ce, 1989.

[20] P. Terry, S. Wiseman, A new security policy model, in: Proceedings of the IEEE Computer Society Symposium on Security and

Privacy, May 1989.

[21] S. Walke, J. Roskos, J. Boone, T., May®eld, Taxonomy of integrity models, implementations and mechanisms, in: Proceedings of

the 13th National Computer Security Conference, October 1990.

[22] S.J. Waters, Methodology of computer systems design, The Computer Journal 17 (1) (1974) 17±24.

[23] M. Zviran, W.J. Haga, Evaluating password techniques for multilevel authentication mechanisms, The Computer Journal 36 (3)

(1993) 227±237.


Moshe Zviran is a senior lecturer ofInformation Systems in the Faculty ofManagement, The Leon RecanatiGraduate School of Business Admin-istration, Tel Aviv University. He re-ceived his B.Sc degree in Mathematicsand Computer Science and M.Sc andPh.D degrees in information systemsfrom Tel Aviv University, Israel, in1979, 1982 and 1988, respectively. Hehas held academic positions at theClaremont Graduate University, CA,the Naval Post graduate School, CA,

and Ben-Gurion University, Israel. His research interests in-clude information systems, planning, development and man-agement of information systems, information systems securityand information systems in health care and medicine. He is alsoa consultant in these areas for a number of leading organiza-tions. Dr. ZviranÕs research has been published in MIS Quar-terly, Communications of the ACM, Journal of ManagementInformation Systems, IEEE Transactions on EngineeringManagement, Information and Management Information Sys-tems, Omega, The Computer Journal, Journal of MedicalSystems and other journals. He is also co-author (with N.Ahituv and S. Neumann) of Informations Systems for Man-agement (Tel Aviv, Dyonon, 1996).

Chanan Glezer is a lecturer of Infor-mation Systems in the Department ofIndustrial Engineering and Manage-ment at Ben-Gurion University of theNegev. Dr. Glezer holds a Ph.D inMIS from Texas Tech University anda M.B.A. and B.Sc in General Sciencefrom Tel Aviv University. His mainresearch interest is in the developmentand evaluation architectures to addressorganizational coordination tasks suchas meeting±scheduling. He is alsoworking on topics such as interopera-

ble electronic product catalogues, network information retrievalsystems, systems integration and management of the IS func-tion. He has published in Communications of the ACM,Journal of Medical Systems, and the Journal of OrganizationalComputing and Electronic Commerce. He has over eight yearsof MIS-related work experience with the Israel Defense Forces,serving as an application programmer systems designer andMIS o�cer.


towards generating a data integrity standard · pdf filetowards generating a data integrity...

Documents