Distributed Security
CSE
5810
Prof. Steven A. Demurjian, Sr.
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-1155
Storrs, CT 06269-1155
steve@engr.uconn.edu
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
DistribSecurity-1
A Security Model/Enforcement Framework with
Assurance for a Distributed Environment
CSE5810
C. Phillips, S. Demurjian, and T.C. Ting
Computer Science & Engineering Department
The University of Connecticut
Storrs, Connecticut 06269-3155
Charles.Phillips@usma.edu
{steve,ting}@engr.uconn.edu
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
DSEC--2
Motivation

CSE5810



Premise: Artifacts - set of Database
COTS
 DB, Legacy, COTS,
GOTS, Each w/ API
Legacy
Legacy
Premise: Users
Client
 New and Existing
Java
Client
 Utilize Artifact APIs
GOTS
Distributed Application, DA
NETWORK
 Artifacts + Users
Can we Control User
GOTS
Access to Artifact APIs
Client
(Methods) by …
Legacy
 Role (who)
Database
 Classification (MAC)
 Time (when)
Database
COTS
Client
 Data (what)
Client
DSEC--3
Motivation
API Access Based on Role/Classification

Can we Control Access
Based on Role?
CSE5810

Can we Control Access to
Based on Classification?
(high T > S > C > U low)
Java
Client
User A
Role X
Authorize
C1, C2
C3, C5
L1, L2
C: COTS
API:
Methods
C1
C2
C3
C4
C5
Java
Client
User A
Role X
Authorize
Secret
(S)
C: COTS
API:
Methods
T: C1
S: C2
S: C3
T: C4
C: C5
Java
Client
User B
Role Y
Authorize
C1, C4
L2, L3
L: Legacy
API:
Methods
L1
L2
L3
Java
Client
User B
Role Y
Authorize
Confidential
(C)
L: Legacy
API:
Methods
T: L1
C: L2
U: L3
DSEC--4
Motivation
API Access Based on Time/Value

Can we Control Access
Based on Time?

Can we Control Access
Based on Data Values?
CSE5810
Java
Client
User A
Role X
Authorize
C1: TI a
C4: TI b
L1: TI c
C: COTS
API:
Methods
C1
C2
C3
C4
C5
Java
Client
User A
Role X
Authorize
X.C1 (a < 30)
X.C4 (d > 40)
X.L1 (f = 10)
C: COTS
API:
Methods
C1 (a)
C2 (b)
C3 (c)
C4 (d)
C5 (e)
Java
Client
User B
Role Y
Authorize
C2: TI d
L1: TI e
L: Legacy
API:
Methods
L1
L2
L3
Java
Client
User B
Role Y
Authorize
Y.C2 (0<b<99)
Y. L1 (f = 100)
L: Legacy
API:
Methods
L1 (f)
L2 (g)
L3 (h)
DSEC--5
Overview of Remainder of Talk

CSE5810









Problem Statement
Research Goals and Objectives
Relevance/Importance of Research
Distributed Environment Assumptions
Unified Security Model for RBAC/MAC
Security Enforcement Framework
Security Assurance
 Design Time and Run Time Checks
Role Delegation Extensions and Capabilities
Analysis vs. SSE-CMM and Evaluation vs. DCP
Concluding Remarks
DSEC--6
Problem Statement - Research Foci
CSE5810
Security
Administrative
and Management
Tools
Unified
RBAC/MAC
Security Model
Security Policy
Definition
Design Time
Security
Assurance
RBAC/MAC
Enforcement
Framework
Run Time
Security
Assurance
Analyses of RBAC/MAC
Model/Framework
Against SSE-CMM
Evaluation of
RBAC/MAC Model
Using DCP
DSEC--7
Research Goals and Objectives

CSE5810


Security Model that Unifies RBAC/MAC with
 Constraints Based on Method Signature (How),
Time (When), and Security Clearances and
Classifications
Security Policy and Enforcement Assurance
 Design Time (During Security Policy
Definition) Security Assurance
 Run Time (Executing Application) Security
Enforcement
RBAC/MAC Model for a Distributed Setting
 Leverage Middleware Capabilities
 Flexible, Portable, Platform Independent
 Security with Minimal/Controlled Impact
DSEC--8
Research Goals and Objectives

CSE5810

Method-Level Approach
 Constraints using: Role, MAC, Time, and Data
 Customized Access to APIs of Artifacts
 Contrast with Object Level Approach
Assessment: Security Model/Enforcement
 Analysis Versus CMU’s Security Engineering
Capability Maturity Model (SSE-CMM)
 Evaluation of Utility of Approach for
Supporting Dynamic Coalition Problem
 Prototype
 Administrative and Management Tools - Assurance
 Security Resources/Middleware - Enforcement
DSEC--9
Relevance/Importance of Research

CSE5810


Shrinking Military More Reliant on the Civilian
Sector for Operational Support and Internet Usage
 Legacy Software Systems
 COTS and GOTS
 Shared Databases
Flexible Security Policy Realization and
Enforcement in Support of Coalition Warfare
 Classified and Non-Classified Information
 Rapid Deployment and Easy to Use
 Platform Independence
Growing Need for Multi-level Security Solutions
 Currently Government Systems Avoid MAC
 Difficult to Realize and Manage
DSEC--10
Distributed Environment Assumptions

CSE5810




Assume Presence of Middleware (JINI, CORBA):
 Provides Bridge Between Software Artifacts
 Allows Software Artifacts to Register/Publish
their APIs for use by Clients/Other Resources
Lookup Service:
 Middleware that Provides Means for Software
Artifacts (Resource) and Clients to Interact
A Resource is a Software Artifact Accessible via
API (e.g., C++, Java, etc.) Consisting of Services
A Service is a Logical Grouping of Public
Methods that are Registered with Lookup Service
A Method has a Signature Consisting of a Possible
Null Return Type and Zero or More Parameters
DSEC--11
Global Command and Control System
(GCCS) Resource/Service/Methods
GCCS Resource with Two Services
CSE5810 Joint Service with Methods:
Weather (Token);
VideoTeleconference (Token, fromOrg, toOrg);
JointOperationsPlannning (Token, CrisisNum);JOPES
CrisisPicture (Token, CrisisNum, Grid1, Grid2);
TransportationFlow (Token);
LogisticsPlanningTool (Token, CrisisNum);
DefenseMessageSystem (Token);
NATOMessageSystem (Token);
Component Service with Methods:
ArmyBattleCommandSys (Token, CrisisNum);
AirForceBattleManagementSys (Token, CrisisNum);
MarineCombatOpnsSys (Token, CrisisNum);
NavyCommandSystem (Token, CrisisNum);
a.k.a
METOC
TLCF
COP
JFAST
LOGSAFE
DMS
CRONOS
ABCS
TBMCS
TCO
JMCIS
DSEC--12
Security Enforcement Framework
Software Architecture
Database
Client
CSE5810
COTS
Client
Wrapped
Resource
for Database
Application
Wrapped
Resource
for COTS
Application
Lookup
Service
Java
Client
General
Resource
Wrapped
Resource
for Legacy
Application
Software
Agent
Legacy
Client
Lookup
Service
Security Policy
Client (SPC)
Security Authorization
Client (SAC)
Security Delegation
Client (SDC)
Unified Security Resource (USR)
Security
Policy
Services
Security
Authorization
Services
Security
Registration
Services
Security
Analysis and
Tracking (SAT)
DSEC--13
Security Enforcement Framework

CSE5810

Unified Security Resource Services to:
 Manage URs and Privileges
 Authorize URs to Us
 Identify Users and Track Security Behavior
Associated Administrative/Management Tools
 Security Policy Client to Grant/Revoke
Privileges (TCs, methods, SCs)/set CLS/CLR
 Security Authorization Client to Assign CLRs
and Authorize URs to End Users
 Security Analysis Tool (SAT) to Track all
Client Activity (Logons/Method Invocations)
DSEC--14
Unified Security Model Definitions
Lifetimes Concept

CSE5810
Definition 1: A lifetime, LT, is a Discrete Time
Interval [LT.st, LT.et] with LT.et > LT.st
 LT.st (start time) or LT.et (end time) is a tuple
(day, month, year, hour, minute, second)
 where x  y means x.LT.st  y.LT.st and
