SECURITY ANALYSIS OF THE HEALTH CARE TELEMATICS

INFRASTRUCTURE IN GERMANY

Michael Huber, Ali Sunyaev and Helmut Krcmar

Chair for Information Systems, Technische Universit

at M

unchen, Germany

Keywords:

Security analysis, Health Care Telematics, Electronic Health Card, Information Security Management Sys-

tems.

Abstract:

Based on ISO 27001 for Information Security Management Systems, this paper introduces a newly developed

security analysis approach, suitable for technical security analyses in general. This approach is used for a

security analysis of several components and processes of the Health Care Telematics in Germany. Besides the

results of the analysis, basics for further analysis and veriﬁcation activities is given.

1 INTRODUCTION

In Germany, the Electronic Health Card (eHC) will

replace the present health card as requested by law.

By establishing the eHC, several improvements, such

as cost savings, better ways of communication in the

health care sector or the self-determination of the in-

sured person concerning medical data, are supposed

to be achieved (Schabetsberger et al., 2006).

The use of IT to administrate medical data of the

insured, implicates the question, whether these sys-

tems are safe enough to satisfy requirements like pri-

vacy, safety, security and availability (Heeks, 2006).

The data administrated by the eHC and its infras-

tructure is mosltly strictly conﬁdential as it contains

personal information about peoples state of health,

course of disease and hereditary diseases (Lorence

and Churchill, 2005). As for example insurance com-

panies or employers would be highly interested in

such information, the security measures of TI systems

dealing with them have to be analysed in detail (An-

derson, 2001).

Due to their ethical, judicial and social implica-

tions, medical information requires extremely sensi-

tive handling. These aspects emphasise the need for a

security method that evaluates the technical aspects of

information security in a health environment. In this

paper, we ﬁrst introduce the health telematics infras-

tructure. After the introduction, an analysis approach

based on ISO 27001 is introduced in chapter 3. The

result of its application to several components of the

health telematics infrastructure is presented in chap-

ter 4. Chapter 5 concludes the paper and provides an

outlook. The current security status of health care in

Germany was evaluated and valuable hints for future

developments in the health care sector could be de-

rived.

The paper is based on a literature review (e.g.

Computers & Security, Information Management &

Computer Security, Information Systems Security, In-

ternational Journal of Medical Informatics, Informa-

tion Systems Journal, European Journal of Informa-

tion Systems, International Journal of Information Se-

curity, security & privacy, Journal of computer secu-

rity, ACM Transaction on Information and Systems

Security und ACM Computing Surveys). The secu-

rity analysis approach presented in this paper differs

from other approaches due to the following aspects:

Focus (health care sector; technical evaluation of se-

curity measures), being up-to-date (appliance of up-

to-date techniques and standards) and regional dis-

tinctions (located in germany, regional and political

conditions).

2 THE HEALTH TELEMATICS

INFRASTRUCTURE

The present health card in Germany is a storage-only

smart card, whereas the eHC will provide a micro-

processor enabling services such as the ciphering or

signing of information (Schweiger et al., 2007). This

insurance card is actually used exclusively for admin-

istrative purposes such as identifying the insured per-

son or accessing administrative data stored on the card

144

Huber M., Sunyaev A. and Krcmar H. (2008).

SECURITY ANALYSIS OF THE HEALTH CARE TELEMATICS INFRASTRUCTURE IN GERMANY.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 144-153

DOI: 10.5220/0001684901440153

 SciTePress

Figure 1: Schematic representation of the Health Telematics Infrastructure.

for accounting purposes.

Besides the eHC, there are also smart cards for

health personnel, medics, chemists and various other

professional categories, which need to interact with

the eHC and its related infrastructure (these cards are

called Health Professional Cards, shortened HPC).

The eHC as a smart card is only one part of the

infrastructure required to implement the functionality

demanded by law. The major part is represented by

an IT system called Health Telematics Infrastructure

(HTI) and its associated processes, both described in

the following sections.

The given introduction has to be considered as a

brief description of the major parts, functions and pro-

cesses of the HTI. For a more detailed description,

we refer to the public development documents by the

Gematik mbH which can be found at the organisa-

tion’s website

. Furthermore, a compact introduction

to the eHC can be found in (Huber et al., 2008).

2.1 Functions and Stages of Expansion

The eHC and its associated infrastructure will be in-

troduced in several steps with a growing amount of

functionality and complexity. For the insured, the us-

age of some of the functionalities introduced by these

steps is mandatory, the use of some other optional

(Haux, 2005).

The ﬁrst step of introduction will provide the eHC

as a smart card with the ability to store the patients

administrative data (for instance name, address, date

of birth, insurance information, etc.). On its backside,

the eHC provides a form, which enables the card to

act as an europe-wide standardised health card. The

acceptance of this step is mandatory for the insured.

The second step introduces the functionality to

store prescriptions on the smart card, formally pro-

