1. DCP-1 CSE5095 Information Sharing and Security in Dynamic Coalitions Information Sharing and Security in Dynamic Coalitions Steven A. Demurjian Computer Science & Engineering Department 371 Fairfield Road, Box U-2155 The University of Connecticut Storrs, Connecticut 06269-2155 http://www.engr.uconn.edu/~steve steve@engr.uconn.edu

2. DCP-2 CSE5095 Overview of Presentation  The Dynamic Coalition Problem  Civilian Organizations  Military Involvement/GCCS  Information Sharing and Security  Federating Resources  Data Integrity  Access Control (DAC and MAC)  Other Critical Security Issues  Stepping Back  Security Issues for Distributed and Component-Based Applications  Conclusions and Future Work

3. DCP-3 CSE5095 Crisis and Coalitions  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

4. DCP-4 CSE5095 Near Simultaneous Crises Ship Wreck (UK,SP) Olympic Games BOSNIA (NATO) KOSOVO (US,UK) Earthquake (United Nations) Crisis Point NATO Hq

5. DCP-5 CSE5095 Crises in 2005  Tidal Wave in Southeast Asia  Hurricanes in US  Katrina – Louisiana and Mississippi  Rita – Texas and Louisiana  Mudslides in Guatemala  Earthquake in Pakistan/India  Key Questions  How do we React to Such Crises?  What is Potential Role for Computer Scientists and Engineers in Process?  Can we Automate the Interactions Required for the Critical Computing Infrastructure?

6. DCP-6 CSE5095 Emergent Need for Coalitions  “Coalitions must be flexible and no one coalition is or has the answer to all situations.” »Secretary of Defense, Donald Rumsfeld   “Whenever possible we must seek to operate alongside alliance or coalition forces, integrating their capabilities and capitalizing on their strengths.” »U.S. National Security Strategy   “ Currently, there is no automated capability for passing command and control information and situational awareness information between nations except by liaison officer, fax, telephone, or loaning equipment.” »Undersecretary of Defense for Advanced Technology

7. DCP-7 CSE5095 The Dynamic Coalition Problem (DCP)  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  Private Organizations (PVO)  Doctors Without Boarders  Red Cross  Non-Government Organizations (NGO)  State and Local Government  Press Corps  Government Agencies  FBI, CIA, FEMA, CDC, etc.  Military

8. DCP-8 CSE5095 Supporting Advanced Applications DCP Objectives for Crisis  Federate Users Quickly and Dynamically  Bring Together Resources (Legacy, COTs, GOTs, DBs, etc.) Without Modification  Dynamically Realize/Manage Simultaneous Crises  Identify Users by Roles to Finely Tune Access  Authorize, Authenticate, and Enforce a Scalable Security Policy that is Flexible in Response to Collation Needs  Provide a Security Solution that is Portable, Extensible, and Redundant for Survivability  Include Management/Introspection Capabilities to Track and Monitor System Behavior

9. DCP-9 CSE5095 DCP: Coalition Architecture Resources Provide ServicesClients Using Services French Air Force Client U.S. Navy Client U.S. Army Client German COTS Client NATO Database Client U.S. Legacy System COTS GCCS (US) NGO/PVO Resource LFCS (Canada) SICF (France) HEROS (Germany) SIACCON (Italy) Federal Agencies (FEMA, FBI, CIA, etc.) Client NGO/PVO (Red Cross, NYPD, etc.) Client NATO SYS

10. DCP-10 CSE5095 DCP Joint and Combined Information Flow GCCS-N JMCIS GCCS-AF TBMCS Common Operating Environment GCCS GCCS-A MCS BN CO FBCB2 BDE MCS BSATOC CORPS MCS ABCS MCS ASAS CSSCS FAADC2I AFATDS DIV MCS BN XX X | || Adjacent Joint Task Force X TCO GCCS-M NATO Systems Coalition Systems ARMY MarinesNavy Air ForceCoalition Partners Joint - Marines, Navy, Air Force, Army Combined: Many Countries

