DSEC--1 CSE333 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 (860)

DSEC--2 CSE333Motivation Legacy COTS GOTS Database NETWORK Java Client GOTS Client Legacy Client Database Client COTS Client  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)

DSEC--3 CSE333 Java Client User A Role X Authorize C1, C2 C3, C5 L1, L2 L: Legacy API: Methods L1 L2 L3 C: COTS API: Methods C1 C2 C3 C4 C5 Java Client User B Role Y Authorize C1, C4 L2, L3 Motivation API Access Based on Role/Classification  Can we Control Access Based on Role?  Can we Control Access to Based on Classification? (high T > S > C > U low) Java Client User A Role X Authorize Secret (S) L: Legacy API: Methods T: L1 C: L2 U: L3 C: COTS API: Methods T: C1 S: C2 S: C3 T: C4 C: C5 Java Client User B Role Y Authorize Confidential (C)

DSEC--4 CSE333 Java Client User A Role X Authorize C1: TI a C4: TI b L1: TI c L: Legacy API: Methods L1 L2 L3 C: COTS API: Methods C1 C2 C3 C4 C5 Java Client User B Role Y Authorize C2: TI d L1: TI e Motivation API Access Based on Time/Value  Can we Control Access Based on Time?  Can we Control Access Based on Data Values? Java Client User A Role X Authorize X.C1 (a < 30) X.C4 (d > 40) X.L1 (f = 10) L: Legacy API: Methods L1 (f) L2 (g) L3 (h) C: COTS API: Methods C1 (a) C2 (b) C3 (c) C4 (d) C5 (e) Java Client User B Role Y Authorize Y.C2 (0<b<99) Y. L1 (f = 100)

DSEC--5 CSE333 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

DSEC--6 CSE333 Problem Statement - Research Foci Unified RBAC/MAC Security Model Security Policy Definition Run Time Security Assurance Analyses of RBAC/MAC Model/Framework Against SSE-CMM Evaluation of RBAC/MAC Model Using DCP RBAC/MAC Enforcement Framework Security Administrative and Management Tools Design Time Security Assurance

DSEC--7 CSE333 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

DSEC--8 CSE333 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 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 CSE333 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

DSEC--10 CSE333 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

DSEC--11 CSE333 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

DSEC--12 CSE333 Security Enforcement Framework Software Architecture Wrapped Resource for Legacy Application Wrapped Resource for Database Application Lookup Service General Resource Wrapped Resource for COTS Application Java Client Legacy Client Database Client Software Agent COTS Client Lookup Service Security Authorization Client (SAC) Security Policy Client (SPC) Security Registration Services Unified Security Resource (USR) Security Policy Services Security Delegation Client (SDC) Security Analysis and Tracking (SAT) Security Authorization Services

DSEC--13 CSE333 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)

DSEC--14 CSE333  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  LT = [ct,  ] means current time (ct) onward Unified Security Model Definitions Lifetimes Concept

DSEC--15 CSE333 Concept of Containment of Lifetimes

DSEC--16 CSE333 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

DSEC--17 CSE333 Examples of Lifetimes

DSEC--18 CSE333 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

DSEC--19 CSE333  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 Unified Security Model Definitions MAC Concept

DSEC--20 CSE333 Unified Security Model Definitions Distributed 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

DSEC--21 CSE333 Unified Security Model Definitions Methods  Every Method of Service of Resource 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:  Default CLS is U  Default LT = [ct,  ]  Resource by Registering Sets CLS and LT

DSEC--22 CSE333 Unified Security Model Definitions Services  Definition 5: Every service is registered as: where  Note that LT and CLS are Inferred from LT and CLS of Methods that Comprise Service

DSEC--23 CSE333 Unified Security Model Definitions Resource  Definition 6: Every resource is registered as: where  Note that LT and CLS are Inferred from LT and CLS of Services that Comprise Resource

