Survivability In Healthcare

Carnegie Mellon University

Survivability Requirements for the U.S. Health Care Industry
A Thesis Submitted to the Information Networking Institute in Partial Fulfillment of the Requirements for the degree MASTER OF SCIENCE in INFORMATION NETWORKING

by Jose Caldera Pittsburgh, Pennsylvania May 2000 Copyright by Jose Caldera, 2000. All rights reserved

-

Carnegie Mellon University Information Networking Institute

THESIS

SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Master Science in Information Networking

Title Survivability Requirements for the U.S. Health Care Industry Presented by Jose Caldera Accepted by the Information Networking Institute

Thesis Advisor

_________________ Dr. David Fisher
Date: _______

Thesis Advisor

_________________ Dr. Howard Lipson

Date: _______

INI Dept Chairman

_________________ Dr. Richard Stern

Date: _______

-

Abstract
Over the last decade, our society has become more and more dependent on Information Systems (IS), and increasingly dependent on highly distributed IS that operate in unbounded networks, such as the Internet. These systems hold the necessary data on which the majority of our essential services rely. There is an increasing risk to the fulfillment of our essential services due to these systems’ vulnerabilities. In the presence of these vulnerabilities and the limited ability of traditional security approaches to protect such systems, there is a pressing need for new ways to develop systems that are able to survive, limit damage, recover, and operate robustly in the presence of attacks that cannot be completely repelled. Survivability is a new field of study that addresses these issues. A survivable system is able to fulfill its mission in a timely manner, in the presence of attacks, failures, or accidents. At the same time there is a critical need for survivable systems to evolve over time to exploit the changing requirements and new opportunities created by changes in its environment and advancing technology. This thesis examines a variety of issues related to survivability in the U.S. health care industry. It also reviews the concepts of survivability, security, unbounded networks, and emergent properties. It focuses on the deployment of a framework for identifying, validating, and applying mission critical requirements. These mission requirements are further refined into system requirements that lead to design and implementation decisions. The system requirements are highly constrained by the environment that surrounds the system. Moreover, requirements must evolve in response to changes in the environment to remain relevant and cost-effective. Thus, it is necessary to frequently upgrade the system so these changes are addressed. Based on the previously mentioned framework, we examine the current structure of the U.S. health care industry, and propose an initial set of mission requirements for the U.S. health care infrastructure. We also apply the framework to a case study involving a U.S. Army medical treatment facility. The case study allowed us to draw some conclusions about the specific facility, and relate them to the ones we drew from the health care industry.

-

Acknowledgements To my parents… for your wise guidance and great education…I just hope I can do the same for my children… no more and no less… To my brothers… for always being there and sometimes here for me... To David Fisher and Howard Lipson… for their guidance throughout the course of this thesis… To my INI classmates… guys, it has been a heck of a experience sharing with you these two years… To my venezuelan friends… for your support and for the “rumbas” during vacations… To all INI administration personnel: especially Sue Jones, Lisa Currin and Joe Kern. To CERT/SEI administration personnel: especially Annette Welsch

To Jerry for his two choices…

-

Index

Index ............................................................................................................... 1 Table of Figures............................................................................................. 3 Chapter I – Introduction .............................................................................. 4 Chapter II - Concepts ................................................................................... 7
Survivability..................................................................................................................... 7
Survivability Properties............................................................................................................................. 9

Unbounded Networks .................................................................................................... 11 Emergent Algorithms..................................................................................................... 12
Characteristics of Emergent Algorithms ................................................................................................. 13

Conclusions to this chapter ............................................................................................ 15

Chapter III – A Framework for the Design of Survivable Systems....... 16
Mission........................................................................................................................... 17 Mission/Survivability requirements............................................................................... 18 System Requirements..................................................................................................... 19
Constraints on Survivable Systems Design............................................................................................. 20 Evolution of systems requirements ......................................................................................................... 21

Design decisions ............................................................................................................ 22 Implementation .............................................................................................................. 22 Functional requirements................................................................................................. 23 Non Functional requirements......................................................................................... 24 Eliciting requirements.................................................................................................... 25
Threat scenarios ...................................................................................................................................... 25

Conclusions to this chapter ............................................................................................ 26

Chapter IV – The Health Care Services as a Critical Infrastructure.... 27
The National Information Infrastructure........................................................................ 27 Health Care Industry Evolution and the Role of Information Technology (IT) ............ 30
Integrated Delivery Systems (IDS) ......................................................................................................... 30 Healthcare Maintenance Organizations (HMO)...................................................................................... 31 Electronic Medical Records (EMR) ........................................................................................................ 33

-1-

Conclusions to this chapter ............................................................................................ 35

Chapter V – Requirements for a Survivable Health Care Industry...... 37
Application Domain....................................................................................................... 37 Threats............................................................................................................................ 38 Constraints ..................................................................................................................... 41 A Survivable Infrastructure............................................................................................ 43
Mission.................................................................................................................................................... 43 The current infrastructure........................................................................................................................ 43 Survivable requirements.......................................................................................................................... 44

Conclusions to this chapter ............................................................................................ 45

Chapter VI – A Case Study – DHIAP....................................................... 47
DHIAP and our Role...................................................................................................... 47 Stakeholders................................................................................................................... 48 Description..................................................................................................................... 49
Unstated restrictions observed by the SEI............................................................................................... 50

Survivability Analysis.................................................................................................... 51
Evolution of Requirements ..................................................................................................................... 55

Conclusions to this Case Study...................................................................................... 55

Chapter VII – Conclusions......................................................................... 58 Chapter VIII – Future Work ..................................................................... 62
Survivability Definition ................................................................................................. 62 Survivable Solutions ...................................................................................................... 62 Survivable Architectures................................................................................................ 62 Survivable Requirements ............................................................................................... 63 Health Care Infrastructure.............................................................................................. 63

Glossary........................................................................................................ 64 References .................................................................................................... 65 Bibliography ................................................................................................ 69

-2-

Table of Figures

Figure 1. Survivable System Design Framework ............................................................. 17 Figure 2. Multidimensional Framework............................................................................ 23 Figure 3. Flow of Patient’s Health Information ................................................................ 29

-3-

Chapter I – Introduction
Our society is becoming more dependent on Information Systems. An important part of our society is dependant on large sets of systems that electronically hold the information needed to provide essential services. Our information is held by databases in insurance companies, in companies we have worked for, in medical systems, etc. Most of this information is accessible through public communication channels, such as the Internet.

Every critical system of our society is now dependant on information technology (IT). These systems are rapidly becoming integrated and dependant upon one another. This makes access to data imperative to banking and finances, health services, stock markets, commerce, etc, in order to successfully deliver their services. In other words, society is rapidly moving to a state in which it will be impossible to function without having all of this information available in a complex web of systems. The reasons for this are evident: reduction of costs, delivery of higher quality services, the development of a global economy, and a world united by telecommunication networks, among others.

While all of these benefits are invaluable for the evolution of the world, it is also true that successful malicious attacks are becoming more attractive and more feasible. Corporate and nation-state espionage, electronic terrorism, information warfare, loss of privacy, and identity theft, are examples of the inherent dangers associated with the creation of such system of systems.

Current approaches in security do not generally address these problems (i.e. interdependence, lack of control, untrustworthiness, among others) of highly distributed systems1. Traditional security technologies were not designed to protect systems against the evolving threats that result from the interconnection of systems that were not designed to be interconnected in the first place. These systems typically employ a

1

A good example were the recent distributed denial of service attacks that brought down amazon.com, ebay.com,

among others “.com” companies. (February 2000).

-4-

hierarchical design approach, appropriate for systems with centralized administration and coordination. But as will be seen later cannot provide a survivable solution in the context of unbounded systems.

Researchers have come to acknowledge the dangers of such a web of systems and have developed a new way to think about systems. Survivability is a new field of study that allow systems to survive, limit damage, recover, and operate robustly in the presence of attacks, failures, or accidents that, alone or in combination threatens their ability to fulfill their mission. Furthermore, survivable systems should be able to evolve and adapt to the environment where they provide services. This environment involves social and political situations, organizational changes, and improvements in technology.

The behavior of these systems is very much like the behavior of the interaction of our society, or the behavior of our economy. These are examples of what is known as emergent behavior. There are no central authorities; each component of the system cannot have a complete and accurate picture of the whole system; there is no single component that drives nor has control of the overall behavior. The reason for this kind of behavior is because the global properties that comprise this behavior “emerge” from local actions and interactions among the components of the system.

The design of centralized systems under these premises is complicated, and in some cases impossible. Emergent algorithms provide an alternative approach that is simple in concept. They depend only on local activities and near neighbor interactions in highly distributed systems. Emergent algorithms when applied to large number of components can lead to extremely complex behavior from which predictable global properties emerge. The Software Engineering Institute (SEI) at Carnegie Mellon University (CMU), and more specifically the CERT is doing fundamental work in survivability and emergent algorithms.

The main purpose of this thesis is to examine the health care infrastructure from a survivability perspective. It is a first step towards the definition of a survivable

-5-

infrastructure for the health services industry. Our analysis include all of the concepts introduced before in this document, and apply them to this specific infrastructure, including a case study where we had the opportunity to participate.

In the course of this research we have been challenged constantly with these concepts related to survivability. Survivability is a new field that provides many opportunities for new ideas. Therefore we were able to develop our own vision of how survivable systems should be designed. At the same time it is hard to find literature that addresses many of the issues raised by survivability.

Survivability, unbounded networks, and emergent properties are discussed in the next chapter. In chapter III we explain the development of a framework for identifying, validating, and applying mission critical requirements. In chapter IV, we introduce the health care industry, its evolution, its relationship with Information Technology (IT), and why we believe it is a critical infrastructure. In chapter V we apply survivability and related concepts to the health care industry, and we elicit a set of necessary survivability requirements. In chapter VI we describe our findings in a case study involving a U.S. Army medical treatment facility, and draw conclusions on the design of a system for that facility. Also, we relate our findings in this case to findings for the U.S. health care industry as a whole. We give our conclusions in chapter VII. And finally in chapter VIII we give our ideas for future research.

-6-

Chapter II - Concepts
Survivability Throughout the last decade, organizations have become more and more dependent on Information Systems (IS). Moreover, key sectors of our society are becoming increasingly dependent upon highly distributed IS that operate in unbounded networks such as the Internet [FL99]. For a definition of unbounded network, see Unbounded Networks section ahead in this chapter. These systems hold the necessary data on which the majority of the essential services2 rely. There is an increasing risk3 to our society due to these systems’ vulnerabilities4. In the presence of these threats5 and the inability of traditional security approaches to protect such large distributed systems, there is a pressing need for a way to develop systems that are able to survive, limit damage, recover, and operate robustly in the presence of attacks that cannot be completely repelled.

A survivable system must be able to protect against and react to any kind of attack, failure or accident that, alone or in combination, threatens the ability of a system to fulfill its mission in a timely fashion [EFL99]. Here the term system is used in the broadest sense, including networks and large-scale system of systems.

A fundamental assumption underlying survivability is that no individual component of a system can be made immune to all attacks, accidents and design errors [FL99]. Several factors are behind this assumption: 1) Testing and formal verification techniques in current software engineering practice have serious deficiencies; 2) Usually the assumptions (either implicit or explicit) under which the systems are designed are at least

2 3

In this context essential services refer to services that are indispensable to the functioning of the society. A Risk is a potential problem, with causes and effects; to some authors it is the harm that can result if a threat is

actualized; to others, it is a measure of the extent of the harm, such as the product of the likelihood and the extent of the consequences.[Neu95]
4 5

A Vulnerability is a weakness that may lead to undesirable consequences. [Neu95] A Threat is the danger that a vulnerability can actually lead to undesirable consequences – for example, that it can be

exploited intentionally or triggered accidentally.[Neu95]

-7-