11. DCP-11 CSE5095 DCP: Combined Information Flow Logistics Air Defense/Air Operations Fire Support Network and Resource Management Intelligence GCCS - Joint/Coalition - Maneuver Combined Database

12. DCP-12 CSE5095 DCP: Coalition Artifacts and Information Flow – Military Engagement 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 GOAL: Leverage information in a fluid, dynamic environment Dynamic Coalition U.S. Global C2 Systems Army C2

13. DCP-13 CSE5095 DCP: Coalition Artifacts and Information Flow – Civilian Engagement Govt. Transportation Military Medics Local Health Care CDC ISSUES: Privacy vs. Availability in Medical Records Support Life-Threatening Situations via Availability of Patient Data on Demand Pharma. Companies Govt. MDs w/o Borders Red Cross RNs EMTs MDs State Health Other

32. DCP-32 CSE5095 DCP: Global Command and Control System Client/Server INTEL SUPPORT MISSION PLANNING TOPO ARTY AIR DEFENCE ARTY MOBILE SUBSCRIBER EQUIPMENT DATA RADIO X X Situational Awareness MOBILE SUBSCRIBER EQUIPMENT ARTY SUPPORT TOPO SUPPORT MISSION PLANNING MET GCCS Provides: - Horizontal and Vertical Integration of Information to Produce a Common Picture of the Battlefield - 20 separate automated systems - 625 locations worldwide - private network SATCOM MET Company Platoon Squad FBCB2 /EBC BATTLEFIELD C2 SYSTEM EMBEDDED BATTLE COMMAND FBCB2 /EBC Tactical Internet Client/Server GLOBAL C2 SYSTEMS MANEUVER CONTROL SATELLITE AIR DEFENCE INTEL MANEUVER CONTROL MANEUVER CONTROL

33. DCP-33 CSE5095 DCP: Global Command and Control System Joint Services:a.k.a WeatherMETOC Video TeleconferenceTLCF Joint Operations Planning and Execution SystemJOPES Common Operational PictureCOP Transportation Flow AnalysisJFAST Logistics Planning ToolLOGSAFE Defense Message SystemDMS NATO Message SystemCRONOS Component Services: Army Battle Command System ABCS Air Force Battle Management System TBMCS Marine Combat Operations System TCO Navy Command System JMCIS

34. DCP-34 CSE5095 DCP: Global Command and Control System Common Picture Common Operational Picture

35. DCP-35 CSE5095 DCP: Critical Requirements  Difficult to Establish Roles  Requires Host Administrator  Not Separate Roles  No Time Controllable Access  Time Limits on Users  Time Limits on Resource Availability  Time Limits on Roles  No Value Constraints  Unlimited Common Operational Picture  Unlimited Access to Movement Information  Difficult to Federate Users and Resources  U.S. Only system  Private Network (Not Multi-Level Secure)

36. DCP-36 CSE5095 GCCS Shortfalls: User Roles  Currently, GCCS Users have Static Profile Based on Position/Supervisor/Clearance Level  Granularity Gives “Too Much Access”  Profile Changes are Difficult to Make - Changes Done by System Admin. Not Security Officer  What Can User Roles Offer to GCCS?  User Roles are Valuable Since They Allow Privileges to be Based on Responsibilities  Security Officer Controls Requirements  Support for Dynamic Changes in Privileges  Towards Least Privilege

37. DCP-37 CSE5095 Non-Military Crisis: User Roles  Emergent Crisis (Katrina) Requires a Response  Some Critical Issues  Who’s in Charge?  Who is Allowed to do What?  Who can Mobilize Governmental Resources?  Roles can Help:  Role for Crisis Commander  Roles for Crisis Participants  Roles Dictate Control over Resources  For Katrina: Lack of Leadership & Defined Roles  Army Corps of Engineers Only Allowed to Repair Levees – Not Upgrade and Change

38. DCP-38 CSE5095 GCCS Shortfalls: Time Controlled Access  Currently, in GCCS, User Profiles are Indefinite with Respect to Time  Longer than a Single Crisis  Difficult to Distinguish in Multiple Crises  No Time Controllable Access on Users or GCCS Resources  What can Time Constrained Access offer GCCS?  Junior Planners - Air Movements of Equipment Weeks before Deployment  Senior Planners - Adjustment in Air Movements Near and During Deployment  Similar Actions are Constrained by Time Based on Role

