1. Access Control and Audit Indrakshi Ray Computer Science Department Colorado State University Fort Collins CO 80523

2. Attribute-Based Access Control  We need to accommodate a wide-variety of access control policies across different domains  Policy management should be simple

3. Lecture Objectives  Complete access control  Few words about audit

4. Attribute-Based Access Control

5.  Subjects are associated with attributes  Objects are associated with attributes  Environment conditions are associated with attributes  Authorization is expressed as conditions on these attributes

6. Example  MPEG adult movies can only be downloaded by users whose age is greater than 18  Authorization does not refer to specific user  Applies to all users whose age is greater than 18 years  MPEG movies have an attribute that denotes their type  In this case it is adult movies  Attribute-based access control  XACML and NGAC

7. XACML  eXtensible Access Control Markup Language is an OASIS standard  Developed for collaborative environments  Data sharing across different organizational domains  XACML is extensible and is an XML encoded language  Can specify access control policies, access control requests, and access control decisions

8. XACML has three components  XACML policy language  Specify access control rules  Algorithms for combining policies  XACML request/response protocol  Used to query a decision engine that evaluates user access requests against policies  XACML reference architecture  For deployment of software modules to house policies and attributes and compute and enforce access control decisions

9. Terms  Resource  Data or system component needing protection  Subject  An actor who requests access to specific resources  Action  An operation on a resource  Environment  Properties not belonging to the resource, subject, or action that are important for the authorization decision

10. Terms Continued  Attributes  Characteristics of the resource, subject, action, or the environment  Target  Defines conditions that determine whether policy applies to the request

11. XACML Requests  XACML access request consists of attributes of subject, resource, action, and environment  XACML attributes are name-value pairs  Role = “Doctor”, ObjectAttr = “Medical Record”  Attributes are stored in a Policy Information Point (PIP) and retrieved at the time of decision making

12. XACML Policy Structure

13. Policy Language model

14. XACML Policies  XACML policies are structured as PolicySets  PolicySets consist of Policies and may include other PolicySets  Policies are composed of Rules  Target defines a Boolean condition  If true, the request gets evaluated by a PDP  If false, the decision is Not Applicable  Target minimizes the PolicySets, Policy, and Rules that must be examined

15. XACML Policies

16. XACML Rules  Rules have a set of Boolean conditions  Rules evaluate to true or false or indeterminate  Policy can have multiple rules  Rules can be combined by rule combining algorithm  There are 12 rule combining algorithm

17. Rule Combining Algorithm  Four commonly used rule combining algorithm  Deny overrides  AND operation on Permit  Permit overrides  OR operation on Permit  First applicable  Result is the result of the first decision  Only one applicable  If more than one decision applies, then the result is Indeterminate

18. Obligations  XACML includes the concept of obligations  Obligation describes what must be carried out before or after an access request is approved and denied  If Alice is denied access to Document X, email her manager that Alice tried to access document X

19. XACML Policy Example  Target: Value_of(ObjectAttr) = “Return”  Combining Algorithm: Deny overrides  Rule 1:  (Value_of(Role) = “IRS Agent” V Value_of(Role) = “Auditor”) ^  (Value_of(Op) = “read” V Value_of(Op) = “write”) ^  (Value_of(Time) >= 08:00 ^ Value_of(Role) <= 18:00)  Effect: Permit  Rule 2:  (Value_of(Role) = “IRS Agent” V Value_of(Role) = “Auditor”) ^  ( Value_of(Op) = “write”) ^ (Value_of(UserName) = Value_of(Return) Value_of(Role) <= 18:00)  Effect: Deny

20. XACML Policy Example Contd.  User Attribute Names:  UserName = {Smith, Johnson, Thompson};  Roles = {IRS Agent, Auditor, AR Clerk}  Object Attribute Names:  Return = {Smith, Brown}  Attribute Value Assignments:  A(u1) = {Smith, IRS Agent}; A(u2) = {Johnson, IRS Agent}  A(o1) = {Smith}; A(o2) = {Brown}  Environment Name and Value:  Current_Time = 9:30  Authorization State: (u1, read, o1), (u1, read, o2), (u1, write, o2), (u2, read, o1), (u2, write, o1), (u2, read, o2), (u2, write, o2)

21. Decentralized Administration  Policy administration determines how policies can be created and modified  XACML supports delegation that allows for decentralized policy administration  A delegator can delegate all or parts of its own authority or someone else’s authority to a delegatee  A policy may contain a element that describes the source of the policy  Absence of implies that the policy is trusted

