institute for cyber security 1 a perspective on usage control and its future prof. ravi sandhu...
Post on 26-Mar-2015
213 Views
Preview:
TRANSCRIPT
INSTITUTE FOR CYBER SECURITY
1
A Perspective on Usage Controland its Future
Prof. Ravi SandhuExecutive Director and Endowed Chair
Institute for Cyber SecurityUniversity of Texas at San Antonio
January 2009
ravi.sandhu@utsa.edu www.profsandhu.com
© Ravi Sandhu
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
© Ravi Sandhu 3
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 4
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 5
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
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 6
We are not very good at doing any of this
INSTITUTE FOR CYBER SECURITY Security Objectives
7
INTEGRITYmodification
AVAILABILITYaccess
CONFIDENTIALITYdisclosure
USAGEpurpose
USAGE
© Ravi Sandhu
INSTITUTE FOR CYBER SECURITY Usage Control Scope
© Ravi Sandhu 8
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 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 9
INSTITUTE FOR CYBER SECURITY Usage Control Model (UCON)
© Ravi Sandhu 10
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 PEI Models: 3 Layers/5 Layers
© Ravi Sandhu 11
INSTITUTE FOR CYBER SECURITY Policy Model
© Ravi Sandhu 12
Initial state:Never been a
member
State I
Currently a member
State II
Past member
State III
enroll dis-enroll
enroll
1. Straight-forward. User has no access to any group documents.
1. Access to current documents only (or)2. Access to current documents and past
documents3. Access can be further restricted with rate
and/or usage limits4. Access can be further restricted on basis of
individual user credentials
1. Past member loses access to all documents (or)2. can access any document created during his membership (or)3. can access documents he accessed during membership (or)4. can access all documents created before he left the group (this
includes the ones created before his join time)5. all subject to possible additional rate, usage and user credential
restrictions
1. No rejoin of past members is allowed, rejoin with new ID (or)2. Past members rejoin the group just like any other user who
has never been a member3. The same access policies defined during his prior membership
should again be enforced (or)4. access policies could vary between membership cycles
INSTITUTE FOR CYBER SECURITY Enforcement Model
© Ravi Sandhu 13
3
1
2 4 5
Group-Admin MemberJoining Member
Control Center (CC)
7
Ideal Model: steps 3 and 4 are coupledApproximate Model: steps 3 and 4 are de-coupled
D-Member
6
• 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)
Two sets of attributes• Authoritative: as known to the CC• Local: as known on a member’s computer
INSTITUTE FOR CYBER SECURITY Implementation Model
© Ravi Sandhu 14
TPM
VMM
Update Internal PCR
Linux Kernel + TPM Driver + MAC Policies
Internal PCRs
AppPCRs
TRM TVTSS
Indirect communication
Boot time measurement
Isolated executionVM0
VM1
• Use TC mechanisms to bind group key + attributes to TRM
INSTITUTE FOR CYBER SECURITY Founding Principles of RBAC (1996)
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 15
INSTITUTE FOR CYBER SECURITY ASCAA Principles
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 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)
© Ravi Sandhu 17
Questions?? Comments!!
top related