Introduction to Computer Security Lecture 6 RBAC Policy

Introduction to Computer Security Lecture 6 RBAC, Policy Composition Design Principles October 14, 2003 Courtesy of Professors Chris Clifton & Matt Bishop INFSCI 2935: Introduction of Computer Security 1

RBAC (NIST Standard) PA UA Users Roles Operations Objects Permissions user_sessions (one-to-many) role_sessions (many-to-many) Sessions An important difference from classical models is that Subject in other models corresponds to a Session in RBAC INFSCI 2935: Introduction to Computer Security 2

Core RBAC (relations) l l l l l Permissions = 2 Operations x Objects UA ⊆ Users x Roles PA ⊆ Permissions x Roles assigned_users: Roles 2 Users assigned_permissions: Roles 2 Permissions Op(p): set of operations associated with permission p Ob(p): set of objects associated with permission p user_sessions: Users 2 Sessions session_user: Sessions Users session_roles: Sessions 2 Roles ¡ l session_roles(s) = {r | (session_user(s), r) UA)} avail_session_perms: Sessions 2 Permissions INFSCI 2935: Introduction to Computer Security 3

RBAC with General Role Hierarchy RH (role hierarchy) PA UA Users Roles Operations Objects Permissions user_sessions (one-to-many) role_sessions (many-to-many) Sessions INFSCI 2935: Introduction to Computer Security 4

RBAC with General Role Hierarchy l authorized_users: Roles 2 Users authorized_users(r) = {u | r’ ≥ r &(r’, u) UA) l authorized_permissions: Roles 2 Permissions authorized_users(r) = {p | r’ ≥ r &(p, r’) PA) l RH ⊆ Roles x Roles is a partial order called the inheritance relation ¡ written as ≥. ¡ (r 1 ≥ r 2) authorized_users(r 1) ⊆ authorized_users(r 2) & authorized_permisssions(r 2) ⊆ authorized_permisssions(r 1) INFSCI 2935: Introduction to Computer Security 5

Example pe py x, 10 e p 8 x, e p 9 y pxe, 5 py e p 3 x, e p 4 y pp e p 6 x, e py 7 po pa , pb e p 1 x, e p 2 y authorized_users(Employee)? pm, pn authorized_users(Administrator)? px , py p 1 , p 2 authorized_permissions(Employee)? authorized_permissions(Administrator)? INFSCI 2935: Introduction to Computer Security 6

Constrained RBAC RH (role hierarchy) Static Separation of Duty PA UA Users Roles Operations Objects Permissions user_sessions (one-to-many) Sessions Dynamic Separation of Duty INFSCI 2935: Introduction to Computer Security 7

Static Separation of Duty SSD ⊆2 Roles x N l In absence of hierarchy l ¡ l Collection of pairs (RS, n) where RS is a role set, n ≥ 2; for all (RS, n) SSD, for all t ⊆RS: |t| ≥ n ∩r t assigned_users(r)= In presence of hierarchy ¡ Collection of pairs (RS, n) where RS is a role set, n ≥ 2; for all (RS, n) SSD, for all t ⊆RS: |t| ≥ n ∩r t authorized_uers(r)= INFSCI 2935: Introduction to Computer Security 8

Dynamic Separation of Duty l DSD ⊆2 Roles ¡ Collection x. N of pairs (RS, n) where RS is a role set, n ≥ 2; ¡ A user cannot activate n or more roles from RS ¡ What if both SSD and DSD contains (RS, n)? Consider (RS, n) = ({r 1, r 2, r 3}, 2)? l If SSD – can r 1, r 2 and r 3 be assigned to u? l If DSD – can r 1, r 2 and r 3 be assigned to u? l INFSCI 2935: Introduction to Computer Security 9

MAC using RBAC M 1 H HR LW BLP Read Roles M 1 R (same lattice) M 2 R Write Roles M 1 W (inverse lattice) M 2 W LR H L M 2 Transformation rules • R = {L 1 R, L 2 R, …, Ln. R, L 1 W, L 2 W, …, Ln. W} • Two separate hierarchies for {L 1 R, L 2 R, …, Ln. R} and { L 1 W, L 2 W, …, Ln. W} • Each user is assigned to exactly two roles: x. R and LW • Each session has exactly two roles y. R and y. W INFSCI 2935: Introduction to Computer • Permission (o, r) is assigned to x. R iff (o, w)Security is assigned to x. W) 10

