Cyber-Identity, Authority and Trust in an Uncertain World

Prof. Ravi SandhuLaboratory for Information Security

TechnologyGeorge Mason University

www.list.gmu.edusandhu@gmu.edu

2

Outline Perspective on security Role Based Access Control (RBAC) Objective Model-Architecture

Mechanism (OM-AM) Framework Usage Control (UCON) Discussion

PERSPECTIVE

4

Security Conundrum Nobody knows WHAT security is Some of us do know HOW to

implement pieces of it

Result: hammers in search of nails

5

Security Confusion

INTEGRITYmodification

AVAILABILITYaccess

CONFIDENTIALITYdisclosure

USAGEpurpose

• electronic commerce, electronic business• DRM, client-side controls

6

Security Successes On-line banking On-line trading Automatic teller machines (ATMs) GSM phones Set-top boxes

Success is largely unrecognizedby the security community

7

Good enough security Exceeding good enough is not

good You will pay a price in user

convenience, ease of operation, cost, performance, availability, …

There is no such thing as free security Determining good enough is hard

Necessarily a moving target

8

Good enough security

EASY SECURE

COST

Security geeksReal-world users

System owner

• whose security• perception or reality of security

• end users• operations staff• help desk

• system solution• operational cost• opportunity cost• cost of fraud

9

Good enough security In many cases good enough is

achievable at a pretty low threshold The “entrepreneurial” mindset

In extreme cases good enough will require a painfully high threshold The “academic” mindset

ROLE-BASED ACCESS CONTROL (RBAC)

11

MAC and DAC For 25 years access control has

been divided into Mandatory Access Control (MAC) Discretionary Access Control (DAC)

In the past 10 years RBAC has become a dominant force RBAC subsumes MAC and DAC

12

Mandatory Access Control (MAC)

TS

S

C

U

InformationFlow

Dominance

Lattice ofsecuritylabels

13

Mandatory Access Control (MAC)

InformationFlow

DominanceLattice ofsecuritylabels

S,{A,B}

S,{A] S,{B}

S,{}

14

Discretionary Access Control (DAC) The owner of a resource

determines access to that resource The owner is often the creator of the

resource Fails to distinguish read from copy

15

RBAC96 model(Currently foundation of an NIST/ANSI/ISO standard)

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS

16

RBAC SECURITY PRINCIPLES least privilege separation of duties separation of administration and

access abstract operations

17

HIERARCHICAL ROLES

Health-Care Provider

Physician

Primary-CarePhysician

SpecialistPhysician

18

Fundamental Theorem of RBAC RBAC can be configured to do MAC RBAC can be configured to do DAC

RBAC is policy neutral

OM-AM(Objective/Model-Architecture/Mechanism)Framework

20

THE OM-AM WAY

ObjectivesModelArchitectureMechanism

What?

How?

Assurance

21

LAYERS AND LAYERS Multics rings Layered abstractions Waterfall model Network protocol stacks Napolean layers RoFi layers OM-AM etcetera

22

OM-AM AND MANDATORY ACCESS CONTROL (MAC)

What?

How?

No information leakageLattices (Bell-LaPadula)

Security kernelSecurity labels

Assurance

23

OM-AM AND DISCRETIONARY ACCESS CONTROL (DAC)

What?

How?

Owner-based discretionnumerousnumerous

ACLs, Capabilities, etc

Assurance

24

OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC)

What?

How?

Objective neutralRBAC96, ARBAC97, etc.

user-pull, server-pull, etc.certificates, tickets, PACs, etc.

Assurance

25

RBAC96 Model

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS

26

Server-Pull Architecture

Client Server

User-roleAuthorizationServer

27

User-Pull Architecture

Client Server

User-roleAuthorizationServer

28

Proxy-Based Architecture

Client ServerProxyServer

User-roleAuthorizationServer

USAGE CONTROL (UCON)

30

The UCON Vision:A unified model

Traditional access control models are not adequate for today’s distributed, network-connected digital environment. Authorization only – No obligation or condition

based control Decision is made before access – No ongoing

control No consumable rights - No mutable attributes Rights are pre-defined and granted to subjects

31

OM-AM layered Approach

ABC core models for UCON

What ?

How ?