partially wrong. For example, we assume that the requirements are complete and correct, that there are no design flaws, that no harmful code has been inserted, that there are no malicious users, that the systems have not been altered improperly, and that the hardware behaves predictably enough that the worst failures cases are covered. 3) Humans are fallible. 4) There are circumstances beyond our control, such as natural disasters. 5) The development community tends to be slow in adopting emerging research and development concepts that are practical, and in discarding other ideas that are not practical. 6) All potential situations are difficult to forsee, especially those related to the interaction of different parts of the system. 7) Finally, the majority of systems are built on commercial off the shelf products (COTS), these products are usually well known to a large group of people, including attackers, so COTS products have been previously tested and their vulnerabilities are known, and are ready to be exploited. More information on these subjects can be found in [Neu95][Bro95][LF99][GV99].

Having in mind that no system or any of its elements is infallible is already a major step towards the design of survivable systems. As we will see later on in this document, probable solutions to the design of survivable systems are based on components that can be compromised, but that do not lead to compromise the overall mission. The ultimate goal of survivability is to fulfill the mission even when significant portions of the system are damaged or destroyed [EFL99].

In addition to the pressing need for systems that deal with the increasing number of failures and attacks, systems must be developed to survive changes in the environments in which organizations must operate [TBK99]. Systems developers have been designing systems that are stable and that require low maintenance. Therefore systems tend to become obsolete, because they cannot react rapidly to changes in their environment. In consequence, they become an obstacle to organization’s adaptation to the changes in the environment that surrounds them. Changes in the environment may be represented as shifts in market demands, changes in regulation policies, technological advances, etc.

-8-

Organizations are continuously evolving, the resulting behavior, generally known as organizational culture, is also in constant change and adaptation.
IS have come to constitute an important part of an organization’s culture, helping in many cases to shape it, to modify it and to leverage it. IS have become an indispensable piece in the organizational puzzle, thus an organization depends on them to succeed in today’s complicated-always changing environment.

This “emergent behavior”, where emergent refers to the state of being in continual transition and never achieving a final state [TBK99], is both driven by and is driving the development of IS within an organization. Obviously, this implies that the IS should be able to adapt to the new organization model, that is to say that IS never reach a final state, but rather are always adapting to the new demands and new needs of the
organization.

So we extend the concept of survivability to the capability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents, and at the same time its ability to evolve to meet continual changes in an organization and its environment. Survivability Properties As we mentioned before, survivable system design is not intended to provide infallible systems because this is not possible, “but rather to provide some assurance that the most likely and most devastating compromises are properly addressed by the design, and – if compromises do occur – to be able to determine the causes and the effects, to limit negative consequences, and to take appropriate actions.” [Neu99]. Thus, building on the properties expressed in [EFL99] and extending them into our new survivability definition, survivable systems must evidence the following four properties:
• •

Resistance: capability of a system to repel attacks. Recognition: capability of a system to identify that is being attacked, or misused, that users’ patterns have changed, and to understand the state of the system. This is actually necessary to achieve recovery of the system, so it could be seen as the primary step towards recovery.

-9-

•

Recovery: capability to restore services during and after attacks, malfunction, and misuse.

•

Adaptation and evolution: capability to adjust to the dynamic environment that surrounds a system, involving changes in technology, attack patterns, changes in organizational structure and culture, changes in users behavior (including attackers), and changes in social and political situations.

Minimum levels of a system’s quality attributes can also characterize survivable systems. In [EFL99] these attributes include security, reliability, performance, availability, fault tolerance, modifiability, and affordability. We can see the intrinsic relation between these attributes and the properties we mentioned before. We can interpret this new set as a composition of functional and non-functional attributes that in the context of the mission, as we will see later, are quite useful when eliciting the requirements for designing survivable systems.

Building on research on perpetual testing [PT00], we incorporate the idea of perpetual design. Once a product is in operational use, further changes are typically only for maintenance, and do not to alter the basic design approach. We have become used to the “patching” philosophy of software vendors, where flaws in the design are “fixed” through patches. Experience has shown that, in most cases, new versions of the same software/system focus on new features and functionality, but have similar flaws that arise from the same failures in the original design.

The perpetual design approach is the one where the design of the system never ends. The design team of a specific system or product is always revising the design of the system, getting the feedback from the users and tuning the system/software so that copes with the dynamics of the real world, including attacks, advances in technology, changes in the organization, and changes in the users’ needs.

- 10 -

Unbounded Networks In order to provide the new, highly sophisticated, information-based services that societies are becoming dependent upon, systems that were at one time isolated are becoming a complex web of networks. These information networks are being used to achieve new levels of integration that go beyond the traditional organizational boundaries and transform formerly local isolated processes into processes that are part of a more complex, comprehensive, and coherent global process [EFL99]. As a consequence there is an inherent shift from bounded networks with central coordination and administration to unbounded networks. The success of survivability will be dependent upon gaining an understanding of how these complex infrastructures operate.

Bounded systems are those where all parts are controlled by a unified administration, and can be completely characterized and controlled. In contrast, unbounded systems are those that cannot be controlled by a unified administration, and cannot be completely characterized. An unbounded system exhibits the following characteristics: • • • • • • Multiple administrative domains without central authority Absence of global visibility Interoperability between administrative domains determined by convention Widely distributed and interoperable systems Legitimate users and attackers envisioned as peers in the same environment Impossibility to partition the system into a finite number of bounded environment

The Internet is a major component of the underlying technical infrastructure and therefore a major component of the information infrastructure [PCC97]. “The Internet is the collection of loosely connected networks worldwide that are accessible by individual host computers through a variety of gateways, routers, dial-up connections, internet access providers, and internet service providers”. The Internet is an example of an unbounded network, because there is no global administrative control to enforce its policies and conventions [EFL99], and no single entity has global visibility into the network.

- 11 -

In general, the use of the Internet enhances the ability of organizations to conduct their activities in a cost-effective and efficient way [EFL97]. However, the Internet is seriously vulnerable to denial of service attacks, losses of confidentiality and integrity, and collapse of constituent nodes [Neu99]. Therefore, the current state of the Internet cannot guarantee the high degree of availability, reliability, integrity and privacy that industries such as the health care industry require. Designing systems for the Internet presents challenges that current approaches are not able to successfully address. Emergent Algorithms Some interesting approaches to address the design of survivable systems can be seen in social, biological, and economic systems. This is because the key features of survivable systems are the same that nature has already solved. The immune system behaves in such a way that it is able to adapt and protect our bodies even in the presence of unknown malignant cells [SSF97]. The characteristics of the immune system address many of the issues presented in an unbounded network (i.e. distributability, diversity, disposability, adaptability, autonomy, anomaly detection, identity via behavior, untrustworthy components, among others).

The stock market is also a good example of a system that emerges from the interaction of independent agents [Ode98]. No single component of the system is able to significantly impact the market, however a combination of independent actions from different individuals can, for example, crash the market.

Our society is also a system that has emerged from individual actions, where individuals acting alone lack the ability to change the whole system. Along the same line of thought, insect societies such as ant or bee colonies have developed ways to adapt and evolve with their environment and ultimately survive over time [Ode98][WS00][BT00].

Emergent behavior or emergent properties are illustrated by the above examples. Formally, “emergent behavior is the formation of complex behaviors or characteristics

- 12 -

through the collective, simple and autonomous behaviors or characteristics of individual entities” [WS00].

Designing survivable systems is a rather difficult task. Emergent algorithms offer a potential solution to the design of these systems. Emergent algorithms are based on the emergent properties that arise from the actions, and the interaction of independent components.

Fisher and Lipson in [FL99] defined an emergent algorithm as: “any computation that achieves formally or stochastically predictable global effects, by communicating directly with only a bounded number of immediate neighbors and without the use of central control or global visibility”. This definition explicitly states that an emergent algorithm produces global effects through cooperative local actions distributed throughout a system. Characteristics of Emergent Algorithms (A detailed discussion of these characteristics can be found in [FL99]6).
•

Distribution of results. An emergent algorithm may produce results that are distributed globally but do not exist locally, that are entirely local, or that are represented both locally and globally.

•

Communication with immediate neighbors. Each of the nodes executing an emergent algorithm can communicate directly only with a number of immediate neighbors bounded by a constant.

•

Lack of global visibility and/or central control. Nodes are not able to read or change the state of nodes beyond their neighbors. Participants must be effective with only incomplete, and imprecise information.

•

Results dependent on distributed information. Results are dependant on distributed information among the nodes that are executing the emergent

6

[Ode98] presents a set of characteristics that describe emergence in general. It is easy to correlate his classification

with the one provided in [FL99]. We used the one in [FL99] because it gives practical characteristics that help to develop an emergent algorithm, instead of general characteristics that will only allow us to describe a desired emergent behavior.

- 13 -

algorithm. The number of nodes involved in a local computation is independent of the total number of nodes within the network.
•

Undirected communication. Given the distributed nature of these algorithms, and the lack of global visibility and central control, it is generally not possible to know when and where needed information resides. Therefore, nodes must send available information that might be needed even when that information is not requested. This is known as “cooperation without coordination”. This property replaces other types of communication. Even though the resulting traffic may be higher, this information can be transmitted as low priority messages, or when the network is not highly congested. At the same time, this property has the effect of rapidly diffusing information to where it may be needed, even in cases when information sources and destinations are unknown.

•

Unpredictable environment. Emergent algorithms are inherently distributed in character, often involve unreliable information and untrustworthy participants, may be implemented on dynamic platforms that are not fully known, and may involve compromised components. The result can be a stochastic behavior that is not inherent in the algorithm but arises from the application domain.

Examples of applications of emergent algorithms include message routing, detection of intruder incidents, domain name translation in the Internet, protection of critical infrastructures, and safety critical applications involving highly distributed components [FL99].

Several projects lead by the CERT research group at Carnegie Mellon University, are using this approach to address problems like the ones we have described before. Current projects include the development of Easel, which is a simulation environment for emergent algorithms [Fis99], a survivable routing algorithm, modeling of social networks, and modeling of neural networks.

- 14 -

Conclusions to this chapter Survivability is a new approach to achieving mission fulfillment in the context of unbounded systems. Compared to traditional software engineering, survivability is a change in the way we perceive, study, and design systems. Systems should no longer be designed as static entities, but instead should constantly evolve and adapt to the environment that surrounds them, they have to be prepared to resist, recover, recognize, and adapt. Moreover, these systems are part of unbounded networks, which changes the context in which we are used to thinking about systems, so that current approaches for system design are no longer appropriate. To deal with all of these premises (i.e. the ability of systems to resist, recognize, recover and adapt, and operate in unbounded networks) we discussed what we believe is a well-suited solution called emergent algorithms.

- 15 -

Chapter III – A Framework for the Design of Survivable Systems
The main purpose of this framework is to provide designers with a tool that helps them in the design of survivable systems. There are two characteristics we want to emphasize about this framework. First, the mission in our framework is tightly related to the organization’s mission. The mission should be defined to be technology independent, and stable over long period of times. Second, this framework dynamically incorporates the feedback from the context of its implementation and use, allowing it to adapt and evolve to its changing environment, thus allowing it to survive7.

A framework for thinking about requirements and specifications may prevent design failures that can stem from overlooked requirements or over constrained implementations. For example, in the health care industry, according to a study made in the United Kingdom [GKK95], approximately 70.8% of the flaws in automated health IS are introduced at the requirements/specification phase.

The framework depicted in Figure 1 can be viewed as a layered structure of abstractions, where the mission is the most general and therefore the most abstract layer. The mission requirements or survivability requirements would be the next layer. The survivability requirements are more constrained, but only by virtue of their specificity, and not by design decisions. The system requirements layer contains very detailed requirements and is highly constrained by the limitations of available technology, and thus determines the bounds of feasible solutions in the current context. Finally, there is a the design and implementation decisions layer that reflects the necessary tradeoffs to implement the system in a cost effective manner.

7

Previous research in survivability requirements can be found in [LML98], and more recently in [Neu99]

- 16 -

Mission The mission constitutes the purposes of a system, an organization, industry or infrastructure. These purposes should be explicit, concrete, and stable, otherwise it will be impossible to determine whether the mission was fulfilled or not.

