ISSEA Security Engineering for Roles and Resources in a Distributed Environment Security Engineering for Roles and Resources in a Distributed Environment Profs. Steven A. Demurjian and T.C. Ting Computer Science & Engineering Department 191 Auditorium Road, Box U-155 The University of Connecticut Storrs, Connecticut Lt.Col. Charles E. Phillips, Jr. Computer Science & Engineering Department 191 Auditorium Road, Box U-155 The University of Connecticut Storrs, Connecticut

ISSEA Overview of Presentation  Introduction  Distributed Security Model  Enforcement Framework  Experimental Prototype  Supporting Advanced Applications  Conclusions  Future Work

ISSEA Introduction Goals of Our Research  Incorporation of Role-Based Security within a Distributed Resource Environment  Highly-Available Distributed Applications Constructed Using Middleware Tools  Demonstrate Use of Lookup Service to Provide Role-based Access of Clients to Resources  Propose Software Architecture and Role-Based Security Model with Constraints for  Authorization of Clients Based on Role  Authentication of Clients and Resources  Enforcement and Tracking so Clients Only Use Authorized Services (of Resource)  Propose a Flexible Security Solution for Clients and Services (Resources) in Dynamic Coalitions

ISSEA Introduction Proposed Architecture Security Authorization Client (SAC) Security Policy Client (SPC) Wrapped Resource for Legacy Application Wrapped Resource for Database Application Lookup Service General Resource Wrapped Resource for COTS Application Global Clock Resource (GCR) Java Client Legacy Client Database Client Software Agent COTS Client Lookup Service Security Registration Services Unified Security Resource (USR) Security Policy Services Security Authorization Services Security Analysis and Tracking (SAT)

ISSEA Distributed Security Model Lookup Service Middleware  Construct Distributed Applications by  Federating Groups of Users  Resources Provide Services for Users  A Resource Provides a Set of Services for Use by Clients (Users) and Other Resources (Services)  A Service is Similar to a set of Public Methods  Exportable - Analogous to API  Any Entity Utilized by Person or Program  Samples Include:  Computation, Persistent Store, Printer, Sensor  Software Filter, Real-Time Data Source  Services: Concrete Interfaces of Components  Services Register with Lookup Service

ISSEA Distributed Security Model Join, Lookup, and Service Invocation Client Resource Service Object Service Attributes Lookup Service Request Service AddCourse(CSE900) Return Service Proxy to AddCourse( ) JoinJoin Register & Lease Services CourseDB Class Contains Method AddCourse ( ) Service Invocation via Proxy by Transparent RMI Call Service Object Service Attributes Registry of Entries Step1. Join. Services are registered Step2. Client makes request Step3. Lookup Service returns Service Step4. Client Invokes AddCourse(CSE230) on Resource Step5. Resource Returns Results of Invocation to Client

ISSEA Distributed Security Model Lookup Service Shortfalls  Many Current Lookup Services  Successfully Dictates Service Utilization  Requires Programmatic Solution for Security  Does Not Selectively and Dynamically Control Access Based on Client Role  Security of a Distributed Resource Should Selectively and Dynamically Control Client Access to Services Based on the Role  Our Approach  Define Dedicated Resources to Authorize, Authenticate, and Enforce Security by Role  Proposed Unified Security Resources (USR)  Policy Services, Authoriz. Services, Registration Services, & Analysis/Tracking Services

ISSEA Distributed Security Model Resource, Service, Methods  Definition 1: A Distributed Application Consists of M Software/system Resources (Legacy, COTS, Database, Web Server, Etc.) Uniquely Identifiable  Definition 2: Each Resource is Composed of Services That Are Uniquely Identifiable  Definition 3: Each Service is Composed of a Set of Uniquely Identifiable Methods. Note That the Triple (R-id, S-id, M-id) is Unique.  Definition 4: The Signature of a Method of Service of Resource is Unique, and Consists of:  Method Name  Parameter List of Names/Types  Return Type (possible Null)

ISSEA Distributed Security Model Resources, Services, and Methods Read Service with Methods : String getAllClasses (Token); String getRegisteredCourses (Token, StudentName); Vector getClasses (long Token, Semester); Vector getClassDescription (Token, Course); Vector getPreReqCourses (Token, Course); Vector getVacantClasses (Token, Semester); Modification Service with Methods : boolean addCourse (Token, Course); boolean removeCourse (Token, Course); boolean updateEnroll (Token, CourseNumber, UpdateChoice, NewValue); boolean registerCourse (Token, Course, StudentName); boolean dropCourse (Token, Course, StudentName);

