Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Data and Applications Security Developments and Directions Dr. Bhavani Thuraisingham The University of Texas at Dallas Multilevel Secure Data Management February 3, 2012 Outline What is an MLS/DBMS? Summary of Developments Challenges MLS/DBMS Designs and Prototypes Data Models and Functions Directions What is an MLS/DBMS? Users are cleared at different security levels Data in the database is assigned different sensitivity levels-- multilevel database Users share the multilevel database MLS/DBMS is the software that ensures that users only obtain information at or below their level In general, a user reads at or below his level and writes at his level Why MLS/DBMS? Operating systems control access to files; coarser grain of granularity Database stores relationships between data Content, Context, and Dynamic access control Traditional operating systems access control to files is not sufficient Need multilevel access control for DBMSs Summary of Developments Early Efforts 1975 – 1982; example: Hinke-Shafer approach Air Force Summer Study, 1982 Research Prototypes (Integrity Lock, SeaView, LDV, etc.); 1984 - Present Trusted Database Interpretation; published 1991 Commercial Products; 1988 - Present Air Force Summer Study Air Force convened a summer study to investigate MLS/DBMS designs Then study was divided into three groups focusing on different aspects Group 1 investigated the Integrity Lock approach; Trusted subject approach and Distributed approach Group 2 investigated security for military messaging systems Group 3 focused on longer-term issues such as inference and aggregation Outcome of the Air Force Summer Study Report published in 1983 MITRE designed and developed systems based on Integrity Lock and Trust subject architectures 1984 - 1986 Rome Air Development Center (RADC, now Air Force Research Lab) funded efforts to examine long-term approaches; example: SeaView and LDV both intended to be A1 systems RADC also funded efforts to examine the distributed approach Several prototypes and products followed TDI Trusted Database Interpretation is the Interpretation of the Trusted Computer Systems Evaluation criteria to evaluate commercial products Classes C1, C2, B1, B2, B3, A1 and Beyond TCB (Trusted Computing Base Subsetting) for MAC, DAC, etc. (mandatory access control, discretionary access control) Companion documents for Inference and Aggregation, Auditing, etc. Taxonomy for MLS/DBMSs Integrity Lock Architecture: Trusted Filter; Untrusted Back-end, Untrusted Front-end. Checksum is computed by the filter based on data content and security level. Checksum recomputed when data is retrieved. Operating Systems Providing Access Control/ Single Kernel: Multilevel data is partitioned into single level files. Operating system controls access to the filed Extended Kernel: Kernel extensions for functions such as inference and aggregation and constraint processing Trusted Subject: DBMS provides access control to its own data such as relations, tuples and attributes Distributed: Data is partitioned according to security levels; In the partitioned approach, data is not replicated and there is one DBMS per level. In the replicated approach lower level data is replicated at the higher level databases Integrity Lock Trusted Agent to compute checksums Sensor Untrusted Compute Checksum Based on stream data value and Security level; Store data value, Security level and Checksum Data Manager Database Compute Checksum Based on data value and Security level retrieved from the stored database Operating System Providing Mandatory Access Control Unclassified device Secret device TopSecret device Multilevel Data Manager Unclassified Data Secret Data TopSecret Data Extended Kernel Kernel Extensions To enforce additional security policies enforced on data e.g., security constraints, privacy constraints, etc. Multilevel Data Manager Multilevel Data Trusted Subject Unclassified device Secret device Multilevel Data Manager Trusted Component Multilevel Data TopSecret device Distributed Approach - I Trusted Agent to manage Aggregated Data Unclassified Secret Data Manager Data Manager Unclassified Data Secret Data TopSecret Data Manager TopSecret Data Distributed Approach II Trusted Agent to manage Aggregated Data Unclassified Secret Data Manager Data Manager Unclassified Data Secret + Unclassified Data TopSecret Data Manager TopSecret Secret + Unclassified Data Overview of MLS/DBMS Designs Hinke-Schaefer (SDC Corporation) Introduced operating system providing mandatory access control Integrity Lock Prototypes: Two Prototypes developed at MITRE using Ingres and Mistress relational database systems SeaView: Funded by Rome Air Development Center (RADC) (now Air Force Rome Laboratory) and used operating system providing mandatory access control and introduced polyinstation Lock Data Views (LDV) : Extended kernel approach developed by Honeywell and funded by RADC and investigated inference and aggregation Overview of MLS/DBMS Designs (Concluded) ASD, ASD-Views: Developed by TRW based on the Trusted subject approach. ASD Views provided access control on views SDDBMS: Effort by Unisys funded by RADC and investigated the distributed approach SINTRA: Developed by Naval Research Laboratory based on the replicated distributed approach SWORD: Designed at the Defense Research Agency in the UK and there goal was not to have polyinstantiation Some MLS/DBMS Commercial Products Developed (late 1980s, early 1990s) Oracle (Trusted ORACLE7 and beyond): Hinke-Schafer and Trusted Subject based architectures Sybase (Secure SQL Server): Trusted subject ARC Professional Services Group (TRUDATA/SQLSentry): Integrity Lock Informix (Informix-On-LineSecure): Trusted Subject Digital Equipment Corporation (SERdb) (this group is now part of Oracle Corp): Trusted Subject InfoSystems Technology Inc. (Trusted RUBIX): Trusted Subject Teradata (DBC/1012): Secure Database Machine Ingres (Ingres Intelligent Database): Trusted Subject Some Challenges: Inference Problem Inference is the process of forming conclusions from premises If the conclusions are unauthorized, it becomes a problem Inference problem in a multilevel environment Aggregation problem is a special case of the inference problem - collections of data elements is Secret but the individual elements are Unclassified Association problem: attributes A and B taken together is Secret - individually they are Unclassified Some Challenges: Polyinstantiation Mechanism to avoid certain signaling channels Also supports cover stories Example: John and James have different salaries at different levels EMP SS# Name 1 2 3 1 4 3 John Paul James John Mary James Salary 20 30 40 70 80 60 Level U U U S S S Some Challenges: Covert Channel Database transactions manipulate data locks and covertly pass information Two transactions T1 and T2; T1 operates at Secret level and T2 operates at Unclassified level Relation R is classified at Unclassified level T1 obtains read lock on R and T2 obtains write lock on R T1 and T2 can manipulate when they request locks and signal one bit information for each attempt and over time T1 could covertly send sensitive information to T1 Multilevel Secure Data Model: Classifying Databases DATABASE D: Level = Secret EMP SS# Ename DEPT Salary D# D# Dname Mgr 1 John 20K 10 10 Math Smith 2 Paul 30K 20 20 Physics Jones 3 Mary 40K 20 Multilevel Secure Data Model: Classifying Relations EMP: Level = Secret SS# Ename DEPT: Level = Unclassified Salary D# D# Dname Mgr 1 John 20K 10 10 Math Smith 2 Paul 30K 20 20 Physics Jones 3 Mary 40K 20 Multilevel Secure Data Model: Classifying Attributes/Columns EMP SS#: S Ename: U DEPT Salary: S D#: U D#: U Dname: U Mgr: S 1 John 20K 10 10 Math Smith 2 Paul 30K 20 20 Physics Jones 3 Mary 40K 20 U = Unclassified S = Secret Multilevel Secure Data Model: Classifying Tuples/Rows EMP SS# Ename DEPT Salary D# Level D# Dname Mgr Level 1 John 20K 10 U 10 Math Smith U 2 Paul 30K 20 S 20 Physics Jones C 3 Mary 40K 20 TS U = Unclassified C = Confidential S = Secret TS = TopSecret Multilevel Secure Data Model: Classifying Elements EMP SS#: DEPT Ename: Salary D#: 1, S John, U 20K, C 10, U 2, S Paul, U 30K, S 3, S Mary, U 40K, S D#: U Dname: U Mgr: S 10, U Math, U Smith, C 20, U 20, U Physics, U Jones, S 20, U U = Unclassified C = Confidential S = Secret Multilevel Secure Data Model: Classifying Views SECRET VIEW EMP (D# = 20) SS# EMP SS# Ename Salary D# 1 John 20K 10 2 Paul 30K 20 3 Mary 40K 20 4 Jane 20K 20 Ename Salary 2 Paul 30K 3 Mary 40K 4 Jane 20K 1 Michelle 30K UNCLASSIFIED VIEW EMP (D# = 10) 5 Bill 20K 10 6 Larry 20K 10 1 Michelle 30K 20 SS# Ename 1 John Salary 20K 5 Bill 20K 6 Larry 20K Multilevel Secure Data Model: Classifying Metadata Relation REL Relation EMP EMP EMP EMP DEPT DEPT DEPT Attribute SS# Ename Salary D# D# Dname Mgr Level Secret Unclassified Confidential Unclassified Unclassified Unclassified Confidential MLS/DBMS Functions Overview Multilevel Secure Database Functions: Query Processing: Enforce mandatory access control rules during query processing; inference control; consider security constraints for query optimization Transaction management: Check whether security constraints are satisfied during transaction execution; Concurrency control algorithms that prevent covert challenges; Ensure actions of higher level processes do not affect those of lower level processes Metadata management: Classify metadata in such a way that information is not leaked to lower levels Storage management: Ensure that security levels are assigned to storage structures so that information is not leaked to lower levels Integrity management: Example: payload problem. Ensure that integrity constraints enforced at lower level do not take into consideration high level data MLS/DBMS Functions Secure Query Processing Secure User Interface Manager Query Modifier Secure Query Transformer Secure Database Response Manager Secure Query Optimizer Secure Storage Manager MLS/DBMS Functions Secure Transaction Management O is updated to O’’ Unclassified Object O Unclassified Process reads from and writes into the object O’ O* is a copy of O”. Essentially O’ is updated to O* at the Secret level Copy O’ of Object O At the Secret level Secret Process reads from The object O’ MLS/DBMS Functions Secure Integrity Management Integrity Management: TopSecret Constraint: Maximum weight of an aircraft is 1000 lbs Unclassified level: Weights are added but the TopSecret constraint is not visible; Unclassified level there is no constraint Problem: If TopSecret constraint is checked at the Unclassified level it is a security violation; if not it could cause serious integrity Problems Challenge: Enforce constraints in such a away that high level constraints do not affect lower level operations Polyinstantiaon also introduces integrity problems Status and Directions MLS/DBMSs have been designed and developed for various kinds of database systems including object systems, deductive systems and distributed systems Provides an approach to host secure applications Can use the principles to design privacy preserving database systems Challenge is to host emerging secure applications including e- commerce and biometrics systems