22. Usage Scenario Policy Information Point (PIP) serves as the source of attribute values, or the data required for policy evaluation. PIP

23. Usage Scenario Policy Enforcement Point (PEP)  Entity protecting the resource(e.g. file system)  Performs access control by making decision requests and enforcing authorization decisions PEP

24. Usage Scenario The Policy Decision Point (PDP)  Receives and examines the request  Retrieves applicable policies  evaluates the applicable policy and  Returns the authorization decision to PEP PDP

25. Usage Scenario Policy Administration Point (PAP) creates security policies and stores these policies in the repository. PAP

26. Usage Scenario Context Handler  A Context is the canonical representation of a decision request and an authorization decision.  Context Handler can be defined to convert the requests in its native format to the XACML canonical form and to convert the Authorization decisions in the XACML canonical form to the native format. Context Handler

27. How does it work: Data Flow

28. NGAC  Next Generation Access Control was developed by NIST  NGAC policies have  Users  Resources  Operations  Policy class entities and their attributes are treated as containers  NGAC does not express policy through rules but using relations

29. NGAC Relations  Assignments  Memberships in containers  Associations  For deriving privileges  Prohibitions  Denies for users and process capabilities  Obligations  For dynamically altering access state

30. NGAC Containers  Containers group and characterize their members  User containers can represent roles, affiliations, or other characteristics that are pertinent to a security policy  Processes take on the same attributes as the invoking user  Object containers characterize data such as those associated with a certain project, applications, or security classifications  Policy class containers group or characterize collections of policies  Every user, user attribute, and object attribute must belong to at least one policy class  Policy classes can be distinct or may overlap

31. NGAC Assignment and Association

32. NGAC Example Policy  Figure a specifies that users assigned to Group1 or Group2 can read resource objects contained in Projects  Group1 users can write to Project1 objects only  Group2 users can write to Project2 objects only  Group2 users can read/write data objects in Gr2-Secret  Figure a does not specify how its relations and elements were created and managed

33. Access Requests  Processes issue access requests on behalf of a user  A user can be associated with many processes  A process is associated with only one user  Process_user(p) denotes the user associated with process p  p is a process p access request where op is an operation and o is an object  p is granted iff there exists a privilege (u, op, o) where u = process_user(p) and no restriction (u, op, o) or (p, op, o) exists

34. Prohibitions  NGAC includes two types of prohibition relations  User-deny  U-deny(u|ua, ops, os) where u is a user or ua is a user attribute, ops is an operation set, and os is an object set  U-deny can be created by an administrator or dynamically as a consequence of the obligation  Process-deny  P-deny(p, ops, os) where p is a process which cannot perform operation ops on object os

35. NGAC Obligations  Obligations (ep, r)  ep is an event pattern  r is a sequence of administrative operations  Example  When any process p performs (r, o) where o -> Gr2-Secret do create p-deny(p, {w}, not(Gr2-Secret))

36. NGAC Functional Architecture

37. Future Directions  Safety problem in access control  ReBAC and ABAC  Spatio-temporal access control  Provenance-based access control

38. Auditing  Security information and event management tools are able to collect information about queries being issued by users  Database contents change over time  It is not possible to say what tuples were viewed by the user

39. Fine-grained Auditing  Proposed by Agarwal 2004 for detecting privacy breaches  Backlog database that stores all queries executed on the database  User id of query issuer  Time of the query  Purpose of the query  Backlog database also stores updates to base tables in backlog tables  Need to reconstruct the query so capturing temporal information is important

40. Fine-grained Auditing Contd.  SQL statement to capture audit expressions  During clause specifies the time interval, audit-list is the set of columns, table-list gives the list of tables containing the columns and condition-list specifies the conditions that must be satisfied  Audit disease from customer c, treatment t where c.cid = t.pcid and c.zip = 95120 [during start-time to end-time] audit audit-list from table-list where condition-list

41. Fine-grained Auditing  An approach for generating queries and identifying suspicious queries  Identify candidate queries for auditing  Eliminate queries that are outside the time interval or not related to the columns being reviewed  Candidate queries are potential suspicious queries  Potential suspicious queries are combined with the audit expressions to generate auditing queries  Auditing query is run against a database reconstructed from the backlog database

42. Acknowledgement  Some pictures were taken from NIST documents

43. Lecture Objectives  Just glimpse into various aspects of Database Systems  Current students working on  Stream and event processing and their security  Online social networks  Access control, sybil detection  Privacy-preserving queries over encrypted data  Spatio-temporal access control  Distributed Denial-of-Service attacks  Modeling, verification, and analysis of security properties