1 / 23

IT 221: Introduction to Information Security Principles

IT 221: Introduction to Information Security Principles. Lecture 11: Database Security For Educational Purposes Only Revised: November 13, 2002. Special Topics Outline (1). Special Topics Outline: Context and Overview Introduction to Databases Database Components

garan
Télécharger la présentation

IT 221: Introduction to Information Security Principles

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. IT 221:Introduction to Information Security Principles Lecture 11: Database Security For Educational Purposes Only Revised: November 13, 2002

  2. Special Topics Outline (1) • Special Topics Outline: • Context and Overview • Introduction to Databases • Database Components • Advantages of Using Databases • Database Security Factors • Security Requirements • CIA • Types of Disclosures • Interference Problem • Three Dimensions of Integrity • Data Sensitivity • Multilevel Security Requirements

  3. Special Topics Outline (2) • Special Topics Outline: • Methods of Multilevel Security -Partitioning -Encryption -Integrity Loc -Trusted Front-End • Discussion Points

  4. Context and Overview • Context [1]: • Database security is of substantial interest in the arena of IT Security: -Newer than programming and operating systems -Ubiquitous in most businesses and government agencies -Contains info that is of greater general interest that a piece of software. • Value of information is now recognized as a major corporate asset. • Overview: • Covered protocols and mechanisms to enhance security in client-server architectures; Email and IP/Web applications. This lecture will focus on the security aspects of databases. • Lecture material is considered special topics, and is based on Pfleeger, Charles. Security In Computing, Prentice Hall, 1997. Chapter 9.

  5. Introduction to Databases • Introduction [1]: • Collection of data and a set of rules that organize data by specifying certain relationships among the data. • Through these rules, a user describes a logical format for the data. • Data items are stored in a file, but the physical format of the file is of no concern for the user. • Database Administrator (DBA) defines the rules that organize the data and controls who should have access to what parts of the data. • Users interact with the database via a Database Management System (DBMS) or some other front-end tool.

  6. Databases Components • Basic Components [1]: • Records: One related set of data in a database file. • Attributes (Columns/Fields/Elements): Elementary data items contained in a record. • Schema: Logical structure of the database • Query: A command to retrieve, modify, add, and/or delete Attributes and Records in a database.

  7. Advantages of Using Databases • Advantages [1]: • Shared Access: Collection of data, stored and maintained at one central location, to which many people have access as needed. • Minimized Redundancy: Individual users do not have to collect and maintain their own sets of data. • Data Consistency: Change to a data value affects all users of the data value. • Data Integrity: Data values are protected against accidental or malicious incorrect changes. • Controlled Access: Only authorized users are allowed to view or to modify data values.

  8. Database Security Factors • Factors [1]: • Basic security requirements of databases are not unlike the security requirements of other computing systems. • Basic problems include Access Control, exclusion of spurious data, Authentication of unauthorized data, and reliability. • However, as often happens, security goals can conflict with other factors, I.e. namely with performance.

  9. Security Requirements • Requirements [1]: • Physical Integrity: Immunity to physical problems such as power outages, i.e. can be easily reconstructed if destroyed in a catastrophe. • Logical Integrity: Preservation of DB structure, e.g. a modification to the value of one attribute does not affect other attributes. • Element Integrity: Accuracy of data contained in each element. • Audibility: Ability to track who has accessed (or modified) the DB elements. • Access Control: Authorized access (and privileges) for authorized DB users. • Availability: Users can access the database in general and all the data for which they are authorized.

  10. Confidentiality (Secrecy), Integrity and Availability • CIA [1]: • Confidentiality (Secrecy): A large issue with databases because of inference. A user can access sensitive data indirectly. • Integrity: Applies to the individual elements of a database as well as to the database as a whole. • Availability: Important because the shared access motivation underlying the development of databases. However, Availability can conflict with Confidentiality (Secrecy).

  11. Types of Disclosures • Types of Disclosure [1]: • Exact Data: Exact value of the sensitive data itself. The user may know that sensitive data is being requested, or the user may request general data without knowing that some of it is sensitive. • Bound: Sensitive value, y, is between two values L and H. Through an iterative, inductive approach, a hacker could determine L < y < H…L < y < H/2….etc. Ex: Salary Ranges. • Negative Result: Query and determine a negative result, i.e. that z is not the value of y. Ex: If a student does not appear on the Honor Roll list. • Existence: Existence of data is sometimes itself a sensitive piece of information, regardless of the actual value. Ex: Whether a long distance call was placed.

  12. Inference Problem • Inference Problem [1]: • Way to infer or derive sensitive data from non-sensitive data. • Two methods of Attack: -Direct Attack: Seeks to determine values of sensitive fields by seeking them directly with queries that yields few records. Most successful technique is to form a query so specific that it matches exactly one data item. -Indirect Attack: Seeks to infer a result based on one or more statistical results, and requires work outside of the database itself. Example: Inferring information on individual citizens based on US Census Bureau demographics.

  13. Three Dimensions of Integrity • Integrity [1]: • (1) Database Integrity: Concern that the database as a whole is protected against damage, as from the failure of a disk drive or the corruption of the mater database index. These concerns are typically addressed by Operating System integrity controls and recovery procedures. • (2) Element Integrity: Concern that the value of a specific data element is written or changed only by authorized users. Proper access controls protect a database from corruption by unauthorized users. • (3) Element Accuracy: Concern that only correct values are written into the elements of a database. Checks on the values of elements can help to prevent insertion of improper values.

  14. Data Sensitivity (1) • Data Sensitivity[1]: • Sensitive Data: Data that should not be made public. Determining which data items are sensitive depends on the individual DB and the underlying meaning of the data. • More challenging, however, is the case in which some but not all of the elements in the database are sensitive. Several factors can make data sensitive: -(1) Inherently Sensitive: Value may be so revealing that it is sensitive. -(2) From a Sensitive Source: Source of data may indicate a need for confidentiality. -(3) Declared Sensitive: DBA or the owner of the data may have declared it to be sensitive.

  15. Data Sensitivity (2) • Data Sensitivity [1]: • So far, we’ve considered data of only two categories: Sensitive or Non-Sensitive • We’ve alluded to some data being more sensitive than others, but we’ve allowed only yes-or-no access. • Consider an example of a database containing data on US Government expenditures. Some expenditures are for paper clips, which is not sensitive information. But some salary expenditures are subject to privacy requirements.

  16. Multilevel Security Requirements • Multilevel Security Requirements [1]: • Not unlike the Military Model, a Multi-level DB model can be defined: -(1) Security of a single element may be different from the security of other elements of the same record or from other values of the same attribute. That is, the security of one element may be different from that of other elements of the same row or column. This situation implies that security should be interpreted for each individual element. -(2) Two levels – sensitive and non-sensitive- are inadequate to represent some security situations. Several grades of security may be needed. These grades may represent ranges of allowable knowledge, which may overlap. Typically, the security grades form a lattice. -(3) Security of an aggregate – a sum, a count, or a group of values in a DB- may be different from the security of the individual elements. Security of the aggregate may be higher or lower than that of the individual elements.

  17. Methods of Multilevel Security • Methods of Multilevel Security [1]: • Implementing multilevel security for DBs is difficult, probably more so than OSs, because of the small granularity of the items being controlled. • Several Methods include: -Partitioning -Encryption -Integrity Lock -Trusted Front-End

  18. Partitioning • Partitioning [1]: • Database is divided into separate databases, each at its own level of sensitivity. • Analogous to maintaining separate files in separate file cabinets. • Destroys two basic advantages of databases: -Elimination of redundancy and improved accuracy through having only one field to update. -Does not address the problem of a high-level user who needs to access some low-level data to be combined with high-level data.

  19. Encryption • Encryption [1]: • If Sensitive data is encrypted, a user who accidentally receives sensitive data cannot interpret the data. • Thus each level of sensitive data can be stored in a table encrypted under a key unique to the level of sensitivity. • Encryption, however, has one major disadvantage: Each field must be decrypted in order to perform standard database operations , and thus, increases the time to process a query.

  20. Integrity Lock • Integrity Lock [1]: • First proposed at the Air Force Summer Study on Database Security. • Way to provide both integrity and limited access for a database. • Nicknamed ‘spray paint’ because each element is ‘painted’ with a ‘color’ that denotes its sensitivity. Coloring is maintained with the element , not in a master database table. • Each data item consists of three pieces: the data itself, a sensitivity label, and a checksum. • Each level of sensitive data can be stored in a table encrypted under a key unique to the level of sensitivity.

  21. Trusted Front-End • Trusted Front-End[1]: • Interaction between a user, a trusted front-end and a DBMS is as follows: -(1) User identifies self to the front-end; front-end authenticates users -(2) User issues query to front-end. -(3) Front-end verifies user’s authorization to data -(4) Front-end issues query to database manager -(5) DB Manager performs I/O access, interacting with low-level access control to achieve access to actual data. -(6) Database manager returns result of query to front-end -(7) Front-end verifies validity of data via checksum and checks classification of data against security level of user -(8) Front-end transmits data to untrusted front-end for formatting -(9) Untrusted front-end transmits formatted data to user.

  22. Discussion Points • Discussion Points [1]: • Best practices for balancing Security Goals with practical availability/performance needs? • Best practices and commercially available tools.

  23. Resources • [1] Pfleeger, Charles. Security In Computing, Prentice Hall, 1997. Chap-8.

More Related