Design and Application of a Security Analysis Method for Healthcare Telematics in Germany

Ali Sunyaev Health-Care Telematics in Germany GABLER RESEARCH Informationsmanagement und Computer Aided Team Herausge...

Author: Ali Sunyaev

10 downloads 960 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Ali Sunyaev Health-Care Telematics in Germany

GABLER RESEARCH Informationsmanagement und Computer Aided Team Herausgegeben von Professor Dr. Helmut Krcmar

Die Schriftenreihe präsentiert Ergebnisse der betriebswirtschaftlichen Forschung im Themenfeld der Wirtschaftsinformatik. Das Zusammenwirken von Informationsund Kommunikationstechnologien mit Wettbewerb, Organisation und Menschen wird von umfassenden Änderungen gekennzeichnet. Die Schriftenreihe greift diese Fragen auf und stellt neue Erkenntnisse aus Theorie und Praxis sowie anwendungsorientierte Konzepte und Modelle zur Diskussion.

Ali Sunyaev

Health-Care Telematics in Germany Design and Application of a Security Analysis Method

RESEARCH

Bibliographic information published by the Deutsche Nationalbibliothek The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available in the Internet at http://dnb.d-nb.de.

Dissertation Technische Universität München, 2010

1st Edition 2011 All rights reserved © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011 Editorial Office: Stefanie Brich | Anita Wilke Gabler Verlag is a brand of Springer Fachmedien. Springer Fachmedien is part of Springer Science+Business Media. www.gabler.de No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the copyright holder. Registered and/or industrial names, trade names, trade descriptions etc. cited in this publication are part of the law for trade-mark protection and may not be used free in any form or by any means even if this is not specifically marked. Coverdesign: KünkelLopka Medienentwicklung, Heidelberg Printed on acid-free paper Printed in Germany ISBN 978-3-8349-2442-1

Foreword The importance of security management in the development and operation of information systems (IS) has been growing with the ubiquity of information system use. Along with this growth and technological advances IS security has changed tremendously over the past decades and so have its scope, complexity, and the variety of analyzed security aspects. To meet these challenges IS security methodologies should become more industry specific and at the same time integrate organizational and technical aspects. Securing the privacy of health information on systems is a major challenge to the widespread adoption of new healthcare information systems like the forthcoming German electronic health information infrastructure. Encouraged by the lack of healthcare IS research with respect to security, this work presents the design and development of an IS security methodology for the organizational and technical analysis of security issues in health care. Grounded on the research literature on IS security and healthcare IS, and a variety of current theories in the fields of information systems, business administration, and computer science, it develops a security analysis method for healthcare information systems. This security analysis method builds the foundation to practically examine the current status of the German healthcare telematics, its constitutive elements, and process management in order to identify possible vulnerabilities. Based on these insights, the work proposes appropriate solution mechanisms for the security management of the German healthcare telematics including recommendations for future IS developments in the health care sector. Ali Sunyaev‘s work shows that IS security should be linked to the needs of an application area, both on the organizational and technical side. He clearly depicts the current security situation of German health information infrastructure and so facilitates a broader understanding of analyzing healthcare IS security. This work is an important contribution to the research field of managing information systems. In a methodological way it gives valuable impulses for combining different security approaches and research methods depending on the context of a security arrangement. The work appeals by its broad scope of theory, method engineering background, and its comprehensive argumentation. Researchers of information systems will gain new insights on which practical security analysis methods and theories are applicable given for healthcare information systems. For practitioners, it provides recommendations for orchestrating the development of secure healthcare IS and presents the identification of security problems in the current concept of German healthcare telematics.

vi

Foreword

I recommend this book as a valuable reading and resource. It provides new and promising insights into an IS security research field and inspires different kinds of readers to adopt a new perspective on healthcare information systems. I hope this work will find the broad dissemination and attention it deserves. Prof. Dr. Helmut Krcmar

Abstract Purpose: The objective of this thesis is to develop a method for the organizational and technical analysis of security issues in health care (using tools, methods and processes in a structured and traceable way). Using this method the current security status of health care telematics in Germany is evaluated and recommendations for future developments in the health care sector are derived. Methodology: This work is based on the methodological foundation of design-oriented artifact construction in Information Systems (IS) research, in particular method engineering. This research project creates a method to analyze healthcare telematics and also demonstrates the practical application of the designed artifact, based on the integral parts of the design science research framework. Findings: During the planning stage of designing a healthcare specific IS security analysis method, it is advisable to base the design procedure on established standards and best practice approaches. The resulting method therefore relies heavily on previously approved frameworks. Based on the PDCA (Plan/Do/Check/Act) model the HealthcAre Telematics SECurity-HatSec-analysis method is constructed in a compositional manner. Hence, the HatSec method was designed from existing IS security analysis approaches (like ISO 27001 and ITGrundschutzhandbuch), which were previously selected according to their suitability for healthcare and subdivided into method fragments. Applying the concept of method engineering, these method fragments were used to design the HatSec security analysis method. The identified method fragments of the selected IS security analysis approaches were methodically composed into seven steps: (1) scope identification, (2) asset identification, (3) basic security check, (4) threat identification, (5) vulnerability identification, (6) security assessment and (7) security measures. The application of the HatSec method identified 24 deficiencies in the current state of German health care telematics (including weaknesses, inconsistent and conflicting development documents and violation of security demands). Solutions for the uncovered vulnerabilities were also provided during the practical application of the method. Practical Implications: The outcome of this research project facilitates a broader understanding of analyzing healthcare IS security. The HatSec method is designed for chief information security officers (CISO) to analyze healthcare information systems currently in use or under development. A further contribution to practice is the identification of security problems in the current concept of German healthcare telematics.

Contents List of Figures

xvii

List of Tables

xix

1

Introduction 1.1

Motivation .................................................................................................................. 3

1.2

Objectives of the Thesis ............................................................................................. 6

1.3

Research Methodology............................................................................................... 9

1.3.1 1.3.2

Design Science .................................................................................................. 10 Research Design ................................................................................................ 11

1.3.3 1.3.4

Design Theory ................................................................................................... 13 Theoretical Contribution and Research Outcome ............................................. 14

1.4 2

1

Practical Implications, Users, and Beneficiaries ...................................................... 15

Healthcare Telematics in Germany with Respect to Security Issues

17

2.1 German Healthcare................................................................................................... 17 2.1.1 Structure of German Healthcare ........................................................................ 18 2.1.2 Characteristics of the German Healthcare Sector .............................................. 19 2.1.2.1 Information Exchange and Distributed Information Flows in German Healthcare System......................................................................... 19 2.1.2.2 2.1.2.3 2.2

Current Problems ........................................................................................ 20 Specifics of the German Healthcare Domain .............................................. 21

Information Systems in Healthcare .......................................................................... 22

2.2.1 2.2.2

Seamless Healthcare .......................................................................................... 24 Interoperability, Standards and Standardization Approaches in Healthcare .......................................................................................................... 24

2.2.2.1 2.2.2.2

Communication Standards .......................................................................... 27 Documentations Standards and Standardization Approaches ..................... 31

2.2.3 Healthcare IS Architecture Types ...................................................................... 33 2.2.3.1 Monolithic System ...................................................................................... 34 2.2.3.2 2.2.3.3

Heterogeneous System ................................................................................ 35 Service-Oriented IS Architecture ................................................................ 35

x

Contents 2.2.4 2.3

Implications for Security Issues of Healthcare Information Systems ............... 36

Healthcare Telematics .............................................................................................. 39

2.3.1 Definitions and Objectives of Healthcare Telematics ....................................... 39 2.3.2 German Healthcare Telematics ......................................................................... 42 2.3.2.1 Healthcare Telematics Infrastructure .......................................................... 42 2.3.2.2 Electronic Health Card ................................................................................ 44 2.3.3 2.4 3

Risk and Security Issues of Healthcare Telematics ........................................... 46

Summary .................................................................................................................. 52

Catalogue of IS Healthcare Security Characteristics

53

3.1 Legal Framework ..................................................................................................... 54 3.1.1 Privacy ............................................................................................................... 54 3.1.2 3.2

Legal Requirements ........................................................................................... 55

Protection Goals ....................................................................................................... 56

3.2.1

Dependable Healthcare Information Systems ................................................... 57

3.2.2

Controllability of Healthcare Information Systems........................................... 59

3.3

Characteristics of IS Security Approaches with Respect to Healthcare .................. 62

3.3.1 3.3.2

Literature Review .............................................................................................. 64 Overview of Healthcare IS Security Approach Characteristics ........................ 66

3.3.2.1 3.3.2.2

General IS Security Approach Characteristics............................................ 66 General IS Security Approach Characteristics with Reference to

Healthcare ................................................................................................... 67 3.3.2.2.1 Type of the IS Security Approach ....................................................... 68 3.3.2.2.2 3.3.2.2.3 3.3.2.2.4 3.3.2.3 3.4 4

Common Characteristics ..................................................................... 69 Methodology ....................................................................................... 73 Surrounding Conditions ...................................................................... 76

Healthcare-Specific IS Security Approach Characteristics ........................ 77

Summary .................................................................................................................. 81

Analysis of IS Security Analysis Approaches

83

4.1

Overview .................................................................................................................. 83

4.2

Review of Literature ................................................................................................ 84

4.3

Existing Literature Reviews ..................................................................................... 87

Contents

xi

4.4

Theoretical Background ........................................................................................... 91

4.5

Systematization of IS Security Analysis Approaches .............................................. 93

4.5.1 Checklists........................................................................................................... 95 4.5.2 Assessment Approaches .................................................................................... 96 4.5.2.1 Risk Assessment Approaches ..................................................................... 96 4.5.2.2 Security Control Assessment Approaches .................................................. 98 4.5.3 Risk Analysis Approaches ............................................................................... 101 4.5.4 IT Security Management Approaches ............................................................. 102 4.5.4.1 The Plan-Do-Check-Act Approach of ISO 27001 .................................... 104 4.5.4.2 Best Practice Models ................................................................................. 105 4.5.5

Legislation Accommodations .......................................................................... 106

4.6 Analysis of IS Security Analysis Approaches with Respect to Healthcare ........... 108 4.6.1 Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics .................................................................. 110 4.6.2

Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics with Reference to Healthcare ................... 111

4.6.3

Examination of IS Security Approaches with Respect to Healthcare Specific IS Security Approach Characteristics ................................................ 113

4.7 5

Summary ................................................................................................................ 114

Designing a Security Analysis Method for Healthcare Telematics in Germany

117

5.1

Introduction ............................................................................................................ 117

5.2

Research Approach ................................................................................................ 118

5.3

Method Engineering ............................................................................................... 120

5.4

Description of Method Elements ........................................................................... 121

5.4.1 5.4.2

Method Chains and Alliances .......................................................................... 121 Method Fragments ........................................................................................... 122

5.4.3 5.4.4 5.4.5

Method Chunks................................................................................................ 126 Method Components........................................................................................ 126 Theoretical Background .................................................................................. 127

5.5

Formal Description of the Concept of Method Engineering .................................. 128

5.6

HatSec Security Analysis Method ......................................................................... 132

xii

Contents 5.6.1

From Plan-Do-Check-Act Approach to a IS Security Analysis Method

for Healthcare Telematics ................................................................................ 133 5.6.2 Design of the HatSec Security Analysis Method ............................................ 134 5.6.2.1 Method Blocks and Method Fragments .................................................... 136 5.6.2.2 Overview of the Building Blocks of the HatSec Method ......................... 137

6

5.6.2.3 5.6.2.4

Perspectives of the HatSec Method .......................................................... 138 Context and Preparation of the Security Analysis .................................... 139

5.6.2.5 5.6.2.6

Security Analysis Process ......................................................................... 143 Security Analysis Product ......................................................................... 148

5.6.2.7 5.6.2.8

Two Sides of the HatSec Method ............................................................. 152 HatSec Structure ....................................................................................... 154

5.7

Review of the HatSec Security Analysis Method .................................................. 161

5.8

Summary ................................................................................................................ 165

Practical Application of the HatSec Method 6.1

167

Selected Case Studies ............................................................................................. 168

6.2

Assessment and Classification of Threats around the Electronic Health Card ........................................................................................................................ 169 6.2.1 Overview ......................................................................................................... 170 6.2.2 Identification and Classification of the Attackers ........................................... 171 6.2.3 Identification and Classification of the Attack Types ..................................... 173 6.2.4

6.3

Summary.......................................................................................................... 175

Analysis of the Applications of the Electronic Health Card .................................. 176

6.3.1 6.3.2 6.3.3

Overview ......................................................................................................... 177 Data Acquisition .............................................................................................. 177 Process Analysis .............................................................................................. 178

6.3.3.1 6.3.3.2 6.3.3.3

Actual Process ........................................................................................... 178 Process Groups .......................................................................................... 180 Future Process with eHC .......................................................................... 181

6.3.4 Patient Survey .................................................................................................. 183 6.3.4.1 Age Groups Analysis ................................................................................ 184 6.3.4.2 Usage Groups Analysis ............................................................................. 186 6.3.5 Summary.......................................................................................................... 187

Contents 6.4

xiii Analysis of a Proposed Solution for Managing Health Professional Cards

in Hospitals Using a Single Sign-On Central Architecture .................................... 187 6.4.1 Overview ......................................................................................................... 188 6.4.2 Induced Process Changes ................................................................................ 189 6.4.2.1 General Changes ....................................................................................... 189 6.4.2.2 Discharge Letter Process ........................................................................... 190 6.4.3 Existing Approaches for Managing Smart Cards in Hospitals ........................ 191 6.4.3.1 6.4.3.2

The Decentralized Approach .................................................................... 191 The VerSA Approach ............................................................................... 191

6.4.3.3 Disadvantages ........................................................................................... 192 6.4.4 The Clinic Card Approach ............................................................................... 192 6.4.4.1 6.4.4.2

Technical Architecture .............................................................................. 193 Smart Card Management Unit .................................................................. 194

6.4.4.3 6.4.4.4

The Clinic Card and Card Middleware ..................................................... 194 Connector .................................................................................................. 195

6.4.4.5 6.4.4.6

Remote Access .......................................................................................... 195 Unique Characteristics of the Central Approach ...................................... 196

6.4.4.7 Discharge Letter Process ........................................................................... 197 6.4.5 Comparison of the Presented Approaches ....................................................... 198 6.4.5.1 6.4.5.2

Evaluation Framework .............................................................................. 198 Hardware Requirements and Integration .................................................. 198

6.4.5.3 6.4.5.4

Session Management ................................................................................ 199 Usability .................................................................................................... 199

6.4.5.5 Further Value-Adding Aspects ................................................................. 200 6.4.6 Summary.......................................................................................................... 200 6.5

Security Analysis of the German Electronic Health Card’s Components on a Theoretical Level ................................................................................................. 201

6.5.1 6.5.2

Overview ......................................................................................................... 201 Components and Documents Considered in this Security Analysis................ 202

6.5.2.1 Security Analysis of the Electronic Health Card’s Components .............. 203 6.5.2.1.1 Cross-Component Analysis ............................................................... 203 6.5.2.1.2 6.5.2.1.3 6.5.2.1.4 6.5.2.1.5

Key for the Combination of Medical and Administrative Data ........ 203 Unauthorized Transfer of Medical Data ............................................ 203 Missing Backup Method for Honoring Prescriptions ........................ 203 Possibility to Honor the Same Prescription Twice ............................ 204

6.5.2.1.6

Unassigned Assumption About the Security Implied by the Used ”Zone-Concept” ....................................................................... 204

xiv

Contents 6.5.2.1.7

Adjustment of Minimum Standards Happens Infrequently .............. 204

6.5.2.1.8

Inadequate Assumption About the Security of the Systems Inside the Healthcare Telematics Infrastructure ................................ 205 6.5.2.1.9 Security by Obscurity ........................................................................ 205 6.5.2.2 Analysis of the Connector ......................................................................... 205 6.5.2.2.1 6.5.2.2.2

Imprecise Specification of the Blacklist Management ...................... 205 Imprecise Specification of the Trusted Viewer Interface .................. 206

6.5.2.2.3

Security Issues Concerning the Communication with the Trusted Viewer .................................................................................. 206

6.5.2.2.4

Security Issues Concerning the Communication with the Primary System ................................................................................. 207

6.5.2.3 Analysis of the Primary System ................................................................ 208 6.5.2.3.1 Insufficient Classification of the Processed Data .............................. 208 6.5.2.3.2

Unassigned Assumption About the Presence of Security Measures Provided by Present Primary Systems .............................. 208

6.5.2.3.3 Analysis of the Card Reader .............................................................. 209 6.5.2.4 Additional Deficiencies Found During this Security Analysis ................. 209 6.5.2.4.1

Missing Specification for Services to Manage eHC Data by the Insured ......................................................................................... 209

6.5.2.4.2

Missing Backup Processes for Essential Healthcare Telematics Processes ......................................................................... 210

6.5.2.4.3

Possibility of Health Insurance Number Readout by Unauthorized Persons ........................................................................ 210

6.5.2.4.4

Logs for SMC Access on the Primary System May Not Be Reliable .............................................................................................. 210 Problematic Assumptions about the Environment of the Medical Service Provider .................................................................. 211

6.5.2.4.5 6.5.2.4.6

Insider Attacks from Medical Service Provider’s Personnel Not Considered in Threat Analysis ................................................... 211

6.5.2.4.7

Potential for an Attack on the Medical Service Provider’s LAN Considered As Too Low .......................................................... 211 Missing Best-Practices Recommendations for Software Keys ......... 211

6.5.2.4.8 6.5.2.4.9 6.5.3

Missing Emergency Plans Regarding New Attacks on Components and Cryptographic Methods ......................................... 212 Attack-Tree Analysis ....................................................................................... 212

6.5.4

Summary.......................................................................................................... 212

Contents 6.6

xv Security Analysis of the German Electronic Health Card’s Peripheral Parts

in Practice ............................................................................................................... 213 6.6.1 Overview ......................................................................................................... 215 6.6.2 Laboratory’s / Physician’s Practice Configuration .......................................... 215 6.6.3 Network Traffic Analyzes and its Consequences ............................................ 217 6.6.4 Attacking the German Electronic Health Card ................................................ 218 6.6.4.1 Permanent-Card-Ejection .......................................................................... 220 6.6.4.2 6.6.4.3

Fill or Delete Prescriptions ....................................................................... 220 Block a Card’s PIN ................................................................................... 221

6.6.4.4 6.6.4.5

Destroy a Card .......................................................................................... 222 Spy Personal Information ......................................................................... 222

6.6.5 6.7 7

Summary.......................................................................................................... 224

Case Studies: Lessons Learned .............................................................................. 225

Appraisal of Results

227

7.1

Overview ................................................................................................................ 227

7.2

Progress of Cognition ............................................................................................. 229

7.3

Design Proposals for Healthcare Telematics ......................................................... 230

Bibliography

233

Appendix

269

List of Figures Figure 1: IS Research Framework for Design Science ........................................................... 10 Figure 2: Research Structure: Research Questions, Used Research Methods and Results ............................................................................................................................. 13 Figure 3: Output of the Introduced Design Research ............................................................... 15 Figure 4: Structure and Results of Chapter 2 ........................................................................... 17 Figure 5: Structure of the German Healthcare System ............................................................ 18 Figure 6: Medical Communications and Documentation Standards ........................................ 26 Figure 7: IS Structure ............................................................................................................... 34 Figure 8: Monolithic and Heterogeneous Systems .................................................................. 35 Figure 9: Service-Oriented Architecture .................................................................................. 36 Figure 10: Health Telematics Infrastructure for the German Electronic Health Card ............. 42 Figure 11: Structure and Results of Chapter 3 ......................................................................... 53 Figure 12: Protection Goals Interaction in Healthcare ............................................................. 56 Figure 13: Kinds of Healthcare IS Security Approach Characteristics .................................... 63 Figure 14: Structure and Results of Chapter 4 ......................................................................... 84 Figure 15: Systematization of IS Security Analysis Approaches ............................................ 95 Figure 16: Levels of an Information Security Management System ..................................... 104 Figure 17: The Plan-Do-Check-Act approach (PDCA) ......................................................... 104 Figure 18: Structure and Results of Chapter 5 ....................................................................... 118 Figure 19: An Example for a Product Fragment – An Entity-Relationship-Diagram ........... 122 Figure 20: An Example for a Description of a Process Fragment ......................................... 123 Figure 21: Graphic Representation of Characteristics of Method Fragments ........................ 125 Figure 22: Relations between Method Fragments.................................................................. 125 Figure 23: Composition of Method Components ................................................................... 126 Figure 24: Overview of Method Concepts ............................................................................. 127 Figure 25: Matching of the HatSec Method to NIST SP 800-30, ISO 27001 and HB 174-2003................................................................................................................. 137 Figure 26: Context and Preparation Steps of the HatSec Method.......................................... 139 Figure 27: Process Step of the HatSec Method ...................................................................... 144 Figure 28: Product Step of the HatSec Method...................................................................... 148 Figure 29: HatSec Method ..................................................................................................... 153 Figure 30: HatSec Approach as a Plan-Do-Check-Act Model .............................................. 154 Figure 31: Formal Representation of the HatSec Method...................................................... 159 Figure 32: The formal Composition of the HatSec Method................................................... 160 Figure 33: Structure and Results of Chapter 6 ....................................................................... 167 Figure 34: Overview and Correlation of the performed Case Studies ................................... 168

xviii

List of Figures

Figure 35: Threats Identification according to the HatSec Method ....................................... 170 Figure 36: Attacker Models.................................................................................................... 171 Figure 37: Classification of Attacks ....................................................................................... 174 Figure 38: Process Analysis according to the HatSec Method .............................................. 176 Figure 39: Actual Process without eHC ................................................................................. 179 Figure 40: Example Process Group: “Request of information” without eHC ....................... 180 Figure 41: New Process: “Writing Data on eHC”.................................................................. 181 Figure 42: Future Process Group: “Request of Information” ................................................ 182 Figure 43: Security Analysis Product according to the HatSec Method ................................ 188 Figure 44: Old and New Discharge Letter Process ................................................................ 190 Figure 45: VerSA (bottom) and Decentralized Approach (up) .............................................. 191 Figure 46: Central Management Approach ............................................................................ 192 Figure 47: Component Overview ........................................................................................... 193 Figure 48: Remote HPC Access ............................................................................................. 196 Figure 49: Discharge Letter Process Comparison .................................................................. 197 Figure 50: Theoretical Security Analysis according to the HatSec Method .......................... 201 Figure 51: Schematic Representation of the Healthcare Telematics Infrastructure ............... 202 Figure 52: Practical Security Analysis according to the HatSec Method .............................. 214 Figure 53: The Laboratory’s Configuration ........................................................................... 216 Figure 54: The Practice Network from the Attacker’s Point of View ................................... 216 Figure 55: Attack Tree ........................................................................................................... 218 Figure 56: Activity Diagram - Permanent Card Ejection ....................................................... 220 Figure 57: Activity Diagram - Fill or Delete Prescriptions .................................................... 221 Figure 58: Activity Diagram - Lock a PIN ............................................................................ 221 Figure 59: Activity Diagram - Destroy a Card ....................................................................... 222 Figure 60: Activity Diagram - Spy Personal Information ...................................................... 223

List of Tables Table 1: Eight components of an Information Systems Design Theory for the Security Analysis Method in Healthcare ........................................................................ 14 Table 2: Standards for Information Transfer in Healthcare: Functions and Vista ................... 30 Table 3: Overview of Selected Approaches for Integrating the Digital Healthcare Enterprise ........................................................................................................................ 32 Table 4: The 10 Essential e's in „eHealth“ ............................................................................... 41 Table 5: Healthcare-Specific Data Protection Requirements ................................................... 62 Table 6: Reviewed Journals and Analyzed Articles................................................................. 65 Table 7: Scientific Fields of Analyzed References .................................................................. 66 Table 8: Overview of the IS Security Approach Characteristics ............................................. 81 Table 9: Sources of Analyzed Articles ..................................................................................... 85 Table 10: Articles of Interest .................................................................................................... 87 Table 11: The Framework of IS Security Analysis Approaches .............................................. 93 Table 12: Systematization of Other Scientific Articles ............................................................ 94 Table 13: Assessment Approaches/Checklists suggested by Standards ................................ 103 Table 14: Assessment Approaches/Checklist of Best Practice Models ................................. 105 Table 15: Mandatory and Recommended Implementation of Legislative Guidelines........... 107 Table 16: Identified Methods per Class ................................................................................. 108 Table 17: Reflected IS Security Analysis Approaches .......................................................... 109 Table 18: Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics................................................................................ 110 Table 19: Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics with Reference to Healthcare ................................ 112 Table 20: Examination of IS Security Approaches with Respect to Healthcare Specific IS Security Approach Characteristics ............................................................. 114 Table 21: Analyzed Articles – Method Engineering .............................................................. 119 Table 22: Description of the Formalization Symbols ............................................................ 132 Table 23: Reflection of IS Security Approaches with Respect to Healthcare ....................... 135 Table 24: Method Blocks and Method Fragments of the first two Steps of the HatSec Method .......................................................................................................................... 143 Table 25: Method Blocks and Method Fragments of Steps three, four and five of the HatSec Method ............................................................................................................. 148 Table 26: Method Blocks and Method Fragments of the final two Steps of the HatSec Method .......................................................................................................................... 152 Table 27: Characteristics-based Review of the HatSec Method ............................................ 164 Table 28: Abstract of the Characteristics-based Reflection of the HatSec Method ............... 165

xx

List of Tables

Table 29: Classification of the Attacker Groups in the eHC Area ......................................... 172 Table 30: Percentages of Desired Usage ................................................................................ 183 Table 31: Internet Usage by Age............................................................................................ 184 Table 32: Intended Usage of Voluntary Functions by Age (by Patients) .............................. 185 Table 33: Comparison of Internet Users to Non Internet Users ............................................. 186 Table 34: Concepts for the Central Management of Smart Cards in Hospitals ..................... 200 Table 35: Analyzed gematik Documents ............................................................................... 203 Table 36: Connector’s Functions that can be abused ............................................................. 219 Table 37: Summary of Content that can be spied out ............................................................ 223 Table 38: Attacks tested in Laboratory and Practice.............................................................. 224 Table 39: Complete Overview of the IS Security Approach Characteristics ......................... 271

1

Introduction

Since the beginnings of time, human beings have displayed a strong need for safety and security. As a matter of course, this need has been oriented towards the specific situations of the time. In the 19th and 20th centuries, the so-called “industrial age”, this safety and security need was displayed in physical security measures, including measures and equipment to protect factory workers. Helmet and gloves remain essential parts of workers clothing on every building site. With the development of electronic data processing and the internet our society is moving rapidly into the “information age”. Modern information and communication technology allows data to be collected, saved, transmitted, and used in numerous ways. This development has led to an outstanding growth of processed information and produces new central resource - raw material information. Some of this information is freely accessible, some not. Information systems (IS) security demands that information is kept confidential and that the dependability of processing information systems is guaranteed. Healthcare is in the center of this global networking. The use of networked information technology across the boundaries of institutions and various sectors is a potential opportunity for increased efficiency and improved delivery of healthcare services (Haux/Ammenwerth/Buchauer 2001). It creates numerous possibilities such as improved communication between healthcare providers and patients (Michel-Verkerke/Schuring/Spil 2004), smoother transfer of information across electronic boundaries (Sunyaev et al. 2008b), lower costs (gematik 2006q), increased access transparency, and improved treatment quality and safety (Kuhn et al. 2006). An essential step towards the implementation of a networked information system in healthcare is the introduction of an electronic health card (eHC) for patients (Avison/Young 2007) and its counterpart health professional card (HPC) for healthcare providers in Germany. These cards will form an essential part of a comprehensive national telematics infrastructure currently being developed. The eHCs will be mandatory for every German citizen. Furthermore, each healthcare provider will be required to have an HPC. Both cards will have a clearly defined structure and set of functions. In accordance with the most recent German healthcare reform plan, the introduction of the electronic health card will be followed by the introduction of an electronic patient record (Tang et al. 2006). For this reason, a health telematics platform will be implemented in Germany as a communication platform for all parties, involved in the healthcare industry. Furthermore, there is a worldwide movement to develop global healthcare telematics infrastructures in order to improve the quality of care and empower patients (AbouZahr/Boerma 2005). Some of the national and regional healthcare telematics initiatives are (Sittig 2001):

A. Sunyaev, Health-Care Telematics in Germany, DOI 10.1007/978-3-8349-6519-6_1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

2

1 Introduction x

United States of America (National Health Information Infrastructure (NHII) (Yasnoff et al. 2004; Mandl et al. 2007; Simons/Mandl/Kohane 2005)).

x

United Kingdom (Connecting for Health (CfH) (NHS 2007)).

x

Denmark (National IT Strategy (Danish Health Service) (Lippert/Kverneland 2003; Bernstein et al. 2005; Nohr et al. 2005)).

x

Netherlands (National Healthcare Information System).

x

Australia (HealthConnect – National Health Information Network (Rowlands 2005)).

x

New Zealand (Health Information Strategy for New Zealand (HIS-NZ) (Health Information Strategy Steering Committee 2005)).

x

Hong Kong (China, Health Information Infrastructure (Sek et al. 2007; Holliday/Tam 2004)).

x

Bangladesh (Integrated Rural Health Information System (IRHIS) (IRHIS)), Malaysia (Telehealth Platform (Hashim et al. 2001)).

x

Europe (European Health Insurance Card – eEurope 2005 Action Plan (Commission of the European Communities 2002; Kontaxakis et al. 2006; Pattichis/Schizas/Andreou 2002)).

Because of telematics, healthcare is currently undergoing a revolutionary process of qualitative improvement. The vision of a locally-independent and continuously accessible electronic patient record is becoming a reality as a result (Richardson 2005). The cooperating partners are no longer bound by place or time and can be located to any nation or jurisdiction (Haux/Ammenwerth/Buchauer 2001). The German healthcare system is experiencing crucial changes as well. Due to medical and technical progress, hospitals will be able to provide better quality medical treatment at reduced costs compared to the current situation. Restructuring internal processes in an economically sustainable and effective way while complying with legal and ethicals requirements is the main aim of future developments in German healthcare. The information systems (IS) penetration rate and the use of affordable IS applications to increase productivity are insufficient throughout the German healthcare system. The Roland

1 Introduction

3

Berger study – “Quality and Innovation in a Hospital” (Roland Berger & Partner GmbH – International Management Consultants 2003) reveals that one in six German hospitals have not implemented even the most basic elements of a medical information system. Only the largest and most significant institutions have adopted comprehensive IS solutions. Apart from the problem of medical documentation and billing processes being manual in many cases, the automatization of internal and external data transfer from one system to another is often missing. Expenses for healthcare in Germany are rising steadily, with a total increase of 43% between the years 1992 and 2002 (Alex&Gross 2004; Gericke/Rohner/Winter 2006). Regulations require, however, that the maximum fees for compulsory public health insurance remain stable. This situation leads to a necessity of significant cost reductions that affect not only the funding agencies (insurance companies) but also service providers (especially hospitals). Information technology can play an especially role in this situation; in much the same way it has done in other industries before. On the one hand in combination with appropriate changes in the structural and process organization in healthcare IS can make the provision of service more effective, thereby reducing costs (Babulak 2006), while on the other the quality of medical service provision in different areas (not only in imaging systems, but also for example in value-added services for patients, etc.) can be increased significantly through the correct application of IS (Ammon 2002). In such an information system (telematics platform) of communication and co-operation, the requirements for data security, data safety, and data integrity are of the highest priority when dealing with sensitive data such as personal medical information or administrative operational data (Anderson 2001; Beynon-Davies/Lloyd-Williams 1999; Krause/Brown 1996; Serour 2006; Wen/Tarn 2001). The future of this kind of integrated treatment is made possible by solutions that comprise health services and information delivered or enhanced through secure information systems. This requires the development and use of an adequate process-oriented security analysis on information systems in healthcare (Tettero et al. 1997). Guaranteeing the protection of patient-related information and the healthcare information systems is becoming increasingly important (Anderson 1996a). Modern data security services in order to protect such sensitive information are even required by law (Hildebrand et al. 2006). This new technology must not, under any circumstances, endanger the privacy of patients and risk its largescale acceptance by the general population (Choi et al. 2006). 1.1

Motivation

Dependable clinical information systems form the basis for the social and economic development of healthcare in the 21st century, particularly with regard to the quality of medical care.

4

1 Introduction

Undependable systems would result in not only economic losses but also and more critically threats to the safety of patients. Because of their ethical, judicial and social implications, medical information requires extremely sensitive handling. This demands specific security solutions and guidelines for the appropriate use of information and communication technology (ICT) in public health systems on both technical and organizational level (Adams/Blandford 2005). At present, it is generally assumed that pervasive changes, resulting from technological progress in the future, will be especially significant from an organizational perspective (Schneier 2004a). Forthcoming healthcare developments, particularly in Germany, suggest the vision of an integrated healthcare system providing seamless healthcare (Schweiger et al. 2006). This vision lays out that data is provided according to the principle of information logistics (Sunyaev et al. 2006). But the combination of different systems and infrastructure elements creates a very complex and almost unmanageable complete solution (Ash/Bates 2005). In order to deliver continuous and secure information flows along all medical treatment processes within the distributed healthcare information systems, specific security requirements for the medical sector are to be defined and implemented. From this it can be assumed that there are various possible security problems with different danger potentials (Gillon 1991). According to (Heeks 2006) such threats not only endanger IT systems but, more importantly, pose an indirect threat to the health of human beings. This implies a bridging between technology and human security requirements and assumes specific facts and their pendency according to the framing of the healthcare structures (Churches 2003). This leads to the question of whether German healthcare telematics is secure enough to satisfy requirements in areas such as privacy, safety, security and availability (Aljareh/Rossiter 2002). It is generally agreed that security issues should be considered very early on in developing an IS process such as German healthcare telematics in order to avoid risks and to facilitate the success of the overall system. Addressing these special information security needs of the health sector, a security approach should accordingly take the unique operating environment in healthcare into consideration (ISO/FDIS 27799:2007(E) 2007). By their nature, health organizations operate in an environment where visitors and the public at large can never be totally excluded (LeRouge/Mantzana/Wilson 2007). In large health organizations, the number of people moving through operational areas is significant (ISO/FDIS 27799:2007(E) 2007). These factors increase the vulnerability of the information systems not only to physical threats but also to threats from personnel and administrative issues. The other unique healthcare characteristic is the array of factors to be considered when assessing these threats and vulnearbilities (ISO/FDIS 27799:2007(E) 2007).

1.1 Motivation

5

Furthermore, the forthcoming health telematics infrastructure in Germany is the biggest telematics solution in the world, with an overall budget exceeding one and a half billion euros (gematik 2006q). These factors exacerbate the need for a security analysis method that analyzes both the technical and social aspects of information security in a health environment (Bakker 2004; Bates/Gawande 2003; France 2004; Neame/Olson 2004; Smith/Eloff 1999; van der Bijl 2005; Win/Susilo 2006). “At present there are no guaranteed methods for securing the privacy of health information on systems and the resulting lack of trust presents a major challenge to widespread voluntary adoption of these systems for health-and-security critical information” (Kuhn et al. 2008). On account of this and because of the current application concerns1 about the reliability of healthcare telematics in Germany, this thesis explores a security analysis method for healthcare telematics and offers practical information to give valuable hints for future developments in the healthcare sector. This thesis also analyzes both the technical and social aspects of information and communication security in the healthcare sector by using the constructed security analysis method. On the basis of this method the current security status of healthcare telematics in Germany is analyzed and valuable suggestions for future developments in the healthcare sector are derived.

1

73 % of German citizens have serious reservations regarding the confidentiality of their personal health data because of the introduction of forthcoming and mandatory healthcare telematics infrastructure in Germany (Forsa, 2008).

6 1.2

1 Introduction Objectives of the Thesis

The purpose of this research is to develop a method for analyzing security issues in healthcare telematics. The application of the developed security analysis method is demonstrated on a security analysis of the German healthcare telematics. The HatSec (HealthcAre Telematics SECurity) method is used to identify possible security problems in German healthcare telematics and to evaluate the imposed trade-offs of the current security solution. In order to pursue the main objective of this research, the following research questions are addressed: 1. What are the characteristics of healthcare telematics with respect to security? Creating a security analysis method for information systems in a health environment requires an examination of general conditions in the healthcare sector and corresponding problems. In the next step the security requirements have to be collected. The analysis results will be consolidated within a catalogue of IS healthcare security characteristics. For this reason the first research question can be subdivided into the following questions: 1.1. What are the unique characteristics of the German healthcare system? 1.2. Which standardized communications mechanisms are healthcare information systems based on? 1.3. What are the common healthcare IS architecture types? 1.4. What are the key elements of healthcare telematics in Germany? 1.5. What are common risk and security issues of healthcare information systems like German healthcare telematics? 1.6. What are specific security requirements for healthcare telematics? 1.7. What are the characteristics of IS security approaches with respect to healthcare? First, a description of German healthcare system is introduced in detail, including the concept, special characteristics, and key elements of the forthcoming German healthcare telematics infrastructure. Second, the specific security requirements for healthcare telematics are described in detail and summarized in a catalogue of IS healthcare security characteristics.

1.2 Objectives of the Thesis

7

The third outcome of this question is an identification of relevant organizational and technical aspects affecting the specific healthcare security analysis. These characteristics demand specific security requirements for the appropriate use of information and communication technology (ICT) in public health systems on both technical and organizational level. 2. What different types of security analysis methods can be identified in research and practice? This thesis incorporates parts of currently established security analysis methods into the design of a HatSec method. For this reason the IS security analysis approaches which are currently the most examined, discussed, and applied in both literature and practice have to identified. In a next step, the identified IS security analysis methods have to categorized and reviewed according to their suitability for the healthcare sector. Research question 2 can be subdivided into following questions: 2.1. What is the state of the art in IS security analysis approaches? 2.2. What are the different foci of the examined IS security analysis approaches? 2.3. What are the insufficiencies of existing IS security analysis approaches especially regarding their applicability in healthcare? The study of the second research question describes state of the art of IS security analysis methods that are currently receiving attention both in scientific literature and practice. The aim of the literature review is to provide a structured overview of IS security analysis approaches and to structure the IS security research around a classification scheme that can be used in future research and practice. Such an aggregation and systematization of IS security analysis methods could not be identified during the literature research. Moreover, the literature review and the examination of IS security approaches with respect to healthcare show insufficiencies with current IS security analysis approaches that lack techniques to analyze the technical and social aspects of information security in a healthcare environment. This fact again emphasizes the need for a security analysis method specific to healthcare telematics.

8

1 Introduction

3. What are the design elements and constructs of a security analysis method for healthcare telematics in Germany? The concept of method engineering methodology has to be applied and implemented in order to design a security analysis method for healthcare telematics. It has to be shown, which method elements are used to design the HatSec method. Furthermore, the design of the HatSec method has to be traceable and transparent. Research question 3 can be subdivided into following questions: 3.1. What are the principles of method construction? 3.2. What are the fundamental parts and elements of the methods? 3.3. What are the rules of assembling method fragments into a meaningful method? 3.4. What are the steps of the HatSec method? 3.5. What are the advantages of the HatSec method compared to existing IS security analysis methods? The development of a security analysis method, its concept and its incorporation into the discipline method engineering are described as an answer to research question 3. Furthermore, the specific building blocks needed for the construction of the method are explained and analyzed. As a result an example of a security analysis method for healthcare telematics in Germany is expected. This example has been named HatSec. The answer to this research question also provides a detailed overview of IS method engineering approaches in order to describe the concept of method engineering (ME). Through a literature review a formal description of methods is derived that can be used to describe methods in a basic way and transfer them to other fields of application. With the formal description of methods the process of understanding method engineering is facilitated both for the method user and its engineer. In this thesis the derived formal description of method engineering is used as a representation technique for the development and presentation of security analysis method for healthcare telematics. The described formal representation allows the HatSec method to be precisely understood regarding the usage of it as a model artifact and a reinterpretation of its syntactical elements (e.g., method elements, method chains and alliances, method fragments, method chunks and method components).

1.2 Objectives of the Thesis

9

Furthermore, the last part of the answer on the research question three has to identify the advantages of the HatSec method in comparison to existing IS security analysis methods. 4. What are the implications found when applying the method and which recommendations can be given for future healthcare telematics security trade-offs? To demonstrate the application of the constructed HatSec method the current security status of the German healthcare telematics has to be analyzed. It has to be shown, which security shortcomings of the German healthcare telematics can be discovered and resolved. Furthermore, it has to be shown, whether the developed HatSec method is practically applicable. Research question 4 can be subdivided into following questions: 4.1. How does the practical application of the HatSec method look like? 4.2. What are the current open security issues of the German healthcare telematics? 4.3. What practical implications can be derived for the further development of the German healthcare telematics from the security point of view based on the results of the practical application of the HatSec method? The security analysis of the German healthcare telematics based on the constructed HatSec method is the answer on the last research question. The conducted practical application of the HatSec security analysis method has to show the suitability of the HatSec method to healthcare IS security issues. Furthermore, the current status of the security concept of the German healthcare telematics has to be analyzed and where necessary solutions for open security issues have to be provided. The second part of this question identifies design proposals for the healthcare telematics security trade-offs in future. 1.3

Research Methodology

This section describes the research methodology used in this thesis. First, the theory of the design science approach is explained. Then the design science methodology is strictly applied during the construction and the practical application of the HatSec method, which is presented in the derived research design of this thesis. To conclude this section, the design theory of the developed artifact and its potential use in IS research is illustrated.

10

1 Introduction

1.3.1

Design Science

Theories in information systems research always concern artificial phenomena (March/Smith 1995). Such theories are about artificially created organization systems and thereby used information systems. In IS research there are two different ways to deal with artificial phenolmena. On the one hand theories can be observed and analyzed and on the other theories can be created and designed (March/Smith 1995). The goal of IS theories is to understand and describe a reality (March/Smith 1995; Hevner et al. 2004). According to (Kaplan 1964), the process of understanding and describing a reality consists of two parts: Discovery and Justification2. At first a scientist develops a scientific predication (e.g., a theory or a model). In order to describe the predicted theory, the theory has to be conceptualized (e.g., via a specifically developed language). In the next step of the process the scientist tries to justify the predication (Frank 2000).

Environment

Relevance

IS Research

Knowledge Base

Rigor

People

Foundations

x Roles x Capabilities x Characteristics

Organizations x Strategies x Structure & Culture x Processes

Develop / Build x Theories x Artifacts

Business Needs

Technology x Infrastructure x Applications x Communications Architecture x Development Capabilities

Assess

Refine

Applicable Knowledge

x x x x x x x

Theories Frameworks Instruments Constructs Models Methods Instantiations

Justify / Evaluate

Methodologies

Analytical Case Study Experimental Field Study Simulation

x Data Analysis Techniques x Formalisms x Measures x Validation Criteria

Application in the Appropriate Environment

Additions to the Knowledge Base

Figure 1: IS Research Framework for Design Science (Source: (Hevner et al. 2004))

(Hevner et al. 2004) designed a conceptual research framework for design science in the information systems field (Figure 1). Accordingly IS research is influenced by an environment and a knowledge base as direct research constraints. The research environment consists of three components: people, organizations, and technology. These three components have goals and tasks, define problems or explore new possibilities. 2

(Hevner et al. 2004) use the terms build and evaluate.

1.3 Research Methodology

11

As a result these components affect perceived business needs by organization members. Such needs are assessed and defined by the organizations. Strategies, organizational structure, organizational culture and business processes influence the assessment of business needs. The component technology and its elements (infrastructure, applications, etc.) are an essential basis for or enable the concrete business need. The three components collectively define a “problem as perceived by the researcher” (Hevner et al. 2004) and reveal the identified research gap. The other constraint, which influences the IS research is the knowledge base. A knowledge base is described as a raw material (Hevner et al. 2004) with which the science is operated. These are essential theories, frameworks, instruments, constructs, models, methods and instantiations. (Hevner et al. 2004) summarize them as foundations. Methodologies are the second part of a knowledge base. Methodologies are the various techniques for data evaluation and offer basic principles for the assessment of constructed artifacts. In contrast foundations are results or parts of results of previous research in the IS field and are used to build the artifact. Design science (design oriented research) distinguishes four different types of artifacts (March/Smith 1995; Alexander 1973; Carroll/Kellogg 1989; Nunamaker/Chen/Purdin 1991; Takeda et al. 1990; Simon 1996; Markus/Majchrzak/Gasser 2002; Vaishnavi/Kuechler 2004): constructs, models, instantiations3 and methods. Constructs are a set of terms or a language. Constructs can be combined to describe processes, situations or artifacts. Such a combination of constructs is called a model. The described artifacts can be realized by an implementation of it, a concrete instantiation. Finally, the result achievement, the thereby needed process or method, is the artifact around which this thesis is centered. A method is a logical sequence of steps in order to achieve a concrete goal (March/Smith 1995). Methods are based on underlying constructs and a model of the solution space. (Hevner et al. 2004) describe methods as guidance in finding of a solution: “Methods define processes. They provide guidance on how to solve problems, that is, how to search the solution space. These can range from formal, mathematical algorithms that explicitly define the search process to informal, textual descriptions of ’best practice‘ approaches, or some combination”. According to (March/Smith 1995), presentations of a problem and its solution are inherent parts of every method. 1.3.2

Research Design

As this research project intends to design an artifact, specifically a method for a security analysis of healthcare telematics, the underlying research methodology is design science research. “Design science […] creates and evaluates IT artifacts intended to solve identified organiza3

(Hevner et al. 2004) use the term implementations.

12

1 Introduction

tional problems” (Hevner et al. 2004). In this research the organizational problem is identified as: The forthcoming implementation of health telematics infrastructure in Germany encompasses the introduction of a uniform national smart card system to handle electronic health records, electronic prescriptions and health insurance payments. The handling of these new electronic patient cards (its use and potential misuse on the part of all involved parties – patients, physicians, hospitals, pharmacies and health insurance companies) could lead to some new and unknown security problems in the healthcare sector. Care providers and service receivers, namely patients, are particularly concerned about the reliability of the healthcare telematics system. A security analysis method specific to healthcare telematics would solve this need and analyze the current security status of healthcare telematics in Germany from social, organizational and technical points of view. Consequently this research project identifies a method to analyze healthcare telematics and also practically applies the designed artifact in a way based on the integral parts of the design science research framework. (Markus/Majchrzak/Gasser 2002) contend that every artifact construction in design science should include an iterative application process during the artifact-creating phase. In addition, a characteristics-based examination is used in this thesis in order to justify the introduced artifact (HatSec method). In order to answer the research questions (described in 1.2) the following research methods and techniques are used: literature review, method engineering, characteristics-based review and practical application of the designed artifact. Figure 2 introduces relationships between the research methods, which are used to solve the research questions, and the achieved and developed results, including the assignment of the artifact development phases to the research questions. The research methods used and results are described in chapter 5 and 6 in detail.


13

Design and Application of a Security Analysis Method for Healthcare Telematics RQ 1 !

RQ 2 !

Analysis of German Healthcare Telematics

Catalogue of Healthcare IS Security Characteristics

Analysis of IS Security Approaches

RQ 3

Literature Review / Field Research

HatSec Construction

Method Engineering

Security Analysis of the German Healthcare Telematics

Practical Application

RQ 4 Implications

Figure 2: Research Structure: Research Questions, Used Research Methods and Results (Source: own figure)

To start the special characteristics of healthcare telematics in Germany with respect to security are analyzed and summarized. Second, security analysis methods identified in science and practice are classified and assessed according their suitability for a security analysis in healthcare domain. Based on the findings of the research questions one and two, in the next steps, the HatSec is constructed and at the same time applied practically to analyze German healthcare telematics. Finally the research design and its implementation are justified and documented. 1.3.3

Design Theory

(Gregor/Jones 2007) identified eight components of information systems design theory: purpose and scope, constructs, principles of form and function, artifact mutability, testable propositions, justificatory knowledge, principles of implementation, expository instantiation. Table 1 summarizes the description of the eight components of IS design theory by (Gregor/Jones 2007) and illustrates the application of these components in the constructed method.

14

1 Introduction Component

Description

Security Analysis Method in Healthcare

Core components 1)

Purpose and scope (the causa finalis)

„What the system is for,“ the set of meta-requirements or goals that specify the type of artifact to which the theory applies and in conjunction also defines the scope or boundaries of the theory

Development of a new method for analyzing security issues in healthcare and use of the developed method for a security analysis of German healthcare telematics.

2)

Constructs (the causa materialis)

Representations of entities of interest in the theory.

Elements of method construction. Examples are: method fragments, sequences of actions.

3)

Principle of form and function (the causa formalis)

The abstract “blueprint“ or architectture that describes an IS artifact, either product or method/intervention.

A security analysis method is given as a solution design in order to aid the identification and assessment of healthcare IS security issues.

4)

Artifact mutability

The changes in state of the artifact anticipated in the theory, that is, what degree of artifact change is encompassed by the theory.

Suggestions for improving the approach are given for further work: one example is that the approach could be modified and used in other IS domains.

5)

Testable propositions

Truth statements about the design theory.

Suggestions for extending the developed method beyond the scope of the German healthcare telematics will be provided.

6)

Justificatory knowledge

The underlying knowledge or theory from the natural or social or design sciences that gives a basis and explanation for the design (kernel theories).

The method proposed is based on / derived from other security analysis methods.

Additional components 7)

Principles of implementa tion (the causa efficiens)

A description of processes for implementing the theory (either product or method) in specific contexts.

Principles for practical application of the proposed security analysis in healthcare environment will be given by the documentation and illustration of the real use of the method.

8)

Expository instantiation

A physical implementation of the artifact that can assist in representing the theory both as an expository device and for purposes of testing.

The practical application of the method will be realized.

Table 1: Eight components of an Information Systems Design Theory for the Security Analysis Method in Healthcare (Source: according to (Gregor/Jones 2007))

1.3.4

Theoretical Contribution and Research Outcome

This research project contributes multiple outcomes according to design science research methodology. First, the emergent theory on supporting the phenomenon of analyzing security in healthcare is discussed. The outcome of this discussion is the first research outcome. Then, the discipline of method engineering is explained and analyzed. The result of this analysis is used to construct the method suitable to the posed theory.


15

In this context an instrument for formal description of method development is constructed. The formal representation of the method design can be ignored by providing a security analysis method as a design science artifact as intended by the goals of this thesis. But at the same time formal description of method engineering is a IS theory itself. In this case, according to design science methodology, it defines a new knowledge as an operational principle. Such a knowledge base can be used for various developments in the IS field. This thesis contributes to design research methodology by proposing the formal description of method design, which is used as knowledge for representation technique for the HatSec method.

Emergent Theory about supporting a phenomenon

Security analysis method for health care telematics RQ1&2

Knowledge as Operational Principles

Formal representation of method design RQ3

Artifact as Situated Implementation

HatSec method RQ4

Figure 3: Output of the Introduced Design Research (Source: according to (Purao 2002))

Finally, the characteristics of the HatSec method are analyzed theoretically (characteristicsbased review) and the practical application of the HatSec method presents new results about the security analysis of German healthcare telematics. The HatSec method is the instantiation of security analysis method theory and thus is typified the developed design science artifact. The theory results should be classified by level of their abstraction as proposed by (Gregg/Kulkarni/Vinze 2001). The results are classified from the bottom up according to the abstraction levels and are illustrated in Figure 3. Thus, generalized experiences and results as well as healthcare specific security analysis method bridge the identified research gap. 1.4

Practical Implications, Users, and Beneficiaries

On the basis of the outcome of this research project a broader understanding of analyzing healthcare security is expected, which is seen as a major barrier in gaining acceptance of healthcare telematics among the general public and professionals (Kuhn et al. 2008). Therefore, a method of analyzing security in healthcare environments is created. The created method is designed so chief information security officers (CISO) can analyze forthcoming or al-

16

1 Introduction

ready implemented healthcare information systems. A CISO can use the method as a guideline to evaluate the current status of the relevant healthcare information system. This thesis shows that by using the HatSec method, chief information security officers are able to systematically identify and resolve vulnerabilities that are uncovered during the security analysis of healthcare information systems. A further contribution to practice is the identification of real problems in the current security concept of the German healthcare telematics. This work explains how existing problems can be discovered and resolved using the HatSec method. The practical application of the HatSec demonstrates the feasibility of the developed method.

2

Healthcare Telematics in Germany with Respect to Security Issues

The objectives of chapter 2 are the introduction of the German healthcare system (section 2.1), the examination of current information systems in healthcare (section 2.2), and building on that a detailed description of the forthcoming German healthcare telematics (section 2.3). As a result this chapter identifies risks and security issues related to healthcare telematics in general (section 2.3.3). These risks and issues are later examined and considered in the construction and review of the security analysis method proposed for German healthcare telematics. Figure 4 illustrates the organization of this chapter.

Scientific Objective of this Chapter

Security Issues of Healthcare Information Systems

2.1 German Healthcare Explanation

Characteristics of German Healthcare Domain

Structure of German Healthcare

2.2 Information Systems in Healthcare Determining Factors

Current Interoperability and Standardization Issues in Healthcare

Healthcare IS Architecture Types

Implications for Security Issues of Healthcare Information Systems

2.3 Healthcare Telematics Subject of Consideration

Healthcare Telematics

German Healthcare Telematics Infrastructure

Risk and Security Issues of Healthcare Telematics

Figure 4: Structure and Results of Chapter 2 (Source: own Figure)

2.1

German Healthcare

This section examines the following research question (section 1.2): 1.1.

What are the unique characteristics of the German healthcare system?

So, this section introduces the primary actors and institutions in German healthcare and describes the connections between them. Furthermore, the special characteristics of the healthcare sector are identified in order to compare the healthcare sector with other sectors.


18

2 Healthcare Telematics in Germany with Respect to Security Issues

Compared to many other countries, the healthcare sector in Germany is extremely diversified (Schweiger 2007). First there is a clear distinction between healthcare receivers (e.g., patients), healthcare providers (e.g., medical staff) and funding agencies (e.g., health insurance companies) in Germany. Healthcare providers can further be subdivided in hospitals, general practitioners (e.g., doctors in private practices or specialist clinics), pharmacies, pharmaceutical companies and other healthcare service providers (e.g., physiotherapists or masseurs). German healthcare is based on a social insurance system. Mandatory social insurances are regulated by the German state, which has supreme regulatory authority. These social insurances have been noted in the Social Security Code4 since 1976. The five primary social insurance sectors are the national pension scheme, health insurance, compulsory long-term care insurance, statutory accident insurance and unemployment insurance. More than 90% of Germany’s citizens have some form of coverage within the social insurance system. Mandatory social insurance contributions guarantee the financing of this system (Simon 2007). 2.1.1

Structure of German Healthcare Contracts (statutory health insurance only) Refunds (statutory health insurance only)

Refund of expenses (statutory health insurance only)

Legal entitlements Health Care Providers

State Legislation, supervision

Entitlements

Legislation, supervision

Health Insurance Companies

Benefits, services Claims for benefits (private insurance only) Refund (private insurance only)

Premiums Insured Citizens

Coverage Refund of expenses (private health insurance only)

Figure 5: Structure of the German Healthcare System (Source: according to (Simon 2007))

4

Sozialgesetzbuch (SGB).

2.1 German Healthcare

19

In order to describe the structure of German healthcare a simplified distinction is drawn between the four core groups of interest: the German state, insured citizens, healthcare providers and health insurance companies. The German state creates the basis and legal foundations for public healthcare system and controls and guarantees the non-governmental parties’ (e.g. heath insurances) compliance with regulations. Furthermore, the state supports statutory health insurances in the case of some services such as maternity payments. Insured citizens pay insurance contributions to the health insurance funds and gain health insurance coverage for themselves and their family members. Because of their coverage insured citizens can claim benefits such as healthcare services or medical prescriptions (pharmaceuticals). The population of Germany is currently around 82 million people. Almost 4.3 million people in the country are employed in the healthcare sector. The German healthcare system encompasses more than 188,000 healthcare providers, e.g., physicians, medical specialists, dentists. In addition, Germany’s healthcare sector includes more than 21,000 pharmacies, approximately 2.200 hospitals, and more than 300 insurance companies (Simon 2007). Having introduced the structure of German healthcare, the next section of the paper describes the basic characteristics of the healthcare sector. 2.1.2

Characteristics of the German Healthcare Sector

2.1.2.1 Information Exchange and Distributed Information Flows in German Healthcare System German healthcare involves an enormous amount of information exchange between the involved stakeholders described in the previous section. According to (Haas 2006a), more than 700 million prescriptions are filled, 45 million physician’s referrals are issued, and 15 million hospital admissions occur in a single year. The current trend is that the exchange of information is increasing. As described above, healthcare is characterized by a broad spectrum of different actors, including service receivers, service providers, and health insurance companies (Grimson/Grimson 2002). Patients receive services that are provided by numerous individuals and institutions, including healthcare professionals, hospitals, outpatient care services, rehabilitation services, and drug stores. Within hospitals the services provided can be further broken down, as there are highly specialized actors in each field of medicine such as cardiology and dermatology. In addition to intra-disciplinary specialties, there are also inter-disciplinary healthcare workers such as nurses and physical therapists working in hospitals. In order to provide accurate diag-

20


noses and effective treatment, these heterogeneous groups need to be managed and their activities need to be coordinated using information and communication technologies. The distribution of work suggests the existence of a fractured and in some cases isolated information systems’ landscape. This effect is reinforced by the fact that the respective service providers usually act autonomously and independently from each other. This can lead to failures of the different groups or different departments to attain the desired goal - effective and efficient diagnosis and treatment of patients, i.e., management of ill persons. 2.1.2.2 Current Problems Various types of media are to be found in healthcare. A lack of congruous media is caused not only by the parallel usage of both paper-based and digital documents, but also by the usage of different digital data structure formats which leads to inconsistencies in the data collected (Mikkelsen/Aasly 2001). Although (Mikkelsen/Aasly 2001) identify significant differences between the information that is recorded on paper-based and digital media, the number of documents with errors is relatively small compared to the total number of documents examined. The potential consequences of incorrect medical information are determined to be more severe than the consequences of data that is completely missing (Bagchi/Udo/Kesh 2005). Another consequence of data inconsistencies is the error-prone transmission of data to the target medium (Baker et al. 2005). As a result, incorrect information, as identified in the study by (Mikkelsen/Aasly 2001), can potentially be generated but should be avoided as it is closely correlated with a high risk for poor decision-making. Failures in the treatment process reduce the quality of administered treatments. Several sources of errors within the diagnostic process, the first step in the treatment process, have been identified (Bhasale 1998): 1. Error-prone assessment of information, especially when proposing and evaluating hypotheses. 2. Errors in the transfer of information. 3. Inaccurate patient records. 4. Inadequate communication between patients and service providers. 5. Inadequate communication between various service providers. The identification and correction of failures could increase the quality of the treatment process in hospitals (Bates et al. 1994).

2.1 German Healthcare

21

The situation described related to intra-institutional communication can also be equally transferred from the hospital environment to the wider healthcare system. The distribution and discontinuity in the process of providing treatment is even more distinct if the treatment process takes place in different institutions. Deficits in the cross-institutional treatment processes have been demonstrated (Forster et al. 2004). The strict division of service providers and the related existence of different information systems imply heterogeneous data formats (Sunyaev et al. 2006). Since there is no trend towards a uniform and comprehensive standard for semantic and syntactic data exchange can be expected, the need for convergence between the established standards can be observed (Häber/Dujat 2004). Significant deficits in terms of information logistics resulting from the factors mentioned above can be identified. To correct these deficits the right information needs to be provided at the right point of time, in the right quantity, at the right location, and in the right quality (Augustin 1990). An accurate and efficient flow of information is especially important in healthcare (Anderson 1997). There are, however, aspects of the healthcare industry that hinder the elimination of the identified deficits and, as a consequence, compromise the ability of the sector to improve the quality of services offered. Because of these issues, information systems in healthcare have to deal with the complex situation caused by the large number of involved actors and clinical patterns. The specialization of healthcare providers and the diversification of the services they provide are further obstacles. Such diversity of information increases the need for appropriate security controls and at the same time impedes their development. 2.1.2.3 Specifics of the German Healthcare Domain Healthcare has many unique features when compared to other sectors. Most of these features do not concern IS security directly, but they must be considered in order to effectively manage healthcare IS security. This section describes the specifics of the healthcare sector and links them to IS security issues when possible. x

The healthcare sector is partially regulated by a state and has to deal with detailed legal requirements (e.g., 12 Social Security Code-books, German Insurance Supervision Act, German Insurance Contract Act, etc.). Financial support from the state also guarantees a certain quality of the services offered, and also makes the pursuit of profit inconsequential in some parts of healthcare. This situation could lead to inefficiency as

22

2 Healthcare Telematics in Germany with Respect to Security Issues profit making is not the only goal of a healthcare system (Newhouse 2002; Arrow 1963). x

Health itself is not a commodity or good and for this reason healthcare services do not deal with health in the marketplace. Healthcare services buy, sell or provide according health information (McGuire/Fenn/Mayhew 1989; Culyer 1989). The received and perceived healthcare service is therefore based completely on the quality of the available health-related information. The aim of healthcare IS security is to guarantee the high quality of health-related information despite the enormous information asymmetry in the healthcare sector (McGuire/Fenn/Mayhew 1989). Ethical considerations play an essential role in healthcare (Moatti 1999) as well.

x

The healthcare sector includes a large number of non-profit governmental and charitable organizations. Their purpose is to guarantee high quality and economical healthcare services. The healthcare organizations and institutions that are profit oriented are strictly controlled by government regulations. Furthermore, due to the state involvement the risk of for-profit healthcare organizations causing harm remains small.

The description of healthcare IS security approach characteristics in section 3.3 is based in parts on these healthcare specifics. The next section provides an overview of information distribution in healthcare and explains the different IS communications, cooperation and coordination techniques. Through this this thesis provides insight into the complexity of this uncontrolled growth from an IS security point of view. 2.2

Information Systems in Healthcare

Most healthcare facilities now recognize that a comprehensive cross-linking of separate departments within their organization as well as the integration of external partners is necessary step for efficient operation. Many medical institutes include this objective in their budget planning as a high priority – however it is only achievable with adequate concepts and appropriate information and communication technologies (Schweiger/Leimeister/Krcmar 2005). Unfortunately, comprehensive information systems strategies are often lacking in healthcare, especially in cases where different medical departments are allowed to make autonomous decisions on adopting a particular information systems application, applications which are usually chosen on the basis of the one department’s requirements (Ball 2003). In doing so, these systems are mostly undervalued or do not consider the trans-sector interrelationships of the

2.2 Information Systems in Healthcare

23

service providing processes used. Many isolated medical systems were and are implemented in different healthcare areas creating the foundation for unmanaged information systems growth taking the form of heterogeneous, partially incompatible redundant systems. The connection of these systems afterwards is often very cost-intensive due to the required interface programming. This scenario underlines the essential role of technically stable and economical integration architecture and of an aligned integration platform as a part of an adequate information systems strategy in medical institutions. Generally, the concepts of integration are divided (Balzert 2001; Krcmar 2005) into three areas: function integration, data integration and business process integration. x

Function integration denotes the aggregation of multiple independent applications separated from each another into a central application. This should prevent the repeat implementation of semantically similar functions and hence avoid data transfer interfaces.

x

Data integration is based upon a uniform and central data model. This central data model allows participating applications to work avoiding data redundancy, guaranteeing data consistency and comprising a definition of common semantics for all participating applications.

x

Business process integration combines and integrates the various functions in an integration platform. The individual applications are used throughout a business process providing their functions while staying unmodified.

Therefore, system integration is a combination of various applications in the healthcare sector. In this context integration should reduce or avoid the overlaps between different applications to a lesser extent and instead aim for a loose coupling principle according to which the individual components should be left to operate as autonomously as possible. User friendliness, scalability, and the smooth cooperation of single components are the advantages of information integration. Such a system integration is defined as seamless healthcare, which could save costs (personnel and training expenses, error correction costs, repeat records etc.) and optimize all processes, both internal and external (Lenz et al. 2005). The following section provides a detailed description of the vision of seamless healthcare.

24 2.2.1

2 Healthcare Telematics in Germany with Respect to Security Issues Seamless Healthcare

The vision of seamless healthcare can be summarized as comprising horizontally and vertically integrated healthcare processes enabled by seamless IT support. The healthcare services provided are capable of adapting to the variable and individual situation of the patient over time (Ash/Berg 2003). Therefore, this concept focuses on an effective and efficient provision of patient-centered healthcare, independent of time and location. This implies the interconnectedness of all information systems and basing information exchange on data formats for semantic and syntactic unification. Several studies (Fowles et al. 2004; Pyper et al. 2004; Ross et al. 2005) have come to the conclusion that patients are strongly interested in their personal medical information. This interest in medical information could encourage compliance with the treatment process (Essex/Doig/Renshaw 1990) and improve the outcome of treatment (Cimino/Patel/Kushniruk 2001; Ball/Lillis 2001). The described integration of information and the resulting patient empowerment takes place in several steps. Five levels of digitalization (Waegemann 1999) flow into a comprehensive electronic patient record. This record is an integration of data from different and locally distributed institutions and enables the patient to monitor their own medical data and to add their own information in some cases (Wooldridge/Jennings 1995). Applying the vision of seamless healthcare can increase the quality of treatment since all relevant data can be made available to healthcare providers according to the principle of information logistics. This reduces the risk of errors. As all information is stored together, there is little risk of accidental omission or misplacement of data (Bergmann et al. 2007). The availability of digital data and automatic translation between different digital data formats provide ease in transferring data between various media thereby reducing possible errors and the need for the manual handling of data (Bird/Walji 1989). Storage of data in a comprehensive electronic patient record could help to reduce healthcare costs although this aspect of electronic data storage has not been fully investigated. 2.2.2

Interoperability, Standards and Standardization Approaches in Healthcare


Which standardized communications mechanisms are healthcare information systems based on?

Seamless information logistics in healthcare states that in future, stakeholders in healthcare will receive the optimal supply of data required to achieve their goals, independent of their time or technical accessories.


25

In the area of healthcare IS management there are three basic properties related to IS services that the future healthcare integration architectures and platforms should achieve (Sunyaev et al. 2006): x

Interoperability - The cross linking and alignment of all participating systems and applications within a healthcare facility and to its environment are to be made possible through appropriate interfaces or should be realized as a complete, self-containing system. In combination with the appropriate structural and process organizational changes this can lead to the streamlining of work processes and make efficient rationalizations and cost reductions possible.

x

Flexibility - All applications, tools, processes, and methods of each medical system have to exhibit a high level of flexibility in order to radically alleviate, support and develop the working and organizational environment of medical care.

x

Dynamics - All necessary structures for guaranteeing and securing the interoperability and flexibility properties of every medical system have to be dynamic; thus guaranteeing a stable system. This guarantees the sustainability and extendibility of the system.

The described vision of seamless healthcare, as enabler of healthcare telematics, is based on standardized communication mechanisms. The healthcare telematics security concept has to manage the standards and integration architectures described in this section. Standardized communication enables the exchange of data between all participating healthcare information systems (Healthcare Information and Management Systems Society (HIMSS) 2008). Interoperability processes in healthcare and medical market require generally accepted standards (Sunyaev et al. 2006) in order to achieve the following: (1) efficient and effective combination of distributed medical systems, (2) increase competition and reduce costs, (3) easily update or replace healthcare IS products, and (4) reduce errors to make healthcare services safer (WHO 2008; CEN/TC 251 European Standardization of Health Informatics 2008, 1997). IS standards in the healthcare sector can be divided into two groups: syntactical and semantic standards. For an overview of current internationally accepted healthcare IS standards, see Figure 6. Sunyaev provides a comprehensive discussion of accepted IS standards in healthcare (Sunyaev et al. 2008b).

xDT

Contains Metadata for

EDIFACT

DICOM

Are Communication Standards

communication standards

1..*

1

1

1

HL7

< Is formulated via

1

terminology system for communication standards

Contains Metadata for

LOINC

< Is formulated via

SNOMED

documentation standards

1

0..*

medical terminology system

1..*

1

1..*

1

CDA

MeSH

1

UMLS

Contains Metadata For

terminology system for documentation standards

Are Documentation Standards

terminology system for medical terminology systems

ICD

26 2 Healthcare Telematics in Germany with Respect to Security Issues

Figure 6: Medical Communications and Documentation Standards (Source: according to (Sunyaev et al. 2008b))


27

The advantages of generally accepted standards for the processes in healthcare and the medical market can be summarized as follows (CEN/TC 251 European Standardization of Health Informatics 2008; Wirsz 2000): x

Standards increase competition and reduce costs.

x

Standardized products could easily be replaced or updated.

x

Standardized products of various suppliers could easily exchange medical information.

x

Healthcare institutions are able to progressively extend their offers/capabilities.

x

Standardized products could reduce errors and make healthcare services safer.

Several national and international committees, German as well as other European or American - e.g. European Committee for Standardization (CEN (CEN/TC 251 European Standardization of Health Informatics 2008)), Deutsches Institut für Normung (DIN (DIN 2008)), Integrating the Healthcare Enterprise (IHE (IHE 2008; IHE-Europe 2008)), World Health Organization (WHO (WHO 2008)) - have been founded to ensure unified standardization of national and international healthcare systems. Accordingly, there are numerous standardization attempts, which partly correspond to but also disagree with each other (Märkle/Lemke 2002). Two main objectives of these committees can be distinguished: the development of standards for communications and standards for documentation in healthcare. The former focus on enabling the efficient and effective combination of medical information systems, in order to facilitate the exchange of data between different medical information systems (IHE 2008). The latter aim to ensure the correct interpretation of the content of electronically exchanged information (Haas 2006a). The transmission of data between heterogeneous and isolated medical information systems requires the interoperability of systems and data (Hasselbring 1997). Interoperability encompasses norms, interfaces, and standards - the basis for data exchange and communication between participating applications (WHO 2008). 2.2.2.1 Communication Standards Communication standards, also called syntactical standards, ensure the correct transmission of medical and administrative data between different information systems. In the clinical area, one can distinguish them worldwide, mainly between the established standards of Health Lev-

28


el 7/Clinical Document Architecture, (HL7/CDA), Digital Imaging and Communications in Medicine (DICOM), and Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) (Pedersen/Hasselbring 2004). Their openness is the primary factor behind their widespread acceptance. Health Level 7 is the international, vendor-independent, main communications standard in healthcare for the exchange of information between systems and institutions. The Version 2 family of this standard is based on events that trigger the exchange of data. Beginning with Version 3 XML5, data structure is supported, alleviating the integration of data into information systems, since adequate libraries for XML handling are available. HL7 operates at the application layer of the ISO/OSI reference model (ISO7498-1(ISO 2008)). The Clinical Document Architecture (Health Level Seven Inc. Ann Arbor MI 2008) enhances the HL7-standard with a description of the structure and the contents of clinical documents (e.g., discharge summaries and progress notes), based on an XML-format. HL7/CDA also offers a model for the exchange or the common use of information and the option to individually reuse this information (Dolin et al. 2006). Digital Imaging and Communications in Medicine (NEMA 2008) is an open standard for the exchange of images in healthcare. In addition to images, it can also contain additional metainformation, such as patient names, dates of admission, device parameters, and attending physician. The standard lists the data fields (e.g., images, diagnosis, patients, studies, series, and so on), functions of network services, as well as syntax and semantics for the commands and messages. DICOM can store images with or without loss of information, in accordance to TIFF (Tagged Image File Format) and JPEG (Joint Photographic Experts Group) formats, and enables electronic archiving of images in all medical information systems (Schutze et al. 2004). Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT 2008) standardizes the formats for the electronic exchange of administrative data in healthcare information systems as well as in other sectors. Orders, calculations, and payment orders in the health service often rely on it. EDIFACT, unlike the other communication standards dis5

The standard Extensible Mark-up Language XML, as defined by the World Wide Web Consortium (W3C), is used to create machine- and human-readable documents in the shape of a tree structure, thereby defining the structure of these files. An actual document requires the definition of several details, particularly the definition of elements of structure and their arrangement within the document tree. XML is a subset of theStandard Generalized Markup Language (SGML). It is also a metalanguage, which is capable of defining numerous amounts of different mark-up languages, which are still closely related in their basic structure. In order to describe the structure of XML documents, a so called “scheme language” is used. The two most important scheme languages are the Document Type Definition (DTD) and the XML Schema.


29

cussed, was not specifically designed for the healthcare field. It is used globally by numerous commercial organizations in various sectors to exchange accountancy-related data. There are several specific standards, so called xDT-standards (KBV (Kassenärztliche Bundesvereinigung Deutschland)), currently used in the general practitioner segment of German healthcare. xDT is a set of several German standards, which are designed to simplify the communication and data exchange between healthcare providers (i.e., physician’s offices, hospitals, etc.) and health insurance companies. As a result, xDT aims to reduce paper waste by applying information technology using the following data formats: x

ADT: AbrechnungsDatenTransfer (invoice data for medical services).

x

AODT: AmbulantesOperierenDatenTransfer (securing the quality of out-patient surgery).

x

BDT: BehandlungsDatenTransfer (for the communication between general practitioners).

x

KVDT: KassenaerztlicheVereinigungDatenTransfer (standard for communication between physician’s offices and health insurances).

x

LDT: LaborDatenTransfer (communication with laboratories).

x

GDT: GeraeteDatenTransfer (communication with medical devices).

x

ODT: OnkologischerDatenTransfer (ontological data carrier for the documentation of tumor-related information).

Even though all of these xDT-standards serve different purposes, they are all structured according to the same basic rules and principles.

30

2 Healthcare Telematics in Germany with Respect to Security Issues Standards for medical data exchange HL7

DICOM

VCS

xDT

EDIFACT

CDA

IHE

SCIPHOX

D2D

HIS

+

o

-

+

+

+

+

o

o

RIS

+

+

-

o

-

o

+

o

-

PACS

+

+

-

o

-

+

+

+

-

MPI (Master Patient Index)

+

o

-

+

-

+

+

+

-

Graphical diagnosis

+

+

-

-

-

+

+

o

-

Archiving

o

+

-

o

-

+

+

+

o

Functions in healthcare

Diagnosis comments

+

o

o/+

+

-

+

+

+

+

Image documentation

-/o

+

-

-

-

+

+

+

-

Video documentation

-

-a

-

-

-

+

+

-

-

Patient registering

+

-

o

+

-

-

+

-

-

HER

o

+

o

+

+

+

+

+

o

Invoicing

+

-

+

+

+

+

+

+

+

Prescriptions / Ordinances

o

-

-

-

-

+

+

+

-

Emergency data

o

-

-

-

-

+

+

+

-

Communication between / with physicians in private practices

+

o

+

+

+

+

+

+

+

General prospects

+

+

-

-

+

+

+

o

o

According to German healthcare telematics

+

+

o

-

+

+

-

+

o

Extension of scope of operation

+

o

-

-

-b

-b

+

o

o

Prospects

- = this function is not applicable / no expectation for success o = partially applicable / slight chance for success + = fully applicable / good chances for success a in development b already an open standard

Table 2: Standards for Information Transfer in Healthcare: Functions and Vista (Source: according to (Sunyaev et al. 2008b))

There are currently efforts to harmonize the introduced communication standards on an XMLbasis: HL7/CDA already incorporates the XML-format for structuring clinical documents; additionally, there are also XML-based specifications for the DICOM standard (NEMA 2008), for the xDT-standards (Bundesministerium für Gesundheit und Soziale Sicherung 2004), and for EDIFACT (EDIFACT 2008). The advantages of introducing XML-based data structures can be described as follows:

2.2 Information Systems in Healthcare x

31

Automatic processing can be simplified by using established XML programming libraries.

x

XML is an open and platform-independent standard.

x

XML can be read and understood by users.

The communication standards discussed support various functions in healthcare information systems (Table 2). Such a use of miscellaneous standards in several healthcare service sectors is the most important problem in healthcare electronic communications at present (Lenz et al. 2005). Healthcare currently uses a widely diversity range of IS standards (Mauro et al. 2009b). At the moment, almost none of the standards used for information transfer in healthcare address security or privacy issues. However the standards previously discussed also build the foundation for communications in the German healthcare telematics infrastructure being developed. Considering the significance of this issue, communication standards have to be analyzed not just according their secure applicability in the healthcare domain. The next section introduces standardization organizations and documentations standards related to interoperability in healthcare. 2.2.2.2 Documentations Standards and Standardization Approaches Terminology and documentation standards are created to facilitate the correct interpretation of the content of electronically exchanged messages between different medical information systems (see also Figure 6). These standards are responsible for the conversion of encoded medical data. Logical Observation Identifiers Names and Codes (LOINC (Regenstrief Institute Inc. 2008; Huff et al. 1998)) provides a multidimensional terminology system for clinical laboratories. LOINC allows detailed descriptions of medical circumstances so that almost all clinical problems can be solved automatically. The classifications are systems of concepts that are used for medical documentation. In comparison to terminology systems, classifications are less complicated, and thus mostly one-dimensional. The International Classification of Diseases (ICD (DIMDI 2008; WHO 2008)) is an example of a classification of illnesses and related health issues. Systemized Nomenclature of Medicine (SNOMED (SNOMED International 2008)) is a nomenclature. Nomenclatures are combinations of terms that are based on determined concept

32


orders. SNOMED CT covers the arrangement of a unified terminology for expressions in the medical field and supports the languages English, German and Spanish. Initiatives for information integration in healthcare

Characterization and Goal

Approach and assignment of internationally accepted standards

Integrating the healthcare enterprise (IHE) (Hornung/Goetz/Goldschmidt 2005)

IHE is an international initiative, driven by healthcare professionals and industry, to improve the communication of medical information systems and the exchange of data.

IHE’s approach for the information integration is based on propagation and integration/usage of HL7 and DICOM standards. IHE promotes and advances these standards as a suggestion for standardizing bodies.

Professionals and citizens network for integrated care (PICNIC) (Danish Center for Health Telematics 2003; Saranummi 2005)

PICNIC is a European project of regional healthcare providers in a public private partnership with industry to develop the new healthcare networks and to defrag the European market for healthcare telematics.

The development is an open source model, i.e., an open and interoperable architecture with exchangeable components (aim is an easy and simple integration of external products). All components must be based on established standards, such as HL7/CDA.

Open electronic health record (openEHR 2004; The openEHR foundation 2006)

OpenEHR foundation is dedicated to developing an open specification and implementation for the electronic health record (EHR). OpenEHR advances the experiences of GEHRprojects (The Good European Health Record 2006; Blobel 2006) in England and Australia.

The project works closely with standards (e.g., HL7). However, it does not adopt them verbatim but tests, implements and improves their integration and application while giving feedback to the standard bodies.

Standardization of communication between information systems in physician’s offices and hospitals using XML (SCIPHOX) (Standardized Communication of Information Systems in Physician Offices and Hospitals using XML (SCIPHOX) 2006; Gerdsen et al. 2005)

SCIPHOX is a German initiative that aims to define a new common communications standard for ambulant and inpatient healthcare facilities.

The basis for the information exchange is the XML-based HL7/CDA standard. SCIPHOX adapts and improves this global standard for local (German) needs.

www.akteonline.de (Ückert et al. 2002; akteonline.de 2006)

akteonline.de is German state-aided project to develop a Web-based electronic healthcare record.

akteonline.de developed dynamic Web pages, which can be accessed via internet and look similar to physicians and hospital software. The project is based on the common communication standards (DICOM and HL7/CDA).

Table 3: Overview of Selected Approaches for Integrating the Digital Healthcare Enterprise (Source: (Sunyaev et al. 2008b))

The thesaurus Medical Subject Headings (MeSH (United States National Library of Medicine/National Institutes of Health 2008)) is an extension of a nomenclature. MeSH enables the indexing of international publications - such as journals, articles, and books - for the United


33

States National Library of Medicine (NLM). Expanding a thesaurus with semantic and linguistic information creates a met thesaurus. The Unified Medical Language System (UMLS (UMLS 2008)) is a metathesaurus that tries to integrate all important medical terms into a standardized expression and to represent all possible term relationships accordingly. Because of the existence of different documentation standards, many incompatibilities occur, such as in the cases where different users use different terminology systems for documentation (McDonald 1997). Complete interoperability, consent identification for medical data, and meaningful cooperation of functions, are the primary challenges in the development of healthcare information systems over the coming years (Frist 2005). There are many different approaches to standardizing electronic communications and documentation in healthcare to achieve interoperability. Some of the promising standardization initiatives are summarized in Table 3. The analysis described in Table 3 shows that existing international and German standardization approaches for interoperability in healthcare can be divided in two opposing groups (Märkle/Lemke 2002). One group consists of commercial organizations that promote and adopts proprietary standards such as HL7 and DICOM. The other group includes universityand government-funded initiatives which use and support open standards as those initiated by the European Committee of Standardization (CEN/TC 251 European Standardization of Health Informatics 2008). This difference also has a clear geographic component - with the first group being located primarily in the U.S, while support for the latter initiatives comes primarily from Europe. Hopefully, both camps learn from each other and eventually begin to merge. Such a development would be a vital step to making the vision of complete interoperability in the healthcare sector a reality. Nevertheless, all of these standards have contributed indispensable knowledge in reaching the current situation. 2.2.3

Healthcare IS Architecture Types

This section seeks an answer to the following research question (section 1.2): 1.3.

What are the common healthcare IS architecture types?

Generally, IS architecture types in healthcare are divided into three groups; monolithic systems, heterogeneous systems, and service-oriented IS architectures (Reichertz 2006). The term architecture type refers to the hardware- and software-technical arrangement of an application (Figure 7) (Haas 2006a).

34


Hardware level constitutes the technical basis of every IS system. This level encompasses the technical equipment of a healthcare IS system: hardware, network and operating system. The software level consists of applications and databases (Broy/Rausch 2005). Applications and/or databases can cooperate centrally or in a distributed way (Richter/Haller/Schrey 2005).

Software SOA Application Monolithic System

Heterogeneous System

Central Database

Distributed Database

Functions

Services

Database

Hardware / Network/ Operating System

Figure 7: IS Structure (Source: own Figure)

2.2.3.1 Monolithic System Monolithic systems are characterized by a common data basis (Haas 2005). Design and implementation principles demonstrate a common structure that is valid for all system components included in the logical architecture model. These are procured from a supplier that sells the system as a complete solution. Most applications are oriented towards patient care, a situation that is manifested through their patient- or office-close level. Hence, the integration approach is oriented towards a focus on patient treatment (Andersen/Jøorgensen 1988; Masys et al. 2002). The architecture is characterized by a permanent data consistency. The utilized database management system is yet to be constructed in a way recognizing the requirements of software connection. Figure 8 demonstrates a possible example of a monolithic healthcare system.


35

Local Database

Archive Management

Cardiology System

Cardiology System

Laboratory System

Central Database, a conceptual Model

Local Database

Archive Management Laboratory Dystem

Local Database

Communication Server

RIS/PACS Local Database

Patient Data Management System

Surgery Document System

RIS/PACS

Patient Data Management System Local Database

a)

Monolithic System

b)

Surgery Document System

Local Database

Heterogeneous System

Figure 8: Monolithic and Heterogeneous Systems (Source: according to (Haas 2005))

2.2.3.2 Heterogeneous System Due to integration through communication servers, heterogeneous systems are connected with each other (Hasselbring 1997). For example, special applications for radiological departments or laboratories are integrated. Figure 8b illustrates the coupling of multiple departmental systems to a central communications server. All systems communicate exclusively through messages that are forwarded to a corresponding addressee through the communication server. The HL7 standard, which has established itself in the medical field, often serves as a basis for message and information exchange (Health Level Seven Inc. Ann Arbor MI 2008). When necessary, messages can be converted by the communications server to a different format so the receiver can read the message. Systems send their messages through communications server in order to exchange information with other systems. For this to happen the corresponding receiver needs to be known to as a sender, as a communications server only forwards messages to receivers and is unable to decipher them (Haas 2005). Data contained in received messages can be integrated in local databases by the receiving subsystems. Furthermore it is the task of subsystems to keep their local databases consistent with those of other subsystems. A communications server can not assume this task because it unable to differentiate between messages and determine whether they are common messages to the subsystem or, for example, update requests for the local database. 2.2.3.3 Service-Oriented IS Architecture The SOA-principle has significant differences to the information systems used today in healthcare (Figure 7). The SOA-principle is based on standardized logics. It can function in-

36


dependent of the technological and software-technical structure of a system. Because of this it can access both centralized and distributed databases.

ServiceProvider publish

link

ServiceBroker

ServiceRequestor search/find

Figure 9: Service-Oriented Architecture (Source: according to (Dustdar 2003))

In service-oriented architecture, principles of modularization and of hiding the implementation details behind defined interfaces are transferred to an application level: service providers register their services with the help of a central service-broker. A service is described in a standardized format. If the service consumer needs a particular service they send a search query to the service-broker who provides the address of a suitable service provider if one exists. Usage of suitable services is then attached to service providers. In healthcare, SOA-architecture provides an integration of specialized systems, which are connected through publishing of other systems’ services (Mauro et al. 2009b, 2010). In doing so, support of new business processes can be achieved through a combination of already existing services (Richter/Haller/Schrey 2005). Using web technology the SOA-approach allows not only an internal connection of information systems but also cross-boundary institutional integration. 2.2.4

Implications for Security Issues of Healthcare Information Systems

All in all, one can note that there is a diversity of heterogeneous information systems in healthcare (Schweiger et al. 2006; Jennings 2001). This leads, among other issues, to unnecessary multiple data collections and hence to significant loses of time and money. The necessary interfaces are expensive to maintain and implement. There is almost no therapy transparency due to the lack of continuous information logistics. Data protection terms are written out accurately but are hard to be adhered to with existing systems. There are too many standards, their application is complicated, and can be interpreted differently (Schweiger/Krcmar 2004). They rarely agree with each other and are not harmonized (Haux 2006).


37

Achieving secure interoperability to improve efficiency in healthcare requires greater efforts to encourage the harmonization of standards, especially on the semantic level (Sunyaev et al. 2008c). To improve health services, reduce costs, and achieve the vision of seamless healthcare, the problem of standardized software solutions must be solved. As it can be assumed that there will not be a global standard for the integration of semantic and syntactic data, an integration solution (e.g. German healthcare telematics) has to be capable of dealing with different established standards. Future efforts in both research and practice should focus on this topic. Another complicating but important factor is the guaranteed protection of sensitive personal information as well as of health information systems in general. This requirement plays a central role in healthcare because of various legal requirements. For example, regulations insist that the newest data security services are preferably used (Grimes 2004). According to (Blobel/Pharow 2005), the following aspects of security should be considered imperative during conception and development of a medical communication and information system: x

Encrypted data storage.

x

Encrypted communications.

x

Revisable access control.

x

Communications utilizing electronic signatures.

x

Integration of the health professional card (HPC).

x

Integration of PC and network security systems.

x

Secure internet connection.

There is almost no more possibility of effectively integrating these aspects retrospectively (Blobel/Pharow 2005). Therefore these security criteria are also to be considered from the beginning of the conception of integration architecture, such as the healthcare telematics system being developed in Germany (Gritzalis 1997). The standards and standardization approaches discussed as well as illustrated common healthcare IS architectures form the basis for German healthcare telematics. The standards and IS architectures discussed are the cornerstones for the development, implementation, or analysis of healthcare information systems from a security-oriented point of view. The availability of healthcare specific skills and knowledge for effective information systems security analyses are essential issues related to the use of health-

38


care IS security (Brooks/Warren 2006). This requires knowledge of the formats of clinical data, IS standards in healthcare, information on IT and IS in healthcare as well as of clinical and nursing processes (ISO/FDIS 27799:2007(E) 2007). A security analysis of German healthcare telematics must confront the enormous diversity of IS standards and standardization approaches in healthcare (Rigby et al. 2001). The following security issues summarize the derivations from description of information systems in healthcare discussed so far (Janczewski/Xinli Shi 2002; Zhang/Ahn/Chu 2002): x

Healthcare systems are heterogeneous, isolated and dispersed (large number of small organizations, multiple providers and multiple locations).

x

It is impossible to fully predict what data should be shared, when and to whom.

x

Under the healthcare environment, the information sharing tends to be very dynamic and often ad hoc. Hence, a centralized management approach is not appropriate to the healthcare domain.

x

In a healthcare setting, the specific level of access and permissions a user can have to the system will be determined not only by his role in the organization but also by the relevant security context, such as the patient, location, and time.

x

A mechanism must be provided for revoking sharing privileges when they are no longer needed.

The next section provides an overview of healthcare telematics, in particular the German healthcare telematics infrastructure is described in detail. An examination of the potential risk and security issues of healthcare telematics concludes the next section.

2.3 Healthcare Telematics 2.3

39

Healthcare Telematics


What are the key elements of healthcare telematics in Germany?

As described above, integrated treatment, as described in the concept of seamless healthcare, comprises health services and information delivered or enhanced through the internet and related technologies, based on the communication between all information systems of the various healthcare stakeholders (Kuhn/Giuse 2001; Pantazi/Kushniruk/Moehr 2006). The healthcare system already maintains one of the biggest information and communications technology systems in Germany. In this regard, medical information systems are a strategic necessity for developing an integrated healthcare sector that can improve services (ISO/FDIS 27799:2007(E) 2007), reduce medical errors (LeRouge/Mantzana/Wilson 2007), avoid redundant medical examinations, and reduce costs. Such an integrated electronic healthcare is also called eHealth (Oh et al. 2005; Pagliari/Sloan/Gregor 2005). The term eHealth is mostly used as a synonym for healthcare telematics (Haas 2006a). “eHealth is already the third largest pillar of the healthcare industry (after the pharmaceutical and medical devices industries)” (Kuhn et al. 2008). It is obvious that eHealth is much more than just “electronic” health (Eysenbach 2001), eHealth is an enabling factor for the concept of seamless healthcare: a concept that aims to move information, not patients (Dierks 2005). 2.3.1

Definitions and Objectives of Healthcare Telematics

The idea of ”telematics” is based on the two disciplines: ”Tele-communications” and ”Informatics” (Computer Science) (Lehmann 2005). Telematics designates the transportation of any type of digital data by electronic media and is becoming a concept that influences every area of our modern communications-society (Ntasis et al. 2005). The use of networked information technology across the boundaries of institutions and sectors provides an opportunity for increased efficiency and better delivery of healthcare (Haux/Ammenwerth/Buchauer 2001). It creates numerous benefits such as improved communications between healthcare providers and patients (Michel-Verkerke/Schuring/Spil 2004; Dünnebeil et al. 2009b), smoother transfer of information across electronic boundaries (Sunyaev et al. 2008b), lower costs (Krcmar 2005), increased access transparency, and improved treatment quality and safety (Kuhn et al. 2006). Healthcare telematics has the potential to make concepts of place- and time-independent allocation of data, information, experience, and knowledge for the better integration of all parties involved in healthcare a reality (Safran et al. 1998; Parker/Coiera 2000; Frist 2005; Sunyaev

40


2005). In addition, telematics provides a number of economic advantages (WHO 2008; Stausberg/Uslu 2005; Warda/Noelle 2002; Bundesministerium für Wirtschaft und Arbeit (Hrsg.) 2003; Mentzinis 2005), such as (Beyer et al. 2004; O'Brien 2006; Beranek Lafky/Tulu/Horan 2006; Schabetsberger et al. 2006; Dünnebeil et al. 2009a): 1. Efficient utilization of resources in hospitals and physicians’ practices. 2. Reduced transportation costs as only patient data and not the patients themselves have to be moved. 3. Compensation for the lack of physicians through outsourcing. The Healthcare Information and Management Systems Society (HIMMS) defines healthcare telematics as “the application of the internet and other related technologies in the healthcare industry to improve the access, efficiency, effectiveness, and quality of clinical and business processes utilized by healthcare organizations, practitioners, patients, and customers to improve the health status of patients.” (Health Data Management Journal 2008). The World Health Organization (WHO) defines healthcare telematics as eHealth: „eHealth is a new term used to describe the combined use of electronic communication and information technology in the health sector OR is the use, in the health sector, of digital data transmitted, stored and retrieved electronically-for clinical, educational and administrative purposes, both at the local site and at a distance.” (World Health Organization 2005). Another definition is proposed by (Eysenbach 2001): „eHealth is an emerging field in the intersection of medical informatics, public health and business, referring to health services and information delivered or enhanced through the Internet and related technologies. In a broader sense, the term characterizes not only a technical development, but also a state-ofmind, a way of thinking, an attitude, and a commitment for networked, global thinking, to improve healthcare locally, regionally, and worldwide by using information and communication technology.” Table 4 summarizes the accumulated possibilities as objectives of healthcare telematics driven by eHealth.

2.3 Healthcare Telematics “e”`s

41 Explanation

Efficiency

One of the promises of eHealth is to increase efficiency in healthcare, thereby decreasing costs. One possible way of decreasing costs would be by avoiding duplicate or unnecessary diagnostic or therapeutic interventions, through enhanced communications between healthcare establishments, and also through patient involvement.

Enhancing quality of care

Increasing efficiency involves not only reducing costs, but at the same time improving quality. EHealth may enhance the quality of healthcare for example by allowing comparisons between different providers, involving consumers for quality assurance, and directing patient streams to the best service providers.

Evidence based

eHealth interventions should be evidence-based in the sense that their effectiveness and efficiency should not be assumed but proven by rigorous scientific evaluation. Much work still has to be done in this area.

Empowerment of consumers and patients

By making the knowledge bases of medicine and personal electronic records accessible to consumers over the Internet, eHealth opens new avenues for patient-centered medicine, and enables evidence-based patient choice.

Encouragement

Encouragement of a new relationship between the patient and health professional, towards a true partnership, where decisions are made in a shared manner.

Education

Education of physicians through online sources (continuing medical education) and consumers (health education, tailored preventive information for consumers)

Enabling

Enabling information exchange and communication in a standardized way between healthcare establishments.

Extending

Extending the scope of healthcare beyond its conventional boundaries. This is meant in both a geographical sense as well as in a conceptual sense. eHealth enables consumers to easily obtain health services online from global providers. These services can range from simple advice to more complex interventions or products such as pharmaceuticals.

Ethics

eHealth involves new forms of patient-physician interaction and poses new challenges and threats to ethical issues such as online professional practice, informed consent, privacy and equity issues.

Equity

To make healthcare more equitable is one of the promises of eHealth, but at the same time there is a considerable threat that eHealth may deepen the gap between the "haves" and "have-nots". People, who do not have the money, skills, and access to computers and networks, cannot use computers effectively. As a result, these patient populations (which would actually benefit the most from health information) are those who are the least likely to benefit from advances in information technology, unless political measures ensure equitable access for all. The digital divide currently runs between rural vs. urban populations, rich vs. poor, young vs. old, male vs. female people, and between neglected/rare vs. common diseases.

Table 4: The 10 Essential e's in „eHealth“ (Source: according to (Eysenbach 2001))

The definitions and objectives discussed show that healthcare telematics is already very present in both scientific and commercial sectors. Using google6 to search for the term “healthcare telematics” yields around 340.000 results. The German equivalent “Gesundheitstelematik” alone brings more than 126.000 results, while the term “ehealth” yields almost 3.420.000 results. 6

http://www.google.com - google is one of the most used search engines on the web [http://siteanalytics.compete.com/google.com/?metric=uv].

42


2.3.2

German Healthcare Telematics

Within the next few years, German health authorities will develop a nationwide telematics infrastructure to utilize the advantages of ehealth. This infrastructure will centralize the storage of healthcare data and harmonize interactions between the various actors in German healthcare. Current advances in the communications infrastructure will aid the introduction of the healthcare telematics in Germany. 2.3.2.1 Healthcare Telematics Infrastructure Health Telematics Infrastructure

Primary Systems

Connectors (Decentralized)

Network Gateway

Primary Systems Physician & Dentist (PVS)

Application Gateway

Access Network

Connector

VPN Gateway EHC

VSDD

Broker Service (Application Gateway)

HBA/SMC

Primary Systems Hospital (KIS)

Access Network

Connector

CAMS Broker Service (Application Gateway)

VPN Gateway EHC

Professional Services (obligatory & voluntary)

HBA/SMC

Primary System Pharmacist (AVS)

Frontend Network

Backend Network VODD

Access Network Connector VPN Gateway EHC

Broker Service (Application Gateway)

HBA/SMC Medicine Documentation

eKiosk

Access Network Connector VPN Gateway EHC

Broker Service (Application Gateway) eHR

HBA/SMC

Insurant@Home

Decentralized Added Value Services

Access Gateway

Added Value Network

EHC

Figure 10: Health Telematics Infrastructure for the German Electronic Health Card (Source: according to (gematik 2006g))

A telematics infrastructure will form the basis of the mandatory electronic health card system. Figure 10 depicts an abstract overview of the architecture to be used for Germany’s planned national healthcare system.

2.3 Healthcare Telematics

43

The creation of the infrastructure is under the control of gematik7, a German IS institution (when comparisons are performed this thesis refers to the German healthcare telematics infrastructure as gematik). In general, the gematik infrastructure connects existing information systems of various service providers and health insurances via a common network. The requirements for the development of this infrastructure are derived from legal constraints (healthcare regulations), current standards, and the demands of the participating stakeholders. An essential step towards the implementation of this system in Germany will be the introduction of an electronic healthcare smart card (eHC) for patients and a counterpart health professional card (HPC) for care providers. The introduction of these cards is based on a law for the modernization of compulsory public health insurance in Germany. These cards will form an essential part of the comprehensive and nation-wide telematics infrastructure currently being developed. The eHCs will eventually be mandatory for every insured resident of Germany. The primary systems (e.g., a hospital information system) of service providers (i.e., general practitioners or hospitals) are connected to the communications infrastructure (CI) by a special component, a so-called connector. This connector communicates with the primary systems and the card terminals for the eHC, the HPC and the secure module card (SMC). SMCs are used to create secure connections either between components (e.g., between a VPN Box and the CI) or between smart cards. The communication between the connector and the card terminals is transparent to the user and is encrypted automatically. The connector is connected to a so-called VPN box (virtual private network unit). Connection to the communications infrastructure is established via an access gateway. Access gateways allow only registered users to access the communications infrastructure. A certificate within the access node enables the mapping to an appropriate VPN. A special user role is associated with the mapping to a dedicated VPN. The service gateway contains a list specifying the mapping between possible roles and rights for using the application services. These rights specify which services of the user’s VPN can be used. Access gateways and service gateways communicate via a trusted backbone, with components mutually authenticating themselves and connecting via a VPN. These measures allow only those users possessing the appropriate clearance the power to execute application services that invoke these services via access gateways. Dedicated VPNs are capable of accessing infrastructure services.

7

gematik (Gesellschaft für Telematikanwendungen der Gesundheitskarte) mbH – a limited liability company – was fonunded due to an order from the German Ministry of Health (BMG) and is managed by major stakeholders in German healthcare.

44


Application services, such as access to an electronic patient record (ePR), a prescription data service (PDS), or a health insurance data service (HID), can be reached via service gateways. Application services access relevant data via a common access and integration layer (AIL). This layer implements a common rights management for the access to data that allows the mapping of appropriate rights to users. The AIL layer also hides the actual distribution of data and implements storage transparency. This encapsulation facilitates the eventual integration of external systems since the interfaces of the application services will not need to be adapted. For this instance a so-called gematik gateway allows access to root and directory services that are necessary for the administration of the network. The user is not faced with the complexity of the telematics infrastructure. He or she uses the new functions via a user interface that is part of the hospital information system (this means that every manufacturer has to adopt existing software to the new telematics infrastructure). Depending on the selected solution for managing this infrastructure, the user has to insert a smart card and type in a PIN in some situations. 2.3.2.2 Electronic Health Card The functions and regulations of the eHC are defined in § 291a and § 291b of the 5th book of Code of Social Law (Ministry of justice 2007a, 2007b). The eHC possesses two different types of functions. On the one hand the mandatory functions, such as administrative data and electronic prescriptions. These functions allow the physicians to check the administrative data of the patient and to write prescriptions on eHC. On the other hand there are the voluntary medical functions such as the emergency data record and, eventually, an electronic patient record (Federal Ministry of Health 2008). The emergency data includes medical information (e.g., blood group and allergies). Fluoroscopic images, laboratory findings, operation reports and other examinations-related data can be stored in the electronic patient record (Chadwick et al. 2000; Sunyaev et al. 2010). The electronic health card, as a central component of the telematics infrastructure, can provide access to multiple forms of information and can store data locally. This data can be classified as being either mandatory or faculty. Mandatory data consists of basic administrative patient data, such as name, date of birth, or health insurance information. In addition, the implementation of an electronic drug prescription is an obligatory element of the electronic health card. Another feature provides German patients proof of the right to medical services in other European Union countries. In addition to the storage of data on the electronic health card, other applications of the card are possible. These applications are facultative and require patient permission. These applica-


45

tions include: drug order documentation, electronic physician letters, treatment cost receipts, emergency case data, general patient data, and an electronic health record. Facultative applications allow improvements in the treatment process and the integration of the patient as an active participant in his treatment. Additionally, these applications promote an increase in efficiency and effectiveness (gematik 2006q). Because they require patient permission, service providers will needs to make patients aware of and encourage them to use of these applications. The electronic health card has the same proportions as a normal plastic card, e.g., a credit card. The front side of the card contains individual-related information such as a picture of the cardholder and the microchip. Also certain recognition features such as information in braille as well as the name and logo of the insurance company are placed on the front of the card. The back of the card will act as a European health insurance card (EHIC) (Drees 2007). The eHC is a smart card, which means it includes a microprocessor with its own instruction set (Caumanns et al. 2006). This distinguishes it from the health insurance cards currently used in Germany, which are only memory cards. Besides administrative data about the insurant the card will also store medical data such as electronic prescriptions. The insurant can decide whether information for medical emergencies, pharmaceutical documentations, insurants receipts and medical reports will be stored on the eHC or central databases (Neuhaus/ Deiters/Wiedeler 2006). Furthermore, each healthcare provider will receive a Health Professional Card (HPC) and the essential computer equipment (e.g., the connector that interconnects primary systems, card terminals, and communication infrastructure). Both cards have a clearly defined structure and set of functions. Sensitive medical information will be protected by a PIN and is only available with the HPC of a doctor. Thus, it will not be possible to add additional functions or to create additional certificates. This makes it very difficult to use the cards for additional purposes. The telematics infrastructure described creates the basic communications structure that is needed for a cross-institutional information flow. Only administrative information and data for obligatory applications are to be stored on the electronic health card, the storage location of other distributed applications is left open and could be stored either centrally or non-centrally. In order to prevent the storage of redundant data, the electronic health card could be a tool for establishing a virtual patient record. For this purpose, relevant data could be aggregated at runtime and retrieved out of the locally distributed information systems.

46


2.3.3

Risk and Security Issues of Healthcare Telematics


What are common risks and security issues of healthcare information systems, including German healthcare telematics?

According to (Gritzalis et al. 2005) modern electronic medical environments, such as German healthcare telematics, require additional technical, procedural, and organizational measures in order to ensure secure electronic transactions. This is especially true because the vast majority of such electronic correspondences are being conducted through the internet. This section describes the challenges and possible security issues, which could appear during the introduction of the healthcare information systems, such as German healthcare telematics. The issues discussed have to be analyzed according to their solutions in order to guarantee a dependable healthcare IS infrastructure (Sunyaev et al. 2007). Chapter 3 explores healthcare IS security characteristics, concerning the issues described below, and connects them to currently available IS security approaches. (Gritzalis et al. 2005) and (Anderson 1996b) summarized the core risk scenarios that confront healthcare information systems: x

In a diverse environment such as German healthcare telematics (section 2.3.2), ensuring that only authorized persons can access the personal data of patients becomes increasingly difficult and complex. According authorization and authentication solutions always carry risks.

x

Due to the distribution of healthcare professionals (section 2.1.2.1), wide area networks, including the internet, are required for transferring extracts of patient records, a fact that threatens security. Electronic health record applications may be standalone, in which case they are responsible for communicating record contents, or web-based, which by default allows remote accessing of central record databases. In both cases, adequate security measures for protecting patient information must be implemented.

x

Important information on patients’ medical conditions (medical record summaries) will be stored on smart cards (electronic health cards), which patients can carry and present in case they need medical assistance. Although healthcare professionals should normally only read eHC contents after being authorized by their owners, in case of emergencies it may not be possible to obtain authorization. Patients then lose control of who accesses their personal information.

2.3 Healthcare Telematics x

47

In German healthcare telematics medical records are stored in central repositories, at an institutional level, and can be easily accessed over the internet by remote healthcare professionals that patients visit only occasionally. Even though such repositories are very useful, they pose a risk to the confidentiality and integrity of medical information (section 3.2), since they offer their services to multi-user, inter-networked environments, which can be easily attacked.

x

Maintaining electronic healthcare record repositories is also a prerequisite for optimizing medical services. Improving the management of blood supplies at a national level is an example. Medical research is an additional driving force for the development of centralized patient record databases. In such scenarios, the protection of sensitive personal information is a challenging task.

x

In Germany, medical records belong to the healthcare units creating them, rather than to the patients they pertain to. So, the healthcare professionals that are responsible for maintaining sections of the records often refuse to share information with their colleagues in an attempt to protect their own research. In such cases, medical information systems should also protect the intellectual property of healthcare professionals.

x

During the electronic medical transactions, the patients always face the man-in-themiddle risk. That means that somebody may act as an eavesdropper and monitor/record all the traffic exchanged through the communication channel. In such cases, the identity of the patient can be revealed and/or the confidentiality of the data may be compromised.

x

The information transmitted over a communications channel can be deliberately or accidentally modified, thus sacrificing data integrity (section 3.2.1).

x

Internet service providers can easily generate “user profiles” by gathering information on how often her/his medical data are accessed and the type of electronic medical transactions she/he normally performs.

x

Whenever a patient is requested to provide specific personal and/or medical information, she/he runs into the danger of revealing much more information that is really necessary for the specific task she/he is trying to complete.

x

Software bugs and hardware failures occasionally corrupt messages. While mail, fax and telephone systems also fail, their failure modes are more evident than those of a

48

2 Healthcare Telematics in Germany with Respect to Security Issues computer messaging system. It is possible, for example, that a software bug could alter the numbers in a laboratory report without changing it so grossly that it would be rejected. x

Higher error rates could result from sending lab results as unstructured messages sent through the German healthcare telematics are interpreted automatically. This could lead to an incorrect treatment.

x

Viruses have already destroyed clinical information and virus could conceivably be written to make malicious alterations to medical health records.

These risks could arise by using of healthcare IS (e.g., German healthcare telematics). Because these risks concern direct patient care, they also need specific attention. To give a complete overview of possible risks for patients by using the healthcare IS services one should enhance the presented overview of risks by (gematik 2008h). (gematik 2008h) including a variety of threats based on the common criteria catalogue (BSI 2008). In doing so, the categorization of threats and possible risks is aimed specifically at German healthcare telematics and it is furthermore distinguished by potential cause – users of the healthcare telematics, administrative personnel, external attackers, and threats arising from hard- or software failures (Mouratidis/Sunyaev/Jürjens 2009). The following list summarizes threats that can occur because of users, who are authorized to use healthcare telematics services (according to (gematik 2008h)): x

Most of the authentication mechanisms in the German healthcare telematics are knowledge-based. This can lead to security issues due to possible human errors.

x

Due to incomplete data, users could make incorrect decisions and this could lead to negative financial, physical and personal consequences for them.

x

Users could get unauthorized access to external telematic services and because of this transmit or import malware.

x

Users could be convinced to enable an authorized access to his/her data.

x

Inadequate usability of healthcare telematics services could lead to a higher error rate and this could result in privacy or security problems.

2.3 Healthcare Telematics x

49

Healthcare providers could unintentionally digitally sign a document that was by somebody.

The next section identifies threats that can occur because of administrators in the healthcare telematics system (according to (gematik 2008h)). These threats could occur because of the incorrect installation, operation and administration of healthcare telematics services. x

Deficit of developer’s know-how.

x

Access to patient’s data without auditing.

x

Audit files could be intentionally or unintentionally modified or deleted.

x

Breach of data protection could result because of the improper storage, improper use, improper disposal or the unauthorized copying of data.

x

Incorrect implementation of healthcare telematics services could lead to internal and external attacks against the system.

x

In case of security accidents administrator(s) could react improperly and this could lead to further attacks or threats.

x

Security relevant processes could be insufficiently specified and implemented. This could lead to further threats or attacks.

x

An insufficient specification of responsibilities within the healthcare telematics system could lead to unauthorized activities or attacks.

The following points summarize threats that can occur because of external attackers (according to (gematik 2008h)). Attackers act deliberately by attempting to gain unauthorized access to the data stored within the German healthcare telematics infrastructure. x

Improper handling of personal PIN`s and passwords by users could allow external attackers to gain access using the users’ data.

x

Confidential information could be read, modified or deleted by an external attacker.

x

An external attacker could provide healthcare telematics services without the proper authority.

50

2 Healthcare Telematics in Germany with Respect to Security Issues x

An external attacker could exploit software bugs in order to place malware inside the software system.

x

Electronic health card could be stolen or lost. An attacker could impersonate a patient who last their card and get unauthorized access to their data.

The following list summarizes threats that could occur because of the hard- and software used within German healthcare telematics (according to (gematik 2008h)). Hard- and software could breakdown or malfunction and this could lead to internal and external attacks. x

Most of the software products contain unauthorized auxiliary functions.

x

Hardware breakdown because of natural events or accidents (e.g., fire, water, lightning, loss of power supply etc.).

x

Improper emergency plans.

x

Technical breakdowns or malfunctions could lead to the modification of digitally signed documents.

x

Stored data could get lost because of a malfunction in the storage medium, improper backups, or extraneous physical cause.

x

PKI services of the healthcare telematics system could become inaccessible. This would disable security verifications and could result in possible attacks.

x

Unexpected scientific or technological breakthroughs in cryptography could lead to the security mechanisms (as well as the smart cards) of German healthcare telematics becoming outdated earlier than expected.

There must be appropriate countermeasures to deal with these threats. (Serour 2006) provided a list of recommendations that should be considered in order to guarantee the confidentiality, privacy, and security of healthcare information that German healthcare telematics deals with: 1. Patients have the right to ultimate control over the confidentiality of their data. 2. Physicians and health facilities should ensure that the patient data stored is accurate, complete and not excessive to the purpose of storage.


51

3. Competent patients have the rights to access their medical records, to have the data interpreted for them, and to object to the inclusion of specific information. 4. Every physician is obligated to respect and guard the individual patient’s rights to privacy and confidentiality of their health information in all settings, including informal settings (e.g. Hallway conversations, elevators, social settings, publications and lectures). 5. The security of electronic medical information, particularly when transmitting between institutions or to patients with electronic mail systems, requires strict adherence to security protocols, and the principles of data protection. The physician should also be an advocate for continuing improvement of electronic records systems security. 6. Not every member of a healthcare team is entitled to all patient information; but once received every member has the same obligation to keep such information confidential. 7. When a patient’s health condition has serious and potentially harmful implications for the health of others, the physician has an obligation to consult the individual and obtain permission to make the information appropriately available. In the case of direct, immediate and life threatening harm to a specific individual the physician has an obligation to report the risk appropriately. 8. Patients normally have the right to be provided with information on the health of dependent minors and to engage in decision-making. However, the development of the child’s capacity for decision-making in healthcare is a continuous process and in some circumstances, where the minor is capable of understanding the medical issues, the physician may be justified in withholding information from their parents or guardians. This is also true when revealing information that may directly lead to serious harm to the child. 9. No information on a patient should be divulged to an insurance company or to its medical representatives, or other agencies, without the express and informed consent of the individual. Extra effort to assure confidentiality of health records is warranted if breaching that confidentiality may impact on an individual’s safety or access to healthcare. This may require the maintenance of separate records or coding for sensitive areas, assurance of private and individual conversations with health providers, and clear mechanisms for notification of test results that are ag-

52

2 Healthcare Telematics in Germany with Respect to Security Issues reed upon with the individual. Separate records or coding may compromise the overall healthcare of the individual and this possibility must be discussed with the patient. 10. Healthcare information should be available for medical research and healthcare system improvement, provided it is securely anonymized. 11. Many circumstances surrounding an otherwise confidential medical encounter can endanger confidentiality. The names of a clinic, the letter head on a patient letter, the color of contraceptive pills, the choices that an individual makes after consultation, and other actions all can identify medical information that should be confidential. Attention to these secondary cues that surround the medical encounter is a critical part of assuring patients’ confidentiality in healthcare. 12. Even if a physician does not have a patient / physician relationship, any medical information they receive must still be held in strict confidence.

2.4

Summary

This chapter first introduced the current situation of German healthcare in detail. Second, the forthcoming German healthcare telematics infrastructure together with underlying medical IS architectures and medical IS standards were explained in detail. In the third section, the chapter provided an overview of the possible risks for patients using German healthcare telematics and summarized recommendations that be taken into account to minimize these risks. These issues influence statements on security characteristics of healthcare IS and the way healthcare IS are used. Of course, healthcare IS does not differ fundamentally from IS in other sector, but there are some features unique to healthcare IS and these features matter. Medical data security is one of the most important and widely discussed aspects of the planned German healthcare telematics system in both academia and industry (Müller 2005; Wahl 2004; Sunyaev/Leimeister/Krcmar 2009b; IBM/Dr. Bunz/Dr. Neeb 2004). The following chapter gives an overview of both technical and organizational data protection requirements for healthcare telematics and describes appropriate protection goals in detail. Furthermore, the healthcare information systems security characteristics are described. These characteristics will later be used to analyze current IS security approaches and to develop a HatSec method.

3


The objective of this chapter is to examine the special characteristics of information systems security approaches with respect to healthcare. These are needed for the analysis of, during the literature review identified (section 4.5), which concerns common security analysis approaches regarding their applicability in the healthcare domain. Furthermore, these characteristics must be fulfilled by any proposed security analysis method developed for German healthcare telematics. In the following chapter, the legal framework for medical data in Germany is described (section 0). The HatSec security analysis method has to comply with local privacy laws and other legal requirements in Germany. In this situation, there is a conflict between German legal requirements (section 3.1.2) and corresponding technical security goals (section 3.2) for information systems in healthcare. The resulting requirements have to be met by any security concept for German healthcare telematics and thus be evaluated according to their fulfillment of corresponding technical and organizational protection goals.



3.1 Legal Framework Introduction

Privacy

Legal Requirements

3.2 Protection Goals of Healthcare Information Systems Consideration

Dependable Healthcare Information Systems

Controllability of Healthcare Information Systems

3.3 Characteristics of IS Security Approaches with Respect to Healthcare

Implication

Security Requirements for the appropriate Use of Information and Communication Technology (ICT) in public Health Systems on both technical and organizational Level


Due to the special requirements that need to be met to ensure the security of personal health information within a healthcare telematics infrastructure and due to the healthcare processes that directly affect the care and service delivered to the patients (Cavalli et al. 2004), there is a strong need for clear, concise and healthcare specific IS security approach characteristics


54

3 Catalogue of IS Healthcare Security Characteristics

(Vaast 2007). As a result, this chapter presents a full set of characteristics of IS security analysis approaches for the healthcare sector (section 3.3). The HatSec method will be designed on the basis of the derived healthcare IS security characteristics. Figure 11 illustrates the contents of this chapter. 3.1

Legal Framework

The introduction of healthcare telematics and the electronic health cards as well as health professional cards will lead to considerable changes to the everyday work routine of healthcare providers in Germany. Because these changes are so pervasive, specified security requirements must be met in order to guarantee privacy of medical data of every patient (Ash/Berg/Coeira 2004; Denley/Smith 1999; Gritzalis/Lambrinoudakis 2004; Rindfleisch 1997). The required changes not only concern medical processes, they also concern areas such as overall healthcare policy, awareness, training, education and technology. All these fields have to be dealt with carefully and according to German legal requirements. The legal situation of healthcare in Germany and additional security requirements for healthcare IS are also described in this section. 3.1.1

Privacy

Privacy is especially important issue in healthcare. Because of its sensitive nature, medical data is protected by the German Federal Data Protection Law (Bundesdatenschutzgesetz (BDSG), § 28 section 6-9). In Germany, medical data is categorized into the highest level of data protection – the patient alone has the authority to decide whether or not to share details of their medical data or not (Müller 2005). Legal requirements concerning confidential medical communications have a very long history. Information and communication technology in healthcare have to consider these privacy issues and handle medical data extremely carefully (Berg 2004). Healthcare telematics must be employed in a way so that every patient remains the master of their own data. Healthcare telematics has to be developed in accordance to specific security requirements that are specified in § 9 of the Federal Data Protection Law. This paragraph defines rules and security measures and is based on guidelines proposed by the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik (BSI)).

3.1 Legal Framework 3.1.2

55

Legal Requirements

German legislation provides constraints which have to be complied within security strategies of healthcare information systems (Mauro et al. 2009a). (Bake/Blobel/Münch 2004) presented an overview of legal requirements in healthcare: x

Telecommunications Data Protection Ordinance (Datenschutzgesetz der EU (EG) 45/2001 - Regulation (EC) No 45/2001 of the European parliament and of the council on the protection of individuals with regard to the processing of personal data by the community institutions and bodies and on the free movement of such data (2001)).

x

General Personal Right (Allgemeines Persönlichkeitsrecht Art. 1 Abs. 1 GG, Art. 2 Abs.1 GG).

x

Federal Data Protection Law (Bundesdatenschutzgesetz (BDSG)).

x

Act for the Protection of Personal Data (Landesdatenschutzgesetz (LDSG)).

x

Tele Services Data Protection Act (Teledienstdatenschutzgesetz (TDDSG)).

x

Telecommunications Act (Telekommunikationsgesetz (TKG)).

x

Professional Discretion (Schweigepflicht (StGB)).

x

Medical Devices Act (Medizinproduktegesetz (MPG)).

x

Medical Devices Operator Ordinance (Medizinprodukte-Betreiberverordnung (MPBetreibV)).

x

Medical Devices (MPSV)).

x

Electronic Signature Act (Signaturgesetz (SigG)).

x

German Broadcasting Supervisory Regulation (Fernmeldeüberwachungsverordnung (FÜV)).

x

Telecommunications Monitoring Decree (Telekommunikationsüberwachungsverordnung (TKÜV)).

Safety

Ordinance

(Medizinprodukte-Sicherheitsverordnung

56


Privacy and security in healthcare is strictly regulated by a state, so a security analysis method developed in this thesis has to deal with these detailed legal requirements. All specific healthcare-related laws and liability issues arising from these regulations will be integrated in the security analysis process in order to guarantee compliance with these regulations. The next section provides an overview of the data protection requirements for dependable healthcare information systems. These are enhanced by technical and organizational protection goals in order to achieve controllability in such systems. The interaction of protection goals in healthcare is summarized and illustrated as well. 3.2

Protection Goals


What are specific security requirements for healthcare telematics?

In order to make the security measures dependable and controllable certain criteria must be met.

Accuracy

Utility +

Confidentiality +

Use Regulation

+

Possession

Anonymity Enforceability

-

+ Integrity

Legal Certainty

Availability + X → Y … X amplifies Y - Y … X weakens Y X→ X ֲ Y … X implies Y

Authenticity

Revisability

Suitability for Daily Use

Liability

Figure 12: Protection Goals Interaction in Healthcare (Source: according to (Wolf/Pfitzmann 2000))

3.2 Protection Goals

57

Protection is a mechanism to control access to resources (Gollmann 1999). Protection goals provide controlled access to data by limiting the type of access that various users can have. The goal of such protection elements is also to protect the data itself, while maintaining its availability and guaranteeing its integrity. The derived interaction between protection goals in healthcare is illustrated in Figure 12. (Wolf/Pfitzmann 2000) discuss a part of such interactions in detail and identify a differentiation by implication types: an amplifying implication, a weakening implication and compensating implication effect of protection goals. Flagged protection goals (accuracy, utility, possession, use regulation, enforceability, legal certainty, revisability and suitability for daily use) are selective characteristics of the healthcare domain. These additional protection goals are an expansion of the core protection goals defined by (Wolf/Pfitzmann 2000). The following sections introduce the protection goals in detail. 3.2.1

Dependable Healthcare Information Systems

Continuing from the discussion of German healthcare’s legal framework, information systems in healthcare have to comply with security goals such as the so called C.I.A. triangle (Janczewski/Xinli Shi 2002; Höne/Eloff 2002). The C.I.A. triangle is a list of three critical core characteristics of information security: confidentiality, integrity, and availability. This section introduces them in detail. Furthermore, the descriptions of these three essential protection goals of every IS are described with regard to healthcare in order to exemplify healthcare IS related setting. x

Confidentiality Confidentiality is defined as a characteristic that aims to prevent unauthorized access to information. Patients in medical treatment have the right to have their medical data remain confidential. Physicians have to act according to guidelines of professional discretion and facilitate mutual trust between healthcare providers and healthcare service customers. Nevertheless almost all healthcare facilities (e.g., hospitals) are open to the public use. This means that there are virtually no security measures concerning physical access to the healthcare facilities. This characteristic is specific to the healthcare sector and creates a need for special security requirements for healthcare information systems (Gritzalis et al. 2005).

58

3 Catalogue of IS Healthcare Security Characteristics x

Integrity Integrity is defined as a characteristic that is aims to prevent the unauthorized modification of data. The authenticity, accuracy, and completeness of medical data prior to, during, and after medical treatment are integral elements of healthcare security requirements. To this end it is necessary to guarantee both precautionary measures to prevent manipulation of medical data as well as revision mechanisms (audits) for ex-post control and verification of possible manipulations.

x

Availability Availability is defined as a characteristic that aims to prevent the unauthorized withholding of data. This means that personal medical data has to be available within a reasonable amount of time. Healthcare is extremely time-sensitive and successful medical treatments, especially emergency cases, depend on the right information being available on time. Unavailable medical data or delayed data delivery can lead to delays or mistakes in treatment or the denial of treatment. This can have lifethreatening consequences for patients and legal consequences for physicians. Medical information has to be available in emergency situations despite security barriers (Toyoda 1998). Another characteristic specific to information systems in healthcare are horizontal information flows. Healthcare providers need complete medical information on their patients in order to provide the best medical treatments. The fact that healthcare providers act autonomously strengthens the characteristic availability. Furthermore medical information has a very long life cycle (even posthumously), this characteristic demands large-scale oriented availability feature (Pharow/Blobel 2005). However it is not always clear whether somebody is authorized to access medical information (Carr-Hill et al. 2002). As previously discussed medical data concern only patients and their attending physicians but normally due to or-


59

ganizational processes mutual trust in healthcare is often extended to other medical staff such as nurses or medical secretaries (Carayon 2006). 3.2.2

Controllability of Healthcare Information Systems

The described three core protection goals for every IS are enhanced by further protection goals. The protection goals described below are given a higher priority than others in the healthcare IS field (Müller 2005). Additional security elements of information systems in healthcare are authenticity, commitment, use regulation, accuracy, utility, possession, legal liability, legal certainty, enforceability, suitability for daily use, and anonymity (Müller 2005; Anderson 1996b; Furnell et al. 1998; ISO/FDIS 27799:2007(E) 2007). This section describes them in detail and presents their healthcare IS relations through examples. x

Authenticity The authenticity of collected and stored medical data must be guaranteed at all times. The author of the patient related information (responsible person) is to be clearly identified. Medical documents that don’t show their author or the responsible person are invalid (Zhang/Ahn/Chu 2002). For this reason, patient related documents must be signed electronically by the responsible healthcare providers and include a time stamp.

x

Liability The liability of sending and receiving patient related documents is to be secured. That means that the sender can clarify that the patient related medical documents are going to reach the receiver with almost absolute certainty. And, thanks to this function, the receiver cannot deny that a particular medical document was sent to a particular receiver. On the other hand, the receiver can be certain to have received the particular document from the particular sender they expected it from arrive from (Müller 2005).

x

Use Regulation Systems which process sensitive medical data must allow any patient to regulate use of their own medical documents, including determining which specific group of users are allowed access as well as stepped rights of use and definition user access (access control) (Anderson 1996a).

60


Accuracy Stored medical data within healthcare telematics are to be free from mistakes or errors. Incorrect medical information can lead to false medical treatments and are to be avoided. Accuracy ensures this and guarantees the results that are expected by an end user.

x

Utility Medical information stored on patients must have value for a specific purpose. Stored medical data must be of value and serve a specific and well defined medical purpose. Healthcare information systems must guarantee the utility of stored documents.

x

Possession Possession of their medical information is a quality and state of ownership that gives patients the control over their information as required by German law (Müller 2005).

x

Revisability The revisability of any medical data is to be guaranteed. This means that any medical patient data can relate to an uninterrupted manufacturing process in order to determine how, when, and which patient related medical documents were treated and processed. For healthcare providers (or institutions, e.g., hospitals) there is, according to the medical association's professional code of conduct, an obligation to submit and forward any documents about medical treatments. This is a dependent obligation due to the contract governing medical treatments in Germany. It has to be clear who made which diagnosis and ordered what treatment. Furthermore it has to be clear which facts motivated an attending physician to choose a particular treatment (Müller 2005).

x

Legal Certainty For each medical process and its outcome a responsible person has to be identified and verified. Without this legal security patients would have difficulty asserting their rights and claiming for specific damage. Also without legal cer-


61

tainty physician would have difficulty proving that they have acted properly (Müller 2005). x

Enforceability The enforceability of rights for all stakeholders in healthcare requires an agreement on a reliability storage place for data processing (Müller 2005).

x

Suitability for Daily Use Suitability for daily use is an important criterion for evaluating effectiveness in healthcare telematics. All participating system designs in healthcare have to consider certain groups of people who are not familiar with recent information and communication technologies. The increasing complexity of healthcare systems complexity means ever-increasing requirements for the users of healthcare systems. The trade-off between securing healthcare telematics and maintaining its suitability for daily usage should be discussed (Müller 2005).

x

Anonymity Anonymity connotes an exchange of patient-related medical data in a way that makes it impossible to draw conclusions about the personal information of a patient. Patient-related information is required for a complete examination of the patient, for medical documentation, and payments situations. On the other hand anonymity in healthcare allows science-based research with medical data and is indispensable for medical statistics (Toyoda 1998).

Most of the protection goals discussed are relevant not only in healthcare but also in other sectors. The main distinguishing feature of protection goals in healthcare information systems are several specific priorities (Alban et al. 2005). The following descriptions of protection goals were centered on healthcare specific issues. Table 5 presents the discussed protection goals together with additional healthcare specific data protection requirements. The next section provides an overview of healthcare information systems security characteristics. These characteristics are derived from scientific literature.

62

3 Catalogue of IS Healthcare Security Characteristics Data Protection Requirement

Description

Discretion

A Physician has a duty to treat medical records confidentially.

Completeness

The stored medical data must be deposited completely.

Patient Orientation

Every patient has to have a possibility to view and control own medical data.

Free choice of medical practitioner

Every patient has a right to medical self-determination.

Data Sovereignty

The patient has the sole jurisdiction of own medical data.

Social Preservation (Sozialgeheimnis §35 SGB I)

Each patient has a right to the preservation of own social privilege.

Reporting Requirement

Patients have a right to understand own medical treatment and to be adequately informed and advised.

Seizure Ban

A right to refuse to give evidence on medical findings.

Drug Safety, Drug Therapy Safety

Truthful information about adverse drug outcomes and adverse drug reactions from doctors and pharmacists are compulsory.

Duty of Disclosure

The doctor / pharmacist has a duty to inform/enlighten the patient about the diagnosis, the course and treatment of certain disease.

Pharmaceutical Law

Providers and pharmacists must follow the law to manufacture, clinical testing and dispensing of medicines.

Technical Infrastructure

Providers must be able to communicate without any problems among each other.

Record Retention

A physician has a duty to collect medical data in medical records and keep them confidentially.

Right to Inspection

Patients have the right to inspect the concerned medical documents.

Table 5: Healthcare-Specific Data Protection Requirements (Source: own Table)

3.3

Characteristics of IS Security Approaches with Respect to Healthcare


What are the characteristics of IS security approaches with respect to healthcare?

Section 3.1 and section 3.2 described the essential legal requirements and protection goals that must be considered when processing digital data in healthcare information systems. In order to analyze currently accepted and applied IS security approaches according to their applicability in healthcare, special healthcare security characteristics have to be identified. Accordingly, this section identifies healthcare IS security approach characteristics for IS security approaches. These characteristics are (1) healthcare domain specific and (2) involve both technical and process-oriented views on IS security.


63

These unique security-related characteristics of healthcare information systems place specific requirements on a security analysis method developed in this thesis. In order to assess the relevance of security analysis for healthcare, first, three different groups of classification areas are introduced (see Figure 13): 1. General IS Security Approach Characteristics. 2. General IS Security Approach Characteristics with Reference to Healthcare. 3. Healthcare Specific IS Security Approach Characteristics.

Healthcare Relevance

These three categories are then further subdivided into groups of characteristics which should be examined in order to estimate the relevance of any IS security analysis approach according to its appropriateness for the healthcare sector.

Healthcare Specific IS Security Approach Characteristics

General IS Security Approach Characteristics with Reference to Healthcare

General IS Security Approach Characteristics

Figure 13: Kinds of Healthcare IS Security Approach Characteristics (Source: own Figure)

It is not the intention of the general IS Security Approach Characteristics to create a guideline for computer security, nor does it aim to restate what has already been written. There are many requirements that are common to all computer-related systems and therefore related standards, whether used in financial services, manufacturing, industrial control, or indeed in any other organized endeavor (ISO/FDIS 27799:2007(E) 2007). The general IS Security Approach Characteristics aim to personalize the profile of the researched security analysis. The General IS Security Approach Characteristics with reference to healthcare are derived according to their relevance to health informatics and require additional explanation in regards to, e.g., how they can best be applied to protect the confidentiality, integrity and availability of health information.

64


There are also additional health sector specific requirements that coincide with the Healthcare Specific IS Security Approach Characteristics. In this regard, a concerted effort has been made to focus on security requirements needed, e.g., when dealing with the unique challenges of delivering electronic health information that supports the provision of care. The specifics of the characteristics presented are not only based on the two main aspects: (1) their focus on the healthcare sector and (2) the improvement of the quality of treatment (Schweiger et al. 2007a) based on technical and process-oriented approaches. They are also based on the specific target audience such as health consumers, healthcare providers, health funders, the state, the healthcare telematics infrastructure (Standards Australia International 2003) and on the fact that they are taking the unique operating medical environment and specific laws concerning security and privacy of health related data into consideration. 3.3.1

Literature Review

Healthcare IS security issues currently receiving attention in literature were examined in detail in order to identify the characteristics. The literature review was based upon the approach of Webster and Watson (Webster/Watson 2002). A search was performed spanning IS security, information management, information systems, healthcare informatics, risk- and security analysis and management literature8. After the identification of relevant journals, the appropriate articles were examined. Accordingly, a search based on a full-text electronic search9 of selected keywords was carried out to identify relevant articles. The number of articles analyzed amounted to 1007. By examining the title and abstract of each article, a total of 145 articles were determined to be relevant. A further in-depth review resulted in 25 articles that were determined to be relevant and of importance for the research (Table 6).

8

9

All issues of the following journals were searched in an effort to include top journals in the selected disciplines: Accounting, Management & Information Technologies; ACM Computing Surveys; BioHealth; Computers & Security; European Journal of Information Systems; IM Information Management & Consulting; Information & Management; Information and Organization; Information and Software Technology; Information Systems; Information Systems Journal; Information Systems Management; International Journal of Information Management; International Journal of Communication Systems; MIS Quarterly; International Journal of Medical Informatics; Journal of Management Information Systems; Journal of the American Medical Informatics Association; Health Affairs; Journal of Biomedical Informatics; International Journal of Medical Informatics; Methods of Information in Medicine; New England Journal of Medicine; British Medical Journal; ACM Transactions Journals; IEEE Software; IEEE Transactions Journals; Computers and Security; International Journal of Information Security; Information Management and Computer Security; Information Systems Security; Computers and Security. The following databases were used: Business Source Premier, Science direct, JSTOR archive, INSPEC.

3.3 Characteristics of IS Security Approaches with Respect to Healthcare Journal

Keywords

65

Abstract

In-depth Review

Accounting, Management & Information Technologies

3

0

0

ACM Computing Surveys

10

0

0

BioHealth

53

12

1

Computers & Security

143

29

0

European Journal of Information Systems

132

5

2

9

1

0

IM Information Management & Consulting Information & Management

57

2

0

Information and Organization

21

4

0

Information and Software Technology

49

1

0

Information Systems

52

4

0

Information Systems Journal

57

3

0

Information Systems Management

15

1

0

International Journal of Information Management

23

1

0

International Journal of Communication System

21

3

1

MIS Quarterly

31

2

0

International Journal of Medical Informatics

73

8

2

Journal of Management Information Systems

78

7

0

Total Journals

6

827

83

Dissertations/ Master’s Theses/ Working paper

8

8

1

Conferences/ Workshops

12

7

6

Standards/ Methods

140

38

3

Articles of organizations and authorities

20

12

9

1007

148

25

Total

Table 6: Reviewed Journals and Analyzed Articles (Source: own Table)

66

3 Catalogue of IS Healthcare Security Characteristics Scientific Field

References

Security Analysis, Risk Management, Security / Risk Evaluation, Information Systems Security Evaluation Criteria

(Standards Australia International 2003); (Hamdi/Boudriga 2005); (Huber/Sunyaev/Krcmar 2008a); (Beham 2004); (BITKOM 2006); (Bornman/Labuschagne 2004); (Brooks/Warren 2004); (ENISA 2006); (Initiative D21 2001); (Vorster/Labuschagne 2001); (Schlichtinger 2005); (Janczewski/Xinli Shi 2002)

Information Systems Standards, Information Systems in Healthcare

(Anderson 1996b); (Blobel/Pharow 2007); (Standards Australia International/Standards New Zealand 2001); (Haas 2006b); (Hildebrand et al. 2006); (ISO/FDIS 27799:2007(E) 2007); (ISO/IEC 2005b); (LeRouge/Mantzana/Wilson 2007); (Mantzana et al. 2007); (Marschollek/Demirbilek 2006); (Müller 2005); (Schweiger et al. 2007a); (Toyoda 1998)

Table 7: Scientific Fields of Analyzed References (Source: own Table)

Table 7 assigns identified articles into the relevant scientific field. 3.3.2

Overview of Healthcare IS Security Approach Characteristics

In this section an overview of the different types of characteristics is given. In this thesis the term “approach” is used to refer to a published document describing an information systems security analysis method, process or standard related to healthcare. 3.3.2.1 General IS Security Approach Characteristics The general IS Security Approach Characteristics contain basic information which helps to identify and personalize the profile of the researched IS security approach and the skills needed to use the IS security approach. The basic information that should be provided comprises: [1] the name of the IS security approach (ENISA 2006), [2] the name of the company or international organization that provides the IS security approach (Schlichtinger 2005; ENISA 2006), and [3] the current version of the IS security approach during the case study period and information about the existence of any costs – e.g., licenses, fees for upgrades etc. – related to the IS security approach or whether it is [4] available free of charge. [5] Languages available specify the languages in which the IS security approach is documented. The first occurrence or other occurrences of the IS security approach could include several languages in which the IS security approach is available (ENISA 2006). In order to define how much active research is still being undertaken and to ascertain whether the research activities are transparent and conducted so that research methods can be subjected to peer review and independent verification by others, the characteristic activity of the research is taken into consideration as well. The scope of [6] the research activity is also a subject, in particular its limitation, as well as whether it is connected to a long-term goal.

3.3 Characteristics of IS Security Approaches with Respect to Healthcare Name

67

Short Description

1

Name of the approach (ENISA 2006)

The full name of the IS security approach.

2

Vendor name (Schlichtinger 2005; ENISA 2006)

Company or cross-frontier organization that provides the IS security approach.

3

Current version

The version during the case study period.

4

Availability

Are there any costs or is it available free of charge?

5

Languages available (ENISA 2006)

Which languages are supported by the IS security approach?

6

Research activity

Extent, scope, transparency, independency of the review verification of the active research undertaken.

Taking the [7] needed skills (ENISA 2006; Initiative D21 2001), time and effort into consideration (ENISA 2006) in order to understand, maintain or perform the IS security approach in the health organization, there are three types of skills relevant to this thesis: (1) to introduce, (2) to use and (3) to maintain. While the first group of skills is simply a general understanding of the dependencies among the specific details of the IS security approach, the second and the third groups require specific qualifications in order to perform current work and to maintain the life cycle of the IS security approach. For each of these types, the level of skills needed is classified according to the following scale: the basic level requires the most basic skills and amount of experience, the standard level requires a few days or weeks of training, and the specialist level requires extensive knowledge and experience (ENISA 2006; Initiative D21 2001). In certain instances, , external help from outside of the organization is necessary ([8] consultancy) in order to apply the IS security approach (ENISA 2006). In such cases, the IS security approach can be open to any consultant on the market or can be limited to a specific category of consultants (e.g., licensed) (ENISA 2006). Name

Short Description

7

Skills needed / Time and effort (ENISA 2006; Initiative D21 2001)

The skills needed to understand, maintain or perform the IS security approach in the organization.

8

Consultancy support (ENISA 2006)

Is it necessary to use external help (consultancy) in order to apply the IS security approach?

3.3.2.2 General IS Security Approach Characteristics with Reference to Healthcare Information systems researchers first have to understand the healthcare environment before they can develop appropriate information systems (Mantzana et al. 2007). Hospitals, emergency rooms, and laboratories are very different from commercial business environments,. Additionally, the rights and role of “healthcare users” are very different from those of consumers in commercial sectors (Mantzana et al. 2007). This section therefore describes general

68


IS Security Approach Characteristics in relation to the healthcare sector in order to provide a better understanding of the distinctive features of healthcare. 3.3.2.2.1 Type of the IS Security Approach The first characteristics expand the personalization of the profile of the researched approach. [9] Identification of the IS security approach (ENISA 2006; Schlichtinger 2005) is the first aspect, since it defines the types of IS security approaches concerned and the differences between them. An IS security approach type can be a standard, norm, method, regulation, guideline etc. Awareness of the type of approach is very important in the healthcare sector because any violation of existing regulations or norms could result in litigation and could have drastic implications (Adler 2003). Healthcare clearly carries potentially high risks, especially in areas such as laboratories, emergency departments and operating theatres (ISO/FDIS 27799: 2007(E) 2007). There are 4 different types of IS security approaches considered in this thesis: x

Method (ENISA 2006): defined as an ordered, efficient and systematic set of procedures/processes or as an approach – consists primarily of a set of consistent documents, stating, e.g., how to conduct a security assessment. The implementation of the method does not require the installation of an application on a computer (ENISA 2006).

x

Standard (ENISA 2006): Many standards are written as voluntary standards. A voluntary standard may become so common and dominant that its use is automatically expected. An organization may create its own standard and make them mandatory. Standards become norms when they are developed on a formal basis and are recognized or adopted by a government or regulatory body (Haas 2006a). For information systems, standards are the basis for manufacturers to implement compatible and interoperable infrastructure components for example for healthcare telematics platforms (Haas 2006a) and are also the basis for evaluations of security policies and their associated processes. A standard defines what is required, e.g., in terms of IS security in healthcare and, usually, not how these requirements are to be met (ISO/FDIS 27799:2007(E) 2007).

x

Regulation: Defined as legal restrictions enforced by government authorities.

x

Guideline: A generic framework, a best practice approach for managing risk, in this case for instance within the health sector. Usually guidelines are based on different standards and their purpose is to describe procedures for implementing standards or an


69

approach that satisfies the requirements of the applicable statutes and regulations. By definition, following a guideline is never mandatory. Name 9

Short Description

Identification of the IS security approach (ENISA 2006; Schlichtinger 2005)

Type of the IS security approach - can be a standard, a norm, a method, regulation, guideline etc.

3.3.2.2.2 Common Characteristics Due to the specific local laws concerning security and privacy of health related data, [10] the country of origin (ENISA 2006) and [11] the level of reference of an IS security approach (ENISA 2006; Schlichtinger 2005; BITKOM 2006) must be identified. The country of origin contains basic information about whether the IS security approach originated from a commercial or public organization. The level of reference provides more details about the type(s) of initiator(s) of IS security approaches such as: x

National standardization body (BITKOM 2006; ENISA 2006), e.g., ANSI.

x

European standardization body (BITKOM 2006; Hildebrand et al. 2006), e.g., CEN/ISSS (Information Society Standardization System), eHealth standardization focus group.

x

International standardization body (BITKOM 2006; ENISA 2006), e.g., ISO.

x

Private sector organization / association (ENISA 2006), e.g., institute for one world health, drugs for neglected diseases Initiative etc.

x

Public / government organization (ENISA 2006), e.g., UK National Health Service, medicare Australia etc. Name

Short Description

10

The country of origin (ENISA 2006)

From a company or national organization.

11

Level of reference of the IS security approach (ENISA 2006; Schlichtinger 2005; BITKOM 2006)

Details about the type(s) of initiator(s) of the IS security approach.

Once the origin IS security approach and its initiator is established, the next step is to determine the [12] geographical spread (ENISA 2006; Initiative D21 2001) of the IS security approach. This characteristic describes whether or not the IS security approach is also established outside of its original field and outside of its country of origin, i.e., the degree of its internationality. It should be made clear that internationality per se is not equivalent to inter-

70


nationality as measured by appearance in academic journal publications where in particular, publications in prestigious international journals are used as important quality indicators (Buela-Casal/Perakakis/Taylor 2006). In this case, the establishment in terms of usability and implementation of the IS security approach within organizations outside of its original field is an important quality indicator. A list of EU and non-EU member states should be provided in which the implementation is known to working group members. In the healthcare sector, many IS security approaches are available on a regional, national or international level, but they often differ from and compete with each other (Hildebrand et al. 2006). There are a number of successful national initiatives and developments in healthcare, which fail when transferred, for example, to the European level (Hildebrand et al. 2006). The reasons for this are, amongst others, the lack of trust chains at the European level (Hildebrand et al. 2006). For example, the use of digital signatures (Allaert et al. 2004) by healthcare organizations and citizens should be made obligatory in all EU member-states (Hildebrand et al. 2006; Piltz 2007). Public organizations must be involved to solve this problem (Hildebrand et al. 2006). This shows the unique challenges that geographical spread pose for IS security approaches in healthcare. Name 12

Short Description

Geographical spread (ENISA 2006; Initiative D21 2001)

Whether the IS security approach is also established outside of its original field or location, i.e., its degree of internationality, e.g., if the IS security approach is used in EU or non-EU member countries.

In order to gain insight into the IS security approach [13] lifecycle (ENISA 2006; Initiative D21 2001; Beham 2004) and to determine how up-to-date the approach is, a short historical overview becomes a necessity. This should examine the state-of-the-art in IS security approaches and revisions on a periodical basis. Issues such as the frequency of updates or how often revisions take place are covered by this characteristic. In the healthcare sector this information is very important, for example, changing laws concerning security and privacy of health related data greatly influence requirements for IS security. The basic information that should be provided includes the date of the first edition / release, date and number of current updated versions, whether the IS security approach originated from other IS security approaches (i.e., has been integrated into other IS security approaches), which general milestones (i.e., name changes) exist, and if it is currently or is planned to be covered by new IS security approaches. Name 13

Lifecycle / Actuality (ENISA 2006; Initiative D21 2001; Beham 2004)

Short Description A short historical overview in order to gain insight into the IS security approach lifecycle (how up-to-date).


71

After examining the IS security approach lifecycle, the characteristics that provide the requirements for the content of the IS security approach are described. Before this however, it is important to know more about the IS security approach, namely its [14] fundamental objectives and especially those which concern the analysis of security (ENISA 2006), its scope and its intention regarding any targets to be achieved, expected results, improvements, and requirements. A concise and clear description of the IS security approach’s focus can help to identify the coherence, determine the differences between IS security approaches and provide a general overview of their relevance to healthcare. To help understand all of this, here are some practical examples. The IS security approach’s objective for instance could be that healthcare organizations can expect to see the number, severity and impact of their security incidents reduced (Standards Australia International/Standards New Zealand 2001). For example, an improvement healthcare organizations could expect to see is an increase in the public’s trust in the health information systems be achieved through a consistent approach to IS security that is understood by all stakeholders (ISO/FDIS 27799:2007(E) 2007). Finally, the focus of the IS security approach could be, for instance, the establishment of an appropriate level of healthcare IS security for the health provider as a whole or for supporting organizations wishing to be certified according to an IS security management standard. Name 14

Fundamental objectives and IS security approach scope (ENISA 2006)

Short Description Intentions regarding IS security approach targets to be achieved, expected results, improvements and requirements.

In order to provide the sufficiency of any given scope or generally speaking to indicate whether the IS security approach content is [15] complete (Initiative D21 2001; Schlichtinger 2005), all components related to the security analysis should be provided. One basic question is whether the scope has been extensively and thoroughly examined. Another question is, for example, whether catalogues are created and supported, such as catalogues of healthcare related security measures, catalogues of healthcare related hazards consisting of best practice threats, etc. Finally, is there merely a recommendation for healthcare related countermeasures or is there also support for their implementation? Name 15

Completeness (Initiative D21 2001; Schlichtinger 2005)

Short Description How comprehensive, abstract, detailed is the IS security approach?

Next, it is essential to identify the target audience of the document (ENISA 2006; BITKOM 2006). For instance the IS security approach could be intended for those responsible for overseeing healthcare IS security and other guardians of health information seeking guidance on the topic, together with their security advisors, consultants, auditors, vendors and third-party

72


service providers (ISO/FDIS 27799:2007(E) 2007). For a clear differentiation, different types of [16] level of details are defined which imply the target user group in the health organization. Groups of targeted users are: x

Management level: generic guidelines (ENISA 2006), e.g., in healthcare domain users are the president and CEO of the hospital.

x

Operational level: guidelines for the implementation planning with a low level of detail (ENISA 2006), e.g., in the healthcare such users would include health professionals.

x

Organizational level: specific guidelines concerning the organizational and human aspects of IS Security with a high level of detail (ENISA 2006), e.g., in healthcare this level is aimed at healthcare security officers or chief information security officers (CISO). Name

16

Short Description

Level of detail (ENISA 2006; BITKOM 2006)

Who should read and use the IS security approach.

Other important characteristics are the [17] scalability (Initiative D21 2001; Beham 2004) of an IS security approach and the nature of the target organizations (ENISA 2006; Initiative D21 2001; BITKOM 2006; Beham 2004). During a change in technology, scalability is one of the most commonly affected parameters. Ineffective scalability can reduce the popularity of the IS security approach. Therefore, adequate care should be taken to ensure that the incorporation of new technology doesn't affect the scalability of the IS security approach. This means that the IS security approach should be technology-neutral with scalability for size and complexity (ISO/FDIS 27799:2007(E) 2007). Name 17

Scalability (Initiative D21 2001; Beham 2004)

Short Description Scalability for the size and complexity of healthcare organizations.


73

By defining the [18] target organizations (ENISA 2006; Initiative D21 2001; BITKOM 2006; Beham 2004) it becomes obvious what type of health organizations the IS security approach is aimed at:

18

x

Governments, agencies (ENISA 2006): the IS security approach is developed for health organizations working for the state, e.g., UK National Health Service.

x

Large health organizations: the IS security approach is recommended for health organizations with more than 250 employees (ENISA 2006).

x

Small and Medium Size health organizations: the IS security approach is recommended for small and medium sized health organizations that cannot afford dedicated security personnel or a complete segregation of duties (ENISA 2006).

x

Commercial health organizations: the IS security approach is targeted at health organizations that have are required to implement it due to commercial demands from stakeholders, financial regulators, etc.

x

Non-profit (ENISA 2006): health organizations where commercial consideration are not a major issue, such as the NGO health sector, public services, etc.

x

Specific sector (ENISA 2006): the IS security approach is dedicated to a very specific sector, e.g., emergency healthcare and usually cannot be used in other sectors. Name

Short Description

Target organizations (ENISA 2006; Initiative D21 2001; BITKOM 2006; Beham 2004)

The type of health organizations the IS security approach is aimed at.

3.3.2.2.3 Methodology Healthcare organizations wanting to conduct information security analysis may find selecting a methodology problematic (Vorster/Labuschagne 2001). Currently there are numerous security analysis methodologies available, some of which are qualitative while others are more quantitative in nature (Vorster/Labuschagne 2001). These methodologies have the common goal of estimating the overall risk value (Vorster/Labuschagne 2001). But healthcare organizations must select the most appropriate methodology based on their specific needs. This section addresses the problem by presenting the characteristics of the security analysis in the healthcare domain in cases studies where the researched IS security allows.

74


[19] Security analysis (Beham 2004; ISO/FDIS 27799:2007(E) 2007; ISO/IEC 2005b) approach should provide structured methodology based on a set of concepts that comprises, for example, a scope definition, security policy, vulnerability analysis, threat analysis, business impact analysis, scenario analysis, security measures evaluation, cost-benefit analyzes and/or gap analysis. The comparative framework of (Vorster/Labuschagne 2001) is used to evaluate the differences, but that is not the purpose of this thesis. Security Analysis is an integral part of reforming the healthcare sector (Standards Australia International/Standards New Zealand 2001). The security analysis can be used to optimize procedures in order to minimize losses and to provide a comprehensive approach to improving security from the patient’s point of view (Standards Australia International/Standards New Zealand 2001). Name 19

Short Description

Security Analysis (Beham 2004; ISO/FDIS 27799:2007(E) 2007; ISO/IEC 2005b)

Is there an appropriate security analysis approach included?

Part of the security analysis’s scope should be the evaluation of [20] heterogenic, decentralized information systems. The increased interconnection of health information systems as a result of future integrated eHealth systems makes security analysis in healthcare especially challenging, as few health organizations can act as if their systems were isolated islands of information (ISO/FDIS 27799:2007(E) 2007). Name 20

Short Description

Supporting heterogenic, decentralized information systems (ISO/FDIS 27799:2007(E) 2007)

Taking heterogenic, decentralized information systems into consideration.

The security analysis should be [21] process-oriented and not asset or system oriented because healthcare processes directly affect the care of and services delivered to patients (ISO/FDIS 27799:2007(E) 2007). Therefore the scope of the security analysis are healthcare telematics processes that should be clearly defined, for example a patient emergency visit, a patient ambulatory visit, or the prescribing of an electronic prescription. Name 21

Process oriented evaluation method (ISO/FDIS 27799:2007(E) 2007)

Short Description Process oriented and not asset or system oriented method focused on the healthcare telematics processes.

The focus of the security analysis should be targeted at [22] organizational risks (Hamdi/Boudriga 2005). Organizational risks are derived from the interaction of people with the information systems and consider the impact of technical failures on patients. This thesis gives


75

particular attention to organizational risks in healthcare that are addressed due to the processoriented security analysis approach to be developed. Name 22

Organizational Focus (Hamdi/Boudriga 2005)

Short Description Organization focused assessment is targeted at organizational risks which are derived from the interaction with the people with the information systems and consider the impact of technical failures on patients.

From the methodologically point of view the existing security analysis approach should be [23] pro-active and not reactive. There are many differences between preventive and reactive security analysis. The former is a proactive strategy security (before the occurrence of a security incident) while the latter involves interventions after a security incident has occurred (Hamdi/Boudriga 2005). Questions concerning methodology limits in the event of a security analysis are very important from the healthcare point of view because a good outcome in healthcare can only happen if two key elements are present: interdisciplinary processes and the right information (Standards Australia International/Standards New Zealand 2001). This outlines a pro-active integrated multidisciplinary approach and highlights the need for communication at all steps along the care continuum (Standards Australia International/Standards New Zealand 2001). Name 23

Pro-active security analysis (Hamdi/Boudriga 2005)

Short Description Is there a separation between preventative/pro-active and reactive security analysis especially in the healthcare domain (Hamdi/Boudriga 2005)?

The selected security analysis methodology should ensure that security assessments produce [24] comparable and reproducible results (ISO/IEC 2005b), provide IS security approach guidance on how an organization, through the use of metrics, measurements, and appropriate measurement techniques, can assess its security management status in order to compare it to the previous one. This is part of the continuity of the improvement of the IS security of healthcare, which is of great importance because of the high liability impact. Name 24

Comparable and reusable results (ISO/IEC 2005b)

Short Description The security assessment methodology selected shall ensure that security assessments produce comparable and reproducible results.

After conducting a security analysis, the measurement of the [25] maturity of the information system security should be possible (e.g., through a reasoned best practice document). Estimating the level of maturity is of great importance in healthcare due to the potential for serious liability issues (Initiative D21 2001; ENISA 2006).

76

3 Catalogue of IS Healthcare Security Characteristics Name

25

Short Description

Maturity level (Initiative D21 2001; ENISA 2006)

Measurement of the maturity of the information system security.

3.3.2.2.4 Surrounding Conditions The characteristic [26] Available Tools (ENISA 2006; Initiative D21 2001; Beham 2004) provides a list of tools that support the IS security approach (commercial tools as well as noncommercial ones) (ENISA 2006). The list also indicates, in cases where the IS security approach is supported by a tool, whether the tool supports the entire approach or only part of it (e.g.: tool only for security assessment, tool for process modeling). In healthcare, tool support means that appropriate protection is maintained (Standards Australia International 2003), e.g.: easier identification of the health information assets (these may be patient records, x-rays, photographs, databases, internal documentation, e.g., operational policies and procedures, textbooks such as medical or reference books) and processes requiring stronger protection, i.e., what assets and processes does a health business own (Standards Australia International 2003). Name 26

Short Description

Available tools (ENISA 2006; Beham 2004; Initiative D21 2001)

Existing of a list of tools that support the IS security approach.

[27] Certification scheme (Initiative D21 2001; ENISA 2006) concerns itself with topics such as whether a health organization may obtain a certificate to verify that is has fully and correctly implemented a security approach and also whether or not the organization’s IS security approach is compliant with relevant specifications, policy, standards or laws. This means that a health organization of any size, sector or function can seek independent third party veryfication of its information management performance. The professional certification is a vital step toward improving patient care, reducing costly mistakes, and addressing healthcare disparities.

27

Name

Short Description

Certification scheme (Initiative D21 2001; ENISA 2006)

Existence of a certification scheme: a health organization may obtain a certificate, that it has fully and correctly implemented the IS security approach on its information systems.

The last two characteristics in this section are [28] optimal investment sum and [29] organizational integration (ENISA 2006). By establishing healthcare telematics in Germany, several improvements, such as cost savings, improved communications in the healthcare sector and greater patient control over medical data, are supposed to be achieved (Huber/Sunyaev-


77

/Krcmar 2008a). Looking at cost reductions and considering the fact that security planning itself results in costs for the responsible health provider, the amount of the optimal investment sum related to a security analysis project should be conveniently predicted. After calculating the optimal sum it is important to know if the IS security approach provides interfaces with existing processes within the health organization (e.g.: hospital logistics process, business continuity planning in healthcare, change management, information system management, project management etc.) in order to measure its degree of customization. Name

Short Description

28

Optimal investment sum (ENISA 2006)

The amount of the optimal effort related to a risk management project.

29

Organizational integration (ENISA 2006)

Interfaces to existing processes within the health organization.

3.3.2.3 Healthcare-Specific IS Security Approach Characteristics The information security paradigm within the health industry has special requirements that must to be met, such as an added emphasis on protecting patient information (Brooks/Warren 2004). Due to their importance this section provides an overview of these characteristics and describes them in detail. In order to estimate the IS security approach’s relevance for the [30] healthcare branch (BITKOM 2006), the most important characteristics are whether the IS security approach is aimed at healthcare and whether its strategies are tailored to meet the needs of healthcare. For further details, one needs to see what the target audience is in the healthcare branch (Standards Australia International 2003). This is the intended [31] target group that the IS security approach is aimed at. Furthermore, this information helps to get an overview of the scope and especially which parties are involved within the organizational processes in the healthcare. The following groups were identified: x

Health consumers: patients demand high quality, accessible care etc. (Standards Australia International/Standards New Zealand 2001; Standards Australia International 2003).

x

Healthcare providers: public and private hospitals, physician offices, health professionals, pharmacies, medical centers (Standards Australia International 2003).

78


Health funders / health agencies: the rate of funding and payment has not kept pace with the demand for care, which narrows the margin for error and inefficiency. The organization’s financial status and assets need to be protected (Standards Australia International/Standards New Zealand 2001; Standards Australia International 2003).

x

The state: new pressures for increased accountability create a new demand to know if quality is improving, declining, or staying the same (Standards Australia International/Standards New Zealand 2001).

x

Information repositories: healthcare telematics infrastructure (Standards Australia International 2003). Name

Short Description

30

Branch (BITKOM 2006)

Industry sector and the group of business organizations the IS security approach is aimed at.

31

Target audience in the healthcare branch (Standards Australia International 2003)

The intended target group in the healthcare branch the IS security approach aims at: health consumers, healthcare providers, health funders, the state, the healthcare telematics infrastructure.

One of the specific features of the healthcare branch are the numerous government acts which impact the sector, acts which healthcare organizations must [32] comply with (ENISA 2006; Standards Australia International/Standards New Zealand 2001; ISO/IEC 2005b; Initiative D21 2001). Because of this, it is vital to know whether the IS security approach complies with international or national laws and regulations. Name 32

Compliance (ENISA 2006; Initiative D21 2001; ISO/IEC 2005b)

Short Description Compliance with laws and regulations, e.g., several political acts impact the health sector and must be complied with (Standards Australia International/Standards New Zealand 2001).

Another specific feature of healthcare are the relatively high risks in the sector, especially in areas such as laboratories, emergency departments, and operating theatres (ISO/FDIS 27799:2007(E) 2007). The detection of low risks in health information activities that support such areas should therefore be questioned, although the trap of assuming that every health information activity directly relates to care delivery would be equally wrong (ISO/FDIS 27799:2007(E) 2007). To enhance the security assessment it is important not only to provide proposals for [33] healthcare generic hazards list (ISO/FDIS 27799:2007(E) 2007), [34] healthcare security requirements (ISO/FDIS 27799:2007(E) 2007), and [35] healthcare security measures (ISO/FDIS 27799:2007(E) 2007) but also to provide carefully designed [36] risk valuation guidelines relevant to healthcare (ISO/FDIS 27799:2007(E) 2007). Such valua-


79

tion guidelines recognize the importance of patient security, uninterrupted availability of emergency services, professional accreditation, and clinical regulation (ISO/FDIS 27799: 2007(E) 2007). Name

Short Description

33

Hazard list relevant to healthcare (ISO/FDIS 27799:2007(E) 2007)

Proposal for healthcare generic hazards.

34

Security requirements relevant to healthcare (ISO/FDIS 27799:2007(E) 2007)

Proposal for healthcare security requirements.

35

Security measures relevant to healthcare (ISO/FDIS 27799:2007(E) 2007)

Proposal for healthcare security measures.

36

Risk valuation guidelines relevant to health (ISO/FDIS 27799:2007(E) 2007)

Proposal for healthcare valuation of risk explain the risk value specific for healthcare.

A further unique healthcare characteristic is the array of factors to be considered when assessing threats and vulnerabilities (ISO/FDIS 27799:2007(E) 2007) with special emphasis on the creation of [37] security measures which should take into consideration not only the IS security point of view, but also the patient’s point of view. The healthcare sector is at least a decade behind other high-risk industries in ensuring that its information systems security incorporates patients’ points of view. In this sense security is the first vital step towards improving the quality of care (Standards Australia International/Standards New Zealand 2001). Name 37

Security measures point of view (ISO/FDIS 27799:2007(E) 2007)

Short Description Do the security measures provided consider the patient’s point of view as well the IS security point of view?

The protection and security of information is of critical importance to all individuals, government agencies and firms. Healthcare places special emphasis on requirements for [38] confidentiality, privacy, integrity, availability, authenticity, commitment, use regulation, accuracy, utility, possession, legal liability, legal certainty, enforceability, suitability for daily use, and anonymity (ISO/FDIS 27799:2007(E) 2007; Standards Australia International 2003; Anderson 1996b; ISO/IEC 2005b; Müller 2005).

38

Name

Short Description

Requirements for confidentiality, privacy, integrity, availability of information (Anderson 1996b)

Is the protection and security of information ensured for these requirements? Further security elements of information systems in healthcare are authenticity, commitment, use regulation, accuracy, utility, possession, legal liability, legal certainty, enforceability, suitability for daily use and anonymity (Müller 2005).

80


[39] Data quality requirements (ISO/FDIS 27799:2007(E) 2007) are characteristics affirming that medical data must have a state of completeness, validity, consistency, timeliness and accuracy that makes it appropriate for the specific use within the healthcare domain. Due to this fact data quality requirements should be a component of the IS security approach in order to facilitate security assessments. Name 39

Short Description

Data quality requirements (ISO/FDIS 27799:2007(E) 2007)

Requirements for completeness, validity, consistency, timeliness, and accuracy of the data.

The [40] physical security (Standards Australia International/Standards New Zealand 2001; ISO/IEC 2005b) of healthcare information systems is very important due to the high liability impact. Environmental security (ISO/IEC 2005b) is also an important issue. Organizations processing personal health information should use security perimeters to protect the areas that contain the information processing facilities for health applications. These secure areas should be protected by appropriate entry controls to ensure that only authorized personnel are allowed access. Name 40

Physical and environmental security (Standards Australia International/Standards New Zealand 2001; ISO/IEC 2005b)

Short Description Physical security of the information systems.

Table 8 itemizes introduced healthcare IS security approach characteristics according to their suitability for healthcare.


81

General IS Security Approach Characteristics 1. 2.

3.

Name of the approach Vendor name Current version

4. 5. 6.

Availability Languages available Research activity

7. 8.

Skills needed / Time and effort Consultancy support

General IS Security Approach Characteristics with Reference to Healthcare 9. 10. 11. 12. 13. 14.

Identification of the IS security approach The country of origin Level of reference of the IS security Geographical spread Lifecycle / Actuality Fundamental objectives and IS security approach scope

15. 16. 17. 18. 19. 20.

Completeness Level of detail Scalability Target organizations Security Analysis Supporting heterogenic, decentralized information systems

21. 22. 23. 24. 25. 26. 27. 28.

Organizational Focus Pro-active security analysis Comparable and reusable results Maturity level Available tools Certification scheme Optimal investment sum Organizational integration

Healthcare Specific IS Security Approach Characteristics 30. Branch 31. Target audience in the healthcare branch 32. Compliance 33. Hazard list relevant to healthcare

34. Security requirements relevant to healthcare 35. Security measures relevant to healthcare 36. Risk valuation guidelines relevant to health

37. Security measures point of view 38. Requirements for confidentiality, privacy, integrity, availability of information 39. Data quality requirements 40. Physical and environmental security

Table 8: Overview of the IS Security Approach Characteristics (Source: according to (Sunyaev et al. 2009a))

Table 39 in the Appendix summarizes the healthcare IS security approach characteristics relevant for a security analysis method that can be used to examine German healthcare telematics. 3.4

Summary

With the current trend away from paper-based towards digital communication, healthcare is becoming increasingly more dependent on IS technology to maintain and advance patient treatment (Schweiger et al. 2007a). Such dependency on IS technology requires protection from technical disasters and/or human threats (Anderson 2000; Doherty/Fulford 2006; Lorence/Churchill 2005; Blobel 2004). After having conducted an in-depth literature review and using a structured research approach this chapter identified a lack of specific security requirements for the healthcare sector based, amongst others, on its unique operating environment, an environment where security is seen as a people problem and users remain the greatest threat (Schneier 2008). This was also based on the specific laws related to the security and privacy of health related data. Furthermore, the chapter addressed this problem with a presentation of the specific information systems security characteristics in healthcare. The goal of the introduced characteristics is an improvement of healthcare based process-oriented security analysis approaches. The introduced healthcare IS security approach characteristics can be used to estimate the relevance of almost any security analysis approach (Firesmith 2003) with respect to the healthcare sector. This knowledge can help to analyze IS security analysis ap-

82


proaches with regard to their applicability in the healthcare domain, develop new healthcare IS security analysis approaches, and also to alter existing approaches in order to adapt them to the specific healthcare situation at hand.

4 4.1

Analysis of IS Security Analysis Approaches Overview

The goal of information systems security analysis and security assessment is the identification and evaluation of possible threats (Siponen 2005a): security analysis and security assessment are both integral parts of security management. The role of security management in the development and operation of information systems has a long tradition of research in computer science, information systems and management science (Kuper 2005; Landau 2008; Poore 2000; Siponen/Iivari 2006). Integrating the economic, organizational and technical aspects of information systems (IS) security analysis requires the bridging of these different research streams. Various reviews or summaries of information systems security analysis approaches exist, however their respective motivations, backgrounds and foci differ (Kiely/Benzel 2006). The goal of this chapter is to provide an integrated classification of IS security analysis approaches as an overview aid during the examination of identified methods. In order to achieve this aim, this chapter summarizes existing approaches and assigns them to unique and unambiguous classes that were identified during the literature review process. In addition, synonyms and homonyms that appear in the various approaches are identified and classified which allows for a better understanding and comparison of the approaches. Furthermore, in contrast to other works, this thesis does not focus on IS security development but on IS security analysis. This specialization allows a more detailed analysis so that the different foci of IS security analysis approaches can be identified and a more precise delineation of the approaches can be presented. The newly developed classification could prove useful to both researchers and practitioners in this field. Furthermore, the developed classification is essential for the examination of identified methods according to their suitability to the healthcare domain. The derived classification scheme is used to identify different kinds of IS security approaches. This knowledge is then used to select IS security approaches according to their foci and their relevance to a security analysis method that is constructed in this thesis. In the next step, the selected IS security approaches are analyzed regarding the fulfillment of previously defined healthcare IS security approach (chapter 3) characteristics and thereby provide the basis for the method fragments of the HatSec method. The results identify key steps of common IS security approaches, which are latter adapted to healthcare specific security requirements. This chapter begins by describing the literature search in detail, specifically the article selection and article categorization processes that were used. The existing IS security analysis approaches are analyzed in the “Existing Literature Reviews” section. The next section outlines


84

4 Analysis of IS Security Analysis Approaches

a theoretical framework for systemizing and analyzing existing IS Security Analysis approaches in section “Theoretical Framework”. The results of the classification are presented in the section “Systematization of the Security Analysis Approaches”. The section “Analysis of IS Security Analysis Approaches” analyzes identified security analysis methods according to the catalogue of IS healthcare security characteristics that was defined in section 3. Finally the last section in this chapter summarizes the key findings and provides recommendations for an information systems security analysis method specific to healthcare telematics. Figure 14 illustrates the core elements of this chapter.

Different Types of Security Analysis Methods identified in Science and Practice


4.4 Systematization of IS Security Analysis Approaches Methodology

Review of Literature

Theoretical Background

4.5 Analysis of IS Security Analysis Approaches with Respect to Healthcare

Implication

The Literature Review and the conducted Evaluation of IS Security Approaches with Respect to Healthcare show Insufficiencies with current IS Security Analysis Methods lacking the Techniques to analyze technical and social Aspects of Information Security in a Healthcare Environment


4.2

Review of Literature

The research approach used for the literature review was proposed by Webster and Watson (Webster/Watson 2002). A search was performed spanning IS security, information management, information systems, risk- and security management literature.

4.2 Review of Literature Journals

85 Abstract

In-depth Review

ACM Computing Surveys

1

1

Of Interest 1

ACM Transactions on Information and System Security

38

1

0

Bank Accounting & Finance

2

1

0

Communications of the ACM

54

8

1


92

32

2

European Journal of Information Systems

4

1

1

HMD Praxis der Wirtschaftsinformatik

7

5

0

IEEE Security & Privacy

21

4

0

IM Information Management & Consulting

3

1

0

Information and Organization

2

1

0

Information Management & Computer Security

33

9

1

Information Systems Journal

13

2

2

Information Systems Management

12

1

0

Information Systems Research

11

1

0

Information Systems Security

41

9

0

Information Security Management

29

1

0

Internal Auditor

21

1

0

International Journal of Network Management

28

1

0

International Journal of Medical Informatics

9

2

0

Journal of Computer Security

7

1

0

Journal of Management Information Systems

4

1

0

Journal of Research and Practice in Information Technology

2

1

0

Journal of the Association for Information Systems

5

2

0

Management Information Systems Quarterly

8

1

0

Strategic Finance

7

1

0

Others

11

10

2

Total Journals

465

99

10

Articles of organizations and authorities

19

19

2

Dissertations/ Master’s-/ Bachelor Theses/ Working Paper

39

39

5


13

4

1

Total

536

161

18

Table 9: Sources of Analyzed Articles (Source: own Table)

86


To identify relevant articles, selected journals in these fields were examined using a full-text electronic search10 of selected keywords, such as “information systems security”, “IS security (risk) analysis”, “IS security (risk) assessment” and “security and risk management”11. This search yielded a total of 465 articles. The titles and abstracts of each article were examined to determine their relevance for this research (i.e., the article appeared to be relevant to, the topic security analysis). This process generated 99 articles for in-depth review. In an effort to broaden the search beyond the original set of journals a snowball sampling technique (Goodman 1961) was used to discover cited works of potential interest in the 99 articles and an additional 71 sources were found. These sources included dissertations, master and bachelor theses, working papers from universities, publications by organizations and governmental agencies, and conference proceedings. As a result, a total of 161 articles were reviewed indepth. Table 9 offers an overview of the examined articles. The categorization of the literature was concept-driven (Webster/Watson 2002). Each article was examined to assess if it contained a suggestion for a systematization of security analysis approaches or already identified subclasses. Out of the 161 reviewed articles, 18 included such a suggestion. Table 10 lists these articles and illustrates their sub-area of focus. The table also shows which parts of the systematization each article addresses. An X in the column ‘assessment approaches’ means that the article addresses the systematization of assessment approaches. The next section provides an overview of related work in this field. Existing literature reviews concerning the classification of IS security approaches are identified and described in detail. Furthermore, the identified IS security literature reviews are examined and summarized according to their scope and how current they are.

10 11

The following databases were used: Business Source Premier, Science direct, JSTOR archive, INSPEC All issues of the following journals were searched in an effort to include top journals in the selected disciplines and broaden search in German-speaking areas: ACM Computing Surveys, ACM Transactions on Information and System Security, Bank Accounting & Finance, Communications of the ACM, Computers & Security, European Journal of Information Systems, HMD Praxis der Wirtschaftsinformatik, IEEE Security & Privacy, IM Information Management & Consulting, Information and Organization, Information Management & Computer Security, Information Systems Journal, Information Systems Management, Information Systems Research, Information Systems Security, Information Security Management, Internal Auditor, International Journal of Network Management, Journal of the Association for Information Systems, International Journal of Medical Informatics, Journal of Computer Security, Journal of Management Information Systems, Journal of Research and Practice in Information Technology, Management Information Systems Quarterly, Strategic Finance.

X

X

X

X

X

(BITKOM 2006)

X

(Dhillon/Backhouse 2001)

X

(Dhillon/Torkzadeh 2006)

X

(Eloff/von Solms 2000)

X

X

(Faisst/Kovacs 2003)

X

(Faisst/Prokein/Wegmann 2007)

X

(Gordon/Loeb 2006)

X

(Hechenblaikner 2006)

X

(Initiative D21 2001)

X

(Karabacaka/Sogukpinar 2005)

X

(Kokolakis/Demopoulos/Kiountouzis 2000)

X

(Metzler 2003)

X

(Prokein 2005) (Siponen 2005b)

Legislation Accommodations

(Baskerville 1993)

IT Security Management Approaches

X

(Aagedal et al. 2002)

Risk Analysis Approaches

X

Assessment Approaches

Checklists

Authors

87

Overall Systematization

4.2 Review of Literature

X X

X

(Hoo 2000)

X

(Su 2006)

X

X

Table 10: Articles of Interest (Source: own Table)

4.3

Existing Literature Reviews

The literature review yielded five research publications that classify methods used in information systems security. These are the works of (Baskerville 1993), (BITKOM 2006), (Dhillon/Backhouse 2001), (Eloff/von Solms 2000), and (Siponen 2005b). Below this section reviews each of these works and discusses what elements they bring to the classification scheme being developed and identify their shortcomings as relates to IS security analysis approaches.

88


An Analysis of the Traditional IS Security Approaches: Implications for Research and Practice (Siponen 2005b) (Siponen 2005b) addresses information systems security (ISS) methods. His systematization consists of five classes (Checklists, IS Security Standards, IS Security Maturity Criteria, Risk Management, and Formal Methods), three of which are connected to IS security analysis. Two of Siponen’s suggested classes, ISS Maturity Criteria and Formal Methods, are not security analysis approaches. Instead, their focus is on ensuring the secure development of information systems. The other three suggested classes are Checklists, ISS Standards, and Risk Management which correspond with the classes Checklists, IT Security Management Approaches, and Risk Analysis Approaches which are suggested in the this thesis. In contrast to Siponen’s work the systematization developed in this paper distinguishes between standards and best practice models, which are subclasses of the IT security management approaches. Furthermore, in this thesis the term risk analysis is used, instead of risk management. This is due to the fact that the focus of this thesis is narrower than that of Siponen’s work. Therefore, only risk analysis, which is part of the risk management, is of interest for this work. Summary: x

Siponen’s work addresses ISS Methods and therefore has a larger scope than this thesis.

x

Siponen suggests five classes that are somewhat disjointed. The five classes are not further subclassified which limits the decision support for the reader.

x

Siponen does not consider the legal issues that impact IS security nor does it consider IS security assessment approaches.

Current Directions in IS Security Research: Towards Socio-Organizational Perspectives (Dhillon/Backhouse 2001) (Dhillon/Backhouse 2001) classify IS security by using four models from the fields of sociology and philosophy. Subsequently, various IS security approaches are assigned into these models. The IS security approaches they mention are, among others, Checklists, Risk Analysis Methods, and Security Evaluation Methods where Risk Analysis is part of Risk Management. Because security analysis is only a part of security management, the class Risk Analysis is preferred to the class Risk Management as used by (Siponen 2005b). The class evaluation is defined roughly: “Another category of research in computer security is in evaluation methods, whose rationale stems from the need to measure security” (Dhillon/Backhouse 2001, 136).

4.3 Existing Literature Reviews

89

Approaches that they assign to this class include security models such as Bell-LaPadula as well as standards such as BS 7799. This particular systematization uses the term “standard” because security models are not appropriate for conducting a security analysis. Summary: x

Dhillon and Backhouse examine socio-organizational aspects of information systems and IS security. Technical and economical aspects are not considered.

x

Dhillon’s and Backhouse’s systematization classifies IS security methods according to the sociological and philosophical theories that they are based on. This approach is more scientific but is impractical for use in decision support.

x

For sociological and philosophical purposes the classification can be considered complete but it is not suitable for IS security purposes. As mentioned, the technical and economical aspects of IS security are ignored in Dhillon’s and Backhouse’s systematization.

x

Some of the content in this work is outdated. For example, the standard BS 7799 is no longer in use.

Information Security Management: A Hierarchical Framework for Various Approaches (Eloff/von Solms 2000) (Eloff/von Solms 2000) strive to distinguish and define terms in the field of IS security management. They identify and define the following terms: standard, guideline, control, code of practice, certification, accreditation, benchmarking, self-assessment, legislation, and evaluation. Examples for standards, guidelines, code of practices, and evaluations are provided and classified based on a framework the authors developed. The framework consists of two main classes: technology and processes. Summary: x

Eloff and von Solms address IS security management approaches; whereas the focus this thesis is on IS security analysis.

x

Eloff and von Solms only examine a few methods. Their work does not claim to be complete.

90

4 Analysis of IS Security Analysis Approaches x

Their framework identifies two broad classes which are integrated. In contrast to Eloff and von Solm’s framework, the classification proposed in this thesis consists of five classes and provides better decision support for the reader.

x

The Eloff and von Solms article was written in 2000. Because of rapid developments in IS security, some parts of their work are now outdated.

Information Systems Security Design Methods: Implications for Information Systems Development (Baskerville 1993) (Baskerville 1993) compares the development of IS security analysis approaches with the development of IS development approaches by creating a framework which classifies approaches from both fields. The framework consists of three classes, which he labels generations. He classifies IS security analysis approaches chronologically and within the three generations he distinguishes between further approaches. Baskerville’s work includes the classes Checklists and Risk Analysis Approaches. Cost-benefit analysis is suggested as a method to measure the economic aspects of security controls. However, the work does not cover IS security management approaches or the legal issues which affect IS security. Summary: x

Baskerville focuses on a systematization of IS security analysis and IS system development approaches. The topic is very similar to the work this section presents with the exception of covering system development approaches.

x

Baskerville suggests a framework with three classes. The security analysis approaches are mapped to a corresponding generation class, based on their time of dominance. This chronological framework may not be a practical resource for good decision support.

x

Baskerville does not consider IT security management approaches nor the legal issues that affect IS security.

x

Baskerville mentions cost-benefit analysis as a possibility for IS security assessment. This thesis proposes that there are many other approaches that could be useful for this purpose.

x

Baskerville’s article was published in 1993 and as such it is the oldest of the articles analyzed in this thesis.

4.3 Existing Literature Reviews

91

Kompass der IT-Sicherheitsstandards - Leitfaden und Nachschlagewerk (IT Security Compass & Encyclopedia) (BITKOM 2006) BITKOM is a federation of German IT (information technology), IS & IT-services industry organizations. As such it has worked on guidelines to provide companies with an overview of IS security standards and support them in the selection of relevant standards. The purpose of this article is similar to the other articles reviewed and to this thesis, but the topics are different. For example, (BITKOM 2006) considers Standards, Best Practice Models, and Legislation Accommodations, among others. Other standards that do not incorporate IS security analysis and assessment are also examined in the article. These include, for example, standards on physical security or cryptography. The article does not distinguish between standards and best practice models and introduces only a selection of standards in each class. An important security management standard, NIST SP-800-30 (Stoneburner/Goguen/Feringa 2002b), is not addressed. A discussion on the impact of important legislation such as HIPAA (Department of Health and Human Services 2005) is not provided. The next section introduces the developed classification scheme and provides detailed descriptions of the identified classes of IS security approaches. 4.4

Theoretical Background

A central question of any review of IS security literature is how to construct a classification scheme for existing IS security approaches (Siponen 2005a). Through the literature review various publications were found that classify information systems security methods (Dhillon/Backhouse 2001; Siponen 2005a; Eloff/von Solms 2000; Baskerville 1993; BITKOM 2006). A major difference between these classification schemes and the framework proposed in this thesis is that the former concern the methods for developing secure systems, while this thesis focuses on methods for conducting security analyses and assessments of information systems. The classification system proposed in this thesis resulted from an iterative process involving the study of security topics in the IS field, analysis of prior work, as well as both the refinement and incorporation of the elimination of the redundancy that arose due to the oftentimes confusing terminology (Eloff/von Solms 2000). The derived classification scheme aids the selection of IS security approaches, approaches which will later serve as a basis for the design of the HatSec security analysis method. With the developed classification of IS security analysis approaches the scopes of the different approaches are identified. This identification helps to select IS security approaches. The approaches are then analyzed to determine their suitability for healthcare information systems.

92


(Siponen/Willison 2007) perceived that “while there is no doubt that (existing IS security literature reviews) have provided a number of important findings for IS security research and practice, they have certain limitations”. The advantages of the classification scheme presented here are that current IS security analysis approaches can be identified, compared, and assigned into one of the developed classes. The literature review is organized around an integrative framework that explicitly identifies the unique and unambiguous classes (as proposed in (Nosofsky/Clark/Shin 1989)) of IS security analysis and assessment approaches. Consequently every approach related to IS security analysis can clearly be classified and identified within the proposed framework. When writing about a proposed framework or classification as a form of theory in IS, three main criteria must be met: (1) the framework must be identified; (2) relationships among the constructs in the framework must be specified; and (3) these relationships must be falsifiable (Gregor 2006). First, the results of the literature review suggested five main classes: Checklists, Assessment Approaches, Risk Analysis Approaches, IT Security Management Approaches, and Legislation Accommodations. All IS security analysis and assessment approaches can consequently be classified into one of these five classes. Secondly, most of the identified IS security analysis and assessment approaches provide only parts of an IS security analysis or provide only a method for IS security analysis. This information influenced the considerations made in this thesis for introducing a classification which distinguishes between the classes which contain IS security approaches that are based on or contain either none, one or several approaches from preceded classes in this framework. There are three different kinds of classes. Classes that contain approaches providing parts of a security analysis, classes that contain IS security analysis approaches and classes that contain approaches which provide more than a security analysis. Hence, methods from some classes can be part of methods from other classes. Third, as already described above, this framework focuses on the structural nature of the IS security analysis approaches that are defined parts of IS security management. Combinations of these facts lead to the five types of IS security analysis approaches. The distinguishing features of each class are shown in Table 11 and will be explained in the following section. The next section describes the conducted systematization of IS security analysis approaches in detail, by providing examples for every identified class.

4.4 Theoretical Background Class

93 Distinguishing Attributes

Checklists

Checklists cover part of a security analysis. No causal relationships to other classes.


Assessment approaches cover parts of a security analysis. No causal relationships to other classes.


Risk analysis methods may consist of an assessment method and / or a checklist.


IT security management approaches can include several methods from the first three classes.


Legislation accommodations have an exceptional position. Compliance with regulations can be achieved by applying one or more approaches of the other classes. But legislation accommodations don’t contain approaches of the other classes.

Table 11: The Framework of IS Security Analysis Approaches (Source: own Table)

4.5

Systematization of IS Security Analysis Approaches

This section examines the following research questions (section 1.2): 2.1.

What is the state of the art in IS security analysis approaches?

2.2.

What are the different foci of the examined IS security analysis approaches?

This section aims to provide a comprehensive overview of IS security analysis approaches. In order to achieve this goal the works described in the section “Existing Literature Reviews” were consolidated. By consolidating examples from the previously discussed works and identifying IS security analysis approaches discussed in recent publications this thesis used five categories (unambiguous classes) of IS security analysis approaches: Checklists, Assessment Approaches, Risk Analysis Approaches, IT Security Management Approaches, and Legislation Accommodations. These classes represent the scopes, foci and comprehension of the relevant IS security analysis approaches. Because the goal of this thesis is to design a healthcare-specific IS security analysis method. Not all of the IS security approaches from the identified classes will later be analyzed to determine their suitability in healthcare. The structure of the classification developed for this thesis is based on the principles of grounded theory (Bennet 1991). As proposed by (Glaser/Strauss 1967) this thesis sought possible classification classes from the ground up. First categories of occurrences and examples with common characteristics were identified and coded into as many classes as possible; second the attributes of each category were identified through constant comparison between oc-

94


currences and categories, so as to consolidate the classes; third the number of categories were

X

(Eloff/von Solms 2000) (BITKOM 2006) (Baskerville 1993)

X

No particular consideration of IS Security Assessment Approaches

O

O

X

O



(Dhillon/Torkzadeh 2006)

X


(Siponen 2005b)


Author

Checklists

reduced to a minimal set, i.e. no more occurrences were used than were needed to account for the distinguished classes; and finally the classification was used in a plausible representation of studied IS security analysis approaches.

O

X

X

X

X

Legend: X means that the author uses the same name as in this thesis. O means that the class can be found under a different name in the work of the respective author.

Table 12: Systematization of Other Scientific Articles (Source: own Table)

All approaches in one class have the same ideas or goals in respect to IS security analysis. Table 12 reiterates the connections between the systematization suggested in this thesis and the scientific works described above12. Figure 15 shows the identified classes of the systematization. The classes Assessment Approaches, Risk Analysis Approaches, and IT Security Management Approaches are further subdivided in subclasses. For each class a representative method was chosen. These methods are the most important representatives of their respective classes because they are the most commonly used or best known.

12

Not all of the examined approaches can be called security analysis methods. But because this thesis aims to be comprehensive, this section examined both approaches that provide more than a security analysis and approaches thatprovide onlyparts of a security analysis are covered.

4.5 Systematization of IS Security Analysis Approaches

95

IS Security Analysis Approaches

Checklists

SAFE AFIPS


Risk Assessment Approaches

Computer Security Handbook

Questioning Techniques Expert Interviews Stochastic Methods VaR Indicator Approaches


Security Control Assessment Approaches Financial Ratios ROSI Static Investment Appraisal Approaches Cost Comparison Method

Key Indicator Appraches

Dynamic Investment Appraisal Approaches

Causal Methods

Net Present Value Method

Bayesian Networks

Stochastic Decision Analysis Approaches

Classic Approaches


Standards


Best Practice Models

Basel II KonTraG

CRAMM ISRAM Processoriented Approaches Tree-based Approaches Attack Trees

SOX IT-Grundschutzhandbuch

CobiT

HIPAA

ITIL

NIST SP-800-30 ISO/IEC 2700x CISSP

Gorden/Loeb 2002 Game Theory Approaches Cavusoglu et al. 2004 Real Options Theory Approaches Daneva 2006

Caption: Approach provides parts of a security analysis

Class

IT security analysis approach

Class

Approach provides more than a security analysis

Class

Approaches from class A can contain none, one or several approaches from class B and/or class C

Method of a class

A B C Method

Figure 15: Systematization of IS Security Analysis Approaches (Source: according to (Sunyaev et al. 2009e))

4.5.1

Checklists

Checklists are based on the idea that IS security solutions and procedures can be examined and written down in a list: a checklist. Checklists are very popular in practice (Dhillon/Backhouse 2001). The focus is to identify all conceivable threats to an IS system and proposes solutions that would help in overcoming the threats (Dhillon/Torkzadeh 2006). According to

96


Baskerville the idea of checklists is to ask “[…] ‘what can be done’ rather than ‘what needs to be done.’“ (Baskerville 1993). One popular approach of this class is the baseline approach. With this approach it is possible to check if the implemented controls are sufficient to satisfy certain minimum requirements. Baseline approaches are often used in IT security management approaches like the BSI-Grundschutzhandbuch (Bundesamt für Sicherheit in der Informationstechnik 1992). The BSI-Grundschutzhandbuch consists of IT security guidelines provided by the Federal Office for Information Security in Germany. IT security management approaches are introduced in the section “IT security management approaches”. Examples for checklists are: the American Federation of Information Processing Societies (AFIPS) Checklist (Patrick 1979), Security audit and field evaluation for computer facilities and information systems (SAFE) (Krauss 1972), Computer Security Handbook (Hoyt 1973) and IBM’s 88point security assessment questionnaire (IBM 1972). 4.5.2


In contrast to checklists, assessment approaches, qualitatively or quantitatively, assess risks and security controls. Many methods can be found from different research areas. In order to enhance clarity, the assessment approaches are subdivided into two classes. One class contains approaches aimed at assessing risk. The other class contains approaches aimed at assessing security controls. 4.5.2.1 Risk Assessment Approaches There are almost no risk assessment approaches that were explicitly developed for assessing IS risks (Prokein 2005). During the course of Basel II, the Basel Committee on Banking Supervision commits itself to the definition of operational risk and its regulatory capital treatment. There are several scientific articles that demonstrate that IS risks are a subset of operational risks, defined by the Basel Committee on Banking Supervision. Hence, it makes sense to apply the existing methods, assessing operational risks to IS risks. The methods to quantify operational risk can be systemized in different ways. The systematization used in this chapter differentiates the assessment approaches according to the models and theories they are based on. Thus, (Faisst/Kovacs 2003) classify the approaches to assess risk into the four classes: Questioning Techniques, Stochastic Methods, Indicator Approaches and Causal Methods. Representatives of each class always have the same or very similar characteristics. The class Questioning Techniques contains all methods that use subjective estimation of people to assess risks. For example people are not only questioned about possible weaknesses and threats, but also asked to estimate the probability of their occurrence and the extent of poten-


97

tial damage. Questioning techniques include, for example, expert interviews or self-assessments by the responsible employees13. With Stochastic Methods the assessment is based on established methods from statistics and actuarial mathematics. The aim of these methods is to model loss distribution on the basis of historical data on potential loss due to IS risks. This should help to draw conclusions about effective risk management for the future. The conclusions are used to calculate the Value-atRisk (VaR). The assumption in doing so is that it is possible to make a prediction about the future risk, on the basis of the loss distribution of historical data, because it is assumed that the structure of the risks doesn’t change considerably over time (Hechenblaikner 2006). Marshall defines the VaR as follows: „Simply stated, it is the expected maximum loss of some portfolio during some time period at some predefined level of confidence.” (Marshall 2001). In general the VaR expresses the potential loss in monetary terms, which during a certain time period and with a predefined probability (also called confidence level) will not be overspent. The VaR is determined by several parameters. These are the considered time horizon, the confidence level and the assumed probability that represents the future losses. The different stochastic- and actuarial methods for the assessment of operational risk vary in just these parameters. Their most popular representatives are the Loss Distribution Approach suggested from the Basel Committee on Banking Supervision, the Operation Value-at-Risk (OpVaR) and the Extreme Value Theory. Indicator Approaches try to determine the existing risk on the basis of a certain indicator (single indicator approaches) or an indicator system (key indicator approaches). Risk indicators in this context represent parameters that should be directly measurable, and show the existence of not directly ascertainable phenomena. For example indicators are used, when a phenolmenon, like IS risk, cannot be measured directly. On the basis of empirical analysis or expert opinions, indicators are chosen, for which a correlation with IS risks is assumed. A risk indicator can be the age of an IT system, for instance. The assumed correlation then might be that the older the hardware, the higher the risk of a technical failure. Widely-used single indicator approaches include the Basic Indicator Approach, the Standard Approach and the Internal Measurement Approach (Basel Committee on Banking Supervision 2001, 2003). The Basel Committee on Banking Supervision recommends all three approaches. Another popular approach is the Capital Asset Pricing Model (Beeck/Kaiser 2000).

13

A detailed description of Questioning Techniques can be found in (Marshall 2001).

98


The key indicator approaches consider a set of specific indicators. The different key indicator approaches basically differ in the types of the used indicators. An integrative categorization by the indicator type does not exist, yet (Hechenblaikner 2006). One approach of this class worth mentioning is the Scorecard Approach, recommended by the Basel Committee on Banking Supervision under the headline Advanced Measurement Approaches (Basel Committee on Banking Supervision 2001). Operational risks are threats which by definition are caused by persons, systems, inadequate or false processes as well as external events (Basel Committee on Banking Supervision 2003). All of these threats, called super classes of IS risk, combine several risks of subclasses. These are connected through functional and causal dependencies. Causal Methods focus on the modeling of the cause-effect-correlations of IS risks. Instruments for this approach are modeling techniques from physics, mathematics and computer science, which are already used and established in these fields for the design of processes and systems. Popular methods are Neural Networks (Cruz 2002), the Delta Method (King 2001) and the Bayesian Networks (Alexander 2003). 4.5.2.2 Security Control Assessment Approaches Fear, uncertainty, and doubt (FUD) strategy has been used for years to sell investments in security solutions (Cavusoglu/Mishra/Raghunathan 2004). Different factors like the increasing networking of computers, the rising rate of cyber crime and the growing importance of digital data is forcing companies to devote more resources to IS security. For this reason companies are becoming increasingly interested in analyzing and assessing the economic aspects of investments in security controls. However, the largest body of research related to prevention of security breaches is technical and focuses on such issues as encryption and access control (Su 2006). In contrast, the research related to the economic aspects of IS security is small but rapidly growing (Gordon/Loeb 2002). By examining a multitude of approaches for the economic assessment of security controls from different research areas, six disjoint classes could be identified14. The approaches to assess security controls can hence be sub classified in financial ratios, static investment appraisal approaches, dynamic investment appraisal approaches, stochastic decision analysis approaches, game theory approaches and real options theory approaches. In finance, a financial ratio is a ratio of selected values on an enterprise's financial statements (Wöhe 2005). A financial ratio, often used in practice, is Return on Investment (ROI). ROI puts the profit of an investment in relation to the fixed capital. For the purposes of IS security, 14

The systematization is based on (Su 2006), (Perridon/Steiner 2007), (Dinkelbach/Kleine 1996) and (Wöhe 2005).


99

a modified ROI was developed which is called Return on Security Investment (ROSI). There are different methods to calculate ROSI. For example (Sonnenreich/Albanese/Stout 2006) defines ROSI as follows: ROSI

Risk _ Exposure * Risk _ Mitigated Solution _ Cost Solution _ Cost

An overview of the different methods to calculate ROSI is provided by (Schneider 2006). Another suggestion of a ratio to evaluate investments in IS security is given by (Purser 2004). Purser extends ROI by adding a new value in the formula, which is the amount of change in risk due to the security control. Purser calls this new ratio the Total Return on Investment (TROI). The TROI does not considerably differ from other ROSI methods. Hence, it can be seen as another method to calculate ROSI. Static investment appraisal approaches focus on optimizing investment decisions. To know which of several alternative investments I 1,2,..n is the most beneficial. Static approaches only examine one period. This is why the costs for the data collection are low. However, for the same reason the quality of the results must be view critically (Wöhe 2005). Wöhe distinguishes four static approaches Cost Comparison Method, Profit Comparison Method, Average Return Method and Payback Period Method. The adaptability of these methods to IS security investment decisions depends on the ability to determine the parameters necessary for each method. The parameters of the static investment approaches are costs, benefits and payments. The dynamic investment appraisal approaches have in principle the same goal as the static approaches: they want to make a statement about the benefits of an upcoming investment decision. The difference to the static approaches is that dynamic approaches analyze and evaluate the financial impacts of an investment over the entire investment period. The costs for data collection are correspondingly higher. On the other side the quality of the results are higher. The two most popular dynamic approaches are the Net Present Value Method and the Internal Rate of Return Method (Wöhe 2005). A decision analysis model consists of a set of alternatives, one or more objective functions and a maximization goal (Dinkelbach/Kleine 1996). Because the incidence and the potential of the risks cannot be determined ex ante, but are modeled with probabilities, the decision analysis models are termed stochastic (Wöhe 2005). There are several works in literature that pursue this approach. (Gordon/Loeb 2002) provide an economic modeling framework for assessing the optimal amount to invest in information security based on the principle of equating the marginal financial benefits of information security to the marginal financial costs of

100


such security. (Hoo 2000) provides a framework to evaluate different policies for IS security. He defines policy as a group of security controls. (Longstaff et al. 2000) propose their Hierarchical Holographic Model (HHM) to assess security controls. (Bodin/Gordon/Loeb 2005) propose to use the Analytic Hierarchy Process (AHP) for assisting an organization in making information security investment decisions. (Butler 2002) proposes a cost benefit analysis method called SAEM (Security Attribute Evaluation Method) to compare alternative security designs. He defines security design as a mixture of technical security controls. (Cavusoglu/Mishra/Raghunathan 2004) argue that the stochastic decision analysis approaches for evaluating IS security investments, though intuitive, treats security technology as a black box and do not take into account that the context of IS security is different from other general IS investment context. They argue that in security, organizations are dealing with strategic adversaries who are looking for opportunities to exploit vulnerabilities in systems. Therefore IS security can be treated as a kind of game between organizations and attackers. Game theory is used to analyze problems in which the payoffs to players depend on the interaction between players’ strategies. In the security investment problem, the firm’s payoff from security investment depends on the extent of hacking it is subjected to. The hacker’s payoff from hiking depends on the likelihood of being caught. Based on the above idea, (Cavusoglu/Mishra/Raghunathan 2004) use a game theory based approach to determine the optimal IS security investment level. Along the same lines is the work of (Cremonini/Martini 2005). They propose an approach to improve ROI-based evaluation by integrating them with a new index, called Return-On-Attacks (ROA), aimed at measuring the convenience of attacks15. Real options analysis was first developed as a decision support technique in the area of capital investment. The name resulted from the parallels to financial options (Perridon/Steiner 2007). Since 1999, most notably through Amram and Kulatilaka, this concept has found its way into the area of appraising IS investments (e.g., by (Amram/Kulatilaka 1999) and (Benaroch 2002)). (Daneva 2006) proposes a real options-based decision framework for information security. She identifies a number of options and argues that these options embed flexibility in the decision making process. There are attempts to use real options to evaluate IS security controls. (Gordon/Loeb/Lucyshyn 2003) explain why a significant portion of security expenditures are made on a wait-and-see basis. They argue that one key driver of actual expenditures on information security activities is the occurrence of actual security breaches. They further explain that this reactive, as opposed to proactive, approach toward a significant portion

15

A detailed description of these two approaches is not included in this thesis, because that would go beyond its scope. The approaches are explained in detail in (Cavusoglu/Mishra/Raghunathan 2004) and (Cremonini/Martini 2005).


101

of information security expenditure is consistent with the real options view of capital investments (Su 2006). 4.5.3


The purpose of a risk analysis is to analyze the security of the IT infrastructure, to compare it with the security goals and to draw consequences from any discrepancies (Rechenberg/Pomberger 2002). There are a vast number of risk analysis approaches. According to Kokolakis et al. there are already more than 100 commercial approaches (Kokolakis/Demopoulos/Kiountouzis 2000). Hence, a presentation of all approaches is not possible. However, many approaches are very similar, so they can be grouped in classes. (LeVeque 2006) describe these three classes as: Classic, Process-Oriented and Tree-Based Approaches. In literature one can find the terms security risk analysis, information security risk analysis and IT risk analysis 16. Because there is no difference in these approaches, in this thesis, only the term risk analysis is used. Classic risk analysis approaches follow five steps: asset identification and valuation, threats assessment, risk assessment, analyzing of potential security controls and implementation of appropriate security controls to keep the risk at a minimum level (Laudon/Laudon/Schoder 2006). The different approaches only vary in the order and the naming of these steps. Natal of the steps are always passed. It is also possible that a method contains only a few of the steps mentioned above. Prevalent classic risk analysis approaches are the Information Security Risk Analysis Method (ISRAM) (Karabacaka/Sogukpinar 2005), CRAMM17, the Operationally Critical Threat, Asset and Vulnerability Evaluation Method (OCTAVE) (Alberts et al. 2003), FIPS 65 (National Bureau of Standards 1979), CORAS (Fredriksen et al. 2002) and the Organizational DEScriptive security analysis method (ODESSA) (Warren/Furnell/Sanders 1997). The process-oriented approaches extend the classic approaches by adding the factor time. These approaches consider that different controls can be useful in different steps of an attack. Process-oriented approaches reduce the number of many-to-many relationships by dividing the relations between threats, vulnerabilities and risks in a sequence of events. In spite of the advantages of the process-oriented approaches, few examples of methods of this class could be found. Even (LeVeque 2006), who suggested this class, mentioned only one concrete method. 16

17

For example, Voster et al. call some of the methods mentioned above security risk analysis methods (Vorster/Labuschagne 2001), while Karabacaka et al. call the same methods risk analysis methods (Karabacaka/Sogukpinar 2005). CRAMM stands for CCTA’s Risk Analysis and Management Methodology. The U.K. Government Central Computer and Telecommunications Agency (CCTA) set this method as standard risk analysis approach for all authorities in Great Britain. Cp. (Baskerville 1993).

102


Tree-based approaches extend classic approaches by providing a two-dimensional perspective on several elements of an attack. There are different tree-based approaches. All are based on the fault trees (LeVeque 2006). A typical fault tree has a root node, which represents a fault. The causes of the faults provide the basis. These individual faults are combined with Boolean algebra. Other tree-based approaches are threat trees, event trees and attack trees. 4.5.4


In order to reduce the total expenditure for IS security, very often IT security management approaches that support security officers with methodology and content are used. However, these approaches contain more than the risk assessment or security controls. Scholars address the definition of security strategies and - policies, the evaluation of security risk, the determination of security goals, the derivation of security requirements, the selection of appropriate security controls and the implementation of these controls (BITKOM 2006). Because the goal of this section is to identify IS security analysis methods, the focus of the analysis of the IT security management approaches is on that aspect. The terms standard, guideline and best practice model are often used in the context of IT security management. Very often these terms are used synonymously, often correctly. Because of this, in the following section these terms are clearly defined. An overview of these and other terms from the IS security field is provided by (Eloff/von Solms 2000). They use the definition provided by (Oppliger 1996), who defines standards as „[…] documented agreements containing exact criteria that must be followed consistently as rules, guidelines or definitions of characteristics to ensure that any materials, products, processes or services are fit for their purpose.”. In this definition, standards can consist of one or more guidelines. Further they define guidelines as „[…] a set of recommended actions or policy statements that can be performed or adhered to in order to achieve a specific objective.” (Eloff/von Solms 2000). Thus guidelines explain how to implement standards. Best practice models 18 „[…] describe a set of detailed issues, which should be addressed to achieve a specific objective or objectives.” (Eloff/von Solms 2000). Best practice models are experiences of many years, which proved of value and then were written down and published. For instance “a password should consist of at least eight characters.” Guidelines and best practices are in some ways synonymous with one another. The main difference is that best practice models are based solely on practical experiences, whilst guidelines may not necessarily have been previously iniated (Eloff/von Solms 2000). Because this difference is unimportant for this work and the term Best Practice Model was found more often in literature, Best Practice Model will be used in the rest of this 18

Eloff and von Solms call these approaches ‚Code of Practice‘, which is considered as the same in this thesis. Cp.(Eloff/von Solms 2000).


103

thesis for both approaches. Hence, IT security management approaches can be subdivided in the two classes Standards and Best Practice Models. Standard

Assessment Approach/Checklist

IT-Sicherheitshandbuch

Questioning Techniques

IT-Grundschutzhandbuch

Baseline Approach

NIST SP-800-30

Expert Estimations, Self-Assessments, Baseline Approach, Static Investment Appraisal Approaches

ISO/IEC 27000

none

ISO/IEC 27001

none

ISO/IEC 27002

See ISO/IEC 17799

ISO/IEC 27004

Key Indicator Approach

ISO/IEC 17799

Baseline Approach, Doesn’t contain an assessment approach, but refers to ISO/IEC 13335

ISO/IEC 13335

Baseline Approach and Risk Analysis, Risk Assessment with Questioning Techniques

Table 13: Assessment Approaches/Checklists suggested by Standards (Source: own Table)

Because of the complexity of IS and the demand for certification, numerous standards in the area of IS security have been created in the last years (Bundesamt für Sicherheit in der Informationstechnik 2005). There are several committees worldwide that are concerned with the development of standards in security management (Müller 2006). Eloff and von Solms distinguish between international, national and organizational standards (Eloff/von Solms 2000). International standards include, for example, the IT-Sicherheitshandbuch and the IT-Grundschutzhandbuch of the German Bundesamt für Sicherheit in der Informationstechnik (BSI), NIST SP800-3019 and the standards of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). These standards were examined to see if they contain recommendations for assessment approaches in IS security. The results are presented in Table 13. These standards apply to Information Security Management Systems (ISMS). These systems are used to implement and maintain IS security in organizations by coordinating various activities, processes, and tools. Every ISMS contains two levels, a System-level and a Process-level as shown in Figure 16. According to (BSI 2004), the Process-level contains several sub-processes such as development, planning, implementation, evaluation, and maintenance of IS security. The System19

The Standard was published by the National Institute of Standards and Technology (NIST).

104


level in contrast is concerned with the orchestration of the Process-level’s tasks. It contains matters such as organizational structure, responsibilities, processes and resources.

Figure 16: Levels of an Information Security Management System (Source: according to (Huber/Sunyaev/Krcmar 2008a))

4.5.4.1 The Plan-Do-Check-Act Approach of ISO 27001 One of the most important standards of the ISO 2700x family is the 27001 standard, which emerged from the British Standard 7799-2 (British Standards Institution 1999). In this standard fundamental processes to plan, establish, operate and maintain information security in organizations are described in detail. The main framework to achieve these goals is represented by the Plan-Do-Check-Act approach (PDCA). The developed HatSec method integrates PDCA methodology. The PDCA approach, as shown in Figure 17, contains four steps, which are executed repeatedly.

Establish the ISMS

Implement and operate the ISMS

1. Plan

2. Do

4. Act

3. Check

Maintain and improve the ISMS

Monitor and review the ISMS

Figure 17: The Plan-Do-Check-Act approach (PDCA) (Source: according to (British Standards Institution 1999))

In the first step of PDCA, an ISMS policy has to be established. Therefore, objectives, processes and procedures have to be set up in accordance with an organization’s objectives and policies. These are essential for managing risk and improving information security.


105

In a second step, the ISMS policy has to be implemented and operated. Therefore, the controls, processes and procedures set up in the first step are to be implemented. The third step measures the effectiveness and performance of the ISMS. The results are then reported to the management for review. During the fourth step, corrective and preventive actions based on the results of step three and a review of further additional information are undertaken. 4.5.4.2 Best Practice Models Two worldwide accepted and applied best practice models are the Control Objectives for Information and related Technology (CobiT) and the IT Infrastructure Library (ITIL). The focus of these models is the achievement of company goals by improving the control system (CobiT) and introducing processes (ITIL). The models were checked to see if they contain recommendations for assessment approaches in IT security. Table 14 shows the results. Best Practice Model

Assessment Approach/Checklist

CobiT

All Assessment Approaches possible (rating with maturity model)

ITIL

Refers to ISO/IEC 17799

Table 14: Assessment Approaches/Checklist of Best Practice Models (Source: own Table)

In this section, only the most popular ones were examined. Additional standards include, for example: x

ISO/IEC 18028.

x

ISO/IEC TR 18044 (Swanson et al. 2003).

x

ISO/IEC 18043 (Swanson et al. 2003).

x

ISO/IEC TR 15947 (Swanson et al. 2003).

x

NIST SP 800-37 (Swanson et al. 2003).

x

NIST SP-800-55 (Swanson et al. 2003).

x

ISF’s Standard of Good Practice (Information Security Forum (ISF) 2005).

x

Statement on Auditing Standards (SAS) No. 70 (American Institute of Certified Public Accountants 2007).

106

4 Analysis of IS Security Analysis Approaches x

Baselinemethode (Swiss Infosec AG) (Estermann 2004).

x

The Grundschutz-Verfahren (BFI) (Holthaus 2000).

Further best practice models are for instance: x

IDW PS 330 (Eschweiler/Psille 2006).

x

Microsoft Operations Framework (MOF) (Poore 1999).

x

Generally Accepted System Security Principles (GASSP) (Poore 1999).

x

Generally Accepted Information Security Principles (GAISP) (Information Systems Security Association 2003).

x

BSG ITSEC-Methodik (Baer/Zängerle 2000).

x

Code of Practice (CoP) (Solms 1998).

x

Méthode d’Analyze des Risques Informatiques et d’Optimisation par Niveau (Marion) (Solms 1998).

x

Task Force Sicheres Internet (Initiative D21 2001).

x

Committee of Sponsoring Organizations of the Treadway Commission (COSO) (Committee of Sponsoring Organizations of the Treadway Commission 2005).

4.5.5


In recent years, numerous legislations have been enacted in the USA and Europe, which place direct obligations and liabilities on the management of IS security (Laudon/Laudon/Schoder 2006). The legislations affect a broad range of industries, ranging from finance to healthcare (Moore 2004). Important examples of such legislation include: Basel II, the Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG), the Sarbanes-Oxley Act (SOX) and the Health Insurance Portability and Accountability Act (HIPAA (Aikins 2000)). This section examined whether or not the legislations impose or suggest concrete IT security management approaches, risk analysis approaches, or assessment approaches. Table 15 shows the results of this examination.


107

Legislation

Mandatory

Recommended

Basel II

One of the following: Basic Indicator Approach Standard Approach Internal Measurement Approach Loss Distribution Approach Scorecard Approach

BSI-Grundschutzhandbuch

KonTrag

none

Indicator Approach BSI-Grundschutzhandbuch

SOX

None

CobiT ITIL BSI-Grundschutzhandbuch ISO 17799 VaR Indicator Approach

HIPAA

Baseline Approach NIST SP-800-30

CRAMM

Table 15: Mandatory and Recommended Implementation of Legislative Guidelines (Source: own Table)

Examples of additional legislation include the Bundesdatenschutzgesetzes (BDSG), the Telekommunikationsgesetz (TkG), the Gramm-Leach Bliley Act (GLBA), the Family Educational Rights and Privacy Act, the Federal Deposit Insurance Corporation Improvement Act, the Emittenten-Compliance Verordnung, the Mindestanforderungen an das Risikomanagement (MaRisk) and the Capital Adequacy Requirements for insurance industry (Solvency II). Checklists and assessment approaches only cover parts of a security analysis. Methods from these two classes can also be part of methods from other classes. For example a risk analysis method may consist of an assessment method and a checklist. In the same manner, IT security management approaches can include several methods from the other three classes. Legislation accommodations have an exceptional position. Compliance with regulations can be achieved by applying one or more approaches of the other classes. But legislation accommodations do not contain approaches of the other classes. Table 16 illustrates the number of the methods found in each class.

108

4 Analysis of IS Security Analysis Approaches > 100

50

Found Methods

40 33

32

30 20 12 10

5

0 Checklists




Legislations

Table 16: Identified Methods per Class (Source: own Figure)

The next section provides an overview of the analysis of selected IS security approaches according to their suitability for the healthcare sector. The selected IS security approaches are examined with help of the derived healthcare IS security characteristics (section 3.3). The conducted analysis later serves as a basis for the extraction of the method fragments needed to design the HatSec security analysis method. 4.6

Analysis of IS Security Analysis Approaches with Respect to Healthcare


What are the insufficiencies of existing IS security analysis approaches especially regarding their applicability in healthcare?

There are both academic and practical reasons for comparing methods (Avison/Fitzgerald 1995). The purpose of this thesis is to identify an adequate IS security analysis method in order to analyze the security issues of German healthcare telematics. Therefore this section provides a comprehensive comparison of IS security analysis approaches in the healthcare sector. To achieve this goal, 16 different IS security analysis methodologies are analyzed in detail. In order to identify selected IS security approach for the comparison, five categories of IS security analysis approaches currently receiving attention in literature were consolidated: Checklists, Assessment Approaches, Risk Analysis Approaches, IT Security Management Approaches, and Legislation Accommodations. All of the approaches in each class share the same ideas or goals in regards to IS security analysis. There are numerous security analysis methodologies available today, qualitative and quantitative (Vorster/Labuschagne 2001). The selection was guided by the criteria of well-known approaches used


109

in Europe, most of which were suggested by (Vorster/Labuschagne 2001; ENISA 2006; Initiative D21 2001; Beham 2004; Bornman/Labuschagne 2004; Brooks/Warren 2004) and (Eloff/von Solms 2000; ENISA 2006; BITKOM 2006). The next objective focused on internationally accepted IS security analysis approaches (e.g., ISO, the International Organization for Standardization). ISO supports worldwide standardization and requires the approval of at least 75 % of all involved national bodies (ISO/IEC 2005d) before granting the designation International Standard. The next criterion focused on the comprehensiveness of documentations of the identified approaches (comprehensive documentation according both to their availability and extensiveness and good description according to a structured methodology with sufficient available information on the internet). This criterion is needed in order to establish a detailed framework for comparison of the security analysis approaches. Finally IS security analysis approaches developed especially for healthcare were considered. During this research, 16 different information IS security methodologies were analyzed. The developed classification of IS security analysis approaches supported the identification of these 16 security analysis approaches. Table 17 summarizes the selected IS security analysis approaches and classifies them according to the developed framework. Classification

IS Security Analysis Approaches

Checklists

-


(Warren/Furnell/Sanders 1997)


(Alberts et al. 2003; CRAMM 2003; Karabacaka/Sogukpinar 2005)


(ISO/IEC TR 13335-3 1998; ISO/IEC 2005b, 2005c, 2005a; ISO 14971:2007 2007; Stoneburner/Goguen/Feringa 2002a; ISO/FDIS 27799:2007(E) 2007; JIPDEC 2004; Bundesamt für Sicherheit in der Informationstechnik 2004; Standards Australia International/Standards New Zealand 2001)


(Department of Health and Human Services 2005; Food and Drug Administration 2006)

Table 17: Reflected IS Security Analysis Approaches (Source: own Table)

Furthermore, the way in which each of these approaches procedure was reviewed in detail. The characteristics for the examination of the identified IS security analysis approaches were described in the catalogue of IS healthcare security characteristics (Chapter 3). In order to find adequate process-oriented IS security analysis methods for healthcare information systems this thesis focuses on the IS security approaches that are most relevant to healthcare. The underlying analysis of selected IS security approaches is rooted in the following related evaluations: (Vorster/Labuschagne 2001; ENISA 2006; BITKOM 2006; Initia-

110


tive D21 2001; Beham 2004; Bornman/Labuschagne 2004; Brooks/Warren 2004; Finne 1998) and (Eloff/Labuschagne/Badenhorst 2002). This chapter summarizes the complete examination of selected IS security methodologies according to the catalogue of IS healthcare security characteristics defined in section 3.3. 4.6.1

Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics

ISO/IEC 17799

ISO/DIS 14971

HIPAA

Odessa

FDA Guidance for Industry1 Q9 Quality Risk Management

CRAMM

NIST SP 800-30

ISMS JIPDEC for Medical Organizations

IT-Grund Schutzhandbuch

ISRAM

ISO/IEC 17799:2005 Second edition 2005-06-15

ISO/DIS 14971 Draft 2005

0

0

0

0

5

5

5

5

1

1

1

5

5

5

5

0 5

0 5

0 5

3 5

5 5

0 5

0 5

0 5

1 5

1 5

1 5

1 5

1 5

5 5

1 5

1 5

Research activity

0

0

5

0

5

0

0

0

1

1

1

5

1

5

1

1

Skills needed / Time and effort to introduce to use to maintain

5 5 5

5 5 5

5 5 5

5 5 5

5 5 5

5 5 5

5 5 5

5 5 5

5 5 1

5 5 1

5 5 5

5 5 1

5 5 1

5 5 5

5 1 1

5 5 1

Consultancy support

5

5

5

5

5

5

0

0

5

5

3

5

3

5

3

5

Legend:

2 – predominantly not covered 5 – covered

1 – not covered 4 – predominantly covered

2003

Draft 2007

Version 2.0

HB 174-2003

ISO/IEC 27004 ISO/IEC 2nd WD 27004 (2005)

0

Languages available German English

ISO 27799

ISO/IEC 27001 ISO/IEC 27001 First edition 2005-10-15

Available free of charge

Characteristics

Octave Method

ISO/IEC TR 13335-3

Current version

ISO/IEC TR 13335-3:1998

Table 18 examines the 16 selected IS security approaches regarding their fulfillment of “General IS Security Approach Characteristics”. This category describes basic information about the analyzed approaches. The examination personalizes the profiles of the analyzed IS security approaches and defines the skills needed to use them. It also provides information on the availability of the approaches, their maturity, and the languages in which they are available.

3 – partially covered

Table 18: Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics (Source: own Table)


111

The examination shows that most of the analyzed approaches are available in English. With the exception of standards provided by the ISO and the CRAMM approach, the analyzed IS security approaches are available for free and are easily accessible online. Some of the approaches are not going to be developed further for this reason no obvious research activity of the developer groups could be identified. The examination also revealed that most of the analyzed approaches assume the user has more than just a general understanding of the dependencies among specific IS security details and that they also require specific qualifications from users to perform a security analysis using these approaches. This fact implies a need for consultancy support during the implementation of these approaches. The characteristics security analysis approach names, vendor name, current version, and country of origin establish a relationship between the approaches and “General IS Security Characteristics”. These characteristics are present in all of the approaches. Finally one can conclude that all of selected approaches have a well-defined and comprehensive profile, due to the fact that they all fulfill the majority of the required general characteristics. 4.6.2

Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics with Reference to Healthcare

Table 19 displays the 16 selected IS security approaches according to their fulfillment of “General IS Security Approach Characteristics with Reference to Healthcare”. This category provides a better understanding of the specifics of the healthcare sector. Thus, the types of the analyzed approaches are clarified and such an awareness of the type is important because of possible violation of existing regulations or norms caused by the implementation of an unsuitable IS security approach, which could result in litigation and/or other serious consequences. Most of the examined approaches are internationally accepted standards (as defined in section 4.5), the rest are international legislation accommodations. This fact is based on the selection of the 16 IS security approaches: widely used, well-known and internationally accepted approaches were chosen. The characteristic geographic spread describes the degree of international relevance.



CRAMM 5 1 1 1

NIST SP 800-30

FDA Guidance for Industry1 Q9 Quality Risk Management 1 1 5 1

0 0 0 5 0 2 0 3 3

0 0 0 0 5 3 3 3 3

5 3 1 3 3

5 5 1 5 5

3 1 5 5

1 5 5 5

1 1 3 3

3 5 5 5

5 5 0 3

0 5 5 5

5 5 1 3

5 5 5 5

5 5 5 5

5 5 5 5

5 5 1 5

5 5 5 5

5 1 1

5 5 1 5

5 5

0 0

5 5

5 1

5 1

5 5

5 5

5 1

5 1

5 5

5

0

5

1

1

5

5

1

1

5

5 5 5 5

0 0 0 5

5 1 5 5

1 1 1 5

1 1 1 5

5 5 5 5

5 1 1 5

1 1 1 5

1 1 1 5

5 1 1 5

3

5

3

5

5

5

5

5

5

3

0

0

1

1

1

1

1

1

1

1

3 5 5 5 5 1 1 0 5

5 5 5 5 5 1 1 0 5

5 5 5 5 5 1 1 3 5

3 5 5 5 5 5 5 3 5

3 5 5 1 1 1 1 0 5

3

5 3 5 3 3 0 0 0 5

1 5 1 1

HB 174-2003

5 0 0 0 USA

ISRAM

5 0 0 0 UK

ISO 27799

Octave Method

Identification of the product method 0 0 0 0 0 0 standard 5 5 5 5 5 0 regulation 0 0 0 0 0 5 guideline 0 0 0 0 0 0 Country of origin USA Level of reference of the product national standardization body 0 0 0 0 0 0 European standardization body 0 0 0 0 0 0 international standardization body 5 5 5 5 5 0 private sector organization 0 0 0 0 0 0 public / government organization 0 0 0 0 0 5 Geographical spread 3 3 3 3 3 0 Lifecycle /- actuality 0 5 5 0 5 3 Fundamental objectives and product scope 3 3 3 3 3 3 Completeness 3 3 3 3 3 3 Level of detail Management level 5 5 5 5 5 5 Operational level 0 5 5 5 5 5 Organizational level 0 0 0 0 0 0 Scalability 5 5 5 5 3 5 Target organizations governments, agencies 0 5 5 5 5 5 large health organizations 0 0 0 0 5 5 small and medium size health organiza0 0 0 0 5 5 tions commercial health organizations 0 0 0 0 5 5 non-profit 0 0 0 0 5 5 specific sector 0 0 0 0 5 5 Security analysis 3 3 3 3 3 3 Supporting heterogenic, decentralized 5 5 0 5 0 3 information systems Process oriented evaluation method 0 0 0 0 0 0 Focus organizational 3 5 0 5 5 5 technical 3 0 3 5 0 Pro-active Security Analysis 5 5 0 5 5 5 Comparable and reusable results 5 5 0 5 5 3 Maturity level 5 5 0 5 5 3 Available tools 0 0 0 0 0 0 Certification scheme 3 3 5 3 3 3 Optimal investment sum 0 3 0 3 0 0 Organizational integration 5 5 0 5 5 5 Legend: 1 – not covered 2 – predominantly not covered 4 – predominantly covered 5 – covered

Odessa

HIPAA

ISO/DIS 14971

ISO/IEC 17799

ISO/IEC 27004

Characteristics

ISO/IEC 27001


ISO/IEC TR 13335-3

112

5 5

5

5 DE 5

5

5

5 5 5 3 5 5 5 5 5 3 5 5 5 5 5 0 1 5 0 3 3 0 0 3 5 5 5 3 – partially covered

5 1 1 3 3

3 5 3 3

5 3 3 1 3 0 5

Table 19: Examination of IS Security Approaches with Respect to General IS Security Approach Characteristics with Reference to Healthcare (Source: own Table)


113

The next characteristics of this category are security analysis, comparable and reusable results, pro-active security analysis, process oriented evaluation, and the focus. The applicability to these three characteristics ensures the existence of the required security analysis. The comparison showed that most of the approaches offer a security analysis, which is pro active, provides comparable and reusable results and focuses on the organizational risks, but only three of approaches offer a process-oriented evaluation. The process-oriented evaluation is the core of the healthcare requirements, because of German healthcare telematics (section 0), which comprises horizontally and vertically integrated healthcare processes. Only CRAMM, BSI 100-3 and CRISAM offer process oriented security analysis. 4.6.3

Examination of IS Security Approaches with Respect to Healthcare Specific IS Security Approach Characteristics

Table 20 examines the 16 selected IS security approaches according to their fulfillment of “Healthcare Specific IS Security Approach Characteristics”. This category considers healthcare specific requirements such as the importance of protecting patient health information. The specifics of this characteristics category are based on selected target audiences, such as: health consumers, healthcare providers, providers of healthcare funding, the State and the healthcare telematics infrastructure. Furthermore, the healthcare-specific IS security approach characteristics take the uniqueness of the medical environment into consideration. Critically, this classification group also takes into consideration specific laws concerning the security and privacy of health-related data.

ISO/IEC 27001

ISO/IEC 27004

ISO/IEC 17799

ISO/DIS 14971

HIPAA

Odessa

Octave Method

FDA Guidance for Industry1 Q9 Quality Risk Management

CRAMM

NIST SP 800-30

ISO 27799



ISRAM

HB 174-2003


ISO/IEC TR 13335-3

114

Branch Healthcare

0

0

0

0

5

5

5

2

5

1

1

5

5

1

1

5

Target audience in the healthcare branch health consumers healthcare providers health funders the state information repositories

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0

5 0 0 0 0

5 5 5 5 5

5 5 0 0 0

0 0 0 0 0

5 5 5 5 5

1 1 1 1 1

1 1 1 1 1

5 5 5 5 5

5 5 5 5 5

1 1 1 1 1

1 1 1 1 1

5 5 5 5 5

Compliance

0

0

0

0

5

5

0

2

5

1

1

5

5

1

1

5

Hazard list relevant to healthcare

0

0

0

0

0

3

2

0

1

1

1

1

1

1

1

1

Security requirements relevant to healthcare

0

0

0

0

2

3

3

0

3

1

1

3

3

1

1

1

Security measures relevant to healthcare

0

0

0

0

2

3

2

0

1

1

1

1

1

1

1

1

Risk valuation guidelines relevant to health

0

0

0

0

0

0

0

0

1

1

1

5

1

1

1

1

Security measures point of view IS security point of view patient’s point of view

5 0

5 0

0 0

5 0

5 5

5 5

5 5

5 0

5 5

5 1

5 1

5 5

5 5

5 1

5 1

5 5

Requirements for confidentiality, privacy, integrity and availability of information

5

5

0

5

5

5

5

5

5

5

5

5

5

5

5

5

Data quality requirements

0

0

0

0

0

3

0

0

1

1

1

3

1

1

1

1

Physical and environmental security

5

5

0

5

5

5

0

3

1

5

1

5

5

5

5

5

Characteristics

Legend:

1 – not covered 2 – predominantly not covered 4 – predominantly covered

3 – partially covered 5 – covered

Table 20: Examination of IS Security Approaches with Respect to Healthcare Specific IS Security Approach Characteristics (Source: own Table)

4.7

Summary

The literature review indicated that no single existing classification system of security analysis methods covers all currently used approaches. This chapter provided a classification scheme that includes current state-of-the-art of security analysis methods. The scheme gives a structured overview of current approaches and an understanding of the differences in their foci. This classification can therefore serve as a tool for security officers or IS security staff when making choices about suitable security analysis methods. This new classification is related to previous literature but is also more general and more able to capture the currently popular methods. The classification scheme is tree-structured and consists of five primary classes. Each class contains approaches with similar characteristics. The five main classes are: Checklists, Assessment Approaches, Risk Analysis Approaches, IT Security Management Approaches and Legislation Accommodations. In addition, these five classes are subdivided

4.7 Summary

115

into subclasses. Furthermore, this chapter explains the redundant terminology currently used in literature. Overall, this chapter analyzed current IS security approaches according to their suitability for the healthcare domain. The examination of the current IS security approaches highlights insufficiencies within current IS security analysis methods that lack the techniques to analyze technical and social aspects of information security in a healthcare environment and identifies a need for a IS security analysis method specified on healthcare environment. Table 23 clarifies that only (ISO/FDIS 27799:2007(E) 2007) and (Standards Australia International/Standards New Zealand 2001) fulfill the required characteristics in part. This result identified an existing demand for the development of a new healthcare IS security analysis method or the need to adapt existing IS security analysis methods for the current situation in healthcare. (Siau 1999) stated that “many of these methods lack theoretical foundations and empirical evidence to demonstrate their worthiness” and that there is “no one method [which] is suitable for all situations”. Current research shows that current security analysis methods lack the techniques to analyze not only technical but also, and especially, the social aspects of healthcare security (Brooks/Warren 2004). Furthermore, “little research has been conducted providing methods to control security policies effectively across a decentralized health IS” (Lüthi 2008). That is why the next chapter of this thesis describes a method engineering discipline in detail and uses the method engineering approach to construct an IS security analysis method specifically for healthcare, a method that focuses on both the technical and organizational aspects of IS security.

5

5.1

Designing a Security Analysis Method for Healthcare Telematics in Germany Introduction

The analysis of information systems demands a methodical approach in order to know which steps have to be taken in which order at which time in the analysis process (e.g., (Avison/Fitzgerald 1995; Braun et al. 2005; Iivari/Hirschheim 1996)). While in many cases a method and its included steps as a whole are the objects of research, this chapter in detail examines the fundamental parts and elements of methods as well as their interplay among each other and uses method engineering technique in order to design a security analysis method for healthcare telematics in Germany. The research subject is set in the discipline method engineering (Alderson et al. 1998). In this context the development of a formal description, which provides an overview of the method’s structure and its corresponding building blocks, shall be emphasized. The formalization of methods on the one hand helps explain existing methods and method parts. On the other hand it facilitates the transfer of methods to other application fields. Furthermore, the described methods become more transparent, traceable and understandable for both method users and its engineers (Fitzgerald 1996). (Siau/Rossi 2008) argue that right now the theoretical foundation during the method’s development process is almost nonexistent. They also decry the fact that empirical evidence is scant at best. Even though “both researchers and practitioners want a better appreciation of the characteristics as well as the strengths and weaknesses of methods in order to classify them, improve them, and enhance the information systems development (ISD) process” (Siau/Rossi 2008). Such knowledge would enable both method users and its engineers “to choose a method for a particular application, a specific development situation and an organization” (Siau/Rossi 2008). In this case, healthcare security analysis method is developed according to a formal method engineering process that is transparent, traceable and understandable because it is based on a theoretical foundation and designed for a particular application in healthcare telematics. The formal representation of the HatSec security analysis method enables automated (computer-assisted) application of the HatSec method. This creates the possibility for developing a tool to support the application of the HatSec method in the future. In comparison the identified, analyzed and introduced IS security approaches in this thesis, HatSec security analysis method is not only described in descriptive Text and thus can be easily redesigned and adapted to the situation at hand. Furthermore, the formal description of the HatSec method allows the user to modify and extend the HatSec method during the application, method fragments


118

5 Designing a Security Analysis Method for Healthcare Telematics in Germany

can be substituted or swapped, the scope of the HatSec method can thus be run on whole IS security analysis spectrum from process-oriented to technical issues. This chapter is organized as follows: Since this research is based on a comprehensive literature review of relevant journals and articles, section 5.2 overviews the research approach used. Section “Description of the Method Elements” describes the concept of method engineering and the existing building blocks and elements that can be used to build a method. Section “Formal Description of the Concept of Method Engineering” deals with the formalization of the concept of methods. The developed formalization of method engineering is used in section “HatSec Security Analysis Method” in order to develop a new information systems security analysis method specific to healthcare telematics on the basis of the requirements for such a method. These healthcare specific security analysis method characteristics were defined in section 3. Section “Review of the HatSec Security Analysis Method” provides the overview on the suitability of the developed HatSec method to the healthcare domain. The last section concludes this chapter and provides an outlook. Figure 18 illustrates the composition of the core elements of this chapter.


Design Elements and Constructs for a Security Analysis Method for Healthcare Telematics in Germany

5.3 Method Engineering Theory

Method Elements

Formal Description of the Concept of Method Engineering

5.6 HatSec Security Analysis Method

Implication

The derived Formal Description of Method Engineering is used as a Representation Technique for the Development and Presentation of HatSec as a Model Artifact with Re-Interpretation Possibilities of its syntactical Elements


5.2

Research Approach

In order to describe the concept of method engineering the description of IS method engineering approaches currently receiving attention in the literature is examined in detail. The literature review was based upon the approach by Webster and Watson (Webster/Watson 2002). A search was performed by spanning the IS engineering, information management, informa-

5.2 Research Approach

119

tion systems, method engineering, IS development and management literature20. After the identification of relevant journals, the appropriate articles were examined. After the identification of relevant journals the appropriate articles were examined. Accordingly, a search based on a full-text electronic search21 of selected keywords was carried out to identify relevant articles. By examining the title and abstract of each article, a total of 65 relevant articles were found. A further in-depth review resulted in the discovery of 17 articles that were relevant and of importance for this research (Table 21). Journal Accounting, Management & Information Technologies

Keywords 40

Abstract 1

In-depth Review 0

ACM Computing Surveys Communications of the ACM

3 7

1 5

1 0


41

1

1

European Journal of Information Systems Information Management & Consulting

87 1

4 1

0 0

Information and Software Technology

39

6

1

Information Systems

31

6

2

Information Systems Journal Information Systems Management

37 12

7 1

0 0

Information Systems Research

5

1

0

Information Technology & People

15

4

0

International Journal of Software Engineering and Knowledge Engineering

10

1

0

Knowledge-Based Systems MIS Quarterly

10 14

1 1

1 0

Total Journals Dissertations/ Master’s Theses/ Working paper

352 5

41 5

6 3


19

19

8

Total

376

65

17

Table 21: Analyzed Articles – Method Engineering (Source: according to (Sunyaev/Hansen/Krcmar 2008)

The next section provides an overview of method engineering.

20

21

All issues of the following journals were searched in an effort to include top journals in the selected disciplines: Accounting, Management & Information Technologies; ACM Computing Surveys;Computers & Security; European Journal of Information Systems; IM Information Management & Consulting; Information & Management; Information and Organization; Information and Software Technology; Information Systems; Information Systems Journal; Information Systems Management; International Journal of Information Management; International Journal of Communication Systems; MIS Quarterly; Journal of Management Information Systems; ACM Transactions Journals; IEEE Software; IEEE Transactions Journal; Information Systems Research; Information Technology & People; International Journal of Software Engineering and Knowledge Engineering; Knowledge-Based Systems. The following databases were used: Business Source Premier, Science direct, JSTOR archive, INSPEC.

120 5.3

5 Designing a Security Analysis Method for Healthcare Telematics in Germany Method Engineering


What are the principles of method construction?

Methods are the cornerstone of goal-oriented and tactical action in many application fields and different kinds of projects. The use of methods is essential for the development of information system because they support developers of IS by providing systematic development approaches (Avison/Fitzgerald 1995; Nilsen et al. 1992). However, the existence of development methods alone is not always a guarantee for success (Almendros Jimknez/Gonzalez Jimenez 2000). The environment in which companies operate is changing over time and forces the companies to conform their development work to the increasing complexity of IS (Fitzgerald 1997). In this context, the need for comprehensive methods that cover a wide range of situations within the development process is emphasized (Nilsson 1999; Karlsson/Wistrand 2006). It is, however, problematic to use the application of comprehensive IS development methods in specific situations or to adapt detailed and concrete methods to broader contents. Malouin und Landry (1983) recognized this problem early on and called this phenomena “The Mirage of Universal Methods in Systems Design”. Their article states that different development methods produce different hypotheses, assumptions and suppositions. It is unlikely that one standard method will suit all situations (Kumar/Welke 1992). These circumstances necessitate an adaptation of methods and their context to particular situations. This can be made possible by 1. a new development of a method if existing methods do not meet posed requirements, 2. a modification of a method (e.g., through incremental improvement or tailoring), 3. a re-use of parts of different methods with subsequent re-combination to a new method or 4. a combination of all previously mentioned actions. (Grundy/Venable 1996) declare that if necessary, a modification or adaptation of a method can even be implemented during the development process. The application of comprehensive IS development methods to specific situations as well as the application of detailed methods to a broad project context is problematic. Rather, methods have to be adapted to the situation

5.3 Method Engineering

121

at hand. This process is part of the discipline method engineering. (Brinkkemper 1996) defines method engineering as follows: „Method engineering is the engineering discipline to design, construct and adapt methods, techniques and tools for the development of information systems”. Formalization, a common practice in the computer sciences, are used to algorithms executable. The formalization of method engineering provides not only a traceable and transparent representation of engineering methods and fragments thereof, it also enables the assembly of engineering methods by offering basic construct rules. “To assemble method fragments into a meaningful method, we need a procedure and representation to model method fragments and impose some constraints or rules on method assembly processes” (Brinkkemper/Saeki/Harmsen 1998). Furthermore, due to the formalization of method engineering relationships between method fragments are represented according to the defined rules. This fact enables effective tool support on the basis of formally expressed method engineering rules. In the majority of cases a method consists of several parts, which divide the development process in manageable and ordered steps (Agerfalk et al. 2006). This division of methods in parts supports the clarity and eases the assignment of responsibilities. The following section will show and explain the basic concepts and elements related to methods. The next section describes the method elements needed to design a method in detail. Furthermore, the intersections between these elements are illustrated and explained. 5.4

Description of Method Elements

This section examines the following research question (section 1.2): 3.2. 5.4.1

What are the fundamental parts and elements of the methods?

Method Chains and Alliances

In some cases it can become necessary to connect methods and method parts respectively. This can be done with method chains and method alliances (Nilsson 1999). Nilsson defines method chains as the “integration of methods between different levels of development work22” (Nilsson 1999). This approach to combining methods is a kind of vertical integration. For example, there can be higher level dealing with conceptual modeling and lower level dealing with object modeling. The latter can in turn be used for database scheme 22

Nilsson distinguishes between strategic, process-oriented and system-oriented development (Nilsson 1999).

122


definition. Method alliances are method integration within the same abstraction level and thus can be called horizontal integration. Method alliances cover several aspects of problem domains or perspectives at a specific level. (Cronholm/Ågerfalk 1999) state that in their opinion Nilsson means method fragments (see next section) when he speaks of methods. This thesis subscribes to this view. 5.4.2

Method Fragments

Since a fragment is a detached, broken off, or an incomplete part of something (Oxford Online Dictionary 2007), (Harmsen/Brinkkemper/Oei 1994) call the building blocks of methods method fragments. These can be classified according to the dimensions perspective and granularity layer23 (Brinkkemper/Saeki/Harmsen 1999).

Size

Name

Sex

works at Manager

Department

1

n

Position

Employee m

Description is assigned

0..n

Entity

Project

Size Relation

Subject

Project manager

Attribute

Figure 19: An Example for a Product Fragment – An Entity-Relationship-Diagram (Source: own Figure)

The dimension perspective explores the product and process view on method fragments. Product fragments (PDF) are goal-oriented and are deliverables, milestone documents, models, diagrams, etc. Figure 19 illustrates an example of a product fragment, in this case an EntityRelationship-Diagram. Process fragments (PCF) are process-oriented and are stages, tasks and activities to be carried out (Rolland/Prakash 1996). Figure 20 illustrates a possible process fragment. 23

The third dimension abstraction level is not subject of consideration.

5.4 Description of Method Elements

123

Documentation evaluation

Data model exists? no

yes

Data model construction

Data model examination

Data model is appropriate? yes

Data model delivery

no Data model adjustment

Figure 20: An Example for a Description of a Process Fragment (Source: according to (Harmsen/Brinkkemper/Oei 1994))

The granularity layer is very important for describing the type and structure of a method fragment. A fragment can reside on one of the layers, stage, model, diagram or concept (Brinkkemper/Saeki/Harmsen 1999). The method layer addresses the complete method for developing the IS. For example, the Information Engineering method (Martin 1990) resides on this granularity layer. The stage layer addresses a segment of the life cycle of the IS. An example of a method fragment residing on the stage layer is the Technical Design Report. The model layer addresses a perspective of the IS. Such a perspective is an aspect system of an abstraction level. Examples of method fragments are the Data Model and the User Interface Model (Object Management Group (OMG) 2003). The diagram layer addresses the representation of a view of a model layer method fragment. For instance, the Object Diagram and the Class Hierarchy (Object Management Group (OMG) 2008) both address the data perspective, but in another representation. For instance, the state-chart lies on this granularity layer, as does the modeling procedure to produce it. The concept layer addresses the concepts and associations of the method fragments on the Diagram layer, as well as the manipulations defined on them. Concepts are subsystems of Diagram layer method fragments. Examples are: Entity and Entity is involved in Relationship (Chen 1976).

124


(Hofstede/Verhoef 1997) add that the sensible arrangement of method fragments on the respective granularity layer is very important in order to avoid negative consequences in the form of monetary or organizational costs. On the basis of respective granularity layer the type and structure of a particular method fragment can thus be described. (Brinkkemper/Saeki/Harmsen 1999) draw a distinction between five granularity levels: method, stage, model, diagram and concept. This classification uses an ascending order according to the granularity grade and is specified below. Method presents the lowest granularity level and refers to a complete method that is mostly be used during a development process of a designated product (usually an IS). Information engineering method (Martin 1990) is one example for this granularity level; it handles the categories data, processes, technology and organization. Stage addresses one phase of an IS life cycle. An example for a method fragment on this granularity level is a technical design report or a computer-aided software engineering tool, which is supporting the business area analysis of the information engineering method. Model addresses one perspective on IS. This is an aspect system of one particular abstraction level. A data model or user interface model are examples for method fragments on this granularity level. Diagram addresses the representation of a perspective on a particular method fragment, which is integrated in the superior level model. For example, a state transition diagram belongs to this granularity level. Concept refers to concepts and associations of the method fragments, which are integrated on the diagram-level. Concepts are therefore subsystems of method fragments, which are integrated on the diagram-level. Entities and the identification of the entities are the examples for this granularity level. The arrangement of the method fragments into the according granularity levels should be carried out very carefully and with a high level of accuracy, so that no negative follow-ups result. Approximate granularity leads to method fragments that will be decomposed or specialized afterwards during their composition (if even procurable). By contrast excessive granularity leads to an additional adaptation complexity during the composition of methods and to problems with the rebuilding of methods.


125

t ep nc Co

Method fragments

Granularity levels

m gra Dia

Product fragment l de Mo

ge Sta d tho Me

Process fragment

Figure 21: Graphic Representation of Characteristics of Method Fragments (Source: according to (Harmsen/Brinkkemper/Oei 1994))

Figure 21 illustrates the concept of method fragments according to (Harmsen/Brinkkemper/Oei 1994). To conclude the explanation of method fragments, the relationships between method fragments will be discussed. Relations describe the interrelation of method fragments and divide the development of methods into logic steps. Relations between fragments of the same layer and relations between fragments of different layers exist (Harmsen/Brinkkemper/Oei 1994).

produces 0...m

precedes

Process fragment

Product fragment

Process fragment

0...n requires

Figure 22: Relations between Method Fragments (Source: own Figure)

126


The relevant relation between fragments of the same layer is the predecessor relation. It says that one step can be done not until the previous step is done. This relation is only defined for process fragments, but can be derived for product fragments. The most important relation between fragments of different layers is the input/output relation. It explains that on the one hand process fragments require product fragments and on the other hand process fragments produce product fragments. The possible relations between fragments are illustrated in Figure 22. 5.4.3

Method Chunks

(Ralyté/Rolland 2001) choose an approach that builds upon the concept of method fragments. The existing process and product fragments are combined into a method chunk, which guarantees the close coupling between the process part and its correspondent product part. This is supposed to emphasize the consistency and independence of method chunks (Ayeda/Ralyte/Rolland 2004). Thus a single method consists of several, loosely coupled and already existing method chunks. 5.4.4

Method Components Method Method component MC A

MC B

Process MC D

Notation

MC F

Concept

MC E

MC G

MC C

MC n

Figure 23: Composition of Method Components (Source: own Figure)

(Brinkkemper/Lyytinen/Weike 1996) consider methods to be exchangeable and reusable components. (Karlsson/Wistrand 2004) state that method components are the smallest meaningful part of methods and consist of a process, notation and concept.


127

Figure 23 illustrates the graphic representation of method component’s composition. A process describes rules and recommendations for IS development and informs the method (component) user about which actions to perform and in what order. Notation means semantic, syntactic and symbolic rules for documentation. Concepts are categories included in the process and the notation (Cronholm/Ågerfalk 1999). They support the description of the problem domain and the method itself (Karlsson/Agerfalk/Hjalmarsson 2001). 5.4.5

Theoretical Background Method types - Method as an instance of a method type

Method chains and alliances - Composition of method fragments (MF) - Method chain: integration of MFs of different granularity levels - Method alliance: integration of MFs of the same granularity level

Method f ragments - Process fragment (PCF): description of activities incl. tasks - Product fragment (PDF): description of the output of a particular PCF - Granularity levels: method, stage, model, diagram, concept - Connections between fragments of the same/different type

Method components - Process: descriptions of procedures - Notation: documentation of activities in a process - Concept: categories included in the process and the notation

Method blocks - Extension of the method base through expert knowledge - Linking of PCF and corresponding PDF

Legend conceptually equivalent/ analogous to/ relates to

Figure 24: Overview of Method Concepts (Source: own Figure)

This section summarizes the results of the analysis of the method engineering discipline by providing an overview of individual concepts and their main points. Figure 24 illustrates an overview of described method concepts and emphasizes (1) the similarities between them and (2) their intersection.

128


The concept of the method types demonstrates the coherence between the general method types and the specific methods that were derived from them. Method chains and alliances link multiple method parts into meaningful entities. This linkage can be processed vertically combining several method parts from diverse granularity levels or it can be processed horizontally combining method types, which are integrated within the same granularity level. Method fragments divide method parts by means of the dimensions perspective and granularity. The dimensions perspective deals with the subcategorization of method parts in product or process fragments. The classification of the fragments into the granularity levels method, stage, model, diagram and concept enables the clear and stringent composition of a new method. In addition, the intersection between method fragments and their relations to each other provide a logical configuration for a method. Method components distinguish between process and product-oriented aspects of method parts. They are called processes or notations and are composed of their concepts. Method blocks are similar to method fragments. However, they combine both product and process fragments. The classification into the correct granularity levels as well as adding of further context information about the particular method fragment completes the concept of method blocks. The analysis of method engineering turned up two central characteristics of method concepts. First, methods are not closed and monolithic structures. Methods are a kind of composition of several method blocks with their own specific contents and procedures. Second, all introduced concepts of method engineering argue that a method always consists of product fragments (goal-oriented) and process fragments (process-oriented). Methods are built of such method fragments. In turn, method fragments stand in relationship to each other. The following three method elements build the framework for fundamental method definition and followed method construction: process, product, and relationship. 5.5

Formal Description of the Concept of Method Engineering


What are the rules of assembling method fragments into a meaningful method?

5.5 Formal Description of the Concept of Method Engineering

129

At this point, the concept of method will be described in formally to allow for a better understanding of the concept. This will facilitate a concise and logical explanation of the construction of methods and the method elements they consist of. In addition, the formalization will ease any transfer and application of the concept of method to other areas. The method concepts considered in the formalization are method chains and alliances, method fragments, method chunks and method components and will be aggregated under the collective term “method fragments”. Since the involved elements in the mentioned concepts largely vary only by name24 and not by content, the aggregation avoids recurrences when formulating the formal description. Annotation METHOD: Method itself TASKS: Set of tasks SMF: Set of method fragments ACTIVITIES: Set of activities P: Set of process fragments STAGES: Set of stages R: Set of product fragments DOCUMENTS: Set of documents REL: Set of relations between method fragments MODELS: Set of models MBL: Set of method blocks DIAGRAMS: set of diagrams

24

Process and product fragments in (Harmsen/Brinkkemper/Oei 1994) and (Ralyté/Rolland 2001), process and notation in (Brinkkemper/Saeki/Harmsen 1999).

130


Additionally, the function returning the level of a particular method fragment is defined as level: SMF → {n | n ‫ א‬N}

(1)

Since a method fragment is either a process fragment or a product fragment, for SMF applies: SMF = P ‫ ׫‬R

(2)

A process fragment p ‫ א‬P is process oriented and provides guidelines. For p applies: P = {p | p ‫ א‬TASKS ۩ p ‫ א‬ACTIVITIES ۩ p ‫ א‬STAGES}

(3)

A product fragment r ‫ א‬R is goal oriented and provides the results of process fragments. For r applies: R = {r | r ‫ א‬DOCUMENTS ۩ r ‫ א‬MODELS ۩ r ‫ א‬DIAGRAMS}

(4)

For the set of relations REL between method fragments the following applies: REL = {produces, requires, precedes, Ivert, Ihor}

(5)

Relations between method fragments are meaningful and necessary for the method construction. The following relations exist: Input / Output relations: either for the case that a process fragment requires a product fragment (rule (6)) or for the case that any process fragment produces a product fragment (rule (7)). requires = {(p ‫ א‬P, r ‫ א‬R) | r is required by p}25

(6)

produces = {(p ‫ א‬P, r ‫ א‬R) | r is produced by p}

(7)

Predecessor relations for consistency-checking (Harmsen/Brinkkemper/Oei 1994): if a process fragment requires an existing product fragment, the product fragment has to be produced by a preceding process fragment. precedes = {(p1, p2 ‫ א‬P) | ‫׌‬r ‫ א‬R: produces(p1, r) ‫ ר‬requires(p2, r)}

25

(8)

To be read: for a process fragment p element of P there exists (at least) one product fragment r element of R, for that applies: p requires r.

5.5 Formal Description of the Concept of Method Engineering

131

precedes_mbl = {(mbl1, mbl2 ‫ א‬MBL) | ‫׌‬pdf1, pdf2 ‫ א‬PDF, ‫׌‬pcf1, pcf2 ‫ א‬PCF: (pcf1, pdf1) = mbl1 ‫( ר‬pcf2, pdf2) = mbl2 ‫( ר‬pcf1, pcf2) ‫ א‬precedes}

(9)

While relations show the relationships between method fragments, the following concepts are used to link method fragments to logical units. These concepts are the integration of method fragments and the development of method blocks. The integration of method fragments leads to the development of method chains and method alliances. The vertical integration produces method chains by linking method fragments of different levels of granularity. Connecting method fragments with the same granularity is called horizontal integration. The following two rules illustrate these concepts in a formal way. connects ={(mf1, mf2 ‫ א‬MF) | ((mf1 and mf2 are connected))}

(10)

Ivert = {(mf1, mf2 ‫ א‬connects) | ((level(mf1) = level(mf2) + 1) ‫( ש‬level(mf1) = level(mf2) - 1))} (11) Ihor = {(mf1, mf2 ‫ א‬connects) | level(mf1) = level(mf2)}

(12)

The distinction whether it is a vertical (10) or horizontal (11) integration can be made with the help of the granularity level of the involved method fragments. Rule 10 states that the number of the granularity level of the method fragment must be one number higher or lower than the number of the granularity level of the preceding method fragment. The development of method blocks is one more way to link method fragments to logical units. In this case it is the connection of a process fragment with its respective product fragment. The following applies: MBL = {(p ‫ א‬P, r ‫ א‬R)}

(13)

In this context the following rule states that a process fragment and its respective product fragment are always on a higher granularity layer than the method block that is constructed from them: ‫׊‬mbl ‫ א‬MBL, ‫׊‬p ‫ א‬P, ‫׊‬r ‫ א‬R | (p, r) = mbl ֜ level(mbl) = level(p) – 1 ‫ ר‬level(mbl) = level(r) – 1 (14) A formal description of global method concept will now follow the explanation of method elements.

132


METHOD:={mf1, mf2, mf3,... , mfn, rel1,2, rel2,3, rel3,4, ..., relm-1,m}

with mfn ‫ א‬SMF,

relm,n ‫ א‬REL The rule states that a method consists of several method fragments that are connected to one another by relations. Table 22 summarizes the symbols used and their meanings. Symbol

Name

Explanation

{,}

set brackets

{a,b,c} means the set consisting of a, b, and c

{|}

set builder notation

{x | P(x)} means the set of all x for which P(x) is true

(,)

tuple

An ordered list (or sequence, or horizontal vector, or row vector) of values

֜

implication

A ֜ B means if A is true then B is also true; if A is false then nothing is said about B

‫ר‬

logical conjunction

The statement A ‫ ר‬B is true if both A and B are true; else it is false

‫ש‬

logical disjunction

The statement A ‫ ש‬B is true if A or B (or both) are true

ْ

xor

The statement A ْ B is true when either A or B, but not both, are true

‫׊‬

universal quantification

‫ ׊‬x: P(x) means P(x) is true for all x

‫׌‬

existential quantification

‫ ׌‬x: P(x) means there is at least one x such that P(x) is true

‫א‬

set membership

a ‫ א‬S means a is an element of the set S

→

function arrow

f: X → Y means the function f maps the set X into the set Y

Գ

natural numbers

Գ means { 1, 2, 3, ...}

‫׫‬

set-theoretic union

A ‫ ׫‬B means the set of those elements which are either in A, or in B, or in both

Table 22: Description of the Formalization Symbols (Source: own Table)

The next section provides a description of the design and construction of the HatSec security analysis method. The detailed description consists of both an intuitive explanation of the method and its formal representation. 5.6

HatSec Security Analysis Method


What are the steps of the HatSec method?

As revealed in section 4.6, there is currently no security analysis method available which suits the needs of healthcare at the moment. This thesis develops an IS security analysis method for healthcare telematics in Germany. Consequently, this thesis follows a trend to develop more-


133

specialized, in this case domain-specific, methods and approaches (Gray/Rossi/Tolvanen 2004). First, this section describes the HatSec method in detail and provides an overview of its method steps. Then the section illustrates the HatSec method both graphically way and according to the concept of method engineering. This makes the HatSec method easy to understand correctly. 5.6.1

From Plan-Do-Check-Act Approach to a IS Security Analysis Method for Healthcare Telematics

According to (Gollmann 1999), a technical security analysis is defined as a methodical, traceable analysis of an information system concerning primarily its technical aspects. This thesis enhances a technical security analysis to an information systems security analysis that concerns both technical and organizational aspects. Furthermore, the challenge of this new approach is not only to identify, analyze and address the security analysis but also to interpret these in a context that is applicable to the healthcare sector. During the planning stage of designing such an IS security analysis method specific to healthcare domain (Katsikas 2000), it is advisable to base the design procedure on established standards and best practice approaches (Furnell et al. 1998), so that a security analysis method relies on a previously approved frameworks (Siponen/Baskerville/Heikka 2006). In regards to security analyses, there are many different solutions from activity catalogues to loose collections of analysis techniques and useful tools as described in chapter 4. Despite each solution having its advantage for certain sectors, no appropriate standard or tool could be found to analyze German healthcare telematics in the way needed for this thesis (Blobel/Roger-France 2001). Therefore a new approach had to be developed, one that allows for an analysis of healthcare telematics infrastructure components and processes from both technical and organizations points of view (using tools, methods and processes in a structured and traceable way) (Lindup 1995; Nicol 2005). HatSec is the abbreviation of Healthcare Telematics Security and specifies an IS security analysis method for healthcare telematics. Based on the PDCA model, which was presented in section 4.5.4.1, a new approach for a technical and organizational security analysis of healthcare telematics is developed. By building a new approach based on this model, various activities during a security analysis can be orchestrated in a reasonable manner. Furthermore, the repeated execution of the approach’s steps provides continuous feedback of the analysis results to accommodate the analysis activities.

134


The HatSec method is built in a compositional manner. This means that the HatSec method was designed from existing IS security analysis approaches. Each of the identified and analyzed security analysis methods applicable in healthcare (section 4.6) were subdivided into method fragments and partially reintegrated into method blocks as described in section 5.4. These method elements, each of them an integral part of an existing IS security approach, were used to construct the HatSec security analysis method (Sunyaev 2009). The steps of the PDCA approach described in section 4.5.4.1 were adopted as a framework to be filled with identified method steps and form the basis for the HatSec method’s design. 5.6.2

Design of the HatSec Security Analysis Method

Security analysis goes by many names: security risk analysis, risk assessment, management review, gap analysis, risk management, vulnerability assessment, loss prevention, review of a sensitive application, information security audit etc. and each name refers to the same function: analyzing an information system, an organization, or a business process to assess its existing security profile and identify the safeguards needed to bring the system’s security up to the desired level (Hamilton 1999). All security analysis methodologies have several phases, stages, and steps. The identified method steps of selected IS security analysis approaches were chosen and methodically composed into the following seven steps: (1) scope identification, (2) asset identification, (3) basic security check, (4) threat identification, (5) vulnerability identification, (6) security assessment and (7) security measures. These steps are assigned to each of the identified method blocks (section 5.6.2) and represent at least one part of an IS security approach that best fits to the current situation. As previously described, all these selected parts were chosen according to their suitability for healthcare.


135

General IS Security Approach Characteristics



ISO/IEC TR 13335-3 (ISO/IEC TR 13335-3 1998; Ayalp 2006)

4

2

2

ISO 27001 (ISO/IEC 2005b)

4

3

2

ISO 27004 (ISO/IEC 2005c)

4

2

1

ISO 17799 (ISO/IEC 2005a)

4

3

2

ISO 14971 (ISO 14971:2007 2007)

5

3

3

HIPAA (Department of Health and Human Services 2005; Anton et al. 2007; Artnak/Benson 2005)

4

3

3

Odessa (Warren/Furnell/Sanders 1997)

4

3

3

Octave Method (Alberts/Dorofee 2001; Alberts et al. 2003)

4

3

1

FDA Guidance for Industry1 Q9 Quality Risk Management (Food and Drug Administration 2006)

4

3

2

CRAMM (CRAMM 2003)

4

3

2

NIST SP 800-30 (National Institute of Standards & Technology 2002)

4

3

2

ISO 27799 (ISO/FDIS 27799:2007(E) 2007)

4

4

4

ISMS JIPDEC for Medical Organisations (JIPDEC 2004)

4

3

3

IT-Grundschutzhandbuch (BSI 2005)

5

3

2

ISRAM (Karabacaka/Sogukpinar 2005)

3

2

2

HB 174-2003 (Standards Australia International/Standards New Zealand 2001)

4

3

3

CRISAM (Stallinger 2004)

4

Legend: 1 – not covered 5 – covered

2 – predominantly not covered

3 3 – partially covered

2 4 – predominantly covered

Table 23: Reflection of IS Security Approaches with Respect to Healthcare (Source: own Table)

Although a new approach had to be developed, several existing IS security approaches which were used as a foundation. Based on the results of a study of current IS security approaches’ suitability for healthcare (section 4.6), the following IS security approaches were integrated into the HatSec method: x

ISO 27799 (ISO/FDIS 27799:2007(E) 2007).

x

ISMS JIPDEC for Medical Organizations (JIPDEC 2004).

136

5 Designing a Security Analysis Method for Healthcare Telematics in Germany x

IT-Grundschutzhandbuch (BSI 2005).

x

ISRAM (Karabacaka/Sogukpinar 2005).

x

HB 174-2003 (Standards Australia International/Standards New Zealand 2001).

x

CRISAM (Stallinger 2004).

x

US Department of Health and Human Services - Guidance for Industry1 Q9 Quality Risk Management (Food and Drug Administration 2006).

x

CRAMM (CRAMM 2003).

x

NIST SP 800-30 (National Institute of Standards & Technology 2002).

x

ISO 27001 (ISO/IEC 2005b).

Table 23 provides a short overview of these selected IS security analysis approaches with regards to their applicability in the healthcare domain. 5.6.2.1 Method Blocks and Method Fragments During the analysis of the selected IS security approaches with respect to healthcare (section 4.6) selected method fragments were identified (Table 24, Table 25, Table 26). The selection was guided by the healthcare suitability of the identified IS security approaches (chapter 4), their fulfillment of healthcare IS security characteristics (as proposed in section 3.3) and their applicability for healthcare telematics in Germany (chapter 2 described the special characteristics of the German healthcare telematics, used IS standards and IS architectures). A full characteristics-based examination of the identified IS security approaches, which suited to the described situation best, was extensively described in section 4.6. All of the derived method fragments are integral parts of selected and analyzed IS security approaches. These method fragments characterize specific parts of selected IS security approaches, they were one-to-one extracted from the selected security analysis methods in order to be used as method fragments for the HatSec method design.


137

5.6.2.2 Overview of the Building Blocks of the HatSec Method NIST SP 800-30, 2002 HatSec Method

System Characterization

ISO/IEC 27001:2005 Security Analysis Context and Preparation

Threat Identification

Vulnerability Identification

c

Scope Identification

d

Asset Identification

Define the Scope and Boundaries

Identify the Assets within the Scope

Security Analysis Process

Control Analysis

f

Likelihood Determination

e


Identify the Risks Basic Security Check

Analyze and evaluate the Risks

g

Impact Analysis

h

Risk Determination

Identify and evaluate Options for the treatment of Risk

Security Assessment

i

Control Reccomendations


Select Control Objectives and Controls

Security Measures Security Analysis Product

Results Documentation

HB 174:2003

Identify Risks

Analyze Risks

Evaluate Risks

Monitor and Review

Communicate and Consult

Establish the Context

Assess risks

Test Risks

Figure 25: Matching of the HatSec Method to NIST SP 800-30, ISO 27001 and HB 174-2003 (Source: own Figure)

Figure 25 presents the identified 7 building blocks of the HatSec method and the corresponding steps of NIST SP 800-30 (National Institute of Standards & Technology 2002), ISO 27001 (ISO/IEC 2005b) and HB 174-2003 (Standards Australia International/Standards New Zealand 2001). The other approaches that served as a basis for the construction of the HatSec method can be assigned to the 7 steps in a similar way. The next section describes and divides the selected steps into method fragments.

138


The analysis of 16 different approved security approaches26 (Table 20) revealed that all of these security approaches start with or recommend starting with the identification of a security analysis scope. Some of the approaches use different names for the same steps, some of them describe the steps as a part of a management system or just summarize the steps together with the characterization of the review. But all of them have the same message and objective, namely starting a security analysis with a clearly defined scope, identifying the assets concerning the structure context, moving forward with the identification of threats and vulnerabilities, and finishing with the assessment of the security status and providing appropriate security measures. Due to this fact and taking the requirements of healthcare into consideration, the building blocks (steps) of the HatSec method are named according to the described procedure. Depending upon the context in which the security analysis takes place, the healthcare organization conducting a security analysis could use any of the presented method fragments of the described security approaches. 5.6.2.3 Perspectives of the HatSec Method In the process of the new security analysis approach it is necessary to identify, from all perspectives, the input in each process step and the output as the result of the process. By recognizing the input and output of each process it is possible to ensure that identical steps in the approaches used do not overlap with one another. Due to the similar output of the analyzed security approaches, the results of the steps are considered to be the same. Furthermore, because the approaches provide the same output a clear intersection to the next steps is also ensured as. The developed HatSec method consists of both standard security analysis steps (as proposed by global IS security management approaches) and sector-specific security analysis steps, developed especially for information systems in healthcare. Furthermore, the security analysis steps of the developed HatSec method are distinguished by security analysis phases. The HatSec method is divided into three main areas: context and preparation of the security analysis, security analysis process and its product. The corresponding HatSec process model is designed sequentially in this order.

26

ISO/IEC TR 13335-3 (ISO/IEC TR 13335-3 1998; Ayalp 2006), ISO 27001 (ISO/IEC 2005b), ISO 27004 (ISO/IEC 2005c), ISO 17799 (ISO/IEC 2005a), ISO 14971 (ISO 14971:2007 2007), HIPAA (Department of Health and Human Services 2005; Anton et al. 2007; Artnak/Benson 2005), Odessa (Warren/Furnell/Sanders 1997), Octave Method (Alberts/Dorofee 2001; Alberts et al. 2003), FDA Guidance for Industry1 Q9 Quality Risk Management (Food and Drug Administration 2006), CRAMM (CRAMM 2003), NIST SP 800-30 (National Institute of Standards & Technology 2002), ISO 27799 (ISO/FDIS 27799:2007(E) 2007), ISMS JIPDEC for Medical Organisations (JIPDEC 2004), ITGrundschutzhandbuch (BSI 2005), ISRAM (Karabacaka/Sogukpinar 2005), HB 174-2003 (Standards Australia International/Standards New Zealand 2001) and CRISAM (Stallinger 2004).


139

5.6.2.4 Context and Preparation of the Security Analysis To be able to conduct such a security analysis, a familiarization is needed that deals with the basic context problem and a specific preparation for this comprehensive process. To achieve this, the first step of the HatSec method contains the identification of the possible scope. In this step HatSec differs between different ways to identify the scope. The scope could be an asset / system based as offered in (Stoneburner/Goguen/Feringa 2002a; Bott et al. 2005; ISO/IEC 2005b; ISO/FDIS 27799:2007(E) 2007) or process based as offered in (BSI 2005; Stallinger 2004). The result of this step delineates the operational authorization boundaries and provides information essential to defining the security of the healthcare organizations (Stoneburner/Goguen/Feringa 2002a). Thus, the first step of HatSec is similar to the first step of PDCA where an analysis of possible threats takes place. In the second step of the HatSec method, the assets of the information system are identified as described in (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; CRAMM 2003; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007). Sources for conducting the second step could include documents from the information system’s database or results from previous security analysis. This step goes par with actions of the plan and do steps of the PDCA approach. There, assets, requirements and measures are also identified. The result of this step is the identification of assets or the development of the processes within the scope. This output is the framework needed for further security assessment. Figure 26 illustrates the context and preparation steps of the HatSec security analysis method.

Security Analysis Context and Preparation Asset based Process based

c


Modelling System related information IT structure analysis

d


Figure 26: Context and Preparation Steps of the HatSec Method (Source: own Figure)

140


Using the formal description from section 5.5, these first two steps of HatSec method are the MBL “Scope Identification” and MBL “Asset Identification”. MBL “Scope Identification” consists_of := {(PCF „System Characterization“, PDF „Scope“) ْ (PCF „Scope Definition“, PDF „Scope“) ْ (PCF „Initialization of IT Security Process“, PDF „Scope“) ْ (PCF „Process Information“, PDF „Scope“) ْ (PCF „Security Framework Definition“, PDF „Scope“)} MBL “Asset Identification” consists_of := {(PCF „System-Related Information“, PDF „Assets“) ْ (PCF „Asset Definition“, PDF „Assets“) ْ (PCF „IT Structure Analysis“, PDF „Assets“) ْ (PCF „Asset Valuation“, PDF „Assets“) ْ (PCF „Assets Visibility“, PDF „Assets“)} Table 24 summarizes the extracted method fragments, shows the corresponding descriptions in detail and assigns the identified method fragments into the two method blocks (steps). Method Blocks

Method Fragments

Description

MBL “Scope Identification”

PCF “System Characterization”

“In assessing risks for an IT system, the first step is to define the scope of the effort. In this step, the boundaries of the IT system are identified, along with the resources and the information that constitute the system. Characterizing an IT system establishes the scope of the risk assessment effort, delineates the operational authorization (or accreditation) boundaries, and provides information (e.g., hardware, software, system connectivity, and responsible division or support personnel) essential to defining the risk.” (Stoneburner/Goguen/Feringa 2002a, 10)

PCF “Scope Definition”

“Define the scope and boundaries of the ISMS in terms of the characteristics of the business, the organization, its location, assets and technology, and including details of and justification for any exclusions from the scope.” (ISO/IEC 2005b)

PCF “Initialization of IT Security Process”

“A systematic IT security process should have been initiated. This serves to channel the IT security operations along ordered tracks. For example, appropriate roles and tasks must be defined. The information security risk assessment should have a clearly defined scope in order to be effective and should include relationships with risk assessments in other areas, if appropriate. The scope of a risk assessment can be either the whole organization, parts of the organization, an individual information system, specific system components, or services where this is practicable, realistic, and helpful.” (BSI 2005, 5)

5.6 HatSec Security Analysis Method Method Blocks

MBL “Asset Identification”

141

Method Fragments

Description

PCF “Process Information”

“A formal scope statement needs to be produced. It is essential that the scope statement define the boundary of the compliance activity in terms of people, processes, places, platforms, and applications. Scope identification is one of the most important starting points for a health provider for a security analysis. There are different ways: The scope could be the information security framework of the health provider.” (Stallinger 2004)

PCF “Security Framework Definition”

“One of the most important starting points for a health provider in their development of an health information security framework will be the drafting of an information security policy. A policy will provide a statement of direction and support for Health Information Security. A policy should provide rules for the safeguarding of all data and should outline your approach to managing information security. The policy can then be a point of reference for all staff in relation to their information security responsibilities.” (ISO/IEC 2005d, 2005b; Stallinger 2004; Standards Australia International/Standards New Zealand 2001)

PDF “Scope”

“In assessing security, the first step is to define the scope of the effort.” (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; ISO/IEC 2005a; ISO/FDIS 27799:2007(E) 2007; JIPDEC 2004; Karabacaka/Sogukpinar 2005)

PCF “SystemRelated Information”

“Identifying risk for an IT system requires a keen understanding of the system’s processing environment. The person or persons who conduct the risk assessment must therefore first collect system-related information, which is usually classified as follows: x x x x x x

Hardware Software System interfaces (e.g., internal and external connectivity) Data and information Persons who support and use the IT system System mission (e.g., the processes performed by the IT system) x System and data criticality (e.g., the system’s value or importance to an organization) x System and data sensitivity Additional information related to the operational environmental of the IT system and its data includes, but is not limited to, the following: x x x x x x x x

The functional requirements of the IT system Users of the system (e.g., system users who provide technical support to the IT system; application users who use the IT system to perform business functions) System security policies governing the IT system (organizational policies, federal requirements, laws, industry practices) System security architecture Current network topology (e.g., network diagram) Information storage protection that safeguards system and data availability, integrity, and confidentiality Flow of information pertaining to the IT system (e.g., system interfaces, system input and output flowchart) Technical controls used for the IT system (e.g., built-in or add-on security product that supports identification and authentication, discretionary or mandatory access control, audit,

142 Method Blocks

5 Designing a Security Analysis Method for Healthcare Telematics in Germany Method Fragments

Description residual information protection, encryption methods) x Management controls used for the IT system (e.g., rules of behavior, security planning) x Operational controls used for the IT system (e.g., personnel security, backup, contingency, and resumption and recovery operations; system maintenance; off-site storage; user account establishment and deletion procedures; controls for segregation of user functions, such as privileged user access versus standard user access) x Physical security environment of the IT system (e.g., facility security, data center policies) x Environmental security implemented for the IT system processing environment (e.g., controls for humidity, water, power, pollution, temperature, and chemicals). For a system that is in the initiation or design phase, system information can be derived from the design or requirements document. For an IT system under development, it is necessary to define key security rules and attributes planned for the future IT system. System design documents and the system security plan can provide useful information about the security of an IT system that is in development. For an operational IT system, data is collected about the IT system in its production environment, including data on system configuration, connectivity, and documented and undocumented procedures and practices. Therefore, the system description can be based on the security provided by the underlying infrastructure or on future security plans for the IT system. Information-Gathering Techniques: Questionnaire, On-site Interviews, Document Review, Use of Automated Scanning Tool.” (Stoneburner/Goguen/Feringa 2002a, 11)

PCF “Asset Definition”

“Identify the assets within the scope of the ISMS, and the owners of these assets.” (ISO/IEC 2005b)

PCF “IT Structure Analysis”

“IT structure analysis IT structure analysis is to be performed for IT assets, as specified in Section 4.1 of the IT-Grundschutz Methodology. This is a way of ascertaining key information about IT assets (for example the basic network layout and a list of the most important IT applications which depend on the IT systems). Modeling A modeling process is to be performed, as specified in Section 4.3 of the IT-Grundschutz Methodology and Section 2 of the IT-Grundschutz Catalogues. This involves determining which target objects in the real IT network each module of the IT-Grundschutz Catalogues should be applied to. The standard security measures stated in the individual modules form the basis for the IT-Grundschutz security concept for IT assets under review.” (BSI 2005, 5)

PCF “Asset Valuation”

“CRAMM enables the reviewer to identify the physical (e.g., IT hardware), software (e.g., application packages), data (e.g., the information held on the IT system) and location assets that make up the information system. Each of these assets can be valued. Physical assets are valued in terms of the replacement cost. Data and software assets are valued in terms of the impact that would result if the information were to be unavailable, destroyed, disclosed or modified.” (CRAMM 2003)


Method Fragments

143 Description

PCF “Assets Visibility”

“Visible health business assets.” International/Standards New Zealand 2001)

(Standards

Australia

PDF “Assets”

“Regardless of size it is important that all organizations have an inventory or record of assets (physical assets, software assets, information assets and other intangible assets). Based on this information, their business can then provide levels of protection commensurate with the value and importance of the assets (classification levels, e.g., public, internal only, confidential health information, confidential non-health information).” (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; Siemens Insight Consulting 2007; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007)

Table 24: Method Blocks and Method Fragments of the first two Steps of the HatSec Method (Source: own Table)

5.6.2.5 Security Analysis Process The third and fourth steps are the steps, during which the actual analysis activities take place. During the third step a threat analysis involving an examination of possible threats to each asset is conducted (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; CRAMM 2003; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/ FDIS 27799:2007(E) 2007). Before conducting the threat analysis, a basic security check should be undertaken in order to determine which standard security measures have already been implemented for the IT assets under review. Security basic checks will reveal any deficits and point out where the threat analysis should take place. The basis for this step is a hazard list related to healthcare, one where specific healthcare threats are documented. Step five involves vulnerability identification as offered in different ways in (Stoneburner/ Goguen/Feringa 2002a; ISO/IEC 2005b; CRAMM 2003; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007) and is not necessary to be fulfilled as in (BSI 2005). The goal of this step is to develop a list of vulnerabilities that could be exploited by potential threat sources. Security requirements relevant to healthcare form the basis for this step. The sixth step involves implementing the results of step three and four and determines the level of security as shown in different ways in (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; CRAMM 2003; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007). The bases for this step are the risk valuation guidelines relevant to healthcare as recommended by (ISO/FDIS 27799:2007(E) 2007). Such valuation guidelines recognize the importance of patient security, uninterrupted availability of emergency services, professional accreditation, and clinical regulation (ISO/FDIS 27799:

144


2007(E) 2007). These three steps are therefore similar to the check step of the PDCA approach where the ISMS is being reviewed and tested. Figure 27 illustrates the process step of the HatSec security analysis method.


Hazard list relevant to health care

f

g

Security requirements relevant to health care

Risk valuation guidelines relevant to health care

h

e


Basic Security Check


Security Assessment

Figure 27: Process Step of the HatSec Method (Source: own Figure)

Using the formal description from section 5.5, these four steps of HatSec method are based on the MBL “Basic Security Check”, MBL “Threat Identification”, MBL “Vulnerability Identification” and MBL “Security Assessment”. MBL “Basic Security Check” consists_of Grundschutz“, PDF „Threat Summary“)}

:=

{(PCF

„IT-

MBL “Threat Identification” consists_of := {(PCF „Threat Definition“, PDF „Threat List“) ْ (PCF „Threat Allocation“, PDF „Threat List“) ْ (PCF „Threat Assessment“, PDF„Threat List“) ْ (PCF „Threat Recognition“, PDF „Threat List“)} MBL “Vulnerability Identification” consists_of := {(PCF „Vulnerability Definition“, PDF „Vulnerability List“) ْ (PCF „Vulnerability Recognition“, PDF „Vulnerability List“) ْ (PCF „Risk Identification“, PDF„Vulnerability List“)}


145

MBL “Security Assessment” consists_of := {(PCF „Risk Determination“, PDF „Risk Evaluation“) ْ (PCF „Risk Assessment“, PDF „Risk Evaluation“) ْ (PCF „Threat Assessment“, PDF „Risk Evaluation“) ْ (PCF „Risk Analysis“, PDF „Risk Evaluation“) ْ (PCF „Risk Measurement“, PDF „Risk Evaluation“)} Table 25 summarizes the extracted method fragments, presents the corresponding descriptions in detail and assigns the identified method fragments to these three method blocks (steps). Method Blocks

Method Fragments

Description

MBL “Basic Security Check”

PCF “IT-Grundschutz”

“Basic security check Prior to the risk analysis a basic security check must be performed, as specified in Section 4.4 of the IT-Grundschutz Methodology. This determines which standard security measures have already been implemented for the IT assets under review and where there are still deficits. Supplementary security analysis A supplementary security analysis must have been performed, as specified in Section 4.5 of the IT Grundschutz Methodology. During the Supplementary Security Analysis a decision is made as to which objects are to be the subject of risk analyses and to identify those for which this is not necessary. Threat Summary The threats that are relevant to the target objects under review and are listed in the IT-Grundschutz Catalogues constitute an appropriate starting point for the risk analysis. In contrast to the "ITSicherheitshandbuch" (Bundesamt für Sicherheit in der Informationstechnik 1992), threats, vulnerabilities and risks are not examined separately here. The aim of the following work steps is to produce a summary of the threats to which the target objects under review are subject. For this purpose it is advisable to initially reduce the IT assets down to the components under review.” (BSI 2005)

PDF “Threat Summary”

“The security basic check points to deficits where threat analysis is to take place.” (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; Siemens Insight Consulting 2007; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007)

PCF “Threat Definition”

“A threat is an action or event that may result in a detrimental outcome to a system or information assets. The result may even be life threatening. The threat analysis involves an examination of possible threats to each asset. The threats might include human actors, natural catastrophes, unintentional errors, etc.” (Stoneburner/Goguen/Feringa 2002a, 12)

PCF “Threat Allocation”

“Identify the threats to the assets.” (ISO/IEC 2005b)

MBL “Threat Identification”

146 Method Blocks

5 Designing a Security Analysis Method for Healthcare Telematics in Germany Method Fragments PCF “Threat Assessment”

Description “Having understood the extent of potential problems, the next stage is to identify just how likely such problems are to occur. CRAMM covers the full range of deliberate and accidental threats that may affect information systems including: x Hacking x Viruses x Failures of equipment or software x Willful damage or terrorism x Errors by people This stage concludes by calculating the level of the underlying or actual risk.” (CRAMM 2003)

MBL “Vulnerability Identification”

PCF “Threat Recognition”

“You will need to identify your threats. A threat is an action or event that may result in a detrimental outcome to a system or information assets. The result may even be life threatening. Once you have identified your threats, you can them determine the risks to your business. For each threat the likelihood and Impact/Consequence needs to be determined to evaluate the risk.” (Standards Australia International/Standards New Zealand 2001)

PDF “Threat List”

“A threat analysis involves an examination of possible threats.” (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; Siemens Insight Consulting 2007; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007)

PCF “Vulnerability Definition”

“The analysis of the threat to an IT system must include an analysis of the vulnerabilities associated with the system environment. The goal of this step is to develop a list of system vulnerabilities (flaws or weaknesses) that could be exploited by the potential threatsources. Recommended methods for identifying system vulnerabilities are the use of vulnerability sources, the performance of system security testing, and the development of a security requirements checklist. It should be noted that the types of vulnerabilities that will exist, and the methodology needed to determine whether the vulnerabilities are present, will usually vary depending on the nature of the IT system and the phase it is in, in the SDLC: x

x

x

If the IT system has not yet been designed, the search for vulnerabilities should focus on the organization’s security policies, planned security procedures, and system requirement definitions, and the vendors’ or developers’ security product analyses (e.g., white papers). If the IT system is being implemented, the identification of vulnerabilities should be expanded to include more specific information, such as the planned security features described in the security design documentation and the results of system certification test and evaluation. If the IT system is operational, the process of identifying vulnerabilities should include an analysis of the IT system security features and the security controls, technical and procedural, used to protect the system.


147

Method Fragments

Description 1.

2.

3.

Vulnerability Sources: x Previous risk assessment documentation of the IT system assessed x The IT system’s audit reports, system anomaly reports, security review reports, and system test and evaluation reports x Vulnerability lists, such as the NIST I-CAT vulnerability database (http://icat.nist.gov) x Security advisories, such as Fed CIRC and the Department of Energy’s Computer Incident Advisory Capability bulletins x Vendor advisories x Commercial computer incident/emergency response teams and post lists (e.g., SecurityFocus.com forum mailings) x Information Assurance Vulnerability Alerts and bulletins for military systems x System software security analyses. System Security Testing - Proactive methods (Automated vulnerability scanning tool, Security test and evaluation (ST&E), Penetration testing) Development of Security Requirements Checklist During this step, the risk assessment personnel determine whether the security requirements stipulated for the IT system and collected during system characterization are being met by existing or planned security controls. Typically, the system security requirements can be presented in table form, with each requirement accompanied by an explanation of how the system’s design or implementation does or does not satisfy that security control requirement. A security requirements checklist contains the basic security standards that can be used to systematically evaluate and identify the vulnerabilities of the assets (personnel, hardware, software, information), nonautomated procedures, processes, and information transfers associated with a given IT system in the following security areas: x Management x Operational x Technical. Sources that can be used in compiling such a checklist include, but are not limited to, the following government regulatory and security directives and sources applicable to the IT system processing environment: x x

CSA of 1987 Federal Information Processing Standards Publications x OMB November 2000 Circular A-130 x Privacy Act of 1974 x System security plan of the IT system assessed x The organization’s security policies, guidelines, and standards Industry practices.” (Stoneburner/Goguen/Feringa 2002a, 13)

148


Method Blocks

Method Fragments

Description

PCF “Vulnerability Recognition”

“Identify the vulnerabilities that might be exploited by the threats.” (ISO/IEC 2005b, 4)

PCF “Risk Identification”

“Risk identification is a systematic use of information to identify hazards referring to risk question or problem description. Information can include historical data, theoretical analysis, informed opinions, and the concerns of stakeholders. Risk identification addresses the “What might go wrong?” question, including identifying the possible consequences. This provides the basis for further steps in the quality risk management process.” (Food and Drug Administration 2006, 4)

PDF “Vulnerability List”

“A list of vulnerabilities that could be exploited by the potential threat sources”. (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; Siemens Insight Consulting 2007; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007)

Table 25: Method Blocks and Method Fragments of Steps three, four and five of the HatSec Method (Source: own Table)

5.6.2.6 Security Analysis Product In step seven, activities are chosen to determine whether a security level is acceptable or whether it requires improvement using different criteria types going from a risk – level matrix to necessary protection requirements as offered in (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; CRAMM 2003; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007). This step has a counterpart in the act step of the PDCA approach, where measures are also implemented to improve the ISMS. Figure 28 illustrates the product step of the HatSec security analysis method.


Likelihood determination Impact analysis Security determination

h

Security Assessment

i


Figure 28: Product Step of the HatSec Method (Source: own Figure)


149

Using the formal description from section 5.5, the last step of HatSec method is based on the MBL “Security Measures”. MBL “Threat Identification” consists_of := {(PCF „Risk-Level Matrix“, PDF „Security Level Acceptance“) ْ (PCF „Criteria“, PDF „Security Level Acceptance“) ْ (PCF „Protection Requirements“, PDF „Security Level Acceptance“) ْ (PCF „Control Recommendations“, PDF „Security Level Acceptance“) ْ (PCF „Risk Treatment“, PDF „Security Level Acceptance“)} Table 26 summarizes the extracted method fragments, shows the corresponding descriptions in detail and assigns the identified method fragments to these two method blocks (steps). Method Blocks MBL “Security Assessment”

Method Fragments

Description

PCF “Risk Determination”

“Control Analysis The goal of this step is to analyze the controls that have been implemented, or are planned for implementation, by the organization to minimize or eliminate the likelihood (or probability) of a threat exploiting system vulnerability. To derive an overall likelihood rating that indicates the probability that a potential vulnerability may be exploited within the construct of the associated threat environment (Step 5 below), the implementation of current or planned controls must be considered. For example, a vulnerability (e.g., system or procedural weakness) is not likely to be exploited or the likelihood is low if there is a low level of threat-source interest or capability or if there are effective security controls that can eliminate or reduce the magnitude of damage. Likelihood Determination To derive an overall likelihood rating that indicates the probability that a potential vulnerability may be exploited within the construct of the associated threat environment, the following governing factors must be considered: x Threat-source motivation and capability x Nature of the vulnerability x Existence and effectiveness of current controls. The likelihood that a potential vulnerability could be exploited by a given threat-source can be described as high, medium, or low.

150 Method Blocks


Description Impact Analysis The next major step in measuring level of risk is to determine the adverse impact resulting from successful threat exploitation of vulnerability. Before beginning the impact analysis, it is necessary to obtain the following information. x

System mission (e.g., the processes performed by the IT system) x System and data criticality (e.g., the system’s value or importance to an organization) x System and data sensitivity. The adverse impact of a security event can be described in terms of loss or degradation of any, or a combination of any, of the following three security goals: integrity, availability, and confidentiality. Because of the generic nature of this discussion, this guide designates and describes only the qualitative categories—high, medium, and low impact. Risk Determination The purpose of this step is to assess the level of risk to the IT system. The determination of risk for a particular threat/vulnerability pair can be expressed as a function of x

The likelihood of a given threat-source’s attempting to exercise a given vulnerability x The magnitude of the impact should a threat-source successfully exercise the vulnerability x The adequacy of planned or existing security controls for reducing or eliminating risk. To measure risk, a risk scale and a risk-level matrix must be developed.” (Stoneburner/Goguen/Feringa 2002a, 19) PCF “Risk Assessment”

1. 2.

3.

4. PCF “Threat Assessment”

“Identify the impacts that losses of confidentiality, integrity and availability may have on the assets. Assess the economic impact upon the organization that might result from security failures, taking into account the consequences of a loss of confidentiality, integrity or availability of the assets. Assess the realistic likelihood of security failures occurring in the light of prevailing threats and vulnerabilities, and the effects associated with these assets, and the controls currently implemented. Estimate the levels of risks.” (ISO/IEC 2005b, 4)

“This step works through the threat summary systematically. It checks whether the IT security measures already implemented or at least planned in the IT security concept provide adequate protection for each target object and threat. As a general rule, these will be standard security measures taken from the IT-Grundschutz Catalogues. The test is performed using the IT security concept and the following testing criteria: Completeness, Mechanism strength, Reliability. The risk assessment provides an overview as to which threats are adequately covered for the target objects under review by the measures contained in the IT-Grundschutz Catalogues (OK=Y), and as to where there may still be risks (OK=N).” (BSI 2005, 5)


151

Method Fragments

Description

PCF “Risk Analysis”

“Risk Analysis is the estimation of the risk associated with the identified hazards. It is the qualitative or quantitative process of linking the likelihood of occurrence and severity of harms. In some risk management tools, the ability to detect the harm (detectability) also factors in the estimation of risk. Risk evaluation compares the identified and analyzed risk against given risk criteria. Risk evaluations consider the strength of evidence for all three of the fundamental questions.” (Food and Drug Administration 2006)

PCF “Risk Measurement”

“Likelihood & Impact/Consequences The likelihood of an event occurring over a 12 month period is broken into four event occurrences — x x x x

Almost Certain —This event will most likely occur; Likely —There is a high chance that this event will occur; Possible —There is a chance that this event will occur; and Unlikely —There is minimal chance that this event will occur.

Likelihood & Impact/Consequences The likelihood of an event occurring over a 12 month period is broken into four event occurrences — x x x x

Almost Certain —This event will most likely occur; Likely —There is a high chance that this event will occur; Possible —There is a chance that this event will occur; and Unlikely —There is minimal chance that this event will occur.

Risk Assessment Based on likelihood and Consequence, the table S.25 outlines the Risk of an event occurring.” (Standards Australia International/Standards New Zealand 2001)

MBL “Security Measures”

PDF “Risk Evaluation”

“A Risk valuation guideline in order to recognize the importance of patient security, uninterrupted availability of emergency services, professional accreditation and clinical regulation.” (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; Siemens Insight Consulting 2007; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007)

PCF “Risk-Level Matrix”

“The final determination of mission risk is derived by multiplying the ratings assigned for threat likelihood (e.g., probability) and threat impact.” (Stoneburner/Goguen/Feringa 2002a, 24).

PCF “Criteria”

“Develop criteria for accepting risks and identify the acceptable levels of risk. Determine whether the risks are acceptable or require treatment using the criteria for accepting risks established in PCF “Risk Assessment”.” (ISO/IEC 2005b, 4)

152 Method Blocks


Description

PCF “Protection Requirements”

“An assessment of protection requirements is to be performed, as specified in Section 4.2 of the IT-Grundschutz Methodology. The result is the protection requirement for the IT applications, systems, rooms used by IT assets and a list of the critical communication links. The security requirement refers to the basic parameters of confidentiality, integrity and availability and is determined at three levels, namely normal, high and very high.” (BSI 2005, 5)

PCF “Control Recommendations”

“During this step of the process, controls that could mitigate or eliminate the identified risks, as appropriate to the organization’s operations, are provided. The goal of the recommended controls is to reduce the level of risk to the IT system and its data to an acceptable level. The following factors should be considered in recommending controls and alternative solutions to minimize or eliminate identified risks: x x x x x

Effectiveness of recommended options (e.g., system compatibility) Legislation and regulation Organizational policy Operational impact Safety and reliability.” (Stoneburner/Goguen/Feringa 2002a, 5)

PCF “Risk Treatment”

“Possible actions include: 1. Applying appropriate controls; 2. Knowingly and objectively accepting risks, providing they clearly satisfy the organization’s policies and the criteria for accepting risks; 3. Avoiding risks; and 4. Transferring the associated business risks to other parties, e.g., insurers, suppliers.” (ISO/IEC 2005b, 4)

PDF “Security Level Acceptance”

“Determination whether a security level is acceptable or whether it requires a specific.” (Stoneburner/Goguen/Feringa 2002a; ISO/IEC 2005b; BSI 2005; Siemens Insight Consulting 2007; Standards Australia International/Standards New Zealand 2001; JIPDEC 2004; ISO/FDIS 27799:2007(E) 2007)

Table 26: Method Blocks and Method Fragments of the final two Steps of the HatSec Method (Source: own Table)

5.6.2.7 Two Sides of the HatSec Method Taking all – the first, fourth, fifth and sixth steps – one can conduct standard analyses in the form of checklists, which also determine the security level of healthcare organizations, according to its compliance to a standard or policy, and maturity level. Therefore the scope could be standard based, for example when searching for compliance with standards such as (ISO/IEC 2005b) or policy based when searching for compliance with the company policy needed to fulfill the requirements (for example (Saleh/Alrabiah/Bakry 2007)). The basis for this standard analysis is the compliance with legal healthcare requirements as proposed in


153

(Standards Australia International/Standards New Zealand 2001; ISO/FDIS 27799:2007(E) 2007). Consequently, the HatSec method can be used either as a healthcare information systems security analysis approach or as a quasi standard IS security analysis method that can be applied in any sector. Both possibilities offer users the oppurtunity to determine how they use the HatSec method. Decisions about the use of particular method parts are left to the user. These method parts are introduced in the next chapter of this thesis. Figure 29 outlines the complete systematic composition of the HatSec method graphically and highlights the healthcare specific factors that influence the identified security analysis steps.

Security Analysis Context and Preparation Asset based Process based

c


Modelling System related information IT structure analysis

d


Standard based Policy based


Hazard list relevant to health care

f

g

Security requirements relevant to health care


Likelihood determination Impact analysis Security determination


h

e



Standard security check Policy security check Maturity level assesment

Security Assessment Compliance with legal health care requirements

i


Security Analysis

Standard Analysis

Figure 29: HatSec Method (Source: own Figure)

Every step of the HatSec method consists of one or more elements of existing IS security approaches. So, each step of the HatSec method features at least one step of a security analysis method that fit this step of the security analysis best. These findings formed the basic principles for the design and construction of HatSec method.

154


c


d

i


1. Plan

2. Do

4. Act

3. Check

Security Measures

h

e f g




Security Assessment

Figure 30: HatSec Approach as a Plan-Do-Check-Act Model (Source: own Figure).

Figure 30 illustrates the cohesion between the PDCA approach and the developed security analysis approach. Both are executed repeatedly, and the activities of the HatSec steps overlap with activities of the PDCA approach. 5.6.2.8 HatSec Structure According to the method engineering concept described in section 5.5, the HatSec method consists of specific method fragments (integral individual parts of existing IS security approaches) or of more general method blocks, relations between them (either between method blocks or method fragments), and whether they are integrated horizontally or vertically. Method fragments can be either products or process fragments. Method blocks combine several method fragments in a specific way (section 5.4.2). The interconnection (relations) of method blocks or method fragments and their integration levels depend on the specific situation. During the construction of the HatSec method, the following four core types of relations were used: consists_of, produces, requires and precedes (for detailed description see section 5.5). This is the formal representation of the HatSec method:


155

MF = PDF ‫ ڂ‬PCF Method = {MBL, MF, consists_of, produces, requires, precedes, precedes_mbl, Ihor} consists_of := {((MBL „Scope Identification“, PCF „System Characterization“, PDF „Scope“) ْ (MBL „Scope Identification“, PCF „Scope Definition“, PDF „Scope“) ْ (MBL „Scope Identification“, PCF „Initialization of IT Security Process“, PDF „Scope“) ْ(MBL „Scope Identification“, PCF „Process Information“, PDF „Scope“) ْ (MBL „Scope Identification“, PCF „Security Framework Definition“, PDF „Scope“))), (((MBL „Asset Identification“, PCF „System-Related Information“, PDF „Assets“) ْ (MBL „Asset Identification“, PCF „Asset Definition“, PDF „Assets“) ْ (MBL „Asset Identification“, PCF „IT Structure Analysis“, PDF „Assets“) ْ (MBL „Asset Identification“, PCF „Asset Valuation“, PDF „Assets“) ْ (MBL „Asset Identification“, PCF „Assets Visibility“, PDF „Assets“))), ((MBL „Basic Security Check“, PCF „IT-Grundschutz“, PDF „Threat Summary“)), (((MBL „Threat Identification“, PCF „Threat Definition“, PDF „Threat List“) ْ (MBL „Threat Identification“, PCF „Threat Allocation“, PDF „Threat List“) ْ (MBL „Threat Identification“, PCF „Threat Assessment“, PDF„Threat List“) ْ (MBL „Threat Identification“, PCF „Threat Recognition“, PDF „Threat List“))), (((MBL „Vulnerability Identification“, PCF „Vulnerability Definition“, PDF „Vulnerability List“) ْ (MBL „Vulnerability Identification“, PCF „Vulnerability Recognition“, PDF „Vulnerability List“) ْ (MBL „Vulnerability Identification“, PCF „Risk Identification“, PDF„Vulnerability List“))), (((MBL „Security Assessment“, PCF „Risk Determination“, PDF „Risk Evaluation“) ْ (MBL „Security Assessment“, PCF „Risk Assessment“, PDF „Risk Evaluation“) ْ (MBL „Security Assessment“, PCF „Threat Assessment“, PDF „Risk Evaluation“) ْ (MBL „Security Assessment“, PCF „Risk Analysis“, PDF „Risk Evaluation“) ْ (MBL „Security Assessment“, PCF „Risk Measurement“, PDF „Risk Evaluation“))), ((MBL „Security Measures“, PCF „Risk-Level Matrix“, PDF „Security Level Acceptance“) ْ (MBL „Security Measures“, PCF „Criteria“, PDF „Security Level Acceptance“) ْ (MBL „Security Measures“, PCF „Protection Requirements“, PDF „Security Level Acceptance“) ْ (MBL „Security Measures“, PCF „Control Recommendations“, PDF „Security Level Acceptance“) ْ (MBL „Security Measures“, PCF „Risk Treatment“, PDF „Security Level Acceptance“))} produces := { ((PCF „System Characterization“, PDF „Scope“) ْ (PCF „Scope Definition“, PDF „Scope“) ْ (PCF „Initialization of IT Security Process“, PDF „Scope“) ْ (PCF „Process Information“, PDF „Scope“) ْ (PCF „Security Framework Definition“, PDF „Scope“)), ((PCF „System-Related Information“, PDF „Assets“) ْ (PCF „Asset Definition“, PDF „Assets“) ْ (PCF „IT Structure Analysis“, PDF „Assets“) ْ (PCF „Asset Valuation“, PDF „Assets“) ْ (PCF „Assets Visibility“, PDF „Assets“)), (PCF „IT-Grundschutz“, PDF „Threat Summary“), ((PCF „Threat Definition“, PDF „Threat List“) ْ (PCF „Threat Allocation“, PDF „Threat List“) ْ (PCF „Threat Assessment“, PDF „Threat List“) ْ (PCF „Threat Recognition“, PDF „Threat List“)), ((PCF „Vulnerability Definition“, PDF „Vulnerability List“) ْ (PCF „Vulnerability Recognition“, PDF „Vulnerability List“) ْ (PCF „Risk Identification“, PDF „Vulnerability List“)), ((PCF „Risk Determination“, PDF „Risk Evaluation“) ْ (PCF „Risk Assessment“, PDF „Risk Evaluation“) ْ (PCF „Threat Assessment“, PDF „Risk Evaluation“) ْ (PCF „Risk Analysis“, PDF „Risk Evaluation“) ْ (PCF „Risk Measurement“, PDF „Risk Evaluation“)), ((PCF „Criteria“, PDF „Security Level Acceptance“) ْ (PCF „Risk-Level Matrix“, PDF „Security Level Acceptance“) ْ (PCF „Protection Requirements“, PDF „Security Level Acceptance“) ْ (PCF „Control Recommendations“, PDF „Security Level Acceptance“) ْ (PCF „Risk Treatment“, PDF „Security Level Acceptance“))} requires := { ((PCF „System-Related Information“, PDF „Scope“) ْ (PCF „Asset Definition“, PDF „Scope“) ْ (PCF „IT Structure Analysis“, PDF „Scope“) ْ (PCF „Asset Valuation“, PDF „Scope“) ْ (PCF „Assets Visibility“, PDF „Scope“)), (PCF „IT-Grundschutz“, PDF „Assets“) , 27

(PCF „IT-Grundschutz“, PDF „Threat list“)* , ((PCF „Threat Definition“, PDF „Threat Summary“) ْ (PCF „Threat Allocation“, PDF „Threat Summary“) ْ (PCF „Threat Assessment“, PDF „Threat Summary“) ْ (PCF „Threat Recognition“, PDF „Threat Summary“),), ((PCF „Vulnerability Definition“, PDF „Threat List“) ْ (PCF „Vulnerability Recognition“, PDF „Threat List“) ْ (PCF „Risk Identification“, PDF „Threat List“)),

27

If applicable (optional)

156


((PCF „Risk Determination“, PDF „Vulnerability List“) ْ (PCF „Risk Assessment“, PDF „Vulnerability List“) ْ (PCF „Threat Assessment“, PDF „Vulnerability List“) ْ (PCF „Risk Analysis“, PDF „Vulnerability List“) ْ (PCF „Risk Measurement“, PDF „Vulnerability List“)), ((PCF „Criteria“, PDF „Risk Evaluation“) ْ (PCF „Risk-Level Matrix“, PDF „Risk Evaluation“) ْ (PCF „Protection Requirements“, PDF „Risk Evaluation“) ْ (PCF „Control Recommendations“, PDF „Risk Evaluation“) ْ (PCF „Risk Treatment“, PDF „Risk Evaluation“))} precedes := {(p1, p2 ‫ א‬PCF) | ‫׌‬r ‫ א‬PDF: produces (p1, r) ‫ ר‬requires(p2, r)} precedes_mbl := {(mbl1, mbl2 ‫ א‬MBL) | ‫׌‬pdf1, pdf2 ‫ א‬PDF, ‫׌‬pcf1, pcf2 ‫ א‬PCF: (pcf1, pdf1) = mbl1 ‫( ר‬pcf2, pdf2) = mbl2 ‫( ר‬pcf1, pcf2) ‫א‬ precedes} precedes := { ((PCF „System-Related Information“, PCF „System Characterization“) ْ (PCF „Asset Definition“, PCF „System Characterization“) ْ (PCF „IT Structure Analysis“, PCF „System Characterization“) ْ (PCF „Asset Valuation“, PCF „System Characterization“) ْ (PCF „Assets Visibility“, PCF „System Characterization“) ْ (PCF „System-Related Information“, PCF „Scope Definition“) ْ (PCF „Asset Definition“, PCF „Scope Definition“) ْ (PCF „IT Structure Analysis“, PCF „Scope Definition“) ْ (PCF „Asset Valuation“, PCF „Scope Definition“) ْ (PCF „Assets Visibility“, PCF „Scope Definition“) ْ (PCF „System-Related Information“, PCF „Initialization of IT Security Process“) ْ (PCF „Asset Definition“, PCF „Initialization of IT Security Process“) ْ (PCF „IT Structure Analysis“, PCF „Initialization of IT Security Process“) ْ (PCF „Asset Valuation“, PCF „Initialization of IT Security Process“) ْ (PCF „Assets Visibility“, PCF „Initialization of IT Security Process“) ْ (PCF „System-Related Information“, PCF „Process Information“) ْ (PCF „Asset Definition“, PCF „Process Information“) ْ (PCF „IT Structure Analysis“, PCF „Process Information“) ْ (PCF „Asset Valuation“, PCF „Process Information“) ْ (PCF „Assets Visibility“, PCF „Process Information“) ْ (PCF „System-Related Information“, PCF „Security Framework Definition“) ْ (PCF „Asset Definition“, PCF „Security Framework Definition“) ْ (PCF „IT Structure Analysis“, PCF „Security Framework Definition“) ْ (PCF „Asset Valuation“, PCF „Security Framework Definition“) ْ (PCF „Assets Visibility“, PCF „Security Framework Definition“)), ((PCF „System-Related Information“, PCF „IT-Grundschutz“) ْ (PCF „Asset Definition“, PCF „IT-Grundschutz“) ْ (PCF „IT Structure Analysis“, PCF „IT-Grundschutz“) ْ (PCF „Asset Valuation“, PCF „IT-Grundschutz“)ْ(PCF „Assets Visibility“, PCF „ITGrundschutz“) ْ ), ((PCF „IT-Grundschutz“, PCF „Threat Definition“) ْ (PCF „IT-Grundschutz“, PCF „Threat Allocation“) ْ (PCF „IT-Grundschutz“, PCF „Threat Assessment“) ْ (PCF „IT-Grundschutz“, PCF „Threat Recognition“) ْ ), ((PCF „Threat Definition“, PCF „Vulnerability Definition“) ْ (PCF „Threat Allocation“, PCF „Vulnerability Definition“) ْ (PCF „Threat Assessment“, PCF „Vulnerability Definition“) ْ (PCF „Threat Recognition“, PCF „Vulnerability Definition“) ْ (PCF „Threat Definition“, PCF „Vulnerability Recognition“) ْ (PCF „Threat Allocation“, PCF „Vulnerability Recognition“) ْ (PCF „Threat Assessment“, PCF „Vulnerability Recognition“) ْ (PCF „Threat Recognition“, PCF „Vulnerability Recognition“) ْ (PCF „Threat Definition“, PCF „Risk Identification“) ْ (PCF „Threat Allocation“, PCF „Risk Identification“) ْ (PCF „Threat Assessment“, PCF „Risk Identification“) ْ (PCF „Threat Recognition“, PCF „Risk Identification“) ْ ), ((PCF „Vulnerability Definition“, PCF „Risk Determination“) ْ (PCF „Vulnerability Recognition“, PCF „Risk Determination“) ْ (PCF „Risk Identification“, PCF „Risk Determination“) ْ (PCF „Vulnerability Definition“, PCF „Risk Assessment“) ْ (PCF „Vulnerability Recognition“, PCF „Risk Assessment“) ْ (PCF „Risk Identification“, PCF „Risk Assessment“) ْ (PCF „Vulnerability Definition“, PCF „Threat Assessment“) ْ (PCF „Vulnerability Recognition“, PCF „Threat Assessment“) ْ (PCF „Risk Identification“, PCF „Threat Assessment“) ْ (PCF „Vulnerability Definition“, PCF „Risk Analysis“) ْ (PCF „Vulnerability Recognition“, PCF „Risk Analysis“) ْ (PCF „Risk Identification“, PCF „Risk Analysis“) ْ (PCF „Vulnerability Definition“, PCF „Risk Measurement“) ْ (PCF „Vulnerability Recognition“, PCF „Risk Measurement“) ْ (PCF „Risk Identification“, PCF „Risk Measurement“) ْ ), ((PCF „Risk Determination“, PCF „Risk-Level Matrix“) ْ (PCF „Risk Assessment“, PCF „Risk-Level Matrix“) ْ (PCF „Threat Assessment“, PCF „Risk-Level Matrix“) ْ (PCF „Risk Analysis“, PCF „Risk-Level Matrix“) ْ (PCF „Risk Measurement“, PCF „Risk-Level Matrix“) ْ (PCF „Risk Determination“, PCF „Criteria“) ْ (PCF „Risk Assessment“, PCF „Criteria“) ْ (PCF „Threat Assessment“, PCF „Criteria“) ْ (PCF „Risk Analysis“, PCF „Criteria“) ْ (PCF „Risk Measurement“, PCF „Criteria“) ْ (PCF „Risk Determination“, PCF „Protection Requirements“) ْ (PCF „Risk Assessment“, PCF „Protection Requirements“) ْ (PCF „Threat Assessment“, PCF „Protection Requirements“) ْ (PCF „Risk Analysis“, PCF „Protection Requirements“) ْ (PCF „Risk Measurement“, PCF „Protection Requirements“) ْ (PCF „Risk Determination“, PCF „Control Recommendations“) ْ (PCF „Risk Assessment“, PCF „Control Recommendations“) ْ (PCF „Threat Assessment“, PCF „Control Recommendations“) ْ (PCF „Risk Analysis“, PCF „Control Recommendations“) ْ (PCF „Risk Measurement“, PCF „Control Recommendations“) ْ (PCF „Risk Determination“, PCF „Risk Treatment“) ْ (PCF „Risk Assessment“, PCF „Risk Treatment“) ْ (PCF „Threat Assessment“, PCF „Risk Treatment“) ْ (PCF „Risk Analysis“, PCF „Risk Treatment“) ْ (PCF „Risk Measurement“, PCF „Risk Treatment“) ْ ), ((PCF „Threat Definition“, PCF „IT-Grundschutz“) ْ (PCF „Threat Allocation“, PCF „IT-Grundschutz“) ْ (PCF „Threat Assessment“, PCF „IT-Grundschutz“) ْ (PCF „Threat Recognition“, PCF „IT-Grundschutz“))*} precedes_mbl = {(MBL „Scope Identification“, MBL „Asset Identification“), (MBL „Asset Identification“, MBL „Basic Security Check“), (MBL „Basic Security Check“, MBL „Threat Identification“), (MBL „Threat Identification“, MBL „Vulnerability Identification“), (MBL „Vulnerability Identification“, MBL „Security Assessment“), (MBL „Security Assessment“, MBL „Security Measures“), (MBL „Threat Identification“, MBL „Basic Security Check“)*} The function of returning the level of a method fragment is defined as level: MF → {n | n ‫ א‬N}

5.6 HatSec Security Analysis Method 28

Ihor = precedes ‫ ڂ‬precedes←

157

‫ ڂ‬produces ‫ ڂ‬produces←‫׊‬p1, p2 ‫ א‬MF | (p1, p2) ‫ א‬Ihor ֜ level(p1) = level(p2)

Ihor := { ((MF „System-Related Information“, MF „System Characterization“) ْ (MF „Asset Definition“, MF „System Characterization“) ْ (MF „IT Structure Analysis“, MF „System Characterization“) ْ (MF „Asset Valuation“, MF „System Characterization“) ْ (MF „Assets Visibility“, MF „System Characterization“) ْ (MF „System-Related Information“, MF „Scope Definition“) ْ (MF „Asset Definition“, MF „Scope Definition“) ْ (MF „IT Structure Analysis“, MF „Scope Definition“) ْ (MF „Asset Valuation“, MF „Scope Definition“) ْ (MF „Assets Visibility“, MF „Scope Definition“) ْ (MF „System-Related Information“, MF „Initialization of IT Security Process“) ْ (MF „Asset Definition“, MF „Initialization of IT Security Process“) ْ (MF „IT Structure Analysis“, MF „Initialization of IT Security Process“) ْ (MF „Asset Valuation“, MF „Initialization of IT Security Process“) ْ (MF „Assets Visibility“, MF „Initialization of IT Security Process“) ْ (MF „System-Related Information“, MF „Process Information“) ْ (MF „Asset Definition“, MF „Process Information“) ْ (MF „IT Structure Analysis“, MF „Process Information“) ْ (MF „Asset Valuation“, MF „Process Information“) ْ (MF „Assets Visibility“, MF „Process Information“) ْ (MF „System-Related Information“, MF „Security Framework Definition“) ْ (MF „Asset Definition“, MF „Security Framework Definition“) ْ (MF „IT Structure Analysis“, MF „Security Framework Definition“) ْ (MF „Asset Valuation“, MF „Security Framework Definition“) ْ (MF „Assets Visibility“, MF „Security Framework Definition“)), ((MF „System-Related Information“, MF „IT-Grundschutz“) ْ (MF „Asset Definition“, MF „IT-Grundschutz“) ْ (MF „IT Structure Analysis“, MF „IT-Grundschutz“) ْ (MF „Asset Valuation“, MF „IT-Grundschutz“) ْ (MF „Assets Visibility“, MF „IT-Grundschutz“) ْ), ((MF „IT-Grundschutz“, MF „Threat Definition“) ْ (MF „IT-Grundschutz“, MF „Threat Allocation“) ْ (MF „IT-Grundschutz“, MF „Threat Assessment“) ْ (MF „IT-Grundschutz“, MF „Threat Recognition“) ْ ), ((MF „Threat Definition“, MF „Vulnerability Definition“) ْ (MF „Threat Allocation“, MF „Vulnerability Definition“) ْ (MF „Threat Assessment“, MF „Vulnerability Definition“) ْ (MF „Threat Recognition“, MF „Vulnerability Definition“) ْ (MF „Threat Definition“, MF „Vulnerability Recognition“) ْ (MF „Threat Allocation“, MF „Vulnerability Recognition“) ْ (MF „Threat Assessment“, MF „Vulnerability Recognition“) ْ (MF „Threat Recognition“, MF „Vulnerability Recognition“) ْ (MF „Threat Definition“, MF „Risk Identification“) ْ (MF „Threat Allocation“, MF „Risk Identification“) ْ (MF „Threat Assessment“, MF „Risk Identification“) ْ (MF „Threat Recognition“, MF „Risk Identification“) ْ ), ((MF „Vulnerability Definition“, MF „Risk Determination“) ْ (MF „Vulnerability Recognition“, MF „Risk Determination“) ْ (MF „Risk Identification“, MF „Risk Determination“) ْ (MF „Vulnerability Definition“, MF „Risk Assessment“) ْ (MF „Vulnerability Recognition“, MF „Risk Assessment“) ْ (MF „Risk Identification“, MF „Risk Assessment“) ْ (MF „Vulnerability Definition“, MF „Threat Assessment“) ْ (MF „Vulnerability Recognition“, MF „Threat Assessment“) ْ (MF „Risk Identification“, MF „Threat Assessment“) ْ (MF „Vulnerability Definition“, MF „Risk Analysis“) ْ (MF „Vulnerability Recognition“, MF „Risk Analysis“) ْ (MF „Risk Identification“, MF „Risk Analysis“) ْ (MF „Vulnerability Definition“, MF „Risk Measurement“) ْ (MF „Vulnerability Recognition“, MF „Risk Measurement“) ْ (MF „Risk Identification“, MF „Risk Measurement“) ْ ), ((MF „Risk Determination“, MF „Risk-Level Matrix“) ْ (MF „Risk Assessment“, MF „Risk-Level Matrix“) ْ (MF „Threat Assessment“, MF „Risk-Level Matrix“) ْ (MF „Risk Analysis“, MF „Risk-Level Matrix“) ْ (MF „Risk Measurement“, MF „Risk-Level Matrix“) ْ (MF „Risk Determination“, MF „Criteria“) ْ (MF „Risk Assessment“, MF „Criteria“) ْ (MF „Threat Assessment“, MF „Criteria“) ْ (MF „Risk Analysis“, MF „Criteria“) ْ (MF „Risk Measurement“, MF „Criteria“) ْ (MF „Risk Determination“, MF „Protection Requirements“) ْ (MF „Risk Assessment“, MF „Protection Requirements“) ْ (MF „Threat Assessment“, MF „Protection Requirements“) ْ (MF „Risk Analysis“, MF „Protection Requirements“) ْ (MF „Risk Measurement“, MF „Protection Requirements“) ْ (MF „Risk Determination“, MF „Control Recommendations“) ْ (MF „Risk Assessment“, MF „Control Recommendations“) ْ (MF „Threat Assessment“, MF „Control Recommendations“) ْ (MF „Risk Analysis“, MF „Control Recommendations“) ْ (MF „Risk Measurement“, MF „Control Recommendations“) ْ (MF „Risk Determination“, MF „Risk Treatment“) ْ (MF „Risk Assessment“, MF „Risk Treatment“) ْ (MF „Threat Assessment“, MF „Risk Treatment“) ْ (MF „Risk Analysis“, MF „Risk Treatment“) ْ (MF „Risk Measurement“, MF „Risk Treatment“) ْ ), ((MF „Threat Definition“, MF „IT-Grundschutz“) ْ (MF „Threat Allocation“, MF „IT-Grundschutz“) ْ (MF „Threat Assessment“, MF „IT-Grundschutz“) ْ (MF „Threat Recognition“, MF „IT-Grundschutz“))*, ((MF „System Characterization“, MF „System-Related Information“) ْ (MF „System Characterization“, MF „Asset Definition“) ْ (MF „System Characterization“, MF „IT Structure Analysis“) ْ (MF „System Characterization“, MF „Asset Valuation“) ْ (MF „System Characterization“, MF „Assets Visibility“) ْ (MF „Scope Definition“, MF „System-Related Information“) ْ (MF „Scope Definition“, MF „Asset Definition“) ْ (MF „Scope Definition“, MF „IT Structure Analysis“) ْ (MF „Scope Definition“, MF „Asset Valuation“) ْ (MF „Scope Definition“, MF „Assets Visibility“) ْ (MF „Initialization of IT Security Process“, MF „System-Related Information“) ْ (MF „Initialization of IT Security Process“, MF „Asset Definition“) ْ (MF „Initialization of IT Security Process“, MF „IT Structure Analysis“) ْ (MF „Initialization of IT Security Process“, MF „Asset Valuation“) ْ (MF „Initialization of IT Security Process“, MF „Assets Visibility“) ْ (MF „Process Information“, MF „System-Related Information“) ْ (MF „Process Information“, MF „Asset Definition“) ْ (MF „Process Information“, MF „IT Structure Analysis“) ْ (MF „Process Information“, MF „Asset Valuation“) ْ (MF „Process Information“, MF „Assets Visibility“) ْ (MF „Security Framework Definition“, MF „System-Related Information“) ْ (MF „Security Framework Definition“, MF „Asset Definition“) ْ (MF „Security Framework Definition“, MF „IT Structure Analysis“) ْ (MF „Security Framework Definition“, MF „Asset Valuation“) ْ (MF „Security Framework Definition“, MF „Assets Visibility“)), ((MF „IT-Grundschutz“, MF „System-Related Information“) ْ (MF „IT-Grundschutz“, MF „Asset Definition“) ْ (MF „ITGrundschutz“, MF „IT Structure Analysis“) ْ (MF „IT-Grundschutz“, MF „Asset Valuation“) ْ (MF „IT-Grundschutz“, MF „Assets Visibility“)),

28

R← denotes the converse of R, i.e., the set {(y, x) | (x, y) ‫ א‬R}

158


((MF „Threat Definition“, MF „IT-Grundschutz“) ْ (MF „Threat Allocation“, MF „IT-Grundschutz“) ْ (MF „Threat Assessment“, MF „IT-Grundschutz“) ْ (MF „Threat Recognition“, MF „IT-Grundschutz“)), ((MF „Vulnerability Definition“, MF „Threat Definition“) ْ (MF „Vulnerability Definition“, MF „Threat Allocation“) ْ (MF „Vulnerability Definition“, MF „Threat Assessment“) ْ (MF „Vulnerability Definition“, MF „Threat Recognition“) ْ (MF „Vulnerability Recognition“, MF „Threat Definition“) ْ (MF „Vulnerability Recognition“, MF „Threat Allocation“) ْ (MF „Vulnerability Recognition“, MF „Threat Assessment“) ْ (MF „Vulnerability Recognition“, MF „Threat Recognition“) ْ (MF „Risk Identification“, MF „Threat Definition“) ْ (MF „Risk Identification“, MF „Threat Allocation“) ْ (MF „Risk Identification“, MF „Threat Assessment“) ْ (MF „Risk Identification“, MF „Threat Recognition“)), ((MF „Risk Determination“, MF „Vulnerability Definition“) ْ (MF „Risk Determination“, MF „Vulnerability Recognition“) ْ (MF „Risk Determination“, MF „Risk Identification“) ْ (MF „Risk Assessment“, MF „Vulnerability Definition“) ْ (MF „Risk Assessment“, MF „Vulnerability Recognition“) ْ (MF „Risk Assessment“, MF „Risk Identification“) ْ (MF „Threat Assessment“, MF „Vulnerability Definition“) ْ (MF „Threat Assessment“, MF „Vulnerability Recognition“) ْ (MF „Threat Assessment“, MF „Risk Identification“) ْ (MF „Risk Analysis“, MF „Vulnerability Definition“) ْ (MF „Risk Analysis“, MF „Vulnerability Recognition“) ْ (MF „Risk Analysis“, MF „Risk Identification“) ْ (MF „Risk Measurement“, MF „Vulnerability Definition“) ْ (MF „Risk Measurement“, MF „Vulnerability Recognition“) ْ (MF „Risk Measurement“, MF „Risk Identification“)), ((MF „Risk-Level Matrix“, MF „Risk Determination“) ْ (MF „Risk-Level Matrix“, MF „Risk Assessment“) ْ (MF „Risk-Level Matrix“, MF „Threat Assessment“) ْ (MF „Risk-Level Matrix“, MF „Risk Analysis“) ْ (MF „Risk-Level Matrix“, MF „Risk Measurement“) ْ (MF „Criteria“, MF „Risk Determination“) ْ (MF „Criteria“, MF „Risk Assessment“) ْ (MF „Criteria“, MF „Threat Assessment“) ْ (MF „Criteria“, MF „Risk Analysis“) ْ (MF „Criteria“, MF „Risk Measurement“) ْ (MF „Protection Requirements“, MF „Risk Determination“) ْ (MF „Protection Requirements“, MF „Risk Assessment“) ْ (MF „Protection Requirements“, MF „Threat Assessment“) ْ (MF „Protection Requirements“, MF „Risk Analysis“) ْ (MF „Protection Requirements“, MF „Risk Measurement“) ْ (MF „Control Recommendations“, MF „Risk Determination“) ْ (MF „Control Recommendations“, MF „Risk Assessment“) ْ (MF „Control Recommendations“, MF „Threat Assessment“) ْ (MF „Control Recommendations“, MF „Risk Analysis“) ْ (MF „Control Recommendations“, MF „Risk Measurement“) ْ (MF „Risk Treatment“, MF „Risk Determination“) ْ (MF „Risk Treatment“, MF „Risk Assessment“) ْ (MF „Risk Treatment“, MF „Threat Assessment“) ْ (MF „Risk Treatment“, MF „Risk Analysis“) ْ (MF „Risk Treatment“, MF „Risk Measurement“)), ((MF „IT-Grundschutz“, MF „Threat Definition“) ْ (MF „IT-Grundschutz“, MF „Threat Allocation“) ْ (MF „IT-Grundschutz“, MF „Threat Assessment“) ْ (MF „IT-Grundschutz“, MF „Threat Recognition“))*, ((MF „System Characterization“, MF „Scope“) ْ (MF „Scope Definition“, MF „Scope“) ْ (MF „Initialization of IT Security Process“, MF „Scope“) ْ (MF „Process Information“, MF „Scope“) ْ (MF „Security Framework Definition“, MF „Scope“)), ((MF „System-Related Information“, MF „Assets“) ْ (MF „Asset Definition“, MF „Assets“) ْ (MF „IT Structure Analysis“, MF „Assets“) ْ (MF „Asset Valuation“, MF „Assets“) ْ (MF „Assets Visibility“, MF „Assets“)), (MF „IT-Grundschutz“, MF „Threat Summary“), ((MF „Threat Definition“, MF „Threat List“) ْ (MF „Threat Allocation“, MF „Threat List“) ْ (MF „Threat Assessment“, MF „Threat List“) ْ (MF „Threat Recognition“, MF „Threat List“)), ((MF „Vulnerability Definition“, MF „Vulnerability List“) ْ (MF „Vulnerability Recognition“, MF „Vulnerability List“) ْ (MF „Risk Identification“, MF „Vulnerability List“)), ((MF „Risk Determination“, MF „Risk Evaluation“) ْ (MF „Risk Assessment“, MF „Risk Evaluation“) ْ (MF „Threat Assessment“, MF „Risk Evaluation“) ْ (MF „Risk Analysis“, MF „Risk Evaluation“) ْ (MF „Risk Measurement“, MF „Risk Evaluation“)), ((MF „Criteria“, MF „Security Level Acceptance“) ْ (MF „Risk-Level Matrix“, MF „Security Level Acceptance“) ْ (MF „Protection Requirements“, MF „Security Level Acceptance“) ْ (MF „Control Recommendations“, MF „Security Level Acceptance“) ْ (MF „Risk Treatment“, MF „Security Level Acceptance“)), ((MF „Scope“, MF „System Characterization“) ْ (MF „Scope“, MF „Scope Definition“) ْ (MF „Scope“, MF „Initialization of IT Security Process“) ْ (MF „Scope“, MF „Process Information“) ْ (MF „Scope“, MF „Security Framework Definition“)), ((MF „Assets“, MF „System-Related Information“) ْ (MF „Assets“, MF „Asset Definition“) ْ (MF „Assets“, MF „IT Structure Analysis“) ْ (MF „Assets“, MF „Asset Valuation“) ْ (MF „Assets“, MF „Assets Visibility“)), (MF „Threat Summary“, MF „IT-Grundschutz“), ((MF „Threat List“, MF „Threat Definition“) ْ (MF „Threat List“, MF „Threat Allocation“) ْ (MF „Threat List“, MF „Threat Assessment“) ْ (MF „Threat List“, MF „Threat Recognition“)), ((MF „Vulnerability List“, MF „Vulnerability Definition“) ْ (MF „Vulnerability List“, MF „Vulnerability Recognition“) ْ (MF „Vulnerability List“, MF „Risk Identification“)), ((MF „Risk Evaluation“, MF „Risk Determination“) ْ (MF „Risk Evaluation“, MF „Risk Assessment“) ْ (MF „Risk Evaluation“, MF „Threat Assessment“) ْ (MF „Risk Evaluation“, MF „Risk Analysis“) ْ (MF „Risk Evaluation“, MF „Risk Measurement“)), ((MF „Security Level Acceptance“, MF „Criteria“) ْ (MF „Security Level Acceptance“, MF „Risk-Level Matrix“) ْ (MF „Security


159

Level Acceptance“, MF „Protection Requirements“) ْ (MF „Security Level Acceptance“, MF „Control Recommendations“) ْ (MF „Security Level Acceptance“, MF „Risk Treatment“)), ((MF „System-Related Information“, MF „Scope“) ْ (MF „Asset Definition“, MF „Scope“) ْ (MF „IT Structure Analysis“, MF „Scope“) ْ (MF „Asset Valuation“, MF „Scope“) ْ (MF „Assets Visibility“, MF „Scope“)), (MF „IT-Grundschutz“, MF „Assets“) , (MF „IT-Grundschutz“, MF „Threat list“)*, ((MF „Threat Definition“, MF „Threat Summary“) ْ (MF „Threat Allocation“, MF „Threat Summary“) ْ (MF „Threat Assessment“, MF „Threat Summary“) ْ (MF „Threat Recognition“, MF „Threat Summary“),), ((MF „Vulnerability Definition“, MF „Threat List“) ْ (MF „Vulnerability Recognition“, MF „Threat List“) ْ (MF „Risk Identification“, MF „Threat List“)), ((MF „Risk Determination“, MF „Vulnerability List“) ْ (MF „Risk Assessment“, MF „Vulnerability List“) ْ (MF „Threat Assessment“, MF „Vulnerability List“) ْ (MF „Risk Analysis“, MF „Vulnerability List“) ْ (MF „Risk Measurement“, MF „Vulnerability List“)), ((MF „Criteria“, MF „Risk Evaluation“) ْ (MF „Risk-Level Matrix“, MF „Risk Evaluation“) ْ (MF „Protection Requirements“, MF „Risk Evaluation“) ْ (MF „Control Recommendations“, MF „Risk Evaluation“) ْ (MF „Risk Treatment“, MF „Risk Evaluation“)), ((MF „Scope“, MF „System-Related Information“) ْ (MF „Scope“, MF „Asset Definition“) ْ (MF „Scope“, MF „IT Structure Analysis“) ْ (MF „Scope“, MF „Asset Valuation“) ْ (MF „Scope“, MF „Assets Visibility“)), (MF „Assets“, MF „IT-Grundschutz“), (MF „Threat list“, MF „IT-Grundschutz“), ((MF „Threat Summary“, MF „Threat Definition“) ْ (MF „Threat Summary“, MF „Threat Allocation“) ْ (MF „Threat Summary“, MF „Threat Assessment“) ْ (MF „Threat Summary“, MF „Threat Recognition“)), ((MF „Threat List“, MF „Vulnerability Definition“) ْ (MF „Threat List“, MF „Vulnerability Recognition“) ْ (MF „Threat List“, MF „Risk Identification“)), ((MF „Vulnerability List“, MF „Risk Determination“) ْ (MF „Vulnerability List“, MF „Risk Assessment“) ْ (MF „Vulnerability List“, MF „Threat Assessment“) ْ (MF „Vulnerability List“, MF „Risk Analysis“) ْ (MF „Vulnerability List“, MF „Risk Measurement“)), ((MF „Risk Evaluation“, MF „Criteria“) ْ (MF „Risk Evaluation“, MF „Risk-Level Matrix“) ْ (MF „Risk Evaluation“, MF „Protection Requirements“) ْ (MF „Risk Evaluation“, MF „Control Recommendations“) ْ (MF „Risk Evaluation“, MF „Risk Treatment“))}

Figure 31: Formal Representation of the HatSec Method

The HatSec security analysis method consists of seven core security analysis steps: 1. Scope identification. 2. Asset identification. 3. Basic security check. 4. Threat identification. 5. Vulnerability identification. 6. Security assessment. 7. Security measures.

160

5 Designing a Security Analysis Method for Healthcare Telematics in Germany PCF „System Characterization“

Legend Relations: Security Analysis Method

PCF „Scope Definition“

+

1) 2) 3) 4)

+

PCF „Initialization of IT Security Process“ PCF „Process Information“

produces requires consists_of precedes_mbl

Tuples: 3)

mandatory optional

3)

PCF „Security Framework Definition“ 1) 3)

MBL „Scope Identification“

PCF „Scope“

3)

MBL „Security Measures“

PDF „Security Level Acceptance“ 1)

2) 3)

PCF „System-Related Information“

PCF „Criteria“

PCF „Asset Definition“

+

PCF „Risk-Level Matrix“

+

PCF „IT Structure Analysis“

4)

4)

+

+

PCF „Protection Requirements“ PCF „Control Recommendations“

PCF „Asset Valuation“ PCF „Risk Treatment“ 3)

PCF „Assets Visibility“

2) 1) 3)

MBL „Asset Identification“

PDF „Assets“

3)

MBL „Security Assessment“

PDF „Risk Evaluation“ 1)

2)

PCF „Risk Determination“

3)

4) PCF „IT-Grundschutz“

PCF „Risk Assessment“

3) 1) 3) PDF „Threat Summary“

MBL „Basic Security Check“

4)

+

+

PCF „Threat Assessment“ PCF „Risk Analysis“

2) PCF „Risk Measurement“ PCF „Threat Definition“ 2)

2) PCF „Threat Allocation“

+

+

PCF „Threat Assessment“

3)

MBL „Vulerability Identification“

PDF „Vulnerability List“

3)

3)

3) PDF „Threat List“

4)

1)

PCF „Threat Recognition“ 1)

4)

MBL „Threat Identification“

+ 4)

PCF „Vulnerability Definition“

+

PCF „Vulnerability Recognition“ PCF „Risk Identification“ 2)

Figure 32: The formal Composition of the HatSec Method (Source: own Figure)

The steps are filled by method fragments. User of the HatSec method decides which method fragment from the selected IS security analysis approaches fits best to their specific situation. After the selection of one method fragment, the HatSec method can be modified or adapted to the situation at hand. This is possible because of the identified method fragments. Figure 32

5.7 Review of the HatSec Security Analysis Method

161

illustrates the composition of these method fragments. The replaceability of method fragments and the interconnection between method fragments are illustrated as well. 5.7

Review of the HatSec Security Analysis Method


What are the advantages of the HatSec method compared to existing IS security analysis methods?

This section reviews the developed HatSec security analysis method according to its suitability for identified healthcare IS security approaches characteristics (Boudreau/Gefen/Straub 2001; Bortz/Döring 2002; Graf v.d. Schulenburg et al. 1995; Grimshaw/Russel 1998; Kim/ Johnson 2002; Scriven 1980). The review process in design science research covers a wide spectrum (Hevner et al. 2004). Most IS literature in recent years has recommended a combination of methodologies to strengthen the quality of the designed artifact: action research, case studies, laboratory experiments, characteristics-based evaluation and surveys (Kuechler/Vaishnavi 2008; Winter 2008; Järvinen 2007 ; Pries-Heje/Baskerville/Venable 2008; Ahlemann/Riempp 2008; Dias de Figueiredo/Rupino da Cunha 2007). These techniques help to validate and assess the constructed artifact. As proposed by (Pries-Heje/Baskerville/Venable 2008) and according to (Ahlemann/Riempp 2008) the derived characteristics of IS security approaches with respect to healthcare are used to define the concrete characteristics that should be fulfilled by the developed security analysis method. These requirements should be implemented by the HatSec method as they structure the problem domain and define the review framework parameters (Kim/Johnson 2002). The starting point for the development of the HatSec method was the idea to create a security analysis method specific to healthcare telematics objectives. Furthermore, the development was based on established existing IS security analysis methods. This means that the HatSec method provides building blocks that were identified as the core components of every IS security analysis method and on the other hand these building blocks fit to healthcare IS security approach characteristics best. Considering these aspects, the HatSec method was used during the analysis of German healthcare telematics (Chapter 6). Table 27 presents the examination of the HatSec method in regards to healthcare IS security approach characteristics.

162

5 Designing a Security Analysis Method for Healthcare Telematics in Germany Characteristics-based Review of the HatSec Method Characteristics

1

Name of the approach

2

Vendor name

3

Current version

4

Availability - For free

5

Assessment

Short Description

HatSec

The method is named HatSec (Healthcare Telematics Security).

TUM

The Technische Universität München is the source of this IS security approach.

1.0

HatSec is freely available. 5

Languages available

Version 1.0 HatSec supports only the English language.

- German

0

- English

5

6

Research activity

5

7

Skills needed / Time and effort - to introduce - to use

5

- to maintain

5

8

Consultancy support

5

9

Identification of the IS security approach 5 0

The country of origin

11

Level of reference of the IS security approach

The skills needed to understand, maintain or perform the HatSec method in the organization accord to the usual skills of a CISO.

External help (consultancy) is not necessary to apply the HatSec method. HatSec is a healthcare IS security analysis method.

- standard - regulation

10

Extent, scope, transparency, independency are the characteristics of undertaken research.

5

- method

- guideline

The current version of HatSec.

0 0 5DE

The HatSec method was developed in Germany. The initiator for the development of HatSec method is a public/government organization.

-National Standardization body

0

-European Standardization body -International Standardization body

0 0

-Private sector organization -Public / government organization

0 0

12

Geographical spread

0

The HatSec method was only applied in Germany.

13

Lifecycle / Actuality

5

The HatSec method is a completely new IS security approach.

14

Fundamental objectives and IS security approach scope

5

The HatSec method aims to achieve expected results, improvements and requirements.

15

Completeness 5

The HatSec method is described in detail by method building blocks.


163

Characteristics-based Review of the HatSec Method Characteristics

Assessment

Short Description

- Management level

5

Due to its flexibility the HatSec method targets all levels of details.

- Operational level

5

- Organizational level

5

17

Scalability

5

Due to its flexibility the HatSec method is very scalable.

18

Target organizations -Governments, agencies

5

The HatSec method is aimed at all target organizations in the healthcare field.

-Large health organizations -Small and Medium Size health organizations

5

16

19

Level of detail

5

-Commercial health organizations

5

-Non-profit

5

-Specific sector

5

5

The HatSec method includes a comprehensive standard security analysis.

Supporting heterogenic, decentralized information systems

5

The HatSec method considers heterogenic, decentralized information systems.

21

Process oriented evaluation method

5

22

Organizational Focus

20

Security Analysis

- Organizational - Technical

5 5

23

Pro-active security analysis

24

Comparable and reusable results

25

Maturity level

26

Available tools

27

Certification scheme

28

Optimal investment sum

29

Organizational integration

30

Branch

31

The HatSec method focuses on the security issues at the process level. The HatSec method targets organizational risks, which result from the interaction of people with the information systems and also considers the implications of a technical failure of the information systems on patient security.

5

The HatSec method distinguishes between preventive/proactive and reactive security analysis.

5

Due to the use of method building blocks from established IS security standards the HatSec method ensures comparable and reproducible results.

5

The HatSec method provides a measurement of the maturity of the information system security.

0

The HatSec method does not include any further supporting tools.

0

The HatSec method does have a certification scheme.

5

Due to its flexibility the HatSec method can be applied without further investment.

5

- Healthcare

5

Target audience in the healthcare branch

5

The HatSec method supports interfaces to existing processes within the health organization. The HatSec method is aimed specifically at the healthcare branch. The HatSec method is aimed at: health consumers, healthcare providers, health funders, the state, the healthcare telematics infrastructure.

164

5 Designing a Security Analysis Method for Healthcare Telematics in Germany Characteristics-based Review of the HatSec Method Characteristics

Assessment

Short Description

32

Compliance

5

The HatSec method complies with German law and regulations.

33

Hazard list relevant to healthcare

5

The HatSec method proposes healthcare generic hazards.

34

Security requirements relevant to healthcare

5

The HatSec method proposes healthcare security requirements.

35

Security measures relevant to healthcare

5

The HatSec method proposes healthcare security measures.

36

Risk valuation guidelines relevant to health

5

The HatSec method proposes healthcare valuation of risk.

37

Security measures point of view

5

The HatSec method can provide security measures according to the patient’s point of view as well as to the IS security point of view.

38

Requirements for confidentiality, privacy, integrity, availability of information

5

The HatSec method fulfills all IS security requirements.

39

Data quality requirements

5

The HatSec method fulfills requirements for completeness, validity, consistency, timeliness, and accuracy of the data.

40

Physical and environmental security

5

The HatSec method analyzes the physical security of information systems.

Legend:

1 – not covered

2 – predominantly not covered

3 – partially covered 4 – predominantly covered

5 – covered

Table 27: Characteristics-based Review of the HatSec Method (Source: own Table)

It is obvious that this review is based on concrete statements about the building blocks used in HatSec. One can legitimately argue that such a review applies to security analysis steps taken from analyzed and already existing IS security analysis methods. This also explains the fact that there are only completely fulfilled characteristics or characteristics that are not fulfilled at all. The explanation for this fact lies in the basis for the development of HatSec. The healthcare IS security approach characteristics for a security analysis method that are not fulfilled by the HatSec method are the characteristics that were not needed to analyze the open security issues in German healthcare telematics. The HatSec method differs from all other identified IS security analysis approaches primary in following points: focus (healthcare domain; technical and organizational analysis of the security requirements and their implementation in German healthcare telematics), completeness (consolidation of identified IS security approaches while taking the best parts of them into HatSec`s consideration), timeliness (taking advantage of the latest findings in the area of the socio-technical IS security) and finally the regional focus (local conditions in Germany, political and regional framework, German legislation and regulations).


165

Table 28 summarizes the characteristics-based reflection as conducted in section 4.6. General IS Security Approach Characteristics



HatSec Method

4

4

5

ISO/IEC TR 13335-3 (ISO/IEC TR 13335-3 1998; Ayalp 2006)

4

2

2

ISO 27001 (ISO/IEC 2005b)

4

3

2

ISO 27004 (ISO/IEC 2005c)

4

2

1

ISO 17799 (ISO/IEC 2005a)

4

3

2

ISO 14971 (ISO 14971:2007 2007)

5

3

3

HIPAA (Department of Health and Human Services 2005; Anton et al. 2007; Artnak/Benson 2005)

4

3

3

Odessa (Warren/Furnell/Sanders 1997)

4

3

3

Octave Method (Alberts/Dorofee 2001; Alberts et al. 2003)

4

3

1

FDA Guidance for Industry1 Q9 Quality Risk Management (Food and Drug Administration 2006)

4

3

2

CRAMM (CRAMM 2003)

4

3

2

NIST SP 800-30 (National Institute of Standards & Technology 2002)

4

3

2

ISO 27799 (ISO/FDIS 27799:2007(E) 2007)

4

4

4

ISMS JIPDEC for Medical Organisations (JIPDEC 2004)

4

3

3

IT-Grundschutzhandbuch (BSI 2005)

5

3

2

ISRAM (Karabacaka/Sogukpinar 2005)

3

2

2

HB 174-2003 (Standards Australia International/Standards New Zealand 2001)

4

3

3

3

2

CRISAM (Stallinger 2004) Legend:

1 – not covered 4 – predominantly covered

4 2 – predominantly not covered 5 – covered

3 – partially covered

Table 28: Abstract of the Characteristics-based Reflection of the HatSec Method (Source: own Table)

5.8

Summary

This chapter provided a formal description of method engineering. Using a structured research approach first the existing literature on IS method engineering approaches was examined. Based on the literature review the construction and description of the concept of method engineering was discussed. Then a detailed approach for formalizing the concept of method en-

166


gineering was presented, unveiling the method fragments and its relations that underlie formalization design. Next, the HatSec method was designed according to the derived formalization rules. It also demonstrated a possible application of the introduced formalization of method engineering in research and practice. The formalization of the concept of method engineering discussed can be used to describe each part or element of almost any IS method. Therefore it can be applied to obtain information about the structure and the underlying assembling technique. This knowledge can help to develop new methods and to alter existing methods so as to adapt them to the specific situation at hand. Furthermore, due to the formal description of methods and in comparison to descriptive texts in use today, the method engineering becomes more traceable. This modular approach allows a transparent and understandable design of the processes and method development itself. In particular, formal description of methods enables automated (computer-assisted) method engineering. The developed HatSec method was applied in practice; the results of this application are presented in the next chapter of this thesis in detail.

6

Practical Application of the HatSec Method

The goal of this chapter is an examination of the application benefits of the designed artifact under specific conditions. This chapter presents the practical application of the developed HatSec security analysis method in selected cases. Figure 33 illustrates the core elements of the following discussion.


Finding the Implications and Recommendations for Future Healthcare Telematics Security Trade-offs by applying the HatSec Method

6.1 Selected Case Studies Assessment and Classification of Threats around the electronic Health Card

Analysis of the Applications of the electronic Health Card Practical Application of the HatSec Method

Analysis of a Proposed Solution for Managing Doctor’s Smart Cards in Hospitals Using a Single Sign-On Central Architecture Security Analysis of the German electronic Health Card`s Components on a theoretical Level Security Analysis of the German electronic Health Card`s peripheral Parts in Practice

6.7 Case Studies: Lessons Learned

Implication

Results of the Security Analysis of the German Healthcare Telematics and according Design Proposals for identified Security Problems


The analysis of the German healthcare telematics using the HatSec method is also chosen as a case-based application of the developed artifact (Grant/Ngwenyama 2003; Dias de Figueiredo/Rupino da Cunha 2007) and seen as final segment in this thesis. The objective hereby is to determine how the HatSec method could best be used in practice. During the development of this thesis, the HatSec method was used in different settings by analyzing the security status of healthcare telematics in Germany. It was checked whether the HatSec method could adapt to specific situations at hand. This was done by examining the practical use of five different security analysis parts. Furthermore, practical application of the designed method serves as a tool for decision support in finding an appropriate solution for a given problem (Gustafson/Wyatt 2004; Klecun/Cornford 2005).


168

6 Practical Application of the HatSec Method

An overview of the selected research methodology that was used to construct and apply the HatSec method was provided in Figure 2 (section 1.3.2). 6.1

Selected Case Studies

According to the design science methodology (section 1.3.1) and to the research design used in this thesis (section 1.3.2), this section applies the HatSec security analysis method practically in a series of selected cases. On the one hand, case-based application of HatSec method strengthens the characteristics-based review (section 0) and thereby supports the underlying design theory of the constructed artifact. Also the performed security analysis of German healthcare telematics demonstrates the partial initiation of the HatSec method in practice (Baskerville/Wood-Harper 1996). The practical application of the HatSec method is useful and indispensable (as a demonstration) for both research and practice. The underlying and presented results of the security analysis consist of five parts. Each of these parts represents concrete problem solutions that were developed during the analysis of the security issues of the healthcare telematics in Germany. The results of the security analysis are introduced in detail and comprise at least one of the steps of the HatSec method. So the HatSec method was partially applied according to its steps. The following results of the conducted security analysis of the German healthcare telematics are used in this thesis as case studies. These case studies were performed in order to practically apply the HatSec method to demonstrate its feasibility and to explore any limitations of the presented approach (Figure 34).

Case 3

Case 2

Analysis of a Proposed Solution for Managing Health Professional Cards in Hospitals Using a Single Sign-On Central Architecture

Analysis of the Applications of the electronic Health Card Case 1 Assessment and Classification of Threats around the electronic Health Card Case 4 Security Analysis of the German electronic Health Card`s Components on a theoretical Level

Case 5 Security Analysis of the German electronic Health Card`s peripheral Parts in Practice

Figure 34: Overview and Correlation of the performed Case Studies (Source: own Figure)

Identification of possible attackers and attack types is the first result of security analysis of German healthcare telematics. The results of this step are later used to conceptualize potential

6.1 Selected Case Studies

169

attacks on German healthcare telematics and its peripheral components. To achieve these results, statistics, common classification schemes, and other resources are used. During the second step of the HatSec method, the assets of healthcare telematics, security, legal requirements, and security measures are identified. Therefore in this step the assets, requirements and measures are selected and described in detail. The tools for the accomplishing step two are healthcare telematics system’s legal documents, results from previous risk analyses, or simply the basic objectives of IS security. The third and fourth steps are the central steps, during which analysis activities actually take place. Step three contains activities of a theoretical nature. These can be, for example, an Attack-Tree Analysis (cp. (Huber/Sunyaev/Krcmar 2008b)) or the application of proper metrics to measure security. This step also contains analysis activities in a practical way. This includes, for example penetration tests, the use of one or more exploitation frameworks or the use of individual tools such as port scanners, dedicated exploits, brute forcing tools, etc. The results of steps three and four are used to improve and complete the activities complementary. The synchronization of these steps results in a more complete and accurate analysis, as both, theoretical and practical activities are used. These steps improve each other by completing a basic security check as proposed by (BSI 2005). Step five contains a recap of the previous steps’ results. In steps six and seven, activities are chosen to minimize the risks posed by the uncovered vulnerabilities and weaknesses. The selected case studies provide answers to the following research questions (section 1.2): 4.1.

How does the practical application of the HatSec method look like?

4.2.

What are the current open security issues of the German healthcare telematics?

4.3.

6.2

What practical implications can be derived for the further development of the German healthcare telematics from the security point of view based on the results of the practical application of the HatSec method?

Assessment and Classification of Threats around the Electronic Health Card

The first case study considers the identification and the classification of attackers and attacks on German healthcare telematics. The results of this case study are used as a starting point for the security analysis. The goal of the first case study is to test the applicability of the method’s fourth step. The first case study demonstrates that the according part of the HatSec method worked and that the identification of possible threats can define abstract as well as very precise threat list. The first case study explores the question of whether the HatSec method is applicable to German healthcare telematics, due to the manual effort needed to decide, which met-

170


hod fragment is to be used during the threat analysis. To answer this question, further case studies were performed. They are presented later in this chapter (sections 6.3, 6.4, 6.5 and 6.6). Figure 35 illustrates the concrete implementation of the HatSec method in this case study.


f


e


Identification and classification by: x Classification schemes x Statistics x ...

Identification and classification of attackers and attacks

g h


Security Assessment

Figure 35: Threats Identification according to the HatSec Method (Source: own Figure)

The results identified, classified and assessed possible threats to the electronic health card. Concerning the design and the development of the HatSec method, this case is the first practical application of the HatSec method. This case is performed exactly according to the threat identification step of the HatSec method. This suggests that the HatSec method is flexible according to its scope definition and that HatSec can cover all the realistic span of a security analysis both on the technical and organizational levels for every healthcare information system. Nonetheless, the results were specific to planned healthcare telematics in Germany and formed the basis for further steps and a continuous security analysis as proposed in section 5.6.2.5. As expected the initiation of this part of the HatSec method provides results that future security analysis can integrate. Although this case study displays the actual applicability of part of the HatSec method, their explanatory power is restricted, due to the fact that the analysis was based on threat analysis provided by other security analysis approaches. 6.2.1

Overview

This section offers an identification and classification of possible attackers and attacks on plans to introduce the electronic health card and on the underlying telematics infrastructure in Germany. More transparency in the IS security should be created for patients and care pro-

6.2 Assessment and Classification of Threats around the Electronic Health Card

171

vides and possible security vulnerabilities should be identified in order to develop project-accompanying measures before the electronic health card will be introduced in Germany (Kluge 2004; Smith/Eloff 2002). Furthermore, a classification and assessment of the attacker- and attack-types will contribute to the identification of the possible security vulnerabilities in the planned introduction of the eHC in the test region as well as to develop problem-specific solution approaches for them (Coleman 2004). Identification and Classification of the Attackers

low

Know-how

high

6.2.2

h hig t en itm m

om

low e c m Ti low

high Ressource commitment

Figure 36: Attacker Models (Source: according to (Gerloni et al. 2004))

In order to be able to evaluate the security of a system it is necessary to identify and evaluate the possible attackers. Some attackers, for example, can possess significant information technology knowledge and sophisticated IT skills, while others may use their own capital to finance knowledge and specialized technology to conduct attacks. (Gerloni et al. 2004) support the model depicted in Figure 36, which classifies the attacker according to their attributes: know-how, resources and time input. Regarding the aims pursued by the respective groups of attackers, Schneier mentions “[…] damage, financial profit, information, etc.” (Schneier 2004a), (Gerloni et al. 2004) further mentions competitive advantages and power ambitions. In the following classification these aims are used as basic attacker objectives. Furthermore these basic aims are expanded by the inclusion of other specific aims. Estimation of the relevance of an attacker group in the eHC

172


area is based on plausibility and is subjectively assessed and summarized in Table 29 according to the criteria already defined. Attacker Group Hackers

Goals Knowledge greed, interest in the system, publicity / selfportrayal / esteem / glory, further education, “respectable goals”, vandalism, (ordered) stealing of information.

KnowHow

max Res.

max Time

70-100

5

80

Script kiddies

Vandalism, curiosity, publicity / self-portrayal / esteem / glory, boredom, play instinct.

0-30

1

20

Industrial espionage

Competitive advantage, injury to the interests of the competition.

0-100

60

70

Malicious insiders

Revenge, financial interests and advantages, publicity, information theft while changing employer.

50-100

5

60

Organized crime

Financial interests, acquisition of information and goods.

0-100

100

100

Malware

Vandalism, self-spreading, information theft, publicity / self-portrayal / esteem / glory of the developer.

50-100

–

100

(Cyber-) terrorism

Destroying of the infrastructure, blocking the infrastructure, spreading fear.

0-100

30

90

Media

Publicity, exposure of vulnerabilities geared towards the media.

50-100

10

40

The estimations of “Know-how”, “Resource commitment” and “Time commitment” were conducted on a scale from 0 to 100, where 0 is the minimal and 100 is the maximal value.

Table 29: Classification of the Attacker Groups in the eHC Area (Source: according to (Sunyaev et al. 2008a))

Hackers (cf. (Schneier 2004b), (Gerloni et al. 2004) and (Eckert 2006)): Strong interest from hackers in the eHC is to be expected in the initial phase. This is due primarily to the size of the telematics project and the brisance of the related data. After the initial interest, only rare highly specialized attacks are to be expected (possibly at the order of a third party). Script kiddies (cf. (Schneier 2004b), (Gerloni et al. 2004) and (Eckert 2006)): Big numbers of script kiddies attacks are anticipated on areas that are extremely difficult to protect (e.g. distributed denial-of-service attacks). Also it is conceivable, that in the primary systems area problems can arise through the inadequately protected infrastructure (Sunyaev et al. 2008e). Industrial espionage (cf. (Schneier 2004b), (Gerloni et al. 2004) and (Eckert 2006))): in the eHC area industrial and economical espionage among the funding agencies or service providers are potential problems. Achieving a competitive advantage is one possible motivation for this potential risk.


173

Malicious insiders (cf. (Schneier 2004a) and (Eckert 2006)): Malicious insiders can appear in any area of healthcare. Insiders from the central areas of the telematics infrastructure as well as from the decentralized areas where funding agencies and care providers are situated are conceivable attackers. Organized crime (cf. (Schneier 2004b), (Gerloni et al. 2004) and (Eckert 2006)): Healthcare is a lucrative and interesting target for organized crime. The following activities are conceivable: trading with counterfeit health cards, fraudulent care obtained through manipulating the eHC, electronic prescriptions etc., blackmailing through data theft, selling of stolen medical profiles and so on. Malware (cf. (Gerloni et al. 2004) and (Eckert 2006)): Similar to all other information systems, the telematics infrastructure is also threatened by malware. The decentralized areas are especially at risk while staying under the administration of healthcare providers. In these areas the necessary expertise for establishing and maintaining sufficient protection from malware often does not exist. This is less likely to be an issue with centrally administered components and their corresponding IT personnel. (Cyber-) terrorism (cf. (Schneier 2004b) and (Nelson et al. 1999)): All insured patients are involved in the processes of healthcare telematics infrastructure (TI). The security of the TI is under some circumstances essential for maintaining the health or even the life of an insurant. This makes the TI a possible target for the terror-motivated attacks. The more the TI integrates with the healthcare system and the more the healthcare system depends on the TI, the more devastating the effects of its destruction or damage be. Media: Attacks from the media are especially likely during the initial phase of eHC introduction. An exclusive highly publicized story that, for example, questions the high cost of eHC introduction after discovering supposed vulnerabilities would be of great interest to the media. There is a multiplicity of attacker groups with different motives and capabilities. The next logical step is the identification of possible attack types. 6.2.3

Identification and Classification of the Attack Types

Similar to the classification of attackers, the potential attack types against the telematics infrastructure are systematized according to the suitable criteria. The origin of the attacker as well as his intentions and technical resources can be essential for the differentiation of attack types. In the following section the differentiation of attacks is done according to their technical basis and origin ((Eckert 2006), (Gerloni et al. 2004)). After this the differentiation according to

174


intention is processed (cf. (Schneier 2004b)). The classification of the attacks is summarized in the Figure 37.

Intention Criminal attacks

Breaches of confidentiality

Publicity attacks

Legal attacks

Origin Internal attacks

External attacks

Technological basis Active attacks

Passive attacks

Autonomous attacks

Legend: Attack type Classification criteria for attack types

Figure 37: Classification of Attacks (Source: according to (Sunyaev et al. 2008a))

Active/passive attacks: Contrary to passive attacks a successful active attack, results in an attacker gaining the ability to modify data stored on the distributed servers of the TI. Attacks such as spoofing and denial-of-service attacks also belong to this class. The telematics infrastructure is primarily exposed to this kind of attacks. Autonomous attacks: These attacks are performed autonomously by malware and executed without further involvement by the attackers (e.g. worms). As mentioned previously, the decentralized areas of the IT are especially at risk from these attacks. Internal and external attacks: The difference between internal and external attacks lies in whether the attack comes from outside of the TI or from inside it. In the area of healthcare both variants are possible. Criminal attacks: “How can I achieve the biggest financial gains through an attack on a system?” – this is the central question of all criminal attacks (Schneier 2004b). Criminal attacks are carried out by attacker groups that have financial motives, as explained in the classification presented above. This attack type is entitled to special attention from the data privacy perspective. Sensitive medical information being sold to third parties is an especially serious threat in this category.


175

Breaches of confidentiality: Breaches of confidentiality can in part be included in the criminal attack class although not all breaches of confidentiality are illegal. According to (Schneier 2004b) two actions should be differentiated in this class: targeted attacks on the one side and data-harvesting on the other. Data-harvesting denotes the process of collecting freely available data, compiling it, and deriving further valuable data from it, for instance through data mining. Administrative patient data is the primary target of this attack type. In contrast, an example of legal data-harvesting is the payback system, where millions of customers share information about their buying habits to the market research companies in exchange for small premiums. Direct attacks, such as stalking or industrial espionage, stand in contrast to this. Concerning breaches of confidentiality, the following attacks related to eHC are conceivable: surveillance, corresponding usage of databases, analyzes of data exchange as well as massive electronic surveillance. Publicity attacks: Publicity attacks have aim to achieve media attention through a successful attack on a system. Groups potentially interested in this kind of attack in the healthcare domain include hackers, script kiddies, insiders, malware, and even the media itself. Legal attacks: Legal attacks attempt to convince the (often technically unsophisticated) justice system that a informations system has vulnerability in order to discredit system security. The following case is an example of such an attack: a law enforcement agency uses the mobile telephone of a suspect to track his position and as evidence of their guilt of committing a crime. A potential legal attack in this area would be to prove that the terminal identification of the mobile communication of the user can be counterfeited and hence the suspect cannot be identified with a 100% certainty through this means. The aim of a legal attack is therefore not “[…] to exploit the vulnerability of a system or to find a vulnerability in a system. The aim is to convince the judge and the jury (who probably are not technically experienced) that a system could have a vulnerability to discredit the system and to create enough disbelief in the perfection of the system in order to prove the innocence of the suspect.” (Schneier 2004b). Such attacks can occur from outside or by order of the care provider. 6.2.4

Summary

The threats surrounding the electronic healthcare were classified and assessed. The unique feature of the evaluation of eHC security lay primarily in the size of the entire project, the sensibility of data, and its media exposure. From this it can be assumed that a large number of attackers with varying motives and tactics should be considered. It also stands to reason that because of the complexity of the project (especially through a big number of systems involved), the security issues involved are accordingly complex. According to the first step of the HatSec method and the conducted classification and assessment scheme, possible security

176


problems will primarily be found in the connections to the primary systems. Therefore it is critical to identify possible security risks in the test phase and to develop corresponding measures to counter these risks. Based on this analysis it will be possible to counter possible threats with appropriate protection mechanisms that will contribute to higher acceptance of the eHC. High acceptance on the side of service providers as well as on the side of patients is a significant success factor for the introduction of the electronic health card in Germany. Many patients are currently unsettled by the planned introduction of the eHC. This skepticism can be countered through the encouragement of transparency. 6.3

Analysis of the Applications of the Electronic Health Card

The second case study involves an analysis of applications of the electronic health card at healthcare sites. The results of this case study demonstrate the process orientation of the HatSec method and identify the assets for further security analysis. The goal of the second case study is to see the qualification of the HatSec method for the analysis of the organizational settings in the healthcare environments. This case study show that the HatSec method worked and that business processes can be modeled and analyzed. The second case study explores whether the HatSec method is applicable on the process level.

Security Analysis Context and Preparation

c


d



f


g

h

e


Methodical analysis by: x Applications analysis x Process reorganization x ...

f

Process Analysis / Identification of Assets


Security Assessment

Figure 38: Process Analysis according to the HatSec Method (Source: own Figure)

This part analyzes the applications of the electronic health card in medical practices. The results were specific to German healthcare telematics and served as extended input for further

6.3 Analysis of the Applications of the Electronic Health Card

177

steps and a continuous security analysis. Figure 38 illustrates the concrete implementation of the HatSec method in this case study. The problem of this case study is that the security aspects are not the core focus. This case is intended to identify the assets for further security analysis and to be a demonstration of the process orientation of the HatSec method. Due to the fact that during the performance of this analysis the electronic health card was not introduced, the analysis concentrates on benefit applications and possible process reorganization in physicians’ practices. 6.3.1

Overview

For this evaluation of the eHC’s applications at a healthcare site a dental was chosen as the test site. To analyze the direct effect of the eHC, a process analysis was conducted on actual and future eHC processes. To explore potential user acceptance of the eHC a patient survey was conducted using 49 patients. The benefits for all involved parties were observable. Based on these analyses, several conclusions are drawn for improving eHC introduction plans in Germany. The introduction of the eHC and its extended applications has several direct effects on medical sites. The handling of medical data in a practice is affected, and because of this subsequent process reorganizations have to be analyzed (gematik 2006q) (the internal processes have to be adapted to the eHC). This section analyzes these effects and changes. Furthermore, the results give offers advice to doctors and eHC developers on improving the functions and usability of the eHC. The detailed analyses were made in a dental practice used a test site. Afterwards, the results were compared and transferred to other healthcare sites. 6.3.2

Data Acquisition

In order to analyze the introduction of the eHC in Germany, all of the processes were observed in a dental practice for two months. Thirteen different processes were identified and written down (e.g. prescription issuing, invoice writing). To confirm these results the employees were interviewed about their daily work routines (as recommended (Morris et al. 2005)). Afterwards the results were compared to the previously observed processes. Finally these results were also compared to the processes in other medical practices, which were observed for shorter periods of time. Furthermore, an analysis of these processes was carried out. In this case a mixture of the methods written questionnaire and interview was used (Rubin/Babbie 2004). The participants were chosen randomly. All patients entering the doctor’s practice during the time of the evaluation were asked to fill out a written questionnaire (Schnell/Hill/Esser 2005).

178


Twenty randomly chosen patients were also interviewed personally (oral interviews) in order to obtain more background information and to reduce the disadvantages of the written questionnaire29. Due to the random choice of participants and the practice non-specific questions the results can be transferred to any medical practice. 6.3.3

Process Analysis

6.3.3.1 Actual Process The process in the dental practice used as a test site was modeled in an event-driven process chain (EPC) notation (Davis 2004). For a better overview the processes were divided into the main process and several process groups. The main process (Figure 39) is based primarily on the patient’s clinical pathway through the doctor’s practice. The process starts with patients entering the doctor’s practice and the registering at the practice reception. Depending on whether the patient needs a new prescription or a treatment, a particular process group will be applied. The main process continues with the preparation of the therapy and, if needed, request for information by the medical assistants at the reception or by the doctor. It continues with a waiting sequence for the patient or the treatment by the doctor. After the attendance, the medical assistants start with the post-processing of the therapy. If needed, the patient receives a prescription. When all these activities are finished and the patient has left the doctor’s practice, process groups, like “cleaning instruments”, which do not involve the patient anymore, are applied. Regardless whether a new patient has entered the doctor’s practice or not, the medical assistants have to clean the therapy room and all used instruments. They also have to check the material and, if needed, order new material. Depending on whether a new patient has already arrived, the doctor could start with the next therapy. If nobody has turned up, he could write bills and medical cost schedules. This whole process is nearly the same in every doctor’s practice. The process only differs in the focus of medical treatment.

29

All advantages and disadvantages of an interview can be looked up in (Schnell/Hill/Esser 2005).

6.3 Analysis of the Applications of the Electronic Health Card patient enters doctor´s practice

179

V

register/ greet

treatment is neccassery

reception

generate prescription incl. data check

wants prescription

XOR

V prepare therapy

V

XOR

free treatment room and short waiting time

XOR

therapy / discussion

V

request information

information saved digitally

engaged treatment room / longer waiting time

keep patient waiting

finished therapy / discussion

finished therapy / discussion finished prescription

V

postprocessing

generate prescription no present patient

XOR

V

V

V

XOR

clean treatment room

write medical cost schedules / future planning

write bill

clean material

made appointment

received invoiced valur

material is clean

cleaned treatment room

V

assistant

new patient present / arrives

Figure 39: Actual Process without eHC (Source: according to (Sunyaev et al. 2009c))

clean instruments

instruments are claen

180


6.3.3.2 Process Groups missing information (mostly at new patients)

contact details of former doctor

V

request fluoroscopic images/ consulting former doctor

V

forms are filled out

medical data / anamnesis

V

scan and save

reception

reception or doctor

V

patient

V

fill out anamnesis form / BFS form

needed information received analog

needed information received digitally

save information

V

request information

V

no more analog information present

medical data


return original documents / disposal of copies

reception

Figure 40: Example Process Group: “Request of information” without eHC (Source: according to (Sunyaev et al. 2009c))

The process group most affected by the introduction of eHC is the process group “request of information”. Figure 40 explains this process in detail. If a new patient needs a treatment the reception team usually has to gather the information required for the patient’s treatment. This is done by consulting former doctors and requesting past fluoroscopic images. Digital sent images are then stored in the primary computer system. Analog images have to first be scanned by the medical assistants and then be stored in the primary computer system. Additionally, the patient has to fill out a BFS form and an anamnesis form with his health issues. The BFS form is an exception in the practice used as a test site. It is a form for the BFS health finance


181

GmbH, a factoring agency. This form is needed for billing and has nothing to do with the eHC or the medical therapy. Therefore the BFS form is not considered further. The medical team has to scan these filled out forms and store them in the doctor’s computer system. When all of the necessary information is collected the doctor can easily access it with his computer in the therapy room. Analog images or documents are no longer needed and will return to the previous doctor or will be disposed of if they are copies. In paper-based practices data is collected in paper-based patient records and the assistants have to prepare this record for the doctor. Digital information can also be printed and stored in a paper-based patient record. There are also several mixed forms possible. Due to the documentation requirements imposed on healthcare practitioners the documents have to be stored at the doctor’s practice (Walter 2008). 6.3.3.3 Future Process with eHC write data on EHC

doctor

data is to be written to EHC

update medical data in EHC

HPC with PIN, patient´s admission medical treatmant process / plan

data saved on EHC

Figure 41: New Process: “Writing Data on eHC” (Source: according to (Sunyaev et al. 2009c))

Based on the main process, a future process including the eHC was designed. In designing the future process, the generic processes of the eHC were used (Liftin et al. 2004). Also the estimated time spans of the new process steps have been calculated. It was considered that telemedicine and telematics applications could only become establish in everyday use if their changes do not interfere with current processes or even have advantages for common processses (Warda/Noelle 2002). The main structure of the process groups stays the same. One difference is that the process group “writing data on eHC” is added. The new process group is run at the same time as the

182


process groups “writing medical cost schedules / future planning” and “writing bill” (Figure 41).

missing information (mostly at new patients)

V patient

reception

request information with EHC

filling out BFS form

enter PIN

medical data / anamnesis

scan and save

patient

entered PIN information available

form is filled out

reception

PIN request

(possible intermediate storage in primary system) use of needed information

V

request information

reception


Figure 42: Future Process Group: “Request of Information” (Source: according to (Sunyaev et al. 2009c))

The process groups have to be digitalized and be bound to eHC. As an example of the digitalization of the process groups the former shown process group of “request of information” is visualized in Figure 42. In comparison to the actual process group only the sequence of the BFS form remains the same. The sequence of requesting information is changed completely. If every patient and doctor uses the voluntary medical functions (such as the electronic patient record) treatment will become more effective (Rienhoff/Marschollek 2004). During the patient’s admission reception assistants could download the required information and thereby save a considerable amount of time (up to approximately two minutes per patient for the doctor in the test site practice). This time-saving occurs because there is no longer a need for telephone calls to gather the required medical information about the patient. If the practice still prefers paper based records the information can still be printed out. Because the medical func-


183

tions are voluntary the functions do not have to be used in every instance (Federal Ministry of Health 2008). By comparing current and future process groups it is possible to analyze the amount of time saved or lost. 6.3.4

Patient Survey

49 patients were interviewed in order to analyze the usage of voluntary eHC functions. Patient acceptance is the condition for the usage of the eHC’s new voluntary functions (e.g. the electronic patient record) (Förster 2005). Therefore the questionnaire used contained direct questions about possible usage of the eHC and also included possible indicators for its acceptance30. Indicator questions were about participants´ internet, online banking and PIN usage and their perceptions about security while using these services (Davey 1994). Another indicator is the fear of losing control of their personal medical data and unauthorized access to their data. Direct questions were about future usage of the eHC. Patients were asked, if they will use the electronic patient record and whom they felt should be allowed access to their personal data. Would you use the function of the eHC to store your medical data? Which kind of data would you prefer to be stored on your eHC?

Which doctors would be allowed to have an access to your medical data? Who is allowed to have an access to your medical data?

Yes

no

do not know

89.9%

4.1%

6.1%

all data

selected data

emergency data

59.5%

38.1%

2.4%

all doctors

chosen doctors

my family doctor

34.9%

58.1%

7.0%

assistant and doctor

only the doctor

58.2%

41.8%

Table 30: Percentages of Desired Usage (Source: according to (Sunyaev et al. 2009c))

Using these indicators it was possible to deduce improvements for usage and security perceptions by the patients. Important results from the survey are shown in Table 30. The most important result of the evaluation is that 89.8% of the patients would use the voluntary functions of the eHC. Apparently, 34.9% of the participants would allow every doctor to use their data. In contrast, 58% would only allow select doctors access to their data. The remaining 7% would grant only their family doctor access to the data. 59.5% would store all of their medical data on the eHC and 38% would only want to store specifically selected data. 30

Indicators are directly observable variables (Mouton/Marais 1988).

184


Just 2.4% of the surveyed patients would store only emergency data. 41.8% of interviewed patients would allow only doctors access to their medical data. This result shows the trust to doctors and that there is less for other medical staff. Because of this, however, doctors will have to download more information on their own and lose more time (a download could take up to three minutes per patient). To get more precise results the participants were divided into two groups: age groups and usage groups. 6.3.4.1 Age Groups Analysis The age-based groups are divided into four groups: till 30, 31 to 50, 51 to 65 and above 65. Following curial differences between the groups were observed. For example, internet usage differs significantly between the age groups (Schöllkopf 2007). The participants under the age of 30 had an internet usage rate of 100%. With increasing age the level of internet usage of the participants declines. The age group from 31 to 50 has a usage of 93.75% and the group of 51 to 65 year-old has a usage of 75%. The lowest level of internet usage was displayed by the age group above 65 with only 50%. These percentages can also be compared to a TNS Infratest study (Schöllkopf 2007). Our survey confirmed these results (Table 31). Age

Percentage of internet usage

Age

Percentage of internet usage

14-19

89.4

50-59

58.3

20-29

87.2

60-69

35.5

30-39

82.2

70 and older

13.2

40-49

72.6

Table 31: Internet Usage by Age (Source: according to (Schöllkopf 2007))

The possible influence of these indicators on the usage of the eHC will be analyzed in the usage groups’ analysis. An important difference between the age groups was found in the usage of voluntary medial functions of the eHC. All participants in the age groups 30 and under and those above 65 would use these functions and would store their medical data on the eHC. In the age group 31 to 50 only 81.25% would use the voluntary functions. In the group of 51 to 65 year-old 75% would use them. This shows that there has to be some reasons why the working generation (31-65 year-old) is more skeptical about the voluntary medical functions than the other generations. The exact percentages of willingness to use the voluntary data storage are shown in the left column of the Table 32.

6.3 Analysis of the Applications of the Electronic Health Card 100%

185

total till 30

80%

31 to 50 51 to 65

60%

above 65

40%

20%

0% usage of data storage

saving all data

saving chosen data

saving more than emergency data

Table 32: Intended Usage of Voluntary Functions by Age (by Patients) (Source: according to (Sunyaev et al. 2009c))

The columns on the left “usage of data storage” display the level of willingness to use the data storage function among the age groups. The columns “saving all data” represent the percentages of the patients, who would use the eHC to store all of their own medical data. The average usage of saving all data is at 60%. Only the patients between 51 and 65 differ significantly with fewer than 35% responding favorably to this option. This result emphasizes that age group’s skepticism and has an effect on the columns next to it. The columns “saving chosen data” represent the patients who would store selected data. I.e. they will only store data from doctors or treatments that they have themselves selected. Here the average is at nearly 40% and the group of 51 to 65 differs because of the coherence to the columns before. The columns “saving more than emergency data” are the sum of “saving all data” and “saving chosen data”. This sum is very important for the doctors because only with more than emergency data can they save time by accessing all of required information via download. The average is nearly 100% and so it can be stated that if a patient chooses to uses the voluntary medical functions of the eHC doctors will clearly benefit. Some clear differences between the groups were found in their usage and security perception of the internet, online banking and PINs. Differences in willingness to use eHC features can be derived from these differentiations. Another important indicator of willingness to use eHC feature is the fear of unauthorized access by various parties, e.g. employers gaining insight into personal medical data. These indicators have consequences on the age groups and have been analyzed separately to get a better understanding.

186


6.3.4.2 Usage Groups Analysis 100%

non internet user internet user

80%

60%

40%

20%

0% heard something about eHC

at least medium knowledge

disuse of data storage

Table 33: Comparison of Internet Users to Non Internet Users (Source: according to (Sunyaev et al. 2009c))

One clear result of the evaluation was achieved by analyzing the connection between internet use and willingness to use the voluntary eHC functions. As shown in Table 33, the internet usage has a positive effect on knowledge about eHC introduction and willingness to use of the voluntary eHC functions. Internet users know more about the eHC and would be more likely to store more of their medical data on the eHC. This result was also analyzed by gender and it was discovered that every male internet user surveyed would use the data storage functions. Female internet users are less familiar with the introduction of the eHC in Germany. Here only 83% would use data storage and 12.5% do not know whether they will use date storage or not. A related result was found among non-internet users. More female than male participants would not use the functions of the eHC. That shows that male participants, with are more likely to have an affinity for technology, would have a higher level of eHC function usage. Perceptions of internet applications security also influenced usage of the eHC. All internet users who think the internet is secure will use the voluntary functions of the eHC. Most of these patients would also store all their medical data and would allow all physicians to use them. The evaluation also showed that a higher usage of voluntary functions is displayed among online banking users. Furthermore, patients who feel secure about using PINs would probably use the voluntary functions of the eHC. The last indicator is the fear of unauthorized parties gaining access to medical data. Here, a clear coherence between this fear and lower usage of eHC functions is visible. In the group of participants who were afraid of losing control of their data fewer participants would store the


187

data on the eHC than participants without this fear. In this group there is no difference between males and females. This indicator and the PIN are a reason why 100% of the group above 65 year-old would use the voluntary functions of the eHC. In this group nobody is afraid of losing data and most of them think the PIN is secure. These different indicators and their different allocation among the age groups explain the different levels of willingness to use eHC functions between the groups. 6.3.5

Summary

Based on these results the eHC should bring benefits to all involved partners. The patients could receive better quality treatment because of the improved availability of medical information required by doctors (Lenz et al. 2002; Schröder 2005). The doctors could save time and money because of easier access to medical information (gematik 2006q; Haibach 2005). In the practice used as a test site, for example, the doctor could save up to 10 hours per month if no phone calls to former doctors were necessary. Based on the evaluation it is obvious, that the health insurance companies should begin an information campaign to promote the eHC. In this campaign it will be especially important to inform the general public about security measures. It is important to inform patients about the various security methods used, such as the codification of data (e.g. for internet users) and the PIN (Baldry et al. 1986). User acceptance on the side of physicians as well as patients plays a vital role. Assessment of the security measures is a significant aspect of gaining acceptance (Furnell et al. 1994). Furthermore, to encourage acceptance of the eHC by physicians the voluntary functions should be introduced as early as possible. Only these functions can offer real benefits for doctors. Finally, by comparing the derived processes to other practices this section checked to see if the results are transferable. Analysis of another practice showed related processes, which implies that transfer is possible. The processes in general are always aimed at the patients, regardless of what kind of doctor (Bakker 2003). Only the emphasis of the process groups in the different practices can differ. Thus, the eHC could bring every doctor’s practice a profit if everything worked according to plan. 6.4

Analysis of a Proposed Solution for Managing Health Professional Cards in Hospitals Using a Single Sign-On Central Architecture

The third case study considers the analysis of the secure management of health professional cards in hospitals. The goal of this case is to see the applicability of the security analysis process and product of the HatSec method. The third case study shows that the according parts of the HatSec method work and that the HatSec method can not only analyze the processes but also provide precise results according the solution for the identified problem. This case study

188


gives rise to the question whether the HatSec method is applicable to concrete problem situations. To confirm this, the analysis focused on a secure solution for managing health professional cards in hospitals. Figure 43 illustrates the concrete implementation of the HatSec method in this case study.

h

Identification by: x Legal basis x Specifications x Engineering documents x Basic goals of IT security x ...

Security Assessment

i

Methodical analysis by: x Applications analysis x Process reorganization x ...

Process Analysis / Selection of actions to minimize the risks implied by present vulnerabilities, and weaknesses


Actions by: x Selection from activity catalogue x New development

Figure 43: Security Analysis Product according to the HatSec Method (Source: own Figure)

This section describes and analyzes a single sign-on solution for the central management of healthcare provider’s smart cards in hospitals (Neame 1997). The proposed approach, which is expected to be an improvement over current methods is possible through the introduction of a national healthcare telematics infrastructure in Germany, where every physician and every patient will be given an electronic health smart card (for patients) or a corresponding health professional card (for healthcare providers) (Loos 2005). This introduction will lead to changes in many existing healthcare administration processes (Lenz/Kuhn 2004). The example process of writing a discharge letter is used to compare two existing approaches for integrating the new smart cards into the proposed single sign-on approach. Based on our findings a centralized single sign-on card management approach is supported. It allows the utilization of possible process improvements now and in future. Furthermore, these results outline additional application potentials of the described approach for managing smart cards in healthcare and, especially, in hospitals. 6.4.1

Overview

The creation of electronic health cards and health professional cards will necessitate adaptations to the everyday work processes of care providers in hospitals. Because these changes are so pervasive, the reengineering of the given processes and a possible deployment of new and viable solutions for the management of smart cards in hospitals is required (Kardas/Tunali 2006). Such a solution would potentially achieve improvements in current processes, in terms of both efficiency and effectiveness. For this purpose it has to be taken to take into account

6.4 Managing Health Professional Cards in Hospitals

189

the requirements of an adequate and seamless integration of the HPC into business processes and the given IT infrastructure (Schweiger et al. 2007a; Zöller et al. 2006). The central issue that must be addressed is the missing support for the efficient widespread deployment of smart cards. Smart cards are currently used for a variety of purposes such as single sign-on (SSO) access to systems or as company identification cards. Therefore it can be expected that a large number of smart cards are already in use in any typical healthcare facility, such as a hospital. This section is structured as follows: in section 6.4.2 the new smart card based processes are demonstrated in an administrative process that is commonly carried out in clinical practice. Since there are other already existing approaches for managing clinical smart cards, these approaches are outlined in section 6.4.3. Section 6.4.4 presents a centralized approach the proposed smart card management solution. In order to demonstrate the advantages of the proposed approach, the approach is compared to the other approaches in section 6.4.5. Section 6.4.6 discusses the advantages of the proposed approach over the other approaches. 6.4.2

Induced Process Changes

Users will not be faced with the full complexities of the telematics infrastructure. He or she uses the new functions via the graphical user interface of the hospital information system (this means that every manufacturer has to adopt existing software to the new telematics infrastructure). Depending on the selected solution for managing this infrastructure, the user has to insert a smart card and type in a PIN from time to time. It is this action of inserting the eHC or HPC card and entering a PIN that will be used to evaluate each potential infrastructure solution for this healthcare system. 6.4.2.1 General Changes The introduction of the eHC will lead to significant changes in medical processes. The HPC will become an especially essential part of the everyday work routine in hospitals. Patient medical information will only be accessible by using the HPC in connection with the HPC authentication PIN (PIN.AUT). Furthermore, all medical documents will have to be signed by physicians using the HPC in connection with the signature PIN (PIN.SIG). The usage of different PINs for authentication and signature is already defined in the HPC specification. Dealing with these processes requires the physician to spend more time handling the HPC and the PINs, especially if there also exist additional smart cards (e.g. for Single Sign On requirements (SSO)). The process of issuing a discharge letter is one of the most common processes performed by physicians. This discharge process is used to demonstrate the described card insertion and PIN entering actions.

190


6.4.2.2 Discharge Letter Process The conventional process of issuing a discharge letter is shown on the left of Figure 44.

Physician wants to issue a discharge letter

Physician dictates discharge letter

Discharge letter dictated

Secretary types discharge letter

Physician signs discharge letter handwritten

Discharge letter signed

Mailing of the discharge letter

Discharge letter dispatched

Physician dictates discharge letter

Discharge letter dictated

Secretary types discharge letter

Discharge letter typed

Secretary prints out discharge letter

Discharge letter typed

Physician signs discharge letter eletronically

Discharge letter printed out

Old

New Physician wants to issue a discharge letter

Discharge letter dispatched

Figure 44: Old and New Discharge Letter Process (Source: according to (Mauro et al. 2008b))

Figure 44 illustrates work processes using an extended EPC notation. Nowadays physicians usually dictate discharge letters. A secretary is responsible for typing and printing the letter. Physicians sign the document, and afterwards, the letter can be mailed to the family doctor. In the new process (bottom side of Figure 44) the discharge letter is signed electronically. This means that printing the letter is no longer necessary. There is also no longer a need to mail the document. The letter is stored within the health telematics infrastructure and is thereby directly accessible to the family doctor. At first glance the new process looks quite simple and several prior steps can now be omitted. The process change means that now the physician has to sign the discharge letter electronically. Thus, the doctor has to login on a computer, insert a personal HPC and type a PIN.AUT and a PIN.SIG. If an SSO card is required for the login, the physician has to handle two smart cards, both with PINs. Furthermore, every time a physician changes a workstation, the cards need to be removed and inserted in the new workstation. In addition the input of different PINs is necessary again (SSO PIN, PIN.AUT, and PIN.SIG). Since physicians are highly mobile, moving from patient to patient, this creates a significant amount of busywork throughout the physicians’ day. For this reason an adequate smart card management solution has to be introduced one that simplifies the described work process.

6.4 Managing Health Professional Cards in Hospitals 6.4.3

191

Existing Approaches for Managing Smart Cards in Hospitals

According to the telematics rules to be introduced, every physician will receive a new Health Professional Card and has to use it for authentication and authorization of activities such as signing prescriptions, accessing electronic patient records, etc. There are currently two basic management approaches for the use of smart cards in hospitals, the decentralized approach and the VerSA approach. This section describes and contrasts these two approaches and uses them to suggest a third new approach: the universal clinic card approach. 6.4.3.1 The Decentralized Approach The decentralized approach is the “official” solution, currently being tested in selected regions of Germany (with a reduced range of functions). According to the complete health telematics infrastructure specification (gematik 2006g), every workstation has an SICCT (Secure Interoperable ChipCard Terminal) component (Figure 45, upper side). An inserted HPC card permits its owner to perform processes such as signing prescriptions or accessing patient data. Communications with the central telematics infrastructure (CTI) are facilitated by the connector. When a person leaves the workstation, the HPC is ejected and must be removed.

decentral eHC / HPC

eHC / HPC

eHC / HPC

MIS Connector CTI

eHC / SMC

eHC / SMC

HPC = gematik specified interface / connection

VerSA

Figure 45: VerSA (bottom) and Decentralized Approach (up) (Source: according to (Mauro et al. 2008b))

6.4.3.2 The VerSA Approach The VerSA concept (Warda/Noelle 2002) (“Verteilte Signatur Arbeitsplätze”, an acronym meaning distributed signature workstations) has been developed by the German Federal Association of Pharmacists. This approach (Figure 45, bottom side) requires the HPC to be inserted into a central server card terminal. Each workstation is equipped with an SICCT component. A secure connection to the HPC is established via SMCs (which are inserted at the

192


SICCT). This allows the user to make use of the functions normally provided by the HPC without actually needing to physically insert the card in each workstation. Currently no hardware has been built for this concept. Therefore it cannot be tested or practically compared with other solutions. 6.4.3.3 Disadvantages The problem with these existing two approaches is that they are not specifically designed for hospitals’ needs. They may work fine for a general practitioner with a small number of computers and therefore a small number of expensive SICCTs. In hospitals a multitude of SICCTs would be needed. In addition, besides the HPC, other smart cards will often be in use fulfilling other functions in the hospital. Thus, the user may have to handle more then one smart card and may also be faced with other controls for system access. These disadvantages are a motive for developing a new approach that considers the special needs of hospital environments. 6.4.4

The Clinic Card Approach

For a better handling of the multitude of smart cards, a completely centralized approach for smart card management in hospitals (Figure 46) has been developed.

MIS CC

CC eHC

Connector CTI CC

CC = gematik specified interface / connection = self specified interface / connection

SCMU

Figure 46: Central Management Approach (Source: according to (Mauro et al. 2008b))

The approach is based on a smart card management unit (SCMU, also called smart card safe) that stores HPCs in a secure way as well as a multifunctional smart card (so called clinic card (CC)), which has a well-defined association to an HPC. The overall idea is: The aforementio-


193

ned smart card unites all the functions of other smart cards already in use and therefore reduces the number of smart cards that medical personnel would need (Schweiger et al. 2007b). At the beginning of a workday the user puts his HPC (and perhaps additional signature cards) into the SCMU. After that he or she only needs a CC and CC PIN for all purposes. To avoid queues and to be able to manage a large number of users, there can be many SCMUs, distributed throughout the medical complex. In addition, the mechanism for placing cards in the SCMU should be very easy and quick. 6.4.4.1 Technical Architecture The system consists of the following four components (Figure 47): SCMU, CC, card middleware, and connector. SCMU and CC (via the middleware) are accessed via the connector that only acts as the central access point for the hospital information system (HIS). The connection to the telematics infrastructure is established via the VPN box.

System Boundary

custom

Card Middleware

gematik

Connector VPN Box

custom

Clinic Card

gematik

SCMU HIS

Figure 47: Component Overview (Source: according to (Mauro et al. 2008b))

The SICCT interface of the SCMU and the main parts of the connector are specified by gematik requirements. In addition customized functionalities are necessary for the Clinic Card Solution. Thus the SCMU and the connector each have distinct subunits that perform the gematik connection and the customized functionality.

194


6.4.4.2 Smart Card Management Unit From a technical point of view, the SCMU is a multislot SICCT terminal. eHCs, HPCs, and SMCs are to be read exclusively by SICCT components. The SICCT interface describes the interaction with the connector. In addition, a self-defined interface is necessary for the remote access to the HPC. The SCMU is provided with removal protection for inserted HPCs. Authorized removal is therefore only possible with the associated CC in combination with the CC PIN. The user interface is quite simple. After inserting the CC and the corresponding CC PIN, the SCMU assigns a free card slot (noticeable by a flashing green LED). If the HPC is inserted the LED switches to solid green. The authentication PIN and the signature PIN of the HPC will be requested and stored encrypted on the HPC (which is the only allowed storage place according to German signature laws) for later usage. The insertion of the PIN is done via a PIN-pad (similar to numeric pads on ATM machines) with coaching from screen displayed messages. The encryption keys are cut into two pieces: One half will be held inside the SCMU, the other half will be stored on the CC. After this process, the LED switches to red, indicating a busy card slot. In addition the CC will be ejected and must be removed by the user (otherwise the CC will be retracted and stored in a special box inside the SCMU). Because the SCMU acts as a central unit and holds multiple important chip cards, it must be made readily available to users. Thus, it is established with a redundant power supply as well as redundant network interface cards. In addition a software module on the connector monitors every SCMU. Furthermore, mechanisms are available for securely (i.e. access is only possible by authorized personnel) removing the inserted cards in case of a problem. 6.4.4.3 The Clinic Card and Card Middleware Once the HPC is inserted in the SCMU at the user’s workstation remote access to the HPC is possible with the use of the CC. The user only has to type in the CC PIN to use the functions of the HPC. The CC PIN can also be used for adding signatures. Alternatively, biometric data or RFID tags could be used as authorization mechanisms. In addition further applications can be used with the CC, such as SSO or canteen billing. For these purposes contactless identification systems like Legic (www.legic.com) or Mifare (www.mifare.com) can be integrated in the CC. In short, the user has one single smart card available for all needs. The CC can be read by a normal card reader in combination with the middleware installed on the workstation.


195

6.4.4.4 Connector As shown in Figure 47, the connector has interfaces to internal and external components of the system. One important aspect of the Clinic Card Solution is that the interface to the HIS remains unchanged (in relation to the gematik requirements). Thus, the solution can be integrated into the hospital’s IT infrastructure independently of the given HIS. This is essential because many different HIS exist in Germany (Krcmar et al. 2007). Only a small modification to the conventional connector is necessary for using it in the context of the presented solution. Thus, it is relatively easy and inexpensive to create a connector that is compatible with the proposed Clinic Card solution. 6.4.4.5 Remote Access The SCMU acts like the usual SICCT component until an authentication failure occurs. This means, that a function needs a PIN insertion. For an HPC, this can be a PIN.AUT or a PIN.SIG. The complete remote access process is shown in Figure 48. As a first step, the user chooses a function inside the HIS that requires HPC access (1+2). The HIS calls the corresponding connector service (3). All of this is transparent to the user. The connector tries to access the needed card (4). If a PIN is required for access, the SCMU responds with an authentication failure (5). Up to this point the process is identical to the other solutions (except for the location of the HPC). Because the presented solution doesn’t need an SICCT component connected to the workstation, the PIN has to be typed directly at the workstation (6). However, instead of the HPC PIN, the CC PIN will be requested (7). After the user correctly enters the PIN, the half key (saved on the CC) will be transmitted over secure connections to the connector (8). The connector now is able to initiate the authentication by transmitting the half key to the SCMU (9). Within the SCMU the half keys can be recombined with the encrypted half key stored at the SCMU. The combined key can then be used to decrypt the HPC PIN saved on the HPC. The PIN can now be used for authentication and the result of the card access will be sent to the connector (10). Finally, the connector forwards the result to the HIS (11). The HIS can then finalize the requested user function and present the result to the user (12). This process appears quite complicated but this is not a weakness of the presented solution. Instead the complicated appearance is a result of the way the telematics infrastructure and, especially, the connector work. Fortunately this process is transparent to the user. The user simply requests an HIS function, types the needed CC PIN and continues with the task.

196

6 Practical Application of the HatSec Method 10 KEY

9 KEY

5 4

Connector

HPP

= HPC PIN

KEY

= Half Key

SCMU

8

CCP

6

HPC

= Clinic Card PIN = encrypted or ver encrypted connection

HPP

11

3

KEY

1

7 CCP

HIS

2

Workstation

12

CC KEY

Figure 48: Remote HPC Access (Source: according to (Mauro et al. 2008b))

6.4.4.6 Unique Characteristics of the Central Approach Initially, the centralized solution looks similar to VerSA, but there are some significant differences: x

No HPC PIN is transmitted through the network.

x

No expensive SICCT components are needed at the workstation. A conventional card reader will suffice (except at the patient check-in workstations where patient eHCs have to be read).

x

No SMCs are necessary inside the card terminals.

x

Conventional card readers can be connected to the workstations instead of connecting them to the network. Thus no additional network ports are necessary.

x

A multifunctional smart card (the CC) is in use.


197

The first three points are made possible by the use of a special remote access to the stored cards. As one can see on the second point, the eHC is not integrated into the presented solution yet because there are some legal issues that need to be resolved. In addition, at the present, it is not foreseeable whether the integration of eHCs access makes sense. However, the integration of the eHCs can be done later with a simple software update. 6.4.4.7 Discharge Letter Process This section again looks at the process of issuing a discharge letter that was previously discussed in section 3.2. Assuming that an SSO card is used, the differences between the described approaches are shown in Figure 49. The process begins at a point when the user is not yet logged in on a workstation. Thus, depending on the approach used, different mechanisms for logging in are necessary. As one can see, using the decentralized approach requires the insertion (and removal) of two different cards and the entering of three different PINs. The VerSA solution requires less work because the HPC is inserted into the server terminal and only the SSO card must be inserted each time the user changes workstations. Nevertheless, the user still has to enter different PINs for the login process, the HPC authentication PIN and the signature PIN. The central approach requires only one smart card and only one PIN entry at a given workstation. This enables the physician to finish the process of issuing a discharge letter much faster (in comparison to the other approaches). decentral Computer selected

Insert SSO Card + SSO PIN

Physician logged in

Select document for signing

HPC needed

Document signed

Remove SSO Card

SSO Card removed

Remove SSO Card

SSO Card removed

Computer selected

Insert SSO Card + SSO PIN

Physician logged in


HPC PIN needed

Document signed

Remove SSO Card

SSO Card removed

Insert HPC + HPC PIN

Document ready for signing

Insert signature PIN

Input HPC PIN

Document ready for signing

Insert signature PIN

VerSA

central Computer selected

Insert CC Card + CC PIN

Physician logged in


CC PIN needed

Input CC PIN

Document signed

Remove CC

Figure 49: Discharge Letter Process Comparison (according to (Mauro et al. 2008b))

CC Removed

198 6.4.5

6 Practical Application of the HatSec Method Comparison of the Presented Approaches

6.4.5.1 Evaluation Framework Different evaluation methods exist for healthcare information systems (Häkkinen/Turunen/ Spil 2003). For evaluating the described approaches, an evaluation framework is used which was introduced by (Gappmair/Häntschel 1997) and (Spil/van de Meeberg/Sikkel 1999). According to this framework, the dimensions objects (approaches for card management), criteria (hardware requirements, session management, usability, additional value-adding aspects), and method (comparative procedures) are each handled separately in the evaluation. 6.4.5.2 Hardware Requirements and Integration The decentralized gematik approach requires gematik-certified SICCT components to be installed at each workstation. Network enabled card terminals (connection via LAN) necessitate an additional network connection for each workstation. This can lead to a further extension of the given network infrastructure. Virtual card terminals (connections to the PCs) do not require their own network connection. However, the installation of special software, which is capable of exporting the SICCT interface is necessary (gematik 2007d). The central VerSA concept requires, in addition to the decentralized approach, a server card terminal to be installed in order to provide central access to the HPCs. The amount of necessary server terminals is dependent on the number of employees and the spatial layout of the hospital. For a secure PIN transfer via the network there is also an SMC that is needed for each card terminal. By pursuing the central clinic card approach there arise costs for obtaining the management components, the clinic cards and the card application management system (CAMS). The CAMS manages the data and applications stored on the CC. Furthermore, additional expenses are incurred for the purchase of the card reader terminals and the installation of the necessary terminal software. The actual expenses for obtaining the hardware are dependent on a set of factors. Among these are the number of medical employees in a particular healthcare facility and, the expected market price for SICCT components (which will drop as demand increases). Because it is currently impossible to make exact quantitative calculations of these basic conditions, thit thesis makes the following assumption for the intended comparison: The expected hardware costs are comparable to each other. Therefore, in terms of hardware requirements, there is no advantage of one approach over another.


199

From an objective point of view there is a slightly more effort involved in integrating VerSA or the Clinic Card Solution. This is because, in addition to the placement of card terminals at each workstation, the server terminals have to be installed and configured. When using the Clinic Card Solution there is also an additional effort for the creation of CAMS. But as mentioned before, German health telematics infrastructure is still in its test stage. After the tests are completed, a nationwide rollout of the system will begin. This will include a huge effort by hospitals to integrate the new processes and hardware. Thus, the slightly greater effort required to integrate the Clinic Card Solution is not relevant. 6.4.5.3 Session Management If an HPC is inserted into the card terminal, a set of actions for session management purposes is necessary (gematik 2007b). Central approaches provide the advantage that this effort has to be carried out only once. In contrast, decentralized approaches require the repetition of these actions during each insertion of the HPC. As a result, every time a healthcare provider leaves one workstation, the actions described above need to be repeated at the next workstation. With the VerSA approach the need should be considered to establish logical connections between SMCs and HPCs. Both the SMC and the HPC are capable of establishing only a limited number of connections. If this number is exceeded, previously established connections must be closed. Therefore, parts of the session management need to be repeated again. This problem doesn’t arise when using the central clinic card approach because logical connections on the basis of SMCs for PIN transfer are not necessary. In this area the clinic card solution has clear advantages over the gematik and VerSA approaches. 6.4.5.4 Usability The decentralized approach has the disadvantage for users that the HPC authentication process has to be repeated every time a new workstation is used. As a result, additional work steps are necessary, especially for highly mobile physicians. Furthermore, there is a security risk because the HPC could be left unintentionally in one of the workstation card terminals. Centralized approaches provide a secure safekeeping for the HPCs throughout the workday. Additionally, the HPC can be used remotely, which leads to a simplification of work processes. If the multi-functional clinic card is used, the user has to handle only one card. This reduces work and increases security, especially in the hospital domain. The central approach has an enormous advantage with respect to usability in comparison to the gematik approach (Mauro et al. 2008a). Healthcare providers will clearly in terms of time saving and convenience.

200


6.4.5.5 Further Value-Adding Aspects Both the decentralized and the VerSA approaches are designed for HPC applications only. Therefore, no further value-adding scenarios can be supported. However, the central clinic card approach is capable of supporting a broad spectrum of uses in hospitals. The clinic card can, in the proposed solution, be used to substitute currently used smart cards or contact-free media. Thus, with a single card, a person can open doors automatically, enter restricted parking garages, pay for cafeteria purchases, or sign on to various hospital management systems. Combining access to all of these functions onto a single smart card reduces costs and benefits the user by conveniently managing a broad spectrum of applications. 6.4.6

Summary

Table 34 summarizes the derived evaluation from section 6.4.5. It is evident that the selection of adequate infrastructure fundamentally affects the possible benefits of smart card applications in hospitals. This is why such a decision should be made carefully. Furthermore, Table 34 shows that the single sign-on clinic card solution has significant advantages over present concepts described above. This implies that the small amount of additional development to deploy this system is worth the extra effort and will bring about benefits in a short time. Concept

gematik Approach

VerSA Approach

Clinic Card Solution

O

O

O

Session Management

-

O

+

Usability

O

+

+

Additional Value-adding Aspects

-

-

+

Criteria Hardware Requirements

Legend: + most suitable O suitable - not suitable

Table 34: Concepts for the Central Management of Smart Cards in Hospitals (Source: according to (Mauro et al. 2008b))

The described clinic card solution is capable of being extended for use in accessing personal electronic healthcare records if electronic health cards are deposited into the central smart card management unit and patient agreement is given. In particular, the introduced solution has the potential to provide a truly seamless and secure healthcare system.

6.5 Security Analysis of the German eHC‘s Components on a Theoretical Level 6.5

201

Security Analysis of the German Electronic Health Card’s Components on a Theoretical Level


c


d



Identification of assets, security requirements, legal requirements, security measurements Security Analysis Process

f


g h

e


Identification and description of revealed vulnerabilities Vulnerability Identification

Methodical analysis by: x Penetration tests x Tools for analysis x Exploitation frameworks x Attack-Trees x Metrics x ...

Selection of actions to minimize the risks implied by present vulnerabilities, and weaknesses

Security Assessment

i

Analysis on a theoretical level



Figure 50: Theoretical Security Analysis according to the HatSec Method (Source: own Figure)

The fourth case study considers the security analysis of German healthcare telematics on the theoretical level. The results of this case involve the entire spectrum of the HatSec method. The goal of the fourth case study is to examine the HatSec method’s suitability for a security check of the specification documents. This case study demonstrates that the HatSec method is effective. Several open security issues in German healthcare telematics were also discovered. This section analyzes the specification documents of German healthcare telematics with a focus on security problems, inconsistencies, and incompleteness. The results are specific to healthcare telematics currently under development in Germany and build the core of the performed security analysis. Figure 50 illustrates the concrete implementation of the HatSec method in this case study. 6.5.1

Overview

As described in section 0, German healthcare telematics is divided into a central and a peripheral part (Figure 51). The central part consists of several services, which can be accessed by the insured and the service providers such as medics or hospitals. These services will be located and administrated in one or more central computing centers. The peripheral part of the healthcare telematics infrastructure is located at the medical service provider’s location. This part consists of the medical service provider’s LAN, the connector, card readers for eHCs and

202


HPCs, and the smart cards themselves. The connection between peripheral and central part of the healthcare telematics infrastructure is established by using a VPN connection over the internet, initialized by the medical service provider’s connector, and accepted by a VPN concentrator located in the central part of the healthcare telematics infrastructure.

Peripheral part of the HTI

VPN Tunnel

Central part of the HTI

LAN

eHC Internet Connector Primary System (PVS, AVS, KIS)

WAN Router

VPN Concentrator

HPC

Services provided by the central TI

Figure 51: Schematic Representation of the Healthcare Telematics Infrastructure (Source: according to (Sunyaev/Leimeister/Krcmar 2009a))

The so-called primary system is not part of either segment of the healthcare telematics infrastructure. These systems are software products that are used by medical service providers for storing their patients’ records for accounting purposes and various other tasks related to healthcare. Because these components are being developed and maintained by third party companies, security aspects cannot be supervised by governance and, thus, they are by definition not part of the healthcare telematics infrastructure. Nevertheless, these systems were considered in the security analysis from a general point of view because they store and administer sensitive medical data (Ahn/Sandhu 2000). 6.5.2

Components and Documents Considered in this Security Analysis

The components considered in the security analysis are: eHC, Connector, Primary Systems, Card Readers and the processes occurring during their interaction. Only publicly available documents were taken into account during the analysis. Obviously the analysis would be more complete if internal documents were considered, but by using only public sources the security analysis is based on the same information level any attacker would have access to. Furthermore, some internal development documents were marked as confidential and thus could not be considered at all. Table 35 illustrates the documents, which have been considered for this analysis.

6.5 Security Analysis of the German eHC‘s Components on a Theoretical Level

203

(SGB 2007; BDSG 2003; SigV 2001; SigG 2001; StGB 2005; IBM/Dr. Bunz/Dr. Neeb 2004; IBM et al. 2004; gematik 2005b, 2005a, 2005c, 2006p, 2006f, 2006l, 2006g, 2006e, 2006k, 2006r, 2006s, 2006a, 2006m, 2006t, 2006q, 2006b, 2006c, 2006d, 2006n, 2006j, 2006h, 2006i, 2006o, 2007i, 2007a, 2007f, 2007g, 2007c, 2007e, 2007b, 2007d, 2007h, 2008i, 2008f, 2008g, 2008h, 2008d, 2008e, 2008c, 2008a, 2008b)

Table 35: Analyzed gematik Documents (Source: own Table)

6.5.2.1 Security Analysis of the Electronic Health Card’s Components 6.5.2.1.1 Cross-Component Analysis The cross-component analysis was undertaken to analyze the processes that the mentioned components are involved in. Furthermore, the cross-component analysis included a critical review of the development documents from a security-based point of view. 6.5.2.1.2 Key for the Combination of Medical and Administrative Data (IBM et al. 2004)31 states that security must not depend on the reliability of a single person. However, in (IBM et al. 2004)32 it is explained that the key for combining separate administrative and medical data is to be held by the “Federal Commissioner for Data Protection and Freedom of Information” a position held by a single person. 6.5.2.1.3 Unauthorized Transfer of Medical Data In (SGB 2007; SGB V 2008)33 it is stated that by law, depending on the medical issue, full medical data has to be given to the insurance company without the patient's consent. This exception conflicts with a basic requirement found in (gematik 2006h)34 stating that no one is allowed access to medical data without the permission of the insured person. Although this is a reasonable exception it has, at least, to be communicated to the insured to fulfill another requirement found at (SGB V 2008; SGB 2007)35, demanding the insured be informed about what happens with their medical data (Scott/Jennett/Yeo 2004). By using the eHC to grant permission it would be possible to securely transfer the data to the insurance provider, while involving the insured in the process using the eHC. These explanations cannot be found in any of the considered documents. 6.5.2.1.4 Missing Backup Method for Honoring Prescriptions According to (IBM et al. 2004)36, for every process in the healthcare telematics infrastructure, there has to be at least one manually operated backup process. In (gematik 2006j)37, there can 31 32 33 34 35 36

cp. requirement 004.So.A.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 001.Vt.A.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 010.So.A.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 002.Vt.A.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 011.So.A.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 002.Vf.A.AS in (Huber/Sunyaev/Krcmar 2008b)

204


be found one exception, which combined with the following topic, might result in severe problems concerning availability. There the absence of an adequate backup process for honoring digital prescriptions is mentioned. Because of this an insured person who has only digital eHC prescription would not be able to get their prescriptions filled if the healthcare telematics infrastructure became unavailable to the pharmacy. Obviously this could lead to dangerous situations, including urgently needed medicines not being dispensed. 6.5.2.1.5 Possibility to Honor the Same Prescription Twice If the availability drawback mentioned above would be resolved by strictly implementing the requirement of (IBM et al. 2004)38 and thus establishing a manually operated backup process for honoring prescriptions, every insured person would have both digital prescriptions on their eHC and paper based copy to provide a manual backup process. In this scenario, however, the insured person could first fill their digital prescription and afterwards get the same prescription filled again by visiting a pharmacy where the healthcare telematics infrastructure is not available, due to technical problems for example. This situation would violate several requirements concerning accountability and avoiding repetition39. 6.5.2.1.6 Unassigned Assumption About the Security Implied by the Used ”Zone-Concept” The healthcare telematics infrastructure and its related systems are divided into several zones. This division is made, to allow an in-depth view of each zone’s security. As mentioned in (gematik 2007g), each of these zones is considered a closed area. However, each of these zones is linked to others through a physical connection. Wherever there is a physical connection, there is also the possibility of (unauthorized) traffic between zones, even if the chance for this kind of traffic is low due to protection measures. Nevertheless, if there is the possibility of (unauthorized) traffic, it is not accurate to consider each of these zones on its own or even to classify them separately. Therefore it should be contemplated, whether it might be reasonable to expand the view and consider the interaction between zones as well. Furthermore, it might be reasonable to classify each interconnected zone as the same in regards to security issues. 6.5.2.1.7 Adjustment of Minimum Standards Happens Infrequently As mentioned in (gematik 2007g), the minimum security standards to be implemented on the healthcare telematics infrastructure have to be adjusted annually. According to CERT statis-

37 38 39

cp. requirement 008.Vf.K.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 002.Vf.A.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirements 003.Zu.A.AS, 004.Zu.A.AS and 005.Zu.A.AS in (Huber/Sunyaev/Krcmar 2008b)


205

tics40 from the first quarter of 2007, approximately 2,176 vulnerabilities have been uncovered. Considering the possibility of more than 8,000 vulnerabilities being uncovered in a year, a shorter period for adjusting the minimum security standards could improve security. 6.5.2.1.8 Inadequate Assumption About the Security of the Systems Inside the Healthcare Telematics Infrastructure In (gematik 2006j) it is mentioned, that all IT systems within the VPN provided by the healthcare telematics infrastructure can be considered secure. This argument is, for example, used to justify the missing authentication concerning the connection to the healthcare telematics timeservers. The fact is that there are no completely secure IT systems41, and therefore this argument is not acceptable. Also IT systems controlled and maintained by the healthcare telematics infrastructure itself are vulnerable to various threats, including social engineering attacks, etc. (Peltier 2006). In contrast to the claim cited above, in (gematik 2007f) it is noted, that it is impossible to completely avoid threats and that there will continuously emerging new threats. 6.5.2.1.9 Security by Obscurity In (gematik 2007f), gematik claims that security by obscurity is an improper approach to securing IT systems. Nevertheless, the software used for eHC purposes is classified as highly confidential in the same document. This classification results from parts of the software being the intellectual property of the developing companies. Of course, copyright issues have to be considered in the eHC environment as well, but Shannon’s maxim and Kerckhoff’s principle42 should also be taken into account. At the least, those parts of the eHC related information systems that contain security relevant processes should be published completely and not kept confidential because of intellectual property issues (Huber/Sunyaev/Krcmar 2008a). 6.5.2.2 Analysis of the Connector 6.5.2.2.1 Imprecise Specification of the Blacklist Management The security concept of gematik states that each connector has to validate the certificate of the VPN concentrator of the central part of the healthcare telematics infrastructure 43. In this context, blacklists are used to identify connectors with revoked certificates, which have to be up40 41 42 43

http://www.cert.org/stats cp. (Huber et al., 2007, p. 10) cp. requirement 002.So.A.AS in (Huber/Sunyaev/Krcmar 2008b) cp. Figure 51

206


dated periodical (gematik 2008h). Besides this definition, no further information about implementation and handling of blacklists can be found in any of the documents reviewed. One of the most important issues concerns the origin of the connector’s blacklist information. Obviously, a server inside the healthcare telematics infrastructure can’t provide the information as retrieving the blacklist information would involve connecting to a potentially insecure VPN concentrator. Furthermore, there are several authentication requirements concerning the blacklist service, requirements that have clearly not been considered yet. If insufficient authentication is used, an attacker could claim to be a blacklist-server and thus provide fake blacklists containing some or even all VPN concentrators of the healthcare telematics infrastructure. In the event of such an attack, the healthcare telematics infrastructure would not be reachable because all of its VPN concentrators would be blacklisted. 6.5.2.2.2 Imprecise Specification of the Trusted Viewer Interface According to (SigG 2001, §2, no. 11 respectively §17, para. 2) and (SigV 2001, §15, par. 1c, 2a and 2b) the connector has to provide a trustworthy component - a so called Trusted Viewer component - which enables the verification of signatures and the signed content. There are two possibilities for implementing this component. The connector could contain a built-in Trusted Viewer device or a Trusted Viewer component could be included as a separate component accessing an adequate connector interface over the LAN. Concerning the implementation of the Trusted Viewer and its interface, conflicting details can be found in the specification document (gematik 2006j). On the one hand, it is postulated that every connector has to include an interface for the Trusted Viewer regardless of whether it has a built-in Trusted Viewer component or not (cp. (gematik 2006j)), but on the other hand, the connector has to include the Trusted Viewer interface only if it does not contain a Trusted Viewer component on its own (gematik 2006j). 6.5.2.2.3 Security Issues Concerning the Communication with the Trusted Viewer All communications between the connector and the trusted viewer has to be secured by SSL according to (gematik 2007h)44(gematik 2007h)45(gematik 2006j)46. In (gematik 2006j), it is mentioned that the Trusted Viewer will most likely be included as a separate piece of software. Therefore it would probably not improve security to provide this component with an own identity. The Trusted Viewer will de facto have no identity of its own which implies that authentication between connector and trusted viewer will be, at best, one-sided. This situation supports man-in-the-middle attacks. 44 45 46

cp. requirement 005.In.K.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 011.Vt.K.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 026.In.K.AS in (Huber/Sunyaev/Krcmar 2008b)


207

Nevertheless, if there were two-way authentication, it might still be possible to use fake certificates to launch a man-in-the-middle attack between the connector and the trusted viewer. So far, it has not been explained, how the Trusted Viewer should verify the connector’s certificate or vice versa. Furthermore, it is not explained what happens if a man in the middle attack between connector and trusted viewer occurs because of fake certificates. Will the user be prompted and informed that the certificate is invalid? Where will they be prompted? How can be it ensured that users do not ignore the warning? The worst case scenario for a successful man-in-the-middle attack related to this issue could include, for example, the forgery of prescriptions. 6.5.2.2.4 Security Issues Concerning the Communication with the Primary System The problems illustrated above can partially be adopted for the communication between Primary System and Connector. In none of the regarded documents, there can be found any requirement concerning an authentication between these two components besides the generally postulated use of SSL for the communication between components in the peripheral part of the healthcare telematics infrastructure (cp. (gematik 2007h)47(gematik 2007h)48(gematik 2006j)49). If there will be an authentication between these two components, it probably would only be one-sided, due to the lack of a requirement demanding the Primary System to provide its own identity. The missing or just one-sided authentication enables the establishment of man-in-the-middle attacks between Connector and Primary System. Even if there was an authentication between Primary System and Connector, at least the Primary System could not verify the Connectors identity. Therefore, the Primary System would have to verify the identity by using some kind of service, provided by the healthcare telematics infrastructure. According to (gematik 2007f), the direct access of the healthcare telematics infrastructure by a Primary System is strictly forbidden, and the Connector itself does actually not provide a service like this as well. The worst case of a successful man-in-the-middle attack according to this issue could for example be the illegal retrieval of sensitive medical data of an insured person.

47 48 49

cp. requirement 005.In.K.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 011.Vt.K.AS in (Huber/Sunyaev/Krcmar 2008b) cp. requirement 026.In.K.AS in (Huber/Sunyaev/Krcmar 2008b)

208


6.5.2.3 Analysis of the Primary System 6.5.2.3.1 Insufficient Classification of the Processed Data According to (IBM et al. 2004), the security level of data processed by a Primary System is classified as low or medium. The requirements of these levels are allegedly covered by the security measures of an actual Primary System. According to the classification of IT-Grundschutz50, the abuse of the concerning data would result amongst others in the following: x

the abuse would have only marginal legal consequences,

x

the effects on the social position and the financial circumstances of the person concerned would be insignificant,

x

the tolerable downtime of the Primary System would be 24 hours,

x

the financial loss of the institution using the Primary System would be tolerable.

It is obvious, that the tolerable downtime of systems in the healthcare sector is in most cases not as long as 24 hours. Hospitals definitely cannot afford downtimes of their IT systems as long as 24 hours. Furthermore, the abuse of private, medical data of an insured can result in severe consequences - for example the anamnesis of a person in the hands of his or her employer or insurance company. 6.5.2.3.2 Unassigned Assumption About the Presence of Security Measures Provided by Present Primary Systems According to (IBM et al. 2004), the security measures used in a present Primary Systems are sufficient to assure the postulated level of security for the processed data, which is classified as normal based on the categorization of IT-Grundschutz51. To verify this claim, some of the major manufacturers of Primary Systems have been asked whether they provide for example encryption of sensitive data or role based and password protected user access. 4 of 17 addressed companies answered and confirmed to provide some kinds of security measures in their products. So on the one hand, the claim has been verified, but on the other hand, the question comes up why the remaining companies did not respond at all and whether this behavior is related to providing security features or not.

50 51

http://www.bsi.de/gshb/index.htm http://www.bsi.de/gshb/index.htm


209

In contrast to the four companies providing security features in their products, the designee for data protection and freedom of information in Germany, Peter Schaar claims, that the present Primary Systems frequently do not offer any access control or encryption features (facharzt.de 2005). 6.5.2.3.3 Analysis of the Card Reader As the used card reader is a SICCT standardized, self-contained piece of hardware, its development is not part of the eHC development process and thus it would be no benefit to analyze it in detail. The terminals are being analyzed during their development and certification process. Thus, the card terminals were only considered from a general point of view in the present work, whereas no weaknesses could be revealed. Due to its own digital certificate, the communication between other components and the card reader can be secured by a strong authentication. Furthermore, the card reader is sealed physically, so manipulation attempts can be detected easily. Nevertheless, a practical analysis of these components might be interesting as thus, for example implementation deficiencies could be uncovered. Section 6.6 discusses such a practical security analysis of the healthcare telematics infrastructure peripheral parts. 6.5.2.4 Additional Deficiencies Found During this Security Analysis By applying the iterative security analysis process as suggested by the HatSec method, several additional deficiencies were discovered. Several of them refer to missing parts of documentation52 that still have to be filled by the gematik. 6.5.2.4.1 Missing Specification for Services to Manage eHC Data by the Insured An important and basic requirement of the healthcare telematics infrastructure and the eHC is to enable the insured to exercise his right to view and administrate his own medical data (gematik 2008h). Therefore, two services are planned to privately manage data on the eHC. The so called eKiosk will be a terminal positioned in public places like hospital lobbies, where every insured person can insert his eHC and view or change permissions on data stored on the card. Another service, called Versicherter@home, will enable the insured to manage eHC data at home using the internet. However, neither of these services can be found in the gematik documents, as they belong to the services that will be introduced at last. Since both of them access medical data on the eHC and are less secure than other healthcare telematics infrastructure components due to their ex-

52

gematik did not publish all announced specification documents regarding health care telematics infrastructure in Germany by the date this thesis is completed.

210


posed position, they have to be thoroughly tested and secured, so it may be unwise to specify such critical components at last. 6.5.2.4.2 Missing Backup Processes for Essential Healthcare Telematics Processes As mentioned earlier, one of the security requirements for services within the healthcare telematics infrastructure is to provide backup processes in case the healthcare telematics infrastructure experiences technical difficulties and is unavailable, as stated in (gematik 2008d, 2008h). But so far, no backup processes are described in the specification documents. Because of attacks or technical problems, a one hundred percent availability for components within the healthcare telematics infrastructure can't be guaranteed. 6.5.2.4.3 Possibility of Health Insurance Number Readout by Unauthorized Persons The health insurance number of an insured person issued together with the eHC remains the same throughout the patient’s life, so that it can be used for identification purposes. Because of this it is vital that the number be kept confidential. In (gematik 2008h), a requirement defines that the use of the insurance number stored on the eHC for non health-related purposes should be avoided and access to the number on the eHC should be restricted to medical service providers and other authorized personnel to prevent the leakage of data. RFC 2119 53 states that should defines a recommendation with room for exceptions. As no reasonable exceptions are given by gematik, there is no reason to use should instead of must. Unauthorized users must not have access to the insurance number. 6.5.2.4.4 Logs for SMC Access on the Primary System May Not Be Reliable To protect medical data on the eHC, access is only possible by providing authentication using a HPC or a Security Module Card (SMC). SMCs can be used by the medical service provider’s personnel to gain access as representatives of their institution without a personal HPC. It is stated in (gematik 2008h) that the Primary System must generate a reliable access log for all users with SMC access. This can only be done using software encryption on the log file, as the primary system doesn't possess any hardware key material. Software encryption tends to be less secure as key material may be reverse engineered by an attacker gaining control over the primary system. SMC access is part of the healthcare telematics infrastructure use cases and therefore any logging should be done on a healthcare telematics infrastructure component (e.g. connector) instead of the primary system.

53

http://www.ietf.org/rfc/rfc2119.txt


211

6.5.2.4.5 Problematic Assumptions about the Environment of the Medical Service Provider In (gematik 2008g) it is assumed that the Primary System will provide sufficient security for stored medical data until the data is transferred into the healthcare telematics infrastructure. It is further assumed that the medical service provider’s LAN is hardened against unauthorized access by relevant measures of the IT-Grundschutz. The medical service provider’s LAN and the computer containing the primary system consist of standard electronic parts and no temper-evident casing, so the security measures outside of the peripheral healthcare telematics infrastructure tend to be significantly lower than within. Security and penetration tests on LANs and Primary Systems would help to detect vulnerabilities and enhance local security. In (gematik 2008g) it is assumed that the medical service provider’s personnel will regularly (at least annually) check the healthcare telematics infrastructure components and the trusted viewer software for manipulation. A manipulated component staying undiscovered for up to a year is not satisfactory given the amount of data that will pass through the healthcare telematics infrastructure per day. Therefore this time span should be shortened. 6.5.2.4.6 Insider Attacks from Medical Service Provider’s Personnel Not Considered in Threat Analysis The introduction to the threat analysis in (gematik 2008g) states that the medical service providers and its personnel are regarded as trustworthy and are not considered possible attackers. However, insider attacks performed by healthcare personnel are entirely possible and lead to several million Euros in damage per year for health insurance companies. Larger companies have special agents to hunt down people responsible for fraud within the healthcare sector, as stated by an article in SPIEGEL magazine54. Therefore medical service provider’s personnel should be considered potential healthcare. 6.5.2.4.7 Potential for an Attack on the Medical Service Provider’s LAN Considered As Too Low The introduction to the threat analysis also assumes that the potential for an attack on the peripheral healthcare telematics infrastructure is higher than the potential for an attack on the medical service provider’s LAN (gematik 2008g). As already mentioned, the non-healthcare telematics infrastructure components generally have a lower security level than healthcare telematics infrastructure components, so an attacker would more likely concentrate on breaking into the primary system rather than trying to attack a connector, for example. 6.5.2.4.8 Missing Best-Practices Recommendations for Software Keys (gematik 2008g) explains the security functions of the eHealth-card terminal. In this context it is explained that Best-Practices recommendations for software keys are to be noted. However, 54

http://www.spiegel.de/wirtschaft/0,1518,433364,00.html

212


no specific recommendations and no specific source of information are given to the reader. This information should be supplemented to provide a complete specification. 6.5.2.4.9 Missing Emergency Plans Regarding New Attacks on Components and Cryptographic Methods In (gematik 2008g), gematik states that there is no complete defense against the emergence of new attacks on components and cryptographic algorithms used within the healthcare telematics infrastructure. Providing emergency measures to be taken in case of a successful attack can reduce the remaining risk. Currently, no such emergency measures exist. In order for the specification to be complete, gematik should provide emergency measures, including the exchange of key material, exchange of healthcare telematics infrastructure components not patchable with a software update, emergency software updates for swift reactions to new threats or program errors, and exchange of smart cards (eHC, HPC, SMC) whenever cryptographic or technical issues emerge that could pose a security risk. 6.5.3

Attack-Tree Analysis

As part of the HatSec method, an attack-tree analysis has been developed to identify the most likely and easy attacks. Within the analysis, attack-trees for each of the components, except for the primary system, have been made. The primary systems were excluded from this analysis step due to the variety of primary systems available. There is no standardized primary system because of the manufacturers’ freedom to construct primary systems according to their own preferences. The results of the attack-tree analysis were two large attack-trees for the connector and the card terminal including over 600,000 attack-scenarios each (Huber/Sunyaev/Krcmar 2008b). The attack-trees can be used for further work. In the work by (Huber/Sunyaev/Krcmar 2008b) it emerged that attacks on a technical level are mostly very expensive or unfeasible because the amount of time involved (de Ru/Eloff 1996). Several non- or semi-technical attack methods were also included in the attack-tree analysis for the sake of thoroughness. Including these methods revealed that the most likely attacks are ones that involve bribing, blackmailing or spying on confidential information. These kinds of attacks are typical for attackers belonging to organized crime or terrorist groups as mentioned in section 6.2. 6.5.4

Summary

As a result of the analysis, 24 deficiencies within the security concept of the system currently being developed were identified and described. These include weaknesses and violations of various security demands as well as inconsistent, convicting, or incomplete development and


213

specification documents. The identified security issues are the first results and experiences from the introduction of the healthcare telematics in Germany. More than any other results, the privacy and security concepts analyzed and the vulnerabilities discovered within the German healthcare telematics plans might be helpful for other healthcare telematics projects and could potentially safeguard against possible vulnerabilities in future healthcare information systems. This analysis offers basics and various starting points such as the constructed attack-trees (Huber/Sunyaev/Krcmar 2008b) or the revealed weaknesses that can and should be verified in practice. Section 6.6 illustrates an example. 6.6

Security Analysis of the German Electronic Health Card’s Peripheral Parts in Practice

The fifth case study explores the security analysis of the peripheral sections of the German healthcare telematics on the practical level. The results of this case show the practical application of the HatSec method. The goal of the fifth case study is to examine the suitability of the HatSec method for e.g. penetration tests or the practical examination of German healthcare telematics. This case study shows that the HatSec method is effective. Several open security issues in German healthcare telematics were discovered. This section analyzes the primary systems of the German healthcare telematics according its security level. The results are specific to the forthcoming healthcare telematics in Germany and build a core of the performed security analysis. Figure 52 illustrates the concrete implementation of the HatSec method in this case study.

h

f

i



Security Assessment

g



e


d



c



Selection of actions to minimize the risks implied by present vulnerabilities, and weaknesses

Identification and description of revealed vulnerabilities

Analysis on a practical level

Identification of assets, security requirements, legal requirements, security measurements


Methodical analysis by: x Penetration tests x Tools for analysis x Exploitation frameworks x Attack-Trees x Metrics x ...

214 6 Practical Application of the HatSec Method

Figure 52: Practical Security Analysis according to the HatSec Method (Source: own Figure)

6.6 Security Analysis of the German eHC‘s Peripheral Parts in Practice 6.6.1

215

Overview

This section describes a technical security analysis that is based on experiments done in a laboratory and verified in a physician’s practice. The introduced attack scenarios show that there are several open security issues in the peripheral components of German healthcare telematics system. The results are based on extensive laboratory experiments and on a detailed review of gematik’s specifications. The fact that there is no current standard for secure practices (Avery et al. 2007) is a pressing issue. gematik shifts them into the service consumer tier (SCT) and in this vein they place the responsibility for the primary systems on the service providers. According to (gematik 2008d), the SCT’s systems are not part of the telematics infrastructure, but are only used by them. This means that there are no rules defined for them by gematik (gematik 2008h) and there is no separate security concept as well. gematik also states that it should not be a problem that primary systems can remain unsupervised for up to 30 minutes (gematik 2008g). 6.6.2

Laboratory’s / Physician’s Practice Configuration

The laboratory consists of three main components: the connector, the card reader, and the primary system. This is a standard configuration which is used in every physician’s practice in Germany (Sunyaev et al. 2008d). The connector is the central component in the peripheral part of the telematics infrastructure. If the primary system is to access an electronic health card placed into the card reader it has to call up a connector in order to continue. It is not possible to establish a direct connection between the card reader and the primary system. So if data has to be transferred into the central part of the healthcare telematics infrastructure only the connector can do so. The connector used in this test is part of the Futro S400 series by Siemens in version V1.07R4.5; hpscV1.07R4_build_2493_R13198. The card reader Cherry® SICCT Terminal in version 10037 is another component attached to the laboratory’s network. The electronic health card and the health professional card (HPC) can be inserted into the card reader. It also has a keypad where numeric codes can be entered in order to gain access to these cards’ functions.

216


Figure 53: The Laboratory’s Configuration (Source: own Figure)

A standard personal computer was used as the primary system. The computer used had an AMD® Opteron Processor 144 with 1.81 GHz and 2.5GB RAM. Windows® XP with Service Pack 2, DocConcept® 8.255, DocConnect®56 and Siemens® Trusted Viewer were installed on the computer. The connector’s functions can be initialized with the practice software in order to use the electronic health card’s functions. The functions allow the user to read the administrative data, electronic prescriptions and emergency information stored on the eHC. These components are normally connected by LAN via a standard switch. But the switch was replaced by a repeating hub during the special network analyses (Figure 53).

Figure 54: The Practice Network from the Attacker’s Point of View (Source: own Figure)

A laptop acting as an attacker connected to the network was used for some experiments. It is equipped with a Core 2 Duo T74002x 2.16GHz processor and 2.0GB RAM. While running Windows Vista Business with Service Pack 1 as an operating system, it has none of the tools 55 56

DOCexpert Computer GmbH DOCexpert Computer GmbH

6.6 Security Analysis of the German eHC‘s Peripheral Parts in Practice

217

that are normally used to connect to the electronic health card. But it has several tools installed that enabled an analysis of the network’s traffic. An own client for the connector was also developed. In order to validate the results of the experiments several tests in a real physician’s practice were undertaken. A treatment room was used for the trials. In these an attacker accessed the LAN by using a port behind a piece of furniture. Figure 54 shows which hardware was found analyzing the network and which was accessible. Because the practice had a well-secured network it was not possible to break into the windows domain that connected the practice computers, but it was possible to access the telematics hardware. That means that the attacker did not have access to PCs with practice software, but the attacker was able to control the connector and with it every card reader used in the practice. 6.6.3

Network Traffic Analyzes and its Consequences

While analyzing the data sent over the network, all components were connected via a repeating hub. This means that in contrast to a normal switch all data is sent to every attached device. The use of tools like Wireshark (http://www.wireshark.org) or EttercapNG (http://ettercap.sourceforge.net) makes it possible to get a good impression of the network’s dataflow. The results show: a) The connection between the card reader and connector is fully encrypted. b) There is no encryption between the primary system and the connector. The encrypted connection between the card reader and the connector is enforced by gematik (gematik 2008f). The missing encryption between primary system and connector is the result of the lack of a specification from gematik (gematik 2008g, 2008h) defining the use of a TSL encryption between connector and primary system as optional. As there is no encryption in the implementation all requests and answers from the primary system and the connector can be captured and looked at in plain text by a third party. This security issue is known to gematik (gematik 2008g), but it is labeled a residual risk. It is left to the readers to decide if the possible theft of their private data, which includes administrative data as well as medical emergency information or electronic prescriptions, is an acceptable threat. In addition to the fact that there is no encryption between the primary system and the connector there is also no enforced authentication. That means anyone can access the functions pro-

218


vided by the connector. Using PHP (http://www.php.net) as the programming language in combination with the principles of extreme programming (Beck 2000) an own client was implemented in order to test derived attack scenarios. The program can be controlled via different interfaces, e.g. with a command line tool or a web interface. There are three modes offered by the program: x

The “direct”-mode allows calling functions instantly.

x

The “wait”-mode tries every three seconds to find an attached card and then sends the request.

x

The “listen”-mode registers at the connector and waits for an event, which is triggered when a card is attached and the request will then be sent to the connector.

The client is able to access all functions at the connector that can also be used by DocConnect 8.2. Therefore it can act like a normal primary system and remain well hidden. Abuse of connector functions leaves the system open to very serious attack scenarios. 6.6.4

Attacking the German Electronic Health Card

attacking the eHC

disrupting the use of the card(s)

permanent ejection of attached cards

fill or delete prescriptions

block a card

spy personal data

destroy a card

steal administrative data

steal prescriptions

steal medical emergency information

Figure 55: Attack Tree (Source: according to (Sunyaev et al. 2009b))

The attack tree shown in Figure 55 denotes that the attacks can be classified into disrupting and spying types. The utilization can be interrupted when permanently ejecting all cards that get attached to a card reader. The deletion of prescriptions stored on the electronic health card is as possible as the blocking or destruction of the card itself. An attacker can also steal administrative data, prescriptions and medical emergency information stored on eHCs.


219

Permanent-Card-Ejection PIN needed:

None

supported card types:

All

Connector’s function:

Eject Card

gematik’s specification:

(gematik 2008e, 200 section 5.4.3.3.6) Delete or fill all prescriptions

PINs needed:

HPC practice’s PIN

Supported card types:

EHC

Connector’s function names and their gematik’s specification

ReadVO: (gematik 2008f, 73 section 6.2) DeleteVO: (gematik 2008f, 79 section 6.4) DispenceVO: (gematik 2008f, 76 section 6.3)

Block a Card PINs needed:

PIN to change


EHC, HPC


ChangePin


(gematik 2008e, 204 section 5.4.3.3.8)

Destroy a Card PINs needed:

PUK for locked PIN


EHC, HPC


UnblockPin


(gematik 2008e, 209 section 5.4.3.3.12) Steal private data from electronic health card

PINs needed:

HPC practice’s PIN


EHC

Connector’s functions and their gematik’s specification:

ReadVSD: (gematik 2008f, 52 section 7.1) ReadVO: (gematik 2008h, 73 section 6.2) ReadNFD: (gematik 2008g, 31 section 6.2)

Table 36: Connector’s Functions that can be abused (Source: according to (Sunyaev et al. 2009d))

All attacks are based on the following scenario: The attacker can gain access to the physician’s practice network, e.g. through hacking the WLAN or just plugging into a socket. Also another common procedure is needed in order to access some functions: The physician unlocks his own health professional card (HPC) with his personal identification number (PIN) in the morning and locks the card in the evening, which means the card is ready for use throughout the day.

220


Table 36 shows the specifications of the functions that would be abused in order to attack the German electronic health card under this scenario. 6.6.4.1 Permanent-Card-Ejection The attack: There are two ways to realize a permanent ejection. On the one hand it is possible to constantly call a function that ejects a card, e.g. every three seconds. On the other hand the registration to an event handler at the connector is possible. Then an event is triggered and an immediate response can take place. Regardless of the use it is not possible to attach any card to a card reader anymore (Figure 56). A possible solution: As there is no additional benefit created when ejecting a card via the network this function could easily be removed. It is fully sufficient when a card can only be ejected locally at the card reader.

ad: Permanent-Card-Ejection Card is reattached

No retry

Card gets attached

call: EjectCard

Card gets ejected

Figure 56: Activity Diagram - Permanent Card Ejection (Source: own Figure)

6.6.4.2 Fill or Delete Prescriptions The attack: In order to delete or fill a prescription its Object ID is needed. This is received from the connector in the first step of the process. After reception, the function for deleting or fulfilling the prescription can be initiated (Figure 57). Because there is a limit of eight prescriptions on every electronic health card this procedure will only be repeated at most eight times until every prescription is dispensed or deleted. A possible solution: A physician’s signature is needed to write or change a prescription on an eHC. The use of this PIN while deleting or dispensing electronic prescriptions would weaken the concept of a fully automated function call as described above. Therefore, the attack would


221

not be possible anymore, because every action would have to be authorized by a person on the card reader.

ad: Fill or delete prescription call: DeleteVO / DispenseVO parameter: ID of last prescription

check if prescriptions are available

Card gets attached

call: ReadVO

Figure 57: Activity Diagram - Fill or Delete Prescriptions (Source: own Figure)

6.6.4.3 Block a Card’s PIN The attack: One connector function enables the user to change a card’s PIN remotely. A PIN can be entered incorrectly three times before it is locked. This means abusing this function could block the card (Figure 58). In an experiment it took 350ms to call this function. This means a PIN can be locked within one second.

ad: Lock a PIN

for count = 0

Card gets attached with not locked PIN

while count < 3

PIN locked

do call: ChangePIN wrong param: oldPIN

count = count +1

Figure 58: Activity Diagram - Lock a PIN (Source: own Figure)

A possible solution: As this function does not generate additional value and would be probably only be used very rarely, the function should be removed. It would be sufficient to be able to change the PIN only directly at the card reader.

222


6.6.4.4 Destroy a Card The attack: When a PIN is locked, a function can be called with which the user can unblock the PIN. As a parameter the personal unblocking key (PUK) is needed. It can only be used ten times before it becomes irreversibly locked. So using this function with an incorrect PUK ten times on a locked PIN would lead to a locked PIN and a locked PUK. Not being able to unlock the PIN means that the card cannot be used anymore. The card is effectively destroyed (Figure 59).

ad: Destroy a card

for count = 0

Card gets attached with locked PIN

while count < 10

PUK locked = Card destroyed

do call: UnlockPIN wrong param: PUK

count = count +1

Figure 59: Activity Diagram - Destroy a Card (Source: own Figure)

A possible solution: The occurrence of a locked PIN should be an exception. So there is no real need to implement such a function in the connector and the primary systems. Furthermore, it would be sufficient if the PIN can be unlocked directly on the card reader. 6.6.4.5 Spy Personal Information As the theft of administrative data, electronic prescriptions and emergency information work in the same way they are all combined in Figure 60. The attacks: When a card is inserted, connector functions can be activated in order to steal administrative data, electronic prescriptions and emergency information. In response an XML file is provided. This file can be easily parsed and saved. The collection of this data (Table 37) gives the attacker private information about the patient and detailed knowledge about their health.


223

ad: Spy personal information call: ReadVO

Card gets attached

call: ReadVSD

parse & save response

call: ReadNFD

Figure 60: Activity Diagram - Spy Personal Information (Source: own Figure)

A possible solution: As these functions are essential they cannot be removed. Protecting them with a separate PIN would delay practice work. So only a secure connection between the primary system and the connector, which is encrypted and authenticated, will solve the problem. administrative data

– – – – –

insurant id given name, family name birthday, sex full address information about insurance coverage and the insurance company

electronic prescriptions

– – – – – –

date of issue patient’s and physician’s administrative data information about the prescription name of medication name of pharmacy usage information

emergency information

– – – – –

(past) diseases medication (and incompatibility) attending physician persons to be notified other notices (free text)

Table 37: Summary of Content that can be spied out (Source: own Table)

224


6.6.5

Summary

In the course of the present work critical security issues in the German electronic health card’s system have been discovered. These have been tested in a laboratory and have been verified in a real physician’s practice (Table 38). Therefore the following statements must be made: x

Patient’s private and very sensible data stored on the German electronic health card are not secure and it is possible to steal them because the card is used in an unsecured environment.

x

Manipulations of the eHC and health professional card are also feasible.

x

Possible solutions to these security issues have been proposed. It is undeniable that the connection between the connector and the primary system must be encrypted and that authenticcation has to be enforced. The solutions proposed are not extremely expensive or complicated. Also, it should be possible to implement them in a timely manner. In this regard the rules and scenarios for primary systems should also be included in the specification in order to create a nationwide standard for practice information technology. Attack

Consequences

Permanent-CardEjection

Practice system cannot be used during an attack. This results in a work delay.

Delete all prescriptions

Patient looses all his prescriptions; this is very annoying, especially if he has had prescriptions form different physicians on the card.

Block Card

Unlocking with PUK is possible, but at first the PUK has to be send to the insurant by mail.

Destroy Card

The insurant has to order a new card at his insurance company.

Spy administrative data

Name, address, birthday and insurance data get stolen.

Spy prescriptions

Data which gets stolen can be used to deduce the recent state of health.

Spy emergency information

Information about medication intolerance, previous diseases and other highly private data gets stolen.

Table 38: Attacks tested in Laboratory and Practice (Source: own Table)

For future work, the components should also be exposed to further penetration tests. E.g. man in the middle attacks should be launched between the TLS encrypted network parts and hardware manipulations should be tested.

6.7 Case Studies: Lessons Learned 6.7

225

Case Studies: Lessons Learned

The goal of the cases was to present the application of the Hatsec method in practice and thus verify the feasibility of the developed approach. The cases explored the initiation of the HatSec method by analyzing the security of the current situation in German healthcare telematics. Direct comparison and verification of the HatSec method was difficult, the presented cases overlap in some ways, but they do not contain each other. Also the thoroughness of the HatSec method could not be checked since not all of the method parts were used in the described cases. The explanatory power of the cases was limited by the current status of German healthcare telematics. To investigate, e.g. the applications of the electronic health card in medical environments, the actual use of these cards would have to take place – this was not the case during the work on this thesis. One of the advantages of the HatSec method is its flexibility, so the method user can decide on their own which method parts should be applied and which not. Furthermore, the HatSec method does not require any specific skills in order to use it. Every CISO should be able to understand the established security approaches and thus use them as a reference documents. These documents are described in detail and include internationally accepted standards, bestpractice approaches or obligations provided by formal organizations. Most of referenced approaches are written down in comprehensive documents. As demonstrated the HatSec method can do more than uncover vulnerabilities in healthcare systems. The method also aims to provide further improvements of the analyzed issues. The last three cases presented detailed solutions to every vulnerability in the system. The HatSec method proved its usability on the organizational level by having an option to focus of the security issues on the process level. This implies that the HatSec method can target organizational risks that are almost always the result of user’s interaction with an information system. Such risks are especially problematic for healthcare because German healthcare telematics is based on largely on the interaction of patients with information systems. Due to the design of the HatSec method, it is easy to ensure comparable and reproducible results. The HatSec method was built of already existing method parts. These method parts were chosen according to their applicability to healthcare and also because of their tracebility and acceptation in IS security. However, this fact was viewed critically during the review of the HatSec method.

226


The concept of the approach in its current form has an inherent limitation. HatSec method remains on the abstract level of method design. Every specific step of the HatSec method is connected to the method part of another security approach. The selection of according method parts is determined by the user. This freedom can lead to unsatisfactory results after its application. Furthermore, the interfaces between the steps were defined on the basis of the presented analysis of IS security approaches. The outputs of different method parts can vary and thus influence the following security analysis steps. To summarize the results of the case studies: the studies demonstrated the applicability of the proposed security analysis method, revealed its limitations, and produced valuable results for improving the current security of German healthcare telematics. Overall, one can say that the HatSec is a generic security analysis method. The advantages are its flexibility (due to exchangeable method fragments) and its focus on processes. In contrast, HatSec can be considered as an abstract method, because it takes parts of other security approaches and arranges them into a new artifact. The derived results from the security analysis of German healthcare telematics (Chapter 6) were achieved on the basis of the HatSec method, but the intrinsic security analysis was based on the identified parts of existing IS security analysis approaches. This makes it difficult to review the actual effectiveness of the HatSec method. That is why the description of the presented parts of the security analysis considered the results of the analysis itself, its contribution and possible improvements for the German healthcare telematics but not the HatSec method specifically. Furthermore, the presented results are too diverse and specific to reconcile them exactly according to the HatSec method. This is a major shortcoming of the presented practical application of the HatSec method. A decision was made at the beginning of this research to focus on the findings that can help to shape German healthcare telematics’ reliability. This led to the introduced results, each of which solves a concrete problem situation at hand and therefore neglected the actual purpose of the practical application of the HatSec method. The achieved results may not be unique to the HatSec method. This results from the structure of the HatSec, which is constructed from matched parts of existing IS security analysis approaches. All of these facts complicate the evident efficacy of the HatSec method.

7 7.1

Appraisal of Results Overview

The purpose of this research was to derive an approach for analyzing the security issues of the healthcare telematics infrastructure in Germany. The developed HatSec method helped to identify security problems in the current situation of German healthcare telematics. The structure of this thesis was based around four successive research questions described in section 1.2. The latter, along with the associated findings, are introduced in this chapter: 1. What are the special characteristics of healthcare telematics with respect to security? First, a detailed description of German healthcare system was presented. The description led from the structure of German healthcare to the specific characteristics of healthcare domain. Furthermore, the difference between healthcare and other important sectors was pointed out. The principle of information logistics in healthcare completed the introduction to healthcare in this thesis. In the following step, the healthcare telematics infrastructure being developed in Germany was introduced. The section included descriptions of underlying and associated mechanisms as communications and documentation standards in healthcare, contributory standardization approaches, and instantaneous healthcare information systems architectures. As the main answer to this first research question, a catalogue of IS healthcare security characteristics was created. These healthcare specific security characteristics were summarized according to a comprehensive literature research approach as proposed by (Webster/Watson 2002). The characteristics included specific German legal requirements, identified and expanded healthcare IS security protection goals as well as established and recently defined IS security approach characteristics. These characteristics demanded specific security requirements for the appropriate use of information and communication technology (ICT) in public health systems on both the technical and organizational levels and formed the basis for the design of the HatSec method. 2. What different types of security analysis methods can be identified in science and practice? The outcome of the second research question was an extensive presentation of the current IS security analysis approaches that are receiving attention in literature at present. In addition, all identified IS security analysis approaches were structured around a newly developed classifi-


228

7 Appraisal of Results

cation scheme. No similar aggregation and systematization scheme for IS security analysis approaches could not be found during the work on this thesis. This classification scheme supported the analysis of identified IS security approaches according to their suitability for the current healthcare situation in Germany. The developed classification scheme can be used in both future research and practice. Moreover, the literature review showed insufficiencies in current IS security analysis methods that lack techniques to analyze the technical and social aspects of information security in a healthcare environment. This again emphasized the need for a security analysis method specific to healthcare telematics. However, it was recognized that parts of the identified IS security analysis approaches can be applied in analyzing healthcare telematics in Germany. This fact was used later during the design of the HatSec method. 3. What are the design elements and constructs of a security analysis method for healthcare telematics in Germany? In order to develop, design, and implement the IS security analysis method the principle of method engineering had to be introduced first. The development of such a security analysis method, its concept, and its incorporation into the discipline method engineering were described. Furthermore, the specific building blocks needed for construction of the method were explained and analyzed. As a result an example of a method for a security analysis of healthcare telematics in Germany was conducted. The developed method was named HatSec. The study of this research question also provided a detailed overview of IS method engineering approaches as part of the description of method engineering. Based on a literature review a formal description of methods was derived that can be used to describe methods in a simple way and allow for their transfer to other fields of application. With the formal description of methods the process of understanding method engineering can be facilitated both for method user and method engineer. In this thesis the derived description of method engineering was then used as a representation technique for the development and presentation of a security analysis method for healthcare telematics. The described formal representation allows the HatSec method to be precisely understood regarding its usage as a model artifact and a reinterpretation of its syntactical elements (e.g., method elements, method chains and alliances, method fragments, method chunks and method components). Furthermore, the developed formal description of the concept of method engineering offers new possibilities for the development of IS methods both in future research and practice.

7.1 Overview

229

4. What are the implications found when applying the method and which recommendations can be given for future healthcare telematics security trade-offs? The practical application of the presented HatSec security analysis method completed this thesis. The current status of the security concept of the German healthcare telematics was analyzed and, where necessary, solutions for open security issues were provided. In addition, a design proposal for future German healthcare telematics security trade-offs was identified. Furthermore, a practical application of the HatSec method confirmed its suitability for the healthcare sector and can be seen as an example for its potential use. Both the results and the practical application served as essential resources for the further development of the HatSec method. 7.2

Progress of Cognition

The underlying principles of the HatSec method are generic in nature. However, the specifics of the healthcare domain – comprising its legal, cultural, political, socio-economic and sectored attributes – determine the context for this specific security analysis method (Gaunt 2000; Gerberick/Huber/Rudloff 1999). HatSec also considers both inter-departmental and inter-institutional issues. This provides good flexibility due to its possible application but it also places a great deal of responsibility on the HatSec user by making them decide which method fragments is to be applied. The HatSec method was intentionally left on the abstract level and contained a suggestion of possible security analysis steps with according references to some specific parts of established IS security analysis approaches. The practical application of the HatSec security analysis method, amongst others, illustrated the determination of the HatSec method in a practical operation. The derived classification of existing IS security analysis approaches, the developed formal description of the concept of method engineering as well as the corresponding construction approach of the HatSec method can be applied in every other IS domain. Summing up, the following results were achieved in this thesis: x

Security analysis method for healthcare information systems (HatSec).

x

Catalogue of IS healthcare security characteristics.

x

Classification of existing IS security analysis approaches.

230

7 Appraisal of Results x

Analysis of IS security analysis approaches with regard to their applicability in the healthcare domain.

7.3

x

Formal description of the concept of method engineering.

x

Assessment and classification of threats around the German healthcare telematics.

x

Analysis of the applications of the electronic health card.

x

A solution for managing doctor’s smart cards in hospitals using a single sign-on central architecture.

x

Theoretical security analysis of the German electronic health card’s components.

x

Security analysis of the German electronic health card’s peripheral parts in practice.

x

Identification of more than 24 deficiencies around the current status of the German healthcare telematics (including weaknesses, inconsistent and conflicting development documents and violation of security demands). Design Proposals for Healthcare Telematics

The introduction of the electronic health card in Germany and the associated forthcoming healthcare telematics infrastructure are being widely discussed in both scientific and mainstream publications. The major emphasis in these discussions is given to the issue of financing this large-scale project and questions about data integrity and the reliability of the healthcare telematics system. One recent research study in this field, conducted by the Frauenhofer Institute for Open Communication Systems, stated that the security concept currently being designed and implemented for the healthcare telematics in Germany can ensure the privacy of the medical data of every insured person in Germany (Fraunhofer-Institut für Offene Kommunikationssysteme 2008). But amendments for other healthcare telematics services, such as electronic patient records, have to be done. Some of the solutions proposed in this thesis could minimize the potential risks posed by the identified vulnerabilities. One must maintain that it was the best decision one could make to publish all specification documents of the German healthcare infrastructure publicly. All specification documents concerning the requirements of the composed telematics solution, architecture specifications of the technical infrastructure as well as of all peripheral components and especially comprehensive security concepts, models and cryptographic aims are freely accessible on the internet. This fact has led to numerous

7.3 Design Proposals for Healthcare Telematics

231

discussions and, of course, contributed to the overall (security) performance of the German healthcare telematics infrastructure. Nevertheless, the current status of the healthcare telematics infrastructure is comparable to that of a safe freeway with insecure on-ramps. Some of the possible threats and according solution were introduced in chapter six. The following identified and occurring problems should definitely be resolved before the electronic health card is introduced nationwide in Germany: x

The connection between the primary systems and the connector should be encrypted.

x

Backup processes for essential healthcare telematics processes and services should be defined.

x

Gematik should define and propose security specifications for primary systems.

x

Access logs for e.g. secure module cards should not be recorded within the primary systems.

These shortcomings of the German healthcare telematics architecture are solvable (Sunyaev/Leimeister/Krcmar 2009b); gematik should address these problems and improve the relevant specifications. But there is still one open issue that greatly weakens the entire security concept of the German healthcare telematics infrastructure. gematik has decided to establish a depository service. Such a depository will store and handle the private keys of patients (gematik 2008h). A depository will handle the keys that are stored physical on every electronic health card and can identify and authenticate these. The keys also store patient personal identification numbers. Furthermore the depository is allowed to use this material to transcode the keys and, if necessary, move the stored data. As a result, German healthcare telematics will include a location where all private keys will be stored and managed centrally. These stored objects will, of course be cryptographically secured but this set-up remains the biggest threat to the telematics infrastructure. Gaining access to such a depository would grant attackers access to the sensitive medical data of every participating insurant in Germany. Another important factor, although not technical in nature, which greatly affects the security of the healthcare telematics infrastructure is the “human factor”. As postulated by one of the most famous and acknowledged information systems security experts – Bruce Schneier (Schneier 2008; Schneier 2000; Schneier 1996): “security is a chain, and a single weak link can break the entire system”, “people are often the weakest link in the chain” and “securing the computer and network is hard, but it's much easier than securing the person sitting on the chair in front of the monitor.” The HatSec analysis method examines both the technical and

232

7 Appraisal of Results

organizational levels of IS security. Half of the presented security analysis results concerned processes and therefore concerned the security issues related to involved persons and their security awareness. HatSec, its application and derived security solutions remain to be a tradeoff. Everything in life is a trade-off. German insurants will face a trade-off in terms of the security and privacy of personal health information in German healthcare telematics. This means that insurants will have to decide whether they will sacrifice some degree of privacy by making medical data accessible to healthcare providers via information systems in exchange for access to the benefits of the telematics infrastructure. At present, every insurant in Germany can decide whether or not to use the benefit functions of German healthcare telematics. Currently, only the administrative data (patients name, address, etc.) is indispensable. The inclusion of personal health information in order to use healthcare telematics (section 2.3) remains the individual choice of every insured German. There is a real danger that eventually this voluntary aspect could be replaced by mandatory participation. The right to opt out of the telematics system is a fundamental one and one that should be defended. In conclusion, it should be mentioned that the first and the most important step towards the successful implementation of the German healthcare telematics is raising awareness among concerned healthcare providers. Clearly, no security concept can achieve its goal without the awareness and interest of the most important involved parties.

Bibliography Aagedal, J.Ø.; den Braber, F.; Dimitrakos, T.; Gran, B.A.; Raptis, D.; Stølen, K. (2002): Model-based Risk Assessment to Improve Enterprise Security. Paper presented at the Sixth International Enterprise Distributed Object Computing Conference, pp. 51- 62. AbouZahr, C.; Boerma, T. (2005): Health information systems. The foundations of public health. In: Bull World Health Organ, Vol. 83 (2005) Nr. 8, pp. 578-583. Adams, A.; Blandford, A. (2005): Bridging the gap between organizational and user perspectives of security in the clinical domain. In: International Journal of HumanComputer Studies, Vol. 63 (2005) Nr. 1-2, pp. 175-202. Adler, M.P. (2003): Approaching the Final Security Regulations Using Risk Analysis and Risk Management. In: Journal of Health Care Compliance, Vol. 5 (2003) Nr. 6, pp. 10-14. Agerfalk, P.J.; Goldkuhl, G.; Fitzgerald, B.; Bannon, L. (2006): Reflecting on action in language, organisations and information systems. In: European Journal of Information Systems, Vol. 15 (2006) Nr. 4–8, pp. 4-8. Ahlemann, F.; Riempp, G. (2008): RefModPM: A Conceptual Reference Model for Project Management Information Systems. In: WIRTSCHAFTSINFORMATIK, Vol. 2 (2008), pp. 88-97. Ahn, G.-J.; Sandhu, R. (2000): Role-Based Authorization Constraints Specification. In: ACM Transactions on Information and System Security, Vol. 3 (2000) Nr. 4, pp. 207226. Aikins, R. (2000): Risk Management Methodology for HIPAA Security Standard. In: Journal Of Healthcare Information Management, Vol. 14 (2000) Nr. 4, pp. 29-40. akteonline.de (2006): akteonline.de - eine persönliche elektronische Gesundheitsakte. www.akteonline.de, accessed 12.10.2006. Alban, R.F.; Feldmar, D.; Gabbay, J.; Lefor, A.T. (2005): Internet security and privacy protection for the health care professional. In: Current Surgery, Vol. 62 (2005) Nr. 1, pp. 106-110. Alberts, C.; Dorofee, A. (2001): OCTAVE Method Implementation Guide Version 2.0. Software Engineering Institute, Carnegie Mellon, 2001. Alberts, C.; Dorofee, A.; Stevens, J.; Woody, C. (2003): Introduction to the OCTAVE® Approach. Software Engineering Institute, Carnegie Mellon, 2003. Alderson, A.; Hull, M.E.C.; Jacksonc, K.; Grifﬁths, L.E. (1998): Method engineering for industrial real-time and embedded systems. In: Information and Software Technology, Vol. 40 (1998), pp. 443–454. Alex&Gross (2004): Marktstudie "IT im Gesundheitswesen". www.alexgross.de, accessed 22.12.2008.

A. Sunyaev, Health-Care Telematics in Germany, DOI 10.1007/978-3-8349-6519-6, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

234

Bibliography

Alexander, C. (1973): Notes on the Synthesis of Form, Harvard University Press, Harvard 1973. Alexander, C. (2003): Managing operational risks with Bayesian networks. In: Operational Risk. Regulation, Analysis and Management. Hrsg.: Alexander, C. FT Prentice Hall, London u.a. 2003, pp. 285-295. Aljareh, S.; Rossiter, N. (2002): Towards security in multi-agency clinical information services. In: Health Informatics Journal, (2002) Nr. 8, pp. 95-103. Allaert, F.A.; Le Teuff, G.; Quantin, C.; Barber, B. (2004): The legal acknowledgement of the electronic signature: a key for a secure direct access of patients to their computerised medical record. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 239-242. Almendros Jimknez, J.M.; Gonzalez Jimenez, L. (2000): The LAST Project: Development of a Formal Method for IS-Specification and of a CASE-Tool for IS-Design Paper presented at the Seventh Asia-Pacific Software Engineering Conference (APSEC'00), pp. 54-61. American Institute of Certified Public Accountants (2007): SAS 70. http://www.sas70.com/about.htm, accessed 07.06.2007. Ammon, D. (2002): Ready, Set, Grow: A local practice implements electronic medical record (EMR) technology, triples patient volume and reduces per patient costs by more then 10 percent. In: Health Management Technology, Vol. 23 (2002) Nr. 12, pp. 42-43. Amram, M.; Kulatilaka, N. (1999): Real options: managing strategic investment in an uncertain world, Harvard Business School Press, Cambridge 1999. Andersen, T.; Jøorgensen, G. (1988): Danish experience of statutory right of patients to access hospital records. In: The Lancet, Vol. 2 (1988) Nr. 8625, pp. 1428. Anderson, J.G. (1997): Clearing the way for physicians’ use of clinical information systems. In: Communications of the ACM, Vol. 40 (1997) Nr. 8, pp. 83-90. Anderson, J.G. (2000): Security of the distributed electronic patient record: a case-based approach to identifying policy issues. In: International Journal of Medical Informatics, Vol. 60 (2000), pp. 111–118. Anderson, R. (1996a): Security in Clinical Information Systems, British Medical Association 1996a. Anderson, R. (1996b): A Security Policy Model For Clinical Information Systems. Paper presented at the 1996 IEEE Symposium on Security and Privacy, Oakland, California, USA, pp. 30-43. Anderson, R. (2001): Security engineering: a guide to building dependable distributed systems, Wiley, New York 2001. Anonymous NICTIZ Website. http://www.nictiz.nl/, accessed 21.01.2006.

Bibliography

235

Anonymous (2001): Regulation (EC) No 45/2001 of the European Parliament and of the Council of 18 December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data. In European Parliament (Ed.), Official Journal of the European Communities. Anton, A.I.; Eart, J.B.; Vail, M.W.; Jain, N.; Gheen, C.M.; Frink, J.M. (2007): HIPAA's Effect on Web Site Privacy Policies. In: Security & Privacy Magazine, IEEE, Vol. 5 (2007) Nr. 1, pp. 45-52. Arrow, K.J. (1963): Uncertainty and the welfare economics of medical care. In: The American Economic Review, Vol. LIII (1963) Nr. 5, pp. 141-149. Artnak, K.E.; Benson, M. (2005): Evaluating HIPAA compliance: A guide for researchers, privacy boards, and IRBs. In: Nursing Outlook, Vol. 53 (2005) Nr. 2, pp. 79-87. Ash, J.; Berg , M. (2003): Report of conference Track 4: sociotechnical issues of HIS. In: International Journal of Medical Informatics, Vol. 69 (2003) Nr. 2-3, pp. 305-306. Ash, J.; Berg, M.; Coeira, E. (2004): Some Unintended Consequences of Information Technology in Health Care. The Nature of Patient Care Information System-related Errors. In: Journal of the American Medical Informatics Association, Vol. 11 (2004), pp. 104112. Ash, J.S.; Bates, D.W. (2005): Factors and Forces Affecting EHR System Adoption. In: J Am Med Inform Assoc, Vol. 12 (2005), pp. 8-12. Augustin, S. (1990): Information als Wettbewerbsfaktor: Informationslogistik – Herausforderung an das Management, Verlag TÜV Rheinland, Köln 1990. Avery, A.J.; Savelyich, B.S.P.; Sheikh, A.; Morris, C.J.; Bowler, I.; Teasdale, S. (2007): Improving general practice computer systems for patient safety: qualitative study of key stakeholders In: Qual Saf Health Care, Vol. 16 (2007) Nr. 1, pp. 28-33. Avison, D.; Young, T. (2007): Time to Rethink Health Care and ICT? In: Communications of the ACM, Vol. 50 (2007) Nr. 6, pp. 69-74. Avison, D.E.; Fitzgerald, G. (1995): Information Systems Development: Methodologies, Techniques and Tools, McGraw-Hill, New York 1995. Ayalp, S. (2006): IT-Sicherheitsbewertung und ISO/IEC TR 13335. In, (2006). Ayeda, M.B.; Ralyte, J.; Rolland, C. (2004): Constructing the Lyee method with a method engineering approach. In: Knowledge-Based Systems, Vol. 17 (2004), pp. 239-248. Babulak, E. (2006): Quality of service provision assessment in the healthcare information and telecommunications infrastructures. In: International Journal of Medical Informatics, Vol. 75 (2006) Nr. 3-4, pp. 246-252. Baer, R.; Zängerle, P. (2000): Wie misst man IT-Sicherheit? In: HMD, Vol. 216 (2000), pp. 67-77.

236

Bibliography

Bagchi, K.; Udo, G.; Kesh, M. (2005): An Emprical Study Identifying the Factors that Impact eHealth Infrastructure and eHealth Use. Paper presented at the Americas Conference on Information Systems (AMCIS), Omaha, Nebraska, USA, pp. 2595-2603. Bake, C.; Blobel, B.; Münch, P. (2004): Datenschutz und Datensicherheit im Gesundheitsund Sozialwesen Datakontext 2004. Baker, L.; Rideout, J.; Gertler, P.; Raube, K. (2005): Effect of an Internet-Based System for Doctor-Patient Communication on Health Care Spending. In: J Am Med Inform Assoc, Vol. 12 (2005) Nr. 5, pp. 530–536. Bakker, A. (2004): Access to EHR and access control at a moment in the past: a discussion of the need and an exploration of the consequences. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 267-270. Bakker, A.R. (2003): Views on HIS development; recommendations of earlier working conferences compared with present challenges. In: International Journal of Medical Informatics, Vol. 69 (2003) Nr. 2-3, pp. 91-97. Baldry, M.; Cheal, C.; Fisher, B.; Gillett, M.; Huet, V. (1986): Giving patients their own records in general practice: experience of patients and staff. In: British Medical Journal, Vol. 292 (1986) Nr. 6520, pp. 596-598. Ball, M.J. (2003): Hospital information systems: perspectives on problems and prospects, 1979 and 2002. In: International Journal of Medical Informatics, Vol. 69 (2003) Nr. 23, pp. 83-89. Ball, M.J.; Lillis, J. (2001): E-health: transforming the physician/patient relationship. In: International Journal of Medical Informatics, Vol. 61 (2001) Nr. 1, pp. 1-10. Balzert (2001): Lehrbuch der Software-Technik. (2. Aufl., 1. Nachdr. Aufl.), Spektrum, Akad. Verl., Heidelberg 2001. Basel Committee on Banking Supervision (2001): Working Paper on the Regulatory Treatment of Operational Risk. Basel Committee on Banking Supervision (2003): Operational risk transfer across financial sectors. Baskerville, R. (1993): Information Systems Security Design Methods: Implications for Information Systems Development. In: ACM Computmg Surveys, Vol. 25 (1993) Nr. 4, pp. 375-414. Baskerville, R.L.; Wood-Harper, A.T. (1996): A critical perspective on action research as a method for information systems research. In: Journal of Information Technology, Vol. 11 (1996), pp. 235–246. Bates, D.W.; Gawande, A.A. (2003): Improving Safety with Information Technology. In: New England Journal of Medicine, Vol. 348 (2003) Nr. 25, pp. 2526-2534.

Bibliography

237

Bates, D.W.; O’Neil, A.C.; Boyle, D.; Teich, J.; Chertow, G.M.; Komaro, A.L.; Brennan, T.A. (1994): Potential identifiability and Preventability of Adverse Events Using Information Systems. In: Journal of the American Medical Informatics Association, Vol. 1 (1994) Nr. 5, pp. 404-411. BDSG (2003): Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14. Januar 2003 (BGBl. I S. 66), zuletzt geändert durch Artikel 1 des Gesetzes vom 22. August 2006 (BGBl. I S. 1970). Beck, K. (2000): Extreme programming eXplained: embrace change, Addison-Wesley, Reading, MA 2000. Beeck, H.; Kaiser, T. (2000): Quantifizierung von Operational Risk mit Value-at-Risk. In: Handbuch Risikomanagement Band 1 Risikomanagement für Markt-, Kredit- und operative Risiken. Hrsg.: Johanning, L.; Rudolph, B. Uhlenbruch, Bad Soden 2000, pp. 633-654. Beham, G. (2004): Corporate Risk and IT-Security Application Method im Vergleich mit anderen IT Security Management Basiswerken, Fachhochschule Hagenberg 2004. Benaroch, M. (2002): Managing Information Technology Investment Risk: A Real Options Perspective. In: Journal of Management Information Systems, Vol. 19 (2002) Nr. 2, pp. 43-84. Bennet, R. (1991): How is Management Research Carried Out? In: The Management Research Handbook. Hrsg.: Smith, N.C.; Dainty, P. Taylor & Francis, Routledge 1991, pp. 318. Beranek Lafky, D.; Tulu, B.; Horan, T.A. (2006): A user-driven approach to personal health records. In: Communications of the Association for Information Systems, Vol. 17 (2006) Nr. 46, pp. 27. Berg, W. (2004): Telemedizin und Datenschutz. In: Medizinrecht, Vol. 22 (2004) Nr. 8, pp. 411-414. Bergmann, J.; Bott, O.J.; Pretschner, D.P.; Haux, R. (2007): An e-consent-based shared EHR system architecture for integrated healthcare networks In: International Journal of Medical Informatics, Vol. 76 (2007) Nr. 2-3, pp. 130-136. Bernstein, K.; Bruun-Rasmussen, M.; Vingtoft, S.; Andersen, S.K.; Nohr, C. (2005): Modelling and implementing electronic health records in Denmark. In: International Journal of Medical Informatics, Vol. 74 (2005) Nr. 2-4, pp. 213-220. Beyer, M.; Kuhn, K.A.; Meiler, C.; Jablonski, S.; Lenz, R. (2004): Towards a Flexible, Process-Oriented IT Architecture for an Integrated Healthcare Network. Paper presented at the ACM Symposium on Applied Computing, Nicosia, Cyprus, pp. 264–271. Beynon-Davies, P.; Lloyd-Williams, M. (1999): When health information systems fail. In: Topics in Health Information Management, Vol. 20 (1999) Nr. 1, pp. 66-79.

238

Bibliography

Bhasale, A. (1998): The Wrong Diagnosis: Identifying Causes of Potentially Adverse Events in General Practice Using Incident Monitoring. In: Family Practice, Vol. 15 (1998) Nr. 4, pp. 308–318. Bird, A.P.; Walji, M.T. (1989): Our patients have access to their records. In: British Medical Journal, Vol. 292 (1989) Nr. 6520, pp. 595-596. BITKOM (2006): Kompass der IT-Sicherheitsstandards - Leitfaden und Nachschlagewerk. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V., 2006. Blobel, B. (2004): Authorisation and access control for electronic health record systems. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 251-257. Blobel, B. (2006): Advanced and secure architectural EHR approaches. In: International Journal of Medical Informatics, Vol. 75 (2006) Nr. 3-4, pp. 185-190. Blobel, B.; Pharow, P. (2005): Datensicherheit in medizinischen Informationssystemen und Gesundheitsnetzen,. In: Handbuch der medizinischen Informatik, . Hrsg. Hanser Fachbuchverlag, 2005. Blobel, B.; Pharow, P. (2007): A model driven approach for the German health telematics architectural framework and security infrastructure. In: International Journal of Medical Informatics, Vol. 76 (2007) Nr. 2-3, pp. 169-175. Blobel, B.; Roger-France, F. (2001): A systematic approach for analysis and design of secure health information systems. In: International Journal of Medical Informatics, Vol. 62 (2001), pp. 51-78. Bodin, L.D.; Gordon, L.A.; Loeb, M.P. (2005): Evaluating Information Security Investments Using the Analytic Hierarchy Process. In: Communications of the ACM, Vol. 48 (2005) Nr. 2, pp. 79-83. Bornman, W.G.; Labuschagne, L. (2004): A Comparative Framework for Evaluating Information Security Risk Management Methods. Paper presented at the Information Security South Africa Conference. Bortz, J.; Döring, N. (2002): Forschungsmethoden und Evaluation: Für Human- und Sozialwissenschaftler, Springer, Berlin u.a. 2002. Bott, O.J.; Bergmann, J.; Hoffmann, I.; Vering, T.; Gomez, E.J.; Hernando, M.E. (2005): Analysis and Specification of Telemedical Systems Using Modelling and Simulation: the MOSAIK-M Approach. In: Stud Health Technol Inform, Vol. 116 (2005), pp. 503-508. Boudreau, M.-C.; Gefen, D.; Straub, D.W. (2001): Validation in Information Systems Research: A State-of-the-Art Assessment. In: MIS Quarterly, Vol. 25 (2001) Nr. 1, pp. 116.

Bibliography

239

Braun, C.; Wortmann, F.; Hafner, M.; Winter, R. (2005): Method Construction – A Core Approach to Organizational Engineering. ACM Symposium on Applied Computin. Santa Fe, New Mexico, USA. . Brinkkemper, S. (1996): Method engineering: engineering of information systems development methods and tools. In: Information and Software Technology, Vol. 38 (1996), pp. 275-280. Brinkkemper, S.; Lyytinen, K.; Weike, R.J. (1996): Method Engineering, Chapman & Hall, New York 1996. Brinkkemper, S.; Saeki, M.; Harmsen, F. (1998): Assembly Techniques for Method Engineering. In: Lecture Notes In Computer Science, Vol. 1413 (1998), pp. 381-400. Brinkkemper, S.; Saeki, M.; Harmsen, F. (1999): Meta-Modelling Based Assembly Techniques For Situational Method Engineering. In: lnformation Systems Vol. 24 (1999) Nr. 3, pp. 209-228. British Standards Institution (1999): BS 77992 1999 Management von Informationssicherheit : Teil 2: Spezifikation für Informationssicherheits-Managementsysteme. Brooks, W.; Warren, M. (2004): Health information security evaluation: continued development of an object-oriented method. Paper presented at the 2nd Australian Information Security Management Conference, Perth, Western Australia, pp. 135-150. Brooks, W.; Warren, M. (2006): A Methodology of Health Information Security Evaluation Health Care & Informatics Review Online. Broy, M.; Rausch, A. (2005): Das neue V-Modell® XT: Ein anpassbares Modell für Software und System Engineering. In: Informatik-Spektrum, Vol. 28 (2005) Nr. 3, pp. 220-229. BSI (2004): Studie zu ISO-Normungsaktivitten ISO/BPM - Anforderungen an Information Security Management Systeme. In Bundesamt für Sicherheit in der Informationstechnik (Ed.). BSI (2005): Standard 100-3 Risk Analysis based on IT-Grundschutz. Version 2.0. In Bundesamt für Sicherheit in der Informationstechnik (Ed.). Bonn. BSI (2008): IT-Grundschutz. http://www.bsi.de/gshb/index.htm, accessed 06.02.2008. Buela-Casal, G.; Perakakis, P.; Taylor, M. (2006): Measuring internationality: Reflections and perspectives on academic journals. University of Granada (Spain) and University of Madrid (Spain), 2006. Bundesamt für Sicherheit in der Informationstechnik (1992): IT-Sicherheitshandbuch: Handbuch für die sichere Anwendung der Informationstechnik. (Version 1.0 - März 1992 Aufl.), Bsi, Bonn 1992. Bundesamt für Sicherheit in der Informationstechnik (2004): Risikoanalyse auf der Basis von IT-Grundschutz. Bundesamt für Sicherheit in der Informationstechnik, 2004.

240

Bibliography

Bundesamt für Sicherheit in der Informationstechnik (2005): BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS). Bundesministerium für Gesundheit und Soziale Sicherung (2004): Standards und Initiativen im Gesundheitswesen - eine evaluierende Übersicht und Empfehlung. In, (2004). Bundesministerium für Wirtschaft und Arbeit (Hrsg.) (2003): Informationsgesellschaft Deutschland 2006 Aktionsprogramm der Bundesregierung. http://www.dimdi.de/dynamic/de/ehealth/karte/downloadcenter/veroeffentlichungen/weiteres_infomaterial/akt ionsprogramm-informationsgesellschaft-2006.pdf, accessed 20.09.2006. Butler, S.A. (2002): Security Attribute Evaluation Method: A Cost-Benefit Approach. Paper presented at the ICSE ’02: Proceedings of the 24th International Conference on Software Engineering, pp. 232-240. Carayon, P. (2006): Human factors of complex sociotechnical systems. In: Applied Ergonomics, Vol. 37 (2006) Nr. 4, pp. 525-535. Carr-Hill, R.A.; Jamison, J.Q.; O'Reilly, D.; Stevenson, M.R.; Reid, J.; Merriman, B. (2002): Risk adjustment for hospital use using social security data: cross sectional small area analysis. In: BMJ, Vol. 234 (2002), pp. 1-4. Carroll, J.M.; Kellogg, W.A. (1989): Artifact as theory nexus: Hermeneutics meets theory based design. In: ACM SIGCHI Bulletin, Vol. 20 (1989) Nr. SI, pp. 7-14. Caumanns, J.; Weber, H.; Fellien, A.; Kurrek, H.; Boehm, O.; Neuhaus, J.; Kunsmann, J.; Struif, B. (2006): Die eGK-Lösungsarchitektur - Architektur zurUnterstützung der Anwendungen der elektronischen Gesundheitskarte. In: Informatik Spektrum, Vol. 29 (2006), pp. 341-348. Cavalli, E.; Mattasoglio, A.; Pinciroli, F.; Spaggiari, P. (2004): Information security concepts and practices: the case of a provincial multi-specialty hospital. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 297-303. Cavusoglu, H.; Mishra, B.; Raghunathan, S. (2004): A Model for Evaluating IT Security Investments. In: Communications of the ACM, Vol. 47 (2004) Nr. 7. CEN/TC 251 European Standardization of Health Informatics (1997): Healthcare Information System Architecture Part 1 (HISA) Healthcare Middleware Layer, 1997. CEN/TC 251 European Standardization of Health Informatics (2008): CEN/TC 251Webseite. http://www.centc251.org/, accessed 15.12.2008. Chadwick, D.W.; Crook, C.; Young, A.J.; McDowell, D.M.; Dornan, T.L.; New, J.P. (2000): Using the internet to access confidential patient records: a case study. In: BMJ, Vol. 321 (2000). Chen, P.P.-S. (1976): The Entity-Relationship Model - Toward a Unified View of Data. In: ACM Transactions on Database Systems, Vol. 1 (1976) Nr. 1, pp. 9-36.

Bibliography

241

Choi, Y.B.; Capitan, K.E.; Krause, J.S.; Streeper, M.M. (2006): Challenges Associated with Privacy in Health Care Industry: Implementation of HIPAA and the Security Rules. In: J Med Sys, Vol. 30 (2006) Nr. 1, pp. 57-64. Churches, T. (2003): A proposed architecture and method of operation for improving the protection of privacy and confidentiality in disease registers. In: BMC Medical Research Methodology, Vol. 3 (2003) Nr. 1. Cimino, J.J.; Patel, V.L.; Kushniruk, A.W. (2001): What Do Patients Do with Access to Their Medical Records? Paper presented at the Medinfo 2001, London, pp. 14401444. Coleman, J. (2004): Assessing information security risk in healthcare organizations of different scale In: International Congress Series, Vol. 1268 (2004), pp. 125-130. Commission of the European Communities (2002): eEurope 2005: An information society for all - An Action Plan to be presented in view of the Sevilla European Council, 21/22 June 2002. Brussels. Committee of Sponsoring Organizations of the Treadway Commission (2005): FAQs for COSO's Enterprise Risk Management — Integrated Framework. CRAMM (2003): CCTA Risk Analysis and Management Method, 2003. Cremonini, M.; Martini, P. (2005): Evaluating Information Security Investments from Attackers Perspective: the Return-On-Attack (ROA). 4. Workshop on the Economics of Information Security (WEIS'05). Boston, USA. Cronholm, S.; Ågerfalk, P.J. (1999): On the Concept of Method in Information Systems Development. Linköping Electronic Articles in Computer and Information Science (Vol. 4). Cruz, M.G. (2002): Modeling, Measuring and Hedging Operational Risk, John Wiley & Sons, Chichester 2002. Culyer, A.J. (1989): The Normative Economics of Health Care Finance and Provision. In: Oxford Review of Economic Policy, Vol. 5 (1989) Nr. 1, pp. 34-58. Daneva, M. (2006): Applying Real Options Thinking to Information Security in Networked Organizations. Centre for Telematics and Information Technology, University of Twente., 2006. Danish Center for Health Telematics (2003): PICNIC (Professionals and Citizens Network for Integrated Care)-Webseite. http://www.medcom.dk/picnic, accessed 15.12.2005. Davey, J. (1994): SEISMED: Secure Environment for Information Systems in Medicine In: Computer Methods and Programs in Biomedicine, Vol. 45 (1994), pp. 153-154. Davis, R. (2004): Business process modelling with ARIS: a practical guide, Springer 2004. de Ru, W.G.; Eloff, J.H.P. (1996): Risk analysis modelling with the use of fuzzy logic. In: Computers & Security, Vol. 15 (1996) Nr. 3, pp. 329-248.

242

Bibliography

Denley, I.; Smith, S.W. (1999): Privacy in clinical information systems in secondary care. In: BMJ, Vol. 318 (1999), pp. 1328-1331. Department of Health and Human Services (2005): HIPAA Security Series - Basics of Risk Analysis and Risk Management. http://www.cms.hhs.gov/EducationMaterials/Downloads/BasicsofRiskAnalysisandRiskManagement.pdf, accessed 26.03.2007. Dhillon, G.; Backhouse, J. (2001): Current directions in IS security research: towards socioorganizational perspectives. In: Info Systems J, Vol. 11 (2001), pp. 127–153. Dhillon, G.; Torkzadeh, G. (2006): Value-focused assessment of information system security in organizations. In: Info Systems J, Vol. 16 (2006), pp. 293-314. Dias de Figueiredo, A.; Rupino da Cunha, P. (2007): Action Research and Design in Information Systems: Two Faces of a Single Coin. In: Information Systems Action Research. Hrsg.: Kock, N. Springer, New York 2007, pp. 61–96. Dierks, C. (2005): Rechtliche Aspekte der elektronischen Gesundheitskarte. In: Telemedizinführer Deutschland „Elektronische Gesundheitskarte“. Hrsg.: Hempel, V.; Jäckel, A.; Reum, L. o.O., 2005, pp. 26-27. DIMDI (2008): Deutsches Institut für medizinische Dokumentation und Information. http://www.dimdi.de, accessed 24.04.2008. DIN (2008): Deutsches Institut für Normung. http://www.din.de, accessed 19.10.2008. Dinkelbach, W.; Kleine, A. (1996): Elemente einer betriebswirtschaftlichen Entscheidungslehre, Springer, Berlin u.a. 1996. Doherty, N.F.; Fulford, H. (2006): Aligning the information security policy with the strategic information systems plan. In: Computers & Security, Vol. 25 (2006), pp. 55 – 63. Dolin, R.H.; Alschuler, L.; Boyer, S.; Beebe, C.; Behlen, F.M.; Biron, P.V.; Shabo, A. (2006): HL7 Clinical Document Architecture, Release 2. In: Journal of the American Medical Informatics Association, Vol. 13 (2006), pp. 30–39. Drees, D. (2007): The Introduction of Health Telematics in Germany. Information Security Solutions Europe/SECURE 2007 Conference. Poland, Warsaw: Vieweg. Dünnebeil, S.; Mauro, C.; Sunyaev, A.; Leimeister, J.M.; Krcmar, H. (2009a): Integration of Patient Health Portals into the German Healthcare Telematics Infrastructure. Paper presented at the AMCIS 2009 - Proceedings of the 15th Americas Conference on Information Systems., San Francisco, California, pp. Paper 754. Dünnebeil, S.; Sunyaev, A.; Mauro, C.; Leimeister, J.M.; Krcmar, H. (2009b): Konzeption patientenzentrierter Mehrwertdienste für die Deutsche Gesundheitstelematik. Paper presented at the Proceedings of 54. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (GMDS), Essen, pp. To appear.

Bibliography

243

Dustdar, S.G., H. (2003): Software-Architekturen für Verteilte Systeme, Springer, Heidelberg 2003. Eckert, C. (2006): IT-Sicherheit. Konzepte - Verfahren - Protokolle, Oldenbourg 2006. EDIFACT (2008): United Nations Economic Comission for Europe. http://www.unece.org/, accessed 13.11.2008. Eloff, J.H.P.; Labuschagne, L.; Badenhorst, K.P. (2002): A comparative framework for risk analysis methods. In: Computers & Security, Vol. 12 (2002) Nr. 6, pp. 597-603. Eloff, M.M.; von Solms, S.H. (2000): Information Security Management: A Hierarchical Framework for Various Approaches. In: Computers & Security, Vol. 19 (2000), pp. 243-256. ENISA (2006): Inventory of risk assessment and risk management methods (Vol. Version 1.0 ), ENISA ad hoc working group on risk assessment and risk management, 2006. Eschweiler, J.; Psille, D.E.A. (2006): Security@Work, Springer, Berlin, Heidelberg 2006. Essex, B.; Doig, R.; Renshaw, J. (1990): Pilot study of records of shared care for people with mental illnesses. In: British Medical Journal, Vol. 300 (1990) Nr. 6737, pp. 14421446. Estermann, C. (2004): Management der Informatiksicherheit: Ansätze in Theorie und Praxis, Universität Zürich 2004. Eysenbach, G. (2001): What is e-health? In: Journal of Medical Internet Research, Vol. 3 (2001) Nr. 2, pp. e20. facharzt.de (2005): Datenschutzbeauftragter Schaar zur eCard: Es gibt keine 100prozentige Sicherheit. Interview von facharzt.de mit dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) Peter Schaar, accessed 21.09.2005. Faisst, U.; Kovacs, M. (2003): Quantifizierung operationeller Risiken - ein Methodenvergleich. In: Die Bank, Vol. 43 (2003) Nr. 5, pp. 342-349. Faisst, U.; Prokein, O.; Wegmann, N. (2007): Ein Modell zur dynamischen Investitionsrechnung von IT-Sicherheitsmaßnahmen. In: ZfB, Vol. 77 (2007), pp. 511–538. Federal Ministry of Health (2008): The electronic health card. Finne, T. (1998): A Conceptual Framework for Information Security Management. In: Computers & Security, , Vol. 17 (1998), pp. 303-307. Firesmith, D.G. (2003): Engineering Security Requirements In: Journal of Object Technology, Vol. 2 (2003) Nr. 1, pp. 53-68. Fitzgerald, B. (1996): Formalized systems development methodologies: a critical perspective. In: Information Systems Journal, Vol. 6 (1996) Nr. 1, pp. 3-23. Fitzgerald, B. (1997): The use of systems development methodologies in practice: a field study. In: Info Systems J, Vol. 7 (1997), pp. 201. Food and Drug Administration (2006): Guidance for Industry. Q9 Quality Risk Management. In U.S. Department of Health and Human Services (Ed.).

244

Bibliography

Forster, A.J.; Clark, H.D.; Menard, A.; Dupuis, N.; Chernish, R.; Chandok, N.; Khan, A.; van Walraven, C. (2004): Adverse events among medical patients after discharge from hospital. In: Canadian Medical Association Journal, Vol. 170 (2004) Nr. 3, pp. 345–349. Förster, K. (2005): Die elektronische Gesundheitskarte aus Sicht der Apotheker. In: Telemedizinführer Deutschland „Elektronische Gesundheitskarte“. Hrsg.: Hempel, V.; Jäckel, A.; Reum, L. o.O., 2005, pp. 38-39. Fowles, J.B.; Kind, A.C.; Craft, C.; Kind, E.A.; Mandel, J.L.; Adlis, S. (2004): Patients' Interest in Reading Their Medical Record: Relation With Clinical and Sociodemographic Characteristics and Patients' Approach to Health Care. In: Archives of Internal Medicine, Vol. 164 (2004) Nr. 7, pp. 793-800. France, F.H.R. (2004): Security of health care records in Belgium: Application in a University Hospital. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 235-238. Frank, U. (2000): Evaluation von Artefakten in der Wirtschaftsinformatik. In: Evaluation und Evaluationsforschung in der Wirtschaftsinformatik. Hrsg.: Heinrich, L.J.; Häntschel, I. Oldenbourg, München 2000, pp. 35-48. Fraunhofer-Institut für Offene Kommunikationssysteme (2008): eHealth-Infrastrukturen Sichere Serviceorientierte Architekturen im Gesundheitswesen. Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS, 2008. Fredriksen, R.; Kristiansen, M.; Gran, B.A.; Stolen, K.; Opperud, T.A.; Dimitrakos, T. (2002): The CORAS Framework for a model-based risk management process. In: Lecture Notes In Computer Science, Vol. 2434 (2002), pp. 94 - 105 Frist, W.H. (2005): Health Care in the 21st Century. In: The New England Journal of Medicine, Vol. 352 (2005), pp. 267-272. Furnell, S.; Gritzalis, D.; Katsikas, S.; Mavroudakis, K.; Sanders, P.; Warren, M. (1998): Methods of responding to healthcare security incidents. In: Medinfo, Vol. 9 (1998) Nr. 2, pp. 1138-1142. Furnell, S.; Pangalos, G.; Sanders, P.; Warren, M. (1994): A generic methodology for health care security. In: Medical Informatics journal, Vol. 19 (1994) Nr. 3, pp. 229245. Gappmair, M.; Häntschel, I. (1997): Die Evaluierung von Workflow-Management-Systemen in Laborstudien. In: Wirtschaftsinformatik – Ergebnisse empirischer Forschung. Hrsg.: Grün, O.; Heinrich, L.J. Springer, Wien, New York 1997, pp. 63-77. Gaunt, N. (2000): Practical approaches to creating a security culture. In: International Journal of Medical Informatics, Vol. 60 (2000), pp. 151-157. gematik (2005a): Gematik Fachmodell. Version 0.9. Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH, 2005a.

Bibliography

245

gematik (2005b): Gesamtarchitektur Kryptografische Ziele der Telematik. gematik; AG Gesamtarchitektur. gematik (2005c): Gesamtarchitektur Kryptografische Ziele der Telematik. Version 1.0. gematik; AG Gesamtarchitektur. gematik (2006a): Einführung der Gesundheitskarte - Änderungen der eGK-Spezifikation Teil 2 in der Version V1.1.19 gegenüber der Version 1.1.1. Gematik, 2006a. gematik (2006b): Einführung der Gesundheitskarte - Die Spezifikation der elektronischen Gesundheitskarte - Teil 1: Kommandos, Algorithmen und Funktionen der Betriebssystem-Plattform, 2006b. gematik (2006c): Einführung der Gesundheitskarte - Die Spezifikation der elektronischen Gesundheitskarte - Teil 2: Anwendungen und anwendungsspezifische Strukturen, 2006c. gematik (2006d): Einführung der Gesundheitskarte - Die Spezifikation der elektronischen Gesundheitskarte - Teil 3: Äußere Gestaltung, 2006d. gematik (2006e): Einführung der Gesundheitskarte - Facharchitektur Versichertenstammdaten-Management (VSDM). Gematik, 2006e. gematik (2006f): Einführung der Gesundheitskarte - Festlegungen zu den technischen X.509 Zertifikaten der Versicherten. Gematik, 2006f. gematik (2006g): Einführung der Gesundheitskarte - Gesamtarchitektur. Gematik, 2006g. gematik (2006h): Einführung der Gesundheitskarte - Gesamtarchitektur. Gematik, 2006h. gematik (2006i): Einführung der Gesundheitskarte - Gesamtarchitektur. Version 0.2.0. Gematik, 2006i. gematik (2006j): Einführung der Gesundheitskarte - Konnektorspezifikation - Teil 1 Allgemeine Funktionen und Schnittstellen des Konnektors, 2006j. gematik (2006k): Einführung der Gesundheitskarte - Netzwerkspezifikationen. Gematik, 2006k. gematik (2006l): Einführung der Gesundheitskarte - Speicherplatzbedarf der eGK. Gematik, 2006l. gematik (2006m): Einführung der Gesundheitskarte - Spezifikation eHealth-Kartenterminal. Gematik, 2006m. gematik (2006n): Einführung der Gesundheitskarte - Spezifikation Infrastrukturkomponenten: Zeitdienst, 2006n. gematik (2006o): Einführung der Gesundheitskarte - Spezifikation Infrastrukturkomponenten: Zeitdienst. Version 1.0.0, 2006o. gematik (2006p): Einführung der Gesundheitskarte - Übergabeschnittstelle für die Produktion der eGK. Gematik, 2006p. gematik (2006q): Endbericht zur Kosten-Nutzen-Analyse der Einrichtung einer TelematikInfrastruktur im deutschen Gesundheitswesen. Gematik, 2006q.

246

Bibliography

gematik (2006r): Spezifikation Infrastrukturkomponenten: Namensdienst – Lokalisierungsdienst Stufe 1. Gematik, 2006r. gematik (2006s): Spezifikation Infrastrukturkomponenten: Zeitdienst. Gematik, 2006s. gematik (2006t): Zusammenfassung der fachlichen Inhalte der eGK und der zugehörigen Strukturen. Gematik, 2006t. gematik (2007a): Einführung der Gesundheitskarte - Gesamtarchitektur. (S. 303): Gematik. gematik (2007b): Einführung der Gesundheitskarte - Konnektorspezifikation, 2007b. gematik (2007c): Einführung der Gesundheitskarte - Speicherstrukturen der eGK für Gesundheitsanwendungen Gematik. gematik (2007d): Einführung der Gesundheitskarte - Spezifikation eHealth-Kartenterminal. Gematik, 2007d. gematik (2007e): Einführung der Gesundheitskarte - Spezifikation Ticketservice. Gematik. gematik (2007f): Einführung der Gesundheitskarte - Übergreifendes Sicherheitskonzept der Telematikinfrastruktur, 2007f. gematik (2007g): Übergreifendes Sicherheitskonzept der Telematikinfrastruktur. gematik (2007h): Übergreifendes Sicherheitskonzept der Telematikinfrastruktur. Version 1.9.0. gematik (2007i): Ziele. http://www.gematik.de/(S(npptm5if2hujwrbxkr250v31))/Ziele.Gematik, accessed 20.01.2007. gematik (2008a): Facharchitektur Daten für die Notfallversorgung (NFDM). Version 1.7.0. In, (2008a). gematik (2008b): Facharchitektur Verordnungsdatenmanagement (VODM). Version 1.5.1. In, (2008b). gematik (2008c): Facharchitektur Versichertenstammdatenmanagement (VSDM). Version 2.6.0. In, (2008c). gematik (2008d): Gesamtarchitektur. Version 1.5.0. In, (2008d). gematik (2008e): Konnektorspezifikation. Version 2.8.0. In, (2008e). gematik (2008f): Spezifikation eHealth-Kartenterminal. Version 2.6.2. In, (2008f). gematik (2008g): Spezifisches Sicherheitskonzept der dezentralen Komponenten – Einboxkonnektor-Szenario. Version 0.9.0 Kandidat. In, (2008g). gematik (2008h): Übergreifendes Sicherheitskonzept der Gesundheitstelematik. Version 2.3.0. In, (2008h). gematik (2008i): Wie werden Gesundheitsdaten in Zukunft geschützt? Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH, 2008i. Gerberick, D.; Huber, D.; Rudloff, R. (1999): Defining a technical architecture for health care security. In: Information Systems Security, Vol. 8 (1999) Nr. 2, pp. 37-40.

Bibliography

247

Gerdsen, F.; Müller, S.; Bader, E.; Poljak, M.; Jablonski, S.; Prokosch, H.-U. (2005): Einsatz von CDA/SCIPHOX zur standardisierten Kommunikation medizinischer Befunddaten zwischen einem Schlaganfall-/Glaukom-Screening-Programm und einer elektronischen Gesundheitsakte (EGA). Paper presented at the Proceedings of Telemed 2005, Berlin, pp. 124-137. Gericke, A.; Rohner, P.; Winter, R. (2006): Vernetzungsfähigkeit im Gesundheitswesen – Notwendigkeit, Bewertung und systematische Entwicklung als Voraussetzung zur Erhöhung der Wirtschaftlichkeit administrativer Prozesse. In: HMD, Vol. 251 (2006), pp. 20-30. Gerloni, H.; Oberhaitzinger, B.; Reier, H.; Plate, J. (2004): Praxisbuch Sicherheit für Linux-Server und -Netze, Carl Hanser Ver-lag, München Wien 2004. Gillon, R. (1991): Should patients be allowed to look after their own medical records? In: Journal of Medical Ethics, Vol. 17 (1991) Nr. 3, pp. 115-116. Glaser, B.; Strauss, A. (1967): The Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine Transaction, Chicago 1967. Gollmann, D. (1999): Computer Security, John Wiley & Sons 1999. Goodman, L.A. (1961): Snowball Sampling. In: Annals of Mathematical Statistics, Vol. 32 (1961) Nr. 1, pp. 148-170. Gordon, L.A.; Loeb, M.P. (2002): The Economics of Information Security Investment. In: ACM Transactions on Information and System Security,, Vol. 5 (2002) Nr. 4, pp. 438–457. Gordon, L.A.; Loeb, M.P. (2006): Budgeting Process for Information Security Expenditures. In: Communications of the ACM, Vol. 49 (2006) Nr. 1, pp. 121-!"%. Gordon, L.A.; Loeb, M.P.; Lucyshyn, W. (2003): Information security expenditures and real options: A wait-and-see approach. In: Computer Security Journal, Vol. 19 (2003), pp. 1-7. Graf v.d. Schulenburg, J.-M.; Uber, A.; König, W.; Andersen, H.H.; Henke, K.-D.; Laaser, U.; Allhoff, P.G. (1995): Ökonomische Evaluation telemedizinischer Projekte und Anwendungen (Vol. 22), Nomos Verlagsgesellschaft, Baden-Baden 1995. Grant, D.; Ngwenyama, O. (2003): A report on the use of action research to evaluate a manufacturing information systems development methodology in a company. In: Info Systems J Vol. 13 (2003) Nr. 21-35. Gray, J.; Rossi, M.; Tolvanen, J.-P. (2004): Domain specific modeling with visual languages. In: Journal of Visual Languages & Computing, Vol. 15 (2004), pp. 207–330. Gregg, D.G.; Kulkarni, U.R.; Vinze, A.S. (2001): Understanding the Philosophical Underpinnings of Software Engineering Research in Information Systems. In: Information Systems Frontiers, Vol. 3 (2001) Nr. 2, pp. 169-183.

248

Bibliography

Gregor, S. (2006): The Nature of Theory in Information Systems. In: MIS Quarterly, Vol. 30 (2006) Nr. 3, pp. 611-642. Gregor, S.; Jones, D. (2007): The Anatomy of a Design Theory In: Journal of the Association for Information Systems, Vol. 8 (2007) Nr. 5, pp. 312-335. Grimes, S.L. (2004): Security: a new clinical engineering paradigm. In: Engineering in Medicine and Biology Magazine, IEEE, Vol. 23 (2004) Nr. 4, pp. 80-82. Grimshaw, J.M.; Russel, J.L. (1998): Effect of Clinical Guidelines on Medical Practice: A Systematic Review of Rigorous Evaluation. In: The Lancet, Vol. 342 (1998) Nr. 8883, pp. 1317-1322. Grimson, J.; Grimson, W. (2002): Health care in the information society: evolution or revolution? In: International Journal of Medical Informatics, Vol. 66 (2002), pp. 25-29. Gritzalis, D. (1997): A baseline security policy for distributed healthcare information systems In: Computers & Security, Vol. 16 (1997) Nr. 8, pp. 709-719. Gritzalis, D.; Lambrinoudakis, C. (2004): A security architecture for interconnecting health information systems. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 305-309. Gritzalis, S.; Lambrinoudakis, C.; Lekkas, D.; Deftereos, S. (2005): Technical guidelines for enhancing privacy and data protection in modern electronic medical environments. In: Information Technology in Biomedicine, IEEE Transactions on, Vol. 9 (2005) Nr. 3, pp. 413-423. Grundy, J.C.; Venable, J.R. (1996): Towards an Integrated Environment for Method Engineering. Paper presented at the Proceedings of the IFIP TC8, WG8.1/8.2 working conference on method engineering on Method engineering : principles of method construction and tool support: principles of method construction and tool support, Atlanta, Georgia, United States, pp. 45-62. Gustafson, D.H.; Wyatt, J.C. (2004): Evaluation of ehealth systems and services. In: BMJ, Vol. 328 (2004), pp. 1150. Haas (2006a): Gesundheitstelematik, Springer Verlag, Berlin, Heidelberg 2006a. Haas, P. (2005): Medizinische Informationssysteme und Elektronische Krankenakten, Springer, Berlin, Heidelberg, New York 2005. Haas, P. (2006b): Standards für die Gesundheitstelematik. In: Gesundheitstelematik. Hrsg. Verlag Springer, Berlin Heidelberg 2006b, pp. 293-378. Häber, A.; Dujat, C. (2004): Referenzmodell für das Dokumentenmanagement und die digitale Archivierung von Patientenunterlagen. In Tübinger Archivtage 2004 - 19. Treffen der GMDS-Arbeitsgruppe "Archivierung von Krankenunterlagen" (Ed.).

Bibliography

249

Haibach, S. (2005): Ökonomische Potentiale von elektronischer Gesundheitskarte und elektronischem Heilberufsausweis – Die Sicht der Krankenkassen. In: Smart Cards in telemedizinischen Netzwerken. Hrsg.: Niederlag, W.; Rienhoff, O.; Lemke, H.U. Health Academy, Dresden 2005, pp. 187-193. Häkkinen, H.; Turunen, P.; Spil, T.A.M. (2003): Information in Health Care Process – Evaluation Toolkit Development. Paper presented at the Proceedings of the 36th Hawaii International Conference on System Sciences, Hawaii. Hamdi, M.; Boudriga, N. (2005): Computer and network security risk management: theory, challenges, and countermeasures. In: International Journal of Communication Systems, Vol. 18 (2005) Nr. 8, pp. 763-793. Hamilton, C.R. (1999): Risk management and security. In: Information Systems Security, Vol. 8 (1999) Nr. 2, pp. 69-79. Harmsen, F.; Brinkkemper, S.; Oei, H. (1994): Situational Method Engineering for Information System Project Approaches, Elsevier Science, Amsterdam 1994. Hashim, A.; Harun, M.; Mohan, J.; Suleiman, A. (2001): Integrated Telehealth as a Platform for Research and Development (R&D) and Continuing Professional Development (CPD) in the Malaysian Healthcare Setting Medical Online Sdn Bhd, 2001. Hasselbring, W. (1997): Federated Integration of Replicated Information Within Hospitals. In: International Journal on Digital Libraries, Vol. 1 (1997) Nr. 3, pp. 192-208. Haux, R. (2006): Individualization, globalization and health – about sustainable information technologies and the aim of medical informatics. In: International Journal of Medical Informatics, Vol. 76 (2006) Nr. 12, pp. 795-808. Haux, R.; Ammenwerth, E.; Buchauer, A. (2001): Anforderungskatalog für die Informationsverarbeitung im Krankenhaus, Version 1.0b. http://iig.umit.at/dokumente/anforderungskatalog.pdf, accessed 22.11.2005. Health Data Management Journal (2008): Group Pitches E-health Definition. http://www.healthdatamanagement.com/html/news/NewsStory.cfm?articleId=8484, accessed 22.12.2008. Health Information Strategy Steering Committee (2005): Health Information Strategy for New Zealand. http://www.moh.govt.nz/moh.nsf/c43c7844c94e08cd4c2566d300838b43/1912064eefec8ebccc2570430003dad1?OpenDocument, accessed 06.08.2005. Health Level Seven Inc. Ann Arbor MI (2008): Health Level Seven Internetseite. http://www.hl7.org/, accessed 15.03.2008. Healthcare Information and Management Systems Society (HIMSS) (2008): Electronic Health Records: A Global Perspective, 2008. Hechenblaikner, A. (2006): Operational Risk in Banken - Eine methodenkritische Analyse der Messung von IT-Risiken, Deutscher Universitätsverlag, Wiesbaden, München 2006.

250

Bibliography

Heeks, R. (2006): Health information systems: Failure, success and improvisation. In: International Journal of Medical Informatics, Vol. 75 (2006) Nr. 2, pp. 125-137. Hevner, A.R.; March, S.T.; Park, J.; Ram, S. (2004): Design Science in Information Systems Research. In: MIS Quarterly, Vol. 28 (2004) Nr. 1, pp. 75-106. Hildebrand, C.; Pharow, P.; Engelbrecht, R.; Blobel, B.; Savastano, M.; Hovstø, A. (2006): BioHealth - The Need for Security and Identity Management Standards in eHealth. In: Stud Health Technol Inform., Vol. 121 (2006), pp. 327-336. Hofstede, A.H.M.t.; Verhoef, T.F. (1997): On The Feasibility Of Situational Method Engineering. In: Information Systems, Vol. 22 (1997) Nr. 6/7, pp. 401-422. Holliday, I.; Tam, W.-k. (2004): E-health in the East Asian tigers. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 11-12, pp. 759-769. Holthaus, M. (2000): Management der Informationssicherheit in Unternehmen, Universität Zürich 2000. Höne, K.; Eloff, J.H.P. (2002): Information security policy – what do international information security standards say? In: Computers & Security, Vol. 21 (2002) Nr. 5, pp. 402409. Hoo, K.J.S. (2000): How Much Is Enough? A Risk-Management Approach to Computer Security. In, (2000). Hornung, G.; Goetz, C.F.-J.; Goldschmidt, A.J.W. (2005): Die künftige Telematik-Rahmenarchitektur im Gesundheitswesen: Recht, Technologie, Infrastruktur und Ökonomie. In: Wirtschaftsinformatik, Vol. 46 (2005) Nr. 3, pp. 171-179. Hoyt, D. (1973): Computer Security Handbook, Macmillan, New York 1973. Huber, M.; Sunyaev, A.; Krcmar, H. (2008a): Security Analysis of the Health Care Telematics Infrastructure in Germany. 10th International Conference on Enterprise Information Systems. Barcelona, Spain: Vol. ISAS-2, pp. 144-153. Huber, M.; Sunyaev, A.; Krcmar, H. (2008b): Technische Sicherheitsanalyse der elektronischen Gesundheitskarte. Arbeitspapier Nr. 32., Arbeitspapier Technische Universität München, Lehrstuhl für Wirtschaftsinformatik. Huff, S.M.; Rocha, R.A.; McDonald, C.J.; De Moor, G.J.E.; Fiers, T.; Bidgood, W.D.; Forrey, A.W.; Francis, W.G.; Tracy, W.R.; Leavelle, D.; Stalling, F.; Griffin, B.; Maloney, F.; Leland, D.; Charles, L.; Hutchins, K.; Baenziger, J. (1998): Development of the Logical Observation Identifier Names and Codes (LOINC) Vocabulary. In: Journal of the American Medical Informatics Association, Vol. 5 (1998) Nr. 3, pp. 276-292. IBM (1972): Secure automated facilities environment study 3, Part 2, IBM, Armnok 1972. IBM; Dr. Bunz, H.; Dr. Neeb, J. (2004): Erarbeitung einer Strategie zur Einführung der Gesundheitskarte - Operationales Modell der Telematikinfrastruktur unter Berücksichtigung der Sicherheitsaspekte. (S. 44).

Bibliography

251

IBM; Dr. Biltzinger, P.; Dr. Bunz, H.; Dr. Neeb, J. (2004): Erarbeitung einer Strategie zur Einführung der Gesundheitskarte - Sicherheitsanforderungen. (S. 62). IHE-Europe (2008): Integrating the Healthcare Enterprise Europe. http://www.iheeurope.org, accessed 10.05.2006. IHE (2008): Integration the Healthcare Enterprise. http://www.ihe.net, accessed 19.10.2008. Iivari, J.; Hirschheim, R. (1996): Analyzing Information Systems Development: a Comparison and Analysis of Eight IS Development Approaches. In: Information Systems, Vol. 21 (1996) Nr. 7, pp. 551-575. Information Security Forum (ISF) (2005): The Standard of Good Practice for Information Security. London. Information Systems Security Association (2003): GAISP - Generally Accepted Information Security Principles. Initiative D21 (2001): IT-Sicherheitskriterien im Vergleich, 2001. IRHIS Integrated Rural Health Information System. In. ISO 14971:2007 (2007): Medical devices — Application of risk management to medical devices. In, (2007). ISO (2008): International Organization for Standardization. http://www.iso.org, accessed 23.12.2008. ISO/FDIS 27799:2007(E) (2007): Health Informatics - Information security management in health using ISO/IEC 27002. In, (2007). ISO/IEC (2005a): 17799:2005 Information technology — security techniques — code of practice for information security management system., 2005a. ISO/IEC (2005b): Information technology — Security techniques — Information security management systems — Requirements. In, (2005b). ISO/IEC (2005c): ISO/IEC 2nd WD 27004 ─ Information technology ─ Secutechniques ─ Information security metrics and measurements In, (2005c). ISO/IEC (2005d): Text of ISO/IEC FDIS 17799: 2005-02-11 ― Information techniques ― Security techniques ― Code of practice for information security management (2nd edition), DIN Deutsches Institut für Normung e. V., Berlin 2005d. ISO/IEC TR 13335-3 (1998): Guidelines for the management of IT Security - Part 3: Techniques for the management of IT Security. Genf. Janczewski, L.; Xinli Shi, F. (2002): Development of Information Security Baselines for Healthcare Information Systems in New Zealand. In: Computers & Security, Vol. 21 (2002) Nr. 2, pp. 172-192. Järvinen, P. (2007 ): Action Research is Similar to Design Science. In: Quality and Quantity, Vol. 41 (2007 ) Nr. 1, pp. 37-54. Jennings, N.R. (2001): An Agent-Based Approach for Building Complex Software Systems. In: Communications of the ACM, Vol. 44 (2001) Nr. 4, pp. 35-41.

252

Bibliography

JIPDEC (2004): ISMS User’s Guide for Medical Organizations, 2004. Kaplan, A. (1964): The Conduct of Inquiry, San Francisco: Chandler 1964. Karabacaka, B.; Sogukpinar, I. (2005): ISRAM: information security risk analysis method. In: Computers & Security, Vol. 24 (2005) Nr. 2, pp. 147-159. Kardas, G.; Tunali, E.T. (2006): Design and implementation of a smart card based healthcare information system. In: Computer Methods and Programs in Biomedicine, Vol. 81 (2006) Nr. 1, pp. 66-78. Karlsson, F.; Agerfalk, P.J.; Hjalmarsson, A. (2001): Method configuration with development tracks and generic project types. The 6th CAiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in System Analysis and Design. Switzerland. Karlsson, F.; Wistrand, K. (2004): MC Sandbox – Tool Support for Method Configuration The Ninth CAiSE/IFIP 8.1/EUNO International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD'04). Riga, Latvia. Karlsson, F.; Wistrand, K. (2006): Combining method engineering with activity theory: theoretical grounding of the method component concept. In: European Journal of Information Systems, Vol. 15 (2006), pp. 82-90. Katsikas, S.K. (2000): Health care management and information systems security: awareness, training or education? In: International Journal of Medical Informatics, Vol. 60 (2000), pp. 129-135. KBV (Kassenärztliche Bundesvereinigung Deutschland) (2008): xDT - Synonym für elektronischen Datenaustausch in der Arztpraxis. http://www.kbv.de/ita/4274.html, accessed 15.12.2008. Kiely, L.; Benzel, T.V. (2006): Systemic Security Management In: IEEE Security and Privacy, Vol. 4 (2006) Nr. 6, pp. 74-77. Kim, M.I.; Johnson, K.B. (2002): Personal Health Records: Evaluation of Functionality and Utility. In: Journal of the American Medical Informatics Association, Vol. 9 (2002) Nr. 2, pp. 171-180. King, J.L. (2001): Operational Risk - Measurement and Modelling., John Wiley & Sons, Chichester 2001. Klecun, E.; Cornford, T. (2005): A critical approach to evaluation. In: European Journal of Information Systems, (2005) Nr. 14, pp. 229–243. Kluge, E.-H.W. (2004): Informed consent and the security of the electronic health record (EHR): some policy considerations. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 229-234. Kokolakis, S.A.; Demopoulos, A.J.; Kiountouzis, E.A. (2000): The use of business process modelling in information systems security analysis and design. In: Information Management & Computer Security, Vol. 8 (2000) Nr. 3, pp. 107-116.

Bibliography

253

Kontaxakis, G.; Pozo, M.A.; Ohl, R.; Visvikis, D.; Sachpazidis, I.; Ortega, F.; Guerra, P.; Cheze-Le Rest, C.; Selby, P.; Pan, L. (2006): European health telematics networks for positron emission tomography. In: Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment, Vol. 569 (2006) Nr. 2, pp. 626-630. Krause, M.; Brown, L. (1996): Information security in the healthcare industry. In: Information Systems Security, Vol. 5 (1996) Nr. 3, pp. 32-41. Krauss, L. (1972): SAFE: Security audit and field evaluation for computer facilities and information systems, Amacom, New York 1972. Krcmar, H. (2005): Informationsmanagement. (4. Aufl.), Springer, Berlin, Heidelberg, New York 2005. Krcmar, H.; Leimeister, J.M.; Klapdor, S.; Hörmann, C. (2007): IT-Management im Krankenhaus: Die Sicht der IT-Entscheider: Eine empirische Studie zur Ermittlung von Herausforderungen und Trends für das IT-Management in deutschen Krankenhäusern. Technische Universität München, Lehrstuhl für Wirtschaftsinformatik, 2007. Kuechler, B.; Vaishnavi, V. (2008): On theory development in design science research: anatomy of a research project. In: European Journal of Information Systems, (2008) Nr. 17, pp. 489–504. Kuhn, K.A.; Giuse, D.A. (2001): From Hospital Information Systems to Health Information Systems: Problems, Challenges, Perspectives. In: Methods of Information in Medicine, Vol. 40 (2001) Nr. 4, pp. 275-287. Kuhn, K.A.; Knoll, A.; Mewes, H.-W.; Schwaiger, M.; Bode, A.; Broy, M.; Daniel, H.; Feussner, H.; Gradinger, R.; Hauner, H.; Höfler, H.; Holzmann, B.; Horsch, A.; Kemper, A.; Krcmar, H.; Kochs, E.F.; Lange, R.; Leidl, R.; Mansmann, U.; Mayr, E.W.; Meitinger, T.; Molls, M.; Navab, N.; Nüsslin, F.; Peschel, C.; Reiser, M.; Ring, J.; Rummeny, E.J.; Schlichter, J.; Schmid, R.; Wichmann, H.E.; Ziegler, S. (2008): Informatics and Medicine. From Molecules to Populations. In: Methods Inf Med, Vol. 47 (2008) Nr. 4, pp. 283–295. Kuhn, K.A.; Wurst, S.H.R.; Bott, O.J.; Giuse, D.A. (2006): Expanding the Scope of Health Information Systems Challenges and Developments. In: IMIA Yearbook of Medical Informatics, (2006), pp. 43-52. Kumar, K.; Welke, R.J. (1992): Methodology Engineering: A Proposal For SituationSpecific Methodology Construction. In: Challenges And Strategies For Research In Systems Development. Hrsg.: Cotterman, W.W.; Senn, J.A. John Wiley & Sons, Chichester 1992, pp. 257-269. Kuper, P. (2005): The state of security. In: Security & Privacy Magazine, IEEE, Vol. 3 (2005) Nr. 5, pp. 51-53.

254

Bibliography

Landau, S. (2008): Privacy and security. In: Communications of the ACM, Vol. 51 (2008) Nr. 11, pp. 25-26. Laudon, K.C.; Laudon, J.P.; Schoder, D. (2006): Wirtschaftsinformatik - Eine Einführung, Pearson Studium, München 2006. Lehmann, T.M. (2005): Handbuch der Medizinischen Informatik. (2. vollständig neu bearbeitete Aufl.), Carl Hanser, München, Wien 2005. Lenz, R.; Beyer, M.; Meiler, C.; Jablonski, S.; Kuhn, K.A. (2005): Informationsintegration in Gesundheitsversorgungsnetzen: Herausforderungen an die Informatik. In: Informatik-Spektrum, Vol. 28 (2005) Nr. 2, pp. 105-119. Lenz, R.; Elstner, T.; Siegele, H.; Kuhn, K.A. (2002): A Practical Approach to Process Support in Health Information Systems. In: Journal of the American Medical Informatics Association, Vol. 9 (2002) Nr. 6, pp. 571–585. Lenz, R.; Kuhn, K.A. (2004): Towards a continuous evolution and adaptation of information systems in healthcare. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 1, pp. 75-89. LeRouge, C.; Mantzana, V.; Wilson, E.V. (2007): Health care information systems research, revelations and visions. In: European Journal of Information Systems, Vol. 16 (2007) Nr. 6, pp. 669-671(3). LeVeque, V. (2006): Information Security - A Strategic Approach, Wiley-Interscience, Hoboken u.a 2006. Liftin, D.; Geiler, T.; Lutz, G.; Kirchner, A.; Lomax, R.; Mersmann, J.; Körting, S.; Stadler, J.; Nägele, R. (2004): Erarbeitung einer Strategie zur Einführung der Gesundheitskarte – Geschäftsprozessmodell.: Projektgruppe bIT4health. Lindup, K.R. (1995): A New Model for Information Security Policies. In: Computers & Security, Vol. 14 (1995), pp. 691-695. Lippert, S.; Kverneland, A. (2003): The Danish National Health Informatics Strategy In: The New Navigators: From Professionals to Patients. Hrsg.: R Baud et al. IOS Press, 2003. Longstaff, T.A.; Chittister, C.; Pethia, R.; Haimes, Y.Y. (2000): Are We Forgetting the Risks of Information Technology? In: Computer, Vol. 33 (2000) Nr. 12, pp. 43- 51. Loos, C. (2005): Smart Cards im Gesundheitswesen. In: Wirtschaftsinformatik, Vol. 47 (2005) Nr. 3, pp. 219-221. Lorence, D.P.; Churchill, R. (2005): Incremental adoption of information security in healthcare organizations: implications for document management. In: Information Technology in Biomedicine, IEEE Transactions on, Vol. 9 (2005) Nr. 2, pp. 169-173. Lüthi, M. (2008): Information System Security in Health Information Systems. Dissertation, Universität Bern 2008.

Bibliography

255

Mandl, K.D.; Simons, W.W.; Crawford, W.C.; Abbett, J.M. (2007): Indivo: a personally controlled health record for health information exchange and communication. In: BMC Medical Informatics and Decision Making, Vol. 7 (2007) Nr. 25. Mantzana, V.; Themistocleous, M.; Irani, Z.; Morabito, V. (2007): Identifying healthcare actors involved in the adoption of information systems. In: European Journal of Information Systems, Vol. 16 (2007), pp. 91-102. March, S.T.; Smith, M.D. (1995): Design and natural science research on information technology. In: Decision Support Systems, (1995) Nr. 15, pp. 251-266. Märkle, S.; Lemke, H.U. (2002): Die elektronische Patientenakte - ist eine Standardisierung in Sicht? In, (2002). Markus, M.L.; Majchrzak, A.; Gasser, L. (2002): A Design Theory for Systems That Support Emergent Knowledge Processes. In: MIS Quarterly, Vol. 26 (2002) Nr. 3, pp. 179–212. Marschollek, M.; Demirbilek, E. (2006): Providing longitudinal health care information with the new German Health Card—a pilot system to track patient pathways. In: Computer Methods and Programs in Biomedicine, Vol. 81 (2006) Nr. 3, pp. 266-271. Marshall, C.L. (2001): Measuring and Managing Operational Risks in Financial Institutions. Tools, Techniques, and other Resources, John Wiley & Sons, Singapore u.a. 2001. Martin, J. (1990): Information Engineering, Book II - Planning and Analysis, Prentice Hall, Englewood Cliffs 1990. Masys, D.; Baker, D.; Butros, A.; Cowles, K. (2002): Giving Patients Access to Their Medical Records via the Internet. In: Journal of the American Medical Informatics Association, Vol. 9 (2002) Nr. 2, pp. 181-191. Mauro, C.; Leimeister, J.M.; Sunyaev, A.; Krcmar, H. (2008a): Zentrale Verwaltung von Gesundheitskarten im stationären Krankenhausumfeld – Das IQ-Medi-LOG-Produkt als Alternative zu gematik-Konzepten. In: Wirtschaftsinformatik, Vol. 50 (2008a) Nr. 6, pp. 489-499. Mauro, C.; Sunyaev, A.; Dünnebeil, S.; Leimeister, J.M.; Krcmar, H. (2009a): Medizinische Software im Kontext des Medizinproduktegesetzes. In: Proceedings of Informatik 2009 - Im Focus das Leben. Hrsg. GI - Gesellschaft für Informatik, Lübeck 2009a, pp. To appear. Mauro, C.; Sunyaev, A.; Leimeister, J.M.; Krcmar, H. (2009b): Service-orientierte Integration medizinischer Geräte- eine State of the Art Analyse. Paper presented at the WI 2009 - Proceedings of Wirtschaftsinformatik 2009 - Business Services: Konzepte, Technologien und Anwendungen, Vienna, Austria, pp. 119-128.

256

Bibliography

Mauro, C.; Sunyaev, A.; Leimeister, J.M.; Krcmar, H. (2010): Standardized Device Services: A Design Pattern for Service Oriented Integration of Medical Devices. Paper presented at the Proceedings of the Hawaii International Conference on System Sciences (HICSS 43), Kauai, Hawaii, pp. To appear. . Mauro, C.; Sunyaev, A.; Leimeister, J.M.; Schweiger, A.; Krcmar, H. (2008b): A Proposed Solution for Managing Doctor’s Smart Cards in Hospitals Using a Single Sign-On Central Architecture. Hawaii International Conference on System Sciences (HICSS 41). Big Island, Hawaii. McDonald, C.J. (1997): The Barriers to Electronic Medical Record Systems and How to Overcome Them. In: Journal of the American Medical Informatics Association, Vol. 4 (1997) Nr. 3, pp. 213-221. McGuire, A.; Fenn, P.; Mayhew, K. (1989): The Assessment: The Economics of Health Care. In: Oxford Review of Economic Policy, Vol. 5 (1989) Nr. 1, pp. 1-20. Mentzinis, P. (2005): Zur Bedeutung der elektronischen Gesundheitskarte für Deutschland als Innovationsstandort. In: Telemedizinführer Hrsg. 1. Sonderausgabe (Aufl.). Hempel, Jäckel, Reum, Bad Nauheim 2005, pp. 12-13. Metzler, D. (2003): Abschätzung von Operationellen Risiken durch Informationssysteme in der Finanzindustrie. Diplomarbeit. Universität Zürich. Michel-Verkerke, M.B.; Schuring, R.W.; Spil, T.A.M. (2004): Workflow Management for Multiple Sclerosis Patients: IT and Organization. Paper presented at the 37th Hawaii International Conference on System Sciences, Hawaii. Mikkelsen, G.; Aasly, J. (2001): Concordance of information in parallel electronic and paper based patient records. In: International Journal of Medical Informatics, Vol. 63 (2001) Nr. 3, pp. 123-131. Ministry of justice (2007a): §291a Elektronische Gesundheitskarte. Ministry of justice (2007b): §291b Gesellschaft für Telematik. Moatti, J.-P. (1999): Ethical Issues in the Economic Assessment of Health Care Technologies. In: Health Care Analysis, Vol. 7 (1999), pp. 153–165. Moore, C. (2004): The Growing Trend of Government Involvement in IT Security. Paper presented at the Proceedings of the 1st annual conference on Information security curriculum development, Kennesaw, Georgia pp. 119 - 123. Morris, C.J.; Savelyich, B.S.P.; Avery, A.J.; Cantrill, J.A.; Sheikh, A. (2005): Patient safety features of clinical computer systems: questionnaire survey of GP views In: Qual Saf Health Care, Vol. 14 (2005) Nr. 3, pp. 164-168. Mouratidis, H.; Sunyaev, A.; Jürjens, J. (2009): Secure Information Systems Engineering: Experiences and Lessons Learned from Two Health Care Projects. Paper presented at the Proceedings of the 21st International Conference on Advanced Information Systems, Amsterdam, Netherlands, pp. 231-245.

Bibliography

257

Mouton, J.; Marais, H. (1988): Basic Concepts in the Methodology of the Social Sciences, HSRC Press 1988. Müller, G. (2006): Privacy and security in highly dynamic systems. In: Communications of the ACM, Vol. 49 (2006) Nr. 9. Müller, J.H. (2005): Gesundheitstelematik und Datenschutz. In: Bundesgesundheitsbl – Gesundheitsforsch - Gesundheitsschutz, Vol. 48 (2005), pp. 629-634. National Bureau of Standards (1979): Guideline for Automatic Data Processing Risk Analysis, FIPS PUB 65. U.S. General Printing Office, Washington, DC 1979. National Institute of Standards & Technology (2002): Planning Report 02-3: The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002. Neame, R. (1997): Smart cards - the key to trustworthy health information systems. In: British Medical Journal, Vol. 314 (1997) Nr. 7080, pp. 573-577. Neame, R.; Olson, M.J. (2004): Security issues arising in establishing a regional health information infrastructure. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 285-290. Nelson, B.; Choi, R.; Iacobucci, M.; Mitchell, M.; Gagnon, G. (1999): Cyberterror Prospects and Implications. In Arquilla, J.; Tucker, D. (Eds.): Center for theStudy of Terrorism and Irregular Warfare Monterey, CA. NEMA (2008): DICOM-Webseite. http://medical.nema.org/, accessed 15.12.2008. Neuhaus, J.; Deiters, W.; Wiedeler, M. (2006): Mehrwertdienste im Umfeld der elektronischen Gesundheitskarte - Möglichkeiten und Gestaltung. In: Informatik Spektrum, Vol. 22 (2006) Nr. 5, pp. 332-340. Newhouse, J.P. (2002): Why Is There A Quality Chasm? In: Health Affairs, Vol. 21 (2002) Nr. 4, pp. 13-25. NHS (2007): A practical guide to NHS Connecting for Health. In Service, N.H. (Ed.): Crown. Nicol, D.M. (2005): Modeling and simulation in security evaluation. In: Security & Privacy Magazine, IEEE, Vol. 3 (2005) Nr. 5, pp. 71-74. Nilsen, E.; Jong, H.S.; Olson, J.S.; Polson, P.G. (1992): Method Engineering: From Data to Model to Practice. Paper presented at the Conference on Human Factors in Computing Systems pp. 313 - 320 Nilsson, A.G. (1999): The Business Developer’s Toolbox: Chains and Alliances between Established Methods. In: Perspectives on Business Modelling, Understanding and Changing Organisations. Hrsg.: Nilsson, A.G.T., C.; Nellborn, C. . Springer-Verlag, Berlin, Heidelberg 1999, pp. 217-241. Nohr, C.; Andersen, S.K.; Vingtoft, S.; Bernstein, K.; Bruun-Rasmussen, M. (2005): Development, implementation and diffusion of EHR systems in Denmark. In: International Journal of Medical Informatics, Vol. 74 (2005) Nr. 2-4, pp. 229-234.

258

Bibliography

Nosofsky, R.M.; Clark, S.E.; Shin, H.J. (1989): Rules an Exemplars in Categorization, Identification, and Recognition. In: Journal of Experimental Psychology, Vol. 15 (1989) Nr. 2, pp. 282-304. Ntasis, E.; Gletsos, M.; Mouravliansky, N.A.; Zacharaki, E.I.; Vasios, C.E.; Golemati, S.; Maniatis, T.A.; Nikita, K.S. (2005): Telematics enabled virtual simulation system for radiation treatment planning. In: Computers in Biology and Medicine, Vol. 35 (2005) Nr. 9, pp. 765-781. Nunamaker, J.F.; Chen, M.; Purdin, T.D.M. (1991): Systems Development in Information Systems Research. In: Journal of Management Information Systems, Vol. 7 (1991) Nr. 3, pp. 89-106. O'Brien, M.S. (2006): Implementation of the EPIC Electronic Medical Record/Physician Order-Entry System. In: Journal of Healthcare Management, Vol. 51 (2006) Nr. 5, pp. 338-343. Object Management Group (OMG) (2003): OMG Unified Modelling Language Specification v1.5. http://www.omg.org, accessed 14.04.2003. Object Management Group (OMG) (2008): UML® Resource Page. http://www.uml.org/, accessed 20.10.2008. Oh, H.; Rizo, C.; Enkin, M.; Jadad, A. (2005): What Is eHealth?: A Systematic Review of Published Definitions. In: Journal of Medical Internet Research, Vol. 7 (2005) Nr. 1, pp. e1. openEHR (2004): OpenEHR-Webseite. http://www.openehr.org/, accessed 15.12.2005. Oppliger, R. (1996): Authentication Systems for Secure Networks, Artech House Publishers, Norwood, MA, USA 1996. Oxford Online Dictionary (2007): Method. http://www.askoxford.com/concise_oed/method?view=uk, accessed 6.12.2007. Pagliari, C.; Sloan, D.; Gregor, P. (2005): What is eHealth?: a scoping exercise to map the field. In: Journal of Medical Internet Research, Vol. 7 (2005) Nr. 1, pp. e9. Pantazi, S.V.; Kushniruk, A.; Moehr, J.R. (2006): The usability axiom of medical information systems. In: International Journal of Medical Informatics, Vol. 75 (2006) Nr. 12, pp. 829-839. Parker, J.; Coiera, E. (2000): Improving clinical communication: a view from psychology. In: Journal of the American Medical Informatics Association, Vol. 7 (2000) Nr. 5, pp. 453-461. Patrick, R.L. (1979): Security: Checklist for Computer Center Self-Audits, AFIPS 1979. Pattichis, C.S.; Schizas, C.N.; Andreou, A.S. (2002): Healthcare Telematic Applications in Cyprus. In: Methods of Information in Medicine, Vol. 41 (2002) Nr. 5, pp. 376-381.

Bibliography

259

Pedersen, S.; Hasselbring, W. (2004): Interoperabilität für Informationssysteme im Gesundheitswesen auf Basis medizinischer Standards. In: Informatik - Forschung und Entwicklung, Vol. 18 (2004) Nr. 3-4, pp. 174-188. Peltier, T.R. (2006): Social Engineering: Concepts and Solutions. In: Information Security and Risk management, Vol. November (2006), pp. 13-17. Perridon, L.; Steiner, M. (2007): Finanzwirtschaft der Unternehmung, Vahlen, München 2007. Pharow, P.; Blobel, B. (2005): Electronic signatures for long-lasting storage purposes in electronic archives. In: International Journal of Medical Informatics, Vol. 74 (2005) Nr. 2-4, pp. 279-287. Piltz, I. (2007): The Legal Significance Of Electronic Signatures In The EU. In: iBLIS Internet Business Law Services Journal, (2007). Poore, R.S. (1999): Generally Accepted System Security Principles. In: Information Systems Security,, Vol. 8 (1999) Nr. 3, pp. 27. Poore, R.S. (2000): Valuing Information Assets for Security Risk Management. In: Information Systems Security, Vol. 9 (2000) Nr. 4, pp. 17-23. Pries-Heje, J.; Baskerville, R.; Venable, J. (2008): Strategies for Design Science Research Evaluation. Paper presented at the 16th European Conference on Information Systems, Galway. Prokein, O. (2005): Management von Sicherheitsrisiken bei Banken. http://wifo1.bwl.unimannheim.de/dc2005/Beitraege_PDF/Prokein_Oliver.pdf, accessed 15.12.2007. Purao, S. (2002): Design Research in the Technology of Information Systems: Truth or Dare. GSU Department of CIS Working Paper. Atlanta. Purser, S.A. (2004): Improving the ROI of the security management process. In: Computers & Security, Vol. 23 (2004), pp. 542-546. Pyper, C.; Amery, J.; Watson, M.; Crook, C. (2004): Access to Electronic health records in primary care - a survey of patients' views. In: Medical Science Monitor, Vol. 10 (2004) Nr. 11, pp. SR17-SR22. Ralyté, J.; Rolland, C. (2001): An Approach for Method Reengineering. In: Conceptual Modeling. Paper presented at the 20th International Conference on Conceptual Modeling, Yokohama, Japan, pp. 471-484. Rechenberg, P.; Pomberger, G. (2002): Informatik-Handbuch, Hanser, München, Wien 2002. Regenstrief Institute Inc. (2008): Logical Observation Identifiers Names and Codes (LOINC®). http://www.regenstrief.org/loinc/, accessed 24.4.2008. Reichertz, P.L. (2006): Hospital information systems—Past, present, future. In: International Journal of Medical Informatics, Vol. 75 (2006) Nr. 3-4.

260

Bibliography

Richardson, S.M. (2005): Health Information Systems: Design Theory, Principles, and Application. Paper presented at the Americas Conference on Information Systems (AMCIS), Omaha, Nebraska, USA, pp. 3606. Richter, J.-P.; Haller, H.; Schrey, P. (2005): Serviceorientierte Architektur. In: InformatikSpektrum, Vol. 28 (2005) Nr. 5, pp. 413-416. Rienhoff, O.; Marschollek, M. (2004): Die elektronische Gesundheitskarte—Markstein des Medienwechsels zur elektronischen Kommunikation im Gesundheitswesen. In: Health Academy: Smart Cards in telemedizinischen Netzwerken. Hrsg. W. Aufl.2 (Aufl.). Rienhoff, O. Niederlag, Lemke, Dresden 2004, pp. 21,22. Rigby, M.; Forsström, J.; Roberts, R.; Wyatt, J. (2001): Verifying quality and safety in health informatics services. In: BMJ, Vol. 323 (2001), pp. 552-556. Rindfleisch, T.C. (1997): Privacy, Information Technology, and Health Care. In: Communications of the ACM, Vol. 40 (1997) Nr. 8, pp. 92-100. Roland Berger & Partner GmbH – International Management Consultants (2003): Qualität und Innovation im Krankenhaus. accessed 05.06.2007. Rolland, C.; Prakash, N. (1996): A Proposal For Context-Specific Method Engineering. In: Method Engineering, Principles of method construction and tool support. Hrsg.: Brinkkemper, S.; Lyytinen, K.; Welke, R.J. Chapman & Hall, London 1996, pp. 191208. Ross, S.E.; Todd, J.; Moore, L.A.; Beaty, B.L.; Wittevrongel, L.; Lin, C.-T. (2005): Expectations of Patients and Pysicians Regarding Patient-Accessible Medical Records. In: Journal of Medical Internet Research, Vol. 7 (2005) Nr. 2, pp. Article e13. Rowlands, D. (2005): HealthConnect: A Health Information Network for All Australians In: Person-Centered Health Records. Hrsg. Springer New York 2005, pp. 242-258. Rubin, A.; Babbie, E.R. (2004): Research methods for social work., Wadsworth Publishing 2004. Safran, C.; Jones, P.; Rind, D.; Bush, B.; Cytryn, K.; Patel, V. (1998): Electronic communication and collaboration in a healthcare practice. In: Artificial Intelligence in Medicine, Vol. 12 (1998) Nr. 2, pp. 137-151. Saleh, M.S.; Alrabiah, A.; Bakry, S.H. (2007): Using ISO 17799: 2005 information security management: a STOPE view with six sigma approach. In: International Journal of Network Management, Vol. 17 (2007), pp. 85-97. Saranummi, N. (2005): PICNIC Architecture. In: Stud Health Technol Inform, Vol. 115 (2005), pp. 37-60.

Bibliography

261

Schabetsberger, T.; Ammenwerth, E.; Andreatta, S.; Gratl, G.; Haux, R.; Lechleitner, G.; Schindelwig, K.; Stark, C.; Vogl, R.; Wilhelmy, I. (2006): From a paper-based transmission of discharge summaries to electronic communication in health care regions. In: International Journal of Medical Informatics, Vol. 75 (2006) Nr. 3-4, pp. 209-215. Schlichtinger, A. (2005): Standards of the IT-Governance: COBIT, ITIL etc. - description, confrontation and classification, Wirtschaftuniversität Wien 2005. Schneider, W. (2006): Bewertung von Sicherheitsanforderungen. Diplom, TU München 2006. Schneier, B. (1996): Applied Cryptography, John Wiley & Sons, Inc., New York, Chichester, Brisbane, Toronto, Singapore, 1996. Schneier, B. (2000): Secrets and lies: digital security in a networked world. (1 edition Aufl.), John Wiley & Sons 2000. Schneier, B. (2004a): Secrets & lies: IT-Sicherheit in einer vernetzten Welt, dpunkt-Verl., Heidelberg 2004a. Schneier, B. (2004b): Secrets and Lies: Digital Security in a Networked World, Wiley 2004b. Schneier, B. (2008): The Psychology of Security In: Communications of the ACM, Vol. 50 (2008) Nr. 5, pp. 128. Schnell, R.; Hill, P.; Esser, E. (2005): Methoden der empirischen Sozialforschung, Oldenbourg, München 2005. Schöllkopf, J. (2007): (N)Onliner Atlas 2007, TNS Infratest 2007. Schröder, K.T. (2005): Die elektronische Gesundheitskarte und ihre Vorteile für den Gesundheitsversorgungsprozess. In: Telemedizinführer Deutschland „Elektronische Gesundheitskarte“. Hrsg.: Hempel, V.; Jäckel, A.; Reum, L. o.O. 2005, pp. 8-9. Schutze, B.; Kroll, M.; Geisbe, T.; Filler, T.J. (2004): Patient data security in the DICOM standard. In: European Journal of Radiology, Vol. 51 (2004) Nr. 3, pp. 286-289. Schweiger, A. (2007): Agentenbasiertes Konstruieren von verteilten Systemen am Beispiel Gesundheitswesen. Dissertation, Technische Universität München 2007. Schweiger, A.; Hillebrand, C.; Sunyaev, A.; Krcmar, H. (2006): Portierung einer agentenbasierten elektronischen Patientenakte auf mobile Endgeräte. Paper presented at the Mobiles Computing in der Medizin, Frankfurt, pp. 28-45. Schweiger, A.; Krcmar, H. (2004): Multi-Agent Systems for Active, Dynamic Activity Areas. Paper presented at the Americas Conference on Information Systems (AMCIS), New York City, USA, pp. 242-245. Schweiger, A.; Leimeister, J.M.; Krcmar, H. (2005): Auf dem Weg zur integrierten Versorgung im Gesundheitswesen: Teil 1. In: Krankenhaus-IT Journal, Vol. 2005 (2005) Nr. 1, pp. 62-64.

262

Bibliography

Schweiger, A.; Sunyaev, A.; Leimeister, J.M.; Krcmar, H. (2007a): Information Systems and Healthcare XX: Toward Seamless Healthcare with Software Agents. In: Communications of the Association for Information Systems, Vol. 19 (2007a) Nr. 33, pp. 692709. Schweiger, A.; Sunyaev, A.; Mauro, C.; Leimeister, J.M.; Krcmar, H. (2007b): Single Sign-On Clinic Card-Lösung - Ein Konzept zur zentralen Verwaltung von Gesundheitskarten im stationären Umfeld. Informatik 2007 - Informatik trifft Logistik, Band 2. Proceedings of Informatik 2007, (S. 463-468). Bonn: GI - Gesellschaft für Informatik. Scott, R.E.; Jennett, P.; Yeo, M. (2004): Access and authorisation in a Glocal e-Health Policy context. In: International Journal of Medical Informatics, Vol. 73 (2004) Nr. 3, pp. 259-266. Scriven, M. (1980): The Logic of Evaluation, Edgepress, Inverness, CA, USA 1980. Sek, A.C.; Cheung, N.; Choy, K.; Wong, W.; Tong, A.Y.; Fung, V.H.; Fungc, M.; Hoc, E. (2007): A Territory-Wide Electronic Health Record - from Concept to Practicality: the Hong Kong Experience. In: Medinfo, Vol. 129 (2007), pp. 293-296. Serour, G.I. (2006): Confidentiality, privacy and security of patients' health care information: FIGO Committee for the Ethical Aspects of Human Reproduction and Women's Health. In: International Journal of Gynecology & Obstetrics, Vol. 93 (2006) Nr. 2, pp. 184-186. SGB (2007): Sozialgesetzbuch, DTV-Beck 2007. SGB V (2008): SGB V - Öffentliches Gesundheitswesen (Vol. Fünftes Buch). (15. Aufl Aufl.), DTV-Beck 2008. Siau, K. (1999): Information modeling and method engineering: a psychological perspective. In: Journal of Database Management, Vol. 10 (1999), pp. 44-50. Siau, K.; Rossi, M. (2008): Evaluation techniques for systems analysis and design modelling methods; a review and comparative analysis. (Vol. 9999). Siemens Insight Consulting (2007): Overview CRAMM users. http://www.cramm.com/overview/users.htm, accessed 11.02.2008. SigG (2001): Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz SigG) - Signaturgesetz vom 16. Mai 2001 (BGBl. I S. 876), zuletzt geändert durch Artikel 3 Abs. 9 des Gesetzes vom 7. Juli 2005 (BGBl. I S. 1970; änderung durch Art. 4 G v. 26.2.2007 I 179 zuküunftig in Kraft). SigV (2001): Verordnung zur elektronischen Signatur (Signaturverordnung - SigV) – Signaturverordnung vom 16. November 2001 (BGBl. i S. 3074), geändert durch Artikel 2 des Gesetzes vom 4. Januar 2005 (BGBl. I S. 2). Simon, H.A. (1996): Sciences of the Artificial. (3 Aufl.), MIT Press, Boston 1996.

Bibliography

263

Simon, M. (2007): Das Gesundheitssystem in Deutschland – Eine Einführung in Struktur und Funktionsweise. (2., vollständig überarbeitete Auflage Aufl.), Verlag Hans Huber, Bern 2007. Simons, W.W.; Mandl, K.D.; Kohane, I.S. (2005): The PING Personally Controlled Electronic Medical Record System: Technical Architecture. In: Journal of the American Medical Informatics Association Vol. 12 (2005) Nr. 1, pp. 47-54. Siponen, M.; Baskerville, R.; Heikka, J. (2006): A Design Theory for Secure Information Systems Design Methods. In: Journal of the Association for Information Systems, Vol. 7 (2006) Nr. 11, pp. 725-770. Siponen, M.; Iivari, J. (2006): Six Design Theories for IS Security Policies and Guidelines. In: Journal of the Association for Information Systems, Vol. 7 (2006) Nr. 7, pp. 445472. Siponen, M.; Willison, R. (2007): A Critical Assessment of IS Security Research Between 1990-2004. Paper presented at the 15th European Conference of Information Systems, St. Gallen, Switzerland, pp. 1551-1559. Siponen, M.T. (2005a): Analysis of modern IS security development approaches: towards the next generation of social and adaptable ISS methods. In: Information and Organization, Vol. 15 (2005a) Nr. 4, pp. 339-375. Siponen, M.T. (2005b): An analysis of the traditional IS security approaches: implications for research and practice. In: European Journal of Information Systems, Vol. 14 (2005b), pp. 303–315. Sittig, D.F. (2001): Personal health records on the internet: a snapshot of the pioneers at the end of the 20t Century. In: International Journal of Medical Informatics, Vol. 65 (2001) Nr. 1, pp. 1-6. Smith, E.; Eloff, J.H.P. (1999): Security in health-care information systems—current trends. In: International Journal of Medical Informatics, Vol. 54 (1999), pp. 39-54. Smith, E.; Eloff, J.H.P. (2002): A Prototype for Assessing Information Technology Risks in Health Care. In: Computers & Security Vol. 21 (2002) Nr. 3, pp. 000-000. SNOMED International (2008): SNOMED International Web-Seite. http://www.snomed.org/index.html, accessed 15.12.2008. Solms, R.v. (1998): Information security management (3): the Code of Practice for Information Security Management (BS 7799). In: Informat ion Management & Computer Security, Vol. 6 (1998) Nr. 5, pp. 224-225. Sonnenreich, W.; Albanese, J.; Stout, B. (2006): Return On Security Investment (ROSI) – A Practical Quantitative Model. In: Journal of Research and Practice in Information Technology, Vol. 38 (2006) Nr. 1, pp. 45-56.

264

Bibliography

Spil, T.A.M.; van de Meeberg, H.J.; Sikkel, K. (1999): The definition, selection and implementation of a new Hospital Information System to prepare the hospital for the electronic future: An example of project based education. Paper presented at the Proceedings of the 32nd Hawaii International Conference on System Sciences,, Hawaii. Stallinger, M. (2004): CRISAM® - Corporate Risk Application Method – Summary V2.0, 2004. Standardized Communication of Information Systems in Physician Offices and Hospitals using XML (SCIPHOX) (2006): Arbeitsgemeinschaft SCIPHOX GbR mbH c/o DIMDI. In, (2006). Standards Australia International (2003): Information security management — Implementation guide for the health sector Standards Australia International Ltd,, Sydney 2003. Standards Australia International; Standards New Zealand (2001): Guidelines for managing risk in healthcare sector: Australian/New Zealand handbook, Standards Australia International, Sydney 2001. Stausberg, J.; Uslu, A. (2005): Nutzen und Kosten der Elektronischen Patientenakte. Paper presented at the 50. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds), 12. Jahrestagung der Deutschen Arbeitsgemeinschaft für Epidemiologie (dae), Freiburg im Breisgau, Deutschland, pp. 101103. StGB (2005): Strafgesetzbuch, DTV Deutscher Taschenbuch Verlag 2005. Stoneburner, G.; Goguen, A.; Feringa, A. (2002a): NIST SP 800-30: Risk Management Guide for Information Technology Systems. In, (2002a). Stoneburner, G.; Goguen, A.; Feringa, A. (2002b): Risk Management Guide for Information Technology Systems - Recommendations of the National Institute of Standards and Technology, 2002b. Su, X. (2006): An Overview of Economic Approaches to Information Security Management. University of Twente, 2006. Sunyaev, A. (2005): Telematik im Gesundheitswesen - Sicherheitsaspekte. Diplomarbeit, Technische Universität München 2005. Sunyaev, A. (2009): Design and Application of a Security Analysis Method for Healthcare Telematics in Germany (HatSec). Paper presented at the GI SIG SIDAR, Stuttgart, Germany, pp. p. 19. Sunyaev, A.; Atherton, M.; Mauro, C.; Leimeister, J.M.; Krcmar, H. (2009a): Characteristics of IS Security Approaches with Respect to Healthcare. Paper presented at the AMCIS 2009 - Proceedings of the 15th Americas Conference on Information Systems, San Francisco, California, Paper 609.

Bibliography

265

Sunyaev, A.; Chornyi, D.; Mauro, C.; Krcmar, H. (2010): Evaluation Framework for Personal Health Records: Microsoft HealthVault vs. Google Health. Paper presented at the Proceedings of the Hawaii International Conference on System Sciences (HICSS 43), Kauai, Hawaii, To appear. Sunyaev, A.; Dünnebeil, S.; Mauro, C.; Leimeister, J.M.; Krcmar, H. (2009b): Sicherheitsbetrachtung der Primärsysteme in der Deutschen Gesundheitstelematik. Paper presented at the Proceedings of 54. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (GMDS), Essen. Sunyaev, A.; Göttlinger, S.; Mauro, C.; Leimeister, J.M.; Krcmar, H. (2009c): Analysis of the Applications of the Electronic Health Card in Germany. Paper presented at the WI 2009 - Proceedings of Wirtschaftsinformatik 2009 - Business Services: Konzepte, Technologien und Anwendungen, Vienna, Austria, pp. 749-758. Sunyaev, A.; Hansen, M.; Krcmar, H. (2008): Method Engineering: A Formal Approach. Paper presented at the 17th International Conference on Information Systems Development, Paphos, Cyprus, pp. 645-654. Sunyaev, A.; Huber, M.J.; Mauro, C.; Leimeister, J.M.; Krcmar, H. (2008a): Bewertung und Klassifikation von Bedrohungen im Umfeld der elektronischen Gesundheitskarte. Paper presented at the Proceedings of Informatik 2008 - Beherrschbare Systeme – dank Informatik, pp. 65-70. Sunyaev, A.; Kaletsch, A.; Mauro, C.; Krcmar, H. (2009d): Security Analysis of the German electronic Health Card’s Peripheral Parts. Paper presented at the ICEIS 2009 – Proceedings of the 11th International Conference on Enterprise Information Systems, Milan, Italy, pp. 19-26. Sunyaev, A.; Leimeister, J.M.; Krcmar, H. (2009a): Security Analysis of the German Healthcare Telematics. Paper presented at the AMCIS 2009 - Proceedings of the 15th Americas Conference on Information Systems. , San Francisco, California, Paper 232. Sunyaev, A.; Leimeister, J.M.; Krcmar, H. (2009b): Telematik im Gesundheitswesen: Sichere Autobahn mit unsicheren Auffahrten? In: Krankenhaus-IT Journal, (2009b) Nr. 2, pp. 46-47. Sunyaev, A.; Leimeister, J.M.; Schweiger, A.; Krcmar, H. (2006): Integrationsarchitekturen für das Krankenhaus - Status quo und Zukunftsperspektiven. In: Information Management & Consulting, Vol. 21 (2006), pp. 28-35. Sunyaev, A.; Leimeister, J.M.; Schweiger, A.; Krcmar, H. (2007): Die elektronische Gesundheitskarte und Sicherheitsaspekte: Ein Vorschlag zur entwicklungsbegleitenden Sicherheitsevaluation aus Anwendersicht Paper presented at the Informatik 2007 – Informatik trifft Logistik, pp. 469-474.

266

Bibliography

Sunyaev, A.; Leimeister, J.M.; Schweiger, A.; Krcmar, H. (2008b): IT-Standards and Standardization Approaches in Healthcare. In: Encyclopedia of Healthcare Information Systems. Hrsg.: Wickramasinghe, N.; Geisler. Idea Group, 2008b, pp. 813-820. Sunyaev, A.; Schweiger, A.; Leimeister, J.M.; Krcmar, H. (2008c): Software-Agenten zur Integration von Informationssystemen im Gesundheitswesen. Paper presented at the Multikonferenz Wirtschaftsinformatik 2008, München, pp. 1455-1466. Sunyaev, A.; Tremmel, F.; Mauro, C.; Leimeister, J.M.; Krcmar, H. (2009e): A Re-Classification of IS Security Analysis Approaches. Paper presented at the AMCIS 2009 – Proceedings of the 15th Americas Conference on Information Systems, San Francisco, California, Paper 570. Sunyaev, A.; von Beck, J.; Jedamzik, S.; Krcmar, H. (2008d): IT-Sicherheitsrichtlinien für eine sichere Arztpraxis, Shaker, Berlin, ISBN 978-3832272142. Sunyaev, A.; von Beck, J.; Jedamzik, S.; Krcmar, H. (2008e): IT-Sicherheitsrichtlinien für eine sichere Arztpraxis. Arbeitspapier Nr. 33. Arbeitspapier Technische Universität München, Lehrstuhl für Wirtschaftsinformatik. Swanson, M.; Bartol, N.; Sabato, J.; Hash, J.; Graffo, L. (2003): NIST Special Publication 800-55: Security Metrics Guide for Information Technology Systems, Gaithersburg 2003. Takeda, H.; Tomiyama, T.; Yoshikawa, H.; Veerkamp, P. (1990): Modeling Design Processes. Centre for Mathematics and Computer Science, 1990. Tang, P.C.; Ash, J.S.; Bates, D.W.; Overhage, J.M.; Sands, D.Z. (2006): Personal Health Records: Definitions, Benefits, and Strategies for Overcoming Barriers to Adoption. In: Journal of the American Medical Informatics Association, Vol. 13 (2006), pp. 121126. Tettero, O.; Out, D.J.; Franken, H.M.; Schot, J. (1997): Information security embedded in the design of telematics systems. In: Computers & Security, Vol. 16 (1997) Nr. 2, pp. 145-164. The Good European Health Record (2006): The Good European Health Record. http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/, accessed 10.05.2006. The openEHR foundation (2006): Introducing openEHR. www.openehr.org, accessed 10.05.2006 Toyoda, K. (1998): Standardization and security for the EMR. In: International Journal of Medical Informatics, (1998) Nr. 48, pp. 57-60. Ückert, F.; Görz, M.; Ataian, M.; Prokosch, H.-U. (2002): akteonline - an electronic healthcare record as a medium for information and communication. Paper presented at the Medical Informatics Europe, Budapest, pp. 293-297. UMLS (2008): United States National Library of Medicine. http://www.nlm.nih.gov/research/umls/, accessed 24.04.2008.

Bibliography

267

United States National Library of Medicine; National Institutes of Health (2008): MesH Medical Subject Headings. http://www.nlm.nih.gov/mesh/, accessed 11.05.2008. Vaast, E. (2007): Danger is in the eye of the beholders: Social representations of Information Systems security in healthcare. In: Journal of Strategic Information Systems, Vol. 16 (2007), pp. 130-152. Vaishnavi, V.; Kuechler, W. (2004): Design Research in Information Systems. http://www.isworld.org/Researchdesign/drisISworld.htm, accessed 07.09.2004. van der Bijl, N. (2005): Security in Modern Healthcare. In: Business Briefing: Hospital Engineering & Facilities Management, (2005) Nr. 2, pp. 1-4. Vorster, A.; Labuschagne, L. (2001): A Framework for Comparing Different Information Security Risk Analysis Methodologies. University of Johannesburg, 2001. Waegemann, C.P. (1999): Current Status of EPR Development in the US. Paper presented at the Toward An Electronic Health Record Europe, London, pp. 116-118. Wahl, U. (2004): Telematik – Wer nicht mitspielt, fliegt aus dem System. In: Landesärztekammer Baden-Württemberg, (2004), pp. 480-498. Walter, O. (2008): Die ärztliche Dokumentation. Warda, F.; Noelle, G. (2002): Telemedizin und eHealth in Deutschland: Materialien und Empfehlungen für eine nationale Telematikplattform. (1. Aufl.), videel OHG, Köln 2002. Warren, M.J.; Furnell, S.; Sanders, P.W. (1997): ODESSA - a new approach to healthcare risk analysis. In: SEC. Hrsg. 1997, pp. 391-402. Webster, J.; Watson, R.T. (2002): Analyzing the past to prepare for the future: writing a Literature Review. In: MIS Quarterly, Vol. 26 (2002) Nr. 2, pp. xiii-xxiii. Wen, H.J.; Tarn, J.M. (2001): Privacy and Security in E-Healthcare Information Management. In: Information Security Journal: A Global Perspective, Vol. 10 (2001) Nr. 4, pp. 1-16. WHO (2008): World Health Organization. http://www.who.int, accessed 19.10.2008. Win, K.T.; Susilo, W. (2006): Information security and privacy of health data. In: International Journal of Healthcare Technology & Management, Vol. 7 (2006) Nr. 6, pp. 7-7. Winter, R. (2008): Design science research in Europe. In: European Journal of Information Systems, (2008) Nr. 17, pp. 470–475. Wirsz, N. (2000): IT-Standards im Gesundheitswesen. In: electromedica 68 Heft 1, (2000). Wöhe, G. (2005): Einführung in die Allgemeine Betriebswirtschaftslehre. (22. Aufl., Aufl.), Vahlen, München 2005. Wolf, G.; Pfitzmann, A. (2000): Charakteristika von Schutzzielen und Konsequenzen für Benutzungsschnittstellen. In: Informatik Spektrum, Vol. 23 (2000), pp. 173-191. Wooldridge, M.; Jennings, N.R. (1995): Intelligent Agents: Theory and Practice. In: The Knowledge Engineering Review, Vol. 10 (1995) Nr. 2, pp. 115-152.

268

Bibliography

World Health Organization (2005): What is E-Health? . http://www.emro.who.int/his/ehealth/AboutEhealth.htm, accessed 22.12.2008. Yasnoff, W.A.; Humphreys, B.L.; Overhage, J.M.; Detmer, D.E.; Brennan, P.F.; Morris, R.W.; Middleton, B.; Bates, D.W.; Fanning, J.P. (2004): A consensus action agenda for achieving the national health information infrastructure. In: Journal of the American Medical Informatics Association, Vol. 11 (2004) Nr. 4, pp. 332-338. Zhang, L.; Ahn, G.-J.; Chu, B.-T. (2002): A Role-Based Delegation Framework for Healthcare Information Systems. In: SACMAT, (2002), pp. 125-134. Zöller, A.; Rothlauf, F.; Paulussen, T.O.; Heinzl, A. (2006): Benchmarking of Multiagent Systems In: Multiagent Engineering. Hrsg. Springer Berlin Heidelberg 2006.

Appendix General IS Security Approach Characteristics Name

Short Description

1

Name of the approach (ENISA 2006)

The full name of the IS security approach.

2

Vendor name (Schlichtinger 2005; ENISA 2006)

Company or cross-frontier organization that provides the IS security approach.

3

Current version

The version during the case study period.

4

Availability

Are there any costs or is it available free of charge?

5

Languages available (ENISA 2006)

Which languages are supported by the IS security approach?

6

Research activity

Extent, scope, transparency, independency of the review verification of the active research undertaken.

7

Skills needed / Time and effort (ENISA 2006; Initiative D21 2001)

The skills needed to understand, maintain or perform the IS security approach in the organization.

8

Consultancy support (ENISA 2006)

Is it necessary to use external help (consultancy) in order to apply the IS security approach?

9

Identification of the IS security approach (ENISA 2006; Schlichtinger 2005)

Type of the IS security approach concerned, which can be a standard, a norm, a method, regulation, guideline etc.

10

The country of origin (ENISA 2006)

The origination from a company or national organization.

11

Level of reference of the IS security approach (ENISA 2006; Schlichtinger 2005; BITKOM 2006)

Details about the type(s) of initiator(s) of the IS security approach.

12

Geographical spread (ENISA 2006; Initiative D21 2001)

Whether the IS security approach is also established outside of its original field, i.e., the degree of its internationality, e.g., if the IS security approach is used in EU or non-EU member countries.

13

Lifecycle / Actuality (ENISA 2006; Initiative D21 2001; Beham 2004)

A short historical overview in order to gain insight into the IS security approach lifecycle (the degree of the actuality).

14

Fundamental objectives and IS security approach scope (ENISA 2006)

Intention regarding IS security approach targets to be achieved, expected results, improvements and requirements.

15

Completeness (Initiative D21 2001; Schlichtinger 2005)

How comprehensive, abstract, detailed is the IS security approach?

16

Level of detail (ENISA 2006; BITKOM 2006)

Who should read and use the IS security approach.

17

Scalability (Initiative D21 2001; Beham 2004)

Scalability for the size and complexity of healthcare organizations.

18

Target organizations (ENISA 2006; Initiative D21 2001; BITKOM 2006; Beham 2004)

The most appropriate type of health organizations the IS security approach aims at.


270

Appendix

19

Security Analysis (Beham 2004; ISO/FDIS 27799:2007(E) 2007; ISO/IEC 2005b)

Is there an appropriate security analysis approach included?

20

Supporting heterogenic, decentralized information systems (ISO/FDIS 27799:2007(E) 2007)

Taking heterogenic, decentralized information systems into consideration.

21

Process oriented evaluation method (ISO/FDIS 27799:2007(E) 2007)

Process oriented and not asset or system oriented method focused on the healthcare telematics processes.

22

Organizational Focus (Hamdi/Boudriga 2005)

Organizationally focused assessment is targeted at organizational risks which are derived from the interaction with the people with the information systems and consider the implication of the technical failure of the information systems on the patient security.

23

Pro-active security analysis (Hamdi/Boudriga 2005)

Is there a separation between preventative/pro-active and reactive security analysis especially in the healthcare domain (Hamdi/Boudriga 2005)?

24

Comparable and reusable results (ISO/IEC 2005b)

The security assessment methodology selected shall ensure that security assessments produce comparable and reproducible results.

25

Maturity level (Initiative D21 2001; ENISA 2006)

Measurement of the maturity of the information system security.

26

Available tools (ENISA 2006; Beham 2004; Initiative D21 2001)

Existing of a list of tools that support the IS security approach.

27

Certification scheme (Initiative D21 2001; ENISA 2006)

Existence of a certification scheme: a health organization may obtain a certificate, that it has fully and correctly implemented the IS security approach on its information systems.

28

Optimal investment sum (ENISA 2006)

The amount of the optimal effort related to a risk management project.

29

Organizational integration (ENISA 2006)

Interfaces to existing processes within the health organization.

30

Branch (BITKOM 2006)

Industry sector and the line of business of organizations the IS security approach aims at.

31

Target audience in the healthcare branch (Standards Australia International 2003)

The intended target group in the healthcare branch the IS security approach aims at: health consumers, healthcare providers, health funders, the state, the healthcare telematics infrastructure.

32

Compliance (ENISA 2006; Initiative D21 2001; ISO/IEC 2005b)

Compliance to a law and regulations, e.g., several commonwealth and state acts impact the health sector and must to be complied with (Standards Australia International/Standards New Zealand 2001).

33

Hazard list relevant to healthcare (ISO/FDIS 27799:2007(E) 2007)

Proposal of healthcare generic hazards.

34

Security requirements relevant to healthcare (ISO/FDIS 27799:2007(E) 2007)

Proposal of healthcare security requirements.

35

Security measures relevant to healthcare (ISO/FDIS 27799:2007(E) 2007)

Proposal of healthcare security measures.


Appendix

271

36

Risk valuation guidelines relevant to health (ISO/FDIS 27799:2007(E) 2007)

Proposal of healthcare valuation of risk explain the risk value specific for healthcare.

37

Security measures point of view (ISO/FDIS 27799:2007(E) 2007)

Are the security measures provided according to the patient’s point of view as well or only according to the IS security point of view?

38

Requirements for confidentiality, privacy, integrity, availability of information (Anderson 1996b)

Is the protection and security of information ensured with the offering of these requirements? Further security elements of information systems in healthcare are authenticity, commitment, use regulation, accuracy, utility, possession, legal liability, legal certainty, enforceability, suitability for daily use and anonymity (Müller 2005).

39

Data quality requirements (ISO/FDIS 27799:2007(E) 2007)

Requirements for completeness, validity, consistency, timeliness and accuracy of the data.

40

Physical and environmental security (Standards Australia International/Standards New Zealand 2001; ISO/IEC 2005b)

Physical security of the information systems.

Table 39: Complete Overview of the IS Security Approach Characteristics (Source: own Table)

Design and Application of a Security Analysis Method for Healthcare Telematics in Germany

Hospital and Healthcare Security

Universal Access in Health Telematics: A Design Code of Practice

Foundations of Security Analysis and Design

Foundations of Security Analysis and Design VI

Coordination Polymers: Design, Analysis and Application

Small Wind Turbines: Analysis, Design, and Application

Evidence-based Design for Healthcare Facilities

Foundations of Security Analysis and Design: Tutorial Lectures

Search for a Method

Search for a Method

Application Analysis Tools for ASIP Design: Application Profiling and Instruction-set Customization

Urban Design: Method and Techniques (Urban Design)

Electronic Healthcare Information Security (Advances in Information Security, Vol. 53)

Urban Design: Method and Techniques

Method and Substance in Macrocomparative Analysis

Hospital and Healthcare Security, Fourth Edition

Professional Cocoa Application Security

Mobile Application Security

Mobile Application Security

Centrifugal Pumps: Design And Application

The Lanczos method: evolution and application

Cuda Application Design and Development

The Lanczos Method: Evolution and Application

The Lanczos method: evolution and application

Analysis and Design of Advice

Design and Application of a Security Analysis Method for Healthcare Telematics in Germany

Hospital and Healthcare Security

Universal Access in Health Telematics: A Design Code of Practice

Foundations of Security Analysis and Design

Foundations of Security Analysis and Design VI

Coordination Polymers: Design, Analysis and Application

Small Wind Turbines: Analysis, Design, and Application

Evidence-based Design for Healthcare Facilities

Foundations of Security Analysis and Design: Tutorial Lectures

Search for a Method

Search for a Method

Application Analysis Tools for ASIP Design: Application Profiling and Instruction-set Customization

Urban Design: Method and Techniques (Urban Design)

Electronic Healthcare Information Security (Advances in Information Security, Vol. 53)

Urban Design: Method and Techniques

Method and Substance in Macrocomparative Analysis

Hospital and Healthcare Security, Fourth Edition

Professional Cocoa Application Security

Mobile Application Security

Mobile Application Security

Centrifugal Pumps: Design And Application

The Lanczos method: evolution and application

Cuda Application Design and Development

The Lanczos Method: Evolution and Application

The Lanczos method: evolution and application

Analysis and Design of Advice

Recommend Documents