1. Security Fall 2009McFadyen ACS-49021 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

2. Security Fall 2009McFadyen ACS-49022 Control mechanisms: Discretionary access control (DAC) Text: 23.2 Mandatory access control (MAC) Text: 23.3 Role-based access control (RBAC) Text: 23.3.2 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

3. Security Fall 2009McFadyen ACS-49023 Other references: http://en.wikipedia.org/wiki/Access_control http://www.oracle.com/technology/products/applications/se curity/OracleUserManagementWhitePaper.pdf http://www.oracle.com/technology/deploy/security/seceval/ pdf/seceval_wp.pdf http://www.businessandit.uoit.ca/pst2006/files/presentations /rjaibi.pdf http://www.computerwoche.de/index.cfm?pid=360&pk=32 03&opv=tb&p=3

4. Security Fall 2009McFadyen ACS-49024 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

5. Security Fall 2009McFadyen ACS-49025 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

6. Security Fall 2009McFadyen ACS-49026 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

7. Security Fall 2009McFadyen ACS-49027 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

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

9. Security Fall 2009McFadyen ACS-49029 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

10. Security Fall 2009McFadyen ACS-490210 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

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

12. Security Fall 2009McFadyen ACS-490212 Security principles: Least privilege Separation of duties Data abstraction RBAC

13. Security Fall 2009McFadyen ACS-490213 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

14. Security Fall 2009McFadyen ACS-490214 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

15. Security Fall 2009McFadyen ACS-490215 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

16. Security Fall 2009McFadyen ACS-490216 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

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

18. Security Fall 2009McFadyen ACS-490218 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

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

20. Security Fall 2009McFadyen ACS-490220 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

21. Security Fall 2009McFadyen ACS-490221 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

22. Security Fall 2009McFadyen ACS-490222 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

23. Security Fall 2009McFadyen ACS-490223 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

24. Security Fall 2009McFadyen ACS-490224 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

25. Security Fall 2009McFadyen ACS-490225 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

26. Security Fall 2009McFadyen ACS-490226 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

27. Security Fall 2009McFadyen ACS-490227 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

28. Security Fall 2009McFadyen ACS-490228 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

29. Security Fall 2009McFadyen ACS-490229 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.

30. Security Fall 2009McFadyen ACS-490230 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!

31. Security Fall 2009McFadyen ACS-490231 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