1. AdvDB-6 J. Teuhola 2015151 6. Database Security Security = protection from unauthorized use 6.1. Security issues Legal / ethical / ownership issues Policy of publicity (e.g. in business organizations) Security levels, information classification Technical: Passwords, hardware control, operating system security, physical control

2. AdvDB-6 J. Teuhola 2015152 Security issues (cont.) Security mechanisms: Discretionary: Grant privileges Mandatory: Multilevel security policy, classification of information units Prevention from unauthorized use: Access control (user accounts & passwords) Access rights (data specific)

3. AdvDB-6 J. Teuhola 2015153 Security issues (cont.) Statistical database: Only summaries can be seen Encryption: Only authorized users know how to decipher the code. Public-key cryptography: –Public encoding key –Private decoding key

4. AdvDB-6 J. Teuhola 2015154 Security issues (cont.) Digital signatures: –Authentication technique –Applies an encryption function to the pair: –The verifier does not know the secret key, only a matching public key, using which the decoding algorithm either accepts or rejects the message, depending on its authenticity. –Hard to forge, if the secret code is not revealed.

5. AdvDB-6 J. Teuhola 2015155 Security issues (cont.) Database administrator (DBA): Privileged account: all rights (cf. superuser / root in operating systems). DBA plays an important role in security management. DBA actions: –Create/delete an account (acc. no & password) –Grant privilege –Revoke privilege –Assign a security level to an account

6. AdvDB-6 J. Teuhola 2015156 Security issues (cont.) Log extension: Include account-no and terminal-id in each log entry. Database audit: Track the ‘guilty’ user. Audit trail: A log that is only for security purposes.

7. AdvDB-6 J. Teuhola 2015157 6.2. Discretionary access control Grant/revoke privileges of users Levels: –Account level: Relation-independent privileges of the user account, e.g. the right to do CREATE SCHEMA, CREATE TABLE, CREATE VIEW, ALTER TABLE, DROP TABLE, DROP VIEW,... –Relation level: Control access to specific relations/views or attributes.

8. AdvDB-6 J. Teuhola 2015158 Access matrix model rights for: read / write / update Subjects (users, accounts, programs) Objects (relations, views, rows, columns)

9. AdvDB-6 J. Teuhola 2015159 Owner Creator of the data unit, e.g. relation Has all access rights to the relation May grant privileges to others (concerning read, modify, reference) Revoke: opposite of grant, i.e. cancel the access rights (given for a temporary job).

10. AdvDB-6 J. Teuhola 2015160 Views Views are an important discretionary authorization mechanism Base data can be hidden by offering a projection to the public attributes. Usually defined by SQL-queries, e.g. by projecting to the public attributes. To create a view, SELECT-privileges on base relations are required.

11. AdvDB-6 J. Teuhola 2015161 Views: example Relation: Person (Pid, Name, Salary) View with hidden salary: CREATE VIEW PublicPerson (Pid, Name) ASSELECT Pid, Name FROM Person

12. AdvDB-6 J. Teuhola 2015162 Propagation of privileges Grant option: privilege can be granted further to another user/account. A revoke cancels all propagated privileges. If an account got its grant from multiple sources, all sources must be revoked. Limiting of propagation in the granting lattice (not part of SQL): –Horizontally: number of children –Vertically: maximum depth

13. AdvDB-6 J. Teuhola 2015163 Privileges and SQL GRANT [ON ] TO [WITH GRANT OPTION]; where can be e.g. –CREATETAB (permission to create tables) –SELECT (permission to retrieve) –INSERT (permission to insert tuples) –DELETE (permission to delete tuples) REVOKE [ON ] FROM ;

14. AdvDB-6 J. Teuhola 2015164 6.3. Mandatory access control Multilevel security system Application areas: military, government, industry, medical organizations Typical security classes: –TS = Top Secret –S = Secret –C = Confidential –U = Unclassified

15. AdvDB-6 J. Teuhola 2015165 Bell-LaPadula model Both subjects (S) and objects (O) are assigned a classification (clearance) level. Restrictions to be enforced: 1. S may read O if class(S)  class(O) (‘simple symmetry property’) 2. S may write O only if class (S)  class(O) (‘star property’); prevents ‘leaks’ of information from higher to lower classes.

