26
INSTITUTE FOR CYBER SECURITY 1 The PEI Framework for Application-Centric Security Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security University of Texas at San Antonio May 2009 [email protected] www.profsandhu.com © Ravi Sandhu EI = Policy, Enforcement, Implementation

INSTITUTE FOR CYBER SECURITY 1 The PEI Framework for Application-Centric Security Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for

Embed Size (px)

Citation preview

INSTITUTE FOR CYBER SECURITY

1

The PEI Framework forApplication-Centric Security

Prof. Ravi SandhuExecutive Director and Endowed Chair

Institute for Cyber SecurityUniversity of Texas at San Antonio

May 2009

[email protected] www.profsandhu.com

© Ravi Sandhu

PEI = Policy, Enforcement, Implementation

INSTITUTE FOR CYBER SECURITY Application Context

Our Basic PremiseThere can be no security without application context

Orange Book and Rainbow Series era (1983-1994)Opposite PremiseApplication context makes high assurance security impossible to achieve

May need to settle for “reasonable” assurance or “good-enough” security

Its about “mission assurance” not “information assurance”

© Ravi Sandhu 2

INSTITUTE FOR CYBER SECURITY Rainbow Series

34 titles listed in Wikipedia as the “most significant Rainbow series books”

Only 1 addresses applications Trusted Database Interpretation (TDI) Scope: “Trusted Applications in general and database

management system in particular”

© Ravi Sandhu 3

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 4

Much work and $$$ by researchers and vendors, late 80’s-early 90’s

INSTITUTE FOR CYBER SECURITY Orange/Rainbow Fatal Flaws

Enforcement of 1-way information flow in a lattice is not the dominant concern for most applications

Avoiding covert channels is not the highest priority for most applications

Exclusion of cryptography is not a smart decision for securing distributed systems

© Ravi Sandhu 5

The Common Criteria, an ISO standard, and successor to the Orange Book has its own problems

INSTITUTE FOR CYBER SECURITY Post-Orange Era

Firewalls, patch cycle, vulnerability scanners, intrusion detection, intrusion prevention, Identity Management, Federation, SSL, VPNs, PKI, etc

Emergence and dominance of RBAC over MAC and DAC

Emergence of highly motivated, sophisticated and innovative attackers

© Ravi Sandhu 6

INSTITUTE FOR CYBER SECURITY Emerging Application-Centric Era (ACE)

© Ravi Sandhu 7