x.LT.et  y.LT.et
 X  Y is equivalent to Y  X
 Let ST  max{ X .st , Y .st} and ET  min{ X .et , Y .et}
if ET  ST
Ø
X Y  
[ ST , ET ] if ET  ST

(1.1)
(1.2)
LT = [ct, ] means current time (ct) onward
DSEC--15
Concept of Containment of Lifetimes
CSE5810
DSEC--16
Usage of Lifetimes

CSE5810 

Lifetimes are Important Concepts since they
Delineate “When” an Action or Usage Can Occur
For Example:
 “When” is a User Role Authorized to invoke a
Method?
 “When” is a User Authorized to a User Role?
 “When” Does a Resource Allow its Services
Available in the Distributed Environment?
Overall - LTs Control the Time Constrained
Behavior for Security
DSEC--17
Examples of Lifetimes
CSE5810
DSEC--18
Related Work: Lifetimes

CSE5810




Leasing [Wald99]
Temporal Constraints [Bert96, Bert01, Ahn00]
DBMS Constraints [Bark01, Nota95]
User Constraints [Sand98, Zurk96]
Similarities and Differences:
 Extend Leasing Concept from Resources,
Services, and Methods to LTs of URs/ Users
 Temporal Constraints used on Objects and
Work Flow are applied to Resources, URs, and
Users Which Allows for Less Code
Modification and Dynamic Changes
 LTs in Conjunction with Method Time
Constraints Improve Granularity and Provide
Increased Flexibility for Security Policy
DSEC--19
Unified Security Model Definitions
MAC Concept

CSE5810

Definition 2: Relevant MAC Concepts are:
 A sensitivity level, SLEVEL, SLEVEL =
{U,C,S,T} unclassified (U) - no impact;
confidential (C) causes some damage; secret
(S), causes serious damage; top secret (T)
causes exceptionally grave damage
 SLEVELs form a hierarchy: U < C < S < T
 Clearance (CLR) is SLEVEL given to users
 Classification (CLS) is the SLEVEL given to
entities (roles, objects, methods, etc.)
Note:
 We Utilize 4 Levels of Sensitivity
 Approach Will Work for n Levels
DSEC--20
Unified Security Model Definitions
Distributed Application

CSE5810
Definition 3: A Distributed Application, DAPPL,
is Composed of a Set of Software/system
Resources (e.g., a Legacy, COTS, DB, Etc.), Each
Composed of a Set of Services, Which in Turn Are
Each Composed of a Set of Methods, Namely:
R  {Ri | i  1 m}
Si  {Sij | j  1 ni }
M ij  {M ijk | k  1 qij }

Ri .S ij .M ijk Uniquely Identifies Each Method
DSEC--21
Unified Security Model Definitions
Methods

CSE5810


Every Method of Service of Resource Ri .S ij .M ijk
Must be Registered from a Security Perspective
Registration of Signature and Security Information
 Lifetime of Method (When Available for Use)
 Classification of Method (Level of Use)
Definition 4: Every method is registered as:
M ijk  [M



Name
ijk
,M
LT
ijk
,M
CLS
ijk
,M
Params
ijk
]
Default CLS is U
Default LT = [ct, ]
Resource by Registering Sets CLS and LT
DSEC--22
Unified Security Model Definitions
Services

Definition 5: Every service is registered as:
Sij  [S
CSE5810
Name
ij
LT
ij
,S ,S
CLS
ij
]
where
S
LT .st
ij
S
LT .et
ij
 max{ M
CLS
ij
 min{ M
S

 min{ M
LT .st
ijk
LT .et
ijk
CLS
ijk
| k  1...qij }
| k  1...qij }
| k  1qij }
Note that LT and CLS are Inferred from LT and
CLS of Methods that Comprise Service
DSEC--23
Unified Security Model Definitions
Resource

Definition 6: Every resource is registered as:
Ri  [ RiName , RiLT , RiCLS ]
CSE5810
where
RiLT .st  min{ SijLT .st | j  1...ni }
LT .et
i
 max{ S
| j  1...ni }
CLS
i
 min{ S
| j  1ni }
R
R

LT .et
ij
CLS
ij
Note that LT and CLS are Inferred from LT and
CLS of Services that Comprise Resource
DSEC--24
Clearances/Classifications
Example
CSE5810
(C) GCCS Resource C= min {Service CLSs}
(S) Joint Service with Methods S = min{Method CLSs}
(S)Weather (Token);
(S)VideoTeleconference (Token, fromOrg, toOrg);
(S)JointOperationsPlannning (Token, CrisisNum);
(S)CrisisPicture (Token, CrisisNum, Grid1, Grid2);
(S)TransportationFlow (Token);
(S)LogisticsPlanningTool (Token, CrisisNum);
(S)DefenseMessageSystem (Token);
(T)NATOMessageSystem (Token);
a.k.a
METOC
TLCF
JOPES
COP
JFAST
LOGSAFE
DMS
CRONOS
(C) Component Service with Methods: C = min{Method CLSs}
(S)ArmyBattleCommandSys (Token, CrisisNum);
ABCS
(S)AirForceBattleManagementSys (Token, CrisisNum); TBMCS
(S)MarineCombatOpnsSys (Token, CrisisNum);
TCO
(C)NavyCommandSystem (Token, CrisisNum);
JMCIS
Note: Access Classification Precedes Each Entry.
DSEC--25
Related Work:
Clearances/Classifications

CSE5810





Lattice Based Access Control [Sand93]
MAC and RBAC [Nyan95, Osbo97, Osbo00]
DAC with Roles [Sand98]
Orange Book [DoD96]
MAC with Objects [Thur89]
Similarities and Differences
 Our Approach Opposite in that we Take
Minimum and Standard would Take Maximum
 Our Security Approach is at the Method Level
 Our Approach is Dynamic in That CLRs and
CLSs Can Be Changed During Runtime
 MAC Check at Invocation Eliminates Need for
Object Access or Change
DSEC--26
Unified Security Model Definitions
User Roles and UR List

CSE5810


Definition 7: A user role, UR, representing a set
of responsibilities for an application, is defined as:
UR  [UR Name ,UR LT ,URCLS ]
Notes
 LT and CLS is Set by Security Officer
 Defaults are [ct, ] and U Respectively
Examples: Commander /Joint Planner - Crisis 1
[CDR_CR1, URLT, T]
[JPlannerCR1, [01dec00, 01jun01], S]

Definition 8: A user-role list, , URL is the set of r
unique roles that have been defined for DAPPL.
DSEC--27
Unified Security Model Definitions
Users and User List

CSE5810
Definition 9: A user, U, who will be accessing the
DAPPL via a client application, is defined as:
U  [U



UserId
,U
LT
,U
CLR
]
Notes
 LT and CLS is Set by Security Officer
 Defaults are [ct, ] and U Respectively
