INSTITUTE FOR CYBER SECURITY 1 Security Models: Past, Present and Future Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security

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


2

THE BIG PICTURE

© Ravi Sandhu

INSTITUTE FOR CYBER SECURITY Security Objectives

3

INTEGRITYmodification

AVAILABILITYaccess

CONFIDENTIALITYdisclosure

© Ravi Sandhu


4


AVAILABILITYaccess


USAGEpurpose

© Ravi Sandhu


5


AVAILABILITYaccess


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


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


{ARMY, CRYPTO}Compartmentsand Categories

{ARMY } {CRYPTO}

{}

© Ravi Sandhu 25


HierarchicalClasses with

CompartmentsTS

S

{A,B}

{}

{A} {B}

product of 2 lattices is a latticeproduct of 2 lattices is a lattice

© Ravi Sandhu 26


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


ROLES

USER-ROLEASSIGNMENT


USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

© Ravi Sandhu 40


ROLES

USER-ROLEASSIGNMENT


USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS

© Ravi Sandhu 41


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


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


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


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


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


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


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


Object


Object


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


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

Documents

INSTITUTE FOR CYBER SECURITY 1 Security Models: Past, Present and Future Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security