350 likes | 656 Views
Database Security (Chapter 8, Sections 4-7). Student: Ying Hong Course: Database Security Instructor: Dr. Yang. Contents. Sensitive Data Inference Problem Multilevel Databases Proposals for Multilevel Security Concluding Remarks References. Sensitive Data Introduction (1).
E N D
Database Security(Chapter 8, Sections 4-7) Student: Ying Hong Course: Database Security Instructor: Dr. Yang Database Security (Chapter 8)
Contents • Sensitive Data • Inference Problem • Multilevel Databases • Proposals for Multilevel Security • Concluding Remarks • References Database Security (Chapter 8)
Sensitive Data Introduction (1) • Sensitive data is data that should not be public. • Three kinds of databases: • One that contains nothing sensitive • One that contains everything sensitive • One that contains some but not all sensitive, and the sensitive data may be in varying degrees of sensitivity. Database Security (Chapter 8)
Sensitive Data Introduction (2) • The access control problem is to limit users’ access so that they can obtain only the data to which they have legitimate access. • Several factors that make data sensitive: • inherently sensitive • from a sensitive source • declared sensitive • of a sensitive attribute or a sensitive record • sensitive in relation to previously disclosed information (composite data) Database Security (Chapter 8)
Sensitive Data Access Decisions (1) • Access decisions are made by database administrator and based on an access policy. • The DBMS implement the access decisions. • There are several factors when deciding whether to permit an access. They are: • Availability of the data: some required data may not be accessible. • Example: locking of tuples when updating • Serious problem may be resulted in: DOS Database Security (Chapter 8)
Sensitive Data Access Decisions (2) • Acceptability of the access: some data may be sensitive and not accessible by some user. This control is not as simple as it sounds, because: • the sensitive fields may not be directly requested but only be referenced • some user may want a nonsensitive statistic from the sensitive data • Example: p.351 Database Security (Chapter 8)
Sensitive Data Access Decisions (3) • Assurance of Authenticity: certain characteristics of the user that is external to the database may also be considered. • access the database only during the working time • previous request made by the user may be considered (because sensitive data can sometimes be revealed by combining less sensitive data) Database Security (Chapter 8)
Sensitive Data Types of Disclosures (1) • Data can be sensitive, but even information about data is also a form of disclosure. So a successful security strategy must protect from both direct and indirect disclosure. • Exact data: sensitive data itself • Bounds: sometimes by knowing the bounds on a sensitive data and using a narrowing technique the user may determine the sensitive data in any desired precision. Database Security (Chapter 8)
Sensitive Data Types of Disclosures (2) • Negative Result: some query may be made to determine a negative result from which sensitive data may be disclosed. • Existence: the existence of data is itself a sensitive data, regardless of the actual value. • Probable value: it may be possible to determine the probability that a certain element has a certain value. Database Security (Chapter 8)
Sensitive Data Security vs. Precision • Sharing of nonsensitive data: • Security: To disclose only nonsensitive data, and reject any query that mentions a sensitive field. • Precision: To protect all sensitive data while disclose as much nonsensitive data as possible. • The ideal combination is to maintain perfect security with maximum precision. In fact, we often must sacrifice precision in order to maintain security. • Fig. 8-8, p.354. Database Security (Chapter 8)
Inference Problem • Inference problem is to derive sensitive data from nonsensitive data. It’s a subtle vulnerability in database security. • A sample table: Database Security (Chapter 8)
Inference Problem Direct Attack (1) • Direct attack is an attempt to retrieve some values by directly querying some sensitive fields. • Example: SELECT Name FROM Sample WHERE Sex=‘M’ AND Drugs=1; • Some trick may be used on direct attack. • Example: SELECT Name FROM Sample WHERE (Sex=‘M’ AND Drugs=1) OR (Sex<>’M’ AND Sex<>’F’) OR Dorm=‘Ayres’; Database Security (Chapter 8)
Inference Problem Direct Attack (2) • The rule of “n items over k percent”: data should not be given if n items represent over k percent of the result reported. • In the previous example, the one person selected represents 100 percent of the data reported. Database Security (Chapter 8)
Inference Problem Indirect Attack (1) • Indirect attack is to infer a result based on one or more statistical results. • Several examples of indirect attack: • Sum: a reported sum may be used to infer a value. (Table 8-3: sums of financial aid by dorm and sex) • Count: the count can be combined with the sum to produce some even more revealing results. (Table 8-4: count of students by dorm and sex) Database Security (Chapter 8)
Inference Problem Indirect Attack (2) • Intersecting medians: Unauthorized users may use intersecting medians to determine a sensitive field’s value. (Figure 8.9 & Table 8-5) • Tracker attacks: is to generate the desired data by using additional queries that generate small results. q = count (a b c) q = count(a) - count(a (bc)) = count(a) - count(a (b c) ) Correction (page 358) Database Security (Chapter 8)
Inference Problem Indirect Attack (3) • Linear system vulnerability: with a little algebra and a little more luck in the distribution of the database contents, it’s possible to determine a series of queries that returns results relating to several different sets. q1 = c1 + c2 + c3 + c4 + c5 q2 = c1 + c2 + c4 q3 = c3 + c4 q4 = c4 + c5 q5 = c2 + c5 Database Security (Chapter 8)
Inference Problem Controls for Inference Attacks • Query controls • Effective primarily against direct attacks • Item controls • Suppression: query is rejected without sensitive data provided. • Concealing: the answer provided is close to but not exactly the actual value. Contrast b/w security and precision. Database Security (Chapter 8)
Inference Problem Examples of Controls (1) • Limited response suppression: • Rule of n items over k percent: eliminate low-frequency elements. • More sufficient way: suppress additional cells on the same row and column. (Table 8-6 and 8-7) • combining results: • To combine some rows and columns. (Table 8-8 and 8-9) • Or to present values in ranges. • Or to present values by rounding. Database Security (Chapter 8)
Inference Problem Examples of Controls (2) • Random sample: • Result is computed on a random selected subset of the database but not the whole database. • Random data perturbation: • Result is perturbed by a small error. • Query analysis: • A query and its implications are analyzed. • Complexity: • Maintain a query history for each user. • Judge each query on the context of previous queries. Database Security (Chapter 8)
Inference Problem Conclusion • No perfect solutions. • Three paths to follow: • Suppress obvious sensitive information (easily). • Track what the user knows (costly). • They are used to limit queries accepted and data provided. • Disguise the data (problem with precision). • It’s applied only to the released data. Database Security (Chapter 8)
Multilevel Databases Differentiated Security • An illusion: Sensitivity was determined just by attribute. sensitive vs nonsensitive attributes • The fact: differentiated data security • Three characteristics of database security: • The security of a single element may be different from the others in the same row or column. • Several grades of security are needed. • The security of an aggregate (a sum, a count, or a group of values) may be different from the security of the individual elements. Database Security (Chapter 8)
Multilevel Databases Granularity • An analogy: Defining the sensitivity of each value in a data base is similar to applying a sensitivity level to each individual word of a document. • Both element and combination of elements may have a distinct sensitivity. • In order to keep each value of a database being in its own sensitivity level: • An access control policy must define which users can have access to what data. confidentiality (or secrecy) • Each value must be guaranteed NOT to be changed by any unauthorized person. integrity Database Security (Chapter 8)
Multilevel Databases Security Issues (1) • Integrity • *-property for access control: In multilevel databases a high-level user should not be able to write a lower-level data element. See p.279 for the official definition of *-property. • Problem: Sometimes read and write must happen to the same process, like DBMS. • Solution: Either the process cleared at a high level cannot write to a lower level, or the process must be a “trusted process”. Database Security (Chapter 8)
Multilevel Databases Security Issues (2) • Confidentiality • In multilevel databases two different users from different levels of security may get two different answers to the same query. • Unknowing redundancy, known as polyinstantiation, may be introduced; that is, one record can appear many times, with different level of secrecy each time. Database Security (Chapter 8)
Proposals for multilevel security Partitioning • Model: The database is divided into separate databases, each at its own security level. • Weakness: • Destroy basic advantage of a database: elimination of redundancy. • Problem with combined usage of separate databases. Database Security (Chapter 8)
Proposals Encryption • Model: Each level of sensitive data is stored in a table encrypted under a key unique to the level of sensitivity. • Weakness: • Chosen plaintext attack may increase. Controls: different encryption keys, cipher block chaining (Fig. 8-11, p.365) • High overhead of processing a query: decrypting required fields. • Encryption is not often used to implement separation in data bases. Database Security (Chapter 8)
Proposals Integrity and Sensitivity Locks (1) • Integrity lock (spray paint): The protection is made with elements, not with tables. • Each data item includes (Figure 8-12): • Data itself: stored in plaintext for efficiency of access. • Sensitivity label: defines the sensitivity of the data. • Sensitivity labels are unforgeable, unique, and concealed. • Checksum: computed across both data and sensitivity label. (Cryptographic checksum: Figure 8-13) Database Security (Chapter 8)
Proposals Integrity and Sensitivity Locks (2) • Sensitivity lock: is a combination of a unique identifier and the sensitivity level. (Figure 8-14) • Sensitivity lock = E(Key, Sensitivity label, unique identifier) • Intention: • Use any (untrusted) database manager with a trusted procedure that handles access control. (Figure 8-15) Database Security (Chapter 8)
Proposals Integrity and Sensitivity Locks (3) • It’s only a short-term solution for multilevel security. • Weakness: • Efficiency of integrity locks is a serious drawback. • The space required is expanded. • The processing time of decoding sensitivity label is a problem. • Trojan horse attack: database manager sees all data. Database Security (Chapter 8)
Proposals Trusted Front-End • Model (Figure 8-16): • A trusted front-end (known as a guard) is added. • Interaction b/w user, front-end, and DBMS (page368) • c.f., Commutative filters: • Reformat user’s request if necessary and return only data of appropriate sensitivity to the user. • Advantage: • Database manager can do as much as possible, like selection, optimization, subquery … • Overall efficiency of the system. Database Security (Chapter 8)
Proposals Distributed/federated Database • Operation of a trusted front-end: • Control access to two database managers with different sensitivity. • Take user’s query and formulate single-level queries to the databases as appropriate. • Return results to user, combining results appropriately if they are obtained from different databases. • Weakness: • The front-end is potentially including most of the functionality of a full database manager. • Data must be kept in separate databases according to their different sensitivity degrees. Database Security (Chapter 8)
Proposals Window/View • Window • A window is a subset of a database, containing exactly the information that a user is entitled to access. • View • A view can represent a single user’s subset database, so that all of a user’s queries access only that subset database and sensitive data to the user may be filtered. • Layered system (TCB, trusted computing base): • First layer: access control & user authentication. • Second layer: index & computation of database. • Third layer: translate views into the base relations. Database Security (Chapter 8)
Concluding Remarks On My Own • Partitioning and Distributed databases are not popular, mainly because there is a difficulty in combined usage of different databases. • Integrity lock is just a short-term solution for the security of multilevel databases. Trusted front-end and Commutative filter look like more practical, but more complicated. • Encryption is used, but big problem is overhead of processing. • Window and View are concepts more related to the functionality of database itself. Database Security (Chapter 8)
Concluding Remarks To Our Projects • We may focus on encryption, trusted front-end, commutative filter, and view, looking for practical implementation for some of them. • Basic idea on: • Encryption: encrypt sensitive data stored in databases with a crypto server to handle access and user authentication. • Trusted front-end / commutative filter: require more space to store sensitivity degree for sensitive data, with a guard to handle access and user authentication and may reformat users’ queries. • View: create view for each user with a module (may called view server) to handle access and user authentication. Database Security (Chapter 8)
References • Security in Computing by Charles P. Pfleeger, Chapter 8, Sections 4-7 • Developing a Database Encryption Strategy, at RSA Security Home > Events > RSA Web Seminars Database Security (Chapter 8)