RBAC’s Benefits INFSCI 2935: Introduction to Computer Security 11

Cost Benefits l Saves about 7. 01 minutes per employee, per year in administrative functions ¡ ¡ Average IT amin salary - $59. 27 per hour The annual cost saving is: l l $6, 924/1000; $692, 471/100, 000 Reduced Employee downtime ¡ ¡ ¡ if new transitioning employees receive their system privileges faster, their productivity is increased 26. 4 hours for non-RBAC; 14. 7 hours for RBAC For average employee wage of $39. 29/hour, the annual productivity cost savings yielded by an RBAC system: l $75000/1000; $7. 4 M/100, 000 INFSCI 2935: Introduction to Computer Security 12

Time-based Access Control Requirement l Organizational functions and services with temporal requirements ¡ ¡ ¡ A part-time staff is authorized to work only between 9 am -2 pm on weekdays A day doctor must be able to perform his/her duties between 8 am-8 pm An external auditor needs access to organizational financial data for a period of three months A video library allows access to a subscriber to view at most three movies every week In an insurance company, an agent needs access to patient history until a claim has been settled INFSCI 2935: Introduction to Computer Security 13

Generalized Temporal RBAC l Triggers and Events l Temporal constraints ¡ Roles, user-role and role-permission assignment constraints ¡ Activation constraints (cardinality, active duration, . . ) l Temporal role hierarchy l Time-based Separation of duty constraints INFSCI 2935: Introduction to Computer Security 14

States of a Role in GTRBAC Enabled Active Disabled INFSCI 2935: Introduction to Computer Security 15

Event and Trigger l Simple events ¡ ¡ enable r assign. U r to u assign. P p to r activate r for u disable r deassign. U r to u deassign. P p to r deactivate r for u Prioritized event pr: E, where pr Prios l Status l ¡ l Role, assignment status – e. g. . enabled(r); p_assigned(p , r) Triggers: E 1 , …, En , C 1 , …, Ck pr: E after ∆t , where Ei are events, Ci are status expressions Example: enable Day. Doctor enable Doctor. In. Training after 1 hour l User/administrator run-time request: pr: E after ∆t INFSCI 2935: Introduction to Computer Security 16

Temporal Constraints: Roles, User-role and Role-permission Assignments l Periodic time ¡ ¡ l Calendars: ¡ l (I, P) : [begin, end], P is a set of intervals P is an infinite set of recurring intervals Hours, Days, Weeks, Months, Years Examples all. Weeks + {2, …, 6}. Days + 10. Hours ⊲ 12. hours - Daytime (9 am to 9 pm) of working days all. Weeks + {2, …, 6}. Days - Working days INFSCI 2935: Introduction to Computer Security 17

Temporal Constraints: Roles, User-role and Role-permission Assignments l Periodicity: (I, P, pr: E) ¡ ¡ l Duration constraint: (D, pr: E) ¡ ¡ l ([1/1/2001, ], Daytime, enable Day. Doctor) ([1/1/2000, ], {Mon, Wed}, assign. U Day. Doctor to Smith) (Five hours, enable Doctor. In. Training) activate Day. Doctor for Smith enable Doctor. In. Training after 1 hour Cardinality constraint: ([I, P], N, assign. U r ) ¡ ([1/1/2000, ], {Mon, Wed}, 5, assign. U Day. Doctor) INFSCI 2935: Introduction to Computer Security 18

Activation Time Constraints l Active role duration ¡ Total duration for role activation Per role: Dactive, [Ddefault], active. R_total r 2. Per user role: Duactive, u, active. UR_total r Max active role duration per activation C 1. Per role: Dmax, active. R_max r 2. Per user role: Dumax, u, active. UR_max r 1. ¡ l Cardinality 1. Total number of role activations Per role: Nactive, [Ndefault], active. R_n r 2. Per user role: Nuactive, u, active. UR_n r Max number of concurrent activations C 1. Per role: Nmax, [Ndefault], active. R_con r 2. Per user role: Numax, u , active. UR_con r 1. 2. INFSCI 2935: Introduction to Computer Security 19

