A Security Model/Enforcement Framework with Assurance for a Distributed Environment

1
A Security Model/Enforcement Framework with
Assurance for a Distributed Environment
C. Phillips, S. Demurjian, and T.C. Ting Computer
Science Engineering Department The University
of Connecticut Storrs, Connecticut 06269-3155
Charles.Phillips_at_usma.edu steve,ting_at_engr.uconn.
edu http//www.engr.uconn.edu/steve (860) 486 -
4818
2
Motivation

• Premise Artifacts - set of
• DB, Legacy, COTS, GOTS, Each w/ API
• Premise Users
• New and Existing
• Utilize Artifact APIs
• Distributed Application, DA
• Artifacts Users
• Can we Control User Access to Artifact APIs
  (Methods) by
• Role (who)
• Classification (MAC)
• Time (when)
• Data (what)

Database
COTS
Legacy
Legacy Client
GOTS
NETWORK
GOTS Client
Legacy
Database
Database Client
COTS Client
3
Motivation API Access Based on
Role/Classification

• Can we Control Access
• Based on Role?

• Can we Control Access to Based on
  Classification?
• (high T gt S gt C gt U low)

4
Motivation API Access Based on Time/Value

• Can we Control Access Based on Time?

• Can we Control Access Based on Data Values?

5
Overview of Remainder of Talk

• 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

6
Problem Statement - Research Foci
Security Policy Definition
Design Time Security Assurance
Run Time Security Assurance
Unified RBAC/MAC Security Model
Analyses of RBAC/MAC Model/Framework Against
SSE-CMM
Evaluation of RBAC/MAC Model Using DCP
7
Research Goals and Objectives

• 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

8
Research Goals and Objectives

• 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 CMUs 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

9
Relevance/Importance of Research

• 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

10
Distributed Environment Assumptions

• 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

11
Global Command and Control System (GCCS)
Resource/Service/Methods
GCCS Resource with Two Services Joint Service
with Methods a.k.a Weather
(Token) METOC VideoTeleconference
(Token, fromOrg, toOrg) TLCF
JointOperationsPlannning (Token,
CrisisNum) JOPES CrisisPicture (Token,
CrisisNum, Grid1, Grid2) COP
TransportationFlow (Token) JFAST
LogisticsPlanningTool (Token, CrisisNum)
LOGSAFE DefenseMessageSystem
(Token) DMS NATOMessageSystem
(Token) CRONOS Component Service with
Methods ArmyBattleCommandSys (Token,
CrisisNum) ABCS AirForceBattleManagementSys
(Token, CrisisNum) TBMCS
MarineCombatOpnsSys (Token, CrisisNum) TCO
NavyCommandSystem (Token, CrisisNum) JMCIS
12
Security Enforcement Framework Software
Architecture
Database
Client
Java
Client
Software
Agent
Legacy
Client
13
Security Enforcement Framework

• 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)

14
Unified Security Model DefinitionsLifetimes
Concept

• Definition 1 A lifetime, LT, is a Discrete Time
  Interval LT.st, LT.et with LT.et gt 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
• LT ct, ? means current time (ct) onward

15
Concept of Containment of Lifetimes
16
Usage of Lifetimes

• 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

17
Examples of Lifetimes
18
Related Work Lifetimes

• 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

19
Unified Security Model DefinitionsMAC Concept

• 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 lt C lt S lt 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

20
Unified Security Model DefinitionsDistributed
Application

• 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
• Uniquely Identifies Each
  Method

21
Unified Security Model DefinitionsMethods

• Every Method of Service of ResourceMust 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
• Default CLS is U
• Default LT ct, ?
• Resource by Registering Sets CLS and LT

22
Unified Security Model DefinitionsServices

• Definition 5 Every service is registered
  aswhere
• Note that LT and CLS are Inferred from LT and CLS
  of Methods that Comprise Service

23
Unified Security Model DefinitionsResource

• Definition 6 Every resource is registered as
  where
• Note that LT and CLS are Inferred from LT and CLS
  of Services that Comprise Resource

24
Clearances/ClassificationsExample
(C) GCCS Resource C min Service CLSs (S)
Joint Service with Methods S minMethod
CLSs a.k.a (S)Weather (Token) METOC
(S)VideoTeleconference (Token, fromOrg,
toOrg) TLCF (S)JointOperationsPlannning
(Token, CrisisNum) JOPES (S)CrisisPicture
(Token, CrisisNum, Grid1, Grid2) COP
(S)TransportationFlow (Token) JFAST
(S)LogisticsPlanningTool (Token, CrisisNum)
LOGSAFE (S)DefenseMessageSystem
(Token) DMS (T)NATOMessageSystem
(Token) CRONOS (C) Component Service with
Methods C minMethod 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.
25
Related Work Clearances/Classifications

