Transcript Attribute-Based Access Control

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
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, email 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:



Object Attribute Names:


A(u1) = {Smith, IRS Agent};
A(o1) = {Smith};
A(u2) = {Johnson, IRS Agent}
A(o2) = {Brown}
Environment Name and Value:


Return = {Smith, Brown}
Attribute Value Assignments:



UserName = {Smith, Johnson, Thompson};
Roles = {IRS Agent, Auditor, AR Clerk}
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 <PolicyIssuer> element that
describes the source of the policy
 Absence of <PolicyIssuer> 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
 <op, o>p is a process p access request where op is an
operation and o is an object
 <op, o>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 = 95120
[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