Example of Activation Time Constraint l l Video library offers 600 hours of total time per week A, B and C subscribe for 100 hours each D subscribes for 250 hours E subscribes for 50 hours A B C (Weekly, 300, 100, active. R_total MV 1) D (Weekly, 250, active. R_total MV 2) E MV 1 MV 2 Video Database MV 3 (Weekly, 50, Introduction activeto. R_total MV 3) INFSCI 2935: Computer Security 20

Role Hierarchy in GTRBAC l GTRABC-based temporal role hierarchies allow ¡ Separation of permission inheritance and role activation semantics that facilitate management of access control ¡ Capturing the effect of the presence of temporal constraints on hierarchically related roles and therefore allowing fine-grained access control INFSCI 2935: Introduction to Computer Security 21

Types of Role Hierarchy l Permission-Inheritance hierarchy (I-hierarchy) ¡ ¡ l Role-Activation hierarchy (A-hierarchy) ¡ ¡ ¡ l Senior inherits juniors’ permission User assigned to senior cannot activate juniors Senior does not inherit juniors’ permissions User assigned to senior can activate juniors Advantage: SOD constraints can be hierarchically related roles defined General Inheritance hierarchy (IA-hierarchy) ¡ ¡ Senior inherits juniors’ permission User assigned to senior can activate juniors INFSCI 2935: Introduction to Computer Security 22

Types of Role Hierarchy u assigned to Software Engineer Combination of roles that can be activated by u: { (Software Engineer)} Combination of roles that can be activated by u {(Software Engineer), (Software Engineer, Programmer), (Programmer) } Programmer (a) IA Hierarchy Programmer (b) A Hierarchy INFSCI 2935: Introduction to Computer Security Programmer (c) I Hierarchy 23

Weakly Restricted and Strongly Restricted Temporal Role Hierarchies l I-hierarchy: (assume x is senior of y) ¡ Weakly restricted hierarchy l l ¡ Strongly restricted hierarchy l l x inherits y’s permissions only when both x and y enabled A-hierarchy: (assume x is senior of y and u is assigned to x) ¡ Weakly restricted hierarchy l l ¡ u can activate y x need not be enabled Strongly restricted hierarchy l l x inherits y’s permissions y need not be enabled u can activate y only when both x and y are enabled IA-hierarchy: x and y are related by both I-hierarchy and 24 A-hierarchy INFSCI 2935: Introduction to Computer Security

Temporal Role Hierarchy Example Part. Time. Doctor {(3 pm-6 pm), (7 am-10 am)} Part. Time. Doctor 7 am 10 am Is 9 am Day. Doctor 9 pm Night. Doctor 9 am Day. Doctor Is 9 pm Day. Doctor (9 am-9 pm) INFSCI 2935: Introduction to Computer Security Night. Doctor (9 pm-9 am) 25

Policy Composition Courtesy of Professors Chris Clifton & Matt Bishop INFSCI 2935: Introduction of Computer Security 26

Problem: Consistent Policies l Policies defined by different organizations ¡ Different needs ¡ But sometimes subjects/objects overlap l Can all policies be met? ¡ Different categories l Build lattice combining them ¡ Different l security levels Need to be levels – thus must be able to order ¡ What if different DAC and MAC policies need to be integrated? INFSCI 2935: Introduction to Computer Security 27

Multidomain Environments l Heterogeneity exists at several levels Security goals Constituent organizational units -UN -Federal -Local -EC etc. -Availability -Biba integrity model -Multilevel etc. -MLS DBMS -MLS OS etc. INFSCI 2935: Introduction to Computer Security Constituent systems 28

Multidomain Challenges Key challenges l Semantic heterogeneity l Secure interoperation l Assurance and risk propagation l Security Management INFSCI 2935: Introduction to Computer Security 29