vided to the insured as a paper form. This step is

mandatory for the insured as well.

http://www.gematik.de

Regarding the remaining steps three and four, the

use of their functionality is optional. For these steps,

it is planned to provide things like emergency-data,

the documentation of the history of medication and

an electronic dossier of the insured, partially stored

on the smart card, partially provided by a centralised

data processing center as part of the HTI.

2.2 Architecture

Figure 1 outlines the architecture of the HTI, which is

divided into a central and a decentral part.

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 cen-

tral computing centres.

The decentral part of the HTI is located at the

medical service providers. This part consists of the

medical service provider’s LAN, the Connector, card

readers for eHC and HPC and the smart cards them-

selves. The connection between decentral and central

part of the HTI is established by using a vpn connec-

tion over the internet, initialised by the medical ser-

vice provider’s Connector and accepted by a vpn con-

centrator located at the central part of the HTI.

Not part of either fraction of the HTI are the so

called Primary Systems. These systems are software

products, medical service providers use for storing

their patients’ records, for accounting purposes and

various other tasks related to health care. Because

of those components are being developed and main-

tained by third party companies, security aspects can

not be supervised by governance and thus, they are

by deﬁnition not part of the HTI. Nevertheless, these

systems were considered in the security analysis from

a general point of view, because they do store and ad-

minister sensitive medical data.

SECURITY ANALYSIS OF THE HEALTH CARE TELEMATICS INFRASTRUCTURE IN GERMANY

145

3 A NEW SECURITY ANALYSIS

APPROACH

According to (Gollmann, 2006), a technical security

analysis is deﬁned as a methodical, traceable analy-

sis of an IT system concerning primarily its technical

aspects.

Planning to perform a security analysis, it is advis-

able to base the used procedure on established stan-

dards and best practice approaches, so the analysis

relies on a previously approved scaffold.

Regarding security analyses, there are many dif-

ferent solutions from activity catalogues to loose col-

lections of analysis techniques and useful tools. De-

spite of each solution having its advantage in its ded-

icated domain, no appropriate standard or proceed-

ing could be found to analyse the mentioned compo-

nents in the way, the deﬁnition of (Gollmann, 2006)

demands. Therefore, a new approach had to be de-

veloped, allowing to analyse the relating components

from a technical point of view, using tools, methods

and processes in a structured and traceable way.

Figure 2: Levels of an Information Security Management

System.

3.1 Information Security Management

Systems

Although a new approach had to be developed, there

are some standards which were used as its base. These

standards apply to Information Security Management

Systems (ISMS). These systems are used to implement

and maintain IT security in organisations by coordi-

nating various activities, processes and tools.

An ISMS contains two levels, a System-level and

a Process-level as shown in ﬁgure 2. According to

(BSI, Bundesamt f

ur Sicherheit in der Information-

stechnik, 2004), the Process-level contains several

subprocesses such as development, planning, imple-

mentation, evaluation, and maintenance of IT secu-

rity. The System-level in contrast is concerned with

the orchestration of the Process-level’s tasks. It con-

tains matters like organisational structure, responsi-

bilities, processes and resources.

3.2 ISO 2700x

Besides well known standards like the BSI IT-

Grundschutz

, BS 7799-2 (BSI, British Standards In-

stitution, 1999) or COBIT (ITGI, IT Governance In-

stitute, 2007), there is a relatively new group of stan-

dards dealing with ISMS. This assembly of standards

is called the ISO/IEC 2700x family and will contain

at least seven standards. At the moment (november

2007), some standards of the 2700x family are already

published, others are still under development.

ISO 2700x contains, respectively will contain

standards for establishing and maintaining IT secu-

rity. Therefore, it combines particular standards from

simple vocabulary via ISMS requirements, risk man-

agement and management activities up to practical

implementation guidelines. Thus, this family is or

will be one of the most complete and comprehen-

sive up-to-date compilations of standards regarding

the ISMS issue.

3.3 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 actually emerged

from the British Standard 7799-2 (BSI, British Stan-

dards Institution, 1999). In this standard, fundamental

processes to plan, establish, operate and maintain in-

formation security in organisations are described. The

main scaffold to achieve these goals is represented

by the Plan-Do-Check-Act approach (PDCA). This

approach, as shown in ﬁgure 4, contains four steps,

which are executed repeatedly.

In the ﬁrst step of PDCA, an ISMS policy has to

be established. Therefore, objectives, processes and

procedures which are essential for managing risk and

improving information security have to be set up in

accordance with an organisation’s objectives and poli-

cies.

http://www.bsi.de/gshb/index.htm

Figure 4: The Plan-Do-Check-Act approach (PDCA).

ICEIS 2008 - International Conference on Enterprise Information Systems

146

Figure 3: The developed security analysis approach.

In a second step, the ISMS policy has to be im-

plemented and operated. Therefore, the controls, pro-

cesses and procedures set up in step one have to be