• 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

26
Unified Security Model DefinitionsUser Roles and
UR List

• Definition 7 A user role, UR, representing a set
  of responsibilities for an application, is
  defined as
• 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.

27
Unified Security Model DefinitionsUsers and User
List

• Definition 9 A user, U, who will be accessing
  the DAPPL via a client application, is defined
  as
• Notes
• LT and CLS is Set by Security Officer
• Defaults are ct, ? and U Respectively
• Example UsersGeneral DoBest DoBest, 1 year,
  TColonel DoGood DoGood, 6 mo., S
• Definition 10 A user list, UL is the set of u
  users that have been defined for DAPPL.

28
Examples Users, User-Roles, and URA
29
Related Work RBAC

• Benefits of RBAC
• Flexible, Ease of Use, Policy Realization
• Bert97, Demu95, Ferr92, Nyan93, Sand96, Ting87
• Main Approaches
• UConn - Demu9401, 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

30
Unified Security Model Definitions Signature
Constraint

• 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
• ExampleCrisisPicture (Token, CrisisNum, Grid1,
  Grid2)SC Grid1 lt NA20 and Grid2 lt NC40

31
Unified Security Model Definitions Time Constraint

• 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
• ExampleArmyBattleCommandSys (Token,
  CrisisNum)TC 10dec00, 16feb01

32
Related Work Signature and Time Constraints

• 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

33
Unified Security Model Definitions Mandatory
Access Control Constraint

• 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

34
Unified Security Model DefinitionsUser Role
Authorizations

• 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
  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

35
Unified Security Model DefinitionsUser Role
Authorizations

• Definition 15a UR authorization matrix, URAM,is
  a matrix indexed by roles and
  methodsNotes
• Initially, URAM, contains all 0 entries
• When equal to 1 for someauthorization is a Valid
  URA (VURA)
• At Design, UR CLS must dominate M CLS and there
  must be Overlap of LT/TC

36
Example Users, User Roles, and URAs
,
37
Unified Security Model DefinitionsRemaining
Definitions

• Definition 15b A valid user-role authorization
  list, where 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 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

38
Unified Security Model DefinitionsRemaining
Definitions

• Definition 17a User authorization matrix, UAM
• Notes
• Initially, UAM, contains all 0 entries
• When equal to 1 for someAuthorization is a Valid
  UA (VUA)
• At Design Time, a Us CLR must dominate a Roles
  CLS with overlap of TC and LT

39
Example UAM and URAM Matrices
User Authorization Matrix (UAM) 1 authorized, 0
not
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
User-Role Authorization Matrix (URAM) 1 UR
authorized to invoke Method, 0 otherwise
Method\User-Role ArmyLogCR1 ArmyLogCR2
JPlannerCR1 JPlannerCR2 CDR_CR1 ArmyBattleCommam
dSys 1 1 1 1
1 CrisisPicture 1 1 1
1 1 MarineCombatOpnsSys 0
0 1 1 1 LogPlanningTool
1 1 0 0 1
40
Unified Security Model DefinitionsRemaining
Definitions

• Definition 17b A valid user authorization list,
  where 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-Timewhere
  Creation Time is Clock at Creation

41
Security Enforcement Framework Software
Architecture
Database
Client
Java
Client
Software
Agent
Legacy
Client
42
Security Enforcement Framework

• 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)

