INSTITUTE FOR CYBER SECURITY A Perspective on Usage Control and its Future Prof.

Download Report

Transcript INSTITUTE FOR CYBER SECURITY A Perspective on Usage Control and its Future Prof.

INSTITUTE FOR CYBER SECURITY
A Perspective on Usage Control
and its Future
Prof. Ravi Sandhu
Executive Director and Endowed Chair
Institute for Cyber Security
University of Texas at San Antonio
January 2009
[email protected]
www.profsandhu.com
© Ravi Sandhu
1
INSTITUTE FOR CYBER SECURITY






Outline
Security trends and change drivers
Foundational security assumptions
Usage: a fundamental security objective
The Usage Control or UCON model
The PEI (Policy, Enforcement, Implementation)
framework
The ASCAA principles (Abstraction, Separation,
Containment, Automation, Accountability)
© Ravi Sandhu
2
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
3
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
4
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
5
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
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
6
Security Objectives
INSTITUTE FOR CYBER SECURITY
USAGE
purpose
INTEGRITY
modification
USAGE
AVAILABILITY
access
CONFIDENTIALITY
disclosure
© Ravi Sandhu
7
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
8
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)


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
9
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
10
INSTITUTE FOR CYBER SECURITY
© Ravi Sandhu
PEI Models: 3 Layers/5 Layers
11
Policy Model
INSTITUTE FOR CYBER SECURITY
1.
1.
1. 2.
2.
3.
4.
3.
3.
5.
4.
4.
Pastrejoin
No
member
past
losesmembers
access
toisall
allowed,
documents
rejoin
(or)
with new ID (or)
Access
toofcurrent
documents
only
(or)
Straight-forward.
User
hasjust
can access
Past
members
rejoin
document
the
group
created
during
like any
his other
membership
user who
(or)
Access
toany
current
documents
and
past
has
can
never
accessbeen
documents
a member
he accessed during membership (or)
no
access
to
any
group
documents
The
can access
same access
all documents
policies defined
created during
before he
hisleft
prior
themembership
group (this
documents.
Accessagain
canones
beenforced
further(or)
restricted
includes
should
the
be
created
before
his joinwith
time)rate
and/or
usage
limits
all subject
access
policies
to possible
could
vary
additional
between
rate,
membership
usage andcycles
user credential
restrictions
Access can be further restricted on basis of
individual user credentials
Initial state:
Never been a
member
Currently a
member
enroll
Past member
State III
State II
State I
enroll
© Ravi Sandhu
disenroll
12
Enforcement Model
INSTITUTE FOR CYBER SECURITY
Control Center
(CC)
4
2
7
3
5
1
Two sets of attributes
• Authoritative: as known to the CC
• Local: as known on a member’s computer
Member enroll and dis-enroll (steps 1-2, 5)
• Document add and remove (step 6, 7)
• Read policy enforcement (step 3)
• Attribute update (step 4)
•
Joining Member
Group-Admin
6
Member
D-Member
Ideal Model: steps 3 and 4 are coupled
Approximate Model: steps 3 and 4 are de-coupled
© Ravi Sandhu
13
Implementation Model
INSTITUTE FOR CYBER SECURITY
•
Use TC mechanisms to bind group key
+ attributes to TRM
Indirect
communication
Boot time
measurement
Isolated
execution
VM0
TRM
TSS
TV
VM1
Linux Kernel + TPM Driver + MAC Policies
VMM
TPM
© Ravi Sandhu
App
PCRs
Internal
PCRs
Update Internal
PCR
14
INSTITUTE FOR CYBER SECURITY

Abstraction of Privileges


Separation of user-role assignment from role-permission
assignment
Least Privilege



Credit is different from Debit even though both require read
and write
Separation of Administrative Functions


Founding Principles of RBAC (1996)
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
15
INSTITUTE FOR CYBER SECURITY

Abstraction of Privileges




Least Privilege
Separation of Duties
Usage Limits
Automation




Separation of Administrative Functions
Containment


Credit vs debit
Personalized permissions


ASCAA Principles
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
16
INSTITUTE FOR CYBER SECURITY






Conclusion
Security trends and change drivers
Foundational security assumptions
Usage: a fundamental security objective
The Usage Control or UCON model
The PEI (Policy, Enforcement, Implementation)
framework
The ASCAA principles (Abstraction, Separation,
Containment, Automation, Accountability)
Questions?? Comments!!
© Ravi Sandhu
17