implemented.

The third step measures the effectiveness and per-

formance of the ISMS. The measurement results are

reported to the management for review.

During the fourth step, corrective and preventive

actions based on the results of step three and the re-

view of further relevant information have to be taken.

3.4 From PDCA to Security Analysis

Based on the PDCA model, we developed a new ap-

proach for a technical security analysis. By building

a new approach based on this model, various activi-

ties during a security analysis can be orchestrated in

a reasonable manner. Furthermore, the repeated exe-

cution of the approach’s steps provides a continuous

feedback of the analysis results to accommodate the

analysis activities. Figure 3 outlines the developed

security approach.

The steps of the PDCA approach described in 3.3

are adopted as a scaffold to be ﬁlled with analysis

tasks of the developed approach.

The ﬁrst step of the approach contains the iden-

tiﬁcation of possible attackers and attack types. The

result of this step will be used later on to design pos-

sible attacks on the IT system. For achieving these

results, statistics, common classiﬁcation schemes and

other resources can be used. Thus, the ﬁrst step of the

approach is quite analogue to the ﬁrst step of PDCA

where an analysis of possible threats takes place.

In the second step of the approach, the assets

of the IT system, security and also legal require-

ments and ﬁnally security measures are being iden-

tiﬁed. This step goes par with actions of the plan and

do steps of the PDCA approach. There, assets, re-

quirements and measures are identiﬁed as well. The

sources for the accomplishment of step two can be

documents of the IT system’s legal basis, results from

a former risk analysis or just basic objectives of IT

security in general.

The third and fourth step are both the central steps,

where analysis activities actually take place. Step

four contains activities of a theoretical character. This

SECURITY ANALYSIS OF THE HEALTH CARE TELEMATICS INFRASTRUCTURE IN GERMANY

147

could be for example an Attack-Tree Analysis (cp.

4.4.5) or the application of proper metrics to measure

security. The fourth step in contrast contains analy-

sis activities in a practical way. This could include

for example penetration tests, the use of one or more

exploitation frameworks or the use of individual tools

like port scanners, dedicated exploits, brute forcing

tools, etc. These two steps are thus similar to the

check step of the PDCA approach where the ISMS

is being reviewed and tested.

The ﬁfth step implements a synchronisation of the

steps three and four. The results of each step are used

to improve and complete the activities of the com-

plementary step. The synchronisation of these steps

results in a more complete and accurate analysis, as

both, theoretical and practical activities are used and

improve each other. This step has no analogy in the

PDCA approach as it is a combination of two steps,

which have no counterpart in the PDCA approach.

Step six is more or less optional as it just contains

a recapitulation of the former steps results. If these

are already well documented during the preceeding

steps, step six can be skipped.

In step seven, activities are chosen to minimize

the risks implied by the uncovered vulnerabilities and

weaknesses. This step has its counterpart in the act

step of the PDCA approach, where also measures are

implemented to improve the ISMS.

3.5 Mapping the Analysis Approach to

PDCA

Figure 5 shows the coherence of the PDCA approach

and the developed security analysis approach. Both

are executed repeatedly, and the activities of the anal-

ysis steps overlap with activities of the PDCA ap-

proach.

Figure 5: Mapping the developed approach to Plan-Do-

Check-Act.

4 RESULTS OF THE ANALYSIS

4.1 Components an Documents

Considered in the Analysis

The components considered in the security analysis

are eHC, Connector, Primary Systems, Card Readers

and the processes occurring during their interaction.

For the analysis, only publicly available docu-

ments were regarded. Of course, the analysis would

be more complete, if also internal documents were

considered, but by using only public sources, the se-

curity analysis is based on the same information level,

any invader looking for an opportunity to attack this

IT system is able to access. Furthermore, some in-

ternal development documents were marked as con-

ﬁdential at the point of analysis (november 2006 to

november 2207) and thus could not be considered at

all.

Altogether, the documents (SGB, 2007), (BDSG,

2003), (SigV, 2001), (SigG, 2001), (StGB, 2005),

(Gematik, Gesellschaft f

ur Telematikanwendun-

gen der Gesundheitskarte mbH, 2007), (Gematik,

Gesellschaft f

ur Telematikanwendungen der Gesund-

heitskarte mbH, 2006a), (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2006b), (Gematik, Gesellschaft f

ur Telematikan-

wendungen der Gesundheitskarte mbH, 2006c),

(Gematik, Gesellschaft f

ur Telematikanwendun-

gen der Gesundheitskarte mbH, 2005b), (Gematik,

Gesellschaft f

ur Telematikanwendungen der Gesund-

heitskarte mbH, 2005a), (Neeb et al., 2004) have been

considered for the analysis.

All Documents were at most dated to june 2007.

4.2 Identiﬁcation and Classiﬁcation of

Attackers and Attacks

The identiﬁcation and classiﬁcation follows in large