43
Security Enforcement Framework Security
Prototype (JINI and CORBA)
Java GUI PDB Client
Common Resource (Global Clock)
Java GUI UDB Client
Patient DB Resource (PDB)
University DB Resource (UDB)
JINI Lookup Service
CORBA Lookup Service
USR All Services
Security Policy Client
Security Authorization Client
44
Security Enforcement Framework USR Services
Security Policy Services Register Service Query
Privileges Service 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
45
Security Enforcement Framework Security Policy
Services
Register Service Register_Resource(R_Id)
Register_Service(R_Id, S_Id) Register_Method(R_I
d, S_Id, M_Id) Register_Signature(R_Id, S_Id,
M_Id, Signat) UnRegister_Resource(R_Id) UnRegist
er_Service(R_Id, S_Id) UnRegister_Method(R_Id,
S_Id, M_Id) Unregister_Token(Token) Query
Privileges Service Query_AvailResource() Query_Av
ailMethod(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_Rol
e(UR_Name, UR_Disc, UR_Id) Delete_Role(UR_Id)
46
Security Enforcement Framework Security Policy
Services
Constraint Service DefineTC(R_Id, S_Id, M_Id,
SC) DefineSC(R_Id, S_Id, M_Id,
SC)CheckTC(Token, R_Id, S_Id, M_ID)
CheckSC(Token, R_Id, S_Id, M_ID,
ParamValueList) Grant-Revoke Service Grant_Resou
rce(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)
47
Security Authorization and Registration Services
Authorize Role Service 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(Us
er_Id, IP_Addr) Security Tracking and Analysis
Services Tracking Service Logfile(Log
String) Analysis Service Analyze (Java Class
File)
SECURITY REGISTRATION SERVICES
48
Security Enforcement Framework Client, Resource,
Service Invocations
GCCS Client
Security Registration Services
USR
Security Authorization Services
Lookup Service
9 Check_Privileges(Token, GCCS, Joint,
CrisisPicture, NA20,NC40)
Security Policy Services
GCCS Resource
10 Return Result of Check_Privileges()
49
Security PrototypeGlobal Clock Server/Client
Logon
50
The Security Policy Client

• 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

51
Security Policy ClientRegistering a Resource
52
Security Policy ClientRegistering a Service
53
Security Policy ClientRegistering Methods for
Resource
54
Security Policy Client Registering Methods for
Resource
55
Security Policy ClientAdding Methods to Service
56
Security Policy ClientAdding Methods to Service
57
Security Policy Client Confirmation of Registered
Methods
58
Security Policy Client Tracking Defined
Resources
59
Security Policy Client Creating User Role
60
Security Policy Client Creating User Role
61
Security Policy Client Granting Resource to UR
62
Security Policy Client Granting Service to UR
63
Security Policy Client Granting Method to UR
64
Security Policy ClientConfirmation of Method to
Role
65
Security Policy ClientReviewing Access of
Resources to Roles
66
Security Policy Client Defining a Signature
Constraint
67
Security Policy Client Defining a Signature
Constraint
68
The Security Authorization Client

• 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

69
Security Authorization Client Creating a User
70
Security Authorization Client Granting Roles to
User
71
Security PrototypeTracking Logins and Actions
72
Security PrototypeTracking Methods of Resources
73
Security Assurance

• 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

74
Assurance Guarantees

• 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

75
Available Time

• 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

76
The Compare Function for Two LTs
77
Time-Based Guarantees
78
Time-Based Guarantees
79
Lemma 1 Conceptually
80
Time-Based Guarantees
81
Lemma 2 Conceptually
82
Time-Based Guarantees
83
Lemma 3 Conceptually
84
MAC-Based Guarantees

• 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)

85
MAC-Based Guarantees
86
MAC-Based Guarantees
87
MAC-Based Guarantees
88
MAC-Based Guarantees
89
MAC-Based Guarantees
90
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

91
Security Assurance Rules

• 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

92
Security Assurance - Design TimeRule 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

93
Security Assurance - Design TimeRule I
Conceptually

• LTs and TCs must be Contrasted

ct
A.LT
M.LT
TC
TC
M.LT
A.LT
94
Security Assurance - Design TimeRule 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

95
Security Assurance - Design TimeRule II
Conceptually

• LTs and TCs Again Constrained

ct
TC
X.LT
A.LT
TC
X.LT
A.LT
96
Security Assurance - RuntimeRule 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.

97
Security Assurance - RuntimeRule III Conceptually

• 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
ct
TC
TC
98
Security Assurance - RuntimeRule IV Invoking a
Method

• N(Name), P(Params), APV(Actual Param Values)
• SCOracle is a Constraint Checker that Compares
  Parameter Values of Ms Invocation against SC
• returns true if M.parametervalues satisfy SC
• returns false otherwise.

99
Security Assurance - RuntimeRule IV Conceptually

• 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 lt NA20 and Grid2 lt NC40 Call
CrisisPicture (123, 111, NA18, NC45) Compare
Call Against SC to Determine if Can Invoke
100
Safety and Liveness Theorems
101
Safety and Liveness Theorems
102
Safety and Liveness Theorems
103
Safety and Liveness Theorems
104
Related WorkSecurity Assurance

• 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

105
What is Role Delegation?

• 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)

106
Why is Role Delegation Important?

• 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?

107
What Can be Delegated?

• 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

108
Our Focus for Delegation

• 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

109
Role Delegation Extensions

• 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
• Delegatable URs (from Slide 33) CDR_CR1,
  01dec00,01dec01, TJPlannerCR1, 01dec00,
  01jun01, SJPlannerCR2, 01jul01, 01sep01,
  CDURV(A) 1 for A CDR_CR1, JPlannerCR1 and
  JPlannerCR2DURV(A) 0 for A ArmyLogCR1 and
  ArmyLogCR2

