institute for cyber security 1 access control prof. ravi sandhu executive director and endowed chair...
TRANSCRIPT
INSTITUTE FOR CYBER SECURITY
1
Access Control
Prof. Ravi SandhuExecutive Director and Endowed Chair
Institute for Cyber SecurityUniversity of Texas at San Antonio
May 2009
[email protected] www.profsandhu.com
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY 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 2
INSTITUTE FOR CYBER SECURITY ACCESS MATRIX MODEL
U r wown
V
F
Subjects
Objects (and Subjects)
r wown
G
r
rights
© Ravi Sandhu 3
INSTITUTE FOR CYBER SECURITY 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
each column of the access matrix is stored with the object corresponding to
that column
© Ravi Sandhu 4
INSTITUTE FOR CYBER SECURITY CAPABILITY LISTS
each row of the access matrix is stored with the subject corresponding to that
row
each row of the access matrix is stored with the subject corresponding to that
row
U F/r, F/w, F/own, G/r
V G/r, G/w, G/own
© Ravi Sandhu 5
INSTITUTE FOR CYBER SECURITY ACCESS CONTROL TRIPLES
Subject AccessObject
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 systemscommonly used in relational
database management systems
© Ravi Sandhu 6
INSTITUTE FOR CYBER SECURITY TROJAN HORSE EXAMPLE
File FA:r
A:w
File GB:r
A:w
B cannot read file FB cannot read file F
ACL
© Ravi Sandhu 7
INSTITUTE FOR CYBER SECURITY TROJAN HORSE EXAMPLE
File FA:r
A:w
File GB:r
A:w
B can read contents of file F copied to file G
B can read contents of file F copied to file G
ACLA
Program Goodies
Trojan Horse
executes
read
write
© Ravi Sandhu 8
INSTITUTE FOR CYBER SECURITY 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
INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES
Unclassified
Confidential
Secret
Top Secret
can-flowdominance
© Ravi Sandhu 10
INSTITUTE FOR CYBER SECURITY BELL LAPADULA (BLP) MODEL
SIMPLE-SECURITYSubject 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)Subject S can write object O only if
• label(O) equals label(S)
© Ravi Sandhu 11
INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES
{ARMY, CRYPTO}Compartmentsand Categories
{ARMY } {CRYPTO}
{}
© Ravi Sandhu 12
INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES
HierarchicalClasses with
CompartmentsTS
S
{A,B}
{}
{A} {B}
product of 2 lattices is a latticeproduct of 2 lattices is a lattice
© Ravi Sandhu 13
INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES
HierarchicalClasses with
Compartments
S,
{A,B}
{}
{A} {B}S, S,
S,
TS,
{A,B}
{}
{A} {B}TS, TS,
TS,
© Ravi Sandhu 14
INSTITUTE FOR CYBER SECURITY SMITH'S LATTICESMITH'S LATTICE
TS-W
S-W
TS
S
C
U
S-L
S-LW
S-A
TS-X
TS-L TS-K TS-Y TS-Q TS-Z TS-X
TS-KL
TS-KLXTS-KY TS-KQZ
TS-AKLQWXYZ
© Ravi Sandhu 15
INSTITUTE FOR CYBER SECURITY EQUIVALENCE OF BLP AND BIBA
HI (High Integrity)
LI (Low Integrity)
BIBA LATTICEBIBA LATTICE EQUIVALENT BLP LATTICEEQUIVALENT BLP LATTICE
LI (Low Integrity)
HI (High Integrity)
© Ravi Sandhu 16
INSTITUTE FOR CYBER SECURITY EQUIVALENCE OF BLP AND BIBA
HS (High Secrecy)
LS (Low Secrecy)
BLP LATTICEBLP LATTICE EQUIVALENT BIBA LATTICEEQUIVALENT BIBA LATTICE
LS (Low Secrecy)
HS (High Secrecy)
© Ravi Sandhu 17
INSTITUTE FOR CYBER SECURITY COMBINATION OF DISTINCT LATTICES
HS
LS
HI
LI
GIVENGIVEN
BLP BIBA
HS, LI
HS, HI LS, LI
LS, HI
EQUIVALENT BLP LATTICEEQUIVALENT BLP LATTICE
© Ravi Sandhu 18
INSTITUTE FOR CYBER SECURITY LIPNER'S LATTICE
LIPNER'S LATTICE
S: RepairS: Production UsersO: Production Data
S: Application Programmers
O: Development Code and Data
S: System Programmers
O: System Code in Development
O: Repair Code
O: System Programs
O: Production Code O: Tools
S: System ManagersO: Audit Trail
S: System Control
LEGEND
S: SubjectsO: Objects
LEGEND
S: SubjectsO: Objects
© Ravi Sandhu 19
INSTITUTE FOR CYBER SECURITY CHINESE WALL EXAMPLE
BANKS OIL COMPANIES
A B X Y
© Ravi Sandhu 20
INSTITUTE FOR CYBER SECURITY CHINESE WALL LATTICE
A, - B, --, X -, Y
A, X A, Y B, X B, Y
SYSHIGH
SYSLOW
© Ravi Sandhu 21
INSTITUTE FOR CYBER SECURITY COVERT CHANNELS
Low User
High Trojan HorseInfected Subject
High User
Low Trojan HorseInfected Subject
COVERTCHANNEL
Information is leaked unknown to the high user
Information is leaked unknown to the high user
© Ravi Sandhu 22
INSTITUTE FOR CYBER SECURITY 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
INSTITUTE FOR CYBER SECURITY 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 1970sFirst models: mid 1990s
Is RBAC MAC or DAC or neither?
© Ravi Sandhu 24
INSTITUTE FOR CYBER SECURITY 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
INSTITUTE FOR CYBER SECURITY RBAC96 Model
ROLES
USER-ROLEASSIGNMENT
PERMISSIONS-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
ROLE HIERARCHIES
CONSTRAINTS
© Ravi Sandhu 26
INSTITUTE FOR CYBER SECURITY
Example Role Hierarchy
Engineering Department (ED)
Project Lead 1(PL1)
Engineer 1(E1)
Production 1(P1)
Quality 1(Q1)
Director (DIR)
Project Lead 2(PL2)
Engineer 2(E2)
Production 2(P2)
Quality 2(Q2)
Employee (E)
Inheritance hierarchy
© Ravi Sandhu 27
INSTITUTE FOR CYBER SECURITY
Example Role Hierarchy
Engineering Department (ED)
Project Lead 1(PL1)
Engineer 1(E1)
Production 1(P1)
Quality 1(Q1)
Director (DIR)
Project Lead 2(PL2)
Engineer 2(E2)
Production 2(P2)
Quality 2(Q2)
Employee (E)
Inheritanceand activation hierarchy
© Ravi Sandhu 28
INSTITUTE FOR CYBER SECURITYNIST/ANSI RBAC Standard Model 2004
ROLES
USER-ROLEASSIGNMENT
PERMISSIONS-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
ROLE HIERARCHIES
CONSTRAINTS
Permission-role review is advanced requirement
Limited to separation of dutiesOverall formal
model is more complete
© Ravi Sandhu 29
INSTITUTE FOR CYBER SECURITY The RBAC Story
© Ravi Sandhu 30
2nd expansion phase1st expansion phase
1995 2000 2005 2008
Amount ofPublications
Year of Publication
28 30 30 35 40 48 53 88 85 88 112 103 111 866
1992
3 2 7 3
80
60
40
20
0
Pre-RBAC Early RBAC
100
RBAC96paper
ProposedStandard
StandardAdopted
INSTITUTE FOR CYBER SECURITY
Founding Principles of RBAC96
Abstraction of PrivilegesCredit 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 PrivilegeRight-size the rolesDon’t activate all roles all the time
Separation of DutyStatic separation: purchasing manager
versus accounts payable managerDynamic separation: cash-register clerk
versus cash-register manager
© Ravi Sandhu 31
INSTITUTE FOR CYBER SECURITY
ASCAA Principles for Future RBAC
Abstraction of PrivilegesCredit vs debitPersonalized permissions
Separation of Administrative Functions Containment
Least PrivilegeSeparation of DutiesUsage Limits
AutomationRevocationAssignment: (i) Self-assignment, (ii) Attribute-
based Context and environment adjustment
AccountabilityRe-authentication/Escalated authenticationClick-through obligationsNotification and alerts
© Ravi Sandhu 32
INSTITUTE FOR CYBER SECURITY 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
INSTITUTE FOR CYBER SECURITY Security Objectives
34
INTEGRITYmodification
AVAILABILITYaccess
CONFIDENTIALITYdisclosure
USAGEpurpose
USAGE
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Usage Control Scope
© Ravi Sandhu 35
Server-sideReference Monitor
(SRM)
Client-sideReference Monitor
(CRM)
TraditionalAccessControl
TrustManagement
Usage ControlSensitive
InformationProtection
IntellectualProperty Rights
Protection
PrivacyProtection
DRM
SRM & CRM
SecurityObjectives
Security Architectures
INSTITUTE FOR CYBER SECURITY Usage Control Model (UCON)
© Ravi Sandhu 36
Rights(R)
Authorizations
(A)
Subjects(S)
Objects(O)
Subject Attributes (SA) Object Attributes (OA)
Obligations(B)
Conditions(C)
UsageDecisions
before-usage ongoing-Usage after-usage
Continuity ofDecisions
pre-decision ongoing-decision
pre-update ongoing-update post-update
Mutability ofAttributes
• unified model integrating• authorization• obligation• conditions
• and incorporating• continuity of decisions• mutability of attributes
INSTITUTE FOR CYBER SECURITY Conclusion
Discretionary Access Control (DAC) Mandatory Access Control (MAC)
Equivalently Lattice-Based Access Control (LBAC) Role-Based Access Control (RBAC) Usage Control (UCON)
© Ravi Sandhu 37
Models are all importantA Policy Language is not a substitute for a good model