Mission
Threat Scenarios Technology Costs Cultural and Social

Mission Requirements

Mission Requirements

Mission Requirements

Survivability requirements
System Requirements System Requirements System Requirements

System requirements

To clarify this concept we can take a look at the U.S. Health Care Infrastructure (USHI). After studying the evolution of the USHI (a detailed analysis will be presented in following chapters), we have selected the following mission for the purposes of this thesis “To enable the timely delivery of health care services of high quality within the United States”. As we can see, this definition is bounded in terms of services, constrained in terms of time and geography, and it is qualitatively measurable. This makes the

Constraints

Evaluation

Optimal Solution

Tradeoffs

Time

Design and implementation decisions

Figure 1. Survivable System Design Framework

- 17 -

definition explicit and concrete. This mission is also stable, meaning that it is unlikely to change over long periods of time. Last but not least, notice that this definition, though concrete, is broad and it is not limited by a list of “how-to’s”. In fact, its interpretation will change over time as a function of available medical technologies, and changes in society’s expectations for quality in health care. Mission/Survivability requirements A mission requirement is any requirement that must be satisfied in order to fulfill the mission. As we can see from the definition of survivability, mission requirements are essentially the same as survivability requirements. The only difference is that survivability requirements presume an implied extension to the mission to support evoultion, meaning that a survivable system should be able to survive the changes in the environment that surrounds the organization. Therefore the requirements need to include requirements necessary to make the system adapt, so it can survive throughout the lifetime of an organization. For the purpose of this research, we are going to extend the mission requirements so they match the survivability requirements, and treat them as equivalents.

By definition, mission requirements should be sufficient to fulfill the mission. That is to say that, in the ideal case, designers and stakeholders should be able to develop a set of necessary requirements that are sufficient to fulfill the mission. However, practice has shown that this task is rather difficult to accomplish. In the ideal case, the elicited requirements are both necessary and sufficient. It is relatively easy to recognize whether a requirement is necessary - if we forsee any way to fulfill the mission without that requirement, then the requirement is not necessary, otherwise it is likely necessary. On the other hand, it is often difficult to know that the set of requirements is sufficient. The reason is that designers must be able to forsee the combined consequences of all the necessary requirements. This is why in practice it is often necessary to add more requirements during the process. Going back to the USHI example, mission requirements include access to medical data whenever needed, from anywhere, and to all authorized users to the extent of their privileges. If we take a closer look, we can see that these are

- 18 -

necessary requirements, since it will not be possible to deliver health care with a certain quality if access is not guaranteed to interested authorized parties at any moment. Nonetheless, this is not a set of sufficient requirements, because with only these requirements we would not be able to guarantee the privacy of the data. This kind of feedback process is necessary to define a comprehensive set of requirements that are sufficient to the extent possible, but there will be no guarantee of their completeness.

Mission requirements should not directly reflect the current environment that surrounds the system to be designed. That is to say that they should not be described as a consequence of the state of the technology, social or political situations, nor the current state of the economy, among others. Instead there is an implicit requirement imposed by the concept of survivability that involves the context where the systems, organizations and infrastructures operate; this is evolution.

Evolution is manifested in this framework as a mission requirement. We believe that evolution is not specific to any particular mission. That is to say, that evolution is a mission requirement by itself, and though it reflects on the system requirements as a consequence of the changes in the context, the instances it may take are probably not particular to any application domain. We will describe a more in-depth approach to the evolution of requirements during the system requirements discussion below. System Requirements The system requirements describe the correct behavior of the system taking into account the constraints imposed by the external environment. Thus, mission requirements must be further stressed and categorized to facilitate the design and implementation of a system. These requirements specify the feasible options for a solution at that particular time, in specific environments, with the current technology upon which the services are to be offered in order to fulfill the mission. System requirements are then shaped by the different constraints imposed by threats, available technology, cultural and social environment, costs, and time. These constraints are inherently dynamic. The technology changes, threats evolve as the environment changes, the cultural and social constraints

- 19 -

change as a consequence of organizational structure change and adoption of new technology, and finally investment in maintenance and deployment of systems varies as well. Therefore, system requirements can and should change over time adapting always to the environment that surrounds the system.

Next, we define the types of constraints that shape the mission requirements into system requirements: Constraints on Survivable Systems Design • Threat Scenarios.
Once the mission requirements are elicited/stated, it is necessary to expose them to the different threat scenarios and elicit the needed non-functional requirements, such that the system to be built can be resistant to the possible threats and guarantee the fulfillment of the mission. • Constraints imposed by the available technology. Technology in some cases is not cost effective enough to be commercially available and in other cases it has not been widely deployed. In a way that is to say that, in some cases, what technology can achieve is limited. • Cultural and social constraints. The culture of a community varies from country to country, from region to region within a country, from religion to religion, and from organization to organization. In some cases, depending on the application domain, these issues will impose constraints that might impact the design of the system. • Costs. Even when there is technology available, sometimes it is not accessible to every organization due to the cost involved in its acquisition. In other cases, the successful implementation of a system or a policy relies on a change in the structure and culture of an organization, which has significant costs that sometimes make the change infeasible. • Time. Constraints imposed by time can be interpreted in two ways: a) response time of
systems, and b) time to develop and implement a system, or a component. The former interpretation goes back to the definition of survivability and the delivery of services in a timely manner; this is strictly related to the response time of a system or

- 20 -

its components. The latter refers to the timeframe available to develop and implement a system. Both interpretations can impose important restrictions on the system design. Evolution of systems requirements Bearing in mind that the context in which systems exist is always changing, it is necessary that organizations, systems, or infrastructures evolve to meet the new characteristics of the external and internal situation that stemmed from these changes. As put by Dorothy Leonard in [Leo95]: “Companies survive on their ability to adapt when necessary, and it is increasingly necessary for them to do so”. The dynamic environment we live in obligates organizations to evolve; otherwise they will most probably fail to provide competitive services and will ultimately disappear. Implicitly we are assuming that organizations in most cases are involved in some kind of competition.

The way most organizations are successful is by providing optimal services given the context at the point in time when these services are being offered. That is to say, the organizations that are able to evolve, and are able to offer services better adapted to the current situation are more likely to be successful than their competitors. The evolution can be instantiated, for example, as an adoption of a new technology, the incorporation of a new process or methodology in the core business processes, new marketing methods, etc. The key is to incorporate features that address changes in the context either externally or internally, and to be able to evolve to cope with these changes.

The evolution of requirements directly affects the system requirements layer in the framework. This evolution determines how the system, organization, or infrastructure responds to the dynamic nature of the constraints reflected in user requirements for new functions, or reflected in new requirements for responding to evolving threats such as an intruder’s knowledge of the system’s behavior and structure. Evolution as a requirement was first addressed in [LML98].

The result of the systems requirements elicitation is a set of feasible solutions for the design of the system. That is to say, any one of the solutions that meets the system

- 21 -

requirements is guaranteed to fulfill the mission (assuming that we elicit a complete set of mission requirements). If there is no way to elicit a set of system requirements that meet the constraints, then the mission of the system, organization, or infrastructure, has to be changed, and the layers below have to be redone again. Design decisions Given the different sets of feasible solutions resulting from the system requirements elicitation, the problem narrows to deciding which features of the different possibilities are more cost effective. What drives these design decisions is different from one group of designers to another. We believe that all designers should look for an optimal solution. But, again, deciding what are the optimization criteria is implicitly vague, since which optimization criteria to be used to design a system depends on the designers’ beliefs. Regardless of the beliefs of the designers, we think that in most cases the optimal design should be related to those functions of the system that are most relevant to the fulfillment of the mission. Therefore, it seems that the people that hold the best information to decide on the criteria should be the same as the people that specified the mission requirements.

Finally, making the necessary tradeoffs such that the requirements that guarantee the most relevant functionality of the system are better satisfied should drive the design decisions. Implementation Going from the design to the implementation should be a straightforward task if all the previous steps were correctly accomplished. Proposing a method to manage the implementation to successfully deliver an operational system is out of the scope of this document.

We believe that these definitions take into account some of the most important issues that may arise in the design of a survivable system. All the previous descriptions of requirements account for the framework. Any of the requirements layers in the framework can also be thought in terms of functional and non-functional requirements; in

- 22 -

fact, we believe this facilitates the design and implementation decisions. Figure 2 shows the second dimension of this framework.

Functionality

Attributes

Mission
Functional Requirements Non-functional Requirements

Survivability Requirements
Functional Requirements Non-functional Requirements

System Requirements
Figure 2. Multidimensional Framework Functional requirements Functional requirements describe the functionality of the system. The functionality of the system is, in most cases, conditional to the environment that surrounds it. That is to say, in some cases threats can gracefully degrade the functionality of the system (expressed in terms of services) and in other cases they can completely change the necessary set of services because priorities might shift. To illustrate, we can think about this in the extreme case. Let’s say that we have a system whose service depends on being accessible all the time. Therefore accessibility becomes the first priority in the system. In the case of an earthquake perhaps the system does not need to be accessible, since most of its users would not have access to normal telecommunication channels to use the system. In that case the highest priority might be the backup and preservation of the data and not the availability of the system. Therefore, the specified behavior and functionality of the system may be different under normal and extreme.

- 23 -

Non Functional requirements Non-functional requirements are those that allow a system to be quantitatively and qualitatively measured. These can also be thought of as a set of system quality attributes [BB99], which can vary depending on the design decisions. From the set of nonfunctional requirements, we have found it helpful to characterize survivable systems in terms of security, reliability, and performance8. •

Security: includes integrity of systems and networking, confidentiality to avoid dissemination of information that could be useful to attackers, high availability, prevention of denials of service despite malicious actions, authorization, accountability, rapid detectability of adverse situations, and prevention of other forms of misuse.

• •

Reliability: includes fault tolerance, fault detection and recovery, and responses to unexpected failures modes. Performance: in order for the other two properties to be valid, it is important that they achieve their functionality in a acceptable “timeframe”; performance properties will assure that the techniques used to implement the needed security and reliability provide the desired survivable behavior.

To demonstrate this argument, let’s think back to the mission definition in terms of functional and non-functional requirements. The mission expresses the services a particular system, infrastructure, or organization is suppose to offer, and at the same time these services are characterized by a set of quality attributes, which provides the measurable properties that ultimately will give us the opportunity to know whether the mission was fulfilled or not. The functional requirements will describe the functionality of the mission, and the non-functional requirements will describe the set of quality attributes that shape those services.
8

A detailed discussion on these attributes, and why they characterize survivable systems can be found in [Neu99].

There is also a more comprehensive set described in [EFL99], but [Neu99] simplifies them in the classification we presented: security, reliability and performance. It is also important to notice that these are the attributes that best characterize survivable systems with current technologies. As technology evolves this may not be longer true.

- 24 -

This division in functional and non-functional requirements should be taken into account at the mission requirements layer, and the layers below. Therefore, having the solutions in terms of functional and non-functional requirements will facilitate the design and implementation decisions, such that designers can have a better idea of how to measure the degree of these quality attributes and can better satisfy the functionality of the mission. Eliciting requirements This section is not intended to provide a comprehensive set of tools to elicit requirements9, nor a list of steps to follow to achieve the requirements necessary to fill the different layers of the framework we just described. Instead, this section will only describe one aspect of requirements elicitation that we find extremely important and system designers overlook most of the time, and that is highly relevant to survivability. This aspect of requirements elicitation involves threat scenarios. Threat scenarios Elaborating on the definition of UML’s Use Cases [BRJ99]: “ A use case specifies the behavior of a system or a part of a system and is a description of a set of consequences of actions, including variants, that a system performs to yield an observable result of value to an actor”. Actor in this definition is related to any component of the system that is interacting as the receiver/ performer of the action we are describing.

The purpose of eliciting threat scenarios is to think ahead and determine which scenarios threaten the ability of a system to perform the services that will allow it to fulfill its mission. Threat scenarios will give us better insights into how systems we are designing can resist, recognize, recover, and evolve in the face of attacks, malfunctions, and failures of the system. Being able to overcome these scenarios is no guarantee that our system will be survivable, but this will definitely improve its chances.

9

A good approach in understanding what requirements are and how they should be elicited can be found in [Jac98] and

[Bro95]

- 25 -

We must not forget that threat scenarios include those where attackers/intruders hide themselves under the proper functionality of the system. That is to say that intruders may engage in illicit use of the system through legitimate user scenarios. To recognize the modus operandi of intruders/attackers is rather a difficult task10. Conclusions to this chapter We have proposed a framework to design survivable systems. We hope that this organized way of thinking will allow systems designers to improve the survivability of systems they design.

Whether the systems designed with this framework are going to be survivable or not will depend on the designers of the system. This framework is useless if the mission is misstated, if the requirements are incorrectly elicited, or if the system is not updated to reflect changes in the context. Ultimately, the responsibility resides with systems designers - this framework is a tool that if used correctly can lead to the design of survivable systems.

10

To deal with these scenarios is one the purpose of a comprehensive realm of study called Intrusion Detection.

- 26 -

Chapter IV – The Health Care Services as a Critical Infrastructure
The purpose of this chapter is to understand the health care industry, how its evolution is driving and being driven by information technology, and to justify why a health care infrastructure is just as critical as other national infrastructures. We will see that the evolution of the health care industry has led to a complex web of highly distributed systems that can be better characterized as an unbounded network. We hope that by the end of this chapter two things become clear to the reader: the critical importance of the health care services infrastructure and the impossibility of having central control in the evolving health care industry. The National Information Infrastructure “In an era of global markets and global competitions, the technologies to create, manipulate, manage and use information are of strategic importance for the United States” [NII00]. This is a primary reason why the U.S. government proposed a National Information Infrastructure (NII). The NII envisions a complex web of physical facilities used to transmit, store, process, and display voice, data and images, that relies on the quality of: • • • The information itself. Applications and software that allow users to access, manipulate, organize, and digest the information. The network standards and transmission codes that facilitate the interconnection and interoperation between networks. Standards and transmission codes ensure the privacy of persons and security of the information carried, as well as the security and reliability of the networks. • The people, who create the information, develop applications and services, construct the facilities, and train others to tap its potential.

This vision led to the publication of “Critical Foundations, Protecting America’s Infrastructures – The Report of the President’s Commission on Critical Infrastructure Protection” [PCC97]. Within the PCCIP report, infrastructure is defined as a network of

- 27 -

independent, mostly privately-owned, manmade systems and processes that function collaboratively and synergistically to produce and distribute a continuous flow of essential goods and services. Critical infrastructures are defined as those that provide essential services that guarantee national defense, economic prosperity, and quality of life. The critical infrastructures recognized in the report are: transportation, oil and gas production and storage, water supply, emergency services, government services, banking and finance, and telecommunication.

Although health care was not recognized as a critical infrastructure when the CCIP was written, it is important to notice that at that point in time the different elements (among them Healthcare Maintenance Organizations - HMO, Integrated Delivery Systems - IDS, and Electronic Medical Records - EMR) did not have the relevance and importance they do today. HMO especially did not have the influence they have now. Furthermore, the health care infrastructure brings together a large number of stakeholders (Figure 3), which forms a far more complex network of applications than do any of the other recognized critical infrastructures. For example, the health care infrastructure allows the integration of business processes from manufacturers (pharmaceuticals) to distributors (insurance, HMO), and from distributors to deliverers (hospitals – government) [WS98]. As we said at the beginning of this document and will extend in the next chapter, the mission of the health care services infrastructure is to deliver health care services at a certain level of quality within the U.S.. In order to achieve this mission the health care infrastructure needs to carefully assemble the functionality of each of its components, otherwise lives may be compromised. Thus, the health infrastructure is crucial.

The Council of Competitiveness in its 1996 report [CC96] recognizes that NII’s tools and technologies offer the potential to expand access to health care, improve its quality, and reduce its cost. We will see later in more detail how the use of technology is driving and is being driven to fulfill these goals. In 1996 research funds were granted from the National Library of Medicine (NLM) to different medical institutions and research groups in different U.S. states “to develop health care applications for the national health

- 28 -

care infrastructure” [NRC97]. For a complete description of the projects the NLM is currently funding, refer to their web page at [NLM00].

Patient’s Employer Employer’s Clinic & Wellness Program Health Insurance Company Spouse’s Self-insured Employer Clinical Laboratory

Consulting Physician

Patient’s Health Record

Care Provider (Physician, Hospital)

Short Term Repository
State Bureau of Vital Statistics

Long Term Repository Temporary Access Identified Health Info

Retail Pharmacy

Managed Care Organization Accrediting Organization

Medical Researcher

Unidentified Health Info

Pharmacy Benefits Manager

Life Insurance Company

Medical Information Bureau

Lawyer in Malpractice case

Figure 3. Flow of Patient’s Health Information

We could interpret the evolution of the health care industry as a shift in target from health organizations to patient centered care in which emphasis is placed on continuity of services for supporting health promotion and maintenance [WS98]. This new focus implies that the functionalities of the different units of service that provide comprehensive services are transparent to the user (see description of HMO and IDS later on this chapter). Information technology plays a key role in the achievement of this transparency. We will spend the next section of this document explaining how information technology is enabling the success of a national health care infrastructure, and also how the pressures in the market for reducing cost and delivering a higher quality of service is driving the technology.

- 29 -

Health Care Industry Evolution and the Role of Information Technology (IT) The health care industry spends approximately $10 to $15 billion a year on IT and is expected to grow by 15% to 20% a year for the next several years [Mun96]. Historically, clinical medicine, though information intensive, has been an area where computers have had limited access to data, except in specific areas such as billing and scheduling, laboratory result reporting, and diagnostic instrument systems [Rin97] [Ste97]. Nowadays, the use of IT has invaded all aspects of the health industry. The need for reliably diffusing (accessing) information among different entities within and outside of an organization at a lower cost has been driving the demand for technology [NRC97]. Therefore organizations have been both using the current public telecommunications infrastructure and building their “own”11 private infrastructure to allow better communication and flow of information among parties involved at a lower cost.

The involvement of IT has responded to the pressures of reducing the cost of care, and has enhanced the ability to improve and measure the quality of care. Partially due to the involvement of IT in the field, The U.S. health care industry has gone through major changes in its structure. 1) There has been a significant consolidation of providers, and mergers of care-financing and provider organizations. 2) There has been an increase in the use of sophisticated management approaches to share financial risks for care between industry segments. And, 3) there has been an increasing number of new entrants into the market for the analysis of clinical practice [NRC97]. As a consequence we have been seeing (and most probably will continue to see) the formation of IDS, HMO, and EMR. Integrated Delivery Systems (IDS12) In the realm of health care, vertical integration refers to coordinating, linking or incorporating within a single organization the activities or entities at different stages of the production and delivery of patient care [CD90]. IDS are systems that have integrated

11

The majority of organizations buy the services from telecommunication service providers to build their “own”

private networks. In many of the cases the communication channels provided are connected to the public network.
12

Given the potential audience of this document it is important to not confuse IDS with Intrusion Detection Systems.

Throughout this document the acronym IDS refers to Integrated Delivery Systems.

- 30 -

a range of facilities, services, and providers (including physicians). The main purpose is to contract with (or arrange for) purchasers to provide and coordinate the full range of health care services for a defined population. At the same time, IDS accept financial risk for managing the health care of this population within fixed payment limits [KZR95].

As we said before the move toward IDS is motivated mainly by reduction of costs and higher quality of health services. It is expected that these goals are achieved by consolidations, by expansions of market shares to protect current business, by managing care over a continuum of time and encounters, and by increasing bargaining power with respect to payers [NRC97]. “Having a full spectrum of services under a single organizational umbrella enables a delivery system to accept responsibility for the entire continuum of care, to coordinate care, and to place patients in the most appropriate setting. Having the full spectrum also enables resources to be allocated more rationally internally to expand or downsize services in accordance with the needs of the population served, and it minimizes transaction costs across settings” [KZR95]. As we can see IDS provide the infrastructure to improve the quality of service and greatly reduce the costs complying with the rationale expressed before.

For all this to be a reality, IDS envisioned the development of integrated information systems as critical [NRC97]. In a survey conducted by Deloitte and Touche [DT96] states that 67% of all hospitals are pursuing the development of an integrated information network. Information systems should be developed to integrate data from the different stakeholders and back-offices systems, and also should be developed to share medical information efficiently and effectively. Healthcare Maintenance Organizations (HMO) This brief section on managed care is not intended to provide a comprehensive guideline on the different institutions or different programs, nor to debate whether they are a good service for the community or not. The purpose of this section is to give a better understanding of the evolution of the health care industry, and its impact on a national infrastructure.

- 31 -

Managed care organizations are organizations that are accountable for the health of an enrolled group of people. They are held responsible for the health of enrollees and, as a consequence, seek improvements in both the results and cost effectiveness of the services provided. Managed care programs, in contrast to traditional forms of insurance, use a partial or full capitation13 system to pay for health care and manage risk [NRC97].

The managed care program can be presented in many forms, all of them based on the ideas stated in the previous paragraph. The types differ, in a sense, with respect to the degree of freedom the customer has access to, and in how the providers are organized.
•

Individual Practice Associations (IPAs): Physicians are prepaid a capitation rate by a managed care organization on a monthly basis for service to members.

•

Group Model HMO: An HMO contracts with a group of physicians that continue to practice in their own offices, but pool and distribute income based on an agreed-upon plan.

•

Network Model HMO: HMO contracts with several groups and /or individual physicians that share the savings, and are also entitled to provide care to nonHMO members.

• •

Staff Model HMO: Physicians are employees of the HMO. Preferred Provider Organization (PPO): Offer the option to beneficiaries to receive services from providers who are not part of the “preferred”, or contracted, panel. Members pay a much higher portion of costs in exchange for this freedom of choice.

•

Point of Service (POS): Provide subscribers free choice of physicians and hospitals for many services, but require a higher co-payment and often a substantial deductible if the provider is not a part of the HMO or designated provider network.

13

Capitation is a method of reimbursement in which the providers are paid a fixed amount of money per each member

enrolled in a health care plan, rather than on the amount and nature of the service provided

- 32 -

No matter the form an HMO’s services take, they are all based on the premise that a health care system should work to keep people healthy, and provide efficient treatment when needed in the right setting and by the right person [IHA00]. There is an underlying assumption in this statement. Being able to provide the right treatment at the right place by the right person is not magic. In order to maintain the needed information to achieve these goals, HMO need to analyze and maintain large amounts of data. This will allow keeping track of the results of different treatments in terms of quality and costs, and thus make it possible to decide which treatment has shown better results at a lower cost [NRC97]. At the same time, HMO emphasize the need to manage care across a continuum of encounters in addition to managing care within a single encounter. Obviously this shift implies a new data-intensive approach that would be impossible without the existence of comprehensive IS. As stated in [DEJ99] “Managed care would be impossible without computers. It’s barely possible with computers”.

Moreover, the tendency is to integrate delivery services and HMO’ systems. The integration between delivery (IDS) and finance (HMO) can “… (1) Align incentives, (2) rationally deploy resources internally (which is almost impossible if insurers are paying each provider independently and often in contradictory manner), and (3) benefit financially from being efficient” [KZR95].

This integration will imply an even more complex network of IS. This complex health care service infrastructure will only fulfill its goals of reduction of costs and delivery of higher quality services if the underlying technical infrastructure is reliable, robust, able to resist attacks and able to evolve to adapt to the changes in the environment. Electronic Medical Records (EMR) One of the most controversial but inevitable issues within the evolution of the health care industry worldwide is any form of accessible collection of the history of a patient, i.e. an electronic medical record. The development of EMR represents a key aspect for the integration of IDS and HMO [NRC97].

- 33 -

Such importance has been given to EMR systems that its market is expected to grow to $1.5 billion in 2000 [HMT95].