110
Role Delegation Extensions

• 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

111
Examples of OUs
DUs

• 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

112
Role Delegation Extensions

• Definition 23 User delegation/authorization
  matrix, UDAMRepresents 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

113
Delegation and Pass on Delegation Authorities

• When Establishing Privileges (by the Security
  Officer) there must be the Ability to Define
• Delegation Authority (DA)
• RecallSecurity 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

114
Role Delegation Extensions

• 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,
  DAMDU has Neither DA Nor PODADU has Just
  DADU has Both DA and PODA

115
Example of DA and PODA

• JPlanner1 DoGood has DA
• JPlanner2 DoGood has DA
• CDR_CR1 DoBest has both DA and PODA
• All Other Entries have Neither DA Nor PODA

116
Recall UAM and URAM Matrices
User Authorization Matrix (UAM) 1 authorized, 0
not
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
User-Role Authorization Matrix (URAM) 1 UR
authorized to invoke Method, 0 otherwise
Method\User-Role ArmyLogCR1 ArmyLogCR2
JPlannerCR1 JPlannerCR2 CDR_CR1 ArmyBattleCommam
dSys 1 1 1 1
1 CrisisPicture 1 1 1
1 1 MarineCombatOpnsSys 0
0 1 1 1 LogPlanningTool
1 1 0 0 1
117
Augment with DAM and UDAM Matrices
118
Example - Role Delegation

• General DoBest Delegates his Role to Colonel
  DoGood with DA, where DoBest, CDR_CR1, and DoGood
  defined asOU DoBest, ct, ?, TUR
  CDR_CR1, 01dec00, 01dec01, TUA DoBest,
  CDR_CR1, 01dec00, 01dec01DA YesPODA Yes
• After DelegationDU DoGood, 01dec00,
  01jun01, TUA DoGood, CDR_CR1, 01dec00,
  01jun01

119
Example - Role Delegation

• Now, Colonel DoGood wishes to re-delegate
  CDR_CR1 to Major CanDoRight, which can be defined
  asDU DoGood, 01dec00, 01jun01, TUR
  CDR_CR1, 01dec00, 01dec01, TUA DoGood,
  CDR_CR1, 01dec00, 01jun01DA YesPODA No
• After DelegationDU CanDoRight, 01jan01,
  01feb01, TUA CanDoRight, CDR_CR1, 01dec00,
  01jun01

120
Related Work Role Delegation

• 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 Zhangs Definitions to Include
• Delegation Authority, Revocation Authority,
  Delegated Role, and Delegatable Role

121
Enforcement Framework andRole Delegation
Revocation Rules

• 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).

122
Enforcement Framework andRole Delegation
Revocation Rules

• 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.

123
Analysis of Role Delegation

• Analysis of Role Delegation Against Set of Common
  Criteria
• Monotonicity
• Permanence
• Totality
• Administration
• Levels of Delegation
• Multiple Delegation
• Agreements
• Cascading Revocation
• Grant-dependency Revocation
• Well Define and Discuss Each

124
Analysis of Role DelegationMonotonicity

• 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

125
Analysis of Role DelegationPermanence

• 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

126
Analysis of Role DelegationTotality

• 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

127
Analysis of Role DelegationAdministration

• Definition Administration Refers to how
  Delegation will be Administered
• User Directed is when the User Controls all
  Aspects of Delegation
• Administrator-Directed (Third party,
  Agent-directed) 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

128
Analysis of Role DelegationLevels of Delegation

• 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

129
Analysis of Role DelegationMultiple Delegations

• 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
  Users 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

130
Analysis of Role DelegationAgreements

• 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

131
Analysis of Role DelegationCascading Revocation

• Definition Cascading Revocation Refers to the
  Indirect Revocation of All DUs When the OU
  Revokes Delegation or Administration Revokes the
  OUs 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)

132
Analysis of Role DelegationGrant Dependency
Revocation

• 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
  Grant-independent Revocation Where Only the DU
  and the Security Administrator Can Revoke a DUR

133
Role Delegation Process Security Management Tools

• 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