Example Users:
General DoBest: [DoBest, 1 year, T]
Colonel DoGood: [DoGood, 6 mo., S]
Definition 10: A user list, UL is the set of u users
that have been defined for DAPPL.
DSEC--28
Examples: Users, User-Roles, and URA
Users:
U  [U UserId , U LT , U CLR ]
CSE5810 (T)General DoBest: [DoBest, [ct, ],
T]
(T)Colonel DoGood: [DoGood, [01dec00,01jun01], T]
(S)Major DoRight: [DoRight, [01dec00,01jan01], S]
(T)Major CanDoRight: [CanDoRight,[01jan01,01feb01, T]
UserUser-Roles:
UR  [UR Name , UR LT , URCLS ]
[CDR_CR1, [01dec00,  ], T]
[JPlannerCR1, [01dec00, 01jun01], S]
[JPlannerCR2, [01jul01, 01sep01], C]
[ArmyLogCR1, [10dec00, 01mar01], S]
[ArmyLogCR2, [01jul01, 01aug01], C]
User Role Authorizations:
URA [UR, M , TC, SC]
[ct,  ],true]
[JPlannerCR1, CrisisPicture,
[JPlannerCR1, ArmyBattleCommandSys, [10dec00,16feb01], true]
[ArmyLogCR1, CrisisPicture, [10dec00,16feb01],
Grid1  NA20 AND Grid2  NC40],
[ArmyLogCR1, LogPlanningTool, [10dec00,16feb01],CrisisNum=CR1]
DSEC--29
Related Work: RBAC

Benefits of RBAC

CSE5810


Main Approaches




Flexible, Ease of Use, Policy Realization
[Bert97, Demu95, Ferr92, Nyan93, Sand96, Ting87]
UConn - [Demu94…01, Hu94, Ting87]
GMU -RBAC96 - [Ahn99…, Osbo96…, Sand96...]
NIST - [Bark97, Ferr99…, Gavr98, Jeag97…]
Similarities and Differences:



Our Approach Does Not Rely on a Role Hierarchy
Administrative Duties are Separated for Ease of Use
and Least Privilege
Our Approach Can Realize Multiple Policies
Simultaneously on Multiple Federated Resources
DSEC--30
Unified Security Model Definitions
Signature Constraint

CSE5810
Definition 11: A Signature Constraint, SC,
Boolean Expression Defined on the Signature of
Method, Mijk of Service Sij of resource Ri that
 Limits the Allowable Values on the Parameters
 Boolean Expression is:
(return-type constraint) and (parameters constraint)


where either/both could be null
Parameters Constraint uses AND, OR, NOT
Example:
CrisisPicture (Token, CrisisNum, Grid1, Grid2);
SC: Grid1 < NA20 and Grid2 < NC40
DSEC--31
Unified Security Model Definitions
Time Constraint

CSE5810

Definition 12: A time constraint, TC, is a lifetime
that represents when a method can be assigned to a
user role (or invoked by a user) or when a user is
allowed to play a role. A TC has the default of [ct,
]. TC utilized at design and run time to:
 user role and method LTs constraining when
the method can be assigned
 user role, method, and user LTs constraining
when the method can be invoked
 user role and user LT constraining when the
user can be authorized to the role
Example:
ArmyBattleCommandSys (Token, CrisisNum);
TC = [10dec00, 16feb01]
DSEC--32
Related Work:
Signature and Time Constraints

CSE5810


Temporal Constraints [Ahn00, Bert96, Bert01]
User Constraints [Sand98, Zurk96]
Similarities and Differences:




Temporal Constraints used on Objects for Work Flow
are applied to Methods as Time Constraints to Create
an Operational Time Window for Valid Invocations
Time Constraints are Role Dependent so Same Method
in a Different Role, Can Have a Different Time
Constraint
Lifetimes in Conjunction with Separate, Method Time
Constraints Improve Granularity and Provide Increased
Flexibility for Security Policy
Use of Flexible, Run-Time, Signature Constraints is
Unique for Role Based Access Control, but Similar to
Other Programming Parameter/Argument Techniques
DSEC--33
Unified Security Model Definitions
Mandatory Access Control Constraint

CSE5810

Definition 13: A mandatory access control
constraint, MACC, is the domination of the
SLEVEL of one entity over another entity:
 CLS of Role Dominate () CLS of Resource,
Service, or Method
 CLR of User Dominate () CLS of Role
Example MACC:
 Design Time
 CLS of Role vs. CLS of Resource, Service, or
Method
 Check for CLR of User vs. CLS of Role

Run Time: CLR of User vs. CLS of Resource,
Service, or Method
DSEC--34
Unified Security Model Definitions
User Role Authorizations

CSE5810
Definition 14: A user-role authorization, URA,
signifies a UR authorized to invoke a method
under optional TC and/or SC, and is defined as:
URA  [UR, M , TC , SC ]
where
 UR is as given in Definition 7
 M is as given in Definition 4
 TC is as given in Definition 12 and is an LT
that represents when the method is available to
UR for invocation with default [ct, ]
 SC is empty (true) or as given in Definition 11
and represents values that invocation can occur
DSEC--35
Unified Security Model Definitions
User Role Authorizations

CSE5810
Definition 15a: UR authorization matrix, URAM,
is a r  q matrix indexed by roles and methods:
1 URi is authorized to invoke M j
URAM (URi , M j )  
0 otherwise
Notes:



Initially, URAM, contains all 0 entries
When equal to 1 for some URA  [ A, M , TC , SC ]
authorization is a Valid URA (VURA)
At Design, UR CLS must dominate M CLS
and there must be Overlap of LT/TC
DSEC--36
Example Users, User Roles, and URAs
Users:
CSE5810
U  [U UserId , U LT , U CLR ]
(T)General DoBest: [DoBest, [ct, ∞], T]
(T)Colonel DoGood: [DoGood, [01dec00,01jun01], T]
(S)Major DoRight: [DoRight, [01dec00,01jan01], S]
], T]
(T)Major CanDoRight: [CanDoRight,[01jan01,01feb01,
User-Roles:
UR  [UR Name , UR LT , URCLS ]
[CDR_CR1, [01dec00,01dec01], T]
[JPlannerCR1, [01dec00, 01jun01], S]
[JPlannerCR2, [01jul01, 01sep01], C]
[ArmyLogCR1, [10dec00, 01mar01], S]
[ArmyLogCR2, [01jul01, 01aug01], C]
User Role Authorizations:
URA [UR, M , TC, SC]
[JPlannerCR1, CrisisPicture, [ct, ∞],true]
[JPlannerCR1, ArmyBattleCommandSys, [10dec00,16feb01], true]
[ArmyLogCR1, CrisisPicture, [10dec00,16feb01],
Grid1  NA20 AND Grid2  NC40],
[ArmyLogCR1, LogPlanningTool, [10dec00,16feb01],CrisisNum=CR1]
DSEC--37
Unified Security Model Definitions
Remaining Definitions

CSE5810

Definition 15b: A valid user-role authorization
list, VURAL  {VURAi  i  1v}
where v  r  q
is the set of all VURAs with URAM(UR,M) = 1.
Definition 16: A user authorization, UA, is a user
authorized to play a role: UA  [U ,UR, TC ]
where

U is as given in Definition 9

UR is as given in Definition 7

TC is as given in Definition 12 and
represents the LT of authorization
DSEC--38
Unified Security Model Definitions
Remaining Definitions

CSE5810
Definition 17a: User authorization matrix, UAM:
1 U j is authorized to URi
UAM (URi ,U j )  
0 otherwise

Notes:

Initially, UAM, contains all 0 entries

When equal to 1 for some
Authorization is a Valid UA (VUA)

At Design Time, a U’s CLR must dominate a
Role’s CLS with overlap of TC and LT
DSEC--39
Example UAM and URAM Matrices
User Authorization Matrix (UAM)
1 = authorized, 0 = not
CSE5810
User\User-Role
DoBest
DoGood
DoRight
CanDoRight
ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1
0
0
0
0
1
0
0
1
1
0
1
0
0
0
0
0
1
0
0
0
User-Role Authorization Matrix (URAM):
1 = UR authorized to invoke Method, 0 = otherwise
Method\User-Role
ArmyLogCR1
ArmyBattleCommamdSys 1
CrisisPicture
1
MarineCombatOpnsSys
0
LogPlanningTool
1
ArmyLogCR2
1
1
0
1
JPlannerCR1
1
1
1
0
JPlannerCR2
1
1
1
0
CDR_CR1
1
1
1
1
DSEC--40
Unified Security Model Definitions
Remaining Definitions

Definition 17b: A valid user authorization list,
VUAL  {VUAi | i  1 w}
CSE5810

where w  r  u
is the set of all VUAs with UAM(UR,U) = 1
Definition 18: A client, C, is authorized user U,
uniquely identified via a client token
C = [U, UR, IP-Address, Client-Creation-Time]
where Creation Time is Clock at Creation
DSEC--41
Security Enforcement Framework
Software Architecture
Database
Client
CSE5810
COTS
Client
Lookup
Service
Wrapped
Resource
for Database
Application
Wrapped
Resource
for COTS
Application
Java
Client
General
Resource
Wrapped
Resource
for Legacy
Application
Software
Agent
Legacy
Client
Security Policy
Client (SPC)
Lookup
Service
Security Authorization
Client (SAC)
Global Clock
Resource (GCR)
Unified Security Resource (USR)
Security
Policy
Services
Security
Security
Authorization Registration
Services
Services
Security
Analysis and
Tracking (SAT)
DSEC--42
Security Enforcement Framework

CSE5810

Unified Security Resource Services to:
 Manage URs and Privileges
 Authorize URs to Us
 Identify Users and Track Security Behavior
Associated Administrative/Management Tools
 Security Policy Client to Grant/Revoke
Privileges (TCs, methods, SCs)/set CLS/CLR
 Security Authorization Client to Assign CLRs
and Authorize URs to End Users
 Security Analysis Tool (SAT) to Track all
Client Activity (Logons/Method Invocations)
DSEC--43
Security Enforcement Framework
Security Prototype (JINI and CORBA)
CSE5810
Java
GUI
PDB Client
Patient DB
Resource (PDB)
Security
Policy
Client
Common
Resource
(Global Clock)
CORBA
Lookup
Service
USR
All
Services
JINI
Lookup
Service
Java
GUI
UDB Client
University DB
Resource (UDB)
Security
Authorization
Client
DSEC--44
Security Enforcement Framework
USR Services
Security Policy Services
Register Service
Query Privileges Service
CSE5810
User Role Service
Constraint Service
Grant-Revoke Service
Grant_Resource(UR_Id, R_Id);
Grant_Service(UR_Id, R_Id, S_Id);
Grant_Method(UR_Id, R_Id, S_Id, M_Id);
Grant_SC(UR_Id, R_Id, S_Id, M_Id, SC);
Grant_TC(UR_Id, R_Id, S_Id, M_Id, TC);
Revoke_Resource(UR_Id, R_Id);
Revoke _Service(UR_Id, R_Id, S_Id);
Revoke _Method(UR_Id, R_Id, S_Id, M_Id);
Revoke _SC(UR_Id, R_Id, S_Id, M_Id, SC);
Revoke _TC(UR_Id, R_Id, S_Id, M_Id, TC);
Security Authorization Services
Authorize Role Service
Client Profile Service
Security Registration Services
Register Client Service
Security Tracking and Analysis Services
DSEC--45
Security Enforcement Framework
Security Policy Services
Register Service
Register_Resource(R_Id);
Register_Service(R_Id, S_Id);
CSE5810 Register_Method(R_Id, S_Id, M_Id);
Register_Signature(R_Id, S_Id, M_Id, Signat);
UnRegister_Resource(R_Id);
UnRegister_Service(R_Id, S_Id);
UnRegister_Method(R_Id, S_Id, M_Id);
Unregister_Token(Token)
Query Privileges Service
Query_AvailResource();
Query_AvailMethod(R_Id);
Query_Method(Token, R_Id, S_Id, M_Id);
Check_Privileges(Token, R_Id, S_Id, M_Id, ParamValueList);
User Role Service
Create_New_Role(UR_Name, UR_Disc, UR_Id);
Delete_Role(UR_Id);
DSEC--46
Security Enforcement Framework
Security Policy Services
Constraint Service
DefineTC(R_Id,
DefineSC(R_Id,
CSE5810 CheckTC(Token,
CheckSC(Token,
S_Id,
S_Id,
R_Id,
R_Id,
M_Id,
M_Id,
S_Id,
S_Id,
SC);
SC);
M_ID);
M_ID, ParamValueList);
Grant-Revoke Service
Grant_Resource(UR_Id, R_Id);
Grant_Service(UR_Id, R_Id, S_Id);
Grant_Method(UR_Id, R_Id, S_Id, M_Id);
Grant_SC(UR_Id, R_Id, S_Id, M_Id, SC);
Grant_TC(UR_Id, R_Id, S_Id, M_Id, TC);
Revoke_Resource(UR_Id, R_Id);
Revoke_Service(UR_Id, R_Id, S_Id);
Revoke_Method(UR_Id, R_Id, S_Id, M_Id);
Revoke_SC(UR_Id, R_Id, S_Id, M_Id, SC);
Revoke_TC(UR_Id, R_Id, S_Id, M_Id, TC);
DSEC--47
Security Authorization and Registration
Services
Authorize Role Service
CSE5810
Grant_Role(UR_Id, User_Id);
Revoke_Role(UR_Id, User_Id);
Client Profile Service
Verify_UR(User_Id, UR_Id);
Erase_Client(User_Id);
Find_Client(User_Id);
Find_All_Clients();
SECURITY
AUTHORIZATION
SERVICES
Register Client Service
Create_Token(User_Id, UR_Id, Token);
Register_Client(User_Id, IP_Addr, UR_Id);
UnRegister_Client(User_Id, IP_Addr, UR_Id);
IsClient_Registered(Token);
Find_Client(User_Id, IP_Addr);
Security Tracking and Analysis Services
SECURITY
REGISTRATION
SERVICES
Tracking Service: Logfile(Log String)
Analysis Service: Analyze (Java Class File)
DSEC--48
Security Enforcement Framework
Client, Resource, Service Invocations
CSE5810
GCCS
Client
1 Register_Client(DoRight,100.150.200.250, ArmyLogCR1)
4 Return
Security
Registration
Result,Create_Token(DoRight,ArmyLogCR1,Token) Services
2 Verify_UR(DoRight,ArmyLogCR1)
5. Discover/Lookup(GCCS,Joint,CrisisPicture)
Returns Proxy to Course Client
6 CrisisPicture(Token,CR1, NA20, NC40)
11 Return Result,CrisisPicture(…)
Lookup
Service
7 IsClient_Registered(Token)
9 Check_Privileges(Token, GCCS, Joint,
CrisisPicture, [NA20,NC40])
GCCS
Resource
8 Return Result of IsClient_Registered(…)
3 Client OK?
USR
Security
Authorization
Services
Security
Policy
Services
10 Return Result of Check_Privileges(…)
DSEC--49
Security Prototype
Global Clock Server/Client Logon
CSE5810
DSEC--50
The Security Policy Client

CSE5810

Manages Privileges for Roles and Resources
For Roles:
 Define/Delete Roles including LTs and CLSs
 Grant/Revoke Privileges in Terms of Methods
 Grant Methods to Roles
 Limit Grant based on Time Constraint
 Limit Grant based on Signature Constraint

For Resources:
 Register Resource, its Services, their Methods
 Establish LTs and CLSs
 Resources can Also Register themselves
Programmatically via the USR Services
DSEC--51
Security Policy Client
Registering a Resource
CSE5810
DSEC--52
Security Policy Client
Registering a Service
CSE5810
DSEC--53
Security Policy Client
Registering Methods for Resource
CSE5810
DSEC--54
Security Policy Client
Registering Methods for Resource
CSE5810
DSEC--55
Security Policy Client
Adding Methods to Service
CSE5810
DSEC--56
Security Policy Client
Adding Methods to Service
CSE5810
DSEC--57
Security Policy Client Confirmation of
Registered Methods
CSE5810
DSEC--58
Security Policy Client
Tracking Defined Resources
CSE5810
DSEC--59
Security Policy Client
Creating User Role
CSE5810
DSEC--60
Security Policy Client
Creating User Role
CSE5810
DSEC--61
Security Policy Client
Granting Resource to UR
CSE5810
DSEC--62
Security Policy Client
Granting Service to UR
CSE5810
DSEC--63
Security Policy Client
Granting Method to UR
CSE5810
DSEC--64
Security Policy Client
Confirmation of Method to Role
CSE5810
DSEC--65
Security Policy Client
Reviewing Access of Resources to Roles
CSE5810
DSEC--66
Security Policy Client
Defining a Signature Constraint
CSE5810
DSEC--67
Security Policy Client
Defining a Signature Constraint
CSE5810
DSEC--68
The Security Authorization Client

CSE5810


Intended for Authorization Capabilities
Main Objectives
 Define New User with CLR and LT
 Authorize URs to End Users
 Define Clients
Authorization of Roles to Users Must Satisfy
 User.CLR Dominates Role.CLS
 Overlap of LTs w.r.t. Current Time
DSEC--69
Security Authorization Client
Creating a User
CSE5810
DSEC--70
Security Authorization Client
Granting Roles to User
CSE5810
DSEC--71
Security Prototype
Tracking Logins and Actions
CSE5810
DSEC--72
Security Prototype
Tracking Methods of Resources
CSE5810
DSEC--73
Security Assurance

CSE5810


Security Assurance Represents a Confidence Level
of the Security Capabilities to Insure Sensitive
Information is Protected From Access and Misuse
Assurance is Needed at:
 Design Time (DT) - as Security Policy is
Defined Using our Security Model
 Run Time (RT) - via Enforcement as
Users/Clients Access Resources in Secure
Manner
Security Assurance is Enumerated and Defined to:
 Insure Policy Consistency (A & M Tools)
 Check Conditions as Users Access Resources
DSEC--74
Assurance Guarantees

CSE5810




Available Time : Maximum Amount of Time
Derived from the Intersections of LTs and TCs
Simple Security Property: A Subject Can Read at
the Same or Lower Level. (Read Down/No Read
Up)
Simple Integrity Property: A Subject Can Write to
the Same or Lower Level
Safety: No Bad Things Can Happen During
Execution
Liveness: All Good Things Can Happen
DSEC--75
Available Time

CSE5810


Available Time Represents “When” Construct is
Available for Usage
Comparison of Lifetimes Including
 Role
 Method
 Current Time
Sets a Limit on When an Action can Occur
DSEC--76
The Compare Function for Two LTs
CSE5810
DSEC--77
Time-Based Guarantees
CSE5810
DSEC--78
Lemma 1 Conceptually
CSE5810
DSEC--79
Time-Based Guarantees
CSE5810
DSEC--80
Lemma 2 Conceptually
CSE5810
DSEC--81
Time-Based Guarantees
CSE5810
DSEC--82
Lemma 3 Conceptually
CSE5810
DSEC--83
MAC-Based Guarantees

CSE5810

Verify the Behavior of Method Invocation
Differentiate Between Method Types
 Read-Only Method  Do not Change the State of an Object
 Satisfies Simple Security (Read up/No Read Down)

Read-Write method
 May Change the State of an Object
 Satisfies Simple Security (Read up/No Read Down)
and Simple Integrity (Write Down/No Write Up)

Assume: Values are Not Returned Through
Method Parameters (only Value Parameters)
DSEC--84
MAC-Based Guarantees
CSE5810
DSEC--85
MAC-Based Guarantees
CSE5810
DSEC--86
MAC-Based Guarantees
CSE5810
DSEC--87
MAC-Based Guarantees
CSE5810
DSEC--88
MAC-Based Guarantees
CSE5810
DSEC--89
Safety and Liveness Guarantees

Safety: Nothing bad happens during execution

Liveness: All good things can happen during
execution

GOAL: Maximize Safety and Liveness
 Disconnecting from a network increases Safety,
but decreases Liveness
 Allowing unlimited access increases Liveness,
but decreases Safety
CSE5810
DSEC--90
Security Assurance Rules

CSE5810

A Security Assurance Rule Must hold True for the
Security Policy
 DT: Privilege Definition/Modification
 RT: As Users Perform Actions
Categories of Checks are:
 MACC Domination
 Lifetime
 Time Constraint
 Signature Constraint
 Authorization and Authentication
DSEC--91
Security Assurance - Design Time
Rule I: Authorizing Method to UR

Create a VURA and if the Creation is Successful,
then the entry of URAM = 1.

For Authorization to Occur
 CLS of A must Dominate CLS of M
 LTs of A, M, and TC must Overlap (reset as
TC), and reset TC has an end time after ct
CSE5810
DSEC--92
Security Assurance - Design Time
Rule I Conceptually

CSE5810
LTs and TCs must be Contrasted
A.LT
M.LT
TC
ct
TC
M.LT
A.LT
DSEC--93
Security Assurance - Design Time
Rule II: Authorizing UR to User

Create a VUA and if the Creation is Successful,
the Entries of UAM and UDAM are set to 1

For Authorization to Occur
 CLR of X must Dominate CLS of A
 LTs of A, X, and TC must Overlap (reset as
TC), and reset TC has an end time after ct
CSE5810
DSEC--94
Security Assurance - Design Time
Rule II Conceptually

CSE5810
LTs and TCs Again Constrained
TC
X.LT
A.LT
ct
TC
X.LT
A.LT
DSEC--95
Security Assurance - Runtime
Rule III: Authorizing UR to User

Runtime Authorization (of user to role).

For Authorization to Occur at Runtime
 Rule II must be rechecked (since privileges can
dynamically change).
 Recheck involves the Overlap of the LTs of X,
A, and TC with Respect to Current Time.
CSE5810
DSEC--96
Security Assurance - Runtime
Rule III Conceptually

CSE5810
What is the Time Issue in This Case?
 Must Compare Against Rule II
 Must Also Look at TC vs. ct
 TC.et After ct
 TC.st Before ct
ct
TC
ct
TC
DSEC--97
Security Assurance - Runtime
Rule IV: Invoking a Method
CSE5810


N(Name), P(Params), APV(Actual Param Values)
SCOracle is a Constraint Checker that Compares
Parameter Values of M’s Invocation against SC
 returns true if M.parametervalues satisfy SC
 returns false otherwise.
DSEC--98
Security Assurance - Runtime
Rule IV Conceptually

CSE5810

Same issues as Rule III (Rule I and TC vs. ct)
Additionally, There is a Constraint Checker
Defn: CrisisPicture (Token, CrisisNum, Grid1, Grid2);
SC:
Grid1 < NA20 and Grid2 < NC40
Call: CrisisPicture (123, 111, NA18, NC45);
Compare Call Against SC to Determine if Can Invoke
DSEC--99
Safety and Liveness Theorems
CSE5810
DSEC--100
Safety and Liveness Theorems
CSE5810
DSEC--101
Safety and Liveness Theorems
CSE5810
DSEC--102
Safety and Liveness Theorems
CSE5810
DSEC--103
Related Work
Security Assurance

CSE5810


Motivation and Need within DoD
[C4I99, DARP00, DoD88, Tete99]
Abstract Study of Assurance
[Alfo01, Garv98,McCu91, Maco01]
Role Administration Participates in Assurance
 Separation of Duty [Ahn99, Both01,Garv98,
Glig98, Nyan93, Osob00, Simo97]
 Mutual Exclusion [Bert97, Kand01, Khun97]
 Role Hierarchies [Demu95, Ferr97, Hu95,
Jans98, Moff99, Sand96, Spoo89 ]
 Administration Mechanisms [Awis97,
Murl01, Nyan94, Sand99]
DSEC--104
What is Role Delegation?

CSE5810



Role Delegation is a User-to-User Relationship
that Allows One User to Transfer Responsibility
for a Particular Role to Another Individual
Two Major Types of Delegation
 Administratively-directed Delegation has an
Administrative Infrastructure Outside the
Direct Control of a User Mediates Delegation
 User-directed Delegation has an User (Playing
a Role) Determining If and When to Delegate a
Role to Another User
In Both, Security Administrators Still Oversee
Who Can Do What When w.r.t. Delegation
Work of M. Liebrand (Rensselaer at Hartford)
DSEC--105
Why is Role Delegation Important?

CSE5810
Many Different Scenarios Under Which Privileges
May Want to be Passed to Other Individuals
 Large organizations often require delegation to
meet demands on individuals in specific roles
for certain periods of time
 True in Many Different Sectors
 Financial Services
 Engineering
 Academic Setting

Key Issues:
 Who Controls Delegation to Whom?
 How are Delegation Requirements Enforced?
DSEC--106
What Can be Delegated?

CSE5810



Authority to Do the Task, Carries the Least
Responsibility Necessary to Execute the Task, but
Does Mean the Delegated User Can Execute the
Delegated Task or Role.
Responsibility to Do a Task Implies Accountability
and a Vested Interest that a Task or Role Can Be
Executed Properly.
Duty to Perform a Task Implies that the Delegated
User is Obligated to Execute the Given Task.
Our Focus: Delegate Authority Only
DSEC--107
Our Focus for Delegation

CSE5810




Extensions to the Unified Security Model
 Identify Roles that are Delegatable
 Distinguish: Original and Delegated Users
 Delegation Authority and Delegated Role
Detailed Example to Illustrate Concepts
Analysis of Role Delegation Capabilities
Investigation of SPC, SAC, and SDC in Support of
Delegation
Security Assurance for Delegation
DSEC--108
Role Delegation Extensions

CSE5810

Definition 19: A delegatable UR, DUR, is a UR
that is eligible for delegation.
Definition 20: The delegatable UR vector, DURV,
is defined for all r as:
1 URi is a DUR
DURV (URi )  
0 URi is not a DUR

Delegatable URs (from Slide 33)
[CDR_CR1, [01dec00,01dec01], T]
[JPlannerCR1, [01dec00, 01jun01], S]
[JPlannerCR2, [01jul01, 01sep01], C]
DURV(A) = 1 for A = CDR_CR1, JPlannerCR1 and JPlannerCR2
DURV(A) = 0 for A = ArmyLogCR1 and ArmyLogCR2
DSEC--109
Role Delegation Extensions

CSE5810

Definition 21: An original user, OU UL, is
authorized to the UR such that there exists a VUA
for the OU/UR, i.e., UAM(UR,OU) = 1
 OU: Authorized to the UR via Regular Process
 Implies Not Eligible for Delegation
Definition 22: A delegated user, DU UL, is a
user eligible to be delegated a UR by an OU or a
DU (there is not a VUA i.e., UAM(UR,DU) 1).
 DU of a UR cannot be an OU for same UR
DSEC--110
Examples of
OUs
DUs

CSE5810




ArmyLogCR1
 DoRight
ArmyLogCR2
 CanDoRight
JPlannerCR1
 DoGood
JPlannerCR2
 DoGood
CRC_CR1
 CDR_CR1




ArmyLogCR1
 DoBest, DoGood,
CanDoRight
ArmyLogCR2
 DoBest, DoGood,
DoRight
JPlannerCR1/JPlannerCR2
 DoBest, DoRight,
CanDoRight
CRC_CR1
 DoGood, DoRight,
CanDoRight
DSEC--111
Role Delegation Extensions

CSE5810
Definition 23: User delegation/authorization
matrix, UDAM:
2 U j is a DU of URi

UDAM (URi ,U j )  1 U j is an OU of URi
0 U is not authorized to UR
j
i



Represents who is a DU, OU, or Neither
UDAM Entries are
 Initially All Set to False
 Set to 1 Whenever a User is an OU
 Set to 2 Whenever a User is an DU
Recall Rule II Set UDAM = 1
DSEC--112
Delegation and Pass on Delegation
Authorities

CSE5810
When Establishing Privileges (by the Security
Officer) there must be the Ability to Define:
 Delegation Authority (DA)
 Recall:Security Officer can Delegate a Role to User
 DA Means that the Security Officer Can Delegate
the Authority to Delegate to another User
 Role Can be Delegated by one User to Another
 However, Delegation Authority Cannot

Pass-on Delegation Authority (PODA)
 PODA Augments DA to Allow the Delegation
Authority to Also be Delegated as Part of the
Delegation of a Role to a User
DSEC--113
Role Delegation Extensions

CSE5810


Definition 24: Delegation authority, DA, is given
to the OU to allow delegation of a DUR.
Definition 25: Pass-on delegation authority,
PODA, allows an OU (DU) to pass on DA for a
DUR to another user (OU or DU).
Definition 26: Delegation authority matrix, DAM:
2 U j has DA and PODA for URi

DAM (URi ,U j )  1 U j has only DA for URi
0 U has neither DA nor PODA for UR
j
i

DU has Neither DA Nor PODA
DU has Just DA
DU has Both DA and PODA
DSEC--114
Example of DA and PODA
Delegation Authority Matrix (DAM):
2 = has DA and PODA, 1 = has DA, 0 = neither
CSE5810
User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1
DoBest
0
0
0
0
2
DoGood
0
0
1
1
0
DoRight
0
0
0
0
0
CanDoRight
0
0
0
0
0




JPlanner1: DoGood has DA
JPlanner2: DoGood has DA
CDR_CR1: DoBest has both DA and PODA
All Other Entries have Neither DA Nor PODA
DSEC--115
Recall UAM and URAM Matrices
User Authorization Matrix (UAM)
1 = authorized, 0 = not
CSE5810
User\User-Role
DoBest
DoGood
DoRight
CanDoRight
ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1
0
0
0
0
1
0
0
1
1
0
1
0
0
0
0
0
1
0
0
0
User-Role Authorization Matrix (URAM):
1 = UR authorized to invoke Method, 0 = otherwise
Method\User-Role
ArmyLogCR1
ArmyBattleCommamdSys 1
CrisisPicture
1
MarineCombatOpnsSys
0
LogPlanningTool
1
ArmyLogCR2
1
1
0
1
JPlannerCR1
1
1
1
0
JPlannerCR2
1
1
1
0
CDR_CR1
1
1
1
1
DSEC--116
Augment with
DAM and UDAM Matrices
CSE5810
User Delegation/Authorization Matrix (UDAM):
2 = U is a DU, 1 = U is a OU, and 0 = not authorized
User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1
DoBest
0
0
0
0
1
DoGood
0
0
1
1
0
DoRight
1
0
0
0
0
CanDoRight
0
1
0
0
0
Delegation Authority Matrix (DAM):
2 = has DA and PODA, 1 = has DA, 0 = neither
User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1
DoBest
0
0
0
0
2
DoGood
0
0
1
1
0
DoRight
0
0
0
0
0
CanDoRight
0
0
0
0
0
DSEC--117
Example - Role Delegation

CSE5810

General DoBest Delegates his Role to Colonel
DoGood with DA, where DoBest, CDR_CR1, and
DoGood defined as:
OU: [DoBest, [ct, ], T]
UR: [CDR_CR1, [01dec00, 01dec01], T]
UA: [DoBest, CDR_CR1, [01dec00, 01dec01]]
DA: Yes
PODA: Yes
After Delegation:
DU: [DoGood, [01dec00, 01jun01], T]
UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]
DSEC--118
Example - Role Delegation

CSE5810

Now, Colonel DoGood wishes to re-delegate
CDR_CR1 to Major CanDoRight, which can be
defined as:
DU: [DoGood, [01dec00, 01jun01], T]
UR: [CDR_CR1, [01dec00, 01dec01], T]
UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]
DA: Yes
PODA: No
After Delegation:
DU: [CanDoRight, [01jan01, 01feb01], T]
UA: [CanDoRight, CDR_CR1, [01dec00, 01jun01]]
DSEC--119
Related Work: Role Delegation