parts the indexing of (Schneier, 2004) and (Gerloni

et al., 2004). The attackers were thereby classiﬁed

by the criterions available amount of time, know-how

and available resources. The attacks were divided

into the topics intention (criminal, publicity, etc.), ori-

gin (internal/external) and technical basis (Schneier,

2004). Furthermore, each attacker group and type of

attack was brought into context with the eHC subject.

It emerged, that the biggest threats emanate

from the groups organised crime and cyber-terrorists

which seem to have the major interests and the largest

ﬁnancial resources.

ICEIS 2008 - International Conference on Enterprise Information Systems

148

4.3 Identiﬁcation of Assets and Security

Requirements

The identiﬁcation of assets and security requirements

was done by analysing public development docu-

ments, wordings which form the legal basis of the

eHC and several basic IT security resources (cp. 4.1).

4.4 Analysis of the

Components-Theoretical Level

4.4.1 Cross-component Analysis

The cross-component analysis was intended to anal-

yse the processes, the mentioned components are in-

volved in. Furthermore, the cross-component analysis

included a critical review of the development docu-

ments from a security-based point of view.

Key for the Combination of Medical and Admin-

istrative Data. In (Neeb et al., 2004, p. 30)

, it is

mentioned, that security must not depend on the faith

in one single person. In (Neeb et al., 2004, p. 20)

in contrast, a requirement can be found, which pos-

tulates, that the key for the combination of medical

and administrative data of the insured, which are both

stored separately, has to be kept by the ”Beauftrager fr

den Datenschutz des Medizinischen Dienstes”, which

obviously is represented by one single person.

Unauthorised Transfer of Medical Data. In

(SGB, 2007, SGBV, 294a)

, it is postulated, that un-

der certain circumstances, medical data can be ac-

cessed by the insurance without approval of the in-

sured. This exception is given by law, but conﬂicts

with a general requirement mentioned in (Gematik,

Gesellschaft f

ur Telematikanwendungen der Gesund-

heitskarte mbH, 2006a, p. 63)

, which says, that no

one is allowed to access the medical data of an insured

person without his or her approval. Although, this is

a reasonable exception, it has at least to be commu-

nicated to the insured to fulﬁll another requirement

found at (SGB, 2007, SGBV, 291a, para. 3)

, de-

manding the insured to be told whatever happens with

his medical data. These explanations can not be found

in any of the considered documents.

cp. requirement 004.So.A.AS in (Huber et al., 2008)

cp. requirement 001.Vt.A.AS in (Huber et al., 2008)

cp. requirement 010.So.A.AS in (Huber et al., 2008)

cp. requirement 002.Vt.A.AS in (Huber et al., 2008)

cp. requirement 011.So.A.AS in (Huber et al., 2008)

Missing backup Method for Honoring Prescrip-

tions. According to (Neeb et al., 2004, p. 19)

for every process in the HTI, there has to be at least

one manually operated backup process. In (Gematik,

Gesellschaft f

ur Telematikanwendungen der Gesund-

heitskarte mbH, 2006b, p. 28)

, there can be found

one exception which combined with the following

topic might result in severe problems concerning

availability demands. There, the absence of an ad-

equate backup process for honoring digital prescrip-

tions is mentioned. Thus, an insured who has the pre-

scription exclusively digitally on his eHC, has no op-

portunity to honor this prescription when the HTI is

not available to the pharmacy. It is obvious, that this

could lead to perilous situations, if prescriptions for

immediately needed physics cannot be honored.

Possibility to Honor the Same Prescription Twice.

If the availability drawback mentioned above would

be resolved by strictly implementing the requirement

of (Neeb et al., 2004, p. 19)

and thus establishing a

manually operated backup process for honoring pre-

scriptions, every insured would have on the one hand

the digital copy of the prescriptions on his eHC, on the

other hand a paper based copy to provide a manual

backup process. This way, the insured could at ﬁrst

honor his or her digital prescription as usual and af-

terwards visit a pharmacy, where the HTI is not avail-

able due to technical problems for example. There,

the insured could honor the paper based prescription,

offending several requirements concerning account-

ability and non-repudiation

Unassigned Assumption about the Security Im-

plied by the used ”Zone-Concept”. The HTI and

its related systems are divided into several zones.

This division is made, to allow a discrete view on

every zone concerning it security. As mentioned

in (Gematik, Gesellschaft f

ur Telematikanwendungen

der Gesundheitskarte mbH, 2007, p. 32), each of

these zones is considered as a closed area. However,

each of these zones is related to others using a phys-

ical connection. Wherever there is a physical con-

nection, there is also the possibility of (unauthorized)

trafﬁc between these zones, even if the chance for this

kind of trafﬁc might be very unlikely due to protec-

tion measures. Nevertheless, if there is the possibility

of (unauthorized) trafﬁc, it is not feasible to consider

each of these zones for its own and even classify them

differently.

