Access Control Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security University of Texas at San Antonio May 2009 ravi.sandhu@utsa.edu www.profsandhu.com © Ravi Sandhu

Discretionary Access Control (DAC) Mandatory Access Control (MAC) Outline Discretionary Access Control (DAC) Mandatory Access Control (MAC) Equivalently Lattice-Based Access Control (LBAC) Role-Based Access Control (RBAC) Usage Control (UCON) © Ravi Sandhu

ACCESS MATRIX MODEL Objects (and Subjects) F G r w S r U own u b j e c V rights © Ravi Sandhu 3

ACCESS CONTROL LISTS (ACLs) F U:r U:w U:own G U:r V:r V:w V:own each column of the access matrix is stored with the object corresponding to that column © Ravi Sandhu 4

CAPABILITY LISTS U F/r, F/w, F/own, G/r V G/r, G/w, G/own each row of the access matrix is stored with the subject corresponding to that row © Ravi Sandhu 5

ACCESS CONTROL TRIPLES Subject Access Object U r F U w F U own F U r G V r G V w G V own G commonly used in relational database management systems © Ravi Sandhu 6

TROJAN HORSE EXAMPLE ACL A:r File F A:w B:r File G A:w B cannot read file F © Ravi Sandhu 7

B can read contents of file F copied to file G TROJAN HORSE EXAMPLE A ACL executes File F A:r A:w read Program Goodies Trojan Horse File G B:r A:w write B can read contents of file F copied to file G © Ravi Sandhu 8

DAC Summary Traditional DAC does not prevent copies from being made and there is no control over copies Modern approaches to information sharing and trusted computing seek to maintain control over copies (for example, our talk on Friday) Traditional DAC is weak with respect to confidentiality but may have value with respect to integrity © Ravi Sandhu 9

LATTICE STRUCTURES Top Secret Secret Confidential Unclassified dominance  can-flow © Ravi Sandhu 10

BELL LAPADULA (BLP) MODEL SIMPLE-SECURITY Subject S can read object O only if label(S) dominates label(O) STAR-PROPERTY (LIBERAL) Subject S can write object O only if label(O) dominates label(S) STAR-PROPERTY (STRICT) label(O) equals label(S) © Ravi Sandhu 11

LATTICE STRUCTURES Compartments and Categories {ARMY, CRYPTO} {ARMY } {} © Ravi Sandhu 12

product of 2 lattices is a lattice LATTICE STRUCTURES Hierarchical Classes with Compartments {A,B} TS {A} {B} {} S product of 2 lattices is a lattice © Ravi Sandhu 13

LATTICE STRUCTURES TS, {A,B} Hierarchical Classes with Compartments {} S, {A,B} S, {A} S, {B} S, {} © Ravi Sandhu 14

SMITH'S LATTICE TS-AKLQWXYZ TS-KLX TS-KY TS-KQZ TS-KL TS-W TS-X TS-X TS-Q TS-Z TS-L TS-K TS-Y S-LW S-L TS S-A S-W S C © Ravi Sandhu U 15

EQUIVALENCE OF BLP AND BIBA HI (High Integrity) LI (Low Integrity)  LI (Low Integrity) HI (High Integrity) BIBA LATTICE EQUIVALENT BLP LATTICE © Ravi Sandhu 16

EQUIVALENCE OF BLP AND BIBA HS (High Secrecy) LS (Low Secrecy)  LS (Low Secrecy) HS (High Secrecy) BLP LATTICE EQUIVALENT BIBA LATTICE © Ravi Sandhu 17

COMBINATION OF DISTINCT LATTICES HS HI HS, LI  HS, HI LS, LI LS LI LS, HI BLP BIBA GIVEN EQUIVALENT BLP LATTICE © Ravi Sandhu 18

LIPNER'S LATTICE S: System Managers O: Audit Trail LEGEND S: Subjects O: Objects S: System Control S: Application Programmers O: Development Code and Data S: System Programmers O: System Code in Development S: Repair S: Production Users O: Production Data O: Repair Code O: Production Code O: Tools O: System Programs © Ravi Sandhu 19

CHINESE WALL EXAMPLE BANKS OIL COMPANIES A B X Y © Ravi Sandhu 20

CHINESE WALL LATTICE SYSHIGH A, X A, Y B, X B, Y A, - -, X -, Y B, - SYSLOW © Ravi Sandhu 21

