AdvDB-6 J. Teuhola 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

AdvDB-6 J. Teuhola 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)

AdvDB-6 J. Teuhola 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

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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.

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

AdvDB-6 J. Teuhola 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).

AdvDB-6 J. Teuhola 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.

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

AdvDB-6 J. Teuhola 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

AdvDB-6 J. Teuhola 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 ;

AdvDB-6 J. Teuhola 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

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola Example of multilevel access rights True relation: View of user with level S: View of user with level C: NameBank accountSalarySec.class Smith U S CS Jones S S TSTS NameBank accountSalarySec.class Smith U S CS Jones S SNull SS NameBank accountSalarySec.class Smith UNull C CC

AdvDB-6 J. Teuhola 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).

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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’;

AdvDB-6 J. Teuhola 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 (’, ”)

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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’

AdvDB-6 J. Teuhola 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.

AdvDB-6 J. Teuhola 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