Transcript Slide 1

INSTITUTE FOR CYBER SECURITY
Security Models:
Past, Present and Future
Prof. Ravi Sandhu
Executive Director and Endowed Chair
Institute for Cyber Security
University of Texas at San Antonio
July 2010
[email protected]
www.profsandhu.com
© Ravi Sandhu
1
INSTITUTE FOR CYBER SECURITY
THE BIG PICTURE
© Ravi Sandhu
2
INSTITUTE FOR CYBER SECURITY
Security Objectives
INTEGRITY
modification
AVAILABILITY
access
CONFIDENTIALITY
disclosure
© Ravi Sandhu
3
INSTITUTE FOR CYBER SECURITY
Security Objectives
USAGE
purpose
INTEGRITY
modification
AVAILABILITY
access
CONFIDENTIALITY
disclosure
© Ravi Sandhu
4
Security Objectives
INSTITUTE FOR CYBER SECURITY
USAGE
purpose
INTEGRITY
modification
USAGE
AVAILABILITY
access
CONFIDENTIALITY
disclosure
© Ravi Sandhu
5
INSTITUTE FOR CYBER SECURITY
Security Trends and Change Drivers
Stand-alone computers
Internet
Vandals
Criminals, Nation states, Terrorists
Enterprise security
Mutually suspicious yet mutually
dependent security
Few standard services
Many and new
innovative services
We are at an inflection point
© Ravi Sandhu
6
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.”
Need to be realistic in our security expectations
© Ravi Sandhu
7
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

Information needs to be protected






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


In motion
At rest
In use
Absolute security is impossible and unnecessary


Foundational Security Assumptions
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”
We are not very good at doing any of this
© Ravi Sandhu
9
INSTITUTE FOR CYBER SECURITY

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


Application Context
There can be no security model without application context
Reality

Existing security models are application neutral
 Assumption is they can be readily “configured” or “policyfied” to suit application context
There is also a notion of technology context
for security models but out of scope for this lecture
© Ravi Sandhu
10
Application Context
INSTITUTE FOR CYBER SECURITY
SoftwareArchitect
Alice
Alice
Bob

% Time
25%
75%
100%
Label
U
S
U
What precisely is Secret?





Project
Vista
SecureVista
XP
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
Much work and $$$ by researchers and
vendors, late 80’s-early 90’s
© Ravi Sandhu
11
INSTITUTE FOR CYBER SECURITY
Emerging Application-Centric Era (ACE)
ECE
ACE
Enterprise-Centric Era
Application-Centric Era
Applications are cyber analogs of
previously existing enterprise-centric
applications
•
•
•
•
•
on-line banking
brokerage
e-retail
auctions
search engines
© Ravi Sandhu
Future applications will be
fundamentally different
•
•
•
•
•
?
?
?
?
?
12
INSTITUTE FOR CYBER SECURITY
PEI Models: 3 Layers/5 Layers
This lecture is focused on
the policy models layer
Idealized
Enforceable
(Approximate)
Codeable
At the policy layer security models are
essentially access control models
© Ravi Sandhu
13
INSTITUTE FOR CYBER SECURITY
THE PAST
© Ravi Sandhu
14
INSTITUTE FOR CYBER SECURITY

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 Control Models
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
ACCESS MATRIX MODEL
INSTITUTE FOR CYBER SECURITY
Objects (and Subjects)
G
F
S
u
b
j
e
c
t
s
U
V
rw
own
r
rw
own
rights
© Ravi Sandhu
16
INSTITUTE FOR CYBER SECURITY
ACCESS CONTROL LISTS (ACLs)
F
G
U:r
U:r
U:w
V:r
U:own
V:w
V:own
each column of the access matrix is stored
with the object corresponding to that column
© Ravi Sandhu
17
INSTITUTE FOR CYBER SECURITY
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
18
INSTITUTE FOR CYBER SECURITY
Subject
ACCESS CONTROL TRIPLES
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
19
INSTITUTE FOR CYBER SECURITY
TROJAN HORSE EXAMPLE
ACL
A:r
File F
A:w
B:r
File G
A:w
B cannot read file F
© Ravi Sandhu
20
INSTITUTE FOR CYBER SECURITY
TROJAN HORSE EXAMPLE
ACL
A
executes
Program Goodies
A:r
read
File F
A:w
Trojan Horse
B:r
write
File G
A:w
B can read contents of file F copied to file G
© Ravi Sandhu
21
INSTITUTE FOR CYBER SECURITY

