CSCE 522 Access Control

Midterm Exam Midterm is open book, online exam. It is individual work, you cannot share or discuss the answers with any other student. Plagiarism, cheating, copying from online sources will be penalized. You have 1 hour 30 minutes to write the midterm (allowing extra time to print and scan documents if needed). If you have special accommodation that permits additional time for the exam, please notify me ASAP. CSCE 522 - Farkas

Midterm Process On October 19 at 2:45 pm the Midterm quiz open Follow the link to the downloadable midterm If you print the midterm than hand-write your answers Scan your answers as a single .pdf file. Else type your answers to the .doc file save it as a .pdf file. Name your file as <last name_initialoffirstname>.pdf Upload your .pdf file into the dropbox assignment for Midterm Answers by 4:15 pm. Late submissions: -5 points/minute CSCE 522 - Farkas

Reading Reading for this lecture: Required: Pfleeger: Ch. 2.2 Recommended: S. De Capitani di Vimercati, P. Samarati, S. Jajodia: Policies, Models, and Languages for Access Control, in Databases in Networked Information Systems, Volume 3433 of the series Lecture Notes in Computer Science pp 225-237, http://spdp.di.unimi.it/papers/2005-DNIS.pdf CSCE 522 - Farkas

Access Control Access control: ensures that all direct accesses to object are authorized Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs Need: Proper user identification and authentication Information specifying the access rights is protected form modification CSCE 522 - Farkas

Access Control Requirement Cannot be bypassed Enforce least-privilege and need-to-know restrictions Enforce organizational policy CSCE 522 - Farkas

Access Control Protection objects: system resources for which protection is desirable Memory, file, directory, hardware resource, software resources, etc. Subjects: active entities requesting accesses to resources User, owner, program, etc. Access mode: type of access Read, write, execute CSCE 522 - Farkas

Access Control Access control components: Access control policy: specifies the authorized accesses of a system Access control mechanism: implements and enforces the policy Separation of components allows to: Define access requirements independently from implementation Compare different policies Implement mechanisms that can enforce a wide range of policies CSCE 522 - Farkas

System Architecture and Policy Simple monolithic system Distributed homogeneous system under centralized control Distributed autonomous systems homogeneous domain Distributed heterogeneous system Complexity Of Policy CSCE 522 - Farkas

Closed v.s. Open Systems Closed system Open System yes no no yes (minimum privilege) (maximum privilege) Access requ. Access requ. Allowed accesses Disallowed accesses Exists Rule? Exists Rule? yes no no yes Access permitted Access denied Access permitted Access denied CSCE 522 - Farkas

Negative Authorization Traditional systems: Mutual exclusion New systems: combined use of positive and negative authorizations Support exceptions Problems: How to deal with Incompleteness – Default policy Inconsistencies – Conflict resolution CSCE 522 - Farkas

Conflict Resolution Denial takes precedence Most specific takes precedence Most specific along a path takes precedence Priority-based Positional Grantor and time-dependent Single strategy vs. combination of strategies CSCE 522 - Farkas

Policy Specification Language Express policy concepts Required properties of policy languages: Support access control, delegation, and obligation Provide structuring constructs to handle large systems Support composite policies Must be able to analyze policies for conflicts and inconsistencies Extensible Comprehensible and easy to use CSCE 522 - Farkas

Policy Development Policy maker: Start with high-level policies Refine high-level policies to low-level policy specification Determine resources required to satisfy the policy Translate high-level policies into enforceable versions Support analysis that verifies that lower level policies actually meet the needs of higher level ones. CSCE 824 - Farkas

Authorization Management Who can grant and revoke access rights? Centralized administration: security officer Decentralized administration: locally autonomous systems Hierarchical decentralization: security officer > departmental system administrator > Windows NT administrator Ownership based: owner of data may grant access to other to his/her data (possibly with grant option) Cooperative authorization: predefined groups of users or predefined number of users may access data CSCE 522 - Farkas

Access Control Models All accesses Discretionary AC DAC Mandatory AC Role-Based AC RBAC CSCE 522 - Farkas

Discretionary Access Control Access control is based on User’s identity and Access control rules Most common administration: owner based Users can protect what they own Owner may grant access to others Owner may define the type of access given to others CSCE 522 - Farkas

Access Matrix Model OBJECTS AND SUBJECTS File 1 File 2 S U B J E C T Read Write Own Joe Sam CSCE 522 - Farkas

Implementation Access Control List (column) (ACL) File 1 File 2 Joe:Read Joe:Read Joe:Write Sam:Read Joe:Own Sam:Write Sam:Own Access Control List (column) (ACL) Capability List (row) Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read Sam: File 2/Read, File 2/Write, File 2/Own Subject Access Object Joe Read File 1 Joe Write File 1 Joe Own File 1 Joe Read File 2 Sam Read File 2 Sam Write File 2 Sam Own File 2 Access Control Triples CSCE 522 - Farkas

ACL vs. Capabilities ACL: Capabilities: Per object based Good for file systems Capabilities: Per subject based Good for environment with dynamic, short-lived subjects CSCE 522 - Farkas

Access Control Conditions Data-dependent conditions: access constraints based on the value of the accessed data Time-dependent: access constraints based on the time of the data access Context-dependent: access constraints based on combinations on data which can be accessed History-dependent: access constraints based on previously accessed data CSCE 522 - Farkas