CSE5810



Role Administration [Awis97]
Delegation with RBAC [Bark00, Na00]
Delegation Principals [Zhang01]
Similarities and Differences
 In Our Approach, OU Maintains Control of
Delegation
 DU Cannot Give Delegation Authority



Our Approach is Dynamic, in that, Delegations
have LTs Changeable During Runtime
Our Delegation Incorporates MACC
We extend Zhang’s Definitions to Include
 Delegation Authority, Revocation Authority,
Delegated Role, and Delegatable Role
DSEC--120
Enforcement Framework and
Role Delegation Revocation Rules

CSE5810
User-to-User Delegation Authority Rule
 A User (OU or DU) Who is a Current Member
of a Delegatable Role (DUR), Can Delegate
that User Role to Any User that Meets the
Prerequisite Conditions of the Role:
 DU Receiving the Role is Not a Member of the
Role;
 OU or DU is Identified As Having Delegation
Authority for the Role;
 DU Meets the Mandatory Access Control
Constraints (MACC).
DSEC--121
Enforcement Framework and
Role Delegation Revocation Rules

CSE5810

Delegation Revocation Authorization Rule:
 An Original User Can Revoke Any Delegated
User From a User Role in Which the OU
Executed the Delegation.
 This is a Stricter Interpretation than [Zhan01],
