Li Xiong CS573 Data Privacy and Security

1. Access Control Li Xiong CS573 Data Privacy and Security

2. What is Access Control? • Security Engineering by Ross Anderson, 2001 • Its function is to control which principles (persons, processes, machines, …) have access to which resources in the system – which files they can read, which programs they can execute, and how they share data with other principles, and so on. • Access control is pervasive • OS (unix, windows), databases, Java

3. Night Club Example • Authentication • ID Check • Access Control • Over 18 - allowed in • Over 21 - allowed to drink • On VIP List - allowed to access VIP area • Enforcement Mechanism • Walls, Doors, Locks, Bouncers

4. Access control and other security services • Identification and Authentication – establishing and verifying the identity of the user • Something you know, such as a password or a personal identification number (PIN). • Something you have, such as a smart card or security token. • Something you are, such as fingerprint, voice, retina, or iris characteristics. • Where you are, for example on or off campus, inside or outside a company firewall • Access control determines which subject can access what resources after identification and authentication

5. Access control and other security services • Enforcement mechanisms • Auditing – posteriori analysis of all the requests and activities of users in the system • Deterrent – users may be discouraged from attempting violations • Means to analyze users behavior to detect possible violations

6. Access control and other security services

7. Access control • Access control mechanisms – low level software functions that can be used to implement a policy • Access matrix model • Implementation approaches • Access control policies – high level guidelines that determine how accesses are controlled • Discretionary access control (DAC) • Mandatory access control (MAC) • Role based access control (RBAC) • Attribute based access control (ABAC)

8. Access Matrix Model • A set of subjects S • A set of objects O • A set of rights R • An access control matrix • One row for each subject • One column for each subject/object • Elements are right of subject on an another subject or object

9. Access matrix

10. Implementation approaches • Access control lists (ACLs) • Capabilities • Authorization relation or table

11. Access control lists (ACLs) • Each object is associated with an ACL • Storing the matrix in columns • Modern OS typically take the ACL approach

12. Capabilities • Each subject is associated with a capability list • Storing the matrix in rows

13. Authorization relation • Each row, or tuple, specifies one access right of a subject to an object • Relational databases typically use it

14. Access control • Access control mechanisms – low level software functions that can be used to implement a policy • Access matrix model • Implementation approaches • Access control policies – high level guidelines that determine how accesses are controlled • Discretionary access control (DAC) • Mandatory access control (MAC) • Role based access control (RBAC)

15. Individuals Resources database 1 database 2 database 3 Discretionary AC • Restricts access to objects based solely on the identity of users who are trying to access them • No restrictions on information flow Application Access List Name Access Tom Yes John No Cindy Yes

16. Mandatory AC • Governs access based on the classification of subjects and objects • Assign a security level to all information – sensitivity of information • Assign a security level to each user – security clearance • Military and government: Top secret (TS) > secret (S) > confidential (C) > unclassified (U) • Access principles • Read Down – a subject’s clearance must dominate the security level of the object being read • Write Up – a subject’s clearance must be dominated by the security level of the object being written

17. Mandatory AC (cont) • Information can only flow upwards or within the same class Individuals Resources/Information Write up TS Database 1 DS S Database 2 S Read down C Database 3 C U

18. Role-Based AC • Governs the access based on roles • Access authorizations on objects are specified for roles • Users are given authorizations to adopt roles • A user has access to an object based on the roles

19. Role 1 Role 2 Role 3 Role-Based AC Individuals Roles Resources Database 1 Database 2 Database 3 User’s change frequently, Roles don’t

20. Role-based Access Control Benefits • Authorization management – assigning users to roles and assigning access rights to roles • Hierarchical roles – Inheritance of privileges based on hierarchy of roles • Least privilege – allow a user to sign on with least privilege required for a particular task • Separation of duties – no single user should be given enough privileges • Object classes – objects can be grouped based on classifications

21. RBAC Reference Model (Sandhu ‘96) • RBAC0, minimum requirement • RBAC1, RBAC0 + role hierarchies • RBAC2, RBAC0 + constraints • RBAC3, RBAC1 + RBAC2

22. (UA) User Assign- ment (PA) Permission Assignment USERS ROLES OPS OBS PERMISSIONS user_sessions session_roles SESSIONS Core RBAC System

23. USERS Process Intelligent Agent Person

24. ROLES A role is a job function with some associated semantics regarding responsibility and authority (permissions). Director Developer Budget Manager Help Desk Representative MTM relation between USERS & PRMS

25. Permissions • A permission is an approval of a particular access to one or more objects • Database – Update Insert Append Delete • Locks – Open Close • Reports – Create View Print • Applications - Read Write Execute SQL

26. UA (user assignment) ROLES set USERS set A user can be assigned to one or more roles Developer A role can be assigned to one or more users Help Desk Rep

27. PA (permission assignment) ROLES set PRMS set A prms can be assigned to one or more roles Create Delete Drop Admin.DB1 View Update Append A role can be assigned to one or more prms User.DB1

28. guest admin invokes user SESSIONS Each session is a mapping of one user to possibly many roles USER SESSION FIN1.report1 SQL DB1.table1 APP1.desktop

29. Role Hierarchy RBAC (RH) Role Hierarchy (UA) User Assign- ment (PA) Permission Assignment USERS ROLES OPS OBS PERMISSIONS user_sessions session_roles SESSIONS

30. Production Engineer 1 Quality Engineer 1 Production Engineer 2 Quality Engineer 2 Engineer 1 Engineer 2 Director Engineering Dept Project Lead 1 Project Lead 2 Production Engineer 1 Production Engineer 2 Quality Engineer 1 Quality Engineer 2 Tree Hierarchies

31. Production Engineer 1 Quality Engineer 1 Production Engineer 2 Quality Engineer 2 Engineer 1 Engineer 2 Director Engineering Dept Project Lead 1 Project Lead 2 Lattice Hierarchy

32. Constrained RBAC SSD (RH) Role Hierarchy (UA) User Assign- ment (PA) Permission Assignment USERS ROLES OPS OBS PERMISSIONS user_sessions session_roles SESSIONS DSD

33. Static mutual exclusion constraints • Two mutually exclusive roles: cannot both have the same user as members • Two mutually exclusive roles: cannot both have the same permissions • Two mutually exclusive permissions: one role cannot have both permissions

34. Cardinality constraints • On user-role assignment • At most k users can belong to the role • At least k users must belong to the role • Exactly k users must belong to the role

35. Dynamic Constraints • At most k users can activate the same role in one session • No user is allowed to activate n or more roles in one session

36. Constraints with Role Hierarchies • Two roles can be mutually exclusive only if neither one inherits the other • If two roles are mutually exclusive, no roles can inherit from both • If two roles are mutually exclusive, there can be no “root” or “super users”

37. Separation of Duty • Constraints is a means rather than an end • Separation of duty is the goal • No single user possesses all the permissions needed to accomplish a sensitive task • Permission assignment problem

38. Attribute based Access Control (ABAC) • Access control decisions are made based on a set of characteristics, or attributes, associated with the requestor and/or the resource • A requester provides a set of attributes, they are checked against permissible attributes • E.g. a person in UltraMegaCorp tries to access an administration interface for customer data in Atlanta must present credentials with a division attribute of “customer relations division” and a title of “senior manager” and a location attribute of “Atlanta” • No need for predefined list of roles or permissions

39. References • Access control: principle and practice, Sandhu, 1994 • Role-based Access Control Models, Sandhu, 1996

40. Coming up • Hippocratic databases • Fine-grained access control • Policy management and enforcement