Traditional DAC does not prevent copies from being
made and there is no control over copies


DAC Summary
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
LATTICE STRUCTURES
INSTITUTE FOR CYBER SECURITY
Top Secret
Secret
Confidential
Unclassified
dominance

© Ravi Sandhu
can-flow
23
INSTITUTE FOR CYBER SECURITY
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)
Subject S can write object O only if
•
© Ravi Sandhu
label(O) equals label(S)
24
LATTICE STRUCTURES
INSTITUTE FOR CYBER SECURITY
{ARMY, CRYPTO}
{ARMY }
Compartments
and Categories
{CRYPTO}
{}
© Ravi Sandhu
25
LATTICE STRUCTURES
INSTITUTE FOR CYBER SECURITY
Hierarchical
Classes with
Compartments
{A,B}
TS
{B}
{A}
S
{}
product of 2 lattices is a lattice
© Ravi Sandhu
26
LATTICE STRUCTURES
INSTITUTE FOR CYBER SECURITY
TS, {A,B}
TS, {B}
TS, {A}
Hierarchical
Classes with
Compartments
TS, {}
S, {A,B}
S, {A}
S, {B}
S, {}
© Ravi Sandhu
27
INSTITUTE FOR CYBER SECURITY
SMITH'S LATTICE
TS-AKLQWXYZ
TS-KLX
TS-KY
TS-KQZ
TS-KL
TS-W
TS-X
TS-L
TS-K
TS-Y
TS-Q
TS-Z
TS-X
S-LW
S-L
TS
S-A
S-W
S
C
© Ravi Sandhu
U
28
INSTITUTE FOR CYBER SECURITY
EQUIVALENCE OF BLP AND BIBA
HI (High Integrity)
LI (Low Integrity)

LI (Low Integrity)
BIBA LATTICE
© Ravi Sandhu
HI (High Integrity)
EQUIVALENT BLP LATTICE
29
INSTITUTE FOR CYBER SECURITY
EQUIVALENCE OF BLP AND BIBA
HS (High Secrecy)
LS (Low Secrecy)

LS (Low Secrecy)
BLP LATTICE
© Ravi Sandhu
HS (High Secrecy)
EQUIVALENT BIBA LATTICE
30
INSTITUTE FOR CYBER SECURITY
COMBINATION OF DISTINCT LATTICES
HI
HS
HS, LI
 HS, HI
