Database Security (Chapter 8, Sections 4-7)

1. Database Security(Chapter 8, Sections 4-7) Student: Ying Hong Course: Database Security Instructor: Dr. Yang Database Security (Chapter 8)

2. Contents • Sensitive Data • Inference Problem • Multilevel Databases • Proposals for Multilevel Security • Concluding Remarks • References Database Security (Chapter 8)

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

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

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

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

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

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)

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

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

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

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

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

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

15. 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  (bc)) = count(a) - count(a  (b  c) ) Correction (page 358) Database Security (Chapter 8)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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