Semantic heterogeneity l Different systems use different security policies ¡ l Variations of the same policies ¡ l ¡ Similar roles with different names Similar permission sets with different role names Structural conflict ¡ l e. g. , BLP model and its variations Naming conflict on security attributes ¡ l e. g. , Chinese wall, BLP policies etc. different multilevel lattices / role hierarchies Different Commercial-Off-The-Self (COTS) products INFSCI 2935: Introduction to Computer Security 30

Secure Interoperability l Principles of secure interoperation [Gong, 96] Principle of autonomy l If an access is permitted within an individual system, it must also be permitted under secure interoperation Principle of security l If an access is not permitted within an individual system, it must not be permitted under secure interoperation l Interoperation of secure systems can create new security breaches INFSCI 2935: Introduction to Computer Security 31

Secure Interoperability (Example) A B X a C 1 D b A Z B 2 1 systems 1 and 2 a C D Y b Z 2 F 12 = {a, b, c, d} F 12 = {a, b} F 12 - permitted access between d c Y X (1) F 12 = {a, b, d} Direct access INFSCI 2935: Introduction to Computer Security (2) F 12 = {c} Indirect access 32

Assurance and Risk Propagation & Security Management l Assurance and Risk propagation ¡ A breach in one component affects the whole environment ¡ Cascading problem l Management ¡ Centralized/Decentralized ¡ Managing metapolicy ¡ Managing policy evolution INFSCI 2935: Introduction to Computer Security 33

Design Principles Courtesy of Professors Chris Clifton & Matt Bishop INFSCI 2935: Introduction of Computer Security 34

Design Principles for Security Mechanisms l Principles Least Privilege ¡ Fail-Safe Defaults ¡ Economy of Mechanism ¡ Complete Mediation ¡ Open Design ¡ Separation of Privilege ¡ Least Common Mechanism ¡ Psychological Acceptability ¡ l Based on the idea of simplicity and restriction INFSCI 2935: Introduction to Computer Security 35

Overview l Simplicity ¡ Less to go wrong ¡ Fewer possible inconsistencies ¡ Easy to understand l Restriction ¡ Minimize access power (need to know) ¡ Inhibit communication INFSCI 2935: Introduction to Computer Security 36

Least Privilege l A subject should be given only those privileges necessary to complete its task ¡ Function, l RBAC! ¡ Rights l added as needed, discarded after use Active sessions and dynamic separation of duty ¡ Minimal l not identity, controls protection domain A subject should not have a right if the task does not need it INFSCI 2935: Introduction to Computer Security 37

Fail-Safe Defaults l Default action is to deny access l If action fails, system as secure as when action began ¡ Undo changes if actions do not complete ¡ Transactions (commit) INFSCI 2935: Introduction to Computer Security 38

Economy of Mechanism l Keep the design and implementation as simple as possible ¡ KISS Principle (Keep It Simple, Silly!) l Simpler means less can go wrong ¡ And when errors occur, they are easier to understand fix l Interfaces and interactions INFSCI 2935: Introduction to Computer Security 39

Complete Mediation l Check every access to an object to ensure that access is allowed l Usually done once, on first action ¡ UNIX: Access checked on open, not checked thereafter l If permissions change after, may get unauthorized access INFSCI 2935: Introduction to Computer Security 40

Open Design l Security should not depend on secrecy of design or implementation ¡ Popularly misunderstood to mean that source code should be public ¡ “Security through obscurity” ¡ Does not apply to information such as passwords or cryptographic keys INFSCI 2935: Introduction to Computer Security 41

Separation of Privilege l Require multiple conditions to grant privilege ¡ Example: Checks of $70000 must be signed by two people ¡ Separation of duty ¡ Defense in depth l Multiple levels of protection INFSCI 2935: Introduction to Computer Security 42

Least Common Mechanism l Mechanisms should not be shared ¡ Information can flow along shared channels ¡ Covert channels l Isolation ¡ Virtual machines ¡ Sandboxes INFSCI 2935: Introduction to Computer Security 43

Psychological Acceptability l Security mechanisms should not add to difficulty of accessing resource ¡ Hide complexity introduced by security mechanisms ¡ Ease of installation, configuration, use ¡ Human factors critical here INFSCI 2935: Introduction to Computer Security 44