LI
LS
BLP
LS, LI
LS, HI
BIBA
GIVEN
© Ravi Sandhu
EQUIVALENT BLP LATTICE
31
INSTITUTE FOR CYBER SECURITY
LIPNER'S
LATTICE
S: System Managers
O: Audit Trail
LEGEND
S: Subjects
O: Objects
S: Repair
S: Production Users
O: Production Data
O: Repair Code
© Ravi Sandhu
S:
System Control
S:
Application
Programmers
O: Development
Code and Data
O: Production Code
O: System Programs
S:
System
Programmers
O: System Code in
Development
O: Tools
32
CHINESE WALL EXAMPLE
INSTITUTE FOR CYBER SECURITY
OIL COMPANIES
BANKS
A
© Ravi Sandhu
B
X
Y
33
CHINESE WALL LATTICE
INSTITUTE FOR CYBER SECURITY
SYSHIGH
A, X
A, Y
B, X
B, Y
A, -
-, X
-, Y
B, -
SYSLOW
© Ravi Sandhu
34
INSTITUTE FOR CYBER SECURITY
High User
Information is leaked
unknown to the high user
Low User
© Ravi Sandhu
COVERT CHANNELS
High Trojan Horse
Infected Subject
COVERT
CHANNEL
Low Trojan Horse
Infected Subject
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
Is RBAC MAC or DAC or neither?
© Ravi Sandhu
First emerged: mid
1970s
First models: mid
1990s
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
RBAC96 Model
INSTITUTE FOR CYBER SECURITY
USER-ROLE
ASSIGNMENT
ROLES
USERS
...
© Ravi Sandhu
PERMISSIONS-ROLE
ASSIGNMENT
PERMISSIONS
SESSIONS
39
RBAC96 Model
INSTITUTE FOR CYBER SECURITY
ROLE HIERARCHIES
USER-ROLE
ASSIGNMENT
ROLES
USERS
...
© Ravi Sandhu
PERMISSIONS-ROLE
ASSIGNMENT
PERMISSIONS
SESSIONS
40
RBAC96 Model
INSTITUTE FOR CYBER SECURITY
ROLE HIERARCHIES
USER-ROLE
ASSIGNMENT
ROLES
USERS
...
© Ravi Sandhu
PERMISSIONS-ROLE
ASSIGNMENT
PERMISSIONS
SESSIONS
CONSTRAINTS
41
INSTITUTE FOR CYBER SECURITY
Example Role Hierarchy
Director (DIR)
Project Lead 1
(PL1)
Production 1
(P1)
Project Lead 2
(PL2)
Quality 1
(Q1)
Production 2
(P2)
Engineer 1
(E1)
Inheritance
hierarchy
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
© Ravi Sandhu
42
INSTITUTE FOR CYBER SECURITY
Example Role Hierarchy
Director (DIR)
Project Lead 1
(PL1)
Production 1
(P1)
Project Lead 2
(PL2)
Quality 1
(Q1)
Production 2
(P2)
Engineer 1
(E1)
Inheritance
and activation
hierarchy
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
© Ravi Sandhu
43
INSTITUTE FOR CYBER SECURITY
NIST/ANSI RBAC Standard Model 2004
Permission-role review is
ROLE HIERARCHIES advanced requirement
USER-ROLE
ASSIGNMENT
ROLES
USERS
Overall formal
model is more
complete
© Ravi Sandhu
PERMISSIONS-ROLE
ASSIGNMENT
...
PERMISSIONS
Limited to
separation of
duties
SESSIONS
CONSTRAINTS
44
The RBAC Story
INSTITUTE FOR CYBER SECURITY
Amount of
Publications
Standard
Adopted
Proposed
Standard
100
80
RBAC96
paper
60
40
20
0
1992
3
Pre-RBAC
© Ravi Sandhu
1995
2
7
Early RBAC
3
2000
28
30
30
35
40
1st expansion phase
48
53
88
85
88
Year of
Publication
2008
2005
112
103
111

866
2nd expansion phase
45
INSTITUTE FOR CYBER SECURITY
THE PRESENT
© Ravi Sandhu
46
INSTITUTE FOR CYBER SECURITY

Discretionary Access Control (DAC)



Access based on security labels
Labels propagate to copies
Role-Based Access Control (RBAC)



Owner controls access but only to the original, not to copies
Mandatory Access Control (MAC)
Same as Lattice-Based Access Control (LBAC)


Access Control Models
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 Privileges
 Credit is different from Debit even though both
require read and write
Separation of Administrative Functions
 Separation of user-role assignment from rolepermission 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