cp. requirement 002.Vf.A.AS in (Huber et al., 2008)

cp. requirement 008.Vf.K.AS in (Huber et al., 2008)

cp. requirement 002.Vf.A.AS in (Huber et al., 2008)

cp. requirements 003.Zu.A.AS, 004.Zu.A.AS and

005.Zu.A.AS in (Huber et al., 2008)

SECURITY ANALYSIS OF THE HEALTH CARE TELEMATICS INFRASTRUCTURE IN GERMANY

149

Thus, it should be contemplated, whether it might

be reasonable to expand the view and consider the in-

teraction between zones as well. Furthermore it might

be reasonable to classify each interconnected zone the

same, concerning security issues.

Adjustment of Minimum Standards happens

Infrequently. As mentioned in (Gematik,

Gesellschaft f

ur Telematikanwendungen der Gesund-

heitskarte mbH, 2007, p. 28), the minimum security

standards to be implemented on the HTI have to

be adjusted annually. According to statistics of

CERT

, in the ﬁrst quarter of 2007, there have been

already 2,176 vulnerabilities announced. Regarding

the estimated amount of more than 8,000 uncovered

vulnerabilities during one year, a shorter period for

adjusting the minimum security standards could

improve security.

Inadequate Assumption about the Security of the

Systems inside the HTI. In (Gematik, Gesellschaft

ur Telematikanwendungen der Gesundheitskarte

mbH, 2006b, p. 60) it is mentioned, that all IT sys-

tems within the vpn provided by the HTI are consid-

ered to be secure. This argument is for example used

to justify the missing authentication concerning the

connection to the time servers of the HTI. As it is a

fact that there are no completely secure IT systems

this argument is not acceptable. Also IT systems con-

trolled and maintained by the HTI itself are vulner-

able for example to malware, social engineering at-

tacks, and so on.

Inconsistent with the claim cited above, in

(Gematik, Gesellschaft f

ur Telematikanwendungen

der Gesundheitskarte mbH, 2007, p. 32), it is noted,

that it is not possible to completely avoid threats and

that there will continuously emerge new threats.

Security by Obscurity. In (Gematik, Gesellschaft

ur Telematikanwendungen der Gesundheitskarte

mbH, 2007, p. 246), the Gematik claims, that security

by obscurity is not a proper approach securing IT sys-

tems. Nevertheless, the software used for eHC pur-

poses is classiﬁed as highly conﬁdential in the same

document. This classiﬁcation results from parts of the

software being intellectual property of the developing

companies. Of course, copyright issues have to be re-

garded in the eHC environment as well, but also Shan-

non’s maxime and Kerckhoff’s principle

should be

considered.

Thus, at least these parts of the eHC related IT

systems, which contain security relevant processes,

http://www.cert.org/stats

cp. (Huber et al., 2008, p. 10)

cp. requirement 002.So.A.AS in (Huber et al., 2008)

should be published completely and not kept secret

to ensure intelectual property.

4.4.2 Analysis of the Connector

Imprecise Speciﬁcation of the Blacklist Manage-

ment. In the security concept of the Gematik, it is

deﬁned, that each Connector has to validate the cer-

tiﬁcate of the vpn concentrator of the central part of

the HTI

. In this context, blacklists are used to iden-

tify Connectors with revoked certiﬁcates, which have

to be updated periodical (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2007, p. 63). Besides this deﬁnition, no further infor-

mation about implementation and handling of black-

lists can be found in any of the considered documents.

One of the most important issues is, where the Con-

nector retrieves the blacklist information from. they

can obviously not be provided by a server inside of

the HTI, as fetching the blacklist information would

come along with connecting to a potentially inse-

cure vpn concentrator. Furthermore, there are several

authentication requirements concerning the blacklist

service, which have obviously not been considered

yet. If insufﬁcient authentication is used, an attacker

could claim to be a blacklist-server and thus provide

fake blacklists containing some or even all vpn con-

centrators of the HTI. Establishing such an attack, the

HTI would not be reachable any more because of all

of its vpn concentrators being blacklisted by an at-

tacker.

Imprecise Speciﬁcation of the Trusted Viewer In-

terface. According to (SigG, 2001, 2, no. 11 re-

spectively 17, para. 2) and (SigV, 2001, 15, para. 1c,

2a and 2b) the Connector has to provide a trustworthy

component - a so called Trusted Viewer component -

, which enables the veriﬁcation of signatures and the

signed content. There are two possibilities of imple-

menting this component. On the one hand, the Con-

nector can contain a build in Trusted Viewer device,

on the other hand, a Trusted Viewer component can

be included as a separate component accessing an ad-

equate Connector interface over the LAN.

Concerning the implementation of the Trusted

Viewer and its interface, conﬂicting details can

be found in the speciﬁcation document (Gematik,

Gesellschaft f

ur Telematikanwendungen der Gesund-

heitskarte mbH, 2006b). On the one hand, it is postu-

