| P. Stachour and B. Thuraisingham. Design of LDV: A multilevel secure relational database management system. IEEE Trans. Knowledge and Data Eng., 2(2):190--209, 1990. |
.... There is extensive literature on access control and encryption that is relevant [12] 38] 45] 46] Hippocratic databases will also benefit from the work on database security [7] 30] Of particular interest is work on multilevel relations in the context of multilevel secure databases [23] 24] [50]. It allows multiple levels of security (e.g. top secret, secret, confidential, unclassified) to be defined and associated with individual attribute values. The security level of a query may be higher or lower than that of individual data items. A query with a lower level of security cannot read ....
....our example, Figure 3 shows the schema of the two tables, customer and order, that store the personal information collected by Mississippi. Notice that we have added a special attribute, purpose , to each table, which is similar to attaching security level with records in secure databases [24] [50]. Mississippi s privacy policy for the purchase, registration, recommendations and purchasecircles purposes are shown in Figure 4. For the purchase ffl all the attributes have a retention period of 1 month, ffl the name and shipping address are given to the delivery company, and ffl the name and ....
[Article contains additional citation context not shown here]
P. Stachour and B. Thuraisingham. Design of LDV: A multilevel secure relational database management system. IEEE Trans. Knowledge and Data Eng., 2(2):190--209, 1990.
....by combining meta data with non confidential data to disclose confidential information. Since the beginning of 1980s, researchers, focusing on multi level secure relational databases, identified the problem of indirect access to confidential data via combining meta data with non confidential data [GM84,Mor88,SO87,Hin88,Smi90,Buc90,Den85,Thu87,MSS88,RJHS95,ST90]. However, these techniques often result in over classification of data and, therefore reduce data availability. Moreover, most authors, with the exception of [Den85,Hin88,SO91,DdVS99a,DdVS99b] do not consider the problem of actual inference for specific families of constraints; rather they ....
P.D. Stachour and B. Thuraisingham. Design of LDV: A multilevel secure relational database management system. IEEE Trans. Knowledge and Data Eng., 2(2):190--209, June 1990.
....levels of some of the data items [2, 4 6, 7, 12, 17, 9, 13, 14, 16, 3, 4] These techniques often result in over classification of data and, therefore, reduce the availability of data. Techniques in the second category seek to eliminate inference channel violations during query time [5, 11, 15, 18]. If an inference channel is detected, the query is either refused or modified to avoid security violations. Each of the categories above requires either data dependent or data independent inference algorithms. However, none of the above works has the formal notion of soundness and completeness ....
....either data dependent or data independent inference algorithms. However, none of the above works has the formal notion of soundness and completeness for data dependent and data independent disclosure, and thus cannot establish these formal properties of disclosure inference. Also, most authors [2, 6, 13, 14, 11, 15, 18], with the exception of [5, 7, 16, 3, 4] do not consider the problem of actual inference for specific families of constraints (and its decidability, soundness, completeness, etc. rather they develop a framework, assuming that disclosure inference algorithms are readily available. It is our ....
P.D. Stachour and B. Thuraisingham. Design of LDV: A multilevel secure relational database management system. IEEE Trans. Knowledge and Data Eng., 2(2):190--209, June 1990.
....to outline this research area. 2 Related Work The problems of providing access to certain types of information, while restricting access to other types of information (access control) have been studied extensively by the database security community. In particular, multilevel secure databases [ST90] have been developed as a means of enforcing access control policies that limit sharing of information to those with appropriate authority. However, the adequacy of such controls has always been suspect due to the inference problem : How do we ensure that we cannot infer private data from ....
Paul D. Stachour and Bhavani M. Thuraisingham. Design of LDV: A multilevel secure relational database management system. IEEE Transactions on Knowledge and Data Engineering, 2(2):190--209, 1990. 5
....aggregation#. For instance, the approach described byFernandez in #Fernandez et al. 1989# proposes an access control model that de#nes authorisation inheritance through data hierarchies. The second type of extension has lead with the concept of multilevel access control #Jajodia and Sandhu 1991# #Stachour and Thuraisingham 1990# where relations are made to appear di#erent to users with di#erent clearances as not all clearances may authorise the subjects to all objects. Winslett in #Winslett et al. 1994# further extends this paradigm to de#ne formal query languages for secure relational databases. Lunt in #Lunt et al. ....
Stachour, P. and Thuraisingham, B. #1990# Design Of LDV: A Multilevel Secure Relational Database Management System. IEEE Transactions On Knowledge and Data Engineering, 2#2#, 190-209.
....approximating queries on sub cubes from higher level aggregations (e.g. BS97] However, these works did not have to cope with information that has been intentionally distorted. Closely related, but orthogonal to our work, is the extensive literature on access control and security (e.g. Din78] ST90] Opp97] RG98] Whenever sensitive information is exchanged, it must be transmitted over a secure channel and stored securely. For the purposes of this paper, we assume that appropriate access controls and security procedures are in place and effective in preventing unauthorized access to the ....
P.D. Stachour and B.M. Thuraisingham. Design of LDV: A multilevel secure relational database management system. IEEE Trans. Knowledge and Data Eng., 2(2):190--209, 1990.
....in a tuple which looks to them to be null. The element is not null and it contains data with a higher security level. Thus a second tuple is added to the relation with the same primary key but different security level [93] Several mandatory access control models for RDBS have been proposed so far [35, 36, 52, 62, 69, 75, 90, 91, 96, 128]. The main difference among the models is the way they solve the integrity and polyinstantiation problems. Let us consider three such models whose security evaluation classification was aimed to be at Class A1 2 level. They are as follows. ffl SeaView. The SeaView project has its roots in the ....
....However because of classification constraints, some of data elements that make up a tuple could be stored at security level above the tuple security level. TCB enforces the constraint that the level at which data is stored is the lowest security level at which the data can be retrieved. See [128, 129] for detailed discussion. ffl ASD Views. The ASD Views is a prototype developed at TRW Defense System Group. The main aim for the ASD Views project was to achieve a suitably sized Trusted Computing Base (TCB) that met the criteria for evaluation of class B2 and above. The main feature of the ....
P. D. Stachour and B. Thuraisingham. Design of LDV: A Multilevel Secure Relational Database Management System. IEEE Transactions on Knowledge and Data Engineering, 2(2):190--209, June 1990.
....a as a value. 5 0 . Same as step 4 of the original algorithm. Our decomposition as well as recovery algorithms will have to be modified to accommodate the single tuple per tuple class approach of [19] or the closely related single maintenance level attribute approach adopted by the LDV model [10, 21]. These modifications are straightforward. This brings us to the dynamic mvd requirement proposed in [18] It too will require modifications to both our decomposition and recovery algorithms along the lines discussed in [15] The major difference is that in the single level relations D c we will ....
Stachour, P. D. and Thuraisingham B. "Design of LDV: A Multilevel Secure Relational Database Management System." IEEE Trans. on Knowledge and Data Engineering, 2(2):190-209 (June 1990).
....available to all users without control. Thus, security offered in object oriented approaches cannot differentiate between user needs based on their individual responsibilities. Research and development for access control in databases has traditionally taken an approach based on security clearance [12, 13, 18, 19, 22, 29, 35, 36] using the Bell and Lapadula security model [3] These multi level secure approaches support mandatory access control (MAC) to classify and tag data with relevant security levels. To complement MAC, discretionary access 1 INTRODUCTION 3 control (DAC) has been proposed [21, 30, 34] to allow ....
P. Stachour and B. Thuraisingham, "Design of LDV: A Multilevel Secure Relational Database Management System", IEEE Trans. on Knowledge and Data Engineering, Vol. 2, No. 2, June 1990.
.... Aggregation constraints are similar to classification constraints, except the assigned security levels are applied only to the entire aggregate, and not to the individual elements [Denning 86a] The module responsible for this examination may reclassify the query result based upon the constraints [Stachour 90] The aggregation levels are then used to restrict how much data can be released to a given user. The constraints are enforced by building a rule based classification scheme into the pipelines. In addition, a history recording mechanism is consulted and updated whenever a query response is ....
P. Stachour, and B. Thuraisingham. Design of LDV: A Multilevel Secure Relational Database Management System. In IEEE Transactions on Knowledge and Data Engineering, Vol. 2., No. 2, pp. 190-209, June 1990.
.... For many years, many database security researches have been done to extend the classical relational model to obtain multilevel relations (see for example [6, 9, 10, 13, 29] As a result of such work, multilevel relational databases have been developed not only as prototypes but also as products [26, 21]. In recent times several secure models for object oriented database are proposed. Some proposals consider single level object. Every object is assigned a unique security level that applies to entire object [23, 28] This approach is attractive for its simplicity and its compatibility with a ....
P. D. Stachour and B. Thuraisingham. Design of LDV: A Multilevel Secure Relational Database Management System. IEEE Transactions on Knowledge and Data Engineering, 2(2):190--209, June 1990.
....a physical implementation of the secrecy characterization introduced in Section 2 all secrecy constraints on the data and on query results (C1a, C1g) can be expressed in mandatory protection systems. MAC policies are implemented (C2a) in several academic prototype systems (for example, 28] [29]) and many commercial system providers have announced or already introduced commercial products (to name only a few: Ingres, Oracle, Sybase, Trudata) Most systems use the nucleus of commercial products extended by a trusted software component supporting MAC. This has the advantage that existing ....
P. D. Stachour, M. B. Thuraisingham. Design of LDV: A multilevel secure relational database management system. IEEE Trans. on Knowledge and Data Engineering (TKDE), Vol. 2, No. 2, (1990).
No context found.
STAC90 Stachour, P. D. and B. M. Thuraisingham, "Design of LDV: A Multilevel Secure Relational Database Management System," IEEE Transactions on Knowledge and Data Engineering, VoI. 2, No. 2, pp. 190-209, lEEE, June 1990.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC