CERT
ISW'97 site

 Front Page | Table of Contents | Final Agenda | Index of Authors | Download




Back to [26]   [27]    Forwards to [28]
Protecting Collaboration

Xiaolei Qian
Gio Wiederhold

Computer Science Laboratory
Department of Computer Science
SRI International
Stanford University

qian@csl.sri.com
gio@db.stanford.edu
[respectively]



Abstract

The Trusted Interoperation of Healthcare Information (TIHI) project addresses an issue that arises when some information must be shared among collaborating but distinct organizations forming virtual enterprises. Such organizations cannot fully share their data and information resources, although some information exchange is essential. The TIHI model deals then with protection of information among friends, rather than from adversaries. Such interactions might also be necessary within a single organization, when authority and responsibilities differ significantly.

We define protection domains as areas within which data can be freely exchanged, and hence focus on exchange of information among domains. Among collaborating domains, information exchange must be controlled, auditable, and effective. Examples of domains that must collaborate to satisfy business needs are the following.

Domain A
- Domain B


Medical Records Departments
- Physicians
Medical Records Departments
- Billing Clerks
Hospitals
- Public Health Agencies
Hospitals
- Insurance Companies
Hospitals
- Suppliers and Distributors
Factories
- Suppliers
Factories
- Distributors and Shipping Companies
Military Commanders
- Shipping Companies
Military Commanders
- Intelligence Resources
Military Commanders
- Troops in the Field

Domains might encompass multiple databases and computing systems, or can cut through these systems if adequate protection can be maintained within such systems.

Our technology defines intelligent gateways, or security mediators, through which all communication among domains is channeled. Domains might be protected by multiple security mediators, especially if there are interactions with other domains of differing types. A security mediator is owned by a security officer, who has the authority and responsibility to enforce the security policy set by the organization for its domains.

The security mediator is best visualized as residing on a distinct workstation, operated by the security officer. Within the workstation is a rule-base system that investigates queries coming in and responses to be transmitted out. Any query and any response that cannot be vetted by the rule system is displayed to the security officer, for manual handling. The security officer decides to approve, edit, or reject the information. An associated logging subsystem provides both an audit trail for all information that enters or leaves the domain, and input to the security officer to aid in evolving the rule set and increasing the effectiveness of the system.

Important aspects of the TIHI approach are that

  • TIHI provides a tool to define organization security policies. It does not determine those policies.
  • The interposition of the role of a security officer represents a valid business model, which avoids overloading database administrators from being faced with the conflicting demands of information dissemination and system performance, as well as protection.
  • The audit trail provides an analyzable record of information flow and supports evolution.
  • The definition and implementation of security policies in TIHI is independent of the platforms, software approaches, heterogeneity, and evolution of data systems within a domain.
  • Multilevel secure computer systems, if required, need only be used for the security mediators, if domains can otherwise be kept isolated.



Back to the Table of Contents
Back to [26]   [27]    Forwards to [28]