Assurance

Objective

Mechanism

Architecture

Model

Policy Neutral

ABC model

CRM/SRM, CDID architectures

DRM technologies, certificates, etc.

OM-AM Framework Usage Control System

32

Prior Work Problem-specific enhancement to

traditional access control Digital Rights Management (DRM)

mainly focus on intellectual property rights protection. Architecture and Mechanism level studies, Functional

specification languages – Lack of access control model Trust Management

Authorization for strangers’ access based on credentials

33

Prior Work Incrementally enhanced models

Provisional authorization [Kudo & Hada, 2000]

EACL [Ryutov & Neuman, 2001] Task-based Access Control [Thomas &

Sandhu, 1997] Ponder [Damianou et al., 2001]

34

Usage Control (UCON) Coverage

Protection Objectives

Sensitive information protection

IPR protection Privacy protection

Protection Architectures

Server-side reference monitor

Client-side reference monitor

SRM & CRMServer-sideReference Monitor

(SRM)

Client-sideReference Monitor

(CRM)

TraditionalAccessControl

TrustManagement

Usage ControlSensitive

InformationProtection

IntellectualProperty Rights

Protection

PrivacyProtection

DRM

SRM & CRM

35

Building ABC Models

Rights(R)

UsageDecision

Authoriza-tions (A)

Subjects(S)

Objects(O)

Subject Attributes(ATT(S))

Object Attributes(ATT(O))

Obligations(B)

Conditions(C)

Continuity Decision can be made during usage for continuous enforcement

MutabilityAttributes can be updated as side-effects of subjects’ actions

Usage

Continuity ofDecisions

pre

Before After

ongoing N/A

pre ongoing postMutability of

Attributes

36

Examples Long-distance phone (pre-authorization

with post-update) Pre-paid phone card (ongoing-

authorization with ongoing-update) Pay-per-view (pre-authorization with pre-

updates) Click Ad within every 30 minutes

(ongoing-obligation with ongoing-updates) Business Hour (pre-/ongoing-condition)

37

Beyond the ABC Core Models

Objects(O)

ConsumerSubjects

(CS)

ProviderSubjects

(PS) SerialUsage Controls

Usage Control

IdentifieeSubjects

(IS)

ParallelUsage Controls

38

UCON Architectures We narrow down our

focus so we can discuss in detail how UCON can be realized in architecture level

Sensitive information protection X CRM

First systematic study for generalized security architectures for digital information dissemination

Architectures can be extended to include payment function

Server-sideReference Monitor

(SRM)

Client-sideReference Monitor

(CRM)

SensitiveInformationProtection

IntellectualProperty Rights

Protection

PrivacyProtection

SRM & CRM

UCONArchitectures

DRM

TrustManagement

TraditionalAccessControl

39

Three Factors of Security Architectures

Virtual Machine (VM) runs on top of vulnerable computing

environment and has control functions Control Set (CS)

A list of access rights and usage rules Fixed, embedded, and external control set

Distribution Style Message Push (MP), External Repository (ER)

style

40

Architecture TaxonomyVM: Virtual MachineCS: Control SetMP: Message PushER: External Repository NC1: No control architecture w/ MP NC2: No control architecture w/ ERFC1: Fixed control architecture w/ MP FC2: Fixed control architecture w/ ER EC1: Embedded control architecture w/

MPEC2: Embedded control architecture w/

ERXC1: External control architecture w/ MP XC2: External control architecture w/ ER

w/o VM w/ VM

MP ER

MPMPMP ERERER

Fixed CS Embedded CS External CS

NC1 NC2

FC1 FC2 EC1 EC2 XC1 XC2

41

Conclusion Perspective on security Role Based Access Control (RBAC) Objective Model-Architecture

Mechanism (OM-AM) Framework Usage Control (UCON) Discussion

42

Radical Shifts: get realFocus on what needs to be done rather than how it is to be

done real-word business requirements rather than hypothetical

academic scenarios the 80% problem rather than the 120% problem

soft and informal rather than hard and formal constructing the policy rather than auditing the policy constructive safety via policy articulation and evolution rather

than post-facto algorithmic safety ordinary consumers as end-users and administrators

rather than techno-geeks or math-geeks