48
INSTITUTE FOR CYBER SECURITY
ASCAA Principles for Future Access Control

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
49
Usage Control Scope
INSTITUTE FOR CYBER SECURITY
Privacy
Protection
Security
Objectives
Intellectual
Property Rights
Protection
Sensitive
Information
Protection
DRM
Traditional
Trust
Access
Management
Control
Server-side
Reference Monitor
(SRM)
Usage Control
Client-side
Reference Monitor SRM & CRM
(CRM)
Security Architectures
© Ravi Sandhu
50
Usage Control Model (UCON)
INSTITUTE FOR CYBER SECURITY
unified model integrating
•
authorization
•
obligation
•
conditions
• and incorporating
•
continuity of decisions
•
mutability of attributes
•
Continuity of
Decisions
pre-decision
ongoing-decision
before-usage
ongoing-Usage
pre-update
ongoing-update
Rights
(R)
Subjects
(S)
Objects
(O)
Usage
Decisions
Subject Attributes (SA)
after-usage
Object Attributes (OA)
Authoriz
ations
(A)
Obliga
tions
(B)
Condi
tions
(C)
post-update
Mutability of
Attributes
© Ravi Sandhu
51
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
THE FUTURE
© Ravi Sandhu
53
INSTITUTE FOR CYBER SECURITY

Our Basic Premise


Application-Centric Security Models
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

© Ravi Sandhu
policy concerns in a idealized environment (policy layer)
54
INSTITUTE FOR CYBER SECURITY
PEI Models: 3 Layers/5 Layers
Idealized
Enforceable
(Approximate)
Codeable
This lecture is focused on the policy models layer
© Ravi Sandhu
55
Dissemination-Centric Sharing
INSTITUTE FOR CYBER SECURITY

Extensive research in the last two decades



ORCON, DRM, ERM, XrML, ODRL, etc.
Copy/usage control has received major attention
Manageability problem largely unaddressed
Attribute +
Policy Cloud
Object
Alice
Attribute
Cloud
Object
Bob
Attribute
Cloud
Attribute
+ Policy
Cloud
Attribute +
Policy
Cloud
Attribute
+ Policy
Cloud
Object
Charlie
Attribute
Cloud
Object
Eve
Attribute
Cloud
Susie
Attribute
Cloud
Dissemination Chain with Sticky Policies on Objects
© Ravi Sandhu
56
INSTITUTE FOR CYBER SECURITY

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)
join
Group characteristics


leave

Group
Authz (u,o,r)?
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



Users
Operational aspects


Group-Centric Sharing (g-SIS)
E.g. Who authorizes join, add, etc.?
May be application dependant
Multiple groups

Inter-group relationship
© Ravi Sandhu
remove
add
Objects
57
INSTITUTE FOR CYBER SECURITY
join
g-SIS Operation Semantics
Users
leave
GROUP
Authz (u,o,r)?
add
© Ravi Sandhu
Objects
remove
58
INSTITUTE FOR CYBER SECURITY
Liberal
Join
Strict
Join
g-SIS Operation Semantics
Users
Strict
Leave
Liberal
Leave
GROUP
Authz (u,o,r)?
Strict
Add
Liberal
Add
© Ravi Sandhu
Objects
Strict
Remove
Liberal
Remove
59
INSTITUTE FOR CYBER SECURITY
Family of g-SIS Policy Models
Traditional Groups: <LJ, SL, LA, SR>
Secure Multicast: <SJ, LL, LA, *>
Most Restrictive
g-SIS Specification:
© Ravi Sandhu
60
g-SIS Enforcement Model
INSTITUTE FOR CYBER SECURITY
3.2 Set
Leave-TS (s)
4.2 Add o to
ORL
CC: Control Center
GA: Group Administrator
CC
1. Read
Objects
TRM
TRM
…
TRM
GA
Group Subjects
Subject Attributes: {id, Join-TS, LeaveTS, ORL, gKey}
ORL: Object Revocation List
gKey: Group Key
Object Attributes: {id, AddTS}
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
CONCLUSION
© Ravi Sandhu
63
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 steroids
THE FUTURE
 Application-Centric Access Control Models
 Technology-Centric Access Control Models
Models are all important
A Policy Language is not a substitute for a good model
© Ravi Sandhu
64