Information is leaked unknown to the high user COVERT CHANNELS High Trojan Horse Infected Subject High User Information is leaked unknown to the high user COVERT CHANNEL Low Trojan Horse Infected Subject Low User © Ravi Sandhu 22

LBAC fails to control covert channels MAC/LBAC Summary LBAC fails to control covert channels LBAC fails to control inference and aggregation It is too rigid for most commercial applications It has strong mathematical foundations © Ravi Sandhu 23

RBAC: Role-Based Access Control Access is determined by roles A user’s roles are assigned by security administrators A role’s permissions are assigned by security administrators First emerged: mid 1970s First models: mid 1990s Is RBAC MAC or DAC or neither? © Ravi Sandhu 24

Fundamental Theorem of RBAC RBAC can be configured to do MAC RBAC can be configured to do DAC RBAC is policy neutral RBAC is neither MAC nor DAC! © Ravi Sandhu 25

... RBAC96 Model ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS ... SESSIONS This is a somewhat busy slide It shows a bird’s eye view of RBAC There are many details that need to be debated and filled in Some of these will be discussed in the subsequent panel For our purpose the bird’s eye view will suffice CONSTRAINTS © Ravi Sandhu 26

Example Role Hierarchy Director (DIR) Project Lead 1 (PL1) Project Lead 2 (PL2) Production 1 (P1) Quality 1 (Q1) Production 2 (P2) Quality 2 (Q2) Engineer 1 (E1) Engineer 2 (E2) Engineering Department (ED) Inheritance hierarchy Employee (E) © Ravi Sandhu 27

Example Role Hierarchy Director (DIR) Project Lead 1 (PL1) Project Lead 2 (PL2) Production 1 (P1) Quality 1 (Q1) Production 2 (P2) Quality 2 (Q2) Engineer 1 (E1) Engineer 2 (E2) Engineering Department (ED) Inheritance and activation hierarchy Employee (E) © Ravi Sandhu 28

NIST/ANSI RBAC Standard Model 2004 Permission-role review is advanced requirement ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS Limited to separation of duties ... Overall formal model is more complete SESSIONS This is a somewhat busy slide It shows a bird’s eye view of RBAC There are many details that need to be debated and filled in Some of these will be discussed in the subsequent panel For our purpose the bird’s eye view will suffice CONSTRAINTS © Ravi Sandhu 29

The RBAC Story Standard Adopted Proposed Standard RBAC96 paper © Ravi Sandhu 30

Founding Principles of RBAC96 Abstraction of Privileges Credit is different from Debit even though both require read and write Separation of Administrative Functions Separation of user-role assignment from role- permission assignment Least Privilege Right-size the roles Don’t activate all roles all the time Separation of Duty Static separation: purchasing manager versus accounts payable manager Dynamic separation: cash-register clerk versus cash-register manager © Ravi Sandhu 31

ASCAA Principles for Future RBAC Abstraction of Privileges Credit vs debit Personalized permissions Separation of Administrative Functions Containment Least Privilege Separation of Duties Usage Limits Automation Revocation Assignment: (i) Self-assignment, (ii) Attribute-based Context and environment adjustment Accountability Re-authentication/Escalated authentication Click-through obligations Notification and alerts © Ravi Sandhu 32

Access Control Models Discretionary Access Control (DAC) Owner controls access but only to the original, not to copies Mandatory Access Control (MAC) Access based on security labels Labels propagate to copies Role-Based Access Control (RBAC) Access based on roles Can be configured to do DAC or MAC Attribute-Based Access Control (ABAC) Access based on attributes, to possibly include roles, security labels and whatever © Ravi Sandhu 33

Security Objectives USAGE purpose USAGE INTEGRITY modification AVAILABILITY access CONFIDENTIALITY disclosure © Ravi Sandhu 34

Security Architectures Usage Control Scope Security Objectives Security Architectures © Ravi Sandhu 35

Usage Control Model (UCON) unified model integrating authorization obligation conditions and incorporating continuity of decisions mutability of attributes © Ravi Sandhu 36

Discretionary Access Control (DAC) Mandatory Access Control (MAC) Conclusion Discretionary Access Control (DAC) Mandatory Access Control (MAC) Equivalently Lattice-Based Access Control (LBAC) Role-Based Access Control (RBAC) Usage Control (UCON) Models are all important A Policy Language is not a substitute for a good model © Ravi Sandhu 37