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

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

Lecture Objectives  Complete access control  Few words about audit

Attribute-Based Access Control

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

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

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

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

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

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

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

XACML Policy Structure

Policy Language model

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

XACML Policies

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

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

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, her manager that Alice tried to access document X

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

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)

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

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

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

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

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

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

How does it work: Data Flow

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

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

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

NGAC Assignment and Association

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

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

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

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))

NGAC Functional Architecture

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

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

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

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 = [during start-time to end-time] audit audit-list from table-list where condition-list

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

Acknowledgement  Some pictures were taken from NIST documents

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