Which Allows Any OU of a Role Revocation
Authority Over a DU in the Delegation Path.
 In Addition, a Security Administrator Can
Revoke Any Delegation.
Cascading Revocation Rule:
 Whenever an OU or DU in the delegation path
is revoked, all DUs in the path are revoked.
DSEC--122
Analysis of Role Delegation

CSE5810

Analysis of Role Delegation Against Set of
Common Criteria
 Monotonicity
 Permanence
 Totality
 Administration
 Levels of Delegation
 Multiple Delegation
 Agreements
 Cascading Revocation
 Grant-dependency Revocation
We’ll Define and Discuss Each
DSEC--123
Analysis of Role Delegation
Monotonicity

CSE5810

Definition: Monotonicity Refers to the State of
Control the OU Possesses After Role Delegation
 Monotonic Delegation Means That the OU
Maintains Control of the Delegated Role
 Non-monotonic Means That the OU Passes the
Control of the Role to DU
Our Approach Utilizes Monotonic Delegation
Since We Believe for Assurance it is Critical to
Exercise a Level of Control W.R.T. Delegation
DSEC--124
Analysis of Role Delegation
Permanence

CSE5810

Definition: Permanence Refers to Delegation in
Terms of Time Duration
 Permanent Delegation is When a DU
Permanently Replaces the OU
 Temporary Delegation Has an Associated