ISSEA Distributed Security Model Roles and Constraints  Definition 5: A User Role, UR, is a Uniquely Identifiable Named Entity Representing a Specific Set of Responsibilities Against an Application.  Definition 6: A Signature Constraint, SC, is a Boolean Expression Defined on Method Signature to Limit the Allowable Values on the Parameters, and the Return Type.  Definition 7: A Time Constraint, TC, is an Expression Defined for a Discrete Period of Time (Days or Time Period in GMT) Under Which a Method Can Be Invoked:  TC = {E | E=“Never” or E= “Always” or E = Boolean Expression}.

ISSEA Modification, addCourse, cse101  course  cse499 Modification, updateEnroll, newValue  30 Read, getClasses, semester = Spring Distributed Security Model Roles and Constraints  Sample Signature Constraints for CourseDB Resource  Sample Time Constraints 01jan01  date  31mar01 1apr01  date  14apr01 date = 10apr01

ISSEA Distributed Security Model Privilege Tuples and Authorizations  Definition 8: Assume a Distributed Application Consists of Resources, Services, and Methods. A Security Privilege Tuple Contains a Specific Resource, Service, and/or Method (with Optional Time and Signature Constraint) : {UR, TC, Ri, Sij, [Mijk, SCijk]}  Definition 9: Assume a Distributed Application of Resources, Services, and Methods. A Security Privilege Tuple Set, , Contains All of the Resources, Services, and Methods that have been Authorized (Granted) to a UR:  ={[UR, TC, Ri, Sij, [Mijk, Scijk]}

ISSEA Distributed Security Model Roles, Constraints, and Authorizations Role: CSEFaculty {[CSEFaculty,always,CourseDB,Read,[*]], [CSEFaculty,01jan01  date  31mar01,CourseDB, Modification, [addCourse, cse101  course  cse499]], [CSEFaculty,always,CourseDB,Modification,[updateEnroll, newValue  30]]} Role: CSEUndergrad {[CSEUndergrad,10dec00  date  16feb01, CourseDB, Read, [getClasses, semester = Spring]], [CSEUndergrad,1apr01  date  14apr01, CourseDB, Modification, [registerCourse, cse101  course  cse299]], [CSEUndergrad,15apr01  date  30apr01,CourseDB,Modification, [registerCourse, true]]} Authorized Users/Roles Harris: CSEUndergrad Jones: CSEFaculty, CSEDeptHead Token: [Harris, UR/CSEUndergrad, IP/ , Time/16mar01-14:50:04]

ISSEA Distributed Security Model User and Authorizations  Definition 10: A User, U, is Uniquely Identifiable (User-id) and Authorized to Play One or More Roles in an Application. A User Must Always Play Exactly One Role at Any Point During an Active Session, but is Able to Change Roles During a Session.  Definition 11: A Client, C, Represents an Authorized User, U, Utilizing a Client Application, and is Uniquely Identified During a Specific Session Via a System Generated Token: [User-id, Ur-id, Ip-address, Token-creation- time]

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

ISSEA 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); 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{Revoke}_Resource(UR_Id, R_Id); Grant{Revoke}_Service(UR_Id, R_Id, S_Id); Grant{Revoke}_Method(UR_Id, R_Id, S_Id, M_Id); Grant{Revoke}_SC(UR_Id, R_Id, S_Id, M_Id, SC); Grant{Revoke}_TC(UR_Id, R_Id, S_Id, M_Id, TC);

ISSEA Enforcement Framework Other 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 SECURITY AUTHORIZATION 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();

ISSEA Enforcement Framework Client, Resource, Service Invocations Security Authorization Services Security Registration Services Lookup Service Course Client 1 Register_Client(Harris,cse.uconn.edu,CSEUndergrad) 10 Return Result of Check_Privileges(…) 4 Return Result,Create_Token(CSEUndergrad, Token) 6 RegisterCourse(Token, CSE230, Harris) 3 Client OK? 11 Return Result,RegisterCourse(…) 5. Discover/Lookup(UnivDB,Modification, RegisterCourse) Returns Proxy to Course Client 7 IsClient_Registered(Token) 9 Check_Privileges(Token, UnivDB, Modification, RegisterCourse, [CSE230, Harris]) 2 Verify_UR(Harris, CSEUndergrad) Security Policy Services UnivDB Resource 8 Return Result of IsClient_Registered(…) USR

ISSEA Enforcement Framework Security Prototype (JINI and CORBA)  During the Past Two Years, Extensive Prototype has Been Developed on NT/Linux Using:  Java as Main Development Language  JINI/Corba as Middleware  Oracle/MS Access as Databases  Security Management/Administration Tools  Security Policy Client  Security Authorization Client  Tracking/Analysis Client  We’ll Discuss Each in Turn by Reviewing a Series of GUI Bitmaps