ECEEnterprise-Centric Era(Orange/Rainbow Era

Post-Orange 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 ACE Characteristics

Multi-party interests Fuzzy security objectives Attack/threat models

© Ravi Sandhu 8

INSTITUTE FOR CYBER SECURITY PEI Models: 3 Layers/5 Layers

© Ravi Sandhu 9

INSTITUTE FOR CYBER SECURITY Secure Information Sharing (SIS)

• A fundamental problem in cyber security– Share but protect

• Current approaches not satisfactory• Classic models (DAC/MAC/RBAC) do not work• Recent approaches

• Proprietary systems for Enterprise Rights Management

• Many solutions: IBM, CA, Oracle, Sun, Authentica, etc.• Interoperability is a major issue

• Many languages have been standardized• XrML, ODRL, XACML, etc.

• Primarily, dissemination or object centric

© Ravi Sandhu 10

INSTITUTE FOR CYBER SECURITY Dissemination Centric Sharing

Attach attributes and policies to objects Objects are associated with sticky policies XrML, ODRL, XACML, etc. provide sticky policies

Alice Bob Charlie Ravi Shashi

Attribute + Policy CloudObject

Attribute +

Policy CloudObject

Attribute + Policy Cloud

Object

Attribute +

Policy Cloud

Object

Dissemination Chain with Sticky Policies on Objects

Attribute Cloud

Attribute Cloud

Attribute Cloud

Attribute Cloud

Attribute Cloud

© Ravi Sandhu 11

INSTITUTE FOR CYBER SECURITY Group Centric Sharing (g-SIS) Advocates bringing users & objects together in a

group In practice, co-exists with dissemination centric sharing

NeverGroupSubjec

t Leave

Current

GroupSubjec

t

PastGroupSubjec

t

Join

Join

NeverGroupObject Remove

Current

GroupObject

PastGroupObject

Add

Add

• Two useful metaphors– Secure Meeting/Document Room

• Users’ access may depend on their participation period• E.g. Program committee meeting, Collaborative Product

Development, Merger and Acquisition, etc.– Subscription Model

• Access to content may depend on when the subscription began• E.g. Magazine Subscription, Secure Multicast, etc.

© Ravi Sandhu 12

INSTITUTE FOR CYBER SECURITY Core g-SIS Properties

Join Add

Leave Authz

Add Join

Remove Authz

1. Provenance: Authorization can only originate during a simultaneous period of membership

2. Bounded Authorization: Authorization cannot grow during non-membership periods

3. Persistence: Authorization cannot change if no group event occurs

INSTITUTE FOR CYBER SECURITY g-SIS Operation Semantics

14

GROUP

Authz (S,O,R)?

Join Leave

Add Remove

Subjects

Objects

GROUP

Authz (S,O,R)?

Strict Join

Strict Leave

Liberal Add

Liberal Remove

LiberalJoin

LiberalLeave

StrictAdd Strict

Remove

Subjects

Objects

© Ravi Sandhu 14

INSTITUTE FOR CYBER SECURITY Operation Semantics (Continued)

Strict Join (SJ): Only access objects added after Join time Liberal Join (LJ): Also access objects added before Join

time Strict Leave (SL): Lose access to all objects Liberal Leave (LL): Retain authorizations held at Leave

time

© Ravi Sandhu 15

INSTITUTE FOR CYBER SECURITY Operation Semantics (Continued)

16

Strict Add (SA): Only accessible by existing subjects

Liberal Add (LA): No such restrictions Strict Remove (SR): All subjects lose access Liberal Remove (LR): Subjects who had

authorization at Remove time can retain access

INSTITUTE FOR CYBER SECURITY Family of g-SIS Models

17

Most Restrictiveg-SIS Specification:

Traditional Groups: <LJ, SL, LA, SR>Secure Multicast: <SJ, LL, LA, *>

INSTITUTE FOR CYBER SECURITY PEI Models: 3 Layers/5 Layers

© Ravi Sandhu 18

INSTITUTE FOR CYBER SECURITY Concept of Stale-Safety

AIP AIP AIPAIP

ADP ADP ADP

AEP

AIP: Authorization Information Point

Update

ADP: Authorization Decision Point

AEP:Authorization Enforcement Point

© Ravi Sandhu 19

INSTITUTE FOR CYBER SECURITY g-SIS Enforcement Architecture/Models

Allows offline access Assumes a Trusted Reference Monitor (TRM)

Resides on group subject’s access machine Enforces group policy Synchronizes attributes periodically with server

Objects available via Super-Distribution Encrypt once, read wherever authorized

© Ravi Sandhu 20

INSTITUTE FOR CYBER SECURITY g-SIS

Never Group

Subject

Current Group

Subject

Past Group

SubjectJoin

Add

Join

Never Group Object

Current Group Object

Past Group ObjectAdd Remove

Leave

Time of JoinNULL

Join-TSLeave-TS

Time of JoinTime of LeaveTime of Add

NULL

Add-TSRemove-TS

Time of AddTime of Remove

Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & Remove-TS(o) = NULL

Subject AttributesObjectAttributes

© Ravi Sandhu 21

INSTITUTE FOR CYBER SECURITY g-SIS Architecture

CC

GA

Group Subjects

TRM

TRMTRM

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 22

INSTITUTE FOR CYBER SECURITY Staleness in g-SIS

RT0RT1 RT2 RT3

Join (s) Add (o1) Add (o2)

Leave (s) Request (s, o1, r)

Request (s, o2, r)

Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & o NotIn ORL

Was authorized at recent RT

Was never authorizedRT: Refresh Time

RT4

© Ravi Sandhu 23

INSTITUTE FOR CYBER SECURITY Stale-Safe Security Properties

Weak Stale-Safety Allows (safe) authorization decision to made without

contacting the CC Achieved by requiring that authorization was TRUE at

the most recent refresh time Strong Stale-Safety

Need to obtain up to date authorization information from CC after a request is received

If CC is not available decision cannot be made

24

INSTITUTE FOR CYBER SECURITY Properties

RT Perform

Stale-unsafe Decision

Request Perform Request Perform

Weak Stale-Safety:

Strong Stale-Safety: 25

Formula Formula

Join Add Authz

INSTITUTE FOR CYBER SECURITY Conclusion

Security tools for a brave new world ACE PEI UCON

© Ravi Sandhu 26