The benefits of having an EMR can be summarized as follows [Ste97][NRC97]: 1. Accessibility. This is a key benefit in several aspects; first, access to the data could be restricted to only authenticated and authorized users. Second, access could be accomplished from (potentially) any part of the world. Third, the fact that the data could be accessed from any authorized user from any part of the world can (potentially) guarantee consistency of the information. Fourth, it is possible (and should be imperative) to keep track of who accesses the system at every moment, thus increasing the security of the system and increasing the accountability for the procedures applied to any patient. 2. Flexibility. The history of a patient is composed of different episodes in a wide spectrum of different areas: pediatrics, surgeries, ambulatory processes, and so forth. Text based records are essentially linear records that cannot capture the interdependence among the different episodes. Maintaining the patient’s record electronically allows for representing the relationships between these events (i.e. hyperlinks); the information could also be tailored to specific audiences and/or applications. 3. Availability. Researchers and any other entities interested in patients’ records will have access to a broader supply of constantly updated information, which could help in the development of new treatments, drugs, policies, and laws. 4. Assisted Decision-Making and Quality Assurance. Organizing data in a standard way leads to the development of applications that can be used to generate alerts, warnings and suggestions. Thus, computers could actively be used in the assessment of the quality of health service provided to a patient. For example, doctors sometimes cannot follow the interaction of different drugs that a particular patient is taking. A drug database can trigger alarms to doctors about potential problems arising from the intake of different drugs at the same time. From the point of view of managed care organizations, having EMR will keep track of all tests, therefore avoiding repetition of tests and thus saving costs.

- 34 -

Already, every major hospital within the U.S. has some form of EMR system, whether it is a simple system used only for storing and retrieving laboratory test results, or a more comprehensive system to record the whole patient history, including doctors’ and nurses’ notes [Ste97].

Despite all of the potential benefits, great controversies have arisen due to the issues relating to privacy, accuracy, accessibility, integrity, and confidentiality, among others, inherent to the availability of EMR through current telecommunication channels (e.g. the Internet). The information in a patient record ranges from illnesses, weights, and date of birth, to sexual behaviors, HIV status, and substance abuse, among others. Therefore access to this information in a context not related to health services is, in most cases, harmful to the patient. Disclosure of the information contained in a patient’s record can damage a person’s reputation for life. Making this information electronically available through public access channels, such as the Internet, increases the number of potential attackers, and thus the threat. However, as we will discuss later in greater detail, the real problem is not the Internet (or any other kind of technical infrastructure) but the widespread and unregulated sharing of medical information among all parties interested in a patient’s data, including insurance companies, heath care administrators, and government agencies [NRC97]. Conclusions to this chapter After having the chance to look at the results of the evolution of the health care services industry as demonstrated by IDS, HMO and EMR, it is easy to understand the critical importance of a national infrastructure to support these systems. The inherent characteristics of medical data make this infrastructure a clear target for malicious attacks. We will discuss in greater detail the underlying threats to the health care industry as an information infrastructure, and moreover the threats that differentiate the health industry from other infrastructures. Therefore the systems needed to support health care evolution and services have to be reliable, cannot fail even in the presence of malicious attacks or natural disasters, and moreover they will have to be able to cope with changes

- 35 -

in the environment that surrounds them. That is to say, the success of the health care industry will depend on the survivability of this unbounded network of applications.

- 36 -

Chapter V – Requirements for a Survivable Health Care Industry
In the previous chapter we reviewed the evolution of the health care services industry, and the role of IT. We also were able to justify the critical importance of a national infrastructure to provide health care services. This chapter focuses on the environment that surrounds the industry, the threats that medical services face, the social issues affecting the development of its infrastructure, and how regulations (or the lack thereof) impact the beliefs and disbeliefs of the different stakeholders, among others. With the information we have discussed in previous chapters, and with the description of threats and constraints shown in this chapter, we will have the chance to elicit what we believe are a necessary set of mission requirements for a survivable health care industry. We are sure that we are far from providing a complete set of requirements, but we do believe that the set we are going to present at the end of this chapter is a starting point towards the development of a survivable health care infrastructure. Given the time constraints for this research, we focused on the threats and restrictions imposed by the application domain, and on the survivability requirements to build the health care infrastructure. Future research should address in more depth the systems requirements, and the design issues that should drive an optimal design of these systems. Application Domain The technical infrastructure needed to support the evolution of the health care industry shares the same characteristics as other critical infrastructures that rely heavily on information technology and on the Internet. Moreover, these critical infrastructures in most of the cases are interdependent. For example, the health care industry is dependant on the electric power grid system, the oil and gas system, and the economy as much as it is on the Internet.

Already, the health care industry is taking advantage of the Internet, and this usage is expected to grow, as it has in other industries. A recent report by the California Health Care Foundation: “The Future of the Internet in Health Care” [MC99], recognizes four major forces that ensure the integration of the Internet into health care.

- 37 -

1. Health care consumers of the future will be more actively involved in making decisions about the health care they receive. 2. Consumer’s experiences in other on-lines activities, such as responsiveness and interaction, will shape the expectations they bring to health and health care. 3. The Internet is inexpensive, easy to use, provides a diversity of health care information, and opens its user to a global network of people with common interests. 4. Web technologies – intranets, extranets and the Internet – will serve as a low-cost, rapidly deployable platform for disseminating information across vertically and horizontally integrated health care organizations. Competitive health care organizations will use the web as a channel to promote their services.

Even though the use of the Internet imposes many threats, the major concern that people involved in health care services (either customers or providers) have always expressed regarding medical systems is privacy [NRC97][HPP99] [MC99][Rin97]. Most of the literature addresses privacy issues in great detail. However, it is important to recognize that the threats associated with an information infrastructure, as we previously described, are not limited to privacy. For example, there are a wide range of threats related to integrity, denial-of-service, and trustworthiness of information, which in fact are as important as are those related to privacy.

The majority of these threats, including those related to privacy, are indeed inherited from the information infrastructure, but they are also strengthened, and in some cases empowered by the lack of coherent health care policies. Threats After reviewing different threat classifications in the literature [NRC97][Rin97][MC99], we realized that all of these classifications address privacy issues using a similar approach. We describe below the one in [NRC97], a National Research Council (NRC) report.

- 38 -

Based on the resources available, the degree of access to the information, and the motive, the NRC report recognizes five threat scenarios. The author describes these scenarios as “Organizational threats”, because they can occur at an organizational level.
•

Threat scenario 1. Insiders who make “innocent” mistakes and cause accidental disclosures. Probably the most common source of breached privacy. For example overhead hall conversations, misclassified data, an email, etc.

•

Threat scenario 2. Insiders who abuse their record access privileges. Individuals that have access to data and violate the trust associated with that access.

•

Threat scenario 3. Insiders who knowingly access information for spite or for profit. When an attacker has authorization to some part of the system, but not to the desired data and gains access to that data by other means.

•

Threat scenario 4. The unauthorized physical intruder. The attacker has physical entry to points of data access but has no authorization to access the desired data.

•

Threat scenario 5. Vengeful employees and outsiders, such as vindictive patients or intruders, who mount attacks to access unauthorized information, damage systems, and disrupt operations. (In the literature this threat also includes denialof-service attacks, even though the focus is on privacy issues).

Interestingly, these same scenarios can be applied to other realms of threats, such as those related to integrity, trustworthiness, and denial of service.

Data integrity is a major concern, especially in medical services. For example, an attacker can compromise the life of a patient if he changes the information on particular doses of a specific medicine. At the same time changing information in the EMR and then publishing it can lead to irreparable damage to a patient’s reputation.

Data integrity is tightly related to threats derived from the untrustworthiness of the information available. It is not easy to know whether the information available on the web is reliable, accurate, or precise. Average Internet users believe what they see on the web. But, how do they know whether the source of information is trustworthy or not?.

- 39 -

The reality is that the inherent characteristics of the Internet will provide different, “cheaper”, sources for health care advice. The problem arises with the impossibility of regulating this information. The quality of information published on the Internet is impossible to control (though access can be at least partially controlled), therefore patients seeking cheap advice can go to the web, but the results may not be those desired.

The Internet is also seriously vulnerable to denial-of-service attacks that affect the availability of medical services. The threats might be serious enough to jeopardize a patient’s life since denying access to medical services in emergency situations can be deadly.

It is relatively easy to understand how the previously described scenarios can exploit threats related to privacy, trustworthiness, and denial of service.

Another set of threats is related to the system that provides health services, described as “Risks Created by Systematic Flows of Health Information”. These threats arise because multiple entities are interested in patient/customer medical information. (Figure 3 – page 33) demonstrates the number of entities that directly or indirectly are interested in the medical data). The threats arise as a consequence of the lack of a policy that describes how, and to what extent medical data can be used. There are differences in the understanding and interpretation that each stakeholder has regarding the appropriate use of information provided by a patient, and more importantly these interpretations usually greatly differ from patients’ understanding. This differentiates the health care services industry from the military, and from the financial institutions, where global policies that dictate information usage are in place.

The issue of EMR further increases the fear of patients. People fear that their EMR are going to be linked to all classes of information, and if this information is inappropriately divulged or commercialized it may have irreparable consequences. In a survey released on January 1999 [GZ99], roughly half of the population interviewed felt EMR were the greatest threat to privacy. The same survey showed that approximately one in six

- 40 -

Americans engages in some form of privacy protection through either withholding information, avoiding doctors, giving wrong information, or in some cases avoiding care in general.

Even though EMR and the technical infrastructure exacerbate the technical concerns, the most important issue to address is the lack of a coherent policy that regulates the usage and disclosure of private information across the increasing number of stakeholders [NRC97][MC99].

The sets of threats we presented are not complete, however we believe that these examples demonstrate their diverse nature. We also hope to have demonstrated the delicate character of medical data: its violation, in most cases, threatens a patient’s reputation, and in many cases their life.

Constraints In addition to the large set of threats we have already talked about, there is also an important set of issues that will constrain the design and implementation of a large medical infrastructure. Again, we do not expect to provide a complete set of constraints, but we do expect to show the diverse nature of these constraints, and thus their importance to building a survivable health care infrastructure. The information we are presenting below is a mixture of facts we have gathered throughout our research in the literature as well as in case studies. Giving exact references is rather difficult; nevertheless the description of the constraints given in [MC99] is quite comprehensive and closest to what we state below. •

Lack of understanding of the importance of the infrastructure. Stakeholders have not realized the importance, and moreover the criticality of the health care infrastructure. They may not have thought out the implications of being part of a complex electronically connected industry, and may not understand the impact that the interconnection to other organizations will have on their services.

- 41 -

•

Medical culture has traditionally been extremely conservative and cautious, especially when it comes to technologies that could alter the doctor-patient relationship. Physicians are concerned about losing control of the interaction with their patients due to all the information available on the web. Therefore, physicians may feel reluctant to adopt a more technical approach to treating patients.

•

Clinical information systems in labs, pharmacies and hospitals are fragmented and do not communicate well with each other. For example, the enrollment and eligibility databases of most insurers are weeks to months out of date. We have already analyzed this issue as a threat, but it also represents a constraint towards building a larger information infrastructure.

•

Probably stemming from the lack of understanding of the infrastructure, the health care industry spends much less on technology compared to other information intensive industries. This is reflected in the lack of trained/skilled human resources, and of course the lack of updated technology infrastructure.

•

There is widespread and unregulated sharing of medical information among all the parties interested in a patient’s data, including insurance companies, health care administrators, and government agencies.

•

Patients, desiring to protect their privacy and avoid embarrassment, stigma, and other forms of discrimination, withhold information from their health care providers, or provide inaccurate information.

•

In emergency situations, regular security mechanisms may not apply or may be bypassed, and in some cases may represent a burden. For example, we cannot forget that the ultimate mission of a physician is to deliver health care no matter what the consequences. If, in a specific case, a physician needs to treat a patient in an emergency situation, he may need to avoid some security procedures. Designing policies to address these cases is rather difficult given the potentially large number of stakeholders.

- 42 -