16. AdvDB-6 J. Teuhola 2015166 Mandatory access control in relational databases Assign classification attributes to tuples and attributes (rows & columns). The same relation appears different to different subjects, due to filtering, or polyinstantiation. Null values are shown for attributes that have a higher class than the user’s.

17. AdvDB-6 J. Teuhola 2015167 Rules of mandatory access control in relational databases All attributes of the key (apparent key  primary key) must have the same security class, so that –All key attributes are NON-NULL to authorized users –All key attributes are NULL to unauthorized users, in which case the tuple is not shown. All other attributes have higher or equal security class compared to the primary key. Security of a tuple = the highest security of the tuple’s attributes.

18. AdvDB-6 J. Teuhola 2015168 Example of multilevel access rights True relation: View of user with level S: View of user with level C: NameBank accountSalarySec.class Smith U1234-1234 S10 000 CS Jones S2345-2345 S100 000 TSTS NameBank accountSalarySec.class Smith U1234-1234 S10 000 CS Jones S2345-2345 SNull SS NameBank accountSalarySec.class Smith UNull C10 000 CC

19. AdvDB-6 J. Teuhola 2015169 Polyinstantiation Several tuples are stored to represent the same entity, with the same primary key. Update of a higher-level attribute may create (if the user has a lower clearance) a new version with a lower classification level. This prevents so called covert channels (deduction that a non-null value exists, even though a null value is shown).

20. AdvDB-6 J. Teuhola 2015170 Label-based security Special version of mandatory access control Implemented in Oracle Database 11g. Users have a security label, consisting of a maximum access level, and a list of data collections to which (s)he has access. Data units have labels defining the smallest required access level, plus a list of data units, all of which the user must have access to. Labels can be set e.g. to individual rows of a table.

21. AdvDB-6 J. Teuhola 2015171 Role-based access control (RBAC) A role represents a group of users with similar access rights. Roles can be organized into hierarchies. Connection: –Permissions are associated with roles –Users are associated with roles Operations: –CREATE/DESTROY ROLE … –GRANT … TO … –REVOKE … FROM A flexible and general approach; can replace both discretionary and mandatory access control.

22. AdvDB-6 J. Teuhola 2015172 6.4. SQL injection Danger that threats carelessly written user interfaces, especially with web databases. The interface expects a data item (number, word,...) as input, and the item becomes part of an SQL statement in the application software. A malicious input string, positioned in the query, can result in a legal SQL statement that does totally different things than what was meant.

23. AdvDB-6 J. Teuhola 2015173 Example of SQL injection SQL statement to be executed: SELECT * FROM users WHERE name = ‘ ’; where is typed in by the user. By typing: Smith’; DELETE FROM users WHERE ‘1’=‘1 creates the following combined pair of statements: SELECT * FROM users WHERE name = ‘Smith’; DELETE FROM users WHERE ‘1’=‘1’;

24. AdvDB-6 J. Teuhola 2015174 Prevention of SQL injection Do not paste the input string directly to the skeleton SQL statement in the application code; use instead binding of query parameters to program variables: query = conn.prepareStatement(”SELECT * FROM users WHERE name =?”); query.setString(1, inputname); result = query.executeQuery(); Validate input by filtering out the so called escape characters, such as quotes (’, ”)

25. AdvDB-6 J. Teuhola 2015175 6.5. Statistical database security Statistical database: Confidential data on individuals Only statistical functions allowed Danger: With too selective conditions, also individual attribute values may be deduced. Prevention: Forbid too small populations.

26. AdvDB-6 J. Teuhola 2015176 Example Person subsets for 3 selection conditions: SELECT SUM(salary) FROM Persons WHERE addr=‘Velkua’ AND job=‘police’ AND age>50 Query not allowed (too few satisfying tuples) Intersection: 1 person addr = ‘Velkua’ age > 50 job = ‘police’

27. AdvDB-6 J. Teuhola 2015177 Statistical db security (cont.) Danger: A clever sequence of queries may be applied, with each single query having a sufficiently large population. Prevention: Forbid repeated queries on the same population. Also: Create some ‘noise’ to the results, so that the statistical properties remain.

28. AdvDB-6 J. Teuhola 2015178 Example Query not allowed (repeated use of similar population) Difference of results = salary of the only police over 50 in Velkua SELECT SUM(salary) FROM Persons WHERE addr=‘Velkua’ AND NOT (job=‘police’) AND age>50 SELECT SUM(Salary) FROM Persons WHERE addr=‘Velkua’ AND age>50