Date post: | 13-Dec-2015 |
Category: |
Documents |
Upload: | osborn-french |
View: | 217 times |
Download: | 0 times |
INSTITUTE FOR CYBER SECURITY
1
Security Models:Past, Present and Future
Prof. Ravi SandhuExecutive Director and Endowed Chair
Institute for Cyber SecurityUniversity of Texas at San Antonio
July 2009
[email protected] www.profsandhu.com
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY
2
THE BIG PICTURE
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Security Objectives
3
INTEGRITYmodification
AVAILABILITYaccess
CONFIDENTIALITYdisclosure
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Security Objectives
4
INTEGRITYmodification
AVAILABILITYaccess
CONFIDENTIALITYdisclosure
USAGEpurpose
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Security Objectives
5
INTEGRITYmodification
AVAILABILITYaccess
CONFIDENTIALITYdisclosure
USAGEpurpose
USAGE
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Security Trends and Change Drivers
© Ravi Sandhu 6
Stand-alone computers Internet
Enterprise securityMutually suspicious yet mutually dependent security
Vandals Criminals, Nation states, Terrorists
Few standard servicesMany and newinnovative services
We are at an inflection point
INSTITUTE FOR CYBER SECURITY Diffie on Information Security … 2007
“Now we face a new challenge to security, a world of shared computing and web services. As with radio, this technology is too valuable to go unused, By contrast with radio, which could be protected with cryptography, there may be no technology that can protect shared computation to the degree we would call secure today. In a decade or a generation, there may be no secure computing.”
© Ravi Sandhu 7
Need to be realistic in our security expectations
INSTITUTE FOR CYBER SECURITY Butler Lampson Paraphrased (I think)
Computer scientists could never have designed the web because they would have tried to make it work.But the Web does “work.”What does it mean for the Web to “work”?
Security geeks could never have designed the ATM network because they would have tried to make it secure.But the ATM network is “secure.What does it mean for the ATM network to be “secure”?
© Ravi Sandhu 8
INSTITUTE FOR CYBER SECURITY Foundational Security Assumptions
Information needs to be protected In motion At rest In use
Absolute security is impossible and unnecessary Trying to approximate absolute security is a bad
strategy “Good enough” security is feasible and meaningful Better than “good enough” is bad
Security is meaningless without application context Cannot know we have “good enough” without this
context Models and abstractions are all important
Without a conceptual framework it is hard to separate “what needs to be done” from “how we do it”
© Ravi Sandhu 9
We are not very good at doing any of this
INSTITUTE FOR CYBER SECURITY Application Context
Our Basic Premise There can be no security without application context Courtney’s Law (1970s, 1980s ??):
You cannot say anything interesting (i.e. significant) about the security of a system except in the context of a particular application and environment
Corollary There can be no security model without application
context Reality
Existing security models are application neutral Assumption is they can be readily “configured” or
“policy-fied” to suit application context
© Ravi Sandhu 10
There is also a notion of technology contextfor security models but out of scope for this lecture
INSTITUTE FOR CYBER SECURITY Application Context
Software-Architect Project % Time LabelAlice Vista 25% UAlice SecureVista 75% SBob XP 100% U
What precisely is Secret? There exists a SecureVista project Alice works on SecureVista Alice’s effort on SecureVista is 75% All or some of the above
How do we maintain integrity of the database? Depends
© Ravi Sandhu 11
Much work and $$$ by researchers and vendors, late 80’s-early 90’s
INSTITUTE FOR CYBER SECURITY Emerging Application-Centric Era (ACE)
© Ravi Sandhu 12
ECEEnterprise-Centric Era
ACEApplication-Centric Era
Applications are cyber analogs ofpreviously existing enterprise-centricapplications
• on-line banking• brokerage• e-retail• auctions• search engines
Future applications will befundamentally different
• ?• ?• ?• ?• ?
INSTITUTE FOR CYBER SECURITY PEI Models: 3 Layers/5 Layers
© Ravi Sandhu 13
Idealized
Enforceable(Approximate)
Codeable
This lecture is focused on the policy models layer
At the policy layer security models are essentially access control models
INSTITUTE FOR CYBER SECURITY
14
THE PAST
© Ravi Sandhu
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)Same as Lattice-Based Access Control (LBAC) 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
© Ravi Sandhu 15
INSTITUTE FOR CYBER SECURITY ACCESS MATRIX MODEL
U r wown
V
F
Subjects
Objects (and Subjects)
r wown
G
r
rights
© Ravi Sandhu 16
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 17
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 18
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 19
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 20
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 21
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
Traditional DAC is weak with respect to confidentiality but may have value with respect to integrity
© Ravi Sandhu 22
INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES
Unclassified
Confidential
Secret
Top Secret
can-flowdominance
© Ravi Sandhu 23
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 24
INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES
{ARMY, CRYPTO}Compartmentsand Categories
{ARMY } {CRYPTO}
{}
© Ravi Sandhu 25
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 26
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 27
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 28
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 29
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 30
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 31
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 32
INSTITUTE FOR CYBER SECURITY CHINESE WALL EXAMPLE
BANKS OIL COMPANIES
A B X Y
© Ravi Sandhu 33
INSTITUTE FOR CYBER SECURITY CHINESE WALL LATTICE
A, - B, --, X -, Y
A, X A, Y B, X B, Y
SYSHIGH
SYSLOW
© Ravi Sandhu 34
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 35
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 36
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 37
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 38
INSTITUTE FOR CYBER SECURITY RBAC96 Model
ROLES
USER-ROLEASSIGNMENT
PERMISSIONS-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
© Ravi Sandhu 39
INSTITUTE FOR CYBER SECURITY RBAC96 Model
ROLES
USER-ROLEASSIGNMENT
PERMISSIONS-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
ROLE HIERARCHIES
© Ravi Sandhu 40
INSTITUTE FOR CYBER SECURITY RBAC96 Model
ROLES
USER-ROLEASSIGNMENT
PERMISSIONS-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
ROLE HIERARCHIES
CONSTRAINTS
© Ravi Sandhu 41
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 42
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 43
INSTITUTE FOR CYBER SECURITY NIST/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 44
INSTITUTE FOR CYBER SECURITY The RBAC Story
© Ravi Sandhu 45
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
46
THE PRESENT
© Ravi Sandhu
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)Same as Lattice-Based Access Control (LBAC) 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 47
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 48
INSTITUTE FOR CYBER SECURITY
ASCAA Principles for Future Access Control
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 49
INSTITUTE FOR CYBER SECURITY Usage Control Scope
© Ravi Sandhu 50
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 51
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 Usage Control Model (UCON)
DAC LBAC RBAC ABAC … and many, many others UCON
ABAC on steroids Simple, familiar, usable and effective use cases demonstrate
the need for UCON Automatic Teller Machines CAPTCHAs at Public web sites End User Licencse Agreements Terms of Usage for WiFi in Hotels, Airports Rate limits on call center workers
© Ravi Sandhu 52
INSTITUTE FOR CYBER SECURITY
53
THE FUTURE
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Application-Centric Security Models
Our Basic Premise There can be no security model without application context
So how does one customize an application-centric security model? Meaningfully combine the essential insights of
DAC, LBAC, RBAC, ABAC, UCON, etcetera Directly address the application-specific trade-offs
Within the security objectives of confidentiality, integrity and availability
Across security, performance, cost and usability objectives Separate the real-world concerns of
practical distributed systems and ensuing staleness and approximations (enforcement layer) from
policy concerns in a idealized environment (policy layer)
© Ravi Sandhu 54
INSTITUTE FOR CYBER SECURITY PEI Models: 3 Layers/5 Layers
© Ravi Sandhu 55
Idealized
Enforceable(Approximate)
Codeable
This lecture is focused on the policy models layer
INSTITUTE FOR CYBER SECURITY Dissemination-Centric Sharing
Extensive research in the last two decades ORCON, DRM, ERM, XrML, ODRL, etc.
Copy/usage control has received major attention Manageability problem largely unaddressed
Alice Bob Charlie Eve Susie
Attribute + Policy Cloud
Object
Attribute + Policy Cloud
Object
Attribute + Policy Cloud
Object
Attribute + Policy Cloud
Object
Dissemination Chain with Sticky Policies on Objects
Attribute Cloud
Attribute Cloud
Attribute Cloud
Attribute Cloud
Attribute Cloud
© Ravi Sandhu 56
INSTITUTE FOR CYBER SECURITY Group-Centric Sharing (g-SIS)
Brings users & objects together in a group Focuses on manageability using groups Co-exists with dissemination-centric Two metaphors
Secure Meeting Room (E.g. Program committee) Subscription Model (E.g. Secure multicast)
Operational aspects Group characteristics
E.g. Are there any core properties? Group operation semantics
E.g. What is authorized by join, add, etc.? Read-only Vs Read-Write
Administrative aspects E.g. Who authorizes join, add, etc.? May be application dependant
Multiple groups Inter-group relationship
GroupAuthz (u,o,r)?
join leave
add remove
Users
Objects
© Ravi Sandhu 57
INSTITUTE FOR CYBER SECURITY g-SIS Operation Semantics
GROUPAuthz (u,o,r)?
join leave
add remove
Users
Objects
© Ravi Sandhu 58
INSTITUTE FOR CYBER SECURITY g-SIS Operation Semantics
GROUPAuthz (u,o,r)?
Strict Join
Strict Leave
Liberal Add
Liberal Remove
LiberalJoin
LiberalLeave
StrictAdd Strict
Remove
Users
Objects
© Ravi Sandhu 59
INSTITUTE FOR CYBER SECURITY Family of g-SIS Policy Models
Most Restrictiveg-SIS Specification:
Traditional Groups: <LJ, SL, LA, SR>Secure Multicast: <SJ, LL, LA, *>
© Ravi Sandhu 60
INSTITUTE FOR CYBER SECURITY g-SIS Enforcement Model
CC
GA
Group Subjects
TRM TRM TRM…
1. Read Objects
5.1 Request R
efresh
5.2 Update Attributes
3.1 Subject
Leave (s)
4.1 Object
Remove (o)
3.2 Set Leave-TS (s)
4.2 Add o to ORL CC: Control Center
GA: Group Administrator
Subject Attributes: {id, Join-TS, Leave-TS, ORL, gKey}
ORL: Object Revocation List gKey: Group Key
Object Attributes: {id, Add-TS}
Refresh Time (RT): TRM contacts CC to update attributes
© Ravi Sandhu 61
INSTITUTE FOR CYBER SECURITY From Policy to Enforcement
Additional Trusted/Semi-Trusted Servers Approximate Enforcement
Finally, the Implementation layer models spell out protocol details and details of TRM algorithms
© Ravi Sandhu 62
INSTITUTE FOR CYBER SECURITY
63
CONCLUSION
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Conclusion
THE PAST Discretionary Access Control (DAC) Mandatory Access Control (MAC)
Equivalently Lattice-Based Access Control (LBAC) Role-Based Access Control (RBAC)THE PRESENT Usage Control (UCON)
Attribute-Based Access Control (ABAC) on steroidsTHE FUTURE Application-Centric Access Control Models Technology-Centric Access Control Models
© Ravi Sandhu 64
Models are all importantA Policy Language is not a substitute for a good model