39. DCP-39 CSE5095 Non-Military Crisis: Time Controlled Access  Multiple Crisis Require Ability to Distinguish Between Roles Based on Time and Crisis  Occurrence of Rita (one Crisis) Impacted the Ongoing Crisis (Katrina)  Need to Manage Simultaneous Crisis w.r.t. Time  Different Roles Available at Different Times within Different Crises  Role Might be “Finishing” in one Crisis (e.g., First Response Role) and “Starting” in Another  Individual May Play Different Roles in Different Crisis  Individual May Play Same Role with Different Duration in Time w.r.t. its Activation

40. DCP-40 CSE5095 GCCS Shortfalls: Value Based Access  Currently, in GCCS, Controlled Access Based on Information Values Difficult to Achieve  Unlimited Viewing of Common Operational Picture (COP)  Unlimited Access to Movement Information  Attempts to Constrain would have to be Programmatic - which is Problematic!  What can Value-Based Access Offer to GCCS?  In COP  Constrain Display of Friendly and Enemy Positions  Limit Map Coordinates Displayed  Limit Tier of Display (Deployment, Weather, etc.)

41. DCP-41 CSE5095 Non-Military Crisis: Value Based Access  In Katrina/Rita, What People can See and Do May be Limited Based on Role  Katrina Responders Limited to Katrina Data  Rita Responders Limited to Rita Data  Some Responders (Army Corps Engineers) May Need Both to Coordinate Activities  Within Each Crisis, Information Also Limited  Some Katrina Roles (Commander, Emergency Responders, etc.) see All Data  Other Katrina Roles Limited (Security Deployment Plans Not Available to All  Again – Customization is Critical

42. DCP-42 CSE5095 GCCS Shortfalls: Federation Needs  Currently, GCCS is Difficult to Use for DCP  Difficult to Federate Users and Resources  U.S. Only system  Incompatibility in Joint and Common Contexts  Private Network (Not Multi-Level Secure)  What are Security/Federation Needs for GCCS?  Quick Admin. While Still Constraining US and Non-US Access  Employ Middleware for Flexibility/Robustness  Security Definition/Enforcement Framework  Extend GCCS for Coalition Compatibility that Respects Coalition and US Security Policies

43. DCP-43 CSE5095 Non-Military Crisis: Federation Needs  Crisis May Dictate Federation Capabilities  Katrina  Devastated Basic Communication at All Levels  There was No Need to Federate Computing Systems at Crisis Location with No Power, etc.  Rita  Crisis Known Well in Advance  However, Didn’t Prevent  Disorganized Evacuation  10+ Hour Highway Waits  Running out of Fuel  Federation Myst Coordinate Critical Resources

44. DCP-44 CSE5095 Information Sharing and Security Federated Resources JSTARS Unmanned Aerial Vehicle Satellites Bradley / EBC Embedded Battle Command ABCS Fwd Support Element Ammo/Fuel Refit AIR DEFENCE Embedded Battle Command INTEL FUSION Embedded Battle Command MANEUVER CONTROL Embedded Battle Command PERSONNEL AND LOGISTICS Embedded Battle Command FIELD ARTILLERY Embedded Battle Command Common Picture RESOURCES Command&Control Vehicles Army Airborne Command & Control System Army Battle Command System Embedded Command System

45. DCP-45 CSE5095 Information Sharing and Security Syntactic Considerations  Syntax is Structure and Format of the Information That is Needed to Support a Coalition  Incorrect Structure or Format Could Result in Simple Error Message to Catastrophic Event  For Sharing, Strict Formats Need to be Maintained  In US Military, Message Formats Include  Heading and Ending Section  United States Message Text Formats (USMTF)  128 Different Message Formats  Text Body of Actual Message  Problem: Formats Non-Standard Across Different Branches of Military and Countries

46. DCP-46 CSE5095 Information Sharing and Security Semantics Concerns  Semantics (Meaning and Interpretation)  USMTF - Different Format, Different Meaning  Each of 128 Messages has Semantic Interpretation  Communicate Logistical, Intelligence, and Operational Information  Semantic Problems  NATO and US - Different Message Formats  Different Interpretation of Values  Distances (Miles vs. Kilometers)  Grid Coordinates (Mils, Degrees)  Maps (Grid, True, and Magnetic North)

47. DCP-47 CSE5095 Information Sharing and Security Syntactic & Semantic Considerations  What’s Available to Support Information Sharing?  How do we Insure that Information can be Accurately and Precisely Exchanged?  How do we Associate Semantics with the Information to be Exchanged?  What Can we Do to Verify the Syntactic Exchange and that Semantics are Maintained?  Can Information Exchange Facilitate Federation?  How do we Deal with Exchange to/from Legacy Applications?  Can this be Handled Dynamically?  Or, Must we Statically Solve Information Sharing in Advance?

48. DCP-48 CSE5095 Information Sharing and Security Pragmatics Issues  Pragmatics Require that we Totally Understand Information Usage and Information Meaning  Key Questions Include:  What are the Critical Information Sources?  How will Information Flow Among Them?  What Systems Need Access to these Sources?  How will that Access be Delivered?  Who (People/Roles) will Need to See What When?  How will What a Person Sees Impact Other Sources?

49. DCP-49 CSE5095 Information Sharing and Security Pragmatics Issues  Pragmatics - Way that Information is Utilized and Understood in its Specific Context  For Example, in GCCS

50. DCP-50 CSE5095 Information Sharing and Security Pragmatics Issues  Pragmatics in GCCS X X XXX XX XXX DSCS A2C2S DIV CDR C2V DIV CDR SINCGARS (FS) EPLRS (AD) Info/Intel/Plans DIV REAR VTel SINCGARS (FS) EPLRS (AD) Sustainment Mobility TGT/Fires BVTC DMAIN BVTC SINCGARS (FS) EPLRS (AD) BVTC Relay DR SINCGARS (FS) EPLRS (AD) Division Slice 404 ASB Theater Injection Point (TIP) HCLOS Note: 3rd BDE not part of 1DD in Sep 2000. DR Relay SEN Relay DR CMDR BCV GBS DR TAC DR MVR BN GBS DR MVR BN GBS DR MVR BN GBS DR 4 ENG DR GBS DR GBS DR 3rd BDE BVTC SEN GBS 64 FSB DR GBS 3-29FA 1/10 CAV CMDR BCV DR 1/10 CAV Sqdn DR GBS SEN CMDR BCV GBS DR TAC DR MVR BN GBS DR MVR BN GBS DR MVR BN GBS DR 588 ENG DR GBS DR GBS DR 2nd BDE BVTC SEN GBS 4 FSB DR GBS 3-16FA SEN CMDR BCV GBS DR TAC DR MVR BN GBS DR MVR BN GBS DR MVR BN GBS DR 299 ENG DR GBS DR GBS DR 1st BDE BVTC SEN GBS 204FSB DR GBS 4-42FA SEN DR GBS DR DTAC 1 BVTC DR GBS 9-1FA DR GBS 2/4 AVN BN SEN DR GBS DR 4th BDE BVTC DR GBS 1/4 AVN BN SEN GBS SEN GBS DR VTel DR GBS DR 124th SIG BN GBSDR SINCGARS (FS) EPLRS (AD) SEN GBS DR DISCOM BVTC SEN GBS DR 704MSB SENLEN GBS SEN GBS DR DIVARTY BVTC SINCGARS (FS) EPLRS (AD) GBS Node Estimate Current FDD laydown has 53 autonomous Command Post/TOCs (i.e., nodes) For a full Corps >200 nodes Node Estimate Current FDD laydown has 53 autonomous Command Post/TOCs (i.e., nodes) For a full Corps >200 nodes Basic Distribution Requirement Distribution Polices Automation & Notification User Controls Transport Mechanisms System and Process Monitors Security, Logs, and Archives Basic Distribution Requirement Distribution Polices Automation & Notification User Controls Transport Mechanisms System and Process Monitors Security, Logs, and Archives How - Prioritized - Encrypted - Network Distribution Policy What When Where

51. DCP-51 CSE5095 Information Sharing and Security Data Integrity  Concerns: Consistency, Accuracy, Reliability  Accidental Errors  Crashes, Concurrent Access, Logical Errors  Actions:  Integrity Constraints  GUIs  Redundancy  Malicious Errors  Not Totally Preventable  Actions:  Authorization, Authentication, Enforcement Policy  Concurrent Updates to Backup DBs  Dual Homing

52. DCP-52 CSE5095 Information Sharing and Security Discretionary Access Control  What is Discretionary Access Control (DAC)?  Restricts Access to Objects Based on the Identity of Group and /or Subject  Discretion with Access Permissions Supports the Ability to “Pass-on” Permissions  DAC and DCP  Pass on from Subject to Subject is a Problem  Information Could be Passed from Subject (Owner) to Subject to Party Who Should be Restricted  For Example,  Local Commanders Can’t Release Information  Rely on Discretion by Foreign Disclosure Officer  Pass on of DAC Must be Carefully Controlled!

53. DCP-53 CSE5095 Information Sharing and Security Role Based Access Control  What is Role Based Access Control (RBAC)?  Roles Provide Means for Permissions to Objects, Resources, Based on Responsibilities  Users May have Multiple Roles Each with Different Set of Permissions  Role-Based Security Policy Flexible in both Management and Usage  Issues for RBAC and DCP  Who Creates the Roles?  Who Determines Permissions (Access)?  Who Assigns Users to Roles?  Are there Constraints Placed on Users Within Those Roles?

54. DCP-54 CSE5095 Information Sharing and Security Mandatory Access Control  What is Mandatory Access Control (MAC)?  Restrict Access to Information, Resources, Based on Sensitivity Level (Classification) Classified Information - MAC Required  If Clearance (of User) Dominates Classification, Access is Allowed  MAC and DCP  MAC will be Present in Coalition Assets  Need to Support MAC of US and Partners  Partners have Different Levels/Labels  Need to Reconcile Levels/Labels of Coalition Partners (which Include Past Adversaries!)

55. DCP-55 CSE5095 Information Sharing and Security Other Issues  Intrusion Detection  Not Prevention  Intrusion Types:  Trojan Horse, Data Manipulation, Snooping  Defense:  Tracking and Accountability  Survivability  Reliability and Accessibility  Defense:  Redundancy  Cryptography  Fundamental to Security  Implementation Details (key distribution)

56. DCP-56 CSE5095 A Service-Based Security Architecture

57. DCP-57 CSE5095 Required Security Checks

58. DCP-58 CSE5095 Stepping Back Security for Distributed Environments  Background and Motivation  What are Key Distributed Security Issues?  What are Major/Underlying Security Concepts?  What are Available Security Approaches?  Identifying Key Distributed Security Requirements  Frame the Solution Approach  Outline UConn Research Emphasis:  Secure Software Design (UML and AOSD)  Middleware-Based Realization (CORBA/JINI)  Information Exchange via XML

59. DCP-59 CSE5095 Security for Distributed Applications Legacy COTS Database NETWORK Java Client Java Client How is Security Handled for Individual Systems? What about Distributed Security? Security Issues for New Clients? New Servers? Across Network? What if Security Never Available for Legacy/COTS/Database? Security Policy, Model, and Enforcement?

60. DCP-60 CSE5095 FADD AFATDS GCCS-A MCS ASAS CSSCS Other ABCS U.N. U.S.A NGO/ PVO NATO Marine Corps NavyAir Force Army GCCS Battle Management System Joint Command System Army Battle Command System Combat Operations System U.S. Global C2 Systems DC for Military Deployment/Engagement LFCS Canada SICF France HEROS Germany SIACCON Italy OBJECTIVES: Securely Leverage Information in a Fluid Environment Protect Information While Simultaneously Promoting the Coalition Security Infrastructure in Support of DCP

61. DCP-61 CSE5095 DC for Medical Emergency Govt. Transportation Military Medics Local Health Care CDC ISSUES: Privacy vs. Availability in Medical Records Support Life-Threatening Situations via Availability of Patient Data on Demand Pharma. Companies Govt. MDs w/o Borders Red Cross RNs EMTs MDs State Health Other

62. DCP-62 CSE5095 Security Issues: Confidence in Security  Assurance  Do Security Privileges for Each User Support their Needs?  What Guarantees are Given by the Security Infrastructure in Order to Attain:  Safety: Nothing Bad Happens During Execution  Liveness: All Good Things can Happen During Execution  Consistency  Are the Defined Security Privileges for Each User Internally Consistent? Least-Privilege Principle  Are the Defined Security Privileges for Related Users Globally Consistent? Mutual-Exclusion

63. DCP-63 CSE5095 Security for Coalitions  Dynamic Coalitions will play a Critical Role in Homeland Security during Crisis Situations  Critical to Understand the Security Issues for Users and System of Dynamic Coalitions  Multi-Faceted Approach to Security  Attaining Consistency and Assurance at Policy Definition and Enforcement  Capturing Security Requirements at Early Stages via UML Enhancements/Extensions  Providing a Security Infrastructure that Unifies RBAC and MAC for Distributed Setting

64. DCP-64 CSE5095 Four Categories of Questions  Questions on Software Development Process  Security Integration with Software Design  Transition from Design to Development  Questions on Information Access and Flow  User Privileges key to Security Policy  Information for Users and Between Users  Questions on Security Handlers and Processors  Manage/Enforce Runtime Security Policy  Coordination Across EC Nodes  Questions on Needs of Legacy/COTS Appls.  Integrated, Interoperative Distributed Application will have New Apps., Legacy/COTS, Future COTS

65. DCP-65 CSE5095 Software Development Process Questions  What is the Challenge of Security for Software Design?  How do we Integrate Security with the Software Design Process?  What Types of Security Must be Available?  How do we Integrate Security into OO/Component Based Design?  Integration into OO Design?  Integration into UML Design?  What Guarantees Must be Available in Process?  Assurance Guarantees re. Consistent Security Privileges?  Can we Support Security for Round-Trip and Reverse Engineering?

66. DCP-66 CSE5095 Software Development Process Questions  What Techniques are Available for Security Assurance and Analysis?  Can we Automatically Generate Formal Security Requirements?  Can we Analyze Requirements for Inconsistency and Transition Corrections Back to Design?  How do we Handle Transition from Design to Development?  Can we Leverage Programming Languages in Support of Security for Development?  Subject-Oriented Programming?  Aspect-Oriented Programming?  Other Techniques?

67. DCP-67 CSE5095 Information Access and Flow Questions  Who Can See What Information at What Time?  What Are the Security Requirements for Each User Against Individual Legacy/cots Systems and for the Distributed Application?  What Information Needs to Be Sent to Which Users at What Time?  What Information Should Be “Pushed” in an Automated Fashion to Different Users at Regular Intervals?

68. DCP-68 CSE5095 Information Access and Flow Questions  What Information Needs to Be Available to Which Users at What Time?  What Information Needs to Be “Pulled” On- demand to Satisfy Different User Needs in Time-critical Situations  How Are Changing User Requirements Addressed Within the Distributed Computing Application?  Are User Privileges Static for the Distributed Computing Application?  Can User Privileges Change Based on the “Context” and “State” of Application?

69. DCP-69 CSE5095 Security Handlers/Processing Questions  What Security Techniques Are  Needed to Insure That the Correct Information Is Sent to the Appropriate Users at Right Time?  Necessary to Insure That Exactly Enough Information and No More Is Available to Appropriate Users at Optimal Times?  Required to Allow As Much Information As Possible to Be Available on Demand to Authorized Users?

70. DCP-70 CSE5095 Security Handlers/Processing Questions  How Does the Design by Composition of a Distributed Computing Application Impact on Both the Security and Delivery of Information?  Is the Composition of Its “Secure” Components Also Secure, Thereby Allowing the Delivery of Information?  Can We Design Reusable Security Components That Can Be Composed on Demand to Support Dynamic Security Needs in a Distributed Setting?  What Is the Impact of Legacy/cots Applications on Delivering the Information?

71. DCP-71 CSE5095 Security Handlers/Processing Questions  How Does Distribution Affect Security Policy Definition and Enforcement?  Are Security Handlers/enforcement Mechanisms Centralized And/or Distributed to Support Multiple, Diverse Security Policies?  Are There Customized Security Handlers/enforcement Mechanisms at Different Levels of Organizational Hierarchy?  Does the Organizational Hierarchy Dictate the Interactions of the Security Handlers for a Unified Enforcement Mechanism for Entire Distributed System?

72. DCP-72 CSE5095 Legacy/COTS Applications Questions  When Legacy/COTS Applications are Placed into Distributed, Interoperable Environment:  At What Level, If Any, is Secure Access Available?  Does the Application Require That Secure Access Be Addressed?  How is Security Added if it is Not Present? What Techniques Are Needed to Control Access to Legacy/COTS?  What is the Impact of New Programming Languages (Procedural, Object-oriented, Etc.) And Paradigms?

73. DCP-73 CSE5095 Focusing on MAC, DAC and RBAC  For OO Systems/Applications, Focus on Potential Public Methods on All Classes  Role-Based Approach:  Role Determines which Potential Public Methods are Available  Automatically Generate Mechanism to Enforce the Security Policy at Runtime  Allow Software Tools to Look-and-Feel Different Dynamically Based on Role  Extend in Support of MAC (Method and Data Levels) and DAC (Delegation of Authority)

74. DCP-74 CSE5095 Legacy/COTS Applications  Interoperability of Legacy/COTS in a Distributed Environment  Security Issues in Interoperative, Distributed Environment  Can MAC/DAC/RBAC be Exploited?  How are OO Legacy/COTS Handled?  How are Non-OO Legacy/COTS Handled?  How are New Java/C++ Appls. Incorporated?  Can Java Security Capabilities be Utilized?  What Does CORBA/ORBs have to Offer?  What about other Middleware (e.g. JINI)?  Explore Some Preliminary Ideas on Select Issues

75. DCP-75 CSE5095 A Distributed Security Framework  What is Needed for the Definition and Realization of Security for a Distributed Application?  How can we Dynamically Construct and Maintain Security for a Distributed Application?  Application Requirements Change Over Time  Seamless Transition for Changes  Transparency from both User and Distributed Application Perspectives  Support MAC, RBAC and DAC (Delegation)  Cradle to Grave Approach  From Design (UML) to Programming(Aspects)  Information Exchange (XML)  Middleware: Interoperating Artifacts & Clients

76. DCP-76 CSE5095 A Distributed Security Framework  Distributed Security Policy Definition, Planning, and Management  Integrated with Software Development: Design (UML) and Programming (Aspects)  Include Documents of Exchange (XML)  Formal Security Model with Components  Formal Realization of Security Policy  Identifiable “Security” Components  Security Handlers & Enforcement Mechanism  Run-time Techniques and Processes  Allows Dynamic Changes to Policy to be Seamless and Transparently Made

77. DCP-77 CSE5095 Distributed Security Policy L + SH DB + SH Java Client Java Client Legacy Client DB Client COTS Client L + SH CO+ SHDB + SH Server + SHL + SH CO+ SH Server + SH DB + SH Formal Security Model Security Components Enforcement Mechanism Collection of SHs L: Legacy CO: COTS DB: Database SH: Security Handler Interactions and Dependencies

78. DCP-78 CSE5095 Policy Definition, Planning, Management  Interplay of Security Requirements, Security Officers, Users, Components and Overall System  Minimal Effort in Distributed Setting - CORBA Has Services for  Confidentiality, Integrity, Accountability, and Availability  But, No Cohesive CORBA Service Ties Them with Authorization, Authentication, and Privacy  Difficult to Accomplish in Distributed Setting  Must Understand All Constituent Systems  Interplay of Stakeholders, Users, Sec. Officers

79. DCP-79 CSE5095 Three-Pronged Security Emphasis Secure Software Design via UML with MAC/RBAC Secure Information Exchange via XML with MAC/RBAC Secure MAC/RBAC Interactions via Middleware in Distributed Setting Assurance RBAC, Delegation MAC Properties: Simple Integrity, Simple Security, etc. Safety Liveness

80. DCP-80 CSE5095 Other Possibilities: Reverse Engineer Existing Policy to Logic Based Definition UML Model with Security Capture all Security Requirements! Extending UML for the Design and Definition of Security Requirements Address Security in Use-Case Diagrams, Class Diagrams, Sequence Diagrams, etc. Formal Security Policy Definition using Existing Approach (Logic Based Policy Language) Iterate, Revise Bi-Directional Translation - Prove that all UML Security Definitions in UML in Logic- Based Policy Language and vice-versa Security Model Generation RBAC99 GMU RBAC/MAC UConn Oracle Security Must Prove Generation Captures all Security Requirements Secure Software Design - T. Doan

81. DCP-81 CSE5095 RBAC/MAC at Design Level  Security as First Class Citizen in the Design Process  Use Cases and Actors (Roles) Marked with Security Levels  Dynamic Assurance Checks to Insure that Connections Do Not Violate MAC Rules

82. DCP-82 CSE5095 Secure Software Design - J. Pavlich  What are Aspects?  System Properties that Apply Across an Entire Application  Samples: Security, Performance, etc.  What is Aspect Oriented Programming?  Separation of Components and Aspects from One Another with Mechanisms to Support Abstraction and Composition for System Design  What is Aspect Oriented Software Design?  Focus on Identifying Components, Aspects, Compositions, etc.  Emphasis on Design Process and Decisions

83. DCP-83 CSE5095 Aspects for Security in UML  Consider the Class Diagram below that Captures Courses, Documents, and Grade Records  What are Possible Roles?  How can we Define Limitations of Role Against Classes?

84. DCP-84 CSE5095 A Role-Slice for Professors

85. DCP-85 CSE5095 A Role Slide for Students

86. DCP-86 CSE5095 Legacy COTS GOTS Database NETWORK Java Client Legacy Client Database Client COTS Client Middleware-Based Security - C. Phillips  Artifacts: DB, Legacy, COTS, GOTS, with APIs  New/Existing Clients use APIs  Can we Control Access to APIs (Methods) by …  Role (who)  Classification (MAC)  Time (when)  Data (what)  Delegation 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 Working Prototype Available using CORBA, JINI, Java, Oracle

87. DCP-87 CSE5095 Process-Oriented View Analyses of RBAC/MAC Model/Framework Against SSE-CMM Evaluation of RBAC/MAC Model Using DCP Unified RBAC/MAC Security Model RBAC/MAC Enforcement Framework Security Middleware Security Administrative and Management Tools Security Policy Definition Run Time Security Assurance Design Time Security Assurance

88. DCP-88 CSE5095 Security for XML Documents  Emergence of XML for Document/Information Exchange  Extend RBAC/MAC to XML  Collection of Security DTDs  DTDs for Roles, Users, and Constraints  Capture RBAC and MAC  Apply Security DTDs to XML Documents  An XML Document Appears Differently Based on Role, MAC, Time, Value  Security DTD Filters Document Security DTDs  Role DTD  User DTD  Constraint DTD Application Application DTDs Application XML Files Appl_Role.xml Appl _User.xml Appl_Constraint.xml Security Officer Generates Security XML files for the Application DTDs and XML User’s Role Determines the Scope of Access to Each XML Document

89. DCP-89 CSE5095 Concluding Remarks  Objective is for Everyone to Think about the Range, Scope, and Impact of Security  Question-Based Approach Intended to Frame the Discussion  Proposed Solution for Distributed Environment  Current UConn Foci  Secure Software Design  Middleware Realization  XML Document Customization  Consider these and Other Issues for DCP