Time Limit With Each Role
Our Approach Utilizes Temporary Delegation
Since Temporal Constraints (LTs/TC) Are an
Important Part of Our Unified Security Model
DSEC--125
Analysis of Role Delegation
Totality

CSE5810


Definition: Totality Refers to How Completely the
Permissions Assigned to the Role Are Delegated
 Partial Delegation Refers to the Delegation of
a Subset of the Permissions of the Role
 Total Delegation Refers to the Situation All of
the Permissions of the Role Are Delegated
Our Approach Utilizes Total Delegation Since we
Believe Partial Delegation Defeats Purpose of Urs
and Assignment Methods to UR under TCs/SCs
Partial Delegation is Achievable by Defining
Special Roles that are Delegatable
DSEC--126
Analysis of Role Delegation
Administration

CSE5810

Definition: Administration Refers to how
Delegation will be Administered
 User Directed is when the User Controls all
Aspects of Delegation
 Administrator-Directed (Third party, Agentdirected) is when Control is with the Security
Officer
Our Approach Utilizes a Combination of Both
Allowing the Security Officer to Establish
DA/PODA and the User to Determine to “Whom”
the Delegation will Occur
DSEC--127
Analysis of Role Delegation
Levels of Delegation

CSE5810

Definition: Levels of Delegation Refers to the
Ability of DU to Further Delegate a Role (PODA)
and the Number of Vertical Levels the Delegated
Role Can Be Delegated
 Boolean Control – Roles Can Be Re-delegated
