Security Fall 2009McFadyen ACS How do we protect the database from unauthorized access? Who can see employee salaries, student grades, … ? Who can update … ? Techniques include/involve: accounts - system (DBA), user passwords log-in process - new entry for the log: {who, where, when} privileges roles encryption

Security Fall 2009McFadyen ACS Control mechanisms: Discretionary access control (DAC) Text: 23.2 Mandatory access control (MAC) Text: 23.3 Role-based access control (RBAC) Text: NIST. An introduction to Role Based Access ControlAn introduction to Role Based Access Control R. S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman, Role-Based Access Control ModelsRole-Based Access Control Models

Security Fall 2009McFadyen ACS Other references: curity/OracleUserManagementWhitePaper.pdf pdf/seceval_wp.pdf /rjaibi.pdf 03&opv=tb&p=3

Security Fall 2009McFadyen ACS Discretionary access control (DAC) privileges such as read, write, update are granted to users/accounts a certain amount of discretion is given to the owner or anyone else with appropriate authority

Security Fall 2009McFadyen ACS Mandatory access control (MAC) multilevel security is applied to data and users controlled by a central authority, not by owners of an object the owner/creator of an object does not decide who has clearance to see the object

Security Fall 2009McFadyen ACS Role-based access control (RBAC) involves users, roles, operations, permissions, sessions permissions such as read, write, update are applied to objects/resources for a database we could have database-level – connect, … table/column level – update, … stored procedures – execute, … users are persons users interact with system during sessions, during a session the user invokes one or more roles roles are collections of job functions RBAC

Security Fall 2009McFadyen ACS Role Example: a role Specialist could contain the roles of Doctor and Intern. This means that members of the role Specialist are implicitly associated with the operations associated with the roles Doctor and Intern without the administrator having to explicitly list the Doctor and Intern operations roles Cardiologist and Rheumatologist could each contain the Specialist role RBAC

Security Fall 2009McFadyen ACS RBAC  Example from a paper on RBAC We might have drawn this as: cardiologistrheumatologist specialist doctor intern

Security Fall 2009McFadyen ACS Example: A teller and an accounting supervisor in a bank. Teller: read/write access to records. Supervisor: perform correction (also need read/write access). Rule #1: Supervisor cannot initiate deposits or withdrawals, but can only perform corrections after the fact. Rule #2: Teller can only initiate deposits or withdrawals, but cannot perform corrections once the transaction has been completed. RBAC

Security Fall 2009McFadyen ACS Example: See class discussion Create the database from ER/Studio Populate database Create views Give users access to the database Create roles in the database Add users to the roles Add permissions to the roles RBAC

Security Fall 2009McFadyen ACS RBAC Some variations of RBAC allow lattices for roles…. What change is needed for the ERD?

Security Fall 2009McFadyen ACS Security principles: Least privilege Separation of duties Data abstraction RBAC

Security Fall 2009McFadyen ACS Least privilege user must be given no more privilege than is necessary to perform the job. concept of least privilege requires identifying the user's job functions, determining the minimum set of privileges required to perform that function, and restricting the user to a domain with those privileges and nothing more RBAC

Security Fall 2009McFadyen ACS Separation of duties – mutually exclusive Example: requiring an accounting clerk and account manager to participate in issuing a cheque These two roles must be mutually exclusive to deter fraudulent activities RBAC

Security Fall 2009McFadyen ACS Data abstraction : Permission can be defined at a higher level, rather than on read/write/ execute. For example, permissions can be defined on credit, debit for an account object This is in contrast to the more conventional and less intuitive process of attempting to administer lower-level access control mechanisms directly (e.g., access control lists, capabilities) on an object-by-object basis RBAC

Security Fall 2009McFadyen ACS MAC / DAC: US DoD has four basic divisions for systems: A, B, C, D lowest to highest is D, C1, C2, B1, B2, B3, A1 C1, C2, B1, B2, B3, A1 require DAC B1, B2, B3, A1 require MAC

Security Fall 2009McFadyen ACS Discretionary access control based on granting and revoking of privileges based on a users identity or group they belong to Discretionary