DSEC--24 CSE333 Clearances/Classifications Example (C) GCCS Resource C= min {Service CLSs} (S) Joint Service with Methods S = min{Method 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 = 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 CSE333 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

DSEC--26 CSE333 Unified Security Model Definitions User 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, UR LT, T] [JPlannerCR1, [01dec00, 01jun01], S] [CDR_CR1, UR LT, 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 CSE333 Unified Security Model Definitions Users 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 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 CSE333 Examples: Users, User-Roles, and URA

DSEC--29 CSE333 Related Work: RBAC  Benefits of RBAC  Flexible, Ease of Use, Policy Realization  [Bert97, Demu95, Ferr92, Nyan93, Sand96, Ting87]  Main Approaches  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 CSE333 Unified Security Model Definitions Signature Constraint  Definition 11: A Signature Constraint, SC, Boolean Expression Defined on the Signature of Method, M ijk of Service S ij of resource R i 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 CSE333 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  Example: ArmyBattleCommandSys (Token, CrisisNum); TC = [ 10dec00, 16feb01]

DSEC--32 CSE333 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

DSEC--33 CSE333 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

DSEC--34 CSE333 Unified Security Model Definitions User 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

DSEC--35 CSE333 Unified Security Model Definitions User Role Authorizations  Definition 15a : UR authorization matrix, URAM, is a matrix indexed by roles and methods: Notes:  Initially, URAM, contains all 0 entries  When equal to 1 for some authorization is a Valid URA (VURA)  At Design, UR CLS must dominate M CLS and there must be Overlap of LT/TC

DSEC--36 CSE333 Example Users, User Roles, and URAs ],

DSEC--37 CSE333 Unified Security Model Definitions Remaining Definitions  Definition 15b : A valid user-role authorization list, where  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

DSEC--38 CSE333 Unified Security Model Definitions Remaining Definitions  Definition 17a : User authorization matrix, UAM:  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 CSE333 Example UAM and URAM Matrices User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest DoGood DoRight CanDoRight Method\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 ArmyBattleCommamdSys CrisisPicture MarineCombatOpnsSys LogPlanningTool User Authorization Matrix (UAM) 1 = authorized, 0 = not User-Role Authorization Matrix (URAM): 1 = UR authorized to invoke Method, 0 = otherwise

DSEC--40 CSE333 Unified Security Model Definitions Remaining 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-Time] where Creation Time is Clock at Creation

DSEC--41 CSE333 Security Enforcement Framework Software Architecture Wrapped Resource for Legacy Application Wrapped Resource for Database Application Lookup Service General Resource Wrapped Resource for COTS Application Java Client Legacy Client Database Client Software Agent COTS Client Lookup Service Security Authorization Client (SAC) Security Policy Client (SPC) Global Clock Resource (GCR) Security Registration Services Unified Security Resource (USR) Security Policy Services Security Authorization Services Security Analysis and Tracking (SAT)

DSEC--42 CSE333 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)

DSEC--43 CSE333 Security Enforcement Framework Security Prototype (JINI and CORBA) Java GUI PDB Client JINI Lookup Service USR All Services Common Resource (Global Clock) CORBA Lookup Service Patient DB Resource (PDB) University DB Resource (UDB) Java GUI UDB Client Security Policy Client Security Authorization Client

DSEC--44 CSE333 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); Security Authorization Services Authorize Role Service Client Profile Service Security Registration Services Register Client Service Security Tracking and Analysis Services 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--45 CSE333 Security Enforcement Framework Security Policy Services Register Service Register_Resource(R_Id); Register_Service(R_Id, S_Id); 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 CSE333 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_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 CSE333 Security Authorization and Registration 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 Tracking Service: Logfile(Log String) Analysis Service: Analyze (Java Class File) SECURITY 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

DSEC--48 CSE333 Security Enforcement Framework Client, Resource, Service Invocations Security Authorization Services Security Registration Services Lookup Service GCCS Client 1 Register_Client(DoRight, , ArmyLogCR1) 10 Return Result of Check_Privileges(…) 4 Return Result,Create_Token(DoRight,ArmyLogCR1,Token) 6 CrisisPicture(Token,CR1, NA20, NC40) 3 Client OK? 11 Return Result,CrisisPicture(…) 5. Discover/Lookup(GCCS,Joint,CrisisPicture) Returns Proxy to Course Client 7 IsClient_Registered(Token) 9 Check_Privileges(Token, GCCS, Joint, CrisisPicture, [NA20,NC40]) 2 Verify_UR(DoRight,ArmyLogCR1) Security Policy Services GCCS Resource 8 Return Result of IsClient_Registered(…) USR