Until a Delegating User Says No
 Integer Control –Roles can be Re-delegated
until Fixed Number of Re-delegations Occur
Our Approach Utilizes Modified Boolean Control
via the DA/PODA
 If PODA not Given - Delegation Stops
 Prototype has Limit of either 2 or 3 Levels
DSEC--128
Analysis of Role Delegation
Multiple Delegations

CSE5810

Definition: Multiple Delegations Refers to the
Number of Delegated Users (DU) (Horizontally)
to Whom a Delegatable User Role (DUR) Can Be
Delegated to at Any Given Time
Our Approach Includes Unlimited Delegations in
Our Security Model Since We Want to Maintain
the User’s Flexibility
 A Limit on the Number of DUs to a Role is
Subjective.
 Subjective Limits Are Not Often Enforced;
There Are No Hard Bases for Them
DSEC--129
Analysis of Role Delegation
Agreements

CSE5810

Definition: Agreements Refer to the Delegation
Protocol of the OU to the DU
 Bilateral Agreements: the DU Needs to
Accept the Delegated Role
 Unilateral Agreements: the OU Delegates the
UR Permissions and the DUs Are Not
Required to Accept or Even Acknowledge the
Delegation
Our Approach Utilizes Unilateral Agreements
DSEC--130
Analysis of Role Delegation
Cascading Revocation

CSE5810


Definition: Cascading Revocation Refers to the
Indirect Revocation of All DUs When the OU
Revokes Delegation or Administration Revokes
the OU’s Delegated Role
Non-cascading Revocation Could Be Useful in the
Event a Middle Manager User Is Fired Without
Replacement and Subordinates Need to Execute
the Vacated Roles
Our Approach Utilizes Cascading Revocation and
will Handle Non-Cascading Case via Security
Administrative Tools (Changing Privileges)
DSEC--131
Analysis of Role Delegation
Grant Dependency Revocation

CSE5810

Definition: Grant-Dependency Revocation Refers
to Who Has Authority to Revoke a DU
 Grant-Dependent Revocation Only Allow the
OU to Revoke the Delegated Role
 Grant-Independent Revocation Allows Any
Original Member of the DUR to Revoke a
Delegated Role
Our Approach Utilizes a Limited Form of Grantindependent Revocation Where Only the DU and
the Security Administrator Can Revoke a DUR
DSEC--132
Role Delegation Process
Security Management Tools

CSE5810


Examine the Process of Delegation
Utilize the Military Application
Explore
 Security Policy Client
 Security Authorization Client
 Security Delegation Client
 SDC is a New Administrative Tool
 Utilized by Both Security Officer and the End User


Focus on their role in Delegation Administration
Screen Bit Maps are Ordered to Illustrate a Process
DSEC--133
Security Policy Client
Registration of Resources
CSE5810
DSEC--134
Security Policy Client
Creation of Administration Role
CSE5810
DSEC--135
Security Authorization Client
Granting of Role(s) to User(s)
CSE5810
DSEC--136
Security Policy Client
Cdr. Crisis 1 Role/Conflicting Role List
CSE5810
DSEC--137
Security Policy Client
Granting of Resource(s) to Role(s)
CSE5810
DSEC--138
Security Policy Client
Granting of Service (s) to Role(s)
CSE5810
DSEC--139
Security Policy Client
Granting of Methods(s) to Role(s)
CSE5810
DSEC--140
Security Policy Client
Query Privileges
CSE5810
DSEC--141
Security Authorization Client
Create a User
CSE5810
DSEC--142
Security Authorization Client
Create a User
CSE5810
DSEC--143
Security Authorization Client
Granting a Role
CSE5810
DSEC--144
Security Authorization Client
Granting a Role with DA/PODA
CSE5810
DSEC--145
Security Authorization Client
Granting a Role with DA/PODA
CSE5810
DSEC--146
Security Authorization Client
Query Privileges
CSE5810
DSEC--147
Security Authorization Client
Query Privileges - Results
CSE5810
DSEC--148
The Security Delegation Client
CSE5810
DSEC--149
Security Delegation Client
Log on to the Security Delegation Client
CSE5810
DSEC--150
Security Delegation Client
Attempt to Perform a Delegation
CSE5810
DSEC--151
Security Delegation Client
Attempt to Perform a Delegation
CSE5810
DSEC--152
Security Delegation Client
Query a User’s Role
CSE5810
DSEC--153
Security Delegation Client
Revocation of Delegation
CSE5810
DSEC--154
Security Delegation Client
Revocation of Delegation
CSE5810
DSEC--155
Security Delegation Client
Denying Log in if UR not Available
CSE5810
DSEC--156
Security Delegation Client
Denying Delegation if MAC Violated
CSE5810
DSEC--157
Security Delegation Client
Denying Delegation if TC Violated
CSE5810
DSEC--158
Security Delegation Client
Denying Delegation if no Delegatable Roles
CSE5810
DSEC--159
Security Delegation Client
Pass on Delegation Restriction
CSE5810
DSEC--160
Security Delegation Client
Example
CSE5810
Dobest delegate a role to dogood
without pass-on-delegation, when
dogood delegated this role to
doright, he can’t delegate it with
pass-on-delegation
DSEC--161
Security Delegation Client
Delegation Matrix within SDC
CSE5810
Dobest(T): ArmyLogCR1(c)
When Original user revoke
This role, the role matrix is
revoked within SDC
Chip(T): ArmyLogCR1(c)
Dogood(S): ArmyLogCR1 ( C)
Doright(c ): ArmyLogCR1 ( C)
DSEC--162
Security Delegation Client
Example
CSE5810
Dobest delegate a
role to dogood
Dogood delegate this
role to other users
DSEC--163
Security Delegation Client
Example
CSE5810
Dobest revokes the role
delegated to dogood
The role delegated by dogood
are erased at the same time.
DSEC--164
Design Time Security Assurance
for Delegation

CSE5810
Design Time Checks – Policy Realization
 MACC Domination CLR Dominates CLS
 Role Delegation
 DU Not Already a Role Member

User to User Delegation Authority
 Must Check User Delegation Authority Matrix
 DU Meets MACC Requirements

Lifetime Consistency
 DU’s LT Must be Within OU’s LT

Modified Boolean Delegation
 OU can Delegate and Pass on Delegation Authority
 DU cannot Pass On Delegation Authority

These are Checks in SPC, SAC, and SDC
DSEC--165
Run Time Security Assurance
for Delegation

CSE5810
Executed While Running Distributed Application
 MACC Domination
 Role Delegation
 User to User Delegation Authority
 Lifetime Consistency
 Modified Boolean Delegation
(additional checks)
 Delegation Revocation Authorization Rule
 OU/DU Can Revoke Any Initiated Delegation

Cascading Revocation Rule
 Whenever OU is Revoked, OU’s Delegations are
revoked, Including Passed On Delegations

