1 Group-Centric Models for Secure and Agile Information Sharing Ravi Sandhu Executive Director and Endowed Professor April 2010 [email protected], ,

1

Group-Centric Models for Secure and Agile Information Sharing

Ravi SandhuExecutive Director and Endowed Professor

April 2010

[email protected], www.profsandhu.com, www.ics.utsa.edu

Joint work with ICS colleaguesRam Krishnan, Jianwei Niu and Will Winsborough

© Ravi Sandhu World-Leading Research with Real-World Impact!

Institute for Cyber Security

2

Application Context

Basic premise There is no security without application context

Opposite premise Orange Book and Rainbow Series Era (1983-1994)

Application context makes high-assurance impossibleo Good-enough security is good enougho Mission-assurance not information-assurance

Towards the end of this era applications had to be addressed: Trusted Database Interpretation (TDI)

Firewall Era (1992-2008) Perimeter security, vulnerability scanning, penetrate and

patch, intrusion prevention, secure coding, etc


3

Application Context

What precisely is Secret? There exists a SecureWin7 project Alice works on SecureWin7 Alice’s effort on SecureWin7 is 75% All or some of the above

How do we maintain integrity of the database Depends

• Data and security model are intertwined• Much work and $$$ by researchers and vendors, late 80’s-early 90’s

Software Architect Project % Time Label

Alice Win7 25% U

Alice SecureWin7 75% S

Bob Vista 100% U


4

Application Centric Security

Modern applications Multi-party Different objectives and responsibilities, often in conflict

Ongoing projects at ICS Secure information sharing Social networking Critical infrastructure assurance SaaS in the Cloud/Intercloud Smart grid

New ACM Conference on Data and Application Security and Privacy (CODASPY)

Feb 21-23, 2011, San Antonio, Texas www.codaspy.org, www.sigsac.org Papers due: Sept 15th 2010


The future is application centricThe future is data and application centric

5

PEI Models

Security and system goals(objectives/policy)

Policy models

Enforcement models

Implementation models

Necessarily informal

Specified using users, subjects, objects, admins, labels, roles, groups, etc. in an ideal setting.Security analysis (objectives, properties, etc.).Approximated policy realized using system architecture with trusted servers, protocols, etc.Enforcement level security analysis (e.g. stale information due to network latency, protocol proofs, etc.).Technologies such as Cloud Computing, Trusted Computing, etc.Implementation level security analysis (e.g. vulnerability analysis, penetration testing, etc.)Software and HardwareConcrete System


6

Secure Information Sharing (SIS)

Goal: Share but protect Containment challenge

Client containment High assurance infeasible (e.g., cannot close the analog hole) Low to medium assurance achievable

Server containment Will typically have higher assurance than client containment

Policy challenge How to construct meaningful, usable SIS policy How to develop an intertwined information and security model


7

SIS Policy Construction

Dissemination Centric (d-SIS) Sticky policies that follow an object along a

dissemination chain (possibly modified at each step) Group Centric (g-SIS)

Bring users and information together to share existing information and create new information

Metaphors: Secure meeting room, Subscription service Benefits: analogous to RBAC over DAC

Why not use existing access control (AC) models? Discretionary (DAC): fails containment Lattice-based (LBAC or MAC): no agility Role-based (RBAC): too general Attribute-based (ABAC): too general


8

g-SIS Model Components

Operational aspects Group operation semantics

o Add, Join, Leave, Remove, etco Multicast group is one example

Object modelo Read-onlyo Read-Write (no versioning vs versioning)

User-subject modelo Read-only Vs read-write

Policy specification Administrative aspects

Authorization to create group, user join/leave, object add/remove, etc.


Users

Objects

GroupAuthz (u,o,r)?

join leave

add remove

9

g-SIS Models

Isolated groups model No subject level info flow between groups Groups are information sinks

Connected groups model Connected groups with some type of relationship

o E.g. Subordination (read, write, create subject, move subject), conditional membership, mutual exclusion, etc.

Subject level info flow governed by relationship semantics

Isolated

ConnectedIsolated +ABAC

Connected + ABAC

g-SISModels

Anticipate to be straight-forward

Work in Progress


10

Isolated Group Model (g-SISi)

Abstract model specification = Stateless (vis-à-vis Stateful) Specify without worrying about state structure

o No data structure to maintain user/object attributes Use many sorted, first-order linear temporal logic (FOTL)

o FOTL = LTL with parameters, constants, variables and quantifiers Entities in the isolated group model

Users, subjects, object versions, groups and permissions Operations in the isolated group model

User membership operationso Join(u,g), Leave(u,g)

Object membership operationso Add(o,v,g), Remove(o,v,g)o CreateO(o,v,g)

Subject operationso createS(u,s,g), killS(u,s,g), read(s,o,v,g), update(s,o,v1,v2,g)

Authorization to exercise a permission p on an object version Authz(u,o,v,g,p) AuthzS(s,o,v,g,p)


