1 / 184

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

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@usma.edu {steve,ting}@engr.uconn.edu

keena
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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@usma.edu {steve,ting}@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

  2. 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) Motivation Java Client Database COTS Legacy Legacy Client GOTS NETWORK GOTS Client Legacy Database Database Client COTS Client

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

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

  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 Administrative and Management Tools RBAC/MAC Enforcement Framework 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 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

  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 Security Policy Client (SPC) Wrapped Wrapped General Lookup Resource Resource COTS Resource for Database for COTS Service Client Application Security Authorization Client (SAC) Security Delegation Client (SDC) Application Wrapped Resource for Legacy Application Lookup Service Unified Security Resource (USR) Security Policy Services Security Authorization Services Security Registration Services Security Analysis and Tracking (SAT) 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 Clientto Grant/Revoke Privileges (TCs, methods, SCs)/set CLS/CLR • Security Authorization Clientto 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 > 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 < C < S < T • Clearance (CLR) is SLEVEL given to users • Classification (CLS) isthe 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/systemResources (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 as:where • 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 = 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.

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

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

  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 • Example:CrisisPicture (Token, CrisisNum, Grid1, Grid2);SC: Grid1 < NA20 and Grid2 < 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 • Example:ArmyBattleCommandSys (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 amatrix indexed by roles and methods:Notes: • 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 U’s CLR must dominate a Role’s CLS with overlap of TC and LT

  39. Example UAM and URAM Matrices User Authorization Matrix (UAM) 1 = authorized, 0 = not User\User-RoleArmyLogCR1ArmyLogCR2JPlannerCR1JPlannerCR2CDR_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-RoleArmyLogCR1ArmyLogCR2JPlannerCR1JPlannerCR2CDR_CR1 ArmyBattleCommamdSys 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 tokenC = [U, UR, IP-Address, Client-Creation-Time]where Creation Time is Clock at Creation

  41. Security Enforcement Framework Software Architecture Global Clock Resource (GCR) Security Policy Client (SPC) Wrapped Wrapped General Lookup Resource Resource COTS Resource for Database for COTS Service Client Application Security Authorization Client (SAC) Application Wrapped Resource for Legacy Application Lookup Service Unified Security Resource (USR) Security Policy Services Security Authorization Services Security Registration Services Security Analysis and Tracking (SAT) 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 Clientto Grant/Revoke Privileges (TCs, methods, SCs)/set CLS/CLR • Security Authorization Clientto 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) CORBA Lookup Service JINI 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_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);

  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_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);

  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(User_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 1 Register_Client(DoRight,100.150.200.250, ArmyLogCR1) 2 Verify_UR(DoRight,ArmyLogCR1) 3 Client OK? 4 Return Result,Create_Token(DoRight,ArmyLogCR1,Token) 6 CrisisPicture(Token,CR1, NA20, NC40) 5. Discover/Lookup(GCCS,Joint,CrisisPicture) Returns Proxy to Course Client 11 Return Result,CrisisPicture(…) 7 IsClient_Registered(Token) 8 Return Result of IsClient_Registered(…) GCCS Client Security Registration Services USR Lookup Service Security Authorization Services 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

More Related