ISSEA Enforcement Framework Security Prototype (JINI and CORBA) Java GUI PDB Client JINI Lookup Service Security System Resource PDB &UDB Common Resource (Global Clock) CORBA Lookup Service PDBServer Service write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); UDBServer Service GetClasses(); PreReqCourse(); GetVacantClasses(); EnrollCourse(); AddCourse(); RemoveCourse(); UpdateCourse(). Java GUI UDB Client Security Policy Client Security Authorization Client Patient DB Resource (PDB) University DB Resource (UDB)

ISSEA Security Prototype Security Policy Client

ISSEA Security Prototype Defining a Signature Constraint

ISSEA Security Prototype Tracking Logins and Actions

ISSEA Security Prototype Security Authorization Client

ISSEA Security Prototype Tracking Methods of Resources

ISSEA Security Prototype Global Clock Server for Timestamp

ISSEA Security Prototype Client Authentication Upon Login

ISSEA Security Prototype Registering Individual Method

ISSEA Security Prototype Registering Methods for Resource

ISSEA Security Prototype Confirmation of Registered Methods

ISSEA Security Prototype Tracking Defined Resources

ISSEA Security Prototype Administration of Roles

ISSEA Security Prototype Creating User Role

ISSEA Security Prototype Granting Resources to Roles

ISSEA Security Prototype Reviewing Access of Resources to Roles

ISSEA Security Prototype Granting Methods to Roles

ISSEA Security Prototype Confirmation of Method to Role

ISSEA Security Prototype Creating a User

ISSEA Security Prototype Granting Roles to User

ISSEA Supporting Advanced Applications Dynamic Coalition Problem  A Crisis is Any Situation Requiring National or International Attention as Determined by the President of the United States or UN  A Coalition is an Alliance of Organizations: Military, Civilian, International or any Combination  A Dynamic Coalition is Formed in a Crisis and Changes as Crisis Develops, with the Key Concern Being the Most Effective way to Solve the Crisis  Dynamic Coalition Problem (DCP) is the Inherent Security, Resource, and/or Information Sharing Risks that Occur as a Result of the Coalition Being Formed Quickly

ISSEA Supporting Advanced Applications Global Command And Control System  GCCS is Used to Manage Activities in a Joint and Combined Environment  Joint Refers to More than One Branch Army, Navy, Air Force, Marines, or Coast Guard and Combined Means More Than One Country  GCCS Provides a Local Commander With Operational Awareness in Near Real-time Through an Integrated Set of Resources and Services  GCCS Provides Information-Processing Support to Planning, Mobility, Sustainment, and Messaging by Bringing Together 20 Separate Automated Systems With Several Additions Planned

ISSEA Supporting Advanced Applications GCCS Shortfalls  Does Not Consider Multiple Roles for Users  Does Not Place Time Limitations on Users  Does Not Use Any Resource Constraints  Is Not a Multi-level Secure System  Is a U. S. Only System

ISSEA Supporting Advanced Applications DCP Objectives  Federate Users Quickly and Dynamically  Bring Together Resources Without Modification  Dynamically Realize and Manage Simultaneous Crises  Identify Users by their Roles to Finely Tune Access  Authorize, Authenticate, and Enforce a Scalable Security Policy That is Flexible in Response to Collation Needs  Security Solution that is Portable, Extensible, and Redundant for Survivability  Management, and Introspection Capabilities to Track and Monitor System Behavior

ISSEA Concluding Remarks  For a Distributed Resource Environment  Proposed & Explained a Constraint-Based Approach to Role Security  Authorize, Authenticate, and Enforce  Presented an Software Architecture Containing  Constraint-Based Security Model for Role Security in a Distributed Resource Environment  An Enforcement Framework for Security with Registration, Authorization, and Policy Services

ISSEA Concluding Remarks  Developed Prototype System  JINI and CORBA-Based Prototype for Role- Based Security Model that Allows Role Access  System is Flexible, Scalable and Redundant  System Uses Constraints to Realize Policy  Presented Real-World Issues  Defined the Dynamic Coalition Problem  Discussed the Global Command and Control System and Its Shortcomings  Offered a Set of Objectives for Realization of Distributed Security in a Dynamic Setting

ISSEA Ongoing and Future Work  Integrating Mandatory Access Controls  Currently Integrated into Security Prototype  Model Extended to Include Classifications  Role Deconfliction and Mutual Exclusion  Preliminary Model Being Designed  Prototyping Planned in Near Future  User Constraints  Extend to Include User Constraints  Prototyping Underway  User Role Delegation Authority  Preliminary Model Designed  Prototyping Underway