DSEC--49 CSE333 Security Prototype Global Clock Server/Client Logon

DSEC--50 CSE333 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

DSEC--51 CSE333 Security Policy Client Registering a Resource

DSEC--52 CSE333 Security Policy Client Registering a Service

DSEC--53 CSE333 Security Policy Client Registering Methods for Resource

DSEC--54 CSE333 Security Policy Client Registering Methods for Resource

DSEC--55 CSE333 Security Policy Client Adding Methods to Service

DSEC--56 CSE333 Security Policy Client Adding Methods to Service

DSEC--57 CSE333 Security Policy Client Confirmation of Registered Methods

DSEC--58 CSE333 Security Policy Client Tracking Defined Resources

DSEC--59 CSE333 Security Policy Client Creating User Role

DSEC--60 CSE333 Security Policy Client Creating User Role

DSEC--61 CSE333 Security Policy Client Granting Resource to UR

DSEC--62 CSE333 Security Policy Client Granting Service to UR

DSEC--63 CSE333 Security Policy Client Granting Method to UR

DSEC--64 CSE333 Security Policy Client Confirmation of Method to Role

DSEC--65 CSE333 Security Policy Client Reviewing Access of Resources to Roles

DSEC--66 CSE333 Security Policy Client Defining a Signature Constraint

DSEC--67 CSE333 Security Policy Client Defining a Signature Constraint

DSEC--68 CSE333 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

DSEC--69 CSE333 Security Authorization Client Creating a User

DSEC--70 CSE333 Security Authorization Client Granting Roles to User

DSEC--71 CSE333 Security Prototype Tracking Logins and Actions

DSEC--72 CSE333 Security Prototype Tracking Methods of Resources

DSEC--73 CSE333 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  Enumerated and Defined to  Security Assurance is Enumerated and Defined to:  Insure Policy Consistency (A & M Tools)  Check Conditions as Users Access Resources

DSEC--74 CSE333 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

DSEC--75 CSE333 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

DSEC--76 CSE333 The Compare Function for Two LTs

DSEC--77 CSE333 Time-Based Guarantees

DSEC--78 CSE333 Time-Based Guarantees

DSEC--79 CSE333 Lemma 1 Conceptually

DSEC--80 CSE333 Time-Based Guarantees

DSEC--81 CSE333 Lemma 2 Conceptually

DSEC--82 CSE333 Time-Based Guarantees

DSEC--83 CSE333 Lemma 3 Conceptually

DSEC--84 CSE333 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)

DSEC--85 CSE333 MAC-Based Guarantees

DSEC--86 CSE333 MAC-Based Guarantees

DSEC--87 CSE333 MAC-Based Guarantees

DSEC--88 CSE333 MAC-Based Guarantees

DSEC--89 CSE333 MAC-Based Guarantees

DSEC--90 CSE333  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 Safety and Liveness Guarantees

DSEC--91 CSE333 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

DSEC--92 CSE333   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 Security Assurance - Design Time Rule I: Authorizing Method to UR

DSEC--93 CSE333  LTs and TCs must be Contrasted Security Assurance - Design Time Rule I Conceptually ct A.LTM.LTTC A.LT M.LT TC

DSEC--94 CSE333   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 Security Assurance - Design Time Rule II: Authorizing UR to User

DSEC--95 CSE333  LTs and TCs Again Constrained Security Assurance - Design Time Rule II Conceptually ct A.LT X.LT TC A.LT X.LT TC

DSEC--96 CSE333   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. Security Assurance - Runtime Rule III: Authorizing UR to User

DSEC--97 CSE333  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 Security Assurance - Runtime Rule III Conceptually ct TC ct TC

DSEC--98 CSE333   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. Security Assurance - Runtime Rule IV: Invoking a Method

DSEC--99 CSE333 Security Assurance - Runtime Rule 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 < NA20 and Grid2 < NC40 Call: CrisisPicture (123, 111, NA18, NC45); Compare Call Against SC to Determine if Can Invoke

