1 / 33

Information Security Analytics

Information Security Analytics. Dr. Bhavani Thuraisingham The University of Texas at Dallas Multilevel Secure Data Management September 2013. Outline. What is an MLS/DBMS? Summary of Developments Challenges MLS/DBMS Designs and Prototypes Data Models and Functions Directions.

gypsy
Download Presentation

Information Security Analytics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Information Security Analytics Dr. Bhavani Thuraisingham The University of Texas at Dallas Multilevel Secure Data Management September 2013

  2. Outline • What is an MLS/DBMS? • Summary of Developments • Challenges • MLS/DBMS Designs and Prototypes • Data Models and Functions • Directions

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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.

  9. 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 • 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 • Extended Kernel: Kernel extensions for functions such as inference and aggregation and constraint processing

  10. Integrity Lock

  11. Operating System Providing Mandatory Access Control • Operating system has the TCB; Data manager is untrusted • An instance of the data manager is created at each level (e.g., U, S, TS); note: only one data manager (e.g., Oracle) but multiple instances (processes) • Secret user/device enters data and the Secret instance will write the data to the Secret operating system file • Operating system will control the write operation to the operating system file • Secret user/device queries for data • Secret instance will open both Secret and Unclassified operating system files and read from them, recombine the data and give the data to the Secret user • Operating system will control the read operation to the operating system files

  12. Trusted Subject • All the data is in the multilevel database and stored at the highest level (labels are attached to the data) • When a user queries or writes, the trusted component (the database TCB) will read and write from/into the multilevel database according to the policy • Read at or below your level and write at your level

  13. Distributed Approach – I: Partition • Secret user update (write) will go to Secret data manager via the trusted agent • Secret user query will go to the Secret data manager and the Unclassified data manager via the trusted agent • Problem: When a Secret user data (e.g., query) is sent to the Unclassified data manager it is a WRITE-DOWN

  14. Distributed Approach II: Replication

  15. Extended Kernel

  16. 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

  17. 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

  18. 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

  19. 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

  20. Some Challenges: Polyinstantiation • Mechanism to avoid certain signaling channels • Also supports cover stories • Example: John and James have different salaries at different levels

  21. 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 T2

  22. Multilevel Secure Data Model: Classifying Databases

  23. Multilevel Secure Data Model: Classifying Relations

  24. Multilevel Secure Data Model: Classifying Attributes/Columns

  25. Multilevel Secure Data Model: Classifying Tuples/Rows

  26. Multilevel Secure Data Model: Classifying Elements

  27. Multilevel Secure Data Model: Classifying Views

  28. Multilevel Secure Data Model: Classifying Metadata

  29. MLS/DBMS FunctionsOverview

  30. MLS/DBMS FunctionsSecure Query Processing

  31. MLS/DBMS FunctionsSecure Transaction Management

  32. MLS/DBMS FunctionsSecure Integrity Management

  33. 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

More Related