Presentation is loading. Please wait.

Presentation is loading. Please wait.

Security in Databases. 2 Outline review of databases reliability & integrity protection of sensitive data protection against inference multi-level security.

Similar presentations


Presentation on theme: "Security in Databases. 2 Outline review of databases reliability & integrity protection of sensitive data protection against inference multi-level security."— Presentation transcript:

1 Security in Databases

2 2 Outline review of databases reliability & integrity protection of sensitive data protection against inference multi-level security

3 3 Database DBMS DB Administrator users

4 4 Database concepts database –data + rules components of data –records: composed of fields / elements logical structure  schema attribute  name of a column relation  a set of columns

5 5 DB should deliver (advantages) shared access minimal redundancy data consistency data integrity controlled access

6 6 Security requirements physical DB integrity logical DB integrity element (field) integrity auditability access control user authentication availability –(integrity, confidentiality & availability)

7 7 Reliability & integrity three dimensions: –database integrity –element integrity –element accuracy various techniques –2-phase update –introducing redundancy –recovery –concurrency/consistency control –using monitors

8 8 2-phase update (commit) phase-1: Intent –gathering info & resources –no harm in the case of failure phase-2: commit –adding commit flag to the database –causing permanent changes –may repairable in the case of failure

9 9 2-Phase Update (Example) Suppose DB query asks to add 1 to fields X and Y. Phase 1 (Intent): –Compute updated values in temporary “Shadow” variables Xnew and Ynew: >Xnew := X + 1, Ynew := Y + 1 Phase 2 (Commit): –Set “Commit” flag (i.e. DB changes started, do not repeat Intent phase!) –Copy shadow values into DB: >X := Xnew, Y := Ynew –Write “Update Complete”, Clear Commit flag.

10 10 Redundancy using error detection / correction codes –entire database –records –fields / elements shadow fields –duplication of attributes / records

11 11 Recovery one way to achieve this is to have a log file for all recent changes (since last backup)

12 12 Concurrency/Consistency In a multi-user/process/client environment, concurrency and consistency control is vitally important. Basic techniques –using “atomic operation” >Read-then-(if OK)Write: A Write query to a field is conditioned on its current contents being as specified (in case it was modified recently by someone else) –using “locking” mechanisms >Read queries to a record are blocked while a write is performed to the record by someone else

13 13 Monitors checking the structural consistency of data entered or modified –range comparison -- field specific –state constraints >describe of the condition of entire DB >(Properties which should be satisfied by DB contents at all times) –transition constraints >describe the conditions necessary before a change can be made (Properties which should be satisfied by DB contents so that a change to DB is valid) Collectively called Integrity Constraints

14 14 On sensitive data 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 sensitivity of data in a DB may vary !

15 15 Access decisions on sensitive data factors to be considered when permitting “user x to access data y” –availability of data >Record is blocked from read while it is modified –acceptability of access >No disclosure (even ‘partial’) of sensitive values to unauthorized users –assurance of authenticity of user >Limit access based on other considerations (time of access, previous accesses,…)

16 16 Types of disclosure of sensitive data exact data (field = x) Bounds – x < field < y negative result –field is not equal to x Existence –an Attribute of a field exists in DB probable value –reducing the number of possible values for a field, Improving knowledge of their relative likelihoods.

17 17 Inference Problem definition: –infer or derive sensitive data from non- sensitive or (seemingly) un-related data “inference” is a subtle vulnerability in database security

18 18 A sample database

19 19 Direct attack list NAME where SEX = M & DRUGS = 1 list NAME where (SEX = M & DRUGS = 1) | (SEX != M & SEX != F) | (DORM != East)

20 20 Indirect attack (statistical inference) Sum sum of financial aid by dorm & sex Holmes Grey West Total M 5000 1000 0 6000 F 2000 0 4000 6000 Total 7000 1000 4000 12000

21 21 Indirect attack (cont.) Count –count of students by dorm & sex Holmes Grey West Total M 1 2 0 3 F 1 0 2 3 Total 2 2 2 6 –can be used in combination with “sum”

22 22 Indirect attack (cont.) Median highest value for attribute 1 lowest value for attribute 1 lowest value for attribute 2 highest value for attribute 2 median for attribute 1 & median for attribute 2

23 23 revealing Earhart’s fine Earhart is the only person who has the median of AID and DRUGS, so if data on AID is known, the following query reveals Earhart’s DRUGS: p = median (DRUGS where AID=2000)

24 24 Indirect attack (cont.) Linear system attack –by solving a set of equations e.g. q1 = c1 + c2 + c3 q2 = c2 + c3 q3 = c1 + c3

25 25 Controls for statistical inference 2 types of control –applied to queries --- very hard ! –applied to data items --- relatively easy >suppression --- sensitive data are not provided >concealing --- precise data are not provided

26 26 Summary of inference no perfect solution to inference problem 3 common approaches –suppress obviously sensitive data  fairly easy –track what the user knows  costly –disguise data  may result in incorrect or wrong responses to legitimate queries

27 27 Multi-level security The 2 level security model, sensitive or non- sensitive, is inadequate in many practical applications: –The security of a data element may be different from that of other elements in the same row or column. –In practice many grades of security may be needed. –The security of an aggregate may be different from that of the individual elements

28 28 Realising Multi-level Security Partitioning –each sub-database corresponds to a security level Encryption –each record (or field) can be encrypted using a different key Integrity Trusted Front End Commutative Filter Window/View


Download ppt "Security in Databases. 2 Outline review of databases reliability & integrity protection of sensitive data protection against inference multi-level security."

Similar presentations


Ads by Google