DSEC--100 CSE333 Safety and Liveness Theorems

DSEC--101 CSE333 Safety and Liveness Theorems

DSEC--102 CSE333 Safety and Liveness Theorems

DSEC--103 CSE333 Safety and Liveness Theorems

DSEC--104 CSE333 Related Work Security 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]

DSEC--105 CSE333 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  Rensselaer at Hartford)  Work of M. Liebrand ( Rensselaer at Hartford)

DSEC--106 CSE333 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?

DSEC--107 CSE333 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

DSEC--108 CSE333 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

DSEC--109 CSE333 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], T] [JPlannerCR1, [01dec00, 01jun01], S] [JPlannerCR2, [01jul01, 01sep01], C]  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--110 CSE333 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

DSEC--111 CSE333 Examples of OUs DUs 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

DSEC--112 CSE333 Role Delegation Extensions  Definition 23: User delegation/authorization matrix, UDAM: 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--113 CSE333 Delegation and Pass on Delegation Authorities  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--114 CSE333 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, DAM: DU has Neither DA Nor PODA DU has Just DA DU has Both DA and PODA

DSEC--115 CSE333 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 User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest DoGood DoRight CanDoRight Delegation Authority Matrix (DAM): 2 = has DA and PODA, 1 = has DA, 0 = neither

DSEC--116 CSE333 Recall UAM and URAM Matrices User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest DoGood DoRight CanDoRight Method\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 ArmyBattleCommamdSys CrisisPicture MarineCombatOpnsSys LogPlanningTool User Authorization Matrix (UAM) 1 = authorized, 0 = not User-Role Authorization Matrix (URAM): 1 = UR authorized to invoke Method, 0 = otherwise

DSEC--117 CSE333 Augment with DAM and UDAM Matrices User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest DoGood DoRight CanDoRight Delegation Authority Matrix (DAM): 2 = has DA and PODA, 1 = has DA, 0 = neither User\User-RoleArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest DoGood DoRight CanDoRight User Delegation/Authorization Matrix (UDAM): 2 = U is a DU, 1 = U is a OU, and 0 = not authorized

DSEC--118 CSE333 Example - Role Delegation   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--119 CSE333 Example - Role Delegation  Now, Colonel DoGood wishes to re-delegate CDR_CR1 to Major CanDoRight, which can be defined as:  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--120 CSE333 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 Zhang’s Definitions to Include  Delegation Authority, Revocation Authority, Delegated Role, and Delegatable Role

DSEC--121 CSE333 Enforcement Framework and Role 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).

DSEC--122 CSE333 Enforcement Framework and Role 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.

DSEC--123 CSE333 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   We’ll Define and Discuss Each

DSEC--124 CSE333 Analysis of Role Delegation Monotonicity   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--125 CSE333 Analysis of Role Delegation Permanence  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--126 CSE333 Analysis of Role Delegation Totality  Definition:  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--127 CSE333 Analysis of Role Delegation Administration  Definition:  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

DSEC--128 CSE333 Analysis of Role Delegation Levels of Delegation  Definition:  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--129 CSE333 Analysis of Role Delegation Multiple Delegations  Definition:  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--130 CSE333 Analysis of Role Delegation Agreements  Definition:  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--131 CSE333 Analysis of Role Delegation Cascading Revocation  Definition:  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--132 CSE333 Analysis of Role Delegation Grant Dependency Revocation  Definition:  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

DSEC--133 CSE333 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

DSEC--134 CSE333 Security Policy Client Registration of Resources

DSEC--135 CSE333 Security Policy Client Creation of Administration Role

DSEC--136 CSE333 Security Authorization Client Granting of Role(s) to User(s)

DSEC--137 CSE333 Security Policy Client Cdr. Crisis 1 Role/Conflicting Role List

DSEC--138 CSE333 Security Policy Client Granting of Resource(s) to Role(s)

DSEC--139 CSE333 Security Policy Client Granting of Service (s) to Role(s)

DSEC--140 CSE333 Security Policy Client Granting of Methods(s) to Role(s)

DSEC--141 CSE333 Security Policy Client Query Privileges

DSEC--142 CSE333 Security Authorization Client Create a User