CreateO(o,vinit,g)

update(s,o,vinit,v1,g)

update(s,o,vinit,v2,g)

update(s,o,v1,v4,g)

update(s,o,v1,v3,g)

11

g-SISi Operation Semantics

GROUPAuthz (u,o,r)?

Strict Join

Strict Leave

Liberal Add

Liberal Remove

LiberalJoin

LiberalLeave

StrictAdd Strict

Remove

Users

Objects

StrictCreate

LiberalCreateupdate

Read-only Model

Read-Write Model

GROUPAuthz (u,o,r)?

Join Leave

Add Remove

Users

Objects

Create update


12

Core Properties

Authorization Persistence Authorization cannot change unless some group event occurs


13

Core Properties (contd)

Authorization Provenance Authorization can begin to hold only after a simultaneous period of user

and object version membership

Bounded Authorization Authorization cannot grow during non-membership period


14

Core Properties (contd)

Version Authorization Uniformity A current user should be authorized to read and write either all versions

of locally created objects or none of them


15

g-SISi Specification

A g-SIS specification specifies the precise conditions under which Authz(u,o,v,g,p) and AuthzS (s,o,v,g,p) may hold

A g-SIS specification must satisfy all of the core properties That is:


16

Membership Semantics

Strict Vs Liberal operations User operations: <SJ, LJ>, <SL, LL> Object operations: <SA, LA>, <SC, LC> and <SR, LR>

u not authorized to access objects added prior to join time

Users joining after add time not authorized to access o

u retains access to objects authorized at leave time

Users authorized to access o at remove time retain access


17

Membership Renewal Semantics

Lossless Vs Lossy Join Lossless: Authorization from past membership not lost Lossy: Some authorization lost at re-join time

Restorative Vs Non-Restorative Join Restorative: Authorizations from past membership restored Non-Restorative: Past authorizations not restored on re-join

Gainless Vs Gainful Leave Restorative Vs Non-Restorative Leave


18

The π-system Specification

Allows any variation of membership semantics Strict and Liberal versions of user and object operations

Allows selected membership renewal semantics Lossless and Non-Restorative Join Gainless and Non-Restorative Leave


19

The π-system Specification (contd)


20

The π-system Specification (contd)


21

Formal Analysis

The core properties are mutually independent

The core properties are consistent

The π-system satisfies the core properties

Used a model checker to prove these results for a small carrier case Extended this result using manual proof for large carrier case


22

Connected Groups Model (g-SISc)

Groups connected by some type of relationship Conditional membership (users/objects) Subordination

o Read, write, subject create, subject move Mutual exclusion Cardinality

Relationships are reflexive by definition Transitivity and anti-symmetry must be explicitly defined if needed

Relationships vary over time in SIS scenario

G2 G3G1

G5 G6

G4

condM condM

subordRsubordCsubordM

condM subordW


23

Configuring Classic Policies

LBAC in g-SISc

A sample lattice Equivalent g-SISc Configuration


Not an equivalent g-SISc configuration (trusted pipeline from G_ L to G_H via G_M1 or G_M2)

24

Configuring Classic Policies (contd)

Domain and Type Enforcement (DTE) in g-SIS

DTE for trusted pipeline from L to H via M1 or M2

Equivalent g-SISc Configuration

Objects

Subjects


LBAC in DTE

A sample lattice

subordW

25

LBAC Inadequate for Agile Sharing

What if H users from Org A and S users from Org B want to collaborate on a mission?

What if Org B does not want H users to create subjects in S and write to S objects?

o E.g. Org B wants to share intel with Org A but do not want them to modify their data

o Categories work only if pre-determined

Org A Org B

subordR

Org A Org BLBAC g-SISC


subordR

26

LBAC Inadequate (contd)

subordCsubordR

subordW subordCsubordR

subordWsubordCsubordR

subordW

TS

S

G1

G2

H

L

condM

condM

condM

condM

Export

Export

subordR

subordRsubordR

subordR

Export allowedonly byTrusted Subjects

SJ/LJ, SL/LL

SA/LA, SR/LR

SJ/LJ, SL/LL

SA/LA, SR/LR

Export allowedonly byTrusted Subjects

SJ/LJ, SL/LL

SA/LA, SR/LR

SJ/LJ, SL/LL

SA/LA, SR/LR

SC/LC

SC/LC

Publish group for TS objects

Publish group for S objects


Can use all isolated group operation semantics

27

Conclusion

No security without application context Group-Centric Secure Information Sharing is a

promising approach Still in early days

We project the need for Application Centric security models in many emerging arenas Goal: have a methodology and conceptual framework

for this purpose PEI, Stateless-Statefull specifications, Stale-safe

enforcement, etc


Documents

1 Group-Centric Models for Secure and Agile Information Sharing Ravi Sandhu Executive Director and Endowed Professor April 2010 [email protected], ,