134
Security Policy ClientRegistration of Resources
135
Security Policy Client Creation of
Administration Role
136
Security Authorization ClientGranting of Role(s)
to User(s)
137
Security Policy Client Cdr. Crisis 1
Role/Conflicting Role List
138
Security Policy Client Granting of Resource(s)
to Role(s)
139
Security Policy Client Granting of Service (s)
to Role(s)
140
Security Policy Client Granting of Methods(s) to
Role(s)
141
Security Policy Client Query Privileges
142
Security Authorization ClientCreate a User
143
Security Authorization Client Create a User
144
Security Authorization Client Granting a Role
145
Security Authorization Client Granting a Role
with DA/PODA
146
Security Authorization Client Granting a Role
with DA/PODA
147
Security Authorization Client Query Privileges
148
Security Authorization Client Query Privileges -
Results
149
The Security Delegation Client
150
Security Delegation Client Log on to the
Security Delegation Client
151
Security Delegation ClientAttempt to Perform a
Delegation
152
Security Delegation ClientAttempt to Perform a
Delegation
153
Security Delegation ClientQuery a Users Role
154
Security Delegation ClientRevocation of
Delegation
155
Security Delegation ClientRevocation of
Delegation
156
Security Delegation ClientDenying Log in if UR
not Available
157
Security Delegation ClientDenying Delegation if
MAC Violated
158
Security Delegation ClientDenying Delegation if
TC Violated
159
Security Delegation ClientDenying Delegation if
no Delegatable Roles
160
Security Delegation ClientPass on Delegation
Restriction
161
Security Delegation ClientExample
Dobest delegate a role to dogood without
pass-on-delegation, when dogood delegated this
role to doright, he cant delegate it with
pass-on-delegation
162
Security Delegation ClientDelegation Matrix
within SDC
Dobest(T) ArmyLogCR1(c)
When Original user revoke This role, the role
matrix is revoked within SDC
Dogood(S) ArmyLogCR1 ( C)
Chip(T) ArmyLogCR1(c)
Doright(c ) ArmyLogCR1 ( C)
163
Security Delegation ClientExample
Dogood delegate this role to other users
Dobest delegate a role to dogood
164
Security Delegation ClientExample
Dobest revokes the role delegated to dogood
The role delegated by dogood are erased at the
same time.
165
Design Time Security Assurance for Delegation

• 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
• DUs LT Must be Within OUs 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

166
Run Time Security Assurance for Delegation

• 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, OUs Delegations are
  revoked, Including Passed On Delegations
• These are Checks by the Enforcement Framework as
  supported with USR

167
Security Assurance - Design timeRule V
Assigning Delegation Authority

• 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.

168
Theorem V
169
Security Assurance - Design timeRule 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.

170
Security Assurance - Design timeRule 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

171
Security Assurance - Design timeRule 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.

172
Theorem VI, VII, and VIII
173
Assessment of RBAC/MAC Model/Framework

• 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?

174
Analysis vs. SSE-CMM What is SSE-CMM?

• An ISO Standard Model For Capturing the Essential
  Characteristics of an Organizations 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

175
Analysis vs. SSE-CMM Why was SSE-CMM Developed?

• 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

176
Analysis vs. SSE-CMM SSE-CMM Engineering Process
Areas

• 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

177
Analysis vs. SSE-CMM SSE-CMM Model Architecture

• Compare and Contrast RBAC/MAC Model and Framework
  w/Standard
• SSE-CMM 11 Process Areas/61 Base Practices
• PA01 Administer Security Controls
• Base Practice 01 Establish Responsibilities and
  Accountability for Security Controls
• Base Practice 02 Manage the Configuration of
  Security System Controls
• Work in Progress

Domain
Domain
Organization
Project
Process Areas
Security Engineering
Process Areas
Process Areas

Process Areas


Base Practices
Base Practices
Base Practices
Base Practices
10/24/96
178
Evaluation vs. DCP What is DCP?
Dynamic Coalition
Navy
Air Force
NGO/ PVO
Joint Command System
Battle Management System
U.N.
GCCS
U.S.A
NATO
Army Battle Command System
Combat Operations System
Marine Corps
Army
Army C2
U.S. Global C2 Systems
AFATDS
FADD
ASAS
GCCS-A
ABCS
Dynamic Coalition Problem (DCP) are Inherent
Security, Resource, and/or Information Sharing
Risks that Occur as a Result of the Coalition
being Formed Quickly
CSSCS
MCS
Other
179
Evaluation vs. DCPSuitability of Our Approach
for DCP

• Detailed Evaluation of DCP w.r.t. Security Model
• 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

180
Summary Research Innovations

• 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

181
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)

182
Summary Remaining Research

• Security Model that Unifies RBAC/MAC
• Finer Grained MAC
• Classification Levels on a Methods 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

183
Summary Publications to Date

• Initial Security Model
• S. Demurjian, T. C. Ting, P. Barr, C. Phillips,
  Role-Based Security in a Distributed