WIXLIB

B. ThuraisinghamlSecurityissues for federatedmust be defined. The various export policies mustbe integrated to form the federated policy.4In the second approach, called the top-downapproach, an FDS is built from scratch. That is, it isnot assumed that component DBSs exist. Based onuser requirements, a federated schema is generatedinitially,and then variouscomponentsareintegrated into the system. The components maybc selected from products already available, ordeveloped from scratch. The components selectedwill depend on the user requirements. If a new userrequirement has to be supported, then the variousschcmas arc analyzed and appropriate modifkations are made. In a multiple environment,afederated security policy is developed first, basedon user requirements. Then the component MIS/DBSs arc selected and appropriate componentpolicies arc devclopcd. Any change in the realworld could result in modificationsto thefederated policy and, consequently, the componentpolitics.The approach that is selected will depend mainlyon whetherthe MLS/FDSconnectsexistingMLS/DBSs or whether the MLS/FDS has to bedesigned from scratch. As MLVDBS componentsbecome available, a bottom-up approach may beneededforensuringsecureintcropcrabilitybetween them. In this paper, we focus on thebottom-up approach to developing an MLS/FDS.2.2. Characteristics of an MLWFDSThe characteristics of an MLS/FDS are multileveldata distribution, heterogeneity,and autonomy.Multileveldata distributionissues have beendiscussed in two earlier articles WC published inthis journal [8, 91. In particular, we discussed issueson fragmentation and replication of multilevel dataand showed how polyinstantiationcould behandledin a distributedcnvironmcnt.Theconcepts and techniques discussed in these articles4The various parts of the security policy and schema for anMLS/FDS will be discussed in Sections 3 and 4, respectively.512database systemscan bc applied to a federated database system,subject to the restrictions imposed by the exportpolicies of the schema. We shall address some ofthe essential points in Section 4 when we describeschema integration and translation issues. In thissection WC focus mainly on heterogeneityandauton0my.j2.2.7. HeterogeneityThere are various types of heterogeneity that needto be addressed for an MLS/FDS. Some types ofheterogeneityarc present in a non-multilevelenvironment.Othersarise due to multilevelsecurity. In this section, we discuss the issuesinvolved in interconnectingheterogeneous components as identified in [l I] and discuss thesecurity impact for each issue. WC shall also discusssome of the additional security concerns.1. Schema (or data model) heterogeneity: Not all of thedatabases in a heterogeneousarchitccturcarcrepresented by the same data model. Therefore, thedifferent conceptual schemas have to be integrated.In order to do this, translators which transform theconstructs of one data model into those of anotherare being developed. In a multilevelsccurcenvironment, the individual data models can bcmultilevel. That is, a data model has multilevelsecurity constructs incorporated into it. Therefore,the constructs of one multilevel data model have tobe transformed into those of another. During thetranslation process, it should be cnsurcd that a userwho does not have access to a particular entity withrespect to one data model must not have access tothe same entity with respect to a different datamodel.The object-oriented approach is also being investigated for handling schema heterogeneity. The ideahere is for the users to have a generic view of the%otne of the issues were presented in a panel discussion by theauthorat the 5th IFIP WorkingConfcrenccon DatabaseSecurity in Shephcrdstown,West Virginia, November199 1. Adiscussion of hcterogcueousdatabase integrationissues is alsogiven in [ 101.

Computers & Security, Vol. 13, No. 6entire system. Translators are then necessary totranslate the constructs from/to the generic representation to/from an individual representation. Ifthe object-orientedapproach is to be utilized in amultilevel environment, then a multilevel secureobject-oriented data model has to be developed forthe generic representation.62. Transactionprocessing heterogeneity:DifferentDBMSs may utilize different algorithms for transaction .processing. Work is being directed towardintegratingthe various transactionprocessingmechanisms.For example,techniqueswhichintegrate locking, timestamping,and validationmechanisms are being developed. It has been notedthat the standard concurrency control algorithmshave security vulnerabilities. For example, a lockingmechanismcould be used to covertly signalinformationfrom a higher-levelprocess to alower-level one. As a result, various concurrencycontrol mechanisms have been adapted to functionin a multilevel environment. However, integrationof these adapted concurrency control algorithms tofunction in a heterogeneous environment needs tobe investigated.3. Query processing heterogeneity: Different DBMSsutilize different query processing and optimizationstrategies. One of the research areas here is todevelop a global cost model for distributed queryoptimization.In a multilevel environment,theindividual cost models may depend on the securitypolicy enforced, the storage mechanism used, andthe amount of data classified. The global costmodel could then depend on the global securitypolicy that is enforced.4. Query language heterogeneity: Different DBMSswill utilize different query languages. Even if theDBMSs arc based on the relational model, onecould use SQL and the other could USC relationalcalculus. Standardization efforts are underway todevelop a uniform interface language. The security6Keccntly, we have proposedan object-orientedapproachthe intcroperabilityof hcterogcneousdatabase systems.toimpact on these efforts needs to be investigated.For example, various extensions to SQL are beingproposed to handle security constructs. Differentdesigns are proposing different extensions. Theseextensions need to be integrated so that a uniforminterface is provided to the user.5. Constraintheterogeneity:DifferentDBMSsenforce different integrity constraints which arcoften inconsistent. For example, one DBMS couldenforce a constraint that all employees must workat least forty hours while another DBMS may notenforce such a constraint. In a secure environment,additional constraints such as discretionary securityconstraints and mandatory security constraints maybe enforced. The constraints enforced at differentcomponents may be conflicting. These differencesneed to be reconciled.Semantic heterogeneity: Data may be interpreteddifferently at different components. For example,the entity address could mean just the country atone component while another component couldinterpret it to be the number, street name, cityname, and country. It has been recognized thatsemantic heterogeneity is very difficult to handle[12]. The problems are even worse in a multilevelenvironment. For example, a security label at onecomponent could mean something different atefforts arcanother component. Standardizationneeded to resolve such inconsistcncies.76.7. Other security issues: In addition to the securityimpact on the various issues identified for heterogeneousdatabasesystems,thereare someadditional security concerns. These include the following:(a) Different security policies: Each DBMS couldenforce its own security policy for mandatory aswell as discretionary security. In addition, different71t has been pointed out to us that handling label heterogeneityis a networksecurity issue. Marc work needs to be done todeterminewhetherany other componentof the MLS/FDSshould also handle label heterogeneity.513

B. ThuraisinghamlSecurityissues for federa ted database systemsauthentication and integrity mechanisms may beused. For example, one system could enforce a ‘readat or below your level’ and ‘write at your levelpolicy while another system could enforce a ‘readat or below your level’ and ‘write at or above yourlcvcl’ policy. The different policies have to bcintcgratcd in order to provide a global securitypolicy.(b) Different granularity of classification: Even ifthe relational data model is utilized at all nodes, thegranularity of classification could be different. Forexample, one system could enforce classification atthe tuplc level while the other system couldenforce classification at the clement level. Furthcrmore, one system could support the representationof cover stories by enabling two different tupleswith the same primary key to exist at differentsecurity levels while the other system may notpermit the entity integrity property to be violated.Such differences may need to be handled at theglobal level.(c) Different classifications of the same entity: Anentity could be classified at the Secret level at onenode and yet bc classified at the TopSccret level atthe second node. If this is the case, then the globalpolicy should resolve such inconsistencies. One canregard this as a form of polyinstantiation.(d) Different semantics of classification levels: Aclassification level at one node could mean somcthing cntircly different at another node. This is aform of semanticheterogeneity.The globalsecuritypolicymay have to resolvesuchinconsistencies.(e) Different accreditation ranges: One node couldhandle the range from Unclassified to Secret whileanother node could handle the range Confidentialto Top&ret.If a TopSecret user needs to accessthe Unclassified information handled by the firstnode, then it should be ensured that informationfrom the TopSecrct user is not transmitted covertlyinto the node handling the Unclassified data.’514Much research needs to bc done if solutions are tobe provided for the secure interoperabilityofhcterogencousdatabase systems. The problembecomes even more complex if there arc scvcraltypes of heterogeneity. For example, the varioussystems could not only enforce different securitypolicies but also utilize different multilevel datamodels. WC feel that any solution to the problemin the near term should be customized. That is, thecustomers’ requirements should be identified andsolutions to satisfj the requircmcnts need to beprovided.2.2.2. AutonomyThe components of an MLS/FDS may have somedegree of autonomy. The DBA/SSO of each component could decide who has access to the data hecontrols. There are various types of autonomy thata component could exhibit. They include: n autonomy, and design autonomy. Wediscuss each type.Communicationautonomy: Total communicationautonomy implies that a component will detcrmine with whom it wishes to communicate. Thcrcis an additional restriction in a multilevel environment, as a machine handling only Secret and TopSecret data cannot send data to a machineaccrcditcd to process only Unclassified and Confidential data.Execution autonomy: Total execution autonomyimplies that the local operations of a component“It has been pointed out to us that a cascading problem couldoccur when the nodes handle different accreditationranges. Forexample, node 1 handles the range Unclassifkdto Confidcntial, node 2 handles the range from Confidentialto Secret, andnode 3 handles the range from Secret to TopSecret. Suppose aTopSecret user poses a query at node 3 and data from nodes 1and 2 are needed for the response. Then the query is downgraded and sent to node 2 via a Secret connectionand fromnode 2 it is downgradedand sent to node 1 via a Confidentialconnection.Some TopSccretcould then be covertlypassedfrom node 3 to the Unclassifiedlcvel at node 1 via node 2.

Computers & Security, Vol. 13, No. 6are not affected by the federated users in any way.This could cause a problem in a erated user might issue the execution of a transaction at a particular component. If there is alreadya Secret local transaction waiting to be executed atthat component, total autonomy would mean thatthe Unclassified transaction must wait. That is, theactions of a higher level user have interfered with alower level one. This could cause a potential covertchannel.Association atrtonomy: Total association autonomyimplies that a component can decide when andwhat information to share with the others. In thecase of a federated environment, it can also decidewhen to join a federation, when to leave a federation, and which federations to join. Data replication would conflict with association autonomy. Forexample, if data managed at component 1 is replicated at component 2, then if component 1 decidesto leave the federation, the data at component 2should also be removed. However, for securityreasons, one might want to replicate lower-leveldata at higher levels. This constrains associationautonomy.Design autonomy: Total design autonomy wouldimply that each component will have the ability tochoose its own design. For example, it could determine (1) the multilevel data to be managed, (2) thesecurity policy to be enforced, (3) the queryprocessing and transaction management algorithmsto be used, and (4) the semantic interpretation ofdata and labels. One of the difficulties in developing an MLYFDSis the integration of differentsecurity policies. Different policies exist due todesign autonomy.In addition to the various issues discussed here, oneof the major concerns of a secure environment isaccreditation. If the components have autonomy,then the individual DAAs will have the freedom toaccredit their own systems. However, in order toaccredit the h4LS/FDS as a whole, there must besome negotiation between the different DAAs andthe federated DAA. That is, we introduce anadditional type of autonomy called ‘Accreditationautonomy’.3. Securitypolicy issuesIn this section, we discuss issues on developing asecurity policy for an MIXFDS.In Section 3.1, wedescribe a security policy architecture for an MIS/FDS. In Section 3.2, we discuss issues on generatingthe security policy. In Section 3.3, using anexample, we discuss how the security policy may beenforced. In Section 3.4, we discuss the contents ofa security policy for an h4LYFDS.3.1.Securitypolicy architectureFigure 2 illustrates our view of a security policyarchitccturcfor an MLVFDS.Each componentenforces its own security policy. The policy willspecify the various subpolicies for mandatorysecurity, discretionary security, integrity, identification and authentication, and auditing. The component policy itself may bc a combinationofmultiple security policies where each individualpolicy will be that of a local MLS/DBS which ispart of the component.Each component security policy is specific to thecomponent and is specified in a language that ischosen by the DBA/SSO of that component. However, in order to facilitate the integrationofmultiple policies, each component policy must betransformed into a generic component policy. Thisgeneric policy is identical to the component policybut is specified in a generic language. All components that wish to be part of the federation mustUSC the same language for the generic policy. Thegeneric language may be determined by ncgotiation between the component DBA/SSOs and thefederated DBA/SSO.”9Genericrepresentationshave played an importantrole ininterconnectingdifferent computingsystems. We b&wethatthey will also be useful for specifyingsecurity politics. Thiswill also facilitatethe task of integratingdifferentsecuritypolitics.515

B. ThuraisinghamlSecurityissues for federa ted database systemsExport Policyfor Component BFiz. 2. ComponentsOnce the generic policy is specified, the DBA/SSOof a component may want to impose more severerestrictions on the federated user. That is, a localuser may have more privileges than a federateduser. lo Therefore, the DBA/SSO must generate anexport policy which may be different from thegcncric policy. The export policy is also specified inthe generic language. For example, the DBA/SSOmight want only the federated users cleared at theTopSecret level to have access to his data classifiedat the Secret level. Even when generating theexport policy, there may have to be some form ofnegotiation between the component DBA/SSOsand the federated DBA/SSO.Once the exportponent DBA/SSOpolicy is generated, the comno longer has any control. It is‘01n general, as far as a componentis concerned,there are onlytwo types of user: local and foreign. Foreign users are the federated users.516of rhc securitypolicy.now up to the DBA/SSO of the MLS/FDS to combine all of the export policies and then generate afederated policy. The federated policy must includeall restrictions enforced by the individual DBA/SSOs. In addition, the DBA/SSO of the MLS/FDSmay impose some additional restrictions such asdiscretionary access rules for various groups offederated users. It is usually the responsibility of theDBA/SSOof the MLS/FDSto differentiatebetween various classes of federated users.In Fig. 2, WC assume that there are three components: A, B, and C. A and B form a federationwhile B and C form a second federation. That is, Bis involved in multiple federations. Although itneed not be the case, we have assumed that bothfederations USC the same generic language forrepresenting policies. Also, component A is anMLS/DBS which consists of two centralized MLS/DBSs. The two local policies will be combined toform the policy for component A.

Computers & Security., Vol. 73, No. 63.2.Generatingthe securityenvironment, each component may decide to joinor leave a federation at any time. This would meanthat the federated policy must be modifiedwhenever such a decision is made.policyFigure 3 illustrates the various processors whichtransform one security policy into another. If thesecurity policy is static, then all of the transformations can bc done bcforc the system is in operation.However, if the environment is dynamic, then thevarious transformationsmay have to be doneduring system operation. These transformationsneed to be performed by a subject acting on behalfof the DBALSSO. The transformation process canbe quite complex, especially if the applicationspecific policy is complex. Also, in a federatedA transforming processor transforms a componentpolicy to a generic component policy. No additionalinformation is generated during this transformation process. However, it must be ensured thatthe transformation is complete. A transforming/filtering processor examines the generic comthatponent policy, may remove informationFederatedPolicyFederatedPolicyfor MLSfFDS - 2for h#LS/FJX - 1Export Policyfor Component AExport Policyfor Component BExport Policyfor Component CIIIansfo o g/F l eriIIIGeneric Policyfor Component AGeneric Policyfor Component BGeneric Policyfor Component CTransformingProcessorComponent ) policyfor Component AConstructingProcessorLocalPolicy 1LoCalPolicy 2Fig. 3. Generatingthe securitypolicy517

8. ThuraisinghamlSecurityissues for federa ted database s ys ternsrRequest from federated user cleared to readlabeled A (2 B, C, D) or belowFig. 4. A scenarioillustratingis not relevantto the federateduser, andmay transform or add other information.Forexample, all of the schemas may not be exportedand therefore any policy rules specific to theeliminated schemas are removed. Also, additionalpolicies rules may be enforced for the federateduser. That is, the transforming/filteringprocessormay impose additional restrictions. The output ofthe transforming/filteringprocessor is the exportpolicy. ” A constructing p rocessor integrates all ofthe export policies and generates the federatedpolicy. The information required by the transforming, filtering, and constructing processors to carryout their operations is separate from the policyinformation.Maintainingthe consistencyof a componentsecurity policy is the responsibility of the DBA/SSO of that component. The transforming and filtcring processors of a component must ensure thatconsistency is maintained when the generic andexport policies are generated. Maintaining the consistcncy of the fcdcratcd policy is the responsibility“Note that this deviates slightly from the schema architectureof Sheth and Larson [I 1,In that architecture,a filtering processortakes the generic schema and generates the export schema sincethe export schema is a subset of the generic schema. However,it has been pointed out to us that this may not bc the cast forsecurity policies.518data access by a fcderatcduser.of the federated DBA/SSO. The constructing processor, which generates the federated policy fromthe export policies, must rcsolvc any incons

previous work in multilevel secure distributed database management systems and on the results of others' work in federated database systems. In particular, we define a multilevel secure federated database system and discuss issues on hetero- geneity, autonomy, security policy and architecture.