lated, that every Connector has to implement an inter-

face for the Trusted Viewer no matter if it has a built

in Trusted Viewer component or not (cp. (Gematik,

Gesellschaft f

ur Telematikanwendungen der Gesund-

heitskarte mbH, 2006b, p. 21)), on the other hand, the

cp. ﬁg. 1

ICEIS 2008 - International Conference on Enterprise Information Systems

150

Connector has to implement the Trusted Viewer in-

terface only if it does not contain a Trusted Viewer

component on its own (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2006b, p. 45 and p. 136).

Security Issues Concerning the Communication

with the Trusted Viewer. Between Connector and

Trusted Viewer, all communication has to be se-

cured by SSL according to (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2007, p. 172)

, (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2007, p. 137)

and (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2006b, p. 137)

. In (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2006b, p. 137), it is mentioned, that the Trusted

Viewer will most likely be implemented as a sepa-

rate piece of software. Thus it would reputedly not

be a security improvement to provide the this com-

ponent with an own identity. According to this, the

Trusted Viewer will de facto have no own identity

which implies, that authentication between Connec-

tor and Trusted Viewer will be if at all one-sided, sup-

porting man-in-the-middle attacks.

Nevertheless, in case there would be a two-way

authentication, it might be possible, to use fake cer-

tiﬁcates for a man-in-the-middle attack between Con-

nector and Trusted Viewer. So far, it is not speciﬁed,

how the Trusted Viewer should verify the Connector’s

certiﬁcate and vice versa. Fourthermore it is not spec-

iﬁed what happens, if a man in the middle attack be-

tween Connector and Trusted Viewer is established

with fake certiﬁcates. Will the user be prompted that

the certiﬁcate is fake? Where will he be prompted?

How can be assured, that a user does not ignore the

warning?

The worst case of a successful man-in-the-middle

attack according to this issue could for example be the

forgery of prescriptions.

A possible man-in-the-middle attack scenario

based on the weakness described above can be found

at (Huber et al., 2008, p. 73)

Security Issues Concerning the Communication

with the Primary System. The problems illus-

trated in 4.4.2 can partially be adopted for the com-

munication between Primary System and Connec-

tor. In none of the regarded documents, there can

be found any requirement concerning an authentica-

tion between these two components besides the gen-

cp. requirement 005.In.K.AS in (Huber et al., 2008)

cp. requirement 011.Vt.K.AS in (Huber et al., 2008)

cp. requirement 026.In.K.AS in (Huber et al., 2008)

erally postulated use of SSL for the communication

between components in the decentral part of the HTI