Security Fall 2009McFadyen ACS Discretionary access control example grant createtab to A1 ; if A1 creates a table X, then A1 owns X, and has all privileges on table X, and A1 can grant privileges to others Discretionary

Security Fall 2009McFadyen ACS Discretionary access control access matrix model: subject1 object1 object2 object3 subject2 subject3 read/write/update Users/ accounts/ programs Relations/records/columns/views/operations Discretionary

Security Fall 2009McFadyen ACS Discretionary access control: suppose A1 executes: create table employee (…); create table department (…); grant insert, delete on employee, department to A2; grant select on employee, department to A3; grant update on employee(salary) to A4; A1 employeedepartment A2 A3 all insert, delete select all insert, delete select employee.salary A4 update Discretionary access matrix

Security Fall 2009McFadyen ACS Discretionary access control: Views suppose A1 executes: create view EmployeesInDiv5 as select name, position, manager from employee e, department d where d.div=5 and e.deptno=d.deptno; grant select on EmployeesInDiv5 to A4; employeedepartment A4 all select all EmployeesInDiv5 A1 all Discretionary

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Bell LaPadula model: specifies the allowable paths of information flow set of subjects S, and a set of objects O each s in S and o in O has a fixed security class C(s) a clearance C(o) a classification level security classes are ordered by <= e.g. public <= sensitive <= top secret Mandatory

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Two properties of the Bell LaPadula model: Simple Security Property a subject s is not allowed read access to an object o unless C(s) >= C(o) Mandatory To see something, your clearance must be at least that of what you want In the military model, the security clearance of someone receiving a piece of information must be at least as high as the classification of the information

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Second property of the Bell LaPadula model: Star Property a subject s is not allowed write access to an object o unless C(s) <= C(o) Mandatory In the military model, a person receiving some information at one level may pass that information along only to people at levels no lower than the level of the information To create/update something, your clearance must be no greater than the object you are creating/updating

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Implementation of the Bell LaPadula model: for each original attribute in a relation, add a classification attribute add a classification attribute for the tuple (row) - value is maximum of all classifications within the tuple these classification attributes are transparent to the user Mandatory

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Implementation example: suppose U <= C <= S Mandatory Employee relation Smith 40,000 Fair Brown 80,000 Good Name Salary JobPerformance The user view without MAC Smith U 40,000 C Fair S S Brown C 80,000 S Good C S Name C 1 Salary C 2 JobPerformance C 3 TC system view with MAC

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Implementation example: Mandatory Stored Rows: we store only the required tuples that then allow us to materialize tuples for lower levels For example, allows us to materialize tuples for Classes U, C, and S: U: C: S: Smith U 40,000 C Fair S S Smith null null Smith 40,000 null Smith 40,000 Fair

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Implementation example: Mandatory What does a class C user see if he/she executes Select * from Employee Smith 40,000 null Name Salary JobPerformance Smith U 40,000 C Fair S S Brown C 80,000 S Good C S Name C 1 Salary C 2 JobPerformance C 3 TC Brown null Good The result is filtered

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Implementation example: Mandatory What happens if a class C user executes Update Employee set Salary=100,000 Smith U 40,000 C Fair S S Brown C 80,000 S Good C S Name C 1 Salary C 2 JobPerformance C 3 TC Smith U 100,000 C Fair S S Brown C 80,000 S Good C S Name C 1 Salary C 2 JobPerformance C 3 TC Brown C 100,000 C Good C C Class C attribute is updated Class S attribute forces polyinstantiation Let’s assume the result is to be class C.

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Implementation example: Mandatory Stored Rows: our update example required a row to be polyinstantiated For example, updating the Salary field in requires two rows for us to be able to materialize records for classes S, C Brown C 80,000 S Good C S Brown C 100,000 C Good C C Two rows with the same key!

Security Fall 2009McFadyen ACS Mandatory access control for multilevel security Implementation example: Mandatory What does a class C user see if he/she executes Select * from Employee The result is filtered Smith U 100,000 C Fair S S Brown C 80,000 S Good C S Name C 1 Salary C 2 JobPerformance C 3 TC Brown C 100,000 C Good C C Smith 100,000 null Name Salary JobPerformance Brown 100,000 Good Only the row with TC=C is used