A Survivable Infrastructure In this section we are going to apply the framework we described in the previous chapter and elicit the mission/survivability requirements for a survivable health care services infrastructure. We do not expect to elicit a set of complete requirements, but certainly a necessary set of requirements, which we will build on to design a survivable infrastructure. Mission To enable the timely delivery of health care services of high quality within the United States.

As we mentioned during the discussion of the framework, this mission statement is stable, since it does not depend on current technologies or situations; it is qualitatively measurable, and offers a service bounded by geography. The current infrastructure We believe this mission is rather complicated to fulfill given the current state of the infrastructure. First, there is a conflict of interest among the stakeholders. HMO and IDS, were (theoretically) designed to improve quality of services while reducing costs. But apparently what is driving these stakeholders is not the quality of service, but the reduction of costs. Unfortunately, the approach they have used to fulfill these objectives is not always in the best interest of the patients. For example, the very design of any type of HMO is to restrict the access of patients to care services, in some cases introducing single points of access, that we as systems designers know are a source of a wide variety of problems. Second, both IDS and HMO are based on a centralized control approach, which as we have explained before is unlikely to provide a survivable solution in the long run. Third, the current implementation of EMR brings along a broad range of threats to privacy, accuracy, accessibility, integrity, and confidentiality, among others.

Primarily for these reasons, it will be rather complicated to build a survivable health care infrastructure with the current solutions (IDS, HMO, and EMR). Given our understanding of the mission, we are going to focus on eliciting a set of survivability requirements for a - 43 -

patient-centered health care infrastructure, which is apparently one of the objectives that the current infrastructure is trying to address. Survivable requirements • Ubiquitous Access

In order for services to be offered independent of the situation, patients need to have access to medical systems when needed and from wherever they are available. This takes into account emergency and non-emergency situations. This implies that medical delivery systems, in many cases, will need to be accessible at all times, and that authorized health care workers should have access to patient information. Patient information should be available only when needed to deliver care to that patient. •

Authorization

The objective is to maximize availability of the information to physicians, despite administrative and security procedures. It is imperative to manage authorization at different levels of granularity. Physicians that are treating a specific patient must have access to that patient’s medical records, but it may be not necessary for them to have access to all the information contained in the record. Therefore different levels of authorization have to be in place. In general, different stakeholders have different needs from medical systems. The level of authorization has to correspond with the requirements of each of the stakeholders given a specific scenario. In some cases, summaries of the record can be presented.

It is important to notice that the level of authorization and who has access may change depending with the situation. In an emergency situation, health workers (i.e. physicians, nurses, administrative personnel) would need access to a patient’s medical information even though they may not be given permission to access it. This case, of course, could raise issues regarding privacy (though it should not), but we must remember that the fulfillment of the mission depends on delivering health care services at a certain quality level; the readability of this information can be decisive to fulfilling these goals.

- 44 -

We feel it is appropriate to mention that even though it can be argued that authorization is a way to achieve privacy and accountability, authorization by itself is a mission requirement, because with authorization we can fulfill certain levels of security that may protect the infrastructure from denial of service attacks that can jeopardize the offering of services, and therefore the mission. As we mentioned during the definition of the framework these requirements can be, and furthermore are expected to be interrelated in many cases. •

Privacy

As we have mentioned before, privacy is one of the major concerns of all stakeholders (including patients) in health care services. We do not feel the need to delve deeper into this subject. Readers may refer to the previous section on threats in order to find a set of reasons why this is a survivability/mission requirement. •

Safety: Integrity and Completeness

Integrity of the data contained in the medical systems, in almost all cases, is more important than privacy. The reason is because alterations (modification, addition, or deletion) of medical data can definitely threaten the lives of the patients, and thus their safety. •

Accountability

It is imperative to keep accurate information related to medical interventions on patients, such as diagnoses, doses, reasons for procedures, practices, dates of these events, physicians that executed those procedures, etc. Conclusions to this chapter The current state of the health care industry cannot fulfill a patient-centered mission, such as the one we stated previously.

We have presented a set of requirements that regardless of the degree of completion, or sufficiency of this set of requirements express a large variety of concerns to stakeholders.

- 45 -

These requirements have not previously (at least to the best of our knowledge) been brought together in a comprehensive collection that takes this breadth of issues into account. Designing a system that addresses all these issues will certainly not be easy, but the importance of a health care infrastructure justifies attention to the design and construction of a survivable infrastructure.

The characteristics of the application domain (lack of central control, an unbounded network of applications, interaction at local levels) suggest emergent algorithms as a possible solution.

Our hope is that infrastructure designers in the health care industry will find the above requirements useful, will build upon them, and will extend them by further elicitation to more accurately address the inherent threats and constraints.

- 46 -

Chapter VI – A Case Study – DHIAP
The purpose of this chapter is to validate the framework we developed for designing survivable systems. The reader will find in this chapter a case study of the design of a system for a medical facility. It is important to mention that the purpose of this project was not to design a survivable system, but rather to improve the overall security of the system within the given time, cost and other resource constraints. The reason why this is important is because, as we have discussed in previous chapters, thinking about survivability is quite different than from thinking about security. It would be pointless to analyze a system from a survivability point of view and draw conclusions about its security, unless its mission is strongly dependent on security. Therefore, it is not our goal to analyze whether the system was secure or not, nor to criticize the role of any of the stakeholders. The only purpose of this analysis is to make conclusions based on our survivability framework, to better understand the environment that surrounds the implementation of systems in medical facilities, and draw conclusions about how this analysis is linked to the theoretical requirements we believe the health care industry should address.

DHIAP and our Role In response to a recommendation made by Congress in 1997, the Defense Healthcare Information Assurance Program (DHIAP) was developed. “Its purpose is to identify weaknesses in current medical information systems and to develop and demonstrate prototype systems that provide reliable access to health care information while protecting that information from unauthorized access or alteration.”

The purpose of this project was to design and implement a system that allowed access to Medical Information Systems (MedIS) data to authorized health workers within a specific Medical Treatment Facility (MTF). We had the opportunity to work on this project at the Software Engineering Institute (SEI) in Carnegie Mellon University. Our role was to gather information about the design of the system in order to assess its survivability.

- 47 -

Stakeholders Below is a brief description of the participants and their roles within this project. (This is not a list of all the participants, just those that are relevant for our analysis).

TATRC – Telemedicine and Advanced Technology Research. (Sponsor) TATRC is composed of military personnel from all services, along with staff from private industry and academia. Its mission is to provide medical solutions for military requirements to protect and sustain the force. They set the goals for this project and were in charge of assuring that contractors met those goals.

MTF – Medical Treatment Facilities (Customers) Their mission was to guarantee that the system to be implemented complied with their needs, and met their requirements.

ATI – Advanced Technology Institute. (Contractor) ATI’s main objective is to manage technology programs that deliver the technical depth and unbiased, neutral perspective that can best be provided by a collaborative and cooperative team. To the best of our comprehension the underlying mission of ATI in this project was: “to increase the overall security of the existent information system infrastructure of the selected site (i.e. MTF)”. This project was envisioned as a first step towards that mission.

LMES/DSRD - Lockheed Martin Energy Systems / Data Systems Research and Development (Subcontractor) LMES/DSRD (from this point on referred to as LMES) contributes their experience dealing with and evaluating diverse systems that include a security component and training of information security personnel. Their objectives in this project were: • Design a system to provide authorized access to the IS via dial-up

- 48 -

• • •

Implement the system Instruct the site’s technical staff on the administration of the system to be installed Develop the policies for proper use of the system

SEI – Software Engineering Institute. (Subcontractor) SEI provides unique experience and leadership in the area of vulnerability analysis based on its pioneering work in intrusion detection and response including the operation of the CERT Coordination Center. Their objectives in this project were:
• •

Provide independent verification and validation Perform Information Security Evaluations (ISE)

Description

Mission: “Ensure that patient clinical and other health related data is readily accessible but only to authorized health care workers”

Requirements specified by TATRC: • • • • • Evaluate existing medical IS (MedIS) to determine vulnerabilities and recommend operational policy and procedures to address information assurance Propose and validate technical solutions that assist in ensuring the integrity and security of data in MedIS Provide technical and programmatic advice regarding long range programs to address information assurance Provide authorized users appropriate access to data resources from non-secure environments Implement the systems for evaluation

Requirements elicited by LEMS from the MTF:

- 49 -

• • • • • • • • • • •

RADIUS14 as the security protocol for authorization and authentication Rack mounted (router and RAS) Compatible with existing hardware/software resources Minimize administration/support burden 16 discrete, dial-in, voice grads POTS lines Remote management ID, Authentication and authorization for users * Accounting * System should be scalable in terms of number of lines * Options for other technologies * Single vendor solution (if possible) *

* Expressed as “Derived requirements”. Derived requirements are those that arose during the design phase that were not formally stated, but that Lockheed felt were appropriate to the design/implementation of the system.

Unstated restrictions observed by the SEI
•

Lack of trained technicians. There was a steady concern about the lack of capable technical personnel available for the maintenance and administration of any new system. There was a constant pressure from the MTF to implement a system that was reliable, stable, easy to use and manage, and that required the least effort for their technical group.

•

Lack of economic resources. The MTF did not have any funds to put in the project, so even though the equipment and installation would be cost free, they did not want a system that increased their operations or maintenance costs, or that required any user training. There were no provisions for new technical human resources, or any other cost involved in the evolution of the system.

14

RADIUS: Remote Access Dial-In User Service

- 50 -

Survivability Analysis

Mission The mission of the system, as envisioned by TATRC, is quite good. It is stable, meaning that it is not over constrained by current technologies, or by specific scenarios, and it is independent of current social situations. At the same time it is measurable, which implies constraints on performance, and it is tied to a single identifiable set of users. Implicitly we can assume that it is related to the MedIS contained in MTF facilities (it is desirable that the mission would specify this boundary as well). In other words, the service is concrete, specific and stable, characteristics that we laid out as the most important to defining the mission.

Mission/survivability requirements The requirements specified by MTF and elicited by LMES constrained the possibilities of the design. In particular, no distinction was made between the mission requirements and the design specifications.

Three of the requirements elicited by LMES we consider to be mission requirements: 1) remote management; 2) ID, authentication and authorization; and 3) accounting. All of these requirements are related to the mission. Remote management is a functional requirement that may be desirable when managing systems from other locations. Unfortunately the underlying reason (unstated) for this requirement is that system vendors are in charge of the administration of MTF’s systems. In most cases, MTF’s network and systems administrators do not have access to the configuration of these systems. Moreover, communications from vendors’ sites are unencrypted. If the remote management requirement were stated solely for the use of MTF’s technicians, it would aid in the readiness of the system (and support the mission). However this is not the case, which raises high concerns about the security of the infrastructure. The second requirement allows access to the service only to authorized health care workers, at least

- 51 -

in principle. Although satisfaction of this statement is difficult, it is a necessary requirement if we want the system to prevent access by non-health care workers. Finally, given the infeasibility of satisfying the actual requirements 100% of the time, accounting becomes a necessary requirement. Being able to keep track of the behavior of valid users, and non-valid users as well, will allow the system to evolve to be more robust and responsive in the case of misuse, attacks and failures, and at the same time will give valuable information to adapt the system to the needs of the users and the organization as a whole. Also, accounting will give the needed information to properly enforce the policies.

All the other requirements (except for the last three we just addressed) were simply a list of to-do’s (specifications), which as we explained in a previous chapter should not be confused with the mission requirements of the system. The three requirements we just discussed do not guarantee the fulfillment of the mission, so cannot be used in isolation to design a survivable system.

These three requirements are a set of needed requirements, but this set is far from being a sufficient one. For example, the mission specifies that the data should be only accessible to health care workers. Assuming that only authorized users use the system, there are no real protections against unauthorized users eavesdropping on the communication. Furthermore, the system vendors are remote users but not health care workers, are not under administrative the control of MTF’s personnel, and have no obligation to conform to any security policies.