(cp. (Gematik, Gesellschaft f

ur Telematikanwendun-

gen der Gesundheitskarte mbH, 2007, p. 172)

(Gematik, Gesellschaft f

ur Telematikanwendungen

der Gesundheitskarte mbH, 2007, p. 137)

and

(Gematik, Gesellschaft f

ur Telematikanwendungen

der Gesundheitskarte mbH, 2006b, p. 137)

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

mary System to provide its own identity. The missing

or just one-sided authentication enables the establish-

ment of man-in-the-middle attacks between Connec-

tor and Primary System.

Even if there was an authentication between Pri-

mary System and Connector, at least the Primary Sys-

tem could not verify the Connectors identity. There-

fore, the Primary System would have to verify the

identity by using some kind of service, provided by

the HTI. According to (Gematik, Gesellschaft f

Telematikanwendungen der Gesundheitskarte mbH,

2007, p. 177), the direct access of the HTI by a Pri-

mary 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.

4.4.3 Analysis of the Primary System

Insufﬁcient Classiﬁcation of the Data Processed.

Acoording to (Neeb et al., 2004, p. 21), the secu-

rity level of the data processed by a Primary System

is classiﬁed as low or medium. The requirements of

these levels are allegedly covered by the security mea-

sures of an actual Primary System. According to the

classiﬁcation of IT-Grundschutz

, the abuse of the

concerning data would result amongst others in the

following:

• the abuse would have only marginal legal conse-

quences

• the effects on the social position and the ﬁnancial

circumstances of the person concerned would be

insigniﬁcant

• the tolerable downtime of the Primary System

would be 24 hours

cp. requirement 005.In.K.AS in (Huber et al., 2008)

cp. requirement 011.Vt.K.AS in (Huber et al., 2008)

cp. requirement 026.In.K.AS in (Huber et al., 2008)

http://www.bsi.de/gshb/index.htm

SECURITY ANALYSIS OF THE HEALTH CARE TELEMATICS INFRASTRUCTURE IN GERMANY

151

• the ﬁnancial loss of the institution using the Pri-

mary System would be tolerable

It is obvious, that the tolerable downtime of sys-

tems in the healthcare sector is in most cases not as

long as 24 hours. Hospitals deﬁnately can not 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 exam-

ple the anamnesis of a person in the hands of his or

her employer or insurance company.

Unassigned Assumption about the Presence of Se-

curity Measures Provided by Present Primary Sys-

tems. According to (Neeb et al., 2004, p. 21), the

security measures used in a present Primary Systems

are sufﬁcient to assure the postulated level of security

for the processed data, which is classiﬁed as normal

based on the categorisation of IT-Grundschutz

To verify this claim, some of the major manufac-

turers of Primary Systems have been asked wheter

they provide for example encryption of sensitive data

or role based and password protected user access. 4

of 17 addressed companies answered and conﬁrmed

to provide some kinds of security measures in their

products. So on the one hand, the claim has been ver-

iﬁed, but on the other hand, the question comes up

why the remaining companies did not respond at all

and whether this behaviour is related to providing se-

curity features or not.

In contrast to the four companies providing secu-

rity 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 encryp-

tion features (cp. (facharzt.de, 2005)).

4.4.4 Analysis of the Card Reader

As the used card reader is a Secure Interopera-

ble ChipCard Terminal(SICCT) standardised, self-

contained piece of hardware, its development is not

part of the eHC development process and thus it

would be no beneﬁt to analyse it in detail. The ter-

minals are being analysed during their development

and certiﬁcation 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 certiﬁcate, the com-

munication between other components and the card

reader can be secured by a strong authentication. Fur-

thermore, the card reader is sealed physically, so ma-

nipulation attempts can be detected easily.

Nevertheless, a practical analysis of this compo-

nents might be interesting as thus, for example imple-

http://www.bsi.de/gshb/index.htm

mentation deﬁciencies could be uncovered. As men-

tioned in 4.5, no card terminal was actually available

for analysing activities, so these actions have to be

done in future work.

4.4.5 Attack-Tree Analysis

As one tool of step three in the developed analysis

approach, an Attack-Tree Analysis has been made to

identify the most likely and easy attacks. Within the

analysis, Attack-Trees for each of the components de-

spite of the Primary System have been made. The Pri-

mary Systems were excluded from this analysis step

due to the different kinds of available Primary Sys-

tems. There is no standardised Primary System due

to the freedom of each manufacturer to implement a

Primary System in his favourite way.

The result of the Attack-Tree analysis were two

large Attack-Trees for the Connector and the card ter-

miinal including over 600.000 attack-scenarios each.

The Attack-Trees can be used for further work,

when the related components are present. Concern-

ing the work in (Huber et al., 2008), it emerged, that

attacks on a technical level are mostly very expen-

sive or out of scale regarding the expenditure of time.

As also some non or semi-technical ways to achieve

an attackers goal have been included in the Attack-

Tree Analysis for completeness, it showed up, that the

most likely attacks are the ones using bribing, black-

mailing or spying out conﬁdential information like ac-

cess data. These attacks in turn are typical for attack-

ers belonging to the groups of organised crime and

terrorism as mentioned in 4.2.

4.5 Analysis of the

Components-Practical Level

At the beginning of the analysis in november 2006, it

was planned to have some prototypes of the concern-

ing components for analysing purposes within a few

weeks. Unfortunately, just until the end of the analy-

sis process, no hard- or software components usable

for practical tests were available, mainly due to delays

within the development process. Thus, none of the

steps, planned for practical analysis activities could

be executed and none of the revealed issues could be

approved by further practical tests.

5 CONCLUSIONS AND

OUTLOOK

In the course of the present work, a new approach was

developed, to ﬁt the needs of a security analysis from

a technical point of view. This approach based on ISO

ICEIS 2008 - International Conference on Enterprise Information Systems

152

27001, was used to analyse the components Connec-

tor, Primary System, Card Terminal and some of their

interaction processes wihtin the HTI. As a result of

the analysis, 14 deﬁciencies could be revealed, in-

cluding weaknesses, inconsistent and conﬂicting de-

velopment documents and violation of security de-

mands.

For future work, the analysis offers various start-

ing points such as the constructed Attack-Trees or the

revealed weaknesses which can and should be veriﬁed

in practice as soon as the considered components are

physically available for testing purposes.

REFERENCES

Anderson, R. (2001). Security Engineering: A Guide to

Building Dependable Distributed Systems. Wiley &

Sons, 1 edition.

BDSG (2003). Bundesdatenschutzgesetz in der Fassung

der Bekanntmachung vom 14. Januar 2003 (BGBl. I

S. 66), zuletzt ge

andert durch Artikel 1 des Gesetzes

vom 22. August 2006 (BGBl. I S. 1970).

BSI, British Standards Institution (1999). BS 7799-

2 1999 Management von Informationssicherheit :

Teil 2: Speziﬁkation fr Informationssicherheits-

Managementsysteme.

BSI, Bundesamt f

ur Sicherheit in der Informationstechnik

(2004). Studie zu ISO-Normungsaktivitten ISO/BPM

- Anforderungen an Information Security Manage-

ment Systeme.

facharzt.de (2005). Datenschutzbeauftragter Schaar zur

eCard: Es gibt keine 100prozentige Sicherheit. Inter-

view von facharzt.de mit dem Bundesbeauftragten f

den Datenschutz und die Informationsfreiheit (BfDI)

Peter Schaar am 21.09.2005. facharzt.de.

Gematik, Gesellschaft f

ur Telematikanwendungen der

Gesundheitskarte mbH (2005a). Gematik Fachmod-

ell. Version 0.9.

Gematik, Gesellschaft f

ur Telematikanwendungen der

Gesundheitskarte mbH (2005b). Gesamtarchitektur -

Kryptographische Ziele der Telematik. Version 1.0.

Gematik, Gesellschaft f

ur Telematikanwendungen der

Gesundheitskarte mbH (2006a). Einf

uhrung der

Gesundheitskarte - Gesamtarchitektur. Version 0.2.0.

Gematik, Gesellschaft f

ur Telematikanwendungen der

Gesundheitskarte mbH (2006b). Einf

uhrung der

Gesundheitskarte - Konnektorspeziﬁkation. Teil 1 -

Allgemeine Funktionen und Schnittstellen des Kon-

nektors. Version 0.6.0.

Gematik, Gesellschaft f

ur Telematikanwendungen der

Gesundheitskarte mbH (2006c). Einf

uhrung der

Gesundheitskarte - Speziﬁkation Infrastrukturkompo-

nenten: Zeitdienst. Version 1.0.0.

Gematik, Gesellschaft f

ur Telematikanwendungen der

Gesundheitskarte mbH (2007).

Ubergreifendes

Sicherheitskonzept der Telematikinfrastruktur. Ver-

sion 1.9.0.

Gerloni, H., Oberhaitzinger, B., Reier, H., and Plate, J.

(2004). Praxisbuch Sicherheit f

ur Linux-Server und

Netze. Carl Hanser Verlag, M

unchen Wien.

Gollmann, D. (2006). Computer Security. Wiley, 2nd edi-

tion.

Haux, R. (2005). Health information systems - past,

present, future. International Journal of Medical In-

formatics, 75:268–281.

Heeks, R. (2006). Health information systems: Failure, suc-

cess and improvisation. International Journal of Med-

ical Informatics, 75:125–137.

Huber, M., Sunyaev, A., and Krcmar, H. (2008). Arbeitspa-

pier 32 - Technische Sicherheitsanalyse der elektro-

nischen Gesundheitskarte. Technical report, Technis-

che Universit

at M

unchen, Lehrstuhl f

ur Wirtschaftsin-

formatik.

ITGI, IT Governance Institute (2007). Cobit 4.1.

Lorence, D. and Churchill, R. (2005). Incremental adop-

tion of information security in health-care organiza-

tions: implications for document management. In-

formation Technology in Biomedicine, IEEE Transac-

tions on, 9(2):169–173.

Neeb, J., Bunz, H., and Biltzinger, P. (2004). Erarbeitung

einer Strategie zur Einfhrung der Gesundheitskarte -

Sicherheitsanforderungen.

Schabetsberger, T., Ammenwerth, E., Andreatta, S., Gratl,

G., Haux, R., Lechleitner, G., Schindelwig, K., Stark,

C., Vogl, R., and Wilhelmy, I. (2006). From a paper-

based transmission of discharge summaries to elec-

tronic communication in health care regions. Inter-

national Journal of Medical Informatics, 75:209–215.

Schneier, B. (2004). Secrets and Lies : Digital Security in

a Networked World. Wiley.

Schweiger, A., Sunyaev, A., Leimeister, J., and Krcmar, H.

(2007). Information systems and healthcare xx: To-

ward seamless healthcare with software agents. Com-

munications of the Association for Information Sys-

tems, 19:692–709.

SGB (2007). Sozialgesetzbuch. DTV-Beck.

SigG (2001). Gesetz

uber Rahmenbedingungen f

ur elek-

tronische Signaturen (Signaturgesetz - SigG) - Sig-

naturgesetz vom 16. Mai 2001 (BGBl. I S. 876),

zuletzt ge

andert durch Artikel 3 Abs. 9 des Gesetzes

vom 7. Juli 2005 (BGBl. I S. 1970;

anderung durch

Art. 4 G v. 26.2.2007 I 179 zuk

unftig in Kraft).

SigV (2001). Verordnung zur elektronischen Signatur (Sig-

naturverordnung - SigV) - Signaturverordnung vom

16. November 2001 (BGBl. i S. 3074), ge

andert durch

Artikel 2 des Gesetzes vom 4. Januar 2005 (BGBl. I

S. 2).

StGB (2005). Strafgesetzbuch. DTV Deutscher Taschen-

buch Verlag.

SECURITY ANALYSIS OF THE HEALTH CARE TELEMATICS INFRASTRUCTURE IN GERMANY

153