DAC and Trojan Horse Brown: read, write Employee Read Employee REJECTED! Black is not allowed To access Employee Brown Black, Brown: read, write Black’s Employee Black CSCE 522 - Farkas

DAC and Trojan Horse Brown: read, write Employee Word Processor Reads Uses shared program Brown Black, Brown: read, write Black’s Employee TH Inserts Trojan Horse Into shared program Copies Employee To Black’s Black CSCE 522 - Farkas

DAC Overview Advantages: Disadvantages: Intuitive Easy to implement Inherent vulnerability (look TH example) Maintenance of ACL or Capability lists Maintenance of Grant/Revoke Limited power of negative authorization CSCE 522 - Farkas

Access Control RBAC

Reading assignments Required for access control classes: Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, Role-Based Access Control Models, IEEE Computer, Volume 29, Number 2, February 1996 http://csrc.nist.gov/rbac/sandhu96.pdf CSCE 522 - Farkas Lecture 16

RBAC Motivation Multi-user systems Multi-application systems Permissions are associated with roles Role-permission assignments are persistent v.s. user-permission assignments Intuitive: competency, authority and responsibility CSCE 522 - Farkas Lecture 16

Motivation Express organizational policies Separation of duties Delegation of authority Flexible: easy to modify to meet new security requirements Supports Least-privilege Data abstraction CSCE 522 - Farkas Lecture 16

CANNOT ENFORCE THESE PRINCIPLES RBAC Allows to express security requirements but CANNOT ENFORCE THESE PRINCIPLES e.g., RBAC can be configured to enforce BLP rules but its correctness depend on the configuration done by the system security officer. CSCE 522 - Farkas Lecture 16

Roles User group: collection of user with possibly different permissions Role: mediator between collection of users and collection of permissions RBAC independent from DAC and MAC (they may coexist) RBAC is policy neutral: configuration of RBAC determines the policy to be enforced CSCE 522 - Farkas Lecture 16

RBAC RBAC3 consolidated model RBAC1 RBAC2 role hierarchy constraints RBAC0 base model CSCE 522 - Farkas Lecture 16

RBAC0 U Users User assignment Permission assignment R Roles P . . S Permissions . . S Sessions CSCE 522 - Farkas Lecture 16

RBAC0 User: human beings Role: job function (title) Permission: approval of a mode of access (object, access mode) Always positive Abstract representation Can apply to single object or to many CSCE 522 - Farkas Lecture 16

RBAC0 UA: user-role assignments PA: role-permission assignment Many-to-many PA: role-permission assignment Session: mapping of a single user to possibly may roles Multiple roles can be activated simultaneously Permissions: union of permissions from all roles Each session is associated with a single user User may have multiple sessions at the same time CSCE 522 - Farkas Lecture 16

RBAC0 Components Users, Roles, Permissions, Sessions PA  P x R (many-to-many) UA  U x R (many-to-many) user: S  U, mapping each session si to a single user user(si) roles: S  2R, mapping each session si to a set of roles roles(si)  {r | (user(si),r)  UA} and si has permissions  rroles(si) {p | (p,r)  PA} CSCE 522 - Farkas Lecture 16

RBAC0 Permissions apply to data and resource objects only Permissions do NOT apply to RBAC components Administrative permissions: modify U,R,S,P Session: under the control of user to Activate any subset of permitted roles Change roles within a session CSCE 522 - Farkas Lecture 16

RBAC1 Role Hierarchy . U Users R Roles P S Sessions User assignment Permissions S Sessions User assignment Permission CSCE 522 - Farkas Lecture 16

RBAC1 Structuring roles Inheritance of permission from junior role (bottom) to senior role (top) Partial order Reflexive Transitive Anti-symmetric CSCE 522 - Farkas Lecture 16

RBAC1 Components Same as RBAC0: Users, Roles, Permissions, Sessions, PA  P x R, UA  U x R, user: S  U, mapping each session si to a single user user(si) RH  R x R, partial order ( dominance) roles: S  2R, mapping each session si to a set of roles roles(si)  {r | (r’  r) [(user(si),r’)  UA]} and si has permissions  rroles(si) {p | (r”  r) [(p,r”)  PA]} CSCE 522 - Farkas Lecture 16

RBAC1 Role Hierarchy Specialist Primary-care Physician Physician Inheritance of privileges Physician Health-care provider CSCE 522 - Farkas Lecture 16

RBAC2 U Users User assignment Permission assignment R Roles P Permissions Constraints . . S Sessions CSCE 522 - Farkas Lecture 16

RBAC2 – Constraints Enforces high-level organizational policies Management of decentralized security Constraints define “acceptable” and “not acceptable” accesses CSCE 522 - Farkas Lecture 16

RBAC2 Mutually exclusive roles Dual constraint of permission assignments (permission assigned to at most one mutually exclusive role) Cardinality constraints (e.g., # of roles an individual can belong) Prerequisite roles CSCE 522 - Farkas Lecture 16

RBAC2 Constraints can apply to sessions, user and roles functions CSCE 522 - Farkas Lecture 16

RBAC3 Role Hierarchy . U Users R Roles P S Sessions User assignment Permissions S Sessions User assignment Permission Constraints CSCE 522 - Farkas Lecture 16

Next Class Mandatory Access Control CSCE 522 - Farkas