One of the objectives stated by TATRC reads: “Provide authorized users appropriate access to data resources from non-secure environments”. There are no requirements to encrypt the data that is flowing in and out of the system, nor any other requirement that deal with security in the communication from non-secure environments. Thus, the stated mission will not be satisfied. Moreover, one of the specifications provided by TATRC/MTF conflicts with the mission requirements. RADIUS, the protocol to be used for remote communication, does not allow the encryption of the communication. In fact,

- 52 -

for this reason LMES recommended the implementation of TACACS+15, which is also a remote communication protocol that allows encryption, but it is not the solution required by US Army regulations.

This is a system that is supposed to be readily accessible, however there are not enough requirements (remote management being the only one) to accomplish this goal. Readily accessible should mean that every authorized user of the system must have ubiquitous access to the MedIS. The specification of RADIUS as a remote access protocol ties the access to dial-up lines. Once again this technology provides a needed service, but is not sufficient to guarantee the ready access to the services. For example access through the Internet is by far more ubiquitous, and was disregarded, even though in the near future access through the Internet will be required. This does not mean that dial up access is not needed, but by itself does not guarantee the ubiquitous access that the mission requires. Furthermore, it is also important to list a set of requirements that takes into account protection against denial of service attacks, which as we know prevents the offering of the service, thus inhibiting the readiness of the system.

Another part of the mission requires that access to medical data should be granted to authorized health care workers. For the mission to succeed, we need to assume that the MedIS inside the MTF’s facilities are ready to share the data requested by authorized health workers. Unfortunately we do not have information about the status of the MedIS within the MTF. We know that this was not the objective of this project, but the fact that requirements regarding this part of the mission are missing is relevant to our analysis.

System Requirements There is an important requirement that addresses part of the system requirements. TATRC required the development of an operational policy and procedures to address information assurance. The development of the policy should be the result of a close interaction between the MTF and the provider of the system, in this case LMES. Whether

15

TACACS: Terminal Access Controller Access Control System

- 53 -

the resulting policy was appropriate is not the point of this analysis. What it is important is that the requirement was stated, and it plays an important role in the design of the system.

The rest of the system requirements were overlooked. The MTF requirements to use RADIUS, left no room for studying other technologies that could have been more flexible and could have better met the needs of the mission. Even though lack of economic resources and lack of skilled technical personnel constrained the solutions acceptable to the MTF, an exercise of laying out an alternative combination of technologies and resources, to highlight other possibilities more consistent with TATRC’s needs, would have given insight into other possibilities that might be feasible under less restrictive conditions.

At the same time, threat scenarios were overlooked as well. These scenarios are useful to elicit and study before designing a system. The scenarios give us better ideas about where to focus the effort and the investment in the system design. So, eliciting threat scenarios could have helped designers to envision the evolution of the system, and would have left managers aware of their risks, and administrators prepared to react properly in the event of failures, misuse and attacks.

Implementation and Design Decisions Implementation and design decisions are probably closer in definition to the requirements provided by TATRC and MTF. With the exception of the three requirements we already described, the other requirements fit better within this category, given all the reasons we have discussed previously.

Decisions such as number of dial-in lines, whether the devices are going to be mounted on a 19” rack or not, the technology itself, and even the brand of the technology to be used belong inherently to this part of the design process. To give these specifications as requirements is over constraining the design of the system, to the extent that cost

- 54 -

effective and possibly even feasible solutions are precluded. LMES did not have any architectural space in which to work.

Evolution of Requirements The auditing capabilities of the system can give important information for recognizing attacks, misuse of the system, and changes in the behavior of authorized users. This information can be used to redesign the system so it can better repel attacks, to develop policies to improve usage and avoid misuse, and to cope with changes in the organization/environment. We assume that the policy developed takes into account these aspects. The architecture of the system is simple and open enough to make modifications that support evolution. However, successful modifications are tied to the willingness to relax some of the restrictions imposed on the system.

Designing stable systems (so they do not represent a burden to current administrators) is inherently tied to the “low maintenance” requirement, which slows or prevents the system from evolving with the environment that surrounds it. Unfortunately, the evolution of the technology also means more prepared attackers. Therefore, a stable system with inadequate or low maintenance is likely to become an easy target, and furthermore a real constraint to the evolution of the organization as a whole. Conclusions to this Case Study As we said at the beginning of this analysis, our purpose is neither to evaluate the implementation of the system nor to judge the abilities of the stakeholders. Our analysis was to demonstrate how the framework we have described before could lead to systems that are more likely to survive, and how a small example is tied to the same constraints we elicited from the UHSI.

The system developed for the MTF is not survivable because its stated requirements are not consistent with the real mission, and the difference cannot be overcome in the design. A solution based on those requirements could possibly be a first step in a more comprehensive solution that would guarantee the fulfillment of the mission. However, - 55 -

this would be possible only when stakeholders realize the importance and implications that MedIS could have for their organization in terms of delivery of higher quality health care, productivity, privacy and integrity of patient data, among others.

If we look closer at the mission of the system to be built, we can see that it is not significantly different from the one elicited for the USHI. The boundaries are certainly different, but the underlying survivability requirements are quite the same: ubiquitous access, data integrity, data privacy, accountability, and affordable cost.

One of the reasons why the USHI is not in place is the underestimation of the importance of the system, especially to those in high enough levels to make a difference. We believe this is the same reason why MTF’s system fails. MTF’s IT personnel are focused on cost avoidance and inhibiting change, probably because they have been told to do so. TATRC is in a better position to influence Army policy but may not have realized the implications of the mission they laid out. Sponsors (such as TATRC) do not envision this system as the core support to their activities in the future, which is closer than they expect. The healthcare industry is now rapidly changing as we described before, organizations are already facing the pressures imposed by the advances of IT, and if they do not cope with this dynamic environment, they will not survive, nor will their ultimate mission: “To enable the timely delivery of health care services of high quality within the United States”.

The fact that the MTF’s system by itself is not survivable will not put in jeopardy the behavior of a national infrastructure. Nevertheless once it is interconnected to a complex web of databases and other systems in the USHI, the situation may change. And we say “may” because we are not certain of this situation, since as we have seen before, being interconnected to other systems makes it as a small part of a large unbounded network. From the theory of unbounded networks we know that local issues might not affect the behavior of the larger infrastructure, in this case the USHI. But we cannot assure that it will not, especially given that current security systems are typically designed with a fortress model in which compromising any subsystem compromises the whole system.

- 56 -

Survivability research seeks methods (e.g. emergent algorithms) to limit the adverse effects and propagations of compromises and failures, but this research is beyond the scope of this thesis.

During this case study we reached two overall conclusions. First, the system developed for the MTF in our case study will not likely contribute to the satisfaction of the stated mission, and hence is not a survivable system. Second, the presence or absence of this system within the USHI does not imply that the USHI as a whole will be survivable or not.

- 57 -

Chapter VII – Conclusions
Survivability is a new approach to the design and protection of unbounded systems, including critical infrastructures and systems that operate within unbounded networks. As system designers, we are not used to this approach. Historically, we have been taught to design systems to be reliable, stable, and low maintenance, related to a fixed set of well understood customers’ requirements. However, in most cases our customers have a vague idea of what they want. In addition their requirements are evolving, and the technology and environment in which the systems must be maintained are also changing. Therefore, usually those requirements that our systems are designed for, are neither the most appropriate, nor aligned with the real interests of our customers, nor consistent with the changing technology and context.

Survivability makes us think about systems in alignment with the mission of our customers represented in their systems, organizations, industries, and infrastructures. Furthermore, modern systems often have to perform in extreme conditions. Our systems have to be survivable; they have to be able to deliver their mission even in the presence of attacks, accidents, and failures in a timely manner. And at the same time they have to be able to cope with changes in the environment, so they can evolve, and adapt to perform optimally. They must remain cost-effective and efficient in the presence of rapidly evolving technology.

In a way, successful organizations have always known how to adapt to the changes in the environment, how to overcome in some cases the failures of reacting fast to these changes and in other cases the consequences of adapting slowly. Successful organizations have known how to evolve to remain competitive, and thus survive.

During this research we had the opportunity to revisit the concept of survivability to include specific requirements for the evolution of systems. We recognize that there are implications in this new definition that need to be addressed in greater depth.

- 58 -

Given the focus of survivability on the mission of systems, organizations, industries, and infrastructures, we devote a large part of this research to developing a framework that will help in the design survivable systems. The framework explicitly relates the survivability requirements to the mission of the system. This set of requirements, if adequate, will assure the fulfillment of the mission. However, these requirements are constrained by the environment that surrounds them given current technology, social and political situation, costs, time, organizational culture, etc. This new set of requirements, referred as system requirements, offers a set of feasible solutions to the design of our systems. Given a set of feasible solutions, designers are then faced with design decisions to optimize the functionality of the system towards the fulfillment of the mission.

One of the most important things to notice about this framework is the close relationship between the system requirements and the environment that surrounds the system. This suggests that in order for the system to evolve and adapt to the environment, these requirements are likely to change given that the environment is in constant change. Designers must anticipate the changes in the environment. Otherwise they will be unable to optimize the system in a way that it can survive change. If the system is unable to fulfill the mission of the organization, industry, or infrastructure, they too may not survive.

The success of this framework will depend ultimately on the ability of designers and system developers. They must guide customers through this process, and make appropriate decisions. Like any tool, this framework is of value only if used wisely.

Stepping back from the framework, we briefly described what may be a solution to the design of survivable systems. Emergent Algorithms, as we have seen, address issues related to survivability in unbounded networks and unbounded systems. Emergent algorithms are well suited to the deployment of survivable systems. Although there are few practical implementations using this technique in automated systems, expectations are high among researchers in the field, myself included.

- 59 -

In order to validate the framework, we applied it to the health care industry. This industry is relevant to our society, and is of critical importance. Although the health care industry was not recognized as a critical infrastructure within the Report of the President’s Commission on Critical Infrastructure Protection, we believe that the evolution of this industry in the past few years, and the continued evolution in the near future will likely lead to its recognition as a critical national infrastructure.

We believe we have shown the relevance and criticality of the growing national health care infrastructure. We saw how its evolution, and its relationship with information technology development, exacerbated the opportunities for threatening the privacy of patients, and how these effects can jeopardize the delivery of high quality services to the U.S. population, and ultimately can undermine overall health care.

Given the information available, we asserted what we believe should be the mission of the U.S. health care infrastructure. We elicited a set of necessary requirements: ubiquitous access, authorization, availability, data integrity, privacy and accountability. They account for a partial set of necessary requirements to achieve a survivable health care infrastructure. Unfortunately it is beyond our expertise, and the time allotted for this research, to make a design that meet these requirements.

Finally, we had the opportunity to participate in a case study reviewing the design of an information system for a medical facility. Once again we applied the framework, and analyze the design process within that specific case study. What we found was in a way what we expected. The project showed us clearly how the mission could be misstated, how the requirements specified by the customers can be self-contradictory or contradictory to the purpose of the system, how the environment that surrounded the deployment is often overlooked, and how final designs often fail to fulfill either the mission or the stated requirements. The mistakes made in this specific case, are likely to prevail throughout the health care application domain.

- 60 -

This document describes what we believe are the most important lessons learned from our research. Survivability is a research field in an early stage. Ironically the concept has been around us for a long time, we just did not have the incentive to address it in the context of automated systems. Current changes in technology, and society, have made us rethink our role as system designers, and as system developers. Threats and vulnerabilities have increased greatly. We cannot afford to design automated systems in isolation as if they will not be part of larger interdependent systems. The context has changed, and many of the assumptions under which we design systems are no longer valid. It is our role as researchers, designers, and developers to incorporate new approaches, such as survivability, that addresses these issues in our practice. Otherwise the fulfillment of our society’s essential services is at risk.

- 61 -