These are Checks by the Enforcement Framework
as supported with USR
DSEC--166
Security Assurance - Design time
Rule V: Assigning Delegation Authority
CSE5810


UDAM(A, X) =1 implies that UAM(A, X) = 1 by
Rule II.
Rules V establishes DA for user X to role A in the
case where X is an OU.
DSEC--167
Theorem V
CSE5810
DSEC--168
Security Assurance - Design time
Rule VI: DA and PODA

User must have DA in order to have PODA
e.g., a User cannot have PODA without DA

UDAM(A, X) =1 implies that UAM(A, X) = 1 by
Rule II.
Rule VI establishes, respectively, DA/PODA for
user X to role A in the case where X is an OU.
CSE5810

DSEC--169
Security Assurance - Design time
Rule VII: Delegation of UR

The delegation sets UAM and UDAM for the DU
and DR.

Y is a DU of A, and X satisfies Rules V or VI
Y to be authorized to A, hence UAM(A, Y) = 1
CSE5810

DSEC--170
Security Assurance - Design time
Rule VIII: Delegation of DA/PODA

Passing on of DA or DA/PODA from a user
(either OU or DU) to another DU

Rule VIII establishes, respectively, DA or
DA/PODA for user Y a DU of role A, and
assumes Rule VII is satisfied.
CSE5810
DSEC--171
Theorem VI, VII, and VIII
CSE5810
DSEC--172
Assessment of RBAC/MAC
Model/Framework

CSE5810


Intent is to Assess the Capabilities of RBAC/MAC
Model and Security Framework
Analysis vs. SSE-CMM
 SSE-CMM: Standard Security Model
 Compare/Contrast Model/Framework
(including Assurance) Against SSE-CMM
 Use SSE-CMM as a Benchmark to Evaluate
the Degree We Meet ISO Requirements
Evaluation vs. Dynamic Coalitions (DCs)
 Represent via the RBAC/MAC Model Security
Features/Requirements of DCs
 Can RBAC/MAC Model Represent DCs?
 What Features are Good? Need to be Added?
DSEC--173
Analysis vs. SSE-CMM
What is SSE-CMM?

CSE5810

An ISO Standard Model For Capturing the
Essential Characteristics of an Organization’s
Security Engineering Process
The Model is a Standard for Security Engineering
Practices Covering:
 Life Cycle Management of All Activities
 Management, Organizational, and Engineering
Activities
 Concurrent Interactions (Software, Hardware,
Humans, Organizations)
 Certification, Accreditation, and Evaluation
DSEC--174
Analysis vs. SSE-CMM
Why was SSE-CMM Developed?

CSE5810

Objective:
 Advance Security Engineering As a Defined,
Mature, and Measurable Discipline
Project Goal:
 Develop a Mechanism to Enable:
 Selection of Appropriately Qualified Security
Engineering Providers
 Focused Investments in Security Engineering
Practices
 Capability-based Assurance
DSEC--175
Analysis vs. SSE-CMM
SSE-CMM Engineering Process Areas

CSE5810





Administer Security
Controls
Assess Impact
Assess Security Risk
Assess Threat
Assess Vulnerability
Build Assurance
Argument





Coordinate Security
Monitor Security
Posture
Provide Security
Input
Specify Security
Needs
Verify and Validate
Security
DSEC--176
Analysis vs. SSE-CMM
SSE-CMM Model Architecture

Domain
Organization
CSE5810Project
Security Engineering

Process Areas
Process
Areas
 Base Practice 01:
Establish Responsibilities
and Accountability for
Security Controls
 Base Practice 02:
Manage the Configuration
of Security System
Controls
Process
Domain
Areas
Process
Areas
Base
Base
Practices
Practices
10/24/96
Compare and Contrast
RBAC/MAC Model and
Framework w/Standard
SSE-CMM: 11 Process
Areas/61 Base Practices
 PA01: Administer
Security Controls
•
••
Base
Base
Practices
Practices

Work in Progress
DSEC--177
Evaluation vs. DCP
What is DCP?
Dynamic
Coalition
NGO/
PVO
CSE5810
Air Force
Navy
Joint
Command
System
Battle
Management
System
U.N.
GCCS
NATO
U.S.A
Army Battle
Command
System
Army
Army C2
AFATDS
FADD
ASAS
ABCS
CSSCS
GCCS-A
MCS
Combat
Operations
System
Marine Corps
U.S. Global C2 Systems
Dynamic Coalition Problem (DCP) are Inherent
Security, Resource, and/or Information
Sharing Risks that Occur as a Result of
the Coalition being Formed Quickly
Other
DSEC--178
Evaluation vs. DCP
Suitability of Our Approach for DCP

Detailed Evaluation of DCP w.r.t. Security Model

CSE5810






Utility of Multiple Roles for Users
Relevance of Data Value Constraints and Time
Limitations on Users
Examination of API Level Control of Resources
Importance of Multi-level Secure Capabilities
Security Assurance at Design/Run Times
Extrapolating from GCCS to DCP
 Evolve from GCCS to DCP
 What are the Issues and Problems to Solve?
Status: Work in Progress at this Time
DSEC--179
Summary: Research Innovations

CSE5810
Unification of Mandatory Access Control (MAC)
and Role-based Access Control (RBAC) Features
 Realization of MAC: Bell and LaPadula Model
 Highly Flexible RBAC Capabilities
 Security Policy Realization
 Change Policy on the fly


Broad Use of Constraints: Fine-Grained Security
 User Constraints and Role Constraints
 Time Constraints and Signature Constraints
Security Assurance at Design and Run Times
 DT Checks as Security Policy is Defined
 RT Checks for Invocation/Delegation
DSEC--180
Summary: Additional Contributions

Working Prototype that can Administer Multiple
Security Policies Against Multiple Resources in a
Distributed Environment Supporting JINI/CORBA

A Well Defined Security Model which Supports
Security Policy Definition via Administrative and
Management Tools with Security Assurance:
 Security Policy Client (SPC)
 Security Authorization Client (SAC)
 Security Analysis Tool (SAT)
 Security Delegation Client (SDC)
CSE5810
DSEC--181
Summary: Remaining Research

CSE5810
Security Model that Unifies RBAC/MAC
 Finer Grained MAC
 Classification Levels on a Method’s Signature
 Investigate Time-Constrained Classification
User Constraints
 Role Deconfliction
Security Policy and Enforcement Assurance
 Detailing all Design and Run Time Checks
 Defining Security Assurance for Fine Grained
MAC and User Constraints
Completion of Analysis/Evaluation:
 Model/Framework vs. CMU Security Model
 Evaluation of Utility in Support of DCP



DSEC--182
Summary: Publications to Date

Initial Security Model

CSE5810


S. Demurjian, T. C. Ting, P. Barr, C. Phillips, “RoleBased Security in a Distributed Resource
Environment”, Proc. of 14th IFIP WG 11.3 Working
Conf. on Database Security, August 2000.
S. Demurjian, T.C. Ting, C. Phillips, et al., “A User
Role-Based Security Model for a Distributed
Environment”, in Research Advances in Database and
Information Systems Security, J. Therrien (ed.),
Kluwer, 2001.
Enhanced Security Model

C. Phillips, S. Demurjian, T.C. Ting, “Security
Engineering for Roles and Resources in a Distributed
Environment", Proc. of the 3rd Annual Information
Systems Security Engineering Conf., March 2002.
DSEC--183
Summary: Publications to Date

Relevance of Work for DCP

CSE5810

MAC Model Extensions and Security Assurance



C. Phillips, T.C. Ting, S. Demurjian, “Information
Sharing in Dynamic Coalitions”, Proc. of the 7th ACM
SACMAT 2002, June 2002.
C. Phillips, S. Demurjian, T.C. Ting, “Towards
Information Assurance for Dynamic Coalitions”, Proc.
of the 3rd IEEE Info. Assurance Workshop, June 2002.
C. Phillips, S. Demurjian, T.C. Ting, “Security
Assurance for an RBAC/MAC Security Model and
Enforcement Framework”, CSE Technical Report.
Role Delegation Extensions with Assurance

M. Liebrand, H. Ellis, C. Phillips, S. Demurjian, and
T.C. Ting, “Role Delegation for a Distributed, Unified
RBAC/MAC”, Proc. 16th IFIP WG 11.3 Conf. on
Data and Application Security, July 2002.
DSEC--184