DSEC--143 CSE333 Security Authorization Client Create a User

DSEC--144 CSE333 Security Authorization Client Granting a Role

DSEC--145 CSE333 Security Authorization Client Granting a Role with DA/PODA

DSEC--146 CSE333 Security Authorization Client Granting a Role with DA/PODA

DSEC--147 CSE333 Security Authorization Client Query Privileges

DSEC--148 CSE333 Security Authorization Client Query Privileges - Results

DSEC--149 CSE333 The Security Delegation Client

DSEC--150 CSE333 Security Delegation Client Log on to the Security Delegation Client

DSEC--151 CSE333 Security Delegation Client Attempt to Perform a Delegation

DSEC--152 CSE333 Security Delegation Client Attempt to Perform a Delegation

DSEC--153 CSE333 Security Delegation Client Query a User’s Role

DSEC--154 CSE333 Security Delegation Client Revocation of Delegation

DSEC--155 CSE333 Security Delegation Client Revocation of Delegation

DSEC--156 CSE333 Security Delegation Client Denying Log in if UR not Available

DSEC--157 CSE333 Security Delegation Client Denying Delegation if MAC Violated

DSEC--158 CSE333 Security Delegation Client Denying Delegation if TC Violated

DSEC--159 CSE333 Security Delegation Client Denying Delegation if no Delegatable Roles

DSEC--160 CSE333 Security Delegation Client Pass on Delegation Restriction

DSEC--161 CSE333 Security Delegation Client Example 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--162 CSE333 Security Delegation Client Delegation Matrix within SDC Dobest(T): ArmyLogCR1(c) Chip(T): ArmyLogCR1(c) Dogood(S): ArmyLogCR1 ( C) Doright(c ): ArmyLogCR1 ( C) When Original user revoke This role, the role matrix is revoked within SDC

DSEC--163 CSE333 Security Delegation Client Example Dobest delegate a role to dogood Dogood delegate this role to other users

DSEC--164 CSE333 Security Delegation Client Example Dobest revokes the role delegated to dogood The role delegated by dogood are erased at the same time.

DSEC--165 CSE333 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  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--166 CSE333 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, OU’s Delegations are revoked, Including Passed On Delegations  These are Checks by the Enforcement Framework as supported with USR

DSEC--167 CSE333   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. Security Assurance - Design time Rule V: Assigning Delegation Authority

DSEC--168 CSE333 Theorem V

DSEC--169 CSE333   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. Security Assurance - Design time Rule VI: DA and PODA

DSEC--170 CSE333   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 Security Assurance - Design time Rule VII: Delegation of UR

DSEC--171 CSE333   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. Security Assurance - Design time Rule VIII: Delegation of DA/PODA

DSEC--172 CSE333 Theorem VI, VII, and VIII

DSEC--173 CSE333 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?

DSEC--174 CSE333 Analysis vs. SSE-CMM What is SSE-CMM?  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--175 CSE333 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

DSEC--176 CSE333 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

DSEC--177 CSE333 10/24/96 Domain Process Areas Base Practices Base Practices Process Areas Base Practices Base Practices Analysis vs. SSE-CMM SSE-CMM Model Architecture Process Areas Organization Project Security Engineering Process Areas Domain  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

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

DSEC--179 CSE333 Evaluation vs. DCP Suitability 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

DSEC--180 CSE333 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

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

DSEC--182 CSE333 Summary: Remaining Research  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--183 CSE333 Summary: Publications to Date   Initial Security Model  S. Demurjian, T. C. Ting, P. Barr, C. Phillips, “Role- Based Security in a Distributed Resource Environment”, Proc. of 14th IFIP WG 11.3 Working Conf. on Database Security, August  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,   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--184 CSE333 Summary: Publications to Date   Relevance of Work for DCP  C. Phillips, T.C. Ting, S. Demurjian, “Information Sharing in Dynamic Coalitions”, Proc. of the 7th ACM SACMAT 2002, June   MAC Model Extensions and Security Assurance  C. Phillips, S. Demurjian, T.C. Ting, “Towards Information Assurance for Dynamic Coalitions”, Proc. of the 3rd IEEE Info. Assurance Workshop, June  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.