Chapter VIII – Future Work
Given the time constraints and the limited scope of this master’s thesis, there were a number of issues we did not have the time to address. We offer the following topics for further research Survivability Definition We extended the definition of survivability to include the evolution of systems due to changes in organizations’ structure, environment and available technology. We believe we have not addressed its implications well enough. Further research is needed to address the implications of this change in perspective and related issues about the obsolescence of systems and organizations. Survivable Solutions We talked briefly about emergent algorithms, their properties, and how theoretically they address the main issues of survivability. Emergent algorithms are by themselves, a whole field of study that needs validation, and practical implementations. The possibilities of research involving emergent algorithms appears to be endless.

We also briefly talked about the concept of perpetual design. Whether this concept is feasible in the real world or not is unknown to us. We did not address its implications in important areas such as systems engineering, or software development, and ultimately its implementation costs. Survivable Architectures All the literature we had access to during this research that addresses partially or totally survivable architectures agrees on a multilayered architecture that has to be designed from the bottom to the top. Most of the literature envisioned the top layers as emergent from the interaction of the elements in the layers below, which is aligned with the ideas of emergent algorithms.

This topic itself represents a whole field of study as well. - 62 -

Survivable Requirements The framework for designing survivable systems we proposed in this document seems to address the most important issues that surround the concept of. We also used the framework to elicit mission requirements for the health care industry, and to evaluate the design of a specific system. However, the framework needs to be validated in more case studies, and in more complex systems, by different groups of designers. Health Care Infrastructure The large and growing number of players, the evolution still in process, the role of information infrastructures, the critical importance of its applications, the underlying threats, among others, make the health care industry an interesting but complex application domain for survivability. We addressed important issues, and attempted to bring to light many additional closely related. It is our hope that future researchers will consider these issues. The path ahead in this field may be long and complicated, but exciting as well.

- 63 -

Glossary
ATI CMU COTS DHIAP EMR HMO IDS IS IT Advanced Technology Institute Carnegie Mellon University Commercial Of The Shelf Defense Healthcare Information Assurance Program Electronic Medical Records Health Maintenance Organizations Integrated Delivery Systems Information Systems Information Technology

LMES/DSRD Lockheed Martin Energy Systems / Data Systems Research and Development MedIS MTF NII NLM NRC PCCIP POS POTS PPO RADIUS RAS SEI TACACS TATRC UML USHI Medical Information Systems Medical Treatment Facilities National Information Infrastructure National Library of Medicine National Research Council President’s Commission on Critical Infrastructure Protection Point Of Service Plain Old Telephony System Preferred Provider Organization Remote Access Dial-In User Service Remote Access Server Software Engineering Institute Terminal Access Control Access Controller Service Telemedicine and Advanced Technology Research Center Unified Modeling Language United States Healthcare Infrastructure

- 64 -

References
[BB99] M. R. Barbacci, L.J. Bass, J. Carriere, P. Clements, R. Kazman, M. Klein, R. Linger, H. Lipson. Analysis and Design of Survivable Systems using Attribute-Based Architecture Styles. Software Engineering Institute. Carnegie Mellon University. Grady Booch, James Rumbaugh, and Ivar Jacobson. The unified Modeling Language User Guide. Addison Wesley – ACM Press. 1999. USA Frederick Brooks. The Mythical Man-Month – Essays on Software Engineering. Anniversary Edition. Addison Wesley. 1995. USA. Eric Bonabeau, and Guy Theraulaz. Swarm Smarts. Scientific American. March 2000, Volume 282, Number 3. USA. Council on Competitiveness. Highway to Health: Transforming U.S. Health Care in the Information Age. Washington, March 1996. USA. D. Conrad, and W. Dowling. Vertical Integration in Health Services: Theory and Managerial Implications. Health Care Management Review 15 (Fall). 1990. USA. Edmund X. DeJesus. Managing Managed Care. Healthcare Informatics. March 1999. USA. Deloitte and Touche LLP. U.S. Hospitals and the Future of Health Care. Deloitte and Touche, 1996, Philadelphia, USA. James Ellis, David Fisher, Thomas Longstaff, Linda Pesante, and Richard Pethia. Report to the President’s Commission on Critical Infrastructure Protection. Special Report CMU/SEI-97-SR-003. CERT – SEI, CMU. Pittsburgh, 1997. USA Robert Ellison, David Fisher, Richard Linger, Howard Lipson, Thomas Longstaff, Nancy Mead. Survivable Systems: An Emerging Discipline. CERT – SEI, CMU. Pittsburgh, 1999. USA Robert Ellison, Richard Linger, Thomas Longstaff, Nancy Mead. A Case Study in Survivable Network System Analysis. CERT – SEI, CMU. Pittsburgh, September 1998, USA David Fisher. Design and Implementation of Easel, A Language for Simulating Highly Distributed Systems. Proceedings of MacHack 14, 14th Annual Conference for Leading Edge Developers, June 1999, USA.

[BRJ99]

[Bro95]

[BT00]

[CC96]

[CD90]

[DeJ99]

[DT96]

[EFL97]

[EFL99]

[ELL98]

[Fis99]

- 65 -

[FL99]

David Fisher, and Howard Lipson. Energent Algorithms – A New Method for Enhancing Survivability in Unbounded Systems. Proceedings of the Hawaii International Conference on System Sciences. January 99, Maui, Hawaii, USA. D. Gritzalis, I. Kantzavelou, S. Katsikas, and A. Patel. A Classification of Health Information Systems Security Flaws. Proceedings of the 11th International Information Security Conference. 1995, Chapman & Hall, South Africa. Anup Ghosh, and Jeffrey Voas. Inoculating Software for Survivability. Communications of the ACM. Vol 42, No 7. July 1999. USA. Ron Gray, and Mitch Zack. Americans Worry About the Privacy of Their Computerized Medical Records. California Health Care Foundation. January 1999, CA, USA. Health Management Technology. 1995. I/T Sales to Soar Next Five Years. December 1995, p 10. Integrated Healthcare Associates. http://www.iha.org Michael Jackson. Software Requirements & Specifications – a lexicon of practice, principles and prejudices. Addison Wesley – ACM Press. 1995 (reprinted 1998). USA. Arnold Kaluzny, Howard Zuckerman, and Thomas Ricketts III. Partners for the Dance – Forming Strategic Alliances in Health Care. Health Administration Press. Ann Arbor, Michigan 1995. Dorothy Leonard. Wellsprings of Knowledge. Building and sustaining the sources of innovation. Harvard Business School Press. 1995. Boston, Massachusetts USA. Howard Lipson, and David Fisher. Survivability – A New Technical and Business Perspective on Security. Proceedings of the 1999 Security Paradigms Workshop, September 21-24, Caldeon Hills, ON. Association for Computing Machinery. New York, NY, 1999. Richard Linger, Nancy Mead, and Howard Lipson. Requirements Definition for Survivable Network Systems. Proceedings of the Third International Conference on Requirements Engineering (ICRE). April 610, 1998. Colorado Springs, USA, IEEE CS Press, 1998.

[GKK95]

[GV99]

[GZ99]

[HMT95]

[IHA00] [Jac98]

[KZR95]

[Leo95]

[LF99]

[LML98]

- 66 -

[MC99]

Robert Mittman, Mary Cain. The Future of the Internet in Health Care – Five Year Forecast. California HealthCare Foundation. January 1999. USA. (http://www.chcf.org) Neil Munro. Infotech reshapes Health Care Marketplace. Washington Technology, Aug. 8, 1996. USA. Peter Neumann. Computer Related Risks. Addison-Wesley. 1995. New York, New York, USA. Peter Neumann. Practical Architectures for Survivable Systems and Networks: Phase-one Final Report. Computer Science Laboratory. SRI International. January 1999. Menlo Park, CA, USA. National Information Infrastructure. http://metalab.unc.edu/nii/NIIAgenda-for-Action.html National Library of Medicine. http://www.nlm.nih.gov/research/initprojsum.html National Research Council. For the Record: Protecting Electronic Health Information. National Academy Press. Washington, 1997. USA. James Odell. Agents and Emergence. Distributed Computing. October 1998. The Report of the President’s Commission on Critical Infrastructure Protection. Critical Foundations – Protecting America’s Infrastructures. October 1997. Perpetual Testing Research Project. http://www.cs.uoregon.edu/research/perpetual/Perpetual-Testing.html Thomas C. Rindfleisch. Confidentiality, Information Technology, and Health Care. School of Medicine. Stanford University, 1997. USA Anil Somayaji, Steven Hofmeyr, and Stephanie Forrest. Principles of a Computer Immune System. New Security Paradigms Workshop 1997. Langdale, Cumbria UK. Lincoln D. Stein. The Electronic Medical Record – Promises and Threats. Web Security: A Matter of Trust. Volume 2, Issue 3, Summer 1997. O’Reilly & Associates. USA

[Mun96]

[Neu95]

[Neu99]

[NII00]

[NLM00]

[NRC97]

[Ode98]

[PCC97]

[PT00]

[Rin97]

[SSF97]

[Ste97]

- 67 -

[TBK99]

Duane Truex, Richard Bakersville, and Heinz Klein. Growing Systems in Emergent Organizations. Communications of the ACM, August 1999, Vol. 42, No 8. USA. Marc Wilikens, and Alberto Sanna. Survivability within a Dependability Framework and a Virtual Enterprise Case Study from the Health Care Sector. 1998 Information Survivability Workshop. Orlando, FL 1998, USA. Michael Wang, and Tatsuya Suda. The Bio-Networking Architecture: A Biologically Inspired Approach to the Design of Scalable, Adaptive, and Survivable / Available Network Applications. Technical Report 00-03. Department of Information and Computer Science, University of California, Irvine. February 2000.

[WS98]

[WS00]

- 68 -

Bibliography
1. Taimur Aslam, Ivan Krsul, and Eugene Spafford. Use of a Taxonomy of Security Faults. Technical Report TR-96-051. Department of Computer Sciences. Purdue University. September 1996.

2. Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. SEI series in Software Engineering. Addison Wesley. 1998.

3. Jan Hauser, and Manor Askenazi. Towards an Emergent Operating System. http://www.santafe.edu/~manor/EOS.html

4. H. M. Hinton. Under-Specification, Composition and Emergent Properties. New Security Paradigms Workshop 1997. Langdale, Cumbria, UK. ACM 1997.

5. John Knight, Matthew Elder, James Flinn, and Patrick Marx. Summaries of Three Critical Infrastructure Applications. Computer Science Report No. CS-97-27. Department of Computer Sciences. University of Virginia. November 14, 1997. (Revised December 10, 1997)

6. John Knight, Matthew Elder, A.C. Chapin, Brownell Combs, Steven Geist, Sean McCulloch, Luis Nakano, and Robert Sielken. Topics in Survivable Systems. Computer Science Report No. CS-98-22. Department of Computer Sciences. University of Virginia. August 14, 1998.

7. Yannis Korilis, Aurel Lazar, and Ariel Orda. Architecting Noncooperative Networks. IEEE Journal on Selected Areas in Communications. Vol 13, No 8. 1995

- 69 -

8. Mary Shaw, and Paul Clements. A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems. Computer Science Department and Software Engineering Institute. Carnegie Mellon University. Pittsburgh, PA, April 1996. USA.

9. Kevin Sullivan, and Gary McGraw. Massive Games of Artificial Life on the Internet: A Testbed for Research on Survivability Architectures. 1998 Information Survivability Workshop. Orlando, FL 1998, USA.

10. Kevin Sullivan, John Knight, Xing Du, and Steve Geist. Survivability Architectures: The Control System Perspective. Department of Computer Sciences. University of Virginia.

11. Regis Vincent, Bryan Horling, Tom Wagner, and Victor Lesser. Survivability Simulator for Multi-Agent Adaptive Coordination. Computer Science Department. University of Massachusetts. 1998. http://dis.cs.umass.edu/~vincent/wmc98/article.html

12. Michael Wellman, Jeffrey MacKie-Mason, and Sugih Jamin. Market-based Adaptive Architectures for Information Survivability. University of Michigan. http://www-personal.umich.edu/~jmm/papers/darpa/Surv_Proposal.html

13. Aris Zakinthinos, and E. S. Lee. Composing Secure Systems that have Emergent Properties. IEEE. 1998.

- 70 -