Information Sharing and Security in Dynamic Coalitions

1
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_at_engr.uconn.edu
2
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
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
Near Simultaneous Crises
Crisis Point
BOSNIA (NATO)
NATO Hq
KOSOVO (US,UK)
Olympic Games
Earthquake (United Nations)
Ship Wreck (UK,SP)
5
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
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
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
Supporting Advanced ApplicationsDCP 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 Coalition Architecture
Resources Provide Services
Clients Using Services
NATO SYS
Federal Agencies (FEMA, FBI, CIA, etc.) Client
COTS
U.S. Army
LFCS (Canada)
Client
U.S. Navy
SICF (France)
Client
French
Air Force
Client
HEROS (Germany)
U.S. Legacy
System
SIACCON (Italy)
NATO
Database
Client
NGO/PVO Resource
German
NGO/PVO (Red Cross, NYPD, etc.) Client
GCCS (US)
COTS
Client
10
DCPJoint and Combined Information Flow
Common Operating Environment
Combined Many Countries
ARMY
Joint Task Force
Adjacent
Marines
Navy
Air Force
Coalition Partners
GCCS-N
GCCS-M
GCCS-AF
JMCIS
TCO
NATO Systems
TBMCS
Coalition Systems
Joint - Marines, Navy, Air Force, Army
11
DCP Combined Information Flow
12
DCP Coalition Artifacts and Information Flow
Military Engagement
U.S. Global C2 Systems
Navy
Air Force
Joint Command System
Battle Management System
NGO/ PVO
GCCS
U.N.
Army Battle Command System
Combat Operations System
U.S.A
NATO
Marine Corps
Army
Dynamic Coalition
AFATDS
FADD
ASAS
GOAL Leverage information in a
fluid, dynamic environment
GCCS-A
ABCS
CSSCS
MCS
Other
Army C2
13
DCP Coalition Artifacts and Information Flow
Civilian Engagement
Transportation
Military Medics
Govt.
Local Health Care
CDC
ISSUES Privacy vs. Availability in Medical
Records Support Life-Threatening Situations via
Availability of Patient Data on Demand
14
DCP Global Command and Control System
GLOBAL C2 SYSTEMS
MOBILE SUBSCRIBER EQUIPMENT DATA RADIO
SATELLITE
MISSION PLANNING
MET
SUPPORT
INTEL
SATCOM
MANEUVER CONTROL
X X
AIR DEFENCE
ARTY
TOPO
Client/Server
MET
MISSION PLANNING
AIR DEFENCE
SUPPORT
INTEL
X
MANEUVER CONTROL
Client/Server
SATCOM
ARTY
TOPO
Company
AIR DEFENCE
SUPPORT
FBCB2 /EBC
INTEL
Platoon
Client/Server
ARTY
Tactical Internet
MANEUVER CONTROL
BATTLEFIELD C2 SYSTEM EMBEDDED BATTLE COMMAND
SATCOM
FBCB2 /EBC
Squad
MOBILE SUBSCRIBER EQUIPMENT
15
DCPGlobal Command and Control System
16
DCPGlobal Command and Control System
Common Operational Picture
17
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)

18
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

19
Non-Military Crisis User Roles

• Emergent Crisis (Katrina) Requires a Response
• Some Critical Issues
• Whos 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

20
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

21
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

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

23
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

24
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

25
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, Didnt Prevent
• Disorganized Evacuation
• 10 Hour Highway Waits
• Running out of Fuel
• Federation Myst Coordinate Critical Resources

26
Information Sharing and SecurityFederated
Resources
27
Information Sharing and SecuritySyntactic
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

28
Information Sharing and SecuritySemantics
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)

29
Information Sharing and SecuritySyntactic
Semantic Considerations

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

30
Information Sharing and SecurityPragmatics 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?

31
Information Sharing and SecurityPragmatics Issues

• Pragmatics - Way that Information is Utilized and
  Understood in its Specific Context
• For Example, in GCCS

32
Information Sharing and Security Pragmatics
Issues

• Pragmatics in GCCS

33
Information Sharing and SecurityData 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

34
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 Cant Release Information
• Rely on Discretion by Foreign Disclosure Officer
• Pass on of DAC Must be Carefully Controlled!

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

36
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!)

37
Information Sharing and SecurityOther 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)

38
A Service-Based Security Architecture
39
Required Security Checks
40
Stepping BackSecurity 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

41
Security for Distributed Applications
How is Security Handled for Individual Systems?
What if Security Never Available for
Legacy/COTS/Database?
Security Issues for New Clients? New Servers?
Across Network?
What about Distributed Security?
Security Policy, Model, and Enforcement?
42
DC for Military Deployment/Engagement
OBJECTIVES Securely Leverage Information in a
Fluid Environment Protect Information While
Simultaneously Promoting the Coalition Security
Infrastructure in Support of DCP
SICF France
LFCS Canada
HEROS Germany
SIACCON Italy
43
DC for Medical Emergency
Transportation
Military Medics
Govt.
Local Health Care
CDC
ISSUES Privacy vs. Availability in Medical
Records Support Life-Threatening Situations via
Availability of Patient Data on Demand
44
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

45
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

46
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

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

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

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

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

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

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

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

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

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

56
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

57
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

58
A Distributed Security Framework

• Distributed Security Policy Definition, Planning,
  and Management
• Integrated with Software DevelopmentDesign
  (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

59
Interactions and Dependencies
Enforcement Mechanism Collection of SHs
Security Components
Formal Security Model
Distributed Security Policy
60
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

61
Three-Pronged Security Emphasis
Secure Software Design via UML with MAC/RBAC
Assurance RBAC, Delegation MAC Properties Simple
Integrity, Simple Security, etc. Safety Liveness
Secure Information Exchange via XML with MAC/RBAC
Secure MAC/RBAC Interactions via Middleware in
Distributed Setting
62
Secure Software Design - T. Doan
Bi-Directional Translation - Prove that all UML
Security Definitions in UML in Logic- Based
Policy Language and vice-versa
Other Possibilities Reverse Engineer Existing
Policy to Logic Based Definition UML Model with
Security Capture all Security Requirements!
63
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 ViolateMAC Rules

64
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

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

66
A Role-Slice for Professors
67
A Role Slide for Students
68
Middleware-Based Security - C. Phillips
COTS Client
COTS
Database

• 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

Legacy
Legacy Client
Database Client
GOTS
Java Client
NETWORK
Working Prototype Available using CORBA,JINI,
Java, Oracle
69
Process-Oriented View
70
Security for XML Documents
Security DTDs n Role DTD n User DTD n Constraint
DTD

• 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 Officer Generates Security XML files
for the Application
Application DTDs and XML
Application
Application DTDs
Appl_Role.xml Appl _User.xml Appl_Constraint.xml
Application XML Files
Users Role Determines the Scope of Access to
Each XML Document
71
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