Sicherheitsrisikoanalyse des HL7/FHIR Frame- works durch das OWASP … · 2017-06-09 · Eidesstattliche Erklärung „Ich, als Autor und Urheber der vorliegenden Arbeit, bestätige

MASTER THESISzur Erlangung des akademischen Grades„Master of Science in Engineering“im Studiengang Informationsmanagement und Computersicherheit

Sicherheitsrisikoanalyse des HL7/FHIR Frame-works durch das OWASP Risk Rating Model

Ausgeführt von: Markus Diepold, BScPersonenkennzahl: 1310303032

BegutachterInnen: FH-Prof. Dipl.-Ing. Alexander MenseIng. Philipp Urbauer, MSc

Wien, den 19. Mai 2015

Eidesstattliche Erklärung

„Ich, als Autor und Urheber der vorliegenden Arbeit, bestätige mit meiner Unterschrift die Kennt-nisnahme der einschlägigen urheber- und hochschulrechtlichen Bestimmungen (vgl. etwa §21,§46 und §57 UrhG idgF sowie §11 Satzungsteil Studienrechtliche Bestimmungen / Prüfungs-ordnung der FH Technikum Wien).

Ich erkläre insbesondere korrekt fremde Inhalte, gleich welcher Form, übernommen zu ha-ben und bin mir bei Nachweis fehlender Eigen- und Selbstständigkeit sowie dem Nachweiseines Vorsatzes zur Erschleichung einer positiven Beurteilung dieser Arbeit der Konsequenzenbewusst, die von der Studiengangsleitung ausgesprochen werden können (vgl. §11 Abs. 1 Sat-zungsteil Studienrechtliche Bestimmungen / Prüfungsordnung der FH Technikum Wien).

Weiters bestätige ich, dass ich die vorliegende Arbeit bis dato nicht veröffentlicht und wederin gleicher noch in ähnlicher Form einer anderen Prüfungsbehörde vorgelegt habe. Ich versi-chere, dass die abgegebene Version jener im Uploadtool entspricht.”

Wien, 19. Mai 2015 Unterschrift

Kurzfassung

Health Level 7 (HL7) ist eine führende internationale Standardisierungsorganisation im Be-reich Medizindatenaustausch. Im Rahmen des Projektes Fast Healthcare Interoperability Re-sources (FHIR) setzen die Experten auf moderne Internettechnologien wie RepresentationalState Transfer (REST) Webservices und die Datenübertragung in JavaScript Object Notati-on (JSON) oder Extensible Markup Language (XML). Dadurch werden aber natürlich eine Rei-he von Sicherheitsherausforderungen aus dem Bereich der Webapplikationssicherheit schla-gend.

Diese Masterthese gibt einen technischen Einblick in das Konzept von FHIR, und analysiert dasFramework in Bezug auf mögliche Sicherheitsschwachstellen. Dabei wird von einer ganzheit-lichen Betrachtung einer FHIR Implementierung ausgegangen. Für die Risikobewertung wirdauf ein bekanntes Bewertungssystem des Open Web Application Security Project (OWASP),dem OWASP Risk Rating Model zurückgegriffen. Alle im FHIR Framework und im RESTfulApplication Programming Interface (API) identifizierten Risiken werden erhoben, bewertet undpriorisiert in eine Risikoliste aufgenommen. Diese Liste fasst die gewonnen Erkenntnisse undEmpfehlungen für eine sichere Implementierung sozusagen als „Best Practice“ zusammen, undsteht für technisches Personal bei einer etwaigen Umsetzung zur Verfügung. Um eine korrek-te Bewertung zu garantieren, wurde die Analyse exakt nach der Methodik des Risikomodellsdurchgeführt.

Die Arbeit verweist zudem auf gewünschte Schutzziele in der Informationstechnologie, sowieempfohlene Sicherheitskonzepte für die Kommunikation sensibler Gesundheitsinformationen,und gibt dabei Aufschluss inwiefern das FHIR Framework diesen Zielen gerecht wird.

Schlagworte: RESTful Webservices, REST API, JSON, XML, OWASP Top 10, OWASP RiskRating Model, IT Security, Sicherheitslücken, Schutzziele

Abstract

Health Level 7 (HL7) is an international standardization organization in the field of medical he-althcare information interchange. One of the newest projects from the Health Level 7 (HL7)experts is Fast Healthcare Interoperability Resources (FHIR). It is based on popular and mo-dern web technologies such as Representational State Transfer (REST) web services and usesJavaScript Object Notation (JSON) and Extensible Markup Language (XML) as a format fordata exchange.

This paper focuses on the concept of FHIR and analyses the framework for security vulnerabili-ties. The OWASP risk rating model is used for the quantification of all security issues which arefound. All risks are added in a risk list, calculated and sorted by priority. This list can be seenas best practice document to avoid security issues during an FHIR implementation. The ratingmethod follows the exact instructions of the rating model to allow correct ratings.

Additionally this thesis points out common security targets in modern web applications, andespecially on applications carrying sensitive medical data. Finally, it summarizes to what ex-tend the IHE FHIR Framework fulfills these targets.

Keywords: restful web services, rest api, json, xml, owasp top 10, owasp risk rating model,web security, vulnerabilities

Danksagung

"In den letzten fünf Jahren meines Lebens habe ich durch meine beiden berufsbegleitendenStudien (Bachelor und Master an der Fachhochschule Technikum Wien) sehr viele aufregendeErfahrungen gesammelt, tolle Menschen kennengelernt und mich vom Fachwissen und demErfahrungsschatz meiner ProfessorInnen inspirieren lassen. Ganz besonders bedanken möch-te ich mich bei meinem Betreuer FH-Prof. Dipl.-Ing. Alexander Mense für die Unterstützung undfür die vielen Ideen zu meiner Master Arbeit, die allesamt notwendig und vor allem richtungs-weisend für mich waren.

Bedanken möchte ich mich bei meinen MitkommilitonInnen für die vielen Erfahrungen und Mei-nungen aus den unterschiedlichsten Bereichen der Informationstechnologiebranche, durch diedieses Studium erst so richtig abgerundet und angenehm für mich wurde. Hier sei vor allemMarkus genannt, der mich in den letzten Monaten, und vor allem beim Schreiben dieser Ar-beit durch viele spannende Diskussionen immer wieder zum Nachdenken gebracht hat. Diedadurch entstandene Freundschaft möchte ich nicht missen.

Und mein Dank gilt meinen Eltern sowie meiner gesamten Familie, die mich in dieser Zeit im-mer unterstützt hat, und mich in schweren und anstrengenden Momenten zum Weitermachenermutigt hat. Allen voran möchte ich aber meiner Lebensgefährtin Sandra danken, die immeran meiner Seite stand und ein offenes Ohr und ein offenes Herz während dieser anstrengendenZeit hatte. Und ich möchte auch meiner kleinen Tochter Sophie Lena danken, neben der es mirin den letzten Monaten immer schwerer gefallen ist, mich nicht ablenken zu lassen, und die soeine Bereicherung in meinem Leben ist, dass ich es kaum erwarten kann, nach dem Studiummeiner Rolle als Familienvater mit mehr Zeit gerecht zu werden."

Markus Diepold (Wien, April 2015)

Inhaltsverzeichnis

1. Einleitung 11.1. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Einführung FHIR Framework 52.1. Flexibilität von FHIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Die vier Paradigmen der Interoperabilität von FHIR . . . . . . . . . . . . . . . . . 62.3. Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4. Ressourcenkatalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1. Clinical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2. Administrative Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.3. Infrastructure Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5. Ressourcendefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.1. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.2. UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.3. Ressourcengruppen (Bundles) . . . . . . . . . . . . . . . . . . . . . . . . 112.5.4. Fächer (Compartments) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.5. Arten von Ressourcenreferenzen . . . . . . . . . . . . . . . . . . . . . . . 12

2.6. Aufbau von FHIR Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7. Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7.1. Datentyp simple/primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7.2. Datentyp complex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7.3. Sonstige Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8. Nachrichtendefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.8.1. Marker (Tags) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.8.2. Sicherheitsbeschreibungen / Security Labels . . . . . . . . . . . . . . . . 21

3. REST(ful) API 253.1. Interaktionen auf konkrete Instanzen von Ressourcen . . . . . . . . . . . . . . . 25

3.1.1. read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2. vread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.3. update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.4. delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.5. validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.6. history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2. Interaktionen auf unbekannte Instanzen von Ressourcen . . . . . . . . . . . . . 283.2.1. create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.2. search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.3. history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3. Sonstige Interaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.1. conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2. transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4. Interaktionstabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5. Die Such-API (Search/Query) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5.1. Allgemeine Suchparameter . . . . . . . . . . . . . . . . . . . . . . . . . . 353.5.2. Suchparameter Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5.3. Verkettung von Suchparametern . . . . . . . . . . . . . . . . . . . . . . . 393.5.4. Verknüpfung von Suchabfragen . . . . . . . . . . . . . . . . . . . . . . . . 393.5.5. Antworten auf Suchanfragen . . . . . . . . . . . . . . . . . . . . . . . . . 403.5.6. PUSH vs PULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4. Sicherheit in FHIR 434.1. Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2. Kommunikationssicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3. Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4. Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5. Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6. Digitale Signaturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.7. Sicherheit von Anhängen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.8. Sicherheit beim Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5. Analyse der geforderten Schutzziele 525.1. Schutzziel der Authentizität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2. Schutzziel der Datenintegrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.3. Schutzziel der Informationsvertraulichkeit . . . . . . . . . . . . . . . . . . . . . . 545.4. Schutzziel der Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5. Schutzziel der Verbindlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.6. Schutzziel der Anonymisierung und Pseudomisierung . . . . . . . . . . . . . . . 555.7. Übersichtstabelle geforderte Schutzziele . . . . . . . . . . . . . . . . . . . . . . . 56

6. Open Web Application Security Project (OWASP) 576.1. OWASP Risk Rating Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.1. Finden von Bedrohungen (Threat Modeling) . . . . . . . . . . . . . . . . . 58

6.1.2. Berechnungsmodell Eintrittswahrscheinlichkeit . . . . . . . . . . . . . . . 606.1.3. Berechnungsmodell Auswirkung (Factors for Estimating Impact) . . . . . 616.1.4. Berechnung des Gesamtrisikos . . . . . . . . . . . . . . . . . . . . . . . . 626.1.5. Umgang mit Bedrohungen . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1.6. Adaptierung des Risikomodells . . . . . . . . . . . . . . . . . . . . . . . . 646.1.7. Alternative Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2. OWASP Top 10 Liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.2.1. A1 - Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.2.2. A2 - Broken Authentication and Session Management . . . . . . . . . . . 676.2.3. A3 - Cross-Site Scripting (XSS) . . . . . . . . . . . . . . . . . . . . . . . . 686.2.4. A4 - Insecure Direct Object References . . . . . . . . . . . . . . . . . . . 696.2.5. A5 - Security Misconfiguration . . . . . . . . . . . . . . . . . . . . . . . . 706.2.6. A6 - Sensitive Data Exposure . . . . . . . . . . . . . . . . . . . . . . . . . 716.2.7. A7 - Missing Function Level Access Control . . . . . . . . . . . . . . . . . 726.2.8. A8 - Cross-Site Request Forgery (CSRF) . . . . . . . . . . . . . . . . . . 736.2.9. A9 - Using Known Vulnerable Components . . . . . . . . . . . . . . . . . 746.2.10. A10 - Unvalidated Redirects and Forwards . . . . . . . . . . . . . . . . . 75

6.3. Durchführung der Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.4. Ergebnisse der Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.5. Weitere Betrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7. Conclusio 837.1. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Literaturverzeichnis 85

Abbildungsverzeichnis 95

Tabellenverzeichnis 96

Quellcodeverzeichnis 98

Abkürzungsverzeichnis 100

A. Quellcodes 103

B. Weitere Abbildungen 112

C. Identifizierte Threats 113

D. Analysematrix 117

E. HTTP Status Codes 121

F. OWASP Full Attack List 123

1. Einleitung

Fast Healthcare Interoperability Resources (FHIR)1 ist ein geplanter Standard von Health Level7 (HL7)2. Der neuartige Ansatz dabei ist es, die Vorteile der derzeitigen Standards HL7v2[43]HL7v3[44] und Clinical Document Architecture (CDA)[41] zu vereinen, ohne deren Nachteilemitzunehmen. Die Vorteile dieser Formate liegen auf der Hand. Rund 95% aller US Gesund-heitsdienstleister verwenden HL7 in der Version 2.x. In über 35 Ländern gibt es Nationale Nie-derlassungen in Form von HL7 Zweigstellen[43]. Weite Verbreitung, langjährige Implementie-rung in unterschiedlichsten Systemen vieler Hersteller und ausgereifte Schnittstellen machtenHL7 und CDA in den letzten Jahren zum de facto Standard in der medizinischen Kommunikati-on.

Aber eben diese sehr ausgereiften und speziell für die jeweiligen Anwendungen spezifizier-ten Nachrichtenformate sind auch gleichzeitig der Nachteil. Veränderungsprozesse können nurschwer abgebildet werden. Die weite Verbreitung hat gravierende Folgen, sollten sich die For-mate ändern. Genau hier tritt FHIR an, mit dem Ziel einer möglichst einfachen Implementie-rung, um komplexe Anforderungen der Interoperabilität zu optimieren und den notwendigenAufwand zu minimieren. Dabei setzt es auf weit verbreitete Internettechnologien wie Repre-sentational State Transfer (REST)[25] und Standard Nachrichtenformate wie JavaScript ObjectNotation (JSON)[17][9] und Extensible Markup Language (XML)[10][8][98][97] für den Daten-austausch.

Ziel dieser Master These ist die Bewertung der Sicherheitsrisiken[21] dieses neuen Frame-works. Um alle Risiken korrekt zu bewerten, ist es neben dem geeigneten Bewertungsmo-dell, dem OWASP Risk Rating Model[89], auch notwendig, alle technischen Rahmenbedingun-gen, Funktionalitäten und Konzepte zu ermitteln, um einen korrekten Risikobewertungsprozessüberhaupt abbilden zu können. Sobald alle Rahmenfaktoren bekannt sind, wird die eigentli-che Bewertung durchgeführt, die Risiken werden quantifiziert und abschließend als priorisierteAufgabenliste abgebildet. Sie können als „Best Practices“ Anleitung für die sichere Implemen-tierung herangezogen werden, und stehen somit für technisches Personal bei einer etwaigenUmsetzung zur Verfügung.

Nicht Ziel ist die tatsächliche Umsetzung einer funktionierenden FHIR Installation, wenn-gleich für die praktische Analyse einige Teilfunktionen auch implementiert und getestet wurden.Somit richtet sich diese Arbeit vorwiegend an technisches Personal, welches mit der Umset-zung von derartigen Kommunikationslösungen beauftragt wird. Die jeweiligen Bereichsverant-wortlichen (Datenbank, Webserver, Applikationsserver, Middleware etc.) sollen dabei die für

1http://www.hl7.org/FHIR/ [Zugang am 19.04.2015]2http://www.hl7.org/ [Zugang am 23.02.2015]

1

http://www.hl7.org/FHIR/

http://www.hl7.org/

sie relevanten Informationen nutzen können, um eine sichere und fehlerlose Implementierungdurchzuführen.

1.1. Aufbau der Arbeit

Für eine ordnungsgemäße Bewertung der Risiken ist es unerlässlich, dass entsprechend einemfestgelegten Procedere vorgegangen wird, um korrekte Ergebnisse zu erzielen. Daher wirdgleich zu Beginn in Kapitel 2 der Fokus auf die genaue Betrachtung der einzelnen Komponentengerichtet. Alle verwendeten Datentypen, Nachrichtendefinitionen, Ressourcendefinitionen undRessourcenkataloge werden aufgezeigt und erklärt. Im Anschluss an diese Basisdefinitionenerklärt das Kapitel 3 das REST(ful) Application Programming Interface (API) und zeigt nebenden verwendeten Methodenaufrufen auch die Möglichkeiten der Datenmanipulation auf. Zudemwird das eigens in FHIR implementierte API für die Dokumentensuche betrachtet und dessenFunktionsweise erörtert. Mit diesen beiden Kapiteln ist sozusagen die Basisfunktionalität vonFHIR erklärt.

Im nächsten Schritt widmet sich die Arbeit der generischen Sicherheitsbetrachtung von FHIR.In Kapitel 4 werden alle in FHIR definierten Sicherheitsmerkmale und deren Funktion beschrie-ben, und die möglichen Varianten einer Implementierung aufgezeigt. Kapitel 5 vergleicht an-schließend diese in FHIR bereits enthaltenen Sicherheitsfunktionen und überprüft sie auf die inder Informationssicherheit typischerweise geforderten Schutzziele.

Das Kapitel 6 widmet sich ganz dem Open Web Application Security Project (OWASP).Zuerst wird das OWASP Risk Rating Model vorgestellt und erklärt, anschließend wird auf dieOWASP Top 10[82] Liste im Detail eingegangen. Mit dem Wissen der Risikobewertungsme-thode und der Top 10 Liste, wird für jede einzelne Funktionalität im FHIR Framework ein Wertfür ein potentielles Risiko errechnet, und dieser in eine priorisierte Liste eingetragen. Diese Li-ste ist gleichzeitig als Empfehlung zur Beachtung einer sicheren Implementierung von FHIR zuverstehen.

Zum Schluss wird noch ein Fazit über das Analyseergebnis erstellt, und Möglichkeiten zurweiteren Vertiefung in Form von weiteren Arbeiten aufgezeigt.

1.2. Related Work

Im Juni 2010 wurde eine wissenschaftliche Arbeit mit dem Titel ”Threat Modeling - Perhapsit is Time” in der IEEE Security & Privacy Zeitschrift veröffentlicht, die sich auch mit der wis-senschaftlichen Bewertung von Angriffsvektoren auseinandersetzt[104]. Der Autor John Stevenvertritt dabei die Kernaussage, dass es viel einfacher ist, Sicherheitslücken durch definierte in-terne Prozesse zu finden, als es von außen möglich ist.

In a nutshell, the inside-out view that threat models provide simply gives more visi-bility than outside-in blackbox assessments.

2

[104, Seite 83]

In seinem Paper verweist er dabei auf den Threat-Modeling Prozess von Microsoft[70], derseines Erachtens nach sehr professionell aufgesetzt und spezifiziert ist. Die Hauptpunkte indiesem Modell sind das Auffinden von sicherheitsrelevanten Objekten (identify security objec-tives), die generische Betrachtung der zu bewertenden Software (create an application over-view), und die daraufhin folgende Detailbetrachtung der Funktionalitäten (decompose your ap-plication). Anschließend sind daraus resultierende Bedrohungen abzuleiten (identify threats)und dadurch die eigentlichen Verwundbarkeiten aufzufinden und zu beziffern (identify vulnera-bilities). Zudem beschreibt er darin den notwendigen Prozess ganz allgemein:

Threat modeling is the process of enumerating and risk-rating malicious agents,their attacks, and those attacks’ possible impacts on a system’s assets.

[104, Seite 83]

Gerade weil FHIR noch in der Entwicklung ist, gibt es nicht viele wissenschaftliche Arbei-ten, die sich damit überhaupt auseinandergesetzt haben. Das Paper ”HL7 FHIR: An Agile andRESTful Approach to Healthcare Information Exchange” vergleicht das FHIR Konzept mit denbereits bestehenden Standards HL7v2[43] und HL7v3[44]. Zusammengefasst ist der Vorteilvon FHIR, also der agile Ansatz mittels Ressourcen die Komplexität von HL7 über flexible Res-sourcen zu minimieren, auch gleichzeitig dessen Nachteil: Prozesse und Arbeitsabläufe in derMedizin sind sehr komplex, und hier bestehen zumindest begründete Zweifel, ob dieser einfa-che Ansatz von FHIR überhaupt in der Lage ist, derartige Funktionalitäten gänzlich abzubilden.

As a resource oriented environment FHIR allows for very simple implementation ofbase artifacts, their transmission and persistence. However there is very little gui-dance as to how these base resources are to be constructed into larger collectionsand relationships. There is also no support for workflow and dynamic behaviour.This may become an area of divergence leading to a lack of interoperability.

[4, Seite 329]

Im Paper wird FHIR aber vor allem als Möglichkeit betrachtet, medizinische Informationenauch über Systemgrenzen hinweg zu transportieren, wenn auch möglicherweise in einer et-was eingeschränkten Art und Weise, was einem hybriden Modell gleichkommen würde, in demdie bestehenden Schnittstellen belassen werden, und zusätzlich über FHIR Informationen zumBeispiel mit einem Patienten ganz einfach über Webservices oder Mobile Apps ausgetauschtwerden können.

Und genau hier setzt diese Arbeit an. Das Internet und damit verbundene Webservices bietenviele Möglichkeiten, Informationen auszutauschen. Gerade sensible Daten wie Gesundheits-informationen müssen daher besonders geschützt werden. Diese Arbeit analysiert in einem

3

definierten Prozess die Risikofaktoren, welche das FHIR Framework bereits durch seine Funk-tionalität und sein Design beinhaltet und leitet mittels methodischer Betrachtung aller Angriffs-vektoren daraus resultierende Risiken ab. Die Methode richtet sich am OWASP Risk RatingModel aus, welches in Kapitel 6.1 noch genauer beschrieben wird.

Eine andere aktuelle Arbeit über FHIR, das Paper ”Formal Reliability Analysis of a TypicalFHIR Standard based E-Health System using PRISM” welches auf der IEEE HEALTHCOM2014 veröffentlicht wurde[96][95], befasst sich primär mit der Analyse von FHIR als zentralesskalierbares Echtzeit-Kommunikationssystem. Diese Betrachtung liegt aber nicht im Fokus die-ser Arbeit.

1.3. Methodik

Der Kernpunkt dieser Arbeit besteht in einer Sicherheitsrisikoanalyse des FHIR Frameworks.Für die Risikoanalyse wird auf ein etabliertes Modell, das OWASP Risk Rating Model zurückge-griffen. Dieses Modell definiert sehr exakt alle notwendigen Schritte, um zu einer umfassendenGesamtbetrachtung der Verwundbarkeiten und deren Auswirkungen zu gelangen.

Für eine exakte und korrekte Bewertung ist es notwendig, das zu bewertendes System, dasFHIR Framework mitsamt aller ihm zugrundeliegenden Komponenten, Funktionen, Modalitäten,Arbeitsabläufe zu kennen. Zusätzlich muss auch eine exakte Betrachtung aus der Sicht einesmöglichen Angreifers durchgeführt werden. Was sind beispielsweise seine Möglichkeiten oderBeweggründe?

Für die eigentliche Bewertung geht diese Arbeit daher sehr genau auf das Konzept und dieArbeitsweise des FHIR Frameworks ein. Wie sehen FHIR Nachrichten aus, wie laufen Kommu-nikationen ab, wo sind die Angriffspunkte? Wie sehen die Schnittstellen aus? Derartige Fragenwerden in dieser These beantwortet, um die Basis für eine Sicherheitsbetrachtung zu schaffen.Zum besseren Verständnis der möglichen Perspektive eines Angreifers, geht die Arbeit sehrgenau auf die OWASP Top 10 ein, eine Liste der zehn häufigsten Schwachstellen in Weban-wendungen. Andererseits wird auch das OWASP Risk Rating Model sehr exakt erörtert, umFehler in der eigentlichen Bewertung zu vermeiden.

Nach der Durchführung der Bewertung werden die Daten analysiert und interpretiert. Alleeruierten Messwerte werden mittels mathematischer und statistischer Methoden zudem aufPlausibilität hin überprüft.

Am Ende der Arbeit muss verständlich sein, warum diese Messwerte wichtig sind, welchemZweck sie dienen, wie sie entstanden sind und was sie aussagen.

4

2. Einführung FHIR Framework

FHIR steht für Fast Healthcare Interoperability Resources, und ist wie der Name schon sagt mitdem Ziel angetreten, schnelle und einfache Interoperabilität in medizinischen Anwendungen zuermöglichen. Das primäre Ziel ist es nicht die bestehenden Formate HL7v2, HL7v3 und vor al-lem CDA gänzlich abzulösen, sondern einfachen und schnellen Datenaustausch über System-grenzen hinweg zu ermöglichen. Dabei wird ausschließlich auf etablierte Webstandards undTechnologien wie zum Beispiel XML, JSON, HyperText Transfer Protocol (HTTP), HyperTextTransfer Protocol Secure (HTTPS), Atom Syndication Format (ASF), Atom Publishing Proto-col (APP) oder OAuth gesetzt, um einige exemplarisch zu nennen. Für die eigentliche Kommu-nikation von Nachrichten und Dokumenten werden REST(ful) Webservices verwendet.

2.1. Flexibilität von FHIR

Die große Herausforderung beim globalen Austausch von medizinischen Daten ist die hoheKomplexität. Bei bestehenden Standards (HL7 und vor allem CDA) ist dabei jede Domäne(zum Beispiel Pathologie, Kardiologie, Augenheilkunde und weitere) spezifiziert, und sobaldsich Parameter ändern oder neue hinzukommen, müssen alle KommunikationsteilnehmerIn-nen ihre Schnittstellen adaptieren. Und hier setzt FHIR mit seinem neuen Ansatz an. FHIR istnach einer 80/20 Regel spezifiziert. Nur wenn eine Information für mehr als 80% der Benut-zerInnen relevant ist, sollte diese in der Spezifikation enthalten sein. Die restlichen 20% sollennur dort spezifiziert werden, so sie auch benötigt werden. Eine der Kernfunktionen von FHIRist es daher, dass jeder Sender eigene Spezifikationen erstellen kann, und diese neben deneigentlichen Nachrichten oder Dokumenten über dieselbe Kommunikationsschiene mit über-mittelt. Ein Sender kann sich somit seine eigenen Erweiterungen zum Standard definieren, undan beliebige Empfänger senden. Diese können die Definition nun auswerten, und die privatenErweiterungen verwenden. Zusätzlich sind natürlich alle Informationen des Standards, und dieNachricht selbst in einer vom Menschen lesbaren Version ebenfalls enthalten. Somit ist einemaximale Interoperabilität gewährleistet. Abbildung 1 zeigt die drei Bereiche im Dokumenten-aufbau in der Übersicht.

• Bereich 1: Eine Referenz auf die Definition der Ressource

• Bereich 2: Ein vom Menschen lesbarer Inhalt

• Bereich 3: Eine Reihe von Metadaten zur Weiterverarbeitung

5

Abbildung 1.: Beispielaufbau einer FHIR XML Ressource (Quelle: http://www.hl7.org/FHIR/shot.png)

2.2. Die vier Paradigmen der Interoperabilität von FHIR

Um das Ziel der einfachen Interoperabilität zu erreichen setzt FHIR auf vier Säulen (sieheAbbildung 2).

REST - Einfache Webservices für die Kommunikation.

Messages - Nachrichten bestehen aus Ressourcen und haben Ähnlichkeiten zu Nach-richten bestehender Standards wie HL7v2 und HL7v3. Mehrere Ressourcen können zueinem Bundle zusammengefasst werden

Documents - Dokumente bestehen ebenfalls aus solchen Bundles von Ressourcen. Sieähneln eher CDA Dokumenten.

Services - Werden durch Ressourcen beschrieben, und steuern das Verhalten des FHIRRepositories.

Ein FHIR Client kommuniziert zum Beispiel via REST Webservices mit einem FHIR Reposi-tory, ein Laborsystem schickt Nachrichten (Messages) an sein angeschlossenes Respository,und zwei unterschiedliche FHIR Repositories tauchen gegenseitig Dokumente (Documents)aus. In allen drei Fällen gelten die Regeln und Verhaltensweisen, die durch die Services be-schrieben werden.

6

Abbildung 2.: Die 4 Paradigmen der Interoperabilität (Quelle: http://www.corepointhealth.com/geni/interoperability-paradigms-hl7-fhir)

2.3. Ressourcen

Ressourcen sind die essentiellen Bausteine des FHIR Frameworks. Wie bereits erwähnt be-steht jede Ressource aus einer Extension die ihr Verhalten beschreibt, dem Narrative als les-baren Teil und den eigentlichen Elementen selbst, die ebenfalls wieder Erweiterungen habenkönnen (siehe Abbildung 3).

Abbildung 3.: Ressourcen in FHIR

Trotzdem ist nicht jedes Element in FHIR ist eine Ressource. Tabelle 1 zeigt, dass es Elemen-te gibt, die zu klein, zu groß oder zu allgemein sind, um innerhalb des FHIR Frameworks alsRessource definiert zu sein. Zur Erinnerung gilt wieder die 80/20 Regel. Nichts desto wenigersteht es jedem/jeder BenutzerIn frei, solche Elemente über die Erweiterungen (Extensions)selbst zu definieren.

2.4. Ressourcenkatalog

Der Ressourcenkatalog von FHIR unterteilt sich prinzipiell in drei Hauptgruppen: In die Klini-schen Ressourcen, deren Kernaufgabe die Aufzeichnung der klinischen Metadaten ist, und diesich in der Regel auf den Patienten bzw. das Institut beziehen. Administrative Ressourcen, diesich auf Personal oder das Institut selbst beziehen, und den Behandlungsablauf steuern. Und

7

Ressource Keine Ressource

Administrativ: Patient, Ort, Organisation Geschlecht: zu klein

Klinisch: Allergie, Untersuchung Blutdruck: zu spezifisch

Infrastruktur: Dokument, Nachricht, Profil Schwanger: zu allgemein

Gesundheitsakte: zu groß

Tabelle 1.: Was ist eine Ressource?

Infrastrukturelle Ressourcen, welche die Rahmenbedingungen für die FHIR Kommunikation ansich steuern und ermöglichen.

2.4.1. Clinical Resources

Medications & Immunizations: Medication, MedicationPrescription, MedicationAdmini-stration, MedicationDispense, MedicationStatement, Immunization, ImmunizationRecom-mendation

General: AdverseReaction, AllergyIntolerance, CarePlan, Condition, FamilyHistory, Pro-cedure, Questionnaire

Diagnostics: Observation, DiagnosticReport, DiagnosticOrder, ImagingStudy, Specimen

Device Interactions: DeviceObservationReport

2.4.2. Administrative Resources

Attribution: Patient, RelatedPerson, Practitioner, Organization

Entities: Device, Location, Substance, Group

Workflow Management: Encounter, Alert, Supply, Order, OrderResponse

2.4.3. Infrastructure Resources

Support: List, Media, Other, Provenance, SecurityEvent, [Binary]

Document Handling: Composition, DocumentReference, DocumentManifest

Exchange: MessageHeader, OperationOutcome, Query

Conformance: Conformance, Profile, ValueSet, ConceptMap

8

2.5. Ressourcendefinitionen

Wie bereits erwähnt, bestehen Ressourcen selbst aus einer eindeutige Adresse (URL), einemSatz von strukturierten Datenelementen, einer lesbaren XHTML Darstellung des Inhalts derRessource und einer Versionsnummer. Sie können in XML oder auch in JSON repräsentiertwerden. Die Definition der Ressource ist auf zwei Arten möglich. Einerseits als UML Diagramm,das den Inhalt einfach zusammenfasst, andererseits als Pseudo-XML Syntax, die ein Beispieleiner gültigen Instanz dieser Ressource darstellt. Alle Ressourcen bestehen dabei aus

• einer Reihe von Datenelementen,

• optionalen Erweiterungen (siehe Kapitel 2.7.3 Extension),

• einem vom Menschen lesbaren Teil von Nachrichteninhalten (siehe Kapitel 2.7.3 Narrati-ve),

• Ressourcen Zusatzinformationen (Metadaten), die die Verwendung der Ressource weiterbeschreiben,

• und zusätzlichen Schlagwörtern (siehe Kapitel 2.8.1 Tags), welche die Ressource nochweiter beschreiben.

2.5.1. XML

Die XML Darstellung der Ressourcendefinition beinhaltet dabei üblicherweise die pseudo-XMLDarstellung, welche eine beliebige Instanz der Ressource abbildet. Die XML-Syntax einer Res-source wird in Quellcode 1 beispielhaft dargestellt.

1 <[name] xmlns="http://hl7.org/fhir"> doco

2 <Name xmlns="http://hl7.org/fhir" (attrA="value")>

3 <nameA><nameA>

4 <nameB[x]></nameB>

5 <nameC> 

6 <nameD></nameD>

7 </nameC>

8 <name>

9

Quellcode 1: XML Ressourcendefinition Beispiel

Folgende Richtlinien gelten für Ressourcendefinitionen:

• Sowohl Ressourcennamen als auch Elementnamen unterscheiden zwischen Groß- undKleinschreibung. Duplikate, die sich nur in der Schreibweise unterscheiden, dürfen nichtdefiniert werden.

• Jedes Element des Datentyps primitive beinhaltet ein Attribut value, welches denaktuellen Wert des Elements beinhaltet.

9

• Elemente werden mit einer Kardinalität versehen, die festlegt, ob und wie oft ein Ele-ment vorkommen kann oder muss. Wird die Kardinalität rosa dargestellt, dann gibt eszusätzliche Bedingungen, welche sich auswirken. Diese Regeln sind als Mouse-over-Textersichtlich oder in der formalen Definition einsehbar.

• Unterelemente von Elementen (nameD von nameC in Quellcode 1) dürfen nur erlaubteDatentypen verwenden.

• Unterelemente welche eine Anzahl von Elementen enthalten, die bereits woanders defi-niert sind, können einfach auf diese Definitionen verweisen.

• Für den Fall, dass ein logisches Element mehrere Typen hat, dann ist der Name fix imFormat nnn[x] definiert, wobei nnn für den Elementnamen steht, und [x] für den je-weiligen Typ. Mehrere Typen werden mit einem senkrechten Strich ”|” getrennt dargestellt(siehe nameB in Quellcode 2):

10 <name>

11 <nameBType1>

12 ... contents for type1 ...

13 </nameBType1>

14 </name>

Quellcode 2: XML Ressourcendefinition Beispiel

• Jeder Elementname in der Pseudo-Syntax verweist zur Formaldefinition. Ist das Elementunterstrichen, dann muss die Anwendung das Format kennen, verstehen und unterstüt-zen.

• Jedes Element hat eine Attribut id, über welches es intern referenziert werden kann. Dieid ist in der Ressourcendefinition nicht ersichtlich.

• FHIR-Elemente sind nie leer. Sie sollten entweder einen Wert, ein Unterelement oder eineoder mehrere Erweiterungen haben.

• Falls sie keinen Wert haben, oder nicht definiert sind, sind sie wegzulassen. Ein einfachesLeerzeichen ist ebenfalls nicht erlaubt.

• Neben den erwähnten Regeln gelten noch die Definitionen des W3C1 und die Schema-tron Standards[39].

2.5.2. UML

Das UML Diagramm stellt denselben Inhalt dar, wie eine Reihe von Klassen, welche die Ele-mente einer Ressource darstellen (siehe Abbildung 4).

1http://www.w3.org/ [Zugriff am 19.04.2015]

10

http://www.w3.org/

Abbildung 4.: UML Ressourcendefinition (Quelle: http://hl7.org/implement/standards/fhir/formats.html)

Das UML Diagramm zeigt alle Typen des Elements an. In der UML Darstellung gibt es keinefestgelegte Ordnung der Elemente, noch ist erkennbar, ob eine Eigenschaft ein Element oderein Attribut ist. Das UML zeigt aber die Unterelemente und deren Bindung. Primär ist die UMLAnsicht dafür gedacht, einen schnellen Überblick zu erhalten, weil sie für Menschen auf denersten Blick leichter verständlich ist, als eine idente Ressource in XML Notation.

2.5.3. Ressourcengruppen (Bundles)

Ressourcengruppen (in Folge auch Bundles genannt) fassen eine Vielzahl von einzelnen Res-sourcen zusammen. Diese Bundles beinhalten die gesamten Ressourcen, und nicht nur denInhalt und Metadaten (siehe Abbildung 5. Sie dienen

• als Summe aller positiven Ergebnisse einer Suchanfrage (RESTful-Suche),

• als Gruppe aller Versionen einer Ressource (Historische Daten),

• für den Austausch einer Reihe von Ressourcen als einzelne Nachricht,

• als selbst definierte Gruppe von Ressourcen für medizinisch relevante Datenübermittlung.Zum Beispiel eine gesamte Krankenakte,

• oder zum Speichern von mehreren Ressourcen.

Abbildung 5.: Bundles in FHIR

Der Inhalt einer Ressourcengruppe sollte immer vorhanden sein (außer als negative Ant-wortnachricht auf eine Suchanfrage). Ein Bundle hat einen eindeutigen Bezeichner [url] und

11

einen Zeitstempel[55]. Er beinhaltet zudem eine Liste von Ressourcen mitsamt ihren Meta-daten. Zusätzliche Tags beschreiben, welchen Verwendungszweck das Bundle hat. Innerhalbvon FHIR werden XML Ressourcengruppen im The Atom Syndication Format (Atom-Feed)dargestellt[66][77]. Ein Beispiel eines Bundles im als Atom Feed zeigt Quellcode 44 in AnhangA, Seite 107.

2.5.4. Fächer (Compartments)

Jede Ressource kann zu einem oder mehreren logischen Fächern gehören. Ein Fach ist ei-ne Gruppe von Ressourcen, die eine oder mehrere Eigenschaften teilen. Fächer vereinfachendie logische Organisation von Ressourcen. Erstens durch eine schnelle Suche nach verwand-ten/zusammengehörenden Ressourcen, und zusätzlich erlauben sie auch noch eine einfacheRegelung der Zugriffe auf verwandte Ressourcen.

2.5.5. Arten von Ressourcenreferenzen

Bei Referenzen auf Ressourcen wird zwischen internen und externen Referenzen unterschie-den.

Interne Referenzen

Sie dienen als Verweise innerhalb einer Ressource. Diese treten in drei möglichen Fällen auf.In allen drei Fällen hat das Zielelement ein Attribut id, welches einen eindeutigen Wert zuallen anderen id-Elementen innerhalb dieser Ressource besitzt. Werden mehrere Ressourcenzu Ressourcengruppen, sprich Bundles, zusammengefasst, dann können jedoch mehrdeutigeid-Attribute vorhanden sein. Die Anwendung muss hier entsprechende Zuordnungen treffen,welche die id pro Ressource zuweist, und korrekt referenziert. Folgende Fälle können interneReferenzen enthalten:

• Interne Referenz auf die id eines beinhalteten Unterelements. Diese Referenzen sindnotwendig, wenn eine eingebettete Ressource selbst nicht eindeutig wäre, oder nicht ei-genständig existieren könnte (siehe Quellcode 41, Seite 107).

• Interne Referenz zwischen Datenelementen und dem Freitext Element (Narrative). Derid/idref Ansatz erlaubt es auch, innerhalb von strukturierten Daten auf erst späterdefinierte Binärdaten zu referenzieren (siehe Quellcode 42, Seite 107).

• Ebenfalls im Narrative als Bildreferenz in der Form <img src = ”” />, wobei das Bildselbst als Medienressource oder Binärressource definiert sein kann (siehe Quellcode 43,Seite 107).

In allen Fällen gilt die Darstellung in JSON analog zur XML Darstellung. Die JSON Eigen-schaft id ist gleichbedeutend mit dem XML-Attribut id.

12

Externe Referenzen

Sie dienen als Verweise zwischen Ressourcen. Dabei haben die Referenzen immer eine de-finierte Richtung (von der Quelle zum Ziel), und werden als URL entweder absolut, oder re-lativ dargestellt. Die Rückverfolgung der Ressource in der umgekehrten Richtung (vom Zielzur Quelle) ist logisch zwar möglich, jedoch über die Ressource selbst nicht lösbar. Dafür gibtes eigens eine RESTful API als externe Infrastruktur für die umgekehrte Suche von externenReferenzen[57]. Ressourcen werden unabhängig voneinander verarbeitet, und sind daher auchnicht transitiv. So hat zum Beispiel eine Ressource mit einer Referenz auf einen bestimmten Pa-tienten, nicht zwingend bei einer Referenz auf eine bestimmte Untersuchung, auch denselbenPatienten als Referenz. Vereinfacht könnte man sagen, dass externe Referenzen (im Gegen-satz zu beinhaltenden Referenzen) nicht vererbt sind, und sich deshalb nicht auf denselbenKontext beziehen müssen.

2.6. Aufbau von FHIR Nachrichten

Wie wir nun wissen, besteht jede zu übermittelnde Nachricht aus drei Teilen. Jede zu übermit-telnde Nachricht entspricht dabei einem Nachrichtentyp der wiederum als Ressource definiertist. Jede Ressource hat folgende charakteristischen Eigenschaften:

• Eine eindeutige Adresse als Uniform Resource Locator (URL) mit der sie angesprochenwerden kann.

• Identifiziert sich selbst als einen der Ressourcentypen dieser Spezifikation.

• Enthält einen Satz von strukturierten Datenelementen, wie durch die Definition des Res-sourcentyps beschrieben.

• Enthält eine lesbare The Extensible HyperText Markup Language (XHTML) Darstellungdes Inhalts der Ressource

• Eine Versionsnummer der Ressource.

Zusätzlich kann ein- und dieselbe Ressource noch unterschiedlich repräsentiert werden. EineRessource kann zum Beispiel sowohl im XML oder auch als JSON verwendet werden, voraus-gesetzt dass sie so definiert ist (siehe Quellcode 3).

2.7. Datentypen

Die FHIR Spezifikation legt zwei Gruppen von Datentypen fest. simple und primitive alseinfache Datentypen basierend auf dem XML Schema, und complex als komplexe Konstruktevon einfachen Datentypen.

13

1 <[Name] xmlns="http://hl7.org/fhir">

2 <extension></extension>

3 <modifierExtension></modifierExtension>

4 <language value="[code]"/>

5 <text></text>

6 <contained></contained>

7 

8 </[Name]>

Quellcode 3: FHIR XML Beispiel Nachrichtenaufbau

2.7.1. Datentyp simple/primitive

Elemente vom Typ simple/primitive haben keine weiteren Untereigenschaften. Sie könnendennoch Erweiterungen (sogenannte Extensions vom Typ:Extension) haben. Die Abbildung6 zeigt alle einfachen Typen (blau) und alle primitiven Typen (rosa) in der Übersicht.

Abbildung 6.: Übersicht Datentyp simple und primitive (Quelle: http://www.hl7.org/fhir/datatypes.html)

14

Jeder in FHIR erlaubte Datentyp ist dabei genau einem Datentyp der Spezifikation des WorldWide Web Consortium (W3C) für XML Datentypen[7] zugeordnet. Die Tabelle 2 zeigt die Ele-mente vom Datentyp simple nochmals in der Übersicht. Weitere primitive Datentypen sinddie bereits erwähnten Typen code, oid, uuid und id (siehe Tabelle 3).

FHIR Name Schema type Beschreibung

boolean xs:boolean Erlaubte Werte sind true oder false. (0 und 1 sind nicht gültig)

integer xs:int Vorzeichenbehaftete 32-bit Ganzzahl

decimal xs:decimal Rationale Zahl. Keine Exponenten erlaubt.

base64Binaryxs:base64Binary

Base64 kodierter Bytestream[51]

instant xs:dateTime Ein Zeitpunkt. Immer auf Sekunden genau inkl. Zeitzone. Hinweis: DieserTyp ist für Maschinenzeiten gedacht.

string xs:string Eine Anzahl von Unicode Zeichen. Die Größe von 1MB sollte nicht über-schritten werden.

uri xs:anyURI Ein Uniform Resource Identifier (URI) kann als absoluter oder relativer Pfadangegeben werden, und kann optionale Fragmentbezeichner beinhalten[5].

date union ofxs:date,xs:gYearMonth,xs:gYear

Ein Datum oder der Teil eines Datums (zum Beispiel nur das Jahr oder Jahr/-Monat) ohne Zeitzone. Das Datum sollte ein gültiges Datum sein.regex: -?([1-9][0-9]3|0[0-9]3)(-(0[1-9]|1[0-2])

(-(0[1-9]|[12][0-9]|3[01]))?)?

dateTime union ofxs:dateTime,xs:date,xs:gYearMonth,xs:gYear

Ein Datum oder der Teil eines Datums (zum Beispiel nur das Jahr oderJahr/Monat). Werden Stunden und Minuten angegeben, sollte die Zeitzonemit definiert sein. Sekunden sind optional möglich.regex:-?([1-9][0-9]3|0[0-9]3)(-(0[1-9]|1[0-2])

(-(0[1-9]|[12][0-9]|3[01])(T(([01][0-9]|2[0-3]):

[0-5][0-9]:[0-5][0-9]([̇0-9]+)?|(24:00:00(\.0+)?))

(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?)?)?)?

Tabelle 2.: Übersicht einfache Datentypen (Quelle: http://www.hl7.org/fhir/datatypes.html)

2.7.2. Datentyp complex

Komplexe Datentypen werden als XML-Element dargestellt. Sie haben Unterelemente mit demNamen des Datentyps und ein Attribut id. Das Unterelement wird dort definiert, wo es verwen-det wird. Analog dazu wird es in JSON Darstellung ebenfalls als Objekt mit demselben Namenwie der Datentyp erzeugt. Komplexe Datentypen werden über ein Profil beschrieben. Das Profilbeschreibt die möglichen Attribute und Regeln zur Befüllung. Abbildung 7 zeigt einige komplexeDatentypen in der Übersicht.

2https://loinc.org/ [Zugriff am 19.04.2015]3http://www.ihtsdo.org/snomed-ct [Zugriff am 19.04.2015]

15

https://loinc.org/

http://www.ihtsdo.org/snomed-ct

FHIRName

Schematype

Beschreibung

code string Bezeichnet einen String, dessen mögliche Werte aus einer weiteren Codetabelle stammen (zumBeispiel LOINC2, oder SNOMED CT3). Der Code muss mindestens aus einem Zeichen beste-hen, und darf zwischen einzelnen Strings nicht mehr als ein Leerzeichen enthalten. Führendeund nachstehende Leerzeichen müssen ebenfalls entfernt werden.regex: [ˆ\s]+([\s]+[ˆ\s]+)*

oid uri Ein Objekt Bezeichner als URI dargestellt. (RFC3001): urn:oid:1.2.3.4.5

uuid uri Ein universeller eindeutiger Bezeichner, welcher als URI dargestellt wird[59]:urn:uuid:a5afddf4-e880-459b-876e-e4591b0acc11. ”Zu beachten im RFC Kommentar:UUID Werte SOLLEN in Kleinbuchstaben angegeben werden, wobei die Groß-/Kleinschreibung nichtzu unterscheiden ist”

id string Eine Kennzahl im Bereich 0 bis 2ˆ64-1 (optional in Hexadezimal), eine uuid, eine oid, oderjede andere Kombination aus Kleinbuchstaben, Zahlen, ”-” und ”.”, mit einer maximalen Längevon 36 Zeichen.regex: [a-z0-9\-\.]1,36

Tabelle 3.: Übersicht Datentypen primitive (Quelle: http://www.hl7.org/fhir/datatypes.html)

Ratio

Beschreibt eine Verhältniskennzahl. Wird durch Zähler und Nenner definiert. Wenn vorhanden,dann müssen auch beide Attribute definiert sein (siehe Quellcode 4. Alle weiteren Beispiele fürDatentypendefinitionen finden sich im Anhang A, Kapitel Quellcodes).


2 

3 <numerator></numerator>

4 <denominator></denominator>

5 </[name]>

Quellcode 4: XML Datentyp ratio

Quantity

Ein messbarer Wert. Gemessen werden z.b Alter, Anzahl, Geld, Entfernungen, Zeiträume.Kann exakt sein [value] oder relativ [comparator]. Wird in menschen- [units] odermaschinenlesbarer Form [system],[code] angegeben (siehe Quellcode 26, Seite 103).

Range

Ein Bereich von geordneten [quantity] Werten. low und high. Diese sollten dieselbe Ein-heit haben

16

Abbildung 7.: Datentyp complex Teil 1 (Quelle: http://www.hl7.org/fhir/datatypes.html)

Coding

Werte aus definierten Code-Tabellen. Der Code selbst wird dabei durch eine uri und seineVersion beschrieben (siehe Quellcode 28, Seite 103).

Codeable Concept

Stellt Codes in unterschiedlichen Terminologien oder Klartext dar. Wird auch verwendet uminterne Codes auf Standard Codes (LOINC, SNOMED-CT) umzuschlüsseln (siehe Quellcode29, Seite 103).

Attachment

Erlaubt das Hinzufügen von externen Daten wie Dokumenten, Bildern oder Messreihen. Wirddurch den Mime-Typ beschrieben und base64 codiert übertragen (siehe Quellcode 30, Seite104).

Period

Beschreibt einen Zeitraum. durch Beginn und Ende definiert (siehe Quellcode 31, Seite 104).

SampledData

Beinhaltet einzelne Messwerte, zum Beispiel die eines Elektrokardiogramm (EKG). Beschreibtdie Anzahl der einzelnen Werte, die Messwerte, die Einheit, Minimal- und Maximal-Werte (sie-

17

he Quellcode 32, Seite 104).

Zudem gibt es noch weitere komplexe Datentypen (siehe Abbildung 8).

Abbildung 8.: Datentyp complex Teil 2 (Quelle: http://www.hl7.org/fhir/datatypes.html)

HumanName

Beinhaltet den vollständigen Namen einer Person, und den Gültigkeitszeitraum (siehe Quellco-de 33, Seite 104).

Identifier

Ein Identifier ist ein eindeutiger Bezeichner eines einzelnen Objektes innerhalb eines Sy-stems. Typischerweise werden Bezeichner verwendet, um Inhalte in Ressourcen für den Da-tenaustausch eindeutig zu definieren. Der Bezeichner kann auch geändert werden und nureingeschränkt gültig sein (siehe Quellcode 34, Seite 105).

Schedule (Timing)

Definiert mehrfach auftretende Ereignisse. Wird nur für geplante und zukünftige Ereignisseverwendet (siehe Quellcode 35, Seite 105).

ContactPoint

Alle Arten von elektronisch vermittelbaren Adressen einer Person oder Organisation einschließ-lich Telefon, Fax, E-Mail und weitere (siehe Quellcode 36, Seite 105).

18

Address

Eine Postanschrift von Patienten, Angehörigen, Ärzten, Organisationen (siehe Quellcode 37,Seite 106).

OpenTypeElement

Manche Elemente haben keinen bestimmten Datentyp. Diese werden in der De-finition mit einem Stern ”*” als Platzhalter dargestellt. Diese erlaubten Datenty-pen sind: integer, decimal, dateTime, date, instant, time, string, uri,

boolean, code, base64Binary, Coding, CodeableConcept, Attachment,

Identifier, Quantity, Range, Period, Ratio, HumanName,

Address, ContactPoint, Timing und Reference. Der Name des Elements enthält indem Fall auch den verwendeten Datentyp.

2.7.3. Sonstige Datentypen

Zu den sonstigen Datentypen zählt vor allem der Datentyp Resource. Weitere Typen sindNarrative, Reference und Extension (siehe Abbildung 9).

Abbildung 9.: Sonstige Datentypen (Quelle: http://www.hl7.org/fhir/datatypes.html)

Resource

Dieser Datentyp ist die generische Basis für alle in FHIR verwendeten Ressourcen (siehe Ka-pitel 2.5 Resourcendefinitionen).

Reference

Viele der definierten Elemente einer Ressource verweisen auf andere Ressourcen. Diese Ver-weise sind meist interne Referenzen, können sich aber auch auf externe Datenquellen bezie-hen. Alle Referenzen haben eine definierte Richtung (von der Quelle zum Ziel) und werden alsurl entweder absolut oder relativ angegeben (siehe Quellcode 38, Seite 106).

19

Extension

Jedes Element innerhalb einer Ressource oder eines Datentyps kann optionale Erweiterungenin Form von sog. Extensions enthalten. Diese Erweiterungen können beliebig oft vorhandensein. Erweiterungen werden als Unterelemente dargestellt, und müssen vor allen anderen Un-terelementen definiert werden. Der Link zur Beschreibung ist in dem Fall ein Pflichtfeld, undverweist auf die Ressourcendefinition, siehe Kapitel 2.5 und FHIR Ressourcenprofile[65]. EinBeispieldokument findet sich in Anhang A, Quellcode 39, Seite 106.

Narrative

Unter Narrative bezeichnet FHIR einen vom Menschen zu interpretierenden Inhalt. Diese Infor-mation kann optional sein, etwa um Unklarheiten zu beschreiben, oder aber auch nur vorhan-den sein, um den strukturierten Teil der Nachricht wiederzugeben. In der Ressourcendefinitionist beschrieben, wie der narrative Teil zu verstehen ist. Dieser sollte aus Sicherheitsgründen im-mer vorhanden sein. Durch sich verändernde Schnittstellen und Ressourcendefinitionen könn-ten wichtige Informationen beim Empfänger nicht dargestellt werden. Der Narrative verhinderteine eventuelle Fehlinterpretation aufgrund von Schnittstellenfehlern (siehe Quellcode 40, Seite106).

2.8. Nachrichtendefinitionen

Neben den Datentypen gibt es noch weitere grundlegende FHIR Spezifikationen. In den fol-genden Kapiteln werde diese im Detail beschrieben.

2.8.1. Marker (Tags)

Zusätzlich zu den bereits bekannten Metadaten einer Ressource kann diese noch mit zusätz-lichen Variablen markiert werden. Diese Variablen werden verwendet, um die Ressource etwaeinem Arbeitsprozess, oder einem Profil zuzuordnen. Diese Marker (in Folge auch Tags be-zeichnet) werden gemeinsam mit der Ressource selbst übermittelt, und dienen lediglich derZuordnung, der vereinfachten Suche oder der Zugriffssteuerung der Nachricht. Daraus einenRückschluss auf deren Inhalt abzuleiten ist unzulässig. Jeder Tag hat dabei drei Eigenschaften:

Schema uri: Eine uri die den Typ des Tags beschreibt

Term uri: Ein absoluter Verweis auf die Definition des Tags

Label string: Eine optionale Beschreibung zur Verwendung des Tags, und zur Handhabungin Endanwendungen.

20

Typen von Tags

Es gibt drei unterschiedliche Typen von Tags. Allgemeine Tags, definierte Tags, und Tags fürdie Sicherheitsbeschreibung:

COMMON Ein allgemeiner Marker[69]. Bei einem allgemeinen Marker verweist der Term in der Regelauf einen Katalog oder eine weitere Spezifikationen (HL7v2, HL7v3, CDA, LOINC oderSNOMED CT). Wenn die Ressource lokal definiert ist, sollte die uri relativ auf die lokaleDefinition verweisen. In einfachster Form auf eine einzelne HTML-Seite.

DEFINED Eine Zuweisung zu dem in der uri definierten Profil[65].

SECURITY Eine Sicherheitsbeschreibung des Markers[37].

2.8.2. Sicherheitsbeschreibungen / Security Labels

Sicherheitsbeschreibungen beziehen sich auf Ressourcen oder Ressourcengruppen, und die-nen der erweiterten Zugriffssteuerung durch die Access Control Decision Engine (ACDE) sprichder Zugriffssteuerung[38]. Diese Engine steuert nun anhand der Sicherheits-Metadaten undweiteren Ressourceneigenschaften (Ressourcentyp, Ressourceninhalt, Ressourcenherkunft)folgende weiteren Eigenschaften:

• Legt die erlaubten Zugriffe auf die Ressource (lesen, schreiben, ändern) fest

• Bestimmt die Rückgabewerte der Ressource

• Regelt die Vorgehensweise der Handhabung dieser Daten

Die Sicherheitsbeschreibungen erlauben hier eine sehr feingranulare Regelung der Sicher-heitseinstellungen, und verbessern somit den Austausch von Daten im Vergleich zu generi-schen Regeln. Die Security-Tags müssen bei allen Instanzen zwingend durchgesetzt werden,und sind auch bei Weiterübermittlung der Ressourcen immer fixer Bestandteil der Ressource.

Sicherheitsbeschreibungen sind dabei nur ein weiterer Baustein für eine geregelte und si-chere Kommunikation. Die Summe aller Security Labels lässt somit ein ganzes Security Fra-mework entstehen. Eine optimale Voraussetzung wäre natürlich eine voll vertrauenswürdigeUmgebung[14]. Das bedeutet, dass dafür jeder einzelne Kommunikationspartner verpflichtetwird, alle Sicherheitsbeschreibungen einzuhalten und durchzusetzen. In Ermangelung einersolchen Vor-Vereinbarung haben die Security Labels daher eine eingeschränkte Rolle, könnenaber natürlich trotzdem verwendet werden. Die Einhaltung obliegt jedoch in letzter Konsequenzdem Empfänger der Ressource.

Jede FHIR-Instanz sollte zumindest eine lokale Sicherheitsrichtlinie festlegen. Diese Richtli-nie beinhaltet

• eine Liste aller Sicherheitsbeschreibungen, die bekannt sind,

21

• beschreibt, was mit unbekannten Security Labels zu tun ist,

• unterstützt systembedingt alle bekannten Sicherheitsetiketten,

• und regelt betriebliche Auswirkungen der Labels.

Ein Security-Label wird also durch einen Marker mit folgenden Eigenschaften dargestellt:

SCHEMA uri: Beim Schema ist http://hl7.org/fhir/tag/security als fixer Wert für einSecurity-Label hinterlegt

TERM uri: Die URI auf das Label. Typischerweise in der Form[system]\#[code], wobei system ein bekannter System-Code (zum Beispielhttp://hl7.org/implement/standards/fhir/terminologies-systems.html)ist, und code ein Wert dieser Tabelle.

LABEL string: Lesbare Beschreibung des Codes.

Das Grundsystem der Sicherheitsetiketten ist im HL7 Healthcare Classification System(HCS) beschrieben. Diese Spezifikation beinhaltet bereits eine Liste von Etiketten, die in je-der FHIR Instanz unterstützt werden sollten (siehe Liste Core Security Labels in Kapitel 2.8.2).Natürlich steht es jedem/jeder FHIR BenutzerIn frei, eigene Sicherheitsetiketten zu verwenden,jedoch ist es ausdrücklich empfohlen, die Etiketten der HCS zu verwenden, um größtmögli-che Interoperabilität zu gewährleisten. Die Sicherheitsetiketten sind zum aktuellen Stand (FHIRv0.0.82) auch noch nicht letztendlich definiert und festgelegt:

DSTU Note: The use of security labels and the expression of common shared secu-rity policies is currently a matter of ongoing discussion and development in severalcommunities at this time. This is an area where there is likely to be substantial de-velopment during trial use.

[38, Kapitel 2.13.1.1 Representing Security Labels]

Core Security Labels

Wie bereits erwähnt, gilt die HCS Liste als Basisspezifikation für Sicherheitsetiketten. Alle kon-formen FHIR Anwendungen sollten diese Beschriftungen verwenden und korrekt interpretieren.Das Mutal-Trust-Framework[58][64] als Rahmenvertrag zum gegenseitigen Vertrauen sollte hierwieder Anwendung finden. Folgende Security-Labels können in jeder Ressource definiert sein:

Vertraulichkeitsstufen beziehen sich auf Ressourcen oder Ressourcengruppen. Siewerden primär vom Ersteller der Ressource vergeben, können aber bedingt durch opera-tionale Prozesse erstellt oder verändert werden. So ist ein positiver Test auf das HumaneImmundefizienz-Virus (HIV) immer als streng vertraulich einzustufen. Die Vertraulichkeits-stufen in Ressourcengruppen richten sich immer nach der strengsten Vertraulichkeit einereinzelnen Ressource der gesamten Gruppe. Die einzelnen Vertraulichkeitsstufen selbstsind in HL7 v3 definiert (OID = 2.16.840.1.113883.1.11.10228):

22

U unrestricted: Die Metadaten sind nicht als sensibel eingestuft. In der Regel sind dasöffentlich zugängliche Informationen (Firmenname, Telefon, E-Mail Adresse, Postan-schrift).

L low: Die Metadaten sind etwas schützenswert, und werden deswegen anonymisiertoder pseudo-anonymisiert. Ein Rückschluss auf die Identität soll systembedingt nichtmöglich sein. Ein Rückschluss auf die Person hätte aber trotzdem keine nennens-werten Auswirkungen. Für Pflegedienste gilt die ISO 13606-4 im Sensitivity Level(1). Es gibt aber hier keine klare Umschlüssung auf diesen HL7 Code.

M moderate: Die Metadaten sind mäßig schützenswert. Eine Offenlegung könnteschädigende Auswirkungen nach sich ziehen. Zum Beispiel Gesundheitsinforma-tionen für das Marketing, Allergien für die Krankenversicherung, Kreditkartendaten.Diese Stufe lässt sich teilweise auf die ISO 13606-4 im Sensitivity Level (2) um-schlüsseln.

N normal: Die Metadaten in dieser Stufe sind schützenswert, und eine Offenle-gung hätte schädigende Auswirkungen. Zugriff auf die Daten hat zum Beispielmedizinisches Personal., aber kein Pflegepersonal oder die Rechnungsstelle. EinMissbrauch wäre in dem Fall der Zugriff auf diese Daten durch eine private Kran-kenversicherung. Diese Stufe lässt sich teilweise auf die ISO 13606-4 im SensitivityLevel (3) umschlüsseln.

R restricted: Die Metadaten sind geschützt. Zugriff ist nur durch das direkt behan-delnde Personal vorgesehen. Eine sonstige Einsicht bedarf einer vorhergehendenGenehmigung. Diese Stufe lässt sich ebenfalls teilweise auf die ISO 13606-4 imSensitivity Level (3) umschlüsseln.

V very restricted: Diese Metadaten sind in der höchsten Vertraulichkeitsstufe. EineOffenlegung hätte gravierende Auswirkungen. Die Daten sind hochsensibel und pri-vat. Zum Beispiel Informationen eines Opfers zum Missbrauch oder psychiatrischeBefunde. In der Regel haben nur der Ersteller der Information und der Patient daraufZugriff.

Vertraulichkeitsregeln (uri:http://hl7.org/fhir/v3/ActCode\#[CODE])

CEL Celebrity/VIP: Die Person ist öffentlich bekannt oder auch ein Mitarbeiter diesesInstitutes.

EMP Staff: Die Person ist ein Mitarbeiter dieses Institutes.

TABOO Keep information from patient: Die Information ist ohne vorhergehende Genehmi-gung durch einen Arzt für den Patienten nicht einsehbar. Zum Beispiel ein Laborbe-fund vor Begutachtung durch einen Arzt.

DEMO Contact/Employment Details Confidential: Die Daten des Patienten (Adresse, Te-lefonnummern, E-Mail, Arbeitgeber) sind vertraulich, und dürfen auch nicht an An-gehörige weitergegeben werden.

23

DIA Diagnosis-related confidentiality: Kann sich auf jede Ressource beziehen, undentsteht durch eine vertrauliche Diagnose. Zum Beispiel Drogenmissbrauch, psych-iatrische Erkrankungen, Genetik.

ORCON Author Consent needed: Zustimmung des Erstellers der Information notwendig.Typischerweise durch den behandelnden Arzt erstellt, der einen Teil der Gesund-heitsakte als Vertraulich einstuft.

Des Weiteren gibt es auch Security-Labels, die den Nachrichtenfluss regeln. Alle Parteiensind verpflichtet, sich an diese Marker zu halten:

DELAU Delete after use: Wie der Name schon sagt, muss die empfangende Anwendungsicherstellen, dass diese Ressource nach der Verwendung unverzüglich gelöschtwird. Eine Speicherung, oder eine automatische Sicherung ist verboten. Auch etwai-ge Log-Daten über diese Ressource müssen gelöscht werden.

NOREUSE Do Not Re-use: Die Ressource darf nicht an andere Sub-Systeme weitergegebenwerden. Einzig die unmittelbare Verwendung ist gestattet.

Für medizinische Zwecke gibt es noch ein Notfall Security-Label:

break-the-glass Im Notfall Scheibe einschlagen: Im Falle einer medizinischen Notwendigkeit, undfalls der Patient nicht ansprechbar ist, gibt es die Möglichkeit eines Notfallzugriffesauf relevante Informationen. Diese Zugriffe werden streng protokolliert und auditiert,um etwaigen Missbrauch zu verhindern. Details zur noch nicht endgültig erstellenRegelung in FHIR sind in einem eigenen Diskussionsdokument ersichtlich[18]. Zu-dem wir in dem Dokument auf eine mögliche Zertifizierung durch die Joint Commis-sion on Accreditation of Healthcare Organizations (JACHO) verwiesen.

24

3. REST(ful) API

Jede Ressource in FHIR lässt sich sehr granular über RESTful Webservices steuern. Dabeigelten für alle Ressourcen ein und dieselben Webservices. Anwendungen, die konform zu die-sem Framework arbeiten, gelten als RESTful FHIR Anwendungen. Wie in Webservices üblich,lassen sich die Ressourcen via HyperText Transfer Protocol (HTTP) Methoden[23] steuern undverwalten. Jede Server-Instanz kann dabei festlegen, welche Methoden und welche Ressour-cen sie unterstützt.

3.1. Interaktionen auf konkrete Instanzen von Ressourcen

Darunter sind jene Interaktionen zu verstehen, die sich auf konkrete bereits instanziierte Res-sourcen beziehen, oder konkrete Instanzen erzeugen. Zum Beispiel die Aktualisierung einerPatientenressource, oder das Erzeugen eines Befundes. Ihnen gemein ist, dass der Metho-denaufruf über einen eindeutigen Identifier, also dem Attribut [id] erfolgt.

3.1.1. read

Liest den aktuellen Inhalt einer Ressource mittels HTTP GET Metho-de aus. (GET [base]/[type]/[id] {?_format=[mime-type]}) Das Ergebnis ist eineInstanz vom angegebenen Ressourcentyp mit dem Inhalt von id. Die Instanz muss ein Attri-but id besitzen, dessen Wert in dem Fall [id] ist. Sollte das Element nicht existieren, wirdein Fehler als HTTP Statuscode HTTP 404 zurückgegeben. Ist das Element gelöscht worden,wird HTTP 410 zurückgegeben. Die Instanz sollte ebenfalls eine Version enthalten, und denZeitstempel der letzten Änderung.

3.1.2. vread

Analog zu read, nur wird eine spezifische Versionabgefragt (GET [base]/[type]/[id]/_history/[vid] {?_format=[mime-type]}).Die retournierte Instanz hat das Attribut meta.versionId mit dem Wert [vid].

3.1.3. update

Beim update wird eine neue Version der Ressource [id] erstellt, falls diese bereits exi-stiert, ansonsten wird eine Ressource mit [id] erzeugt. Der Aufruf erfolgt mittels HTTP PUT

25

Methode (PUT [base]/[type]/[id] {?_format=[mime-type]}). Im Falle einer Aktua-lisierung antwortet der Server mit dem Status HTTP 200 OK, oder falls die Ressource neuerzeugt wurde, mit HTTP 201 CREATED. Zusätzlich wird im Antwortheader noch ein Zeit-stempel (Last-Modified Header) der letzten Aktualisierung mitgeliefert. Wurde eine Ressourceangelegt oder aktualisiert, wird noch ein Location-Header und ein Content-Location Headermitgeliefert, der die Referenz auf die Ressource beinhaltet. Der Server kann noch mit einerOperationOutcome Ressource (siehe Kapitel 2.4.3 Infrastruktur Ressourcen) Informationenund Warnungen an den Client retour liefern. Diese Nachricht sollte aber keinesfalls Fehler ent-halten. Falls Fehler auftreten, und der Server ein Update nicht durchführt, so antwortet er mitden definierten HTTP Fehlercodes:

• HTTP 400 Bad Request: Die Ressource konnte nicht gelesen werden, oder entsprichtnicht den FHIR Validierungsregeln.

• HTTP 404 Not Found: Der Ressourcentyp wird nicht unterstützt, oder der FHIR Endpunktexistiert nicht.

• HTTP 405 Method not allowed: Die Ressource [id] existierte vor dem Update nochnicht, und der Server erlaubt keine Vergabe von id’s durch den Client.

• HTTP 409 Version Conflict: Manche Server erlauben nur die Aktualisierung von eindeuti-gen Ressourcenversionen. Wird eine falsche Version mitgeliefert, so antwortet der Servermit einem HTTP 409 Version Conflict Fehler.

• HTTP 412 Preconditions failed: Wie HTTP 409. Manche Server erlauben nur die Aktuali-sierung von eindeutigen Ressourcenversionen. Wird bei einem solchen Server vom Clientder Content-Location-Header nicht mitgeliefert, so antwortet der Server mit einem HTTP412 Preconditions failed Fehler.

• HTTP 422 Unprocessable Entity: Standard Fehler für alle anderen Fehler. Der Serversollte wieder mit einer OperationOutcome Ressource (siehe Kapitel 2.4.3) antworten,welche weitere Details zum Fehler enthält.

3.1.4. delete

Die HTTP DELETE (DELETE [base]/[type]/[id] ) Methode löscht die Ressource [id].Ist das Entfernen der Ressource erfolgreich, so antwortet der Server mit einer HTTP 204 NoContent Nachricht. Eine eventuelle read Anfrage auf die Ressource würde den Fehler HTTP410 Ressource not found zurückliefern. Erlaubt der Server das Löschen dieses Ressourcentypsgenerell nicht, so antwortet er mit einem HTTP 405 Method not allowed. Verhindert der Serveraber das Löschen dieser speziellen Ressource aufgrund von anderen Integritätsregeln, so ant-wortet der Server mit HTTP 409 Conflict. Ist ein Löschen nicht möglich, weil die Ressource aufdem Server gar nicht existiert, dann wird wieder eine HTTP 404 Not Found Message gesen-det. Wird ein delete mehrmals auf dieselbe Ressource ausgeführt, so antwortet der Server

26

immer wieder erfolgreich mit HTTP 204 No Content, weil die Ressource ja erfolgreich gelöschtwurde. Ressourcen können in der Definition ein eigenes Statuselement besitzen, welche beimLöschen gesetzt wird. In diesem Fall bleibt eine Ressource bestehen. Ist keine spezielle Vor-gehensweise für das Löschen definiert, so wird die Instanz der Ressource selbst gelöscht.

3.1.5. validate

Bevor eine Ressource mittels update Methode überschrieben wird, kann auch überprüftwerden, ob das überhaupt möglich wäre. Dazu wird einfach ein HTTP POST RequestPOST [base]/[type]/_validate{/[id]} mitsamt aller zu überschreibenden Ressour-ceninformationen als Inhalt gesendet. Der Server überprüft nun als ersten Schritt, ob die Spe-zifikation und das Profil entsprechen, und die Ressource prinzipiell überschrieben werden kann.Im nächsten Schritt wird die optional übermittelte id herangezogen, und abgeklärt, ob die be-stehende Instanz überschrieben werden darf, beziehungsweise ob Regeln für eine Neuanlagebei Nichtvorhandensein festgelegt sind.

Der Client kann die Anfrage an den Server auch gegen ein spezielles Profil richten. Dazu wirdzusätzlich eine Profilkennzeichnung (siehe Kapitel 2.8.1 Tags) an die Ressource angehängt.Damit übermittelt der Client eigentlich nur, dass es sich um Ressourcentyp [xyz]handelt, undder Server überprüft das daraufhin.

Wie genau der Server diese Überprüfungen durchführt, liegt wieder im Ermessen des Ser-vers, und der hinterlegten Regeln und Profile. Der Server muss dabei auf jeden Fall auf formaletechnische Korrektheit hin überprüfen, damit die Nachrichten verarbeitet werden können. Ersollte aber zusätzlich gegen das Schema, die Schematron Spezifikation, eventuell vorhandeneProfile, und auch das referenzierte Client-Profil hin überprüfen.

Die Antwortnachricht bei korrekter Prüfung ist wieder eine HTTP 200 OK Message. Feh-lerantworten sind im Falle einer falschen Validierung entweder ein HTTP 400 Bad Request,falls die Anfrage selbst nicht korrekt ist, bzw. die FHIR-Validierung fehlerhaft war, oder aber einHTTP 422 Unprocessable Entity. In diesem Fall ist die Ressource zwar korrekt, aber ein Up-date der Ressource wäre aufgrund von FHIR-Profilen oder hinterlegten Geschäftsregeln nichtmöglich. Fehlermeldungen sollten wieder eine OperationOutcome Ressource enthalten.

3.1.6. history

Die HTTP GET Methode history kann auf drei verschiedene Arten verwendet werden. Sieretourniert entweder alle Versionen einer bestimmen Ressource [id], alle Ressourcen einesbestimmen Typs, oder alle Ressourcen die vom System unterstützt werden. Sie wird mittelsdieser drei HTTP GET Methoden aufgerufen:GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]}

GET [base]/[type]/_history{?[parameters]&_format=[mime-type]}

GET [base]/_history{?[parameters]&_format=[mime-type]}

27

Als Antwort erhält der Client ein Bundle mit allen Versionen, beginnend mit der ältesten. DiesesBundle enthält auch alle bereits gelöschten Ressourcen, sofern diese nur mit einer entspre-chenden Markierung versehen wurden, und im System selbst noch vorhanden sind. MöglicheParameter des HTTP GET Requests wären zum Beispiel die Anzahl der retournierten Daten-sätze, oder der Zeitpunkt ab dem Ressourcenversionen zurückgegeben werden sollen. Da dieAnzahl der Datensätze im Bundle sehr groß werden kann, soll der Server Seitenumbrüchezwecks Lesbarkeit verwenden[68]. FHIR verweist hierbei auf den RFC5005 Feed Paging andArchiving[77].

3.2. Interaktionen auf unbekannte Instanzen vonRessourcen

3.2.1. create

Die HTTP POST Methode create (POST [base]/[type] {?_format=[mime-type]})

erzeugt eine neue Ressource an der vom Server zugewiesenen Stelle, mit einer durchden Server vergebenen id. Wünscht hingegen der Client die Vergabe der id, so soll-te er auf die update Methode zurückgreifen, und die id selbst vergeben. Nach er-folgter Anlage antwortet der Server mit einer HTTP 201 Created Nachricht. Diese ent-hält den eindeutigen Bezeichner [id] und die Versionsnummer [vid] in der Form:Location: [base]/[type]/[id]/_history/[vid]

Kann die Ressource aufgrund fehlender oder falscher Metadaten nicht erzeugt werden, soantwortet der Server wieder mit HTTP 400 Bad Request, HTTP 404 Not Found falls der ge-wünschte Ressourcentyp nicht existiert, oder die Anfrage nicht an einen gültigen Endpunktgestellt wurde. Auch der Fehlercode HTTP 422 Unprocessable Entity ist möglich. In diesemFall unterbinden hinterlegte Geschäftsregeln das Erzeugen der Ressource. Generell geltenauch hier dieselben Regeln analog zu update für die Interpretation von Kommentaren oderLeerzeichen.

3.2.2. search

Für die generelle Verwaltung von Ressourcen beinhaltet die FHIR-API auch vorbereitete Such-funktionen. Die HTTP GET Methode für die allgemeine Suche wird ohne einschränkende Pa-rameter ausgeführt, und ist in Quellcode 5 ersichtlich. Des Weiteren ist auch die Suche nacheinem einzelnen Ressourcentyp möglich, siehe Quellcode 6, oder die Einschränkung der Su-che auf bestimmte Fächer/Compartments wie in Quellcode Beispiel 7 abgebildet.

1 GET [base]?[parameters] {&_format=[mime-type]}

Quellcode 5: Allgemeine Suche mittels HTTP GET

28

1 GET [base]/[type]?[parameters] {&_format=[mime-type]}

2 GET [base]/[type]/_search?[parameters] {&_format=[mime-type]}

Quellcode 6: Suche nach Ressourcentyp mittels HTTP GET

1 GET [base]/[compartment]/[id]/?[parameters] {&_format=[mime-type]}

2 GET [base]/[compartment]/[id]/[type]?[parameters] {&_format=[mime-type]}

Quellcode 7: Suche nach Compartments mittels HTTP GET

Aus Gründen der Kompatibilität mancher Clients zwischen HTTP GET und HTTP POST Me-thoden sind alle Aufrufe auf /_search auch mittels identischer HTTP POST Header erlaubt.Jeder Suchaufruf erwartet optional eine Reihe von Key-Value-Pairs (Schlüssel-Werte-Paaren)in der aufrufenden URL laut RFC1738[6], RFC1808[24] codiert, und laut World Wide Web Con-sortium (W3C) in der HTML Spezifikation im Abschnitt 17.13.4 - Form content types[99] mittelskaufmännischem und ”&” getrennt. Analog dazu können die Parameter der Suche auch alsmultipart/form-data laut RFC2045[26] mittels HTTP POST abgesetzt werden.

Ist die Suche erfolglos, werden die entsprechenden HTTP 4xx oder HTTP 5xx Fehlercodeszurückgegeben, und beinhalten wieder eine OperationOutcome Ressource für weitere Infor-mationen. Ist die Suche erfolgreich, wird eine Liste von Ressourcen in der festgelegten Reihen-folge als Ergebnis in einem Bundle zurück übermittelt. Die Liste kann sehr lang sein, deshalbist auch in der Suche der Seitenumbruch laut RFC5005 Feed Paging and Archiving[76] wiedergeregelt.

3.2.3. history

Siehe Kapitel 3.1.6 Interaktionen auf Instanzen.

3.3. Sonstige Interaktionen

In der FHIR-API sind auch einige Systemweite Methoden und Funktionen implementiert. DieHistorie (history) und die Suche (search) ist auf Element- und Ressourcenebene ja bereitserwähnt worden. Zudem gibt es aber noch Methoden zur Steuerung von Transaktionen, undzur zentralen Serverkonfiguration.

3.3.1. conformance

Die Konformität des Servers in Bezug auf die Handhabung von Ressourcen, Nachrichten, Re-quests, Ereignissen, und vielen weiteren Parametern, wird im Conformance Request gere-gelt (siehe Quellcode 45, Seite 109) und als XML Antwortnachricht zurückgegeben. Aufgerufenwird die Konformitätserklärung mittels der Methoden HTTP OPTIONS oder HTTP GET (sieheQuellcode 8).

29

1 GET [base]/metadata {?_format=[mime-type]}

2 OPTIONS [base] {?_format=[mime-type]}

Quellcode 8: XML Aufruf für einen Conformance Request

Auf diese Anfragen antwortet der Server mit einer Conformance Ressource, welche alleserverseitig definierten Informationen enthält (siehe Abbildung 18, Seite 112). Anwendungenmüssen die HTTP GET Methode zur Konformität unterstützen. Sie sollten auch die HTTP OP-TIONS Methode implementieren, wenngleich diese nicht von allen Clients beherrscht wird. DieAntwort beinhaltet einen Content-Location Header der auf die Conformance Ressource ver-weist. Die verweisende uri sollte eine direkte Referenz auf diese Version der Konformitätser-klärung sein, und auch noch verfügbar und gültig, wenn sich das hinterlegte Regelwerk ändert.Ändern sich die hinterlegten Regeln, so sollte sich auch die Version im Content-Location Hea-der ändern. Optionale Parameter für die HTTP OPTIONS Methode sind auch in der ObjectManagment Group (OMG) Health-Data RESTful Transport Spezifikation festgelegt[67].

Diese Conformance-Methode bezieht sich auf den Server als gesamtes, und liefert das ak-tuelle Regelwerk. Vorausgesetzt der Server unterstützt die clientseitige Manipulation des Re-gelwerkes, so ist es auch möglich, auf den Conformance Endpunkt die HTTP Methoden read,search, create und update anzuwenden. Diese Art der Serverkonfiguration ist jedoch op-tional. Im Anhang E, Seite 121 findet sich zudem noch eine vollständige Liste aller HTTP StatusCodes.

3.3.2. transaction

Transaktionen werden verwendet, um eine große Anzahl von Ressourcen in einem einzigenArbeitsschritt auf einem Server anzulegen, zu verändern oder zu löschen. Dabei spielt es keineRolle, ob es sich um idente oder unterschiedliche Ressourcen handelt, und auch ein unter-schiedlicher Mix aus Operationen ist erlaubt. Das Ergebnis einer Transaktion ist wiederum eineMenge aus neuen, veränderten oder gelöschten Ressourcen.

Transaktionen sind hilfreich wenn mehrere Interaktionen voneinander abhängig sind, um dieIntegrität der Daten zu wahren. Zum Beispiel werden in einem Schritt eindeutige Bezeichner ge-ändert [id]’s, und vorhandene Referenzen darauf korrigiert. Durch die Transaktion kann einmöglicher Datenverlust verhindert werden. Die Transaktion ist nur dann erfolgreich, wenn alleeinzelnen Schritte korrekt durchgeführt werden. Ist nur ein einzelner Aufruf (create, updateoder delete) nicht möglich, so wird die gesamte Transaktion abgebrochen, um wieder konsi-stenten Ressourcenzustand herzustellen. Weitere Steuerungsmöglichkeiten siehe Kapitel 3.3.2Transactional Integrity.

Der Inhalt der POST Methode ist ein Bundle an Ressourcen, von denen jede einzeln verar-beitet wird. Der Aufruf erfolgt mittels HTTP Post (siehe Quellcode 9).

1 POST [base] {?_format=[mime-type]}

Quellcode 9: HTTP POST einer Transaktion

30

Die einzelnen Methodenaufrufe innerhalb der Transaktion unterscheiden sich nicht zu de-nen, die direkt und einzeln von BenutzerInnen aufgerufen werden. Alle serverseitigen Über-prüfungen für create, update oder delete werden auch in diesem Fall durchgeführt, undeventuelle Fehlermeldungen an die Transaktion zurück übermittelt.

Kann nur ein einzelner Methodenaufruf nicht durchgeführt werden, so werden HTTP 400 oderHTTP 500 Type Response Fehler gemeldet, und die gesamte Transaktion wird abgebrochen.Ist die Transaktion erfolgreich, so wird HTTP 200 OK gemeinsam, mit einem Response Bundleübermittelt.

Für Transaktionen gilt noch eine Besonderheit: Jede Ressource darf innerhalb einer Transak-tion nur einmal verändert werden. Ein Bundle, welches einzelne Ressourcen mehrmals enthält,kann daher nicht durch Transaktionen verändert werden.

Innerhalb der Transaktion benötigen alle Ressourcen einen eindeutigen Bezeichner [id].Ist auf dem Server diese id bereits vorhanden, so wird ein Methodenaufruf als update an-gesehen, und die Ressource mittels HTTP PUT aktualisiert. Ist die id für diese Ressourcenoch nicht vorhanden, und vorausgesetzt sie kann verwendet und angelegt werden, so wirddiese Ressource mittel HTTP POST neu erzeugt. Ressourcen, die gelöscht werden, benötigenohnehin weitere Bezeichner sowohl bei XML als auch JSON Methodenaufrufen.

Innerhalb einer Transaktion können die Ressourcen auch untereinander Abhängigkeiten auf-weisen. Durch die Transaktion können neue Versionen und damit neue Bezeichner entste-hen. Alle Referenzen innerhalb des Bundles werden daher immer korrigiert. Für Referen-zen von anderen Ressourcen außerhalb der Transaktion ist dies nicht der Fall. Die Aktua-lisierung gilt allgemein für die Ressourcenbezeichner und Ressourcenreferenzen. Im spezi-ellen aber auch für URL Elemente, und sogar für <a href=""... & <img src=""...

Tags innerhalb des Narrative. Sind solche zu aktualisierenden Referenzen vorhanden,so werden diese durch das cid:url Schema laut RFC2392 codiert[60]. Zudem wirdvorab die id als URL nach RFC822 codiert[16]. Dadurch werden Sonderzeichen, Leer-zeichen, spitze Klammern et cetera als hexadezimale Zeichen dargestellt %hh escape,und die cid:url als ”cid:[ressource-id]” erzeugt. Zum Beispiel wird dadurchContent-ID: <foo4#[email protected]> zu "cid:foo4%25foo1%40bar%2Enet".

Damit der Client nun auch weiß, welche Ressourcen geändert wurden, und wie die neuerzeugten Ressourcen zu finden sind, übermittelt der Server bei einer erfolgreichen Transaktionein Bundle. Dieses Bundle enthält wiederum für jede einzelne Ressource

• die vom Server vergebene [id] in entry.id.

• sofern die Ressource die Methode vread unterstützt, dann eine Verknüpfung auf sichselbst als versionsspezifische Referenz.

• die vom Client übermittelte [id] als alternative Referenz

.Die Anwendung, welche die Transaktion vorbereitet, kann zu dem Zeitpunkt auch noch gar

nicht wissen, ob eine Ressource zum Zeitpunkt der Transaktion bereits vorhanden ist, oder

31

nicht. Das ist speziell bei Patientendaten oder Personal- und Krankenhausdaten der Fall. Indiesem Fall sollte das Bundle eine Candidate Ressource mit einer cid:xyz Referenz undeinem zusätzlichen Suchaufruf als Atom-Link (siehe Kapitel 2.5.3 Ressourcengruppen / Bund-les) beinhalten. Quellcode 10 zeigt so einen Link in der XML Ansicht.

1 <link href="http://localhost/Patient?[parameters]" rel="search"/>

Quellcode 10: Referenzlink als Atom–Link

Der Suchaufruf auf http://localhost bedeutet in dem Fall, dass der Server den lokalenSpeicher nach allen Ressourcen durchsucht, auf den die Parameter zutreffen. Wird kein Treffergefunden, dann wird die Ressource aus der Transaktion verwendet. Wird ein Eintrag gefun-den, dann verwendet der Server seine lokale Ressource, und verwirft die übermittelte. Werdenmehrere Einträge gefunden, so wird die Transaktion ebenfalls abgebrochen.

Transaktionale Integrität (Transactional Integrity) Während der Verarbeitung von create

und update Operationen innerhalb einer Transaktion kann es vorkommen, dass der Servernicht die gesamte Ressource verarbeitet, sondern nur einen Teil davon. Das ist in folgendenFällen möglich:

• Der Server vermischt bestehenden Inhalt mit neuem.

• Geschäftsregeln verändern den Ressourceninhalt.

• Der Server unterstützt nicht alle Funktionen der übermittelten Ressource.

Trotzdem wird in diesen Fällen die Transaktion (wenn auch nur teilweise) erfolgreich durchge-führt werden. Das entspricht nicht ganz den ACID Eigenschaften atomicity, consistency,isolation und durability von Transaktionen, wie wir es etwa aus Datenbanken kennen,wo teilweise Transaktionen nicht erwünscht, und in der Regel auch nicht erlaubt sind[35][53].

In FHIR steht jedoch die Interoperabilität im Fokus, und deshalb sind in diesen drei oben ge-nannten Fällen Transaktionen trotzdem durchführbar. Ganz allgemein ist damit aber ein mög-liches Risiko des Datenverlustes verbunden. Um dieses Risiko gering zu halten, gelten daherfolgende allgemeine Regeln:

• Für jede Ressource, welche die update Methode unterstützt muss der Server auch dieread Methode erlauben.

• Vor einem update muss der Client ein read auf die Ressource ausführen, damit ermöglichst den aktuellen Inhalt der Ressource kennt.

• Der Client sollte nur jede Informationen verändern, die beabsichtigt sind, und alle anderenunangetastet belassen.

• Der Client kann eine HTTP 409 Rückmeldung verarbeiten, und daraus eventuell nochmalseinen korrekten update Aufruf erzeugen.

32

Beide Teilnehmer (Client und Server) sollten eindeutige Regeln festlegen, wie die transaktio-nale Integrität verwendet wird.

3.4. Interaktionstabellen

Neben den bereits erwähnten Interaktionen und Methoden gibt es noch weitere. Die beidenÜbersichtstabellen Tabelle 4, Seite 33 und Tabelle 5, Seite 34 zeigen alle in FHIR definiertenInteraktionen. In Tabelle 4 werden alle Methodenaufrufe inklusive aller optionalen Parameterdargestellt.

Interaktionen Pfad API Methodenaufruf

Methode Content-Type Body Accept ContentLocation

read /[type]/[id] GET O -

vread /[type]/[id]/_history/[vid] GET O

conformance / or /metadata OPTIONS / GET O

update /[type]/[id] PUT R Resource O or R

create /[type] POST R Resource

transaction / POST R Bundle O

delete /[type]/[id] DELETE

search /[type]/_search? or /[type]? GET O

search-all / GET O

validate /[type]/_validate{/[id]} POST R Resource O

history /[type]/[id]/_history GET O

history-type /[type]/_history GET O

history-all /_history GET O

tags-all /_tags GET O

tags-type /[type]/_tags GET O

tags /[type]/[id]/_tagsGET O

POST R TagList

tags-delete /[type]/[id]/_tags/_delete POST R TagList

tags-version /[type]/[id]/_history/[vid]/_tagsGET O

POST R TagList

tags-version-delete /[type]/[id]/_history/[vid]/_tags/_delete POST R TagList

mailbox/Mailbox (Message) POST R Bundle R

/Mailbox (Document) POST R Bundle

document /Document POST R Bundle

Tabelle 4.: API Methodenaufrufe R-benötigt, O-optional (Quelle: http://hl7.org/implement/standards/fhir/http.html)

Tabelle 5 zeigt die möglichen Antworten inklusive aller definierten und erlaubten HTTP StatusCodes.

33

Interaktion API Methodenantwort

Content Type Body Location ContentLocation

Status Codes

read R Resource R 200, 404, 410

vread R Resource O 200, 404, 405

conformance R Conformance O 200, 404

update R 200, 201, 400, 404, 405, 409,412, 422

create R O 201, 400, 404, 405, 422

transaction R Bundle 200, 400, 404, 405, 409, 412,422

delete 204, 405, 404

search R Bundle 200, 403

search-all R Bundle 200, 403

validate leer oder R leer oder OperationOutcome

400

history R Bundle 200

history-type R Bundle 200

history-all R Bundle 200

tags-all R TagList 200

tags-type R TagList 200

tagsR (GET) TagList 200, 404, 410

leer (POST) 204

tags-delete 204

tags-versionR (GET) TagList 200, 404

leer (POST) 204

tags-version-delete 204

mailboxR (Message) Bundle 200

leer (Document) 204

document 200

Tabelle 5.: API Methodenantworten R-benötigt, O-optional (Quelle:http://hl7.org/implement/standards/fhir/http.html)

34

3.5. Die Such-API (Search/Query)

Wie bereits in Kapitel 3.2.2 erörtert, ist eine der Hauptfunktionen von FHIR die Suche nachRessourcen über Suchparameter, und die Abfrage von Informationen bereits bekannter Res-sourceninstanzen. Das Spektrum der Suchmöglichkeiten reicht dabei von einfachsten Parame-tern über alle Ressourcen eines Typs (wie zum Beispiel die Namenssuche über alle Patienten)bis hin zu komplexen Anfragen aus dynamisch erzeugten Suchkriterien. Da die Suche aber ei-ne sehr große Funktionalität in FHIR darstellt, werden hier auch der Suchaufbau, die Parameterund die Filtermöglichkeiten noch genauer inspiziert.

Die einfachste Form der Suche ist ein einfacher HTTP GET Methodenaufruf wie er in Quell-code 11 gezeigt wird:

1 GET [base-url]/[resourcetype](?parameters)

Quellcode 11: HTTP GET Suchaufruf

Die Parameter der Suchanfrage setzen sich dabei aus einer Reihe von Key-Value-Pairs(Schlüssel-Werte Paaren, für die gilt: Name=[Wert]) zusammen. Die Parameter sind dabeiwieder als URL dargestellt (Siehe Kapitel 3.2.2 URL Encoding) und per HTTP GET über-mittelt, beziehungsweise als application/x-www-form-urlencoded Anhang einer HTTPPOST Anfrage. Auf jegliche Suchanfragen antwortet der Server wieder mit einem Ressour-cenbundle in XML, welches die Ergebnisse der Suche enthält. Optional kann noch eineOperationOutcome weitere Informationen liefern. Fehler in der Suche werden wieder mitHTTP 4xx und HTTP 5xx Status Codes gemeldet, wobei hier der HTTP 403 Status Code be-sonders ist, weil er einfach bedeutet, dass der Server die Suche erst gar nicht durchgeführthat.

3.5.1. Allgemeine Suchparameter

Der wohl allgemeinste Suchparameter ist die [id] einer Ressource. Die Suche für einen be-kannten Ressourcentyp und seine id wird in Beispiel 12 dargestellt:

1 GET [base-url]/patient?_id=23

Quellcode 12: Suche über die id

Die Suche liefert als Ergebnis den PatientIn mit der [id]=23. Rein von der Funktionalität istdie einfache readMethode aus dem Quellcode Beispiel 13 hier äquivalent:

1 GET [base-url]/Patient/23

Quellcode 13: Aufruf mittels read über die id

Die read Methode liefert hier ebenfalls die Ressource mit der [id]=23. Der Unterschiedliegt aber im Detail. Die einfache Leseoperation liefert uns bereits die Ressource selbst, wäh-rend die Suche ja nur ein Bundle von Ressourcen mit der Referenz auf die gefundene Res-source liefert.

35

Neben der id, welche ausnahmslos für alle Ressourcen existiert, gibt es noch viele weitereSuchparameter. Diese sind in der Ressourcendefinition selbst festgelegt. Vereinfacht lässt sichsagen, dass prinzipiell nach jedem definierten Parameter gesucht werden kann, wenngleichder Server diese Suche nicht durchführen oder implementieren muss.

Es ist auch erlaubt, dass ein Parameter mehrmals innerhalb der Ressource vorkommt. Indiesen Fällen wird die Ressource aber bereits beim ersten Auffinden des Parameters in dasRessourcenbundle des Suchergebnisses aufgenommen, und in der Antwort mitgeschickt. Hiermuss der Client entscheiden, ob das Ergebnis der Suche korrekt ist.

3.5.2. Suchparameter Typen

Jeder Parameter der Suche ist als Typ definiert, der genau beschreibt, wie er zu interpretierenist. Folgende Typen sind definiert:

number: Der number Suchparameter sollte eine Ganzzahl oder eine gültige Gleitkommazahl sein.

date: Der date Suchparameter ist ein Datum oder eine Uhrzeit. Die Darstellung basiert aufdem XML-Standard Format[7].

string: Ein string ist ein einfacher Text. Der Text kann zum Beispiel der beginnende Teilstringeines Namens sein. Strings dürfen Leerzeichen enthalten. Die Groß- und Kleinschreibungist nicht von Bedeutung, ebenso wie etwaige Akzente (ê = e).

token: Ein token erlaubt eine Suche nach codierten Elementen (codes) oder eindeutigen Be-zeichnern (identifier). Bei der Verwendung von Codes erlaubt er die Suche in derBeschreibung (text), im angezeigten Namen (displayname), im eigentlichen Co-de selbst (code). Bei den Bezeichnern ist die Suche nach Benennung (label), Sy-stemname (system) und dem Schlüssel selbst (key) möglich. Der Parameter ist dabeientweder ein String, oder ein Schlüssel-Werte-Paar durch einen senkrechten Strich ”|”getrennt.

reference: Eine Referenz auf eine andere Ressource

composite: Eine Komposition verknüpft jeweils zwei unterschiedliche Suchparameter zu einem

quantity: Sucht nach einer Menge oder Anzahl

Die Suchparameter selbst werden dabei zusätzlich durch Modifier beschrieben, welche ihrVerhalten steuern. Das Standardverhalten des Servers ohne Angabe entsprechender Modifierhängt von der Implementierung ab. Die erlaubten Modifier sind:

missing Für alle Parameter außer zusammengesetzten. Zum Beispiel liefert die Suche nach”gender:missing=false” alle Ressourcen, die ein Geschlecht hinterlegt haben.

36

exact Für die Suche in Strings ist der Modifier ”:exact” sehr hilfreich. Ergebnisse werden nurbei eindeutigen Treffern geliefert. Mit diesem Zusatz ist auch die Groß- und Kleinschrei-bung wieder relevant.

text Beim Token liefert der Zusatz ”:text” alle Ergebnisse einer vergleichbaren Textsucheim CodeableConcept oder im Coding, anstatt der standardmäßigen Suche über dieeindeutigen Codes selbst.

type Bei der Suche nach Referenzen erlaubt der Modifier ”:[type]” die Einschränkung derSuche nach einem genannten Ressourcentyp.

numbers

Zahlenwerte können mittels vergleichender Operatoren gesucht werden (<, <=, =, >, >=).Der = Parameter muss dabei in der URL wieder umgewandelt (escaped) werden. Spezielldabei ist, dass die Suche immer auf zwei untergeordnete Stellen genau ist. So liefert dieSuche nach [parameter]=100 alle Werte zwischen 99,5 und 100,5 und die Suche nach[parameter]=100.00 alle Werte zwischen 99,995 und 100,005.

date

Bei der Datumssuche sind ebenfalls alle vergleichenden Operatoren erlaubt. Das Datum selbstentspricht der XML-Datumsdefinition[7] im Format yyyy-mm-ddThh:nn:ss(TZ). Dabei giltdie Empfehlung, dass auch Minuten angegeben werden, sobald eine Stunde als Uhrzeit fest-gelegt ist, und im Fall einer Uhrzeit auch die Zeitzone. Für die Suche gilt das Datum oder dieUhrzeit als implizit. Dass bedeutet, die Suche nach 2015-04-10 liefert alle Ressourcen zwi-schen 2015-04-10T00:00 und 2015-04-10T23:59. Für den Typ instant, der vereinfachtaus Datum, Uhrzeit inkl. Minuten, Sekunden und Millisekunden besteht, gilt dieses Intervall je-doch nicht. Das Beispiel in Quellcode 14 sucht nach allen Behandlungen eines Patienten imZeitraum von 2 Jahren:

1 GET [base-url]/Patient/23/procedure?date=>2012-01-01&date=<2014-12-31

Quellcode 14: Suche über Datum

string

Die Textsuche ist entweder eine Teilstringsuche, oder eine exakte Suche. So findet der Suchauf-ruf aus Quellcode Beispiel 15 im ersten Aufruf die Patienten Eve und Severin, im zweiten Aufrufnur Eve.

37

1 GET [base-url]/Patient?name=eve

2 GET [base-url]/Patient?name:exact=Eve

Quellcode 15: Suche über Text

token

Ein Parameter vom Typ token durchsucht Ressourcen nach Code oder Identifier. DieWerte in den Ressourcen können zudem als URI aus einer Coding- CodeableConcept-oder Identifier-Ressource stammen. Die Syntax des Aufrufes ist wie folgt möglich:

[parameter]=[code] findet Codewerte unabhängig von ihrem Namensraum.

[parameter]=[namespace]|[code] findet alle Codewerte im angegebenen Namensraum.

[parameter]=|[code] findet nur Codewerte ohne Namensraum.

Quellcode 16 zeigt die Suche nach allen Patienten mit dem Schlüsselwert ”1234” im ge-samten System http://acme.org/patient. Im Gegenzug dazu führt Quellcode 17 eineSuche nach allen männlichen Patienten, die mit der Kennziffer ”M” aus der HL/7 Defintionsta-belle http://hl7.org/fhir/v2/0001/ festgelegt sind, durch.

1 GET [base-url]/Patient?identifier=http://acme.org/patient|2345

Quellcode 16: Suche über Codewert

1 GET [base-url]/Patient?gender=http://hl7.org/fhir/v2/0001|M

Quellcode 17: Suche über codierten Code

quantity

Der Suchparameter quantity bezieht sich nur auf den Datentyp Quantity, und sucht nacheiner Menge in der festgelegten Einheit. Die Syntax ist in Quellcode Beispiel 18 ersichtlich.

1 [parameter]=[comparator][number]|[namespace]|[code]

Quellcode 18: Suche über die Menge

Dazu ein einfaches Beispiel: Die Suche nach allen Messwerten innerhalb der Ressourcen Ob-servation, die einen Wert von 5,4 mg (Milligramm) haben, wobei die Einheit als The UnifiedCode for Units of Measure (UCUM)[101] Einheit codiert ist (siehe Quellcode Beispiel 19).

2 GET [base-url]/Observation?value=5.4|http://unitsofmeasure.org|mg

Quellcode 19: Suche über die Menge

Auch hier sind wieder vergleichende Operatoren (<, <=, >, >=) erlaubt. Auch eine ungefähreZuordnung von 10% des Wertes durch die Tilde (~) ist möglich.

38

reference

Der Suchparameter der Referenz erlaubt es nach verknüpften Ressourcen zu suchen. Die An-gabe ist entweder [parameter]=[id], also relativ, wenn es sich um die lokale Ressourceid handelt, oder [parameter]=[url], wobei die URL der absolute Pfad zur referenzier-ten Ressource darstellt. Quellcode 20 zeigt die Suche in allen aufgezeichneten Merkmalen(conditions), in welchen der Patient mit dem Bezeichner 23 hinterlegt ist.

1 GET [base-url]/condition?subject:Patient=23

Quellcode 20: Suche über Referenzen

3.5.3. Verkettung von Suchparametern

Die Verkettung von Suchparametern ist notwendig, um die Suche nicht unnötig über alle Ele-mente einer Ressource laufen zu lassen. Verkettete Elemente werden mit einem Punkt (.) ge-trennt. Die Suche nach allen Diagnoseberichten die den Patientennamen ”Hansi” enthalten,lautet wie in Quellcode 21 ersichtlich:

1 GET [base-url]/DiagnosticReport?subject:Patient.name=hansi

Quellcode 21: Verkettete Suchparameter

3.5.4. Verknüpfung von Suchabfragen

Einzelne Suchparameter können auch kombiniert werden. So liefert die Suche nach/patient?language=DE&language=EN alle Patienten, die Deutsch und Englisch spre-chen, und ist einer logischen UND-Verknüpfung gleichzusetzen. Die Suche nach/patient?language=DE,EN liefert alle, die mindestens eine der gesuchten Sprachen spre-chen. Also das Pendant zur logischen ODER-Verknüpfung.

Eine Sonderform stellt hier noch der Datentyp composite dar. Ein composite besteht auseiner Reihe von Messwerten, welche durch das Dollarzeichen ($) getrennt sind. Da der ei-gentliche Werte-Inhalt aber aus der Liste aller Elemente besteht, müssen diese auch bei derSuchanfrage mittels Dollarzeichen wieder aufgetrennt werden.

Kennzeichnung von Suchparametern (escaping)

Die Zeichen Dollar "$", Komma "," und der senkrechte Strich "|" sind als spezielle Steu-erzeichen für die Verknüpfung definiert. Deshalb müssen sie als Teil von Suchanfragen, in-nerhalb dieser, auch speziell gekennzeichnet werden. Diese Kennzeichnung ist der Backs-lash (\). So bedeutet [parameter]=xxx$yyy eine Verknüpfung von xxx und yyy, wogegen[parameter]=xxx\$yyy nach "xxx$yyy" sucht. Der Suchparameter "xxx\yyy" ist nichterlaubt, und "xxx\\yyy" sucht nach "xxx\yyy".

39

Parameter für die Textsuche

Für die Textsuche sind zwei spezielle Parameter (_text und _content) vorgesehen. Die-ser Parameter sucht im Narrative einer Ressource, oder innerhalb der gesamten Ressource.Suchelemente können einfach durch UND- und ODER-Verknüpfungen kombiniert werden (sie-he Quellcode 22).

1 GET [base-url]/Condition?_text=(knochen OR leber) AND metastasen

Quellcode 22: Kombinierte Suchparameter

3.5.5. Antworten auf Suchanfragen

Die Suchergebnisse können sowohl durch den Client als auch durch den Server noch beein-flusst werden. Der Server kann zum Beispiel die Ergebnisse nach Relevanz bewerten, unddiese Information als OpenSearch Relevance Extension mitliefern. Der Wert wird dabei alsDezimalzahl von 0 bis 1 dargestellt (siehe Quellcode 23).

1 <entry>

2 <os:score

xmlns:os="http://a9.com/-/opensearch/extensions/relevance/1.0/">[score]

3 </os:score>

4 <content type="text/xml">

5 </entry>

Quellcode 23: Suchparameter mit Relevanzinformationen

Auch die Sortierung der Ergebnisse ist möglich. Der Parameter _sort unterstützt dabei dieMethoden ”:asc” (aufsteigende) und ”:desc” (absteigende Sortierung).

Wie bereits in Kapitel 3.1.6 erwähnt steht es dem Server frei, bei sehr großen Suchergeb-nissen diese nur als einzelne Seiten (pages) auszuliefern. Dabei beinhaltet das Ergebnis-Ressourcenbundle nur eine Liste von Referenzen (URLs) auf weitere Seiten. Diese URLs wer-den vom Server generiert, und beinhalten interne Parameter für den Server, um diese Seitenwiederzufinden, und gegebenenfalls zu liefern. Diese Parameter sollten daher durch den Clientnicht interpretiert werden.

Auch dem Client stehen weitere Möglichkeiten der Manipulation von Suchergebnissen zurVerfügung. Der Parameter _count legt fest, wie viele Ergebnisse der Client zurückbekommenmöchte.

Ein großes Augenmerk liegt in der FHIR Spezifikation zudem auch in der effizienten Such-abwicklung, um den auftretenden Netzwerkverkehr so gering als möglich zu halten. Möchteein Client eine ganze Liste von Ressourcen eines Typs erhalten, und für jede einzelne dieserRessourcen auch wieder eine Abfrage stellen, so kann er diese verschachtelte Suche direktdurch den Server durchführen lassen. Die exemplarische Suche in Quellcode 24 liefert alleVerschreibungen und deren verschreibende Ärzte, für die gesuchte Diagnose [xyz].

40

1 GET [base-url]/MedicationDispense?_include=MedicationDispense.

2 authorizingPrescription&_include=MedicationPrescription.

3 prescriber&criteria=[xxx]

Quellcode 24: Rekursive Suchparameter

Ein weiterer noch ungeklärter Punkt in der Verarbeitung von Suchergebnissen sind externeReferenzen. So ist in FHIR noch nicht exakt geklärt, wie damit umzugehen ist. Findet der Servereine Referenz auf ein externes Element (wie in Quellcode 25 Beispielfall ein Bild),

1 <content>

2 <contentType>image/jpeg</contentType>

3 <url>http://example.org/images/2343434/234234.jpg</url>

4 </content>

Quellcode 25: Suchergebnis mit externen Referenzen

so sollte aus Kompatibilitätsgründen das Bild vom Server abgerufen, und als Binary Ressour-ce ausgeliefert werden.

Ein weiterer Parameter der Suche ist die Zusammenfassung (_summary). Diese liefert nurdie Elemente einer Ressource, welche in der Definition als summary gekennzeichnet wurden.Für jede Ressource ist nur eine Zusammenfassung definiert. Diese enthält immer den letztengültigen Stand.

3.5.6. PUSH vs PULL

Das primäre Ziel von FHIR liegt im einfachen Austausch von medizinischen Informationen zwi-schen unterschiedlichen Systemen. Wenn ein System nun Information hat, welches ein anderesSystem benötigt, bleibt noch immer die Frage, ob diese Information vom Sender aktiv übermit-telt wird (PUSH), oder ob der Empfänger sie aktiv anfordert (PULL). FHIR unterstützt beideVarianten.

PUSH

Sobald neue Information verfügbar ist, versendet die Quelle (in dem Fall der Client) diese auto-matisch an das Ziel (den Server). Das Zielsystem muss diese Information empfangen, korrektverarbeiten, und für die weitere Verwendung ordnungsgemäß seinen Index aufnehmen. Die ge-samte weitere Steuerung der Information obliegt in diesem Fall dem Server. Dieser ist für dieZugriffssicherheit der Information verantwortlich.

PULL

Die Quelle (der Server) verwaltet und hält die notwendigen Informationen. Wenn ein Ziel (Client)Informationen benötigt, so muss er diese beim Server anfragen, und bekommt sie im Anschluss

41

übermittelt. In diesem Fall kann sowohl der Server, als auch der Client für die Zugriffssicherheitauf die Information zuständig sein. Oder auch beide.

Welche der beiden Methoden nun die bessere ist, hängt ganz von der gewünschten Topologieund vom Kontext der Verwendung ab. Die FHIR Spezifikation erlaubt beide Methoden in derREST(ful) API.

Verwendung von PUSH: Die Quelle ist der Client, und sobald Information verfügbar istwerden die Methoden create, update und transaction verwendet, um sie zum Ziel,dem Server, zu übermitteln.

Verwendung von PULL: Die Quelle ist der Server und der Client möchte Informatio-nen. Der Client verwendet eine Kombination aus search und read, um die notwendigenDaten zu bekommen.

Verwendung von PUSH/PULL: Die Quelle ist der Server, und das Ziel ist der Client.In regelmäßigen Intervallen fragt der Client den Server nach der Historie von Daten, umdiese in seine eigene Datenbank zu replizieren.

POLL (Feeds)

Neben den erwähnten Methoden PUSH und PULL gibt es auch die möglich über neue In-formationen im Atom Syndication Format informiert zu werden. Atom ist ein XML basiertesDokumentenformat, welches eine Liste von Informationen beschreibt, sogenannte Feeds[77].Ein Client kann also einen Feed abonnieren, und fragt in regelmäßigen Abständen nach Ände-rungen. FHIR erlaubt auch die Verwendung eines ”deleted Entry” Elements, welches es erlaubtdas Löschen von Ressourcen nachzuvollziehen[103].

42

4. Sicherheit in FHIR

Per Definition ist FHIR kein Sicherheitsprotokoll, noch stellt es keinerlei derartiger Funktionali-täten zur Verfügung:

Fast Healthcare Interoperability Resources (FHIR) is not a security protocol, nordoes it define any security related functionality.

[37, Kapitel 2.13.0]

Es definiert lediglich die Syntax und die Handhabung der Nachrichten und Prozesse für eineneinfachen und generischen medizinischen Datenaustausch über Systemgrenzen und Topolo-giegrenzen hinweg. FHIR verweist dabei mehr oder weniger ausreichend auf empfohlene Me-thoden und Standards für die sichere Übermittlung. In der Definition selbst gibt es diesbezüglichdaher keine exakten Vorschriften oder Vorgaben, sondern nur Hinweise und Empfehlungen.Hier die Liste der Sicherheitshinweise im Überblick die hier anschließend im Detail erörtertwerden:

Kommunikationssicherheit: Jegliche Kommunikation soll durch Transport Layer Secu-rity (TLS) beziehungsweise Secure Sockets Layer (SSL) verschlüsselt erfolgen.

Authentifizierung: BenutzerInnen sollten sich authentifizieren. OAuth1 ist hier empfoh-len.

Zugriffskontrolle: FHIR hat eine auf Sicherheitsmarkierungen basierte Infrastruktur (Se-curity Label) definiert, um Zugriffskontrolle prinzipiell zu ermöglichen. FHIR wird eventuell(irgendwann) eine Reihe von Ressourcen zur tatsächlichen Implementierung und Verwal-tung dieser Sicherheitslabel definieren, auch wenn es diese bis dato nicht gibt.

Protokollierung: Dafür sind die eigens dafür vorgesehenen InfrastrukturressourcenProvenance und SecurityEvent zuständig. Sie protokollieren alle Zugriffe auf Res-sourcen.

Digitale Signaturen: FHIR unterstützt Signaturen.

Anhänge, Binärdaten: FHIR erlaubt die Verwendung von Binärdaten nur unter bestimm-ten Voraussetzungen.

1http://OAuth.net/ [Zugriff am 19.04.2015]

43

http://OAuth.net/

Labels: FHIR erlaubt eine Reihe von Sicherheitsmerkmalen, die den Zugriff auf Ressour-cen steuern (siehe Kapitel 2.8.2 Security Labels).

Management Regeln zum Datenzugriff: FHIR ermöglicht vielfältigen und einfachen Da-tenaustausch. Nicht alle Methoden, die FHIR ermöglicht, müssen aber im Kontext länder-spezifischer Gesetze und Regelungen auch erlaubt sein. In den USA regelt der HealthInsurance Portability and Accountability Act (HIPPA) den Austausch medizinischer In-formationen zwischen Institutionen. Es liegt in der Verantwortung der Person oder desInstituts, welches eine FHIR Instanz betreibt, diese auch entsprechend den gesetzlichenVorschriften zu implementieren.

Narrative: Besonderes Augenmerk sollte auch in der Sicherheit der Darstellung desmenschlich lesbaren Teils einer Ressource liegen.

Da sich die FHIR Spezifikation zum Aktuellen Stichtag 11.04.2015 noch in der Version v0.0.82befindet, gibt es speziell für sicherheitskritische Bedenken und gefundene Sicherheitslückeneine eigene Anlaufstelle in Form einer Mailing-Liste2. Nicht so dringliche Anfragen zur Sicher-heit, und eventuelle Vorschläge sollten auf der eigens eingerichteten Community Plattform3

diskutiert werden. Verwunderlich und enttäuschend ist der Umstand, dass diese Diskussions-plattform am 09.12.2012 eingerichtet wurde, und bis dato (Stand 11.04.2015) keinen einzigenDiskussionsbeitrag beinhaltet. Nichts desto weniger gibt es noch eine Reihe von weiteren Dis-kussionsplattformen in der sich Interessierte über Fragen zur FHIR Implementierung austau-schen4. FHIR verweist für eine sichere und konforme Implementierung zudem auch auf dieEntwicklungsprofile der Integrating the Healthcare Enterprise (IHE) Internet User Authorizati-on (IUA)[13].

4.1. Sicherheitskonzept

Für die Implementierung der Sicherheitsmechanismen Authentifizierung, Zugriffskontrolle undProtokollierung definiert FHIR drei unterschiedliche Implementierungsvarianten (Siehe Abbil-dung 10).

LEGENDE:

Der/die BenutzerIn, der/die ein Gesundheitsdatensystem bedient.

Die dabei verwendete Clientanwendung. Diese kann sehr vielfältig gestaltet sein, undreicht vom integrierten System eines Krankenhauses bis hin zu einer mobilen APP odereinem einfachen Webservice.

2http://wiki.hl7.org/index.php?title=FHIR_email_list_subscription_instructions [Zugriff am 19.04.2015]3http://wiki.hl7.org/index.php?title=FHIR_Security_Page [Zugriff am 19.04.2015]4http://thefhirplace.com, http://fhirblog.com/, http://fhir.furore.com/ [Zugriff am 19.04.2015]

44

http://wiki.hl7.org/index.php?title=FHIR_email_list_subscription_instructions

http://wiki.hl7.org/index.php?title=FHIR_Security_Page

http://thefhirplace.com

http://fhirblog.com/

http://fhir.furore.com/

Abbildung 10.: FHIR API Schnittstellenkonzept (Quelle: http://hl7.org/fhir/security.html)

Das zugrundeliegende Sicherheitssystem für die Authentifikation und die Zugriffs-kontrolle.

Das eigentliche FHIR Repository.

Die roten Linien kennzeichnen dabei die FHIR Schnittstellen (APIs).

• In der ersten Variante (links) kommuniziert der Client mit einem Sicherheitssystem aufBasis der FHIR Spezifikation, und dieses Sicherheitssystem kommuniziert (wiederum aufBasis der FHIR Spezifikation) mit dem eigentlichen FHIR Repository.

• In der zweiten Variante (Mitte) kommuniziert die Clientanwendung direkt mit einem Sicher-heitssystem oder hat dieses bereits integriert, und leitet Anfragen an das FHIR Repositorydirekt weiter.

• In der dritten Variante (rechts) kommuniziert der Client direkt mit dem Repository, unddieses überprüft alle Anfragen durch ein angeschlossenes Sicherheitssystem auf Basisder FHIR Spezifikation.

In allen drei Varianten können die Komponenten in teils unterschiedlichen Systemen und Netz-werken betrieben werden. Die FHIR Spezifikation geht lediglich davon aus, dass ein solchesSicherheitssystem vorhanden ist, und entweder VOR der Repository API (Variante eins undzwei), oder DANACH (Variante 3) angeschlossen ist.

Das Sicherheitssystem selbst implementiert dabei die Aufgaben der Identifikation und Au-thentifikation des/der BenutzerIn. Es regelt die Zugriffskontrolle mit dem Ergebnis, dass der/dieBenutzerIn eine FHIR Operation durchführen darf oder nicht. Es protokolliert alle Aktionen und

45

Vorgänge, um spätere Nachvollziehbarkeit zu gewährleisten, und um eventuellen Missbrauchnachzuweisen.

In nahezu jedem Land gibt es für die Zugriffsregelung und Rollendefinition unzählige und teilssehr stark unterschiedliche Rechtsvorschriften. Auch in Österreich gibt es Gesetze, welchedie Kommunikation von medizinischen (und somit sensiblen) Daten regeln. Dazu zählen dasElektronische Gesundheitsakte-Gesetz ELGA-G[27] und die Gesundheitstelematikverordnung2012 (GTelV 2012)[28], beide aus dem Jahre 2012. Im Jahr 2013 wurden dazu zwei weitereVerordnungen ELGA-Verordnung – ELGA-VO[30] und Gesundheitstelematikverordnung 2013(GTelV 2013)[29] veröffentlicht. FHIR verwendet einen sehr generischen Ansatz und unterstütztdabei keinerlei Rollenkonzepte, und sieht diese auch weiterhin nicht vor. Vielmehr stellt es dieFunktionalität der Sicherheitsmarkierungen (siehe Kapitel 2.8.2 Security Labels) zur Verfügung.Ein dabei angeschlossenes Sicherheitssystem soll sich dieser Methodik bedienen, um rollenund zugriffskonforme Anfragen zu stellen. Die einzelnen Sicherheitsempfehlungen sind in denfolgenden Abschnitten im Detail dargestellt.

4.2. Kommunikationssicherheit

Für die REST(ful) API bezieht sich die Sicherheitsempfehlung nur auf die HTTPSpezifikation[33]. Die Basis URL des Servers (Service Root URL) legt dabei fest, wie der Servererreichbar ist (HTTP oder HTTPS). Lediglich die Empfehlung

Communications Security - all exchange of production data should be secured usingTLS/SSL (e.g. https).

[37, Kapitel 2.13.0]

ist vorhanden. Es wird auch keinerlei Bezug darauf genommen, welche Version verwendetwerden soll (SSL, TLS 1.0, 1.1, 1.2)[20] beziehungsweise welche erlaubt ist. Hier sind allenfallsdie Empfehlungen des Deutschen BSI (Bundesamt für Sicherheit in der Informationstechnik)Grundschutzes zu verwenden[19]. Es gibt auch keine festgelegte Regelung über die Verwen-dung von Client Zertifikaten. Alle Entscheidungen obliegen einzig dem Einrichter einer FHIRInstanz. Für browserbasierte Implementierungen gibt es aufgrund der Same-origin policy[3] ei-nige Einschränkungen. Um diese zu umgehen, empfiehlt FHIR hier die Verwendung von cross-origin ressource sharing5 für REST(ful) API Aufrufe.

4.3. Authentifizierung

Der Server kann frei entscheiden, ob er nur den/die BenutzerIn authentifiziert, oder auch denClient. Die Clientauthentifizierung kann über die Topologie (Netzwerk, Media Access Con-trol (MAC) Adresse) erfolgen, oder auch über Clientzertifikate. Die Authentifikation des/der

5http://enable-cors.org/ [Zugriff am 19.04.2015]

46

http://enable-cors.org/

BenutzerIn kann ebenfalls auf vielfältige Arten erfolgen. Bei webbasierten Applikationen sollOAuth6 in der Version 2.0 implementiert werden[36][50][61].

4.4. Zugriffskontrolle

Die Kernaufgabe der Zugriffskontrolle ist die Steuerung der korrekten Berechtigungsvergabevon ordnungsgemäß authentifizierten BenutzerInnen, Geräten, Standorten und Organisatio-nen. Die Zugriffskontrolle bedient sich dabei zusätzlichen Regeln oder ganzen Regelwerkskon-struktionen wie zum Beispiel die ELGA GDA Rollen (OID 1.2.40.0.34.10.26)[31], basie-rend auf dem Object Identifier (OID) Konzept für das Österreichische Gesundheitswesen[100],um eine korrekte Zuordnung von BenutzerInnenanfragen oder Systemanfragen zu Ressourcenzu ermöglichen. In FHIR ist diesbezüglich überhaupt keine Möglichkeit implementiert und auchnicht vorgesehen.

Ein FHIR Repository in der Praxis zu betreiben, setzt dieses Regelwerk jedoch voraus. DerZugriff auf Daten, oder deren Verarbeitung, darf nur dann erlaubt sein, wenn es eine Zusiche-rung gibt, dass die anfordernde oder übermittelnde Stelle auch berechtigt ist, dies zu tun. Dasgilt sowohl für den Client, der eine Ressource per HTTP PUT oder HTTP POST erzeugen will,als auch für den Client der eine Ressource per HTTP GET übermittelt haben möchte.

Die Entscheidungskriterien hinter den verwendeten Regeln können dabei sehr komplex sein,und auch je nach zu verarbeitender Ressource stark variieren. Sie hängen von vielfältigenFaktoren ab:

• Sie können vom Client und vom/von BenutzerInnen in seiner/ihrer jeweiligen Rolle abhän-gen, dem Ort der Anfrage und dem damit einhergehenden Sicherheitslevel.

• Von der Ressource, ihrer Vertraulichkeit, ihrer Wichtigkeit (zum Beispiel hinterlegte Not-falldaten), von der Art der Daten, oder sogar vom Ersteller selbst.

• Vom Patienten, seiner Identität (VIP), seiner Verbindung zum/zur BenutzerIn, der/die aufdiese Daten zugreift oder von einer eventuell hinterlegten Patientenverfügung.

• Und zuletzt noch vom Kontext der Anfrage (Warum wird diese Ressource angefragt?),von der Uhrzeit oder von der Einhaltung der hinterlegten Arbeitsabläufe.

Zusätzlich wird auf die Integrating the Healthcare Enterprise (IHE) Spezifikation zur Zugriffs-kontrolle verwiesen[13].

4.5. Protokollierung

Für die Protokollierung stellt FHIR die Provenance Ressource und die SecurityEvent Res-source zur Verfügung. Die Provenance Ressource (siehe Abbildung 11) basiert dabei auf dem

6http://oauth.net/ [Zugriff am 19.04.2015]

47

http://oauth.net/

W3C Standard[34].

Abbildung 11.: FHIR Provenance Schema (Quelle: http://www.hl7.org/fhir/provenance.html)

Für FHIR lässt sich die Arbeitsweise wie folgt zusammenfassen: Die Provenance Ressour-ce beinhaltet jene Informationen, die für die Erzeugung einer neue Version einer Ressourcevon Relevanz waren. Das sind neben der Aktivität (create, update, etc.) noch die beteiligtenAgents (Client, Server) und die verwendeten Endpunkte. Die Provenance Ressource selbstwird dabei von der Anwendung erzeugt, die den Methodenaufruf durchführt (create, update)und eine neue Instanz einer Ressource erzeugt. Jede Provenance Ressource verweist dabeiauf eine einzige Aktivität, die eine oder mehrere Ressourcen betrifft, die durch diese Aktivitäterzeugt oder verändert wurden. Die Abbildung 12 zeigt den Aktivitätsablauf:

Abbildung 12.: FHIR Provenance Konzept (Quelle: http://www.hl7.org/fhir/provenance.html)

Ähnliche Informationen, aber für einen ganz anderen Verwendungszweck, stellt dieSecurityEvent Ressource (siehe Abbildung 13) zur Verfügung. Alle Ressourcen vom TypSecurityEvent stellen gemeinsam sozusagen das Security log dar. Typischerweise wer-

48

den sie verwendet, um eventuelle Einbrüche in das System zu erkennen, oder um festzustel-len ob jemand unberechtigt auf Ressourcen zugegriffen hat. Sie werden im Gegensatz zurProvenance Ressource eher von der aufgerufenen Stelle bei der Durchführung ihrer Aufga-ben (read, query, create, update, etc) erzeugt. SecurityEvents dienen als Grundlagefür Sicherheitsaudits. Sie können jedoch auch automatisch an eine überprüfende Stelle weiter-gereicht werden. FHIR verweist dabei speziell auf die IHE Audit Trail and Node Authenticati-on (ATNA) Profile[46], die seit vielen Jahren verwendet werden. Ursprünglich durch RFC3881geregelt[63], werden SecurityEvents in FHIR nun durch die National Electrical Manufactur-ers Association (NEMA) DICOM Sicherheits und Management Profile[73] geregelt.

Abbildung 13.: Darstellung SecurityEvent Ressource (Quelle: http://www.hl7.org/fhir/securityevent.html)

Die SecurityEvent Ressource wird gemeinschaftlich durch HL/7, DICOM und IHE abge-stimmt, um eine mHealth Intiative (Mobiler Zugang zu Gesundheitsdaten) voranzutreiben. Ta-belle 6 zeigt einige SecurityEvent Protokolleinträge in der Übersicht:

4.6. Digitale Signaturen

FHIR unterstützt digitale Signaturen, und verweist dabei auf die W3C Spezifikationen[2] zurHandhabung. Signaturen können über die Provenance Ressource auch losgelöst von derRessource selbst hinterlegt werden, um so eine mögliche Manipulation einer Ressource

49

Szenario Typ SubTyp Aktion Beschreibung

General 110100 ApplicationActivity

110120Application Start

E Execute One participant which contains thedetails of the Application

Login 110114 UserAuthentication

110122 UserAuthentication

E Execute One participant which contains thedetails of the logged in user

Login OAuth 110114 UserAuthentication

110122 UserAuthentication

E Execute One participant which contains thedetails of the logged in user

RESTful Operation 113883 RESTfulOperation

113883.308Create

C Create One participant which contains thedetails of the created Ressource

Logout 110114 UserAuthentication

110123 UserLogout

E Execute One participant which contains thedetails of the logged out user

Tabelle 6.: SecurityEvent Protokolleinträge

festzustellen[2, Kapitel 10, Definitionen SignatureDetached]. Diese Signatur ist nicht geeignet,um die inhaltliche Authentizität einer Ressource zu belegen. Dafür ist eine eingebettete Signa-tur vorgesehen[2, Kapitel 10, Definitionen SignatureEnveloped]. Diese wird bei einem Bundleverwendet, um den Inhalt zu signieren. Momentan arbeitet das Integrating the Healthcare Enter-prise (IHE) IT Technical Infrastructure Comittee daran, entsprechende Profile in diesem Bereichzu spezifizieren[47].

4.7. Sicherheit von Anhängen

Einige Ressourcen erlauben die Verwendung von Anhängen. Diese können entweder als Re-ferenz angeführt sein, oder base64 codiert in der Ressource selbst. Anhänge stellen in FHIRein höheres Sicherheitsrisiko dar, als alle anderen Ressourcen, weil sie ausführbare Codeteileenthalten können. Die Implementierung von Anhängen sollte dies immer berücksichtigen undentsprechend sorgsam umgesetzt sein.

4.8. Sicherheit beim Narrative

FHIR unterstützt mit dem Narrative die The Extensible HyperText Markup Language(XHTML)[94] Darstellung[1] als lesbare Form des Inhaltes der Ressource. Die Darstellung vonHTML Inhalten ist mit Sicherheitsrisiken verbunden, wie sie auch schon in anderen Standards(siehe CDA Security Issue Description[62]) erlebt wurden. Aus diesem Grund ist im FHIRNarrative die Verwendung von aktiven Elementen untersagt. Dazu gehören die Elementehead, body, jegliche Referenzen auf externe Stylesheets, veraltete Elemente, die Verwendungvon Scripts oder Formularen, Verweise mittels base, link oder xlink, sowie die Verwendungeingebetteter Inhalte in Form von frames oder iframes, alle Arten von Objekten und auchalle Ereignis gesteuerten Elemente (onClick). Trotzdem ist bei der Darstellung auf folgendes

50

zu achten:

• Vor der Darstellung sollte der Narrative gegen das Schema überprüft werden. AktiveInhalte sind im Schema nicht erlaubt. Auch wenn die Schemaprüfung erfolgreich ist, könn-ten noch externe Inhalte über Stylesheets verlinkt sein, weshalb sie jenseits der Sichtbar-keit und Überprüfbarkeit durch das Schema sind.

• Es muss sichergestellt sein, dass externe Referenzen auf Bilder beim Abrufen dieserReferenzen keine unerwünschten Informationen über die header (siehe CDA SecurityIssue Description oberhalb) preisgeben.

• Externe Referenzen sollten nur unter eingeschränktem Kontext geladen und verarbeitetwerden, solange sie nicht als vollkommen vertrauenswürdig eingestuft sind.

• Eine externe Referenz auf ein Bild, erlaubt es dem Server festzustellen, ob und wann aufdieses zugegriffen wurde. Das kann eine nützliche Funktion sein, könnte aber bei falscherVerwendung durch den Server ein Risiko darstellen.

51

5. Analyse der geforderten Schutzziele

In der Literatur werden Informationen und Daten ganz allgemein als zu schützende Güter derInformationssicherheit definiert. Der Zugriff auf diese Daten ist zu schützen und zu beschrän-ken, damit nur authentifizierten und ordnungsgemäß autorisierten Objekten (Systemen) oderSubjekten (Personen) Zugriff gewährt wird[21]. Diese Schutzziele sind Authentizität, Dateninte-grität, Informationsvertraulichkeit, Verfügbarkeit, Verbindlichkeit und Anonymisierung/Pseudo-misierung.

5.1. Schutzziel der Authentizität

Die Authentizität eines Objekts oder Subjekts wird in der Regel durch den Nachweis der Glaub-haftigkeit in Form von zuvor festgelegten Merkmalen definiert. Für Subjekte ist das im ein-fachsten Fall eine eindeutige BenutzerInnenkennung, in Kombination mit charakteristischenEigenschaften. Diese Eigenschaften können Kennwörter, biometrische Merkmale wie Finger-abdrücke, Zertifikate oder Zutrittskarten sein. Für Objekte (WebServer, AccessPoints etc) wirddieser Nachweis in der Regel durch kryptografische Verfahren erbracht. Speziell für Webappli-kationen verweist FHIR hier aber auf OAuth in der Version 2.0 für die Authentifikation von Be-nutzerInnen.

5.1.1. OAuth 2.0

OAuth ist ein offenes Protokoll für die effiziente und einfache BenutzerInnenverwaltung in We-banwendungen und wurde in der Version 2.0 von der Internet Engineering Task Force (IETF)spezifiziert[36]. Der Vorteil von OAuth ist folgender: läuft eine Anwendung rein als Webanwen-dung, und möchte ein Client solch eine Webanwendung verwenden, so muss er sich bei jedemeinzelnen Aufruf bei diesem Service authentifizieren. Das ist nicht nur umständlich für den/dieBenutzerIn, sondern auch ressourcenintensiv für den Server. OAuth 2.0 bietet hier die Mög-lichkeit mit einem Zugriffsschlüssel, dem sogenannten Access Token, die Authentifizierung aufeinen vertrauenswürdigen Server auszulagern. Abbildung 14 stellt den Ablauf schematisch dar.

Der Ablauf im Detail:

1 Zuerst registriert sich das FHIR-Sicherheitssystem bei einem vertrauenswürdigen OAuthAnbieter xyz, und erhält im Gegenzug einen Sitzungsschlüssel[11] server-key undeine ID.

52

Abbildung 14.: OAuth Schema Ablauf

2 Möchte nun ein/eine BenutzerIn via FHIR-Client auf unser FHIR-Repository zugreifen, sowird die Anfrage an das FHIR-Sicherheitssystem weitergeleitet, und im Gegenzug wirdder/die BenutzerIn aufgefordert, sich beim oAuth Authentifizierungsserver xyz anzumel-den.

3 Der/die BenutzerIn meldet sich beim oAuth Authentifizierungsserver xyz an, und dieser

4 stellt einen Sitzungsschlüssel client-key für den FHIR-Client aus.

5 Bei jeder Anfrage des Benutzers an das FHIR-Repository überprüft der FHIR-Sicherheitsserver über den oAuth API-Server, ob der übermittelte Schlüssel client-keygültig ist.

6 Stimmt der Schlüssel überein, so ist der/die BenutzerIn erfolgreich authentifiziert.

Soweit die Theorie. In der Praxis gibt es zu OAuth einige umstrittene Meinungen. In derVersion 1.0 war das Protokoll sehr einfach, und wurde deshalb innerhalb weniger Jahre vongroßen Anbietern (Google, Facebook, Dropbox u.a.) aufgegriffen und implementiert. Im Jahr2009 übernahm die IETF die Aufgabe die Version 2.0 von OAuth zu spezifizieren. Im Jahr 2012warf mit Evan Hammer einer der Hauptentwickler nach drei Jahren der Spezifikation das Hand-tuch, und wetterte öffentlich gegen die neue Version. Sie sei unzureichend, weniger nützlich,komplizierter, und nicht so sicher wie die Vorgängerversion. Neben Hammer haben auch nochandere Entwickler das Team verlassen, und seither ist es etwas ruhig um OAUth geworden.

In Bezug auf FHIR und medizinische Daten stellt sich zudem die Frage, welche Institutio-nen überhaupt rechtlich in der Lage wären, diese oAuth Authentifizierung durchzuführen. InÖsterreich würden dafür wohl lediglich zertifizierte Gesundheitsdiensteanbieter (GDA) in Fragekommen.

53

5.2. Schutzziel der Datenintegrität

Unter Datenintegrität ist gemeint, dass es weder Personen noch Systemen möglich sein soll,ohne Autorisierung und unbemerkt Daten zu verändern. Die Anforderung der Datenintegrität istin FHIR vor allem durch die Sicherheitsbeschreibungen auf Ressourcenebene geregelt. (vgl.ref Kap. 2.6). Die Vertraulichkeitsstufen regeln dabei den grundlegenden Zugriff auf Ressour-cen und die Vertraulichkeitsregeln im speziellen die Verwendung im Kontext der Verwendungund der aufrufenden Person. Sofern medizinisch notwendig, können in FHIR diese Regeln überdie Notfall-Sicherheitsbeschreibung überschrieben werden, dieser Vorgang wird jedoch nebendem allgemeinen Protokoll auch noch ins Sicherheitsprotokoll aufgenommen. Es soll zudemnicht möglich sein, dass sich Daten während der Verarbeitung verändern. Hier werden Signa-turen verwendet, um überprüfen zu können, ob Informationen des Senders auch unverändertbeim Empfänger ankommen. FHIR unterstützt hier insgesamt siebzehn unterschiedliche Co-des für Signaturen[42]. Diese Codes wurden aus dem American Society for Testing and Materi-als (ASTM) Standard E1762-95(2013)[48] abgeleitet. Die Datenintegrität ist in FHIR somit zwarvorgesehen, aber nur in Verbindung mit einem Sicherheitssystem auch voll funktionell.

5.3. Schutzziel der Informationsvertraulichkeit

Ein System gilt im Allgemeinen als informationsvertraulich, wenn es unautorisierten Objek-ten oder Subjekten nicht möglich ist, an Informationen zu gelangen. In FHIR wird die Infor-mationsvertraulichkeit durch die Vertraulichkeitsstufen (siehe Kapitel 2.8.2) geregelt. Gemäßder Definition ist das Schutzziel der Datenintegrität jedoch nicht gänzlich erfüllt, weil der Zu-griff nicht ausschließlich technisch geregelt werden kann, sondern immer auch von der ord-nungsgemäßen und korrekten Verwendung dieser Labels beim Client ausgeht. Als Beispiel desCoreSecurityLabels DELAU können wir klar sehen, dass wir uns zwar wünschen, dass einClient diese Ressource nach Verwendung löscht, aber es keinerlei technische Möglichkeitengibt, das durchzusetzen oder zu kontrollieren. Auf technischer Basis ist die Informationsver-traulichkeit durch Verschlüsselung zu erzielen. Als Webanwendung bietet FHIR hier zwar alleMöglichkeiten verschlüsselter Verbindungen, diese sind jedoch im Framework nicht eigens in-tegriert, und werden auch für die Implementierung nicht grundlegend vorgeschrieben sondernnur empfohlen. Letztendlich sind sie ausschließlich von der Implementierung abhängig.

5.4. Schutzziel der Verfügbarkeit

Verfügbare Systeme zeichnen sich dadurch aus, dass sie weder durch unautorisierte, nochdurch autorisierte Personen oder Systeme in ihrer Funktionalität beeinträchtigt werden können.In der Regel werden Systeme erst durch entsprechende Implementierung meist in Form vonredundanten Systemen ausfallsicher oder hochverfügbar. Trotzdem lassen sich nicht alle Syste-

54

me in gleichem Ausmaß hochverfügbar implementieren. FHIR als REST(ful) implementiertesSystem erfüllt diese Voraussetzungen hervorragend. Einer der Hauptvorteile von REST ist dieeinfache Skalierbarkeit. Je nach Implementierung können Endpunkte unabhängig voneinanderbetrieben werden, ohne sich gegenseitig zu beeinflussen. Änderungen an einzelnen Ressour-cenendpunkten haben somit keine Auswirkungen auf andere Endpunkte. Auch die Erweiterungder Funktionalität von Endpunkten wirkt sich in der Regel nicht auf bestehende Systeme aus.Diese funktionieren weiterhin, außer sie werden händisch als veraltet und nicht mehr zu ver-wenden eingestuft. Durch diese Methodik ist auch die laufende Erweiterung und Aktualisierungvon FHIR Instanzen und vor allem auch die Kompatibilität von unterschiedlichen Clients ge-währleistet. Das Ziel der Verfügbarkeit ist mit dem FHIR Framework also gänzlich erfüllt.

5.5. Schutzziel der Verbindlichkeit

Unter Verbindlichkeit ist zu verstehen, dass es nicht möglich sein darf, dass ein Client oder einSystem nach der Manipulation einer Ressource dies bestreitet. Das ist in der FHIR API genau-so wichtig, wie zum Beispiel in einem Webshop als Kaufbeleg. Mit den InfrastrukturressourcenProvenance und SecurityEvent ist dies insofern gewährleistet, indem jede Veränderungeiner Ressource protokolliert wird. Diese Protokolle können mittels Such- und Filterfunktionenausgewertet werden, und dienen zweifelsfrei als Nachweis der Verbindlichkeit. Zusätzlich kön-nen Signaturen als Nachweis der Quelle der Information dienen. Das Ziel der Verbindlichkeit istim FHIR Framework ebenfalls erfüllt.

5.6. Schutzziel der Anonymisierung und Pseudomisierung

Das Schutzziel der Anonymisierung bezieht sich im Allgemeinen auf die Unmengen an Me-tadaten, welche wir tagtäglich im Internet hinterlassen. Wir verwenden das freie WLAN desCafes zum Surfen, wir schreiben Nachrichten über private Nachrichtendienste oder teilen un-sere Position und unseren derzeitigen Gemütszustand als Statusnachricht in unseren sozialenProfilen. Nicht nur im Internet werden diese Profile von uns erstellt. Sogar beim täglichen rou-tinemäßigen Lebensmitteleinkauf werden Kundenkarten genutzt, um unser Kaufverhalten zuanalysieren, und diese Informationen für eigene Werbezwecke zu verwenden, oder an Firmen,die mit der massenhaften Auswertung dieser Metadaten bestens vertraut sind, gewinnbringendweiterzuverkaufen. Speziell im Kontext des FHIR Frameworks sehe ich das Schutzziel wedererfüllt, noch gefordert. Es ist in dieser Anforderung auch nicht anwendbar. Trotzdem bieten ver-netzte Systeme prinzipiell die Möglichkeit, Daten auch für weitere Zwecke zur Verfügung zustellen. Sowohl in Österreich1, als auch in Europa2 gibt es entsprechende Open Data Projekte,welche Metadaten anonymisiert und für jeden abrufbar bereitstellen.

1https://www.data.gv.at [Zugriff am 19.04.2015]2http://publicdata.eu/ [Zugriff am 19.04.2015]

55

https://www.data.gv.at

http://publicdata.eu/

5.7. Übersichtstabelle geforderte Schutzziele

In Tabelle 7 werden die Ergebnisse der Schutzzielbewertung nochmals in einer Übersicht zu-sammengefasst:

Schutzziel FHIRFramework

FHIR Sicher-heitssystem

Extern Bemerkung

Authentizität nicht erfüllt möglich oAuth Erst durch ein entsprechendes Sicher-heitssystem vorhanden. Optional zu-sätzlich durch oAuth möglich.

Datenintegrität vorgesehen möglich Durch Signaturen zwar möglich, abervolle Funktionalität nur durch das Si-cherheitssystem gewährleistet.

Vertraulichkeit nicht erfüllt unterstützend In FHIR nicht gänzlich erfüllt. Auchim Sicherheitssystem nicht vorgese-hen. Administrativ mittels verbindli-cher Rahmenverträge zwischen FHIRSystemen geregelt. Technisch durchVerschlüsselung zu erzielen.

Verfügbarkeit erfüllt Als REST(ful) Webservice in der Regelsehr einfach als hoch verfügbar undhoch skalierbar zu implementieren

Verbindlichkeit erfüllt Durch die Infrastrukturressourcen ge-regelt. Können durch Signaturen un-terstützt werden.

Anonymisierungund Pseudomisie-rung

nichtanwendbar

Anonymisierung ist im Kontext vonFHIR kein Schutzziel.

Tabelle 7.: Tabellenübersicht Schutzziele

56

6. Open Web Application Security Project(OWASP)

Das Open Web Application Security Project, in Folge einfach OWASP genannt ist ein weltwei-tes gemeinnütziges Projekt, und wurde 2001 in den USA auch unter gesetzlicher Vorschrift501(c)(3)[49] als OWASP Foundation auch als solches festgelegt. In Europa ist die OWASPEurope mit Sitz in Belgien seit Jänner 2003 tätig[78]. Lokale Niederlassungen in Form vonVereinen gibt es noch in Frankreich, Norwegen und der Schweiz[80].

Das primäre Ziel ist ist die Verbesserung der Sicherheit in der Informationstechnologie. Da-für stellt OWASP viele Tools und Methoden zur Verfügung, die es erlauben, die sicherheits-kritischen Faktoren zu erkennen, und diese in Anwendungen auch richtig zu bewerten, umanschließend ein daraus resultierendes Bedrohungsrisiko abzuleiten. Zudem sollen Entwicklerauch an das Thema der Erschaffung sicherer Anwendungen herangeführt werden, und Feh-ler zukünftiger Anwendungen bereits im Design oder vor Implementierung vermieden werden.Alle Methoden und Tools die OWASP dafür veröffentlicht sind frei zugänglich, und dürfen alsCreative Common 3.0 Lizenz[15] auch weiter verwendet werden.

Neben den Werkzeugen stellt OWASP auch regelmäßig eine Liste mit den weltweit zehn häu-figsten und gefährlichsten Sicherheitsrisiken in Webanwendungen im OWASP Top 10 Projektzur Verfügung. Diese Liste wird von der breit aufgestellten Gemeinschaft an Sicherheitsexper-ten akkordiert zusammengestellt, und enthält neben den Risiken auch gleich die notwendigenInformationen zur Erkennung und Vermeidung, wodurch sie selbst auch wieder zum Werkzeugfür Entwickler und Techniker gereicht. Seit 2008 gelten die Top 10 sogar als offizielle Vorgabenfür den Payment Card Industry (PCI) Data Security Standard, so dass bei Code Reviews nach-gewiesen werden muss, dass geeignete Maßnahmen zur Abwehr der in der Top 10 gelistetenSchwachstellen und Verwundbarkeiten getroffen wurden.

Das hehre Ziel von OWASP ist es, dass jeder Programmierer oder Betreiber von Webanwen-dungen sich der Risiken zumindest bewusst ist, und auch die notwendigen Schritte unternimmt,diese Systeme entsprechend diesen Empfehlungen zu optimieren. In den folgenden Kapitelnwerden diese Top 10 Bedrohungen erklärt, analysiert und ihre Anwendbarkeit und Relevanzauf das FHIR Framework bewertet.

6.1. OWASP Risk Rating Method

Um festzustellen, wie gefährlich oder ungefährlich eine mögliche Bedrohung ist, muss derenRisiko festgestellt werden. In verschiedenen Kulturen und Disziplinen wird Risiko oftmals un-

57

terschiedlich definiert, aber eines haben fast alle Definitionen gemeinsam: Ein Risiko setzt sichimmer aus einem Ereignis mit einer Eintrittswahrscheinlichkeit, und dessen positiver oder ne-gativer Auswirkung zusammen[106][89].

Risk = Likelihood ∗ Impact

Sicherheitslücken in Softwaresystemen aufzufinden, ist äußerst schwierig und wichtig, abergenauso wichtig ist es korrekt einzuschätzen, welche Risiken damit verbunden sind, und welcheAuswirkungen sie haben.

6.1.1. Finden von Bedrohungen (Threat Modeling)

Bereits in den frühen Phasen des Designs und der Entwicklung von Anwendungen könnenBedrohungen identifiziert, und Schwachstellen vermieden werden. Voraussetzung dafür ist na-türlich, dass die handelnden Personen mit der Thematik vertraut sind, und entsprechendenFokus darauf setzen[91]. Oftmals werden Sicherheitsprobleme erst im Zuge der Qualitätssi-cherung in Form von Reviews aufgedeckt, oder durch entsprechende Stresstests (PenetrationTest). Viel wahrscheinlicher ist es, dass diese Sicherheitslücken erst im produktiven Betriebgefunden, und bis zu diesem Zeitpunkt bereits in schädigender Weise ausgenutzt werden.

Die wichtigste Aufgabe beim korrekten Threat Modeling ist die konsequente Beachtung dermöglichen Sicherheitsrisiken über den gesamten Entwicklungszeitraum hindurch. Die Analyse-phase beginnt noch vor der ersten Programmzeile bereits im Designprozess, und je weiter eineSoftware programmiert wird, und mit jeder neuen Codezeile oder Funktion, sollte diese Betrach-tung aktualisiert, und eventuell neue Bedrohungen identifiziert werden. Die Vorgehensweise istdabei immer dieselbe, auch wenn sich die Abstraktionsebene immer weiter vertieft[91].

AS Assessment Scope: Die Bewertung des Kontextes steht dabei immer zu Beginn der Be-trachtung. Wo liegt eventuell ein Risikopotential? Neben den deutlichen Risiken, wie ver-trauliche Informationen in Datenbanken oder Zugriffen auf Dateiservern, geht es hier auchum die Programm und Funktionslogik selbst. Können die BenutzerInnen das Programmeventuell bewusst falsch bedienen, um an Informationen zu gelangen? Sind alle Zugriffeausreichend abgesichert? Jede geplante Funktionalität sollte aus der Sicht eines Angrei-fers bedacht werden.

SM System Modeling: Der nächste Schritt befasst sich mit den möglichen Angreifern auf einSystem. Jeder Angreifer ist dabei einer Bedrohungsgruppe zuzuordnen[90]. Diese Bedro-hungsgruppe setzt sich aus den Fähigkeiten des Angreifers, seiner Absicht und seinenfrüheren Aktivitäten zusammen. Mögliche Bedrohungsgruppen können so aussehen:

– Nicht Zielspezifisch: Computerviren, Würmer, Trojaner

– Angestellte: Mitarbeiter, Auftragsnehmer, Wartungspersonal, Sicherheitsleute wel-che der Firma Schaden zufügen wollen

58

– Organisiertes Verbrechen: Meistens mit dem Ziel an Bankdaten, Kreditkartendatenoder geistiges Eigentum (Software-Prototypen) zu gelangen, die einfach in Geld um-gewandelt werden. Oftmals helfen dabei Insider.

– Andere Unternehmen: Eventuell Konkurrenzunternehmen mit dem Ziel eines Wett-bewerbsvorteils, aber auch Partnerfirmen.

– Menschen (unbeabsichtigt): Durch Nachlässigkeit oder Unfälle

– Menschen (absichtlich): Insider, Außenseiter im Unternehmen

– Naturkatastrophen: Feuer, Blitz, Überschwemmungen, Erdbeben

IT Identify Threats: Aus der Liste der Bedrohungsgruppen durch das System Modeling (SM)und der Funktionalität der Anwendung durch den Assessment Scope (AS), lassen sichnun mögliche Angriffe ableiten (siehe vollständige Liste aller OWASP Angriffe im AnhangF). Ein möglicher Angriff wäre dabei zum Beispiel ein Brute-Force Angriff[81], bei demversucht wird, durch unzählige Versuche nach möglichen Zugangsinformationen (Benut-zerInnenname/Kennwort) einen legitimen Zugriff auf ein System zu erlangen. Jeder die-ser möglichen Angriffe wird dabei durch vier Punkte beschrieben. Zuerst wird der Angriffdurch einen einzigen Satz beschrieben. Dann folgt eine Erklärung, wie der Angriff gest-artet werden kann. Darauf erfolgt die Zuteilung zu den wahrscheinlichsten Bedrohungs-gruppen. Zu guter Letzt wird noch erklärt, durch welche Schwachstellen dieser Angriffausgenutzt werden kann. In dieser Betrachtungsphase sollen auch gleich die möglichenSchutzmaßnahmen mit einfließen. Eine geeignete Schutzmaßnahme kann auch einenFehler im Design sehr gut gegen Angriffe abschirmen. Typische Schutzmaßnahmen sindin der Regel Authentifizierung, Zugriffskontrolle, Sitzungsmanagement, Validierung vonEingaben, Fehlerbehandlung, Protokollierung und Verschlüsselung.

IV Identify Vulnerabilities: Da nun die möglichen Angriffe und die Angriffsziele bekannt sind,lassen sich eventuell unbekannte verwundbare Schwachstellen in der Software identifi-zieren, und die dafür notwendigen Angriffe verhindern. Für die Schwachstellenanalyseist das Projekt OWASP Top 10 primär geeignet, da es die wahrscheinlichsten Angriffs-vektoren aufzeigt, und Tools und Methoden bereitstellt, diese Programmteile auch gleichabzusichern. Dabei sollte aber nicht vergessen werden, dass es noch weitere Bedrohun-gen gibt.

EIB Evaluation or Impact on the Business: Zu guter Letzt werden noch die möglichen Auswir-kungen auf das Geschäftsmodell betrachtet. Mögliche Einschränkungen der Verfügbar-keit, zum Beispiel bei einem Denial of Service (DoS) Angriff[74], Verletzungen der Ver-traulichkeit oder Integrität, eventuell damit einhergehende rechtliche Verpflichtungen bishin zum Vertrauensverlust und Schadenersatzansprüchen. Gerade die möglichen Aus-wirkungen sind nicht einfach zu spezifizieren, geben aber dennoch einen Aufschluss überdie Tragweite der Sicherheitsbedrohung.

59

6.1.2. Berechnungsmodell Eintrittswahrscheinlichkeit

Da nun alle potentiellen Risiken hinreichend bekannt sind, wird im nächsten Schritt ihre Eintritts-wahrscheinlichkeit bewertet. Zu Beginn wird jedes Risiko einer groben Bewertung unterzogen.Hier reicht die Festlegung der Wahrscheinlichkeit auf die Werte l (low), m (medium) oder h(high). Für jedes dieser Risiken und ihrer Grobeinschätzung wird im nächsten Schritt die Be-drohungsgruppe mit betrachtet. Dabei geht es primär um die Bedrohungsgruppen, denen esmöglich ist, einen Angriff auch wirklich durchzuführen, und nicht nur zu versuchen. Für jedesRisiko kann es mehrere Bedrohungsgruppen geben. Hierbei ist für die korrekte Bewertung vomschlechtesten Fall (worst case) in der Betrachtung auszugehen. Zum Beispiel kann eine Kom-promittierung durch einen Mitarbeiter eventuell viel wahrscheinlicher sein, als ein Angriff durcheinen Unbekannten. Das hängt allerdings wiederum von verschiedenen Faktoren ab. Jeder die-ser Faktoren hat eine Wertigkeit von null bis neun, und diese werden für die Gesamtberechnungder Eintrittswahrscheinlichkeit herangezogen.

Angriffsfaktoren (Threat Agent Factors)

Die erste Gruppe der Faktoren bezieht sich dabei auf die Bedrohungsgruppen. Die Bewer-tungskriterien im Einzelnen nach dem OWASP Risk Rating Model[89]:

Fachwissen Die technischen Fertigkeiten spielen eine große Rolle. Experten bei Penetration- undStresstests (1), Netzwerktechniker und Programmierer (3), erfahrener Computerbenut-zerIn (4), technisches Verständnis (6), keine technischen Erfahrungen (9)

Motivation Wie motiviert ist die Gruppe, um mögliche Sicherheitsrisiken zu finden? Nicht sonderlichmotiviert, geringe Belohnung (1), mögliche Belohnung (4), hohe Belohnung (9)

Möglichkeit Welche Ressourcen sind notwendig, und welche Möglichkeiten hat die Gruppe, um aufdiese Sicherheitslücke aufmerksam zu werden, und sie auch aktiv auszunutzen? VollerZugriff, und professionelle teure Ausrüstung (0), spezieller Zugriff und Ausrüstung (4),allgemeiner Zugriff mit 08151 Ausrüstung (7), kein Zugriff oder keinerlei Ausrüstung not-wendig (9)

Größe Wie groß ist die mögliche Bedrohungsgruppe? Entwickler, SystemadministratorIn (2),Intranet-BenutzerIn (4), Geschäftspartner (5), Authentifizierte BenutzerIn (6), anonymeInternetbenutzerInnen (9)

Verwundbarkeitsfaktoren (Vulnerability Factors)

Im nächsten Schritt werden die Verwundbarkeitsfaktoren ermittelt. Dazu werden die möglichenSicherheitsrisiken herangezogen, und für vorhin wahrscheinlichste Bedrohungsgruppe ausge-rechnet. Hier wieder die Betrachtungsliste[89]:

1http://de.wikipedia.org/wiki/08/15_(Redewendung) [Zugriff am 19.04.2015]

60

http://de.wikipedia.org/wiki/08/15_(Redewendung)

Wie einfach ist es für diese Gruppe diese Sicherheitslücke zu finden? Praktisch unmöglich(1), schwer (3), einfach (7), mittels automatischer Tools (9)

Wie einfach ist es für diese Gruppe, diese Sicherheitslücke auch praktisch auszunutzen?Theoretisch möglich (1), schwer (3), einfach (5), automatische Tools verfügbar (9)

Wie bekannt kann diese Lücke für diese Gruppe bereits sein? Unbekannt (1), versteckt(4), offensichtlich (6), öffentlich (9)

Würde eine Kompromittierung dieser Sicherheitslücke erkannt werden? Aktive Erkennungin der Anwendung (1), protokolliert und aktiv gemeldet (3), protokolliert aber nicht über-wacht (8), nicht protokolliert (9)

6.1.3. Berechnungsmodell Auswirkung (Factors for Estimating Impact)

Bei der Berechnung der Auswirkungen werden zwei Betrachtungen herangezogen. Die mögli-chen technischen Auswirkungen, und die möglichen Auswirkungen auf das Geschäftsmodell.Die geschäftlichen Auswirkungen sind in der Regel viel gravierender als die technischen. Leiderstehen in der Regel nicht alle Kennzahlen und Hintergrundinformationen für die korrekte Bewer-tung zur Verfügung, weswegen es umso wichtiger ist, die technischen Auswirkungen korrekt zubeziffern, um jemanden mit den notwendigen wirtschaftlichen Informationen die geschäftlichenAuswirkungen bewerten zu lassen. Die Faktoren reichen wieder von 0 bis 9.

Technische Faktoren

Die technischen Faktoren lassen sich sehr generisch auf die bereits bekannten Schutzziele inder Informationstechnologie reduzieren[89]:

Vertraulichkeit: Wie viele Daten würden dadurch offengelegt, und wie heikel sind diese?Wenige, und keine vertraulichen Daten (2), wenige aber kritische Daten (6), viele Datenaber keine sensiblen (6), viele kritische Daten (7), alle Daten (9)

Integrität: Wie viele Daten könnten beschädigt werden, und wie stark? Wenige Daten,minimale Schäden (1), wenige ernsthaft beschädigte Daten (3), viele leicht beschädigteDaten (7), viele umfangreich beschädigte Daten (7), alle Daten vollständig beschädigt (9)

Verfügbarkeit: Wie viele Dienste könnten davon betroffen sein, und wie wichtig sind die-se? Wenige unwichtige Dienste betroffen (1), wenige wichtige Dienste betroffen, vieleunwichtige (5), einige wichtige Dienste betroffen (5), viele wichtige Dienste betroffen (7),alle Dienste vollständig betroffen (9)

Verantwortlichkeit: Können die Aktionen einer Person zugeordnet werden? Völlig zuzu-ordnen (1), möglicherweise zuzuordnen (7), völlig anonym (9)

61

Geschäftliche Faktoren

Die geschäftlichen Auswirkungen durch Sicherheitsbedrohungen leiten sich zwar direkt aus dentechnischen Bedrohungen ab, es bedarf allerdings einem tiefen Verständnis des Geschäftsmo-delles und der Geschäftslogik, um diese Auswirkung zu beziffern. In jedem Unternehmen oderGeschäftsmodell gibt es Kernaufgaben, ohne welchen ein regulärer Betrieb nicht fortgeführtwerden kann. Diese Kernaufgaben gilt es zu schützen, und die möglichen Schäden zu bezif-fern. Dadurch lassen sich auch Investitionen in die Sicherheit einer Anwendung rechtfertigen.Nicht jedes Unternehmen ist gleich aufgestellt, und die Bewertung hängt von vielen Faktorenab, aber grundlegend gilt es, folgende Punkte zu bewerten[89]:

Finanzieller Schaden: Wie groß wäre der finanzielle Schaden durch einen Exploit (Ein-bruch)? Weniger, als das Beheben der Sicherheitslücke kostet (1), geringer Effekt auf dasjährliche Budget (3), großer Effekt auf das jährliche Budget (7), Bankrott oder Insolvenz(9).

Reputation: Würde ein Exploit dem Ruf der Firma schaden und das Geschäft beeinträch-tigen? Geringer Schaden (1), Verlust von Großkunden (4), Verlust des guten Rufes (5),Beschädigung der Marke (9)

Gesetzeslage: Welche rechtliche Verantwortung könnte für das Unternehmen durch die-se Sicherheitslücke entstehen? Geringe Verletzung der Gesetzeslage (5), klare Verlet-zung des Gesetzes (5), Grobe Fahrlässigkeit (9)

Privatsphäre: Von wie vielen Personen könnten vertrauliche Daten übermittelt werden?Einzelne (3), hunderte (5), tausende (7), Millionen (9)

6.1.4. Berechnung des Gesamtrisikos

Im nächsten Schritt wird ein Gesamtrisiko für jede Bedrohung bewertet. Dazu werden die er-mittelten Werte aus der Eintrittswahrscheinlichkeit und der Auswirkung herangezogen. Das ge-schieht jeweils durch die Berechnung des Mittelwertes der Eintrittswahrscheinlichkeit, und dermöglichen Auswirkung pro Angriffsvektor. Dazu ein Beispiel. Es werden alle Faktoren der Be-drohungsgruppen und der Verwundbarkeiten laut den Katalogen festgelegt, aufsummiert, undanschließend ein Durchschnittswert für Eintrittswahrscheinlichkeit errechnet (siehe Tabelle 8).

Bedrohungsfaktoren Verwundbarkeitsfaktoren

Können Motivation Möglichkeit Größe Finden Ausnützen Bekanntheit Erkennen

5 2 7 1 3 6 9 2

Durchschnittliche Wahrscheinlichkeit = 4.375 (mittel)

Tabelle 8.: Berechnung der durchschnittlichen Wahrscheinlichkeit

62

Nun werden die Auswirkungen bewertet. Die Summe der technischen Auswirkungen unddie Summe der geschäftlichen Auswirkungen werden dabei einzeln ermittelt, und getrennteAuswirkungsfaktoren ermittelt (siehe Tabelle 9).

Auswirkung technisch Auswirkung geschäftlich

Vertraulichkeit Integrität Verfügbarkeit Verantwortlichkeit Finanziell Reputation Gesetzlich Privatsphäre

9 7 5 8 1 2 1 5

Durchschnittlich technisch = 7.25 (hoch) Durchschnittlich geschäftlich = 2.25 (niedrig)

Tabelle 9.: Berechnung der Auswirkungen (technisch, geschäftlich)

Anschließend wird der für jede Bedrohung ermittelte Wert noch über ein Umschlüsselungs-tabelle in drei grobe Bereiche eingeteilt (siehe Tabelle 10):

Wahrscheinlichkeit, Auswirkung

0 bis <3 gering

3 bis <6 mittel

6 bis 9 hoch

Tabelle 10.: Bewertungsskala Wahrscheinlichkeit und Auswirkung

Mit den Ergebnissen beider Betrachtungen (Wahrscheinlichkeit und Auswirkung) kann nundas Gesamtrisiko der Bedrohung ermittelt werden (siehe Tabelle 11). Bitte beachten: Soferngenaue Informationen und Kennzahlen zur geschäftlichen Betrachtung vorliegen, sollte dieseherangezogen werden. Liegen diese Daten jedoch nicht vor, so ist die technische Betrachtungwahrscheinlich zielführender.

Durchschnittliches Gesamtrisiko

Auswirkung

hoch mittel hoch kritisch

mittel gering mittel hoch

gering sehr gering gering mittel

gering mittel hoch

Eintrittswahrscheinlichkeit

Tabelle 11.: Berechnungstabelle für den Schweregrad

Im gezeigten Beispiel ist die Eintrittswahrscheinlichkeit mittel, und die technische Auswir-kung hoch, wodurch sich bei einer rein technischen Auswirkung das Gesamtrisiko als hochherausstellt. Bei zusätzlicher Betrachtung der geringen Auswirkungen auf das Geschäftsmo-dell, könnte die Entscheidung jedoch auch anders ausfallen. Gerade die Betrachtung beiderWelten (technisch und finanziell) erlaubt es erst, eine gute Aussage für die Risikobewertung

63

abzugeben. Diese Gesamtaussage ist ja schließlich die Basis für die daraus resultierendenRisikoentscheidungen.

6.1.5. Umgang mit Bedrohungen

Oder vereinfacht ausgedrückt: Was wird repariert oder verbessert. Nachdem nun alle Risikenbekannt, und mit den gerade erklärten Methoden durchgängig klassifiziert sind, kann eine prio-risierte Gefahrenliste erstellt werden.

Nicht alle Risiken auf dieser Liste werden auch tatsächlich beseitigt. Es hilft nichts, die un-wichtigen Risiken zu vermeiden, und die schweren zu belassen. Dadurch verbessert sich dieGesamtrisikobetrachtung in keiner Weise. Vor allem die Kosten spielen dabei eine entschei-dende Rolle. Ein Risiko zu vermeiden, das in der Entwicklung 100.000.- EUR kostet, aber proJahr nur den Betrug von wenigen 100.- EUR verhindert, wird kein Finanzverantwortlicher frei-geben. Nichtsdestotrotz sind durch die durchgängige Betrachtung aber alle Risiken bekanntund dokumentiert, und werden je nach gewählter Risiko-Akzeptanzlinie[56] auch beachtet undzu rechtfertigen.

6.1.6. Adaptierung des Risikomodells

Das soeben vorgestellte Risikomodell kann natürlich nicht eins zu eins über alle Geschäfts-felder und Webanwendungen gelegt werden. Es wird immer wieder Einsatzbereiche geben, indenen es adaptiert wird, mit zusätzlichen Kennfaktoren erweitert, oder einfach die Gewichtungauch grundlegend umgestellt wird. Es bietet jedoch eine solide Basis, aufgrund dessen eine ge-wichtete Aussage für die Sicherheit und Verwundbarkeit einer Software getätigt werden kann,und kann helfen, das Gesamtrisiko eines potentiellen Schadens deutlich zu minimieren.

Es gibt in der freien Natur (in the wild) mittlerweile auch viele automatisierte Tools welchedieses Threat Modeling vornehmen. Das Hauptproblem dieser Automatismen ist meistens,dass sie durch Aggregation tausender Angriffsmöglichkeiten und potentieller SchwachstellenUnmengen an Daten und Bedrohungen erzeugen. Viel zielführender ist es hier, diese Absiche-rungen zumindest für jene Bedrohungen durchzuführen, die entsprechenden Schaden verur-sachen, und auch wahrscheinlich sind.

6.1.7. Alternative Modelle

Natürlich gibt es neben dem OWASP Risikomodell noch andere, auch wenn sie sich nicht völliggrundlegend voneinander unterscheiden. Der Vollständigkeit halber wird in dem Zusammen-hang noch auf das Fair-Risk Modell von CxoWare[105], und auf das Microsoft Risiko Modell[70]verwiesen. Bei der Betrachtung und Bewertung des FHIR Frameworks wurde jedoch nur dieOWASP Methode angewendet.

64

6.2. OWASP Top 10 Liste

Da nun alle Faktoren für eine korrekte Risikobewertung bekannt sind, kann die aktuelle OWASPTop 10 Liste aus dem Jahr 2013 (zum Zeitpunkt 1. Quartal 2015 der aktuellste Stand) heran-gezogen werden, um das spezifische Sicherheitsrisiko des FHIR Frameworks zu ermitteln. Na-türlich sollte für eine umfassende Sicherheitsbetrachtung die gesamte Liste der Bedrohungeneinbezogen werden (siehe Liste im Anhang F), aber diese Master These betrachtet speziell nurdie Top 10 Liste.

Zur Erinnerung: Jeder potentielle Angreifer sucht mögliche Angriffsvektoren, um eine Sicher-heitslücke zu finden, und in weiterer Folge diese aktiv auszunutzen, um an Informationen oderDaten zu kommen. Diese haben primär das Ziel, in Geld umgewandelt zu werden, können aberauch nur die Absicht nach sich ziehen, dem Unternehmen Schaden zuzufügen. Die Abbildung15 zeigt den Ablauf nochmals in der schematischen Übersicht.

Abbildung 15.: OWASP Angriffsverlauf (Quelle http://owasptop10.googlecode.com/files/OWASP Top 10- 2013.pdf)

Für jedes einzelne Element der OWASP Top 10 Liste liegt ein Risikoprofil bereit, welches wiein Tabelle 12 abgebildete Bewertungen enthält.

Bedrohungsgruppen Angriffsvektoren Häufigkeit derSchwäche

Erkennung derSchwäche

TechnischeAuswirkung

Geschäftliche Auswirkung

Anwendungsspezifisch

einfach weit verbreitet einfach schwer Anwendungsspezifisch,abhängig vom

Geschäftsmodellmittel häufig mittel mittel

schwer selten schwer gering

Tabelle 12.: OWASP Risikoprofil (Quelle http://owasptop10.googlecode.com/files/OWASP Top 10 -2013.pdf)

Für jedes ermittelte Risiko muss also nur mehr die Anwendbarkeit auf die Liste eruiert wer-den, und gegebenenfalls die Bedrohungsgruppen gemeinsam mit den möglichen geschäftli-

65

chen Auswirkungen gemeinsam bewertet werden, um eine sortierte und priorisierte Gefahren-liste zu erstellen.

6.2.1. A1 - Injection

Wie der Name schon sagt, gelingt es dem Angreifer durch diesen Angriff, einen Befehl oder einKommando welches zur Ausführung gelangt, einzuschleusen oder zu manipulieren, um so un-erwünschte Befehle auszuführen. Angriffe mittels Injektion treten vorwiegend auf StructuredQuery Language (SQL) Datenbanken auf, und dort zum Beispiel bei einer unsicheren An-meldung in einer Webanwendung. Sie können aber auch durch Injektion direkter Befehle andas Betriebssystem oder andere Verzeichnisdienste wie Lightweight Directory Access Protocol(LDAP)[102] erfolgen. Das von OWASP Top 10 bereits festgelegte Risikoprofil für Injectionzeigt ganz offensichtlich die Gefahren dieser Bedrohung in ihrer Verbreitung, und die Einfach-heit des Angriffs (siehe Tabelle 13). Der Angriff selbst ist dabei Text-basierend und kann vonvielfältigen Quellen (internen und externen) ausgeführt werden. Die Auswirkungen können da-bei beträchtlich sein. Daten können gelesen, kopiert, manipuliert oder auch beschädigt werden.Ein Angreifer könnte sogar dadurch eventuell den Server selbst übernehmen.





Anwendungsspezifisch einfach häufig mittel schwerAnwendungsspezifisch,

abhängig vomGeschäftsmodell

Tabelle 13.: OWASP Risikoprofil A1 - Injection (Quelle http://owasptop10.googlecode.com/files/OWASPTop 10 - 2013.pdf)

Die Anfälligkeit einer Software für Injektion kann am einfachsten über die Analyse des Quell-codes erfolgen. Automatisierte Tools finden selten alle Verwundbarkeiten, oder können nichtkorrekt feststellen, dass sie eine Lücke gefunden haben. Schlechte oder nicht vorhandeneFehlerbehandlung unterstützt allerdings diese automatischen Tools bei ihrer Suche. Der er-ste Schritt der Absicherung ist die syntaktische Überprüfung aller Eingabeparameter, und dieTrennung der Anwendungsebene von der Datenebene[12]. Die Prüfung der Eingabeparame-ter erfolgt gegen ein hinterlegtes Regelwerk in Form einer Gültigkeitsprüfung durch RegularExpression (REGEX). SQL Abfragen sollten keinesfalls dynamische Anfragen generieren, son-dern vorgefertigte Statements (sogenannte Stored Procedures) verwenden[52]. Anstatt Formu-laren sollten generell abgesicherte Serverroutinen in Form von APIs verwendet werden, da sieschon eine geringere Angriffsfläche bieten. Trotzdem sind auch diese hinsichtlich möglicherAngriffe abzusichern, indem dynamisch parametrierbare APIs ebenfalls auf Injektionsfehler hinüberprüft werden.

66

6.2.2. A2 - Broken Authentication and Session Management

Viele immer wieder auftretende Sicherheitslücken lassen sich auf unzureichende Authentifizie-rung und schlechte oder falsche Schlüsselverwaltung zurückzuführen. Oftmals wird es Angrei-fern zu einfach gemacht, an gültige Zugriffsmerkmale zu gelangen. Das können neben Benut-zerInnennamen und Kennwörtern auch Sitzungsschlüssel und Zertifikate sein, wodurch sichein Angreifer als legitimer/legitime BenutzerIn ausgeben kann, und dessen Rolle im Systemeinnimmt. Die Bewertung durch OWASP siehe Tabelle 14 .





Anwendungsspezifisch mittel weit verbreitet mittel schwerAnwendungsspezifisch,


Tabelle 14.: OWASP Risikoprofil A2 - Broken Authentication and Session Management (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

Authentifizierungssysteme und die Verwaltung der Sitzungsschlüssel werden in der Regeldurch die Anwendungsentwickler selbst durchgeführt. Nicht immer handelt es sich bei diesenEntwicklern auch um IT Sicherheitsexperten, und deswegen ist diese Lücke auch nach wie vorsehr stark verbreitet. Ist ein Angreifer erst einmal im System legitim angemeldet, kann er vondort aus weiteren Schaden verursachen. Die Fehler, die bei unzureichender Implementierunggemacht werden, sind dabei immer wieder dieselben. Zugangsdaten wie BenutzerInnennamenund Kennwörter werden ohne Einwegfunktionen, also unverschlüsselt in Datenbanken abgelegt(siehe Kapitel 6.2.6 Sensitive Data Exposure). Eine HASH-Funktion für sich alleine, wie siehäufig verwendet wird, entspricht dabei keiner ausreichenden Verschlüsselung. Diese Datenkönnen leicht erraten werden, da eine logische Vergabe an BenutzerInnenzugängen erfolgt,oder einfache Kennwörter schlichtweg erlaubt sind. (123456, aaaaaaaa).

Injektionen können auch auf Sitzungsschlüssel erfolgen, welche im Klartext in HTML Hea-dern mitgeschickt werden. Diese Sitzungsschlüssel sind eventuell ewig gültig, oder werdenbeim Login nicht korrekt erneuert, und beim Verlassen der Applikation nicht richtig gelöscht.Die Generierung der Kennwörter oder Sitzungsschlüssel selbst erfolgt nicht ausschließlich übersichere Verbindungen. Zum Schutz vor diesen Angriffen stehen ausreichende Hilfsmittel zursicheren Implementierung zur Verfügung. Sie müssen nur beachtet und korrekt umgesetzt wer-den. Das OWASP Application Security Verification Standard Project (ASVS) stellt dafür auchweitere Checklisten und Informationen[86] (siehe Sektion V2 [Authentifizierung] und V3 [Sit-zungsmanagement] von ASVS) zur Verfügung. Zudem sollten Authentifizierungssysteme auchgegen Cross-Site Scripting (XSS) (siehe nächster Punkt 6.2.3) abgesichert sein.

67

6.2.3. A3 - Cross-Site Scripting (XSS)

XSS ist die am weitesten verbreitete Sicherheitsbedrohung in Webanwendungen, und oft nurdeshalb möglich, da die Applikation nicht gezielt dagegen abgesichert wurde (siehe Tabelle15). Aufgrund fehlender Validierung von Eingabeparametern ist es Angreifern einfach möglichschadhafte Scripts im Webbrowser des/der BenutzerInnen auszuführen, mit dem primären Zieleinen Sitzungsschlüssel zu erlangen, oder weiteren Zugriff auf die Anwendung zu ermöglichen.Oftmals auch nur, um den/die BenutzerIn auf andere Webseiten umzuleiten, in denen weitererSchadcode geladen wird, oder weitere Angriffe auf den Computer des/der BenutzerIn versuchtwerden[22]. Die Erkennung von Anfälligkeiten gegen XSS kann einfach via Codeanalyse undTesttools durchgeführt werden.





Anwendungsspezifisch mittelsehr weitverbreitet

einfach mittelAnwendungsspezifisch,


Tabelle 15.: OWASP Risikoprofil A3 - Cross-Site Scripting XSS (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

Die Bedrohung selbst wirkt sich hier aber primär auf den Computer des/der BenutzerIn aus.Diese könnte in weitere Folge infiziert, und für weitere Angriffe verwendet werden. Die tech-nische Auswirkung auf das Unternehmen ist daher etwas geringer, es kann dadurch jedochunerlaubten Personen möglich sein, alle Funktionen zu nutzen, die ein/eine entsprechend regu-lärer/reguläre BenutzerIn auch hätte. Theoretisch können so auch sehr viele Daten entwendetoder manipuliert werden. Für das Geschäftsmodell stellt sich das Risiko daher etwas größerdar, als die rein technische Betrachtung.

Bei XSS Angriffen selbst, wird dabei zwischen den Arten STORED XSS und REFLECTEDXSS unterschieden. Die Variante Document Object Model (DOM) based XSS nimmt eine spe-ziellere Position ein.

STORED Ist die gefährlichste Form des XSS Angriffes. Dazu werden zuerst infizierte Benutze-rInnendaten durch unzureichende Überprüfung auf der Serverseite gespeichert, und imzweiten Schritt werden diese Daten abgefragt, und durch den Webbrowser des/der Be-nutzerIn interpretiert und angezeigt. Dabei wird der eigentliche Schadcode auf dem Cli-entrechner ausgeführt und abgearbeitet. Da für diesen XSS Angriff mindestens zwei An-fragen (requests) notwendig sind, wird er in der Literatur auch als Second Order XSSbezeichnet.

REFLECTED Kommt von den drei XSS Varianten am häufigsten vor. Dabei ist es dem Angreifer mög-lich, bereits durch einen einzigen request/response Aufruf einen Schadcode auszuführen.Der Angriff wird auch Non Persistant XSS oder Type 1 XSS bezeichnet. Bei Reflected XSSmanipuliert der Angreifer zum Beispiel einfach einen Link, indem er den Schadcode als

68

weiteren Parameter beim URL Aufruf ergänzt, sendet ihn via E-Mail oder veröffentlichtihn in sozialen Netzwerken. Jeder/jede BenutzerIn der/die auf diesen Link klickt, ist nunein potentielles Opfer. Werden diese zusätzlichen Parameter (sprich der Schadcode) vomServer nämlich nicht entfernt, dann werden sie beim HTML response einfach wieder demClient zurück übergeben, und der Webbrowser des Users bringt ihn zur Ausführung. DieAnfälligkeit einer Webanwendung kann ganz einfach mittels solcher manipulierten URLAufrufe überprüft werden. Die OWASP stellt dafür auch eine sehr umfangreiche Liste anmöglichen Testparametern zur Verfügung[92].

DOM BASED In diese dritte Kategorie von XSS Angriffen (in der Literatur auch manchmal als Typ 0 XSSbezeichnet) sind jene gemeint, die durch aktive Komponenten im Webbrowser währendder Seitendarstellung möglich sind[54]. Das Document Object Model (DOM) ist dabeiein strukturiertes Format, das verwendet wird, um Inhalte im Browser korrekt darzustel-len. DOM erlaubt dabei dynamische Scripts, die einem Dokument weitere Eigenschaftenzuordnen können, oder für die Anzeige einfach notwendig sein können (zum Beispielweitere Authentifizierungsdaten in Form von Sitzungsschlüsseln). Das bedeutet, dass esmittels DOM möglich ist, aktive Inhalte zu steuern. Gelingt es einem Angreifer nun die-se DOM Daten zu manipulieren, und anderen Inhalt zu laden (in dem Fall wohl weiterenSchadcode), so spricht man von einem DOM basierenden Seitenangriff. Durch die reinclientseitige Interpretation gelangen DOM basierte Angriffe in der Regel gar nicht erstzum Server, sondern werden bereits durch den Browser des/der BenutzerIn ausgeführt.Ein Angreifer könnte "#<script><alert(’DOM-XSS’)</script>" in die aufrufendeURL anhängen, und diese wird dabei nur auf dem aufrufenden Browser ausgeführt, abernicht zum Server übertragen. Auch für die Absicherung gegen DOM based XSS stelltacOWASP wieder eine Checkliste zur Verfügung[88].

Zum Absichern gegen XSS Angriffe gibt es auch einen ganz aktuellen Enwurf zu einerneuen Version der Content Security Policy (CSP) World Wide Web Consortium (W3C)[107].Diese CSP erlaubt eine feingranulare Steuerung der Same origin policy. Zum Auffinden vonXSS Sicherheitslücken gibt es viele Tools. Einige der Tools, die direkt von OWASP bereit-gestellt werden, möchte ich hier aber exemplarisch nennen: OWASP CAL9000[83], OWASPWebScarab[85] und OWASP Zed Attack Proxy (ZAP)[93].

6.2.4. A4 - Insecure Direct Object References

Ist gemeint, wenn dem Angreifer über die Anwendung ein direkter Zugriff auf weitere Objekteam Server zur Verfügung steht, auf die er regulär keinen Zugriff haben darf, siehe Tabelle 16.Zum Beispiel Dokumente einer anderen Abteilung, oder Einstellungsparameter, die sonst nurein/eine AdministratorIn vornehmen kann, also unerlaubte Zugriffe auf Dateien und Datenban-ken. Zum Absichern einer Anwendung gegen diesen Angriff muss jede einzelne Objektreferenzüberprüft werden. Falls ein Objekt direkt erreichbar ist, und es eingeschränkte Benutzerkonten

69

oder Benutzergruppen gibt, so muss bei jedem Zugriff auf dieses Objekt oder diesen Objekttypauch die Berechtigung überprüft werden. Die Überprüfung auf die Anfälligkeit wird am einfach-sten wieder durch eine Quellcodeüberprüfung durchgeführt. Automatische Tools scheitern hierin der Regel, da sie nur schwer erkennen können, welche Objekte durch die Anwendung ge-schützt werden sollen und welche nicht.





Anwendungsspezifisch einfach häufig einfach mittelAnwendungsspezifisch,


Tabelle 16.: OWASP Risikoprofil A4 - Insecure Direct Object References (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

Ein/eine BenutzerIn kann zum Beispiel einen HTTP Aufruf manipulieren, um an Einstel-lungen eines/einer anderen BenutzerIn zu kommen, indem er die URL nach Belieben ver-ändert: http://example.com/app/accountInfo?acct=notmyacct. Solche Referenzensind daher vor der serverseitigen Ausführung auf ihre Berechtigung hin zu kontrollieren. Einweiterer Schutz ist es, nicht einfach zu erratende Referenzen zu verwenden (fortlaufende Num-mern oder ähnliches), sondern eventuell pro BenutzerIn eindeutige und zufällig generierte. Da-durch können die technischen Auswirkungen sehr gering gehalten werden. Bei Nichtbeachtungkönnte ein Angreifer zum Beispiel durch Erraten von eindeutigen Bezeichnern zumindest alleObjekte dieses Typs angreifen.

6.2.5. A5 - Security Misconfiguration

Eine sichere Webanwendung hängt außer von ihrem als sicher durchdachten Design noch vonvielen weiteren Faktoren ab. Das beginnt schon bei der Auswahl der Entwicklungsumgebung,den verwendeten Plugins und der Auswahl der Programmiersprache. Dazu kommen aber nochalle Komponenten, die für den Betrieb erforderlich sind: der Webserver, auf dem die Anwen-dung läuft, eventuelle Anwendungsserver, Firewalls, Datenbanken, vorgefertigte Frameworks,die verwendet werden, das Betriebssystem auf dem die Komponenten laufen, und viele mehr.Angreifer können hierdurch Sicherheitsmängel oft sehr einfach finden, und diese müssen auchprimär mit der Webanwendung nicht in Verbindung stehen. Hier ist es vonnöten, dass alle be-troffenen Personen mit den etwaigen Risiken in ihrem Verantwortungsbereich korrekt umgehen.AdministratorInnen sollten gemeinsam mit den Entwicklern von Anwendungen die Serverkon-figuration festlegen, und auch nur jene Funktionen aktivieren und verfügbar machen, die auchtatsächlich benötigt werden. So lassen sich die Angriffsflächen zusätzlich minimieren. Tabelle17 zeigt die Gefahrenübersicht.

Unnötige Services, Ports, Webseiten, nicht genutzte Funktionen, das alles sollte nicht in einerproduktiven Umgebung eingesetzt werden, wenn es nicht benötigt wird. Bei der Nutzung vonPlugins oder Dynamic Link Library (DLL) Dateien von externen Herstellern ist darauf zu achten,

70





Anwendungsspezifisch einfach häufig einfach mittelAnwendungsspezifisch,


Tabelle 17.: OWASP Risikoprofil A5 - Security Misconfiguration (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

dass auch eine aktuelle Version verwendet wird (Siehe Kapitel 6.2.9 Using Known VulnerableComponents). Viele Anwendungen treffen bei der Ersteinrichtung Standardeinstellungen füreindeutige Benutzernamen, Kennwörter, Verschlüsselungseinstellungen, die entweder einfachherauszufinden sind, oder die nicht sicher sind. Hier ist vor allem der Betreiber der Anwen-dung (WebadministratorIn, ServeradministratorIn) gefordert, um alle unsicheren Element zubeseitigen. Über falsche Servereinstellungen wie Fehlermeldungen oder Verzeichnisauflistungin Webservern können Angreifer zusätzlich ermutigt werden, aktiv nach weiteren Lücken zusuchen.

Verhindern lassen sich diese Lücken primär durch die Definition eines sicheren Implemen-tierungsprozesses für den Betrieb von Webanwendungen, bei dem genau auf diese PunkteBedacht genommen wird, aber auch durch regelmäßige Stresstests aller notwendigen Kom-ponenten. Diese Tests können sowohl intern, als auch extern durchgeführt werden. Regelmä-ßig deswegen, da entsprechende Sicherheitslücken erst durch neue Versionen, Updates oderFunktionserweiterungen entstehen können. Die technischen Auswirkungen können gravierendsein und bis hin zur kompletten Übernahme des Servers durch Unbekannte vielfältig auftreten.Entsprechend gravierend können auch die Auswirkungen auf das Geschäftsmodell selbst sein.Angreifern könnte es durch falsche oder schwache Sicherheitseinstellungen gelingen, unbe-merkt in Systeme einzudringen und sich so über einen längeren Zeitraum permanenten Zugriffauf Daten zu sichern. In dem Fall spricht man bereits von einem Advanced Persistent Thre-at (APT) Angriff.

6.2.6. A6 - Sensitive Data Exposure

Viele Webanwendungen gehen nicht genügend sorgsam mit besonders schützenswerten Da-ten um. Solche Daten sind unter anderem Kreditkartendaten, Bankdaten, Gehaltsdaten undviele andere. Diese besonders schützenswerten Daten müssen während des gesamten Kom-munikationsflusses geschützt werden und letztendlich auch in Datenbanken und bei Siche-rungen vor unbefugtem Zugriff abgesichert werden. Die Gesamtbewertung der Sensitive DateExposure (siehe Tabelle 18) zeigt deutlich, dass die möglichen technischen und geschäftli-chen Auswirkungen gravierend wären, diese Sicherheitslücke in der Regel aber nicht direktausgenutzt wird, sondern oftmals erst durch das Eindringen in ein System aufgrund andererUnzulänglichkeiten ermöglicht oder erleichtert wird.

Die Absicherung ist daher auch entsprechend einfach möglich. Sind solche sensiblen Da-

71





Anwendungsspezifisch schwer selten mittel schwerAnwendungsspezifisch,


Tabelle 18.: OWASP Risikoprofil A6 - Sensitive Data Exposure (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

ten im Fokus der Anwendung, dann ist die nächste Frage, ob und wie auf diese Daten zu-gegriffen wird. Jede einzelne Interaktion sollte auf entsprechende verschlüsselte Kommunika-tion hin überprüft werden, und es muss sichergestellt sein, dass auch geeignete Verschlüs-selungsmethoden und Versionen verwendet werden. Das National Institute of Standards andTechnology (NIST) stellt eine entsprechende Liste geeigneter zur Verfügung[75]. Beim Spei-chern von sensitiven Daten ist besonders darauf zu achten, auch die geeigneten Verfahren zurVerschlüsselung innerhalb der Datenbank zu verwenden. Zu einfach gewählte, oder nicht vor-handene SALT Werte, beziehungsweise überhaupt nur mittels HASH versehene Daten, sindzu vermeiden[45]. Speziell zum Speichern von diesen Daten gibt es geeignete Verfahren, wiebcrypt2, pbkdf23, scrypt4 um hier nur einige exemplarisch zu nennen. Bei reinen Webanwen-dungen ist darauf zu achten, dass speziell für schützenswerte Daten alle möglichen Zwischen-speicherstellen (Cache vom Browser, automatische Befüllung innerhalb von Formularen) deak-tiviert sind und verhindert werden.

6.2.7. A7 - Missing Function Level Access Control

Viele Anwendungen authentifizieren den/die BenutzerIn beim Login, und dieser erhält nacherfolgter Authentifizierung seiner/ihrer Benutzerrolle entsprechende Funktionen meist in Formvon sichtbaren Menüs aktiviert. Bei Webanwendungen muss die Gültigkeit dieser Authentifizie-rung bei jedem einzelnen Funktionsaufruf hin überprüft werden. Für Angreifer ist es ansonstensehr leicht, einzelne Webaufrufe zu manipulieren, um so Zugriff auf nicht sichtbare Funktionenzu erhalten. Dieser Angriff ist leicht durchzuführen, aber auch entsprechend einfach technischabzusichern (siehe Tabelle 19). Die Herausforderung dabei ist vielmehr, wirklich jede einzel-ne Webseite und jeden einzelnen Funktionsaufruf abzusichern. Hier ist wieder das gemeinsa-me Zusammenspiel von ServeradministratorInnen und EntwicklerInnen gefordert, um optima-len Schutz zu erhalten. Entwickler sollten von vornherein Funktionen nur mit Authentifizierungentwickeln[79]. Gerade im Bereich der Zugriffskontrolle gibt es immer wieder Sicherheitslückenin Teils sehr bekannten und weit verbreiteten Softwarekomponenten, die gravierende Auswir-kungen haben können[72].

Automatisierte Tools helfen hier bei bereits bekannten URLs, aber eine gesamte Funktionsli-

2http://en.wikipedia.org/wiki/Bcrypt [Zugriff am 19.04.2015]3http://en.wikipedia.org/wiki/PBKDF2 [Zugriff am 19.04.2015]4http://en.wikipedia.org/wiki/Scrypt [Zugriff am 19.04.2015]

72

http://en.wikipedia.org/wiki/Bcrypt

http://en.wikipedia.org/wiki/PBKDF2

http://en.wikipedia.org/wiki/Scrypt





Anwendungsspezifisch einfach häufig mittel mittelAnwendungsspezifisch,


Tabelle 19.: OWASP Risikoprofil A7 - Missing Function Level Access Control (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

ste kann am einfachsten über eine entsprechende Analyse des Quellcodes erfolgen. Jeder Zu-griff auf URLs und Funktionalitäten sollte standardmäßig verboten sein, und erst explizit durcheine Authentifizierung und die entsprechende Berechtigung erlaubt werden. Die technischenund geschäftlichen Auswirkungen können wieder beträchtlich sein. Ein/eine BenutzerIn könntesich über schlecht abgesicherte administrative Funktionen weitere Berechtigungen selbst ver-geben, um weitreichenden Zugriff auf das System zu erhalten. Es besteht wieder die Gefahrdes Datenmissbrauchs und dem Bekanntwerden der Sicherheitslücke an sich.

6.2.8. A8 - Cross-Site Request Forgery (CSRF)

Ein Cross-Site Request Forgery (CSRF) Angriff ist in der Regel zwar nicht mehr ganz so einfachdurchführbar und braucht schon ein gewisses Maß an organisierter Vorgehensweise, damit ererfolgreich ist, der technische Ablauf an sich ist jedoch wieder sehr einfach. Die Grundideedahinter ist, dass ein Angreifer sein Opfer dazu bringt, auf eine manipulierte Website zuzu-greifen. Auf dieser Website ist der Schadcode hinterlegt, welcher beim Öffnen der Seite schonvorher vorbereitete HTTP Anfragen an den Opfer-Server schickt. Vorausgesetzt der/die Benut-zerIn besitzt gerade einen gültigen Sitzungsschlüssel für diese Opfer-Zielanwendung (da ersich nicht ordnungsgemäß abgemeldet hat, oder er in einer anderen Browser-Instanz geradediese Seite bedient), dann ist dieser Angriff auch erfolgreich. Sofern der Server dagegen nichtgeschützt ist, kann er diese manipulierten Anfragen nicht von regulären Anfragen aus seinereigenen Applikation unterscheiden. Die Verwundbarkeit gegen diesen Angriff ist jedoch sehreinfach festzustellen (siehe Tabelle 20).





Anwendungsspezifisch mittel häufig einfach mittelAnwendungsspezifisch,


Tabelle 20.: OWASP Risikoprofil A8 - Cross-Site Request Forgery CSRF (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

Die einfachste Form der Absicherung ist das Verwenden von eindeutigen Sitzungsschlüs-seln nicht nur pro BenutzerIn, sondern auch pro Client oder gleich pro einzelne Instanz desEndpunktes (Browsers, Webapplikation). Zusätzlich können in den einzelnen requests noch

73

versteckte Metadaten mitgesendet werden, die einerseits nur die ordnungsgemäß authenti-fizierte Instanz kennt, und die andererseits auch nicht vorhersehbar sind. Für Entwickler stelltOWASP eigene Bibliotheken zur Verfügung[87], die für gängige Entwicklungsumgebungen JavaPlatform Enterprise Edition (J2EE)5, Microsoft.NET6 oder Hypertext Preprocessor (PHP)7 die-se Sicherheitsfunktion bietet. Ob eine Anwendung gegen CSRF prinzipiell anfällig ist, lässt sichmit verschiedenen Tools wie dem OWASP CSRF Tester[84] einfach überprüfen.

Die technischen und geschäftlichen Auswirkungen sind überschaubar. Die Absicherung da-gegen ist sehr einfach, und der Angriff selbst nicht mehr ganz so einfach durchführbar.

6.2.9. A9 - Using Known Vulnerable Components

Fertige Komponenten von Drittherstellern wie Bibliotheken, ganze Frameworks, Softwaremo-dule laufen in einer Anwendung meist mit denselben Berechtigungen (in der Regel Vollzugriffam lokalen System) wie die Applikation selbst, in der sie verwendet werden. Sind diese Kom-ponenten verwundbar, ist dadurch auch das ganze System verwundbar. Dazu zählen nicht nurdie Anwendung selbst, sondern auch alle für den Betrieb notwendigen Komponenten. DieseSchwachstellen lassen sich mit automatisierten Tools sehr einfach auffinden (siehe Tabelle 21).Ein Angreifer kann nun, sofern er diese Schwachstelle findet, sich darüber hinaus Zugriff aufdas System selbst verschaffen.





Anwendungsspezifisch mittel weit verbreitet schwer mittelAnwendungsspezifisch,


Tabelle 21.: OWASP Risikoprofil A9 - Using Known Vulnerable Components (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

Stellen wir uns vor, unser Webserver ist durch so einen Angriff verwundbar, und es gelingtsehr einfach, sich auf das System Zugriff zu verschaffen (zum Beispiel Apache CeltiXFire (CXF)Aufhentication Bypass[71]. In dem Fall liegt das Problem in einer Serverkomponente, und diesemuss entsprechend durch den Betrieb behoben und die Schwachstelle somit korrigiert werden.Schwachstellen bzw. Verwundbarkeiten in Komponenten werden in der Regel durch neue Ver-sionen derselben behoben. Der AdministratorIn wird auf die neue Aktualisierung dieser Kom-ponente aufmerksam, und sichert somit sein System laufend ab.

Betrachten wir in dem Zusammenhang die fertige Applikation. Meistens weiß einzig der Ent-wickler allein, welche fremden Komponenten er eingebunden hat, und in welcher Version. Oh-ne dessen Mithilfe werden Sicherheitslücken oftmals gar nicht erst erkannt. Das Aktualisieren

5http://www.oracle.com/technetwork/java/javaee/overview/index.html [Zugriff am 19.04.2015]6http://www.microsoft.com/net [Zugriff am 19.04.2015]7http://php.net/ [Zugriff am 19.04.2015]

74

http://www.oracle.com/technetwork/java/javaee/overview/index.html

http://www.microsoft.com/net

http://php.net/

von Komponenten in Applikationen birgt ein weiteres Risiko. Meist sind diese neuen Versio-nen mit weiteren Funktionen versehen, die erst ausgetestet oder deaktiviert werden sollten, umnicht weitere Angriffsflächen zu bieten. Es kann auch vorkommen, dass einzelne Module ausKompatibilitätsgründen in einer Hauptversion verbleiben müssen, da sie grundlegend in ihrerFunktionalität verändert wurden.

Um eine Anwendung wirksam gegen diese mögliche Verwundbarkeit abzusichern, muss be-reits in der Designphase auf solche Zusatzmodule geachtet werden. Eine eigene Modulver-waltung für diese externen Programmteile ist hier vorteilhaft, um einzelne unabhängig von dereigentlichen Programmfunktionalität getrennt zu verwalten. Zudem können auch so Berechti-gungen und Zugriffe auf ein notwendiges Minimum beschränkt werden.

Die technischen Auswirkungen können weitreichend sein, und erst das Einfallstor für weitereAngriffe darstellen. Deshalb sind auch die geschäftlichen Auswirkungen sehr breit gefächert.

6.2.10. A10 - Unvalidated Redirects and Forwards

Umleitungen oder Weiterleitungen werden in Webanwendungen häufig verwendet, um den/dieBenutzerIn auf andere Seiten oder Domänen für weitere Funktionsbereiche oder Programm-teile hinzuführen. Werden diese Weiterleitungen nicht entsprechend abgesichert, kann ein An-greifer dies ausnutzen, um den/die BenutzerIn auf seine schädliche Seite umzuleiten. Ob einSystem anfällig für diesen Angriff ist, lässt sich sehr einfach herausfinden (siehe Tabelle 22).Die einfachste Methode ist die Codeanalyse aller Verweise und deren Übergabeparameter (so-genannte Transfers in .NET). Liegt der Quellcode nicht vor, so kann die Anwendung auch viaProxy auf alle Verweise via HTTP Antwortcodes 300 bis 307 hin überprüft werden.





Anwendungsspezifisch mittel selten einfach mittelAnwendungsspezifisch,


Tabelle 22.: OWASP Risikoprofil A10 - Unvalidated Redirects and Forwards (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf)

Sind solche Verweise vorhanden, so sind diese abzusichern. Als erste Regel gilt, solche Ver-weise prinzipiell zu vermeiden. Sind sie dennoch notwendig, so sollte die Zielseite durch dieserverseitige Programmlogik errechnet und aufgelöst werden. Sind Übergabeparameter nichtzu vermeiden, so sollen diese nicht im Klartext übermittelt werden. Zudem sollten nur zugelas-sene Ziele für Weiterleitungen durch den Server und durch die Applikation aufgelöst werden.Angreifer könnten ansonsten Zugriff auf die Applikation bekommen oder auf das Clientsystem,falls es gelingt, den/die BenutzerIn erfolgreich auf weitere Seiten mit Schadcode umzuleiten,und somit sein System zu infiltrieren.

75

6.3. Durchführung der Risikoanalyse

Die eigentliche Risikoanalyse wurde exakt nach der Vorgabe durch das OWASP Risk RatingModel (siehe Kapitel 6.1) durchgeführt. Der erste Schritt war dabei das Identifizieren von Be-drohungen. Die Kernfragen in dieser Phase waren:

• Wo liegt eventuell ein Risikopotential?

• Was könnte passieren?

• Wer könnte Zugriff haben?

• Betrachtung der Komponenten (Komponentensicht) und aller vorhandenen Schnittstellenund deren Verhalten (Schnittstellensicht).

Zur Erinnerung: dieser Abschnitt wird auch Assessment Scope genannt. In diesem Schrittwurden insgesamt dreiundachtzig Bedrohungen (threats) identifiziert und in grobe Bereicheeingeordnet. Diese Liste an möglichen Bedrohungen wurde danach zwecks Übersichtlichkeitin grobe Bereiche gegliedert (siehe Tabelle 24, Anhang C, Seite 113). Im nächsten Schrittfolgte dann das sogenannte System Modeling. Dafür wurde jede dieser Bedrohungen einerBedrohungsgruppe zugeordnet, die für diesen Angriff am ehesten in Frage kommt. Die voll-ständige Liste aller Bedrohungen und ihrer zugeordneten Bedrohungsgruppen sind in Tabelle25, Anhang D, Seite 117 in den Spalten Assessment Scope ersichtlich. Die nächste Betrach-tungsphase, Identify Threats, befasst sich mit den daraus resultierenden Angriffen. Für jedendieser Angriffe wurden vier Faktoren bewertet und als Bedrohungsfaktoren abgeleitet (sieheTabelle 25, Anhang D, Seite 117, Spalte zwei ). Daraufhin folgte der nächste Schritt, IdentifyVulnerabilities, die Bewertung von vier Kennzahlen als Verwundbarkeitsfaktoren. Gemeinsamergeben diese acht Messwerte die durchschnittliche Wahrscheinlichkeit für eine Bedrohung.

likelihood =(4 ∗ threats) + (4 ∗ vulnerabilities)

8

Für jede einzelne Bedrohung wurde diese Wahrscheinlichkeit noch zusätzlich über eine Ma-trix (siehe Tabelle 10, Seite 63) einer Risikogruppe zugeordnet. In dieser These wurden für dieBewertung der Wahrscheinlichkeit aller 83 Bedrohungen also insgesamt 830 Faktoren berück-sichtigt.

76

likelihoodfactors =83∑

assessmetscope=1

(4 ∗ threats + 4 ∗ vulnerabilities + likelihood + matrix_value)


assessmetscope=1

(4 + 4 + 1 + 1)


assessmetscope=1

(10)

likelihoodfactors = 830

Im letzten Schritt Evaluation or Impact on the Business werden über jeweils vier tech-nische und geschäftliche Faktoren noch die möglichen Auswirkungen bewertet. Der Durch-schnittswert wird dabei jedoch für jeden Bereich einzeln betrachtet.

impact_technical =4 ∗ technical_values

4

Dieser Durchschnittswert wurde wieder über Tabelle 10, Seite 63 einer Risikogruppe zuge-ordnet. Für die technischen Auswirkungen wurden insgesamt 498 Werte berücksichtigt.

technicalimpactfactors =83∑

assessmetscope=1

(4 ∗ technical_values + impact_technical + matrix_value)


assessmetscope=1

(4 + 1 + 1)


assessmetscope=1

(6)

technicalimpactfactors = 498

Die durchschnittliche Auswirkung der Geschäftsfaktoren errechnet sich analog:

impact_business =4 ∗ business_values

4

Insgesamt wurden für die Berechnung der technischen Auswirkungen also ebenfalls 498Werte Berücksichtigt.

77

businessimpactfactors =83∑

assessmetscope=1

(4 ∗ business_values + impact_business + matrix_value)


assessmetscope=1

(4 + 1 + 1)


assessmetscope=1

(6)

businessimpactfactors = 498

Abschließend wurde für jede Bedrohung noch das Gesamtrisiko errechnet und das Ergebniswieder über eine Matrix (siehe Tabelle 11, Seite 63) bewertet.

riskfactors =83∑

assessmetscope=1

(likelihood ∗ impact_technical) + (likelihood ∗ impact_business)

riskfactors =83∑

assessmetscope=1

(risk_technical) + (risk_business)

riskfactors =83∑

assessmetscope=1

(1 + 1)

riskfactors =83∑

assessmetscope=1

(2)

riskfactors = 166

Alles zusammen wurden für die gesamte Risikobetrachtung daher knapp zweitausend KPIDaten (Key Performance Indicator) betrachtet.

amountofkpi =83∑

assessmetscope=1

likelihoodfactors + technicalimpactfactors

+ businessimpactfactors + riskfactors

amountofkpi = 830 + 498 + 498 + 166

amountofkpi = 1992

Das Ergebnis dieser Betrachtung ist eine geordnete Liste an Bedrohungen, inklusive ihrerAuswirkung und ihrer Wahrscheinlichkeit, also dem Risiko dieser jeweiligen Bedrohung. Diegesamte Bewertungsmatrix ist sehr umfangreich und deshalb nur im Anhang D, Tabelle 25

dieser These vollständig ersichtlich.

78

6.4. Ergebnisse der Risikoanalyse

Alle Detailergebnisse der Analyse sind in Tabelle 25, Anhang D, Seite 117 dieser These er-sichtlich. Trotzdem werden an dieser Stelle die einzelnen Werte genauer betrachtet, und ihrErgebnis auf Korrektheit und Plausibilität hin überprüft. Abbildung 16 zeigt das ermittelte Ge-samtrisiko jeder einzelnen Bedrohung in ihrer gefundenen Reihenfolge, also nach ihrer ID inTabelle 25, Anhang D, Seite 117 aufsteigend sortiert.

0 10 20 30 40 50 60 70 80 900

1

2

3

4

5

6

7

Bedrohungen

Ges

amtr

isik

o

Bedrohungen nach ID sortiert

Abbildung 16.: Gesamtrisiko aller Bedrohungen, nach ID sortiert

Der Diagrammverlauf zeigt eindeutig, dass die gefundenen Bedrohungen, sehr unterschied-lich in ihren Risiken verteilt sind. Durch das Sortieren aller gefunden Bedrohungen nach ihremRisiko ergibt sich jedoch eine ganz andere Sichtweise. Abbildung 17 zeigt klar und deutlich,dass die absoluten Werte homogen über den Risikobereich verteilt sind. Die Bewertung gehtvon null bis neun, wobei jedoch aufgrund der einzelnen Umschlüsselungstabellen Gesamtwerteunter zwei und oberhalb von 7 sehr selten sind.

Bei Datenreihen ist in der Regel auch sehr hilfreich, auch statistische Faktoren der Rohdatenzu betrachten, um etwas über die Datenqualität aussagen zu können[32]. Speziell bei dieserRisikobetrachtung sind das der Modalwert (häufigster Wert), der Mittelwert (arithmetisches Mit-tel), der Median (der Zentralwert), die Varianz (die Streuung) und die Standardabweichung (derStandardfehler).

79

0 10 20 30 40 50 60 70 80 900

1

2

3

4

5

6

7

Bedrohungen

Ges

amtr

isik

o

Bedrohungen nach Gesamtrisko sortiert

Abbildung 17.: Gesamtrisiko aller Bedrohungen, nach Gesamtrisiko sortiert

Modalwert = haeufigsterWert = 3.375

Mittelwert =1

n

n∑i=1

(xi) = 4.16

Median = Ht − Lt > t̃9∑

i=1

(Ht−i − Lt−i) = 3.88

Der Modalwert als der am häufigsten aufgetretenen Wert beläuft sich dabei auf 3.375, undentspricht in dieser Risikobetrachtung einer mittleren Bedrohung. Er ist dabei etwas geringerausgefallen als der Durchschnittswert (Mittelwert) von 4.16. Der Median, das heißt jener Wert,bei dem es genauso viele höhere Risiken als auch niedrigere Risiken gibt, wurde mit 3.88errechnet.

80

V arianz =

n∑i=1

(xi − x̄)2

n= 1.79991319

Standardabweichung =

√√√√√ n∑i=1

(xi − x̄)2

n= 1.33330118

Die Werte von 1.799 für die Varianz, und deren Quadratwurzel die Standardabweichung von1.333 belegen dabei zusätzlich, dass der große Teil der Bedrohungen dem mittleren Risikobe-reich zuzuordnen ist.

6.5. Weitere Betrachtungen

Wie in Tabelle 23 ersichtlich verteilen sich die Risiken bei der Betrachtung der Bereiche und derzugeordneten Risikostufen keineswegs mehr so linear. Auffällig ist in diesem Zusammenhang,dass die Risiken der Stufe gering mit nur 4 Bedrohungen, dafür aber sehr gering mit 17 Be-drohungen vertreten sind. Hier ergibt sich durch die Umschlüsselung auf die Risikostufen einbreiteres Spektrum in der Mitte der Skala.

kritisch hoch mittel gering sehr gering Anzahl pro Bereich

API 1 2 11 1 10 25

Betrieb 1 8 3 12

Implementierung 7 4 7 1 19

Sozial 1 1 5 7

Kosten 2 2

FHIR Spezifikation 1 4 5

Extern 1 2 3

FHIR Sicherheitssystem 3 3 3 9

Anzahl pro Stufe 10 11 40 4 17

Tabelle 23.: Ergebnis der Risikoanalyse Zusammengefasst

Wirklich interessant ist dabei auch die Betrachtung der Bereiche an sich. So fällt auf, dassdie meisten der Risiken zwar im Bereich der API, der Implementierung und des Betriebes ei-ner FHIR Anwendung gefunden wurden, diese sich aber gänzlich unterschiedlich darstellen.Die Risiken der Kategorie API, wobei hier vor allem die Arbeitsweise eines FHIR Repositoriesgemeint ist, sind vorwiegend auf menschliches Fehlverhalten zurückzuführen, wobei hingegendie Fehler der Implementierung in der Regel eher technische Ursachen haben. Zudem ska-

81

lieren sie dadurch auf eine größere Angreifergruppe, und können bei Ausnützung auch mehrSchaden verursachen.

Als Gesamtergebnis aus Sicht der FHIR Spezifikation und des FHIR Frameworks an sich,zeigt die Analyse, dass die Angriffsflächen durch die RESTful Webservice Schnittstellen beiweitem nicht so gravierend ausgefallen sind, wie sie eventuell vermutet oder erwartet wurden.Das liegt vor allem auch daran, dass Webservices mittels JSON hier sehr wenig Angriffsflä-che bietet, und auch bei Verwendung von XML Dokumenten für die Kommunikation, bis aufNarrative und Binärdaten, wenig Sicherheitsbedenken aufkommen lassen. Die eigentlichenFehler und Risiken liegen vielmehr bei einer sicheren Implementierung eines FHIR Reposito-ries.

Hier müssen Risiken auf den Servern, auf Netzwerkebene, die verwendeten Webservices,eventuelle Clientanwendungen, und vor allem auch das hinterlegte Sicherheitssystem auf alleeventuellen Sicherheitslücken hin geprüft werden. Für eine Implementierung sollten zusätzlichalle Punkte der Stufe kritisch und hoch aus dieser Risikobewertung eigens betrachtet werden.

82

7. Conclusio

Zu Beginn dieser Arbeit war es noch nicht ganz offensichtlich, wohin die Reise gehen würde.Der ursprüngliche Gedanke war es, eine tatsächliche FHIR Implementierung mittels automa-tischer Tools auf eventuelle Verwundbarkeiten hin zu überprüfen. Bei genauerer Betrachtungstellte sich das aber nicht als sehr zielführend heraus. FHIR selbst ist nach wie vor erst in derVersion v0.0.82 spezifiziert. Es gibt zwar einen optimistischen Zeitplan von HL7 FHIR weiter be-kannt zu machen, aber aktuell gibt es noch deutlich weniger Implementierungen als von HL7v2Kommunikationslösungen. Parallel zu den FHIR Recherchen kam bei genauerer Betrachtungder OWASP Top 10, und damit verbunden der Tools und Methoden durch das OWASP RiskRating der Gedanke, bereits vorab fertiger Implementierungen, anhand der Spezifikation po-tentielle Fehlerlücken und sicherheitskritische Bereiche aufzuzeigen.

Das Ergebnis überzeugt von der Mächtigkeit und den Möglichkeiten dieser Risikobetrach-tung. Durch einen definierten Analyse und Risikoprozess können bereits in der Designphaseund während des Entwicklungsprozesses einer Anwendung mögliche Risiken entdeckt, undbehoben oder gänzlich vermieden werden.

Einschränkend für die Bedrohungsanalyse ist noch hinzuzufügen, dass für die Bewertung al-ler möglichen Verwundbarkeiten, ihren Auswirkungen und ihren Wahrscheinlichkeiten keinerleistatistische Glättungen angewendet wurden. Diese Betrachtungen spiegeln zum großen TeilEinzelmeinungen von im IT Sicherheitsumfeld tätigen Personen wieder. Hier wäre es womög-lich besser gewesen, diese Analyse in mehreren kleinen Teams durchzuführen, und diese TeamErgebnisse anschließend zu einem Gesamtergebnis zu aggregieren.

Diese Arbeit zeigt dennoch sehr klar, dass es besser, effizienter und kostengünstiger ist, Si-cherheitsbetrachtungen im gesamten Entwicklungsprozess einer Software als fixen Bestandteilzu etablieren. Ansonsten besteht immer wieder die Gefahr, dass Lücken lange unentdeckt blei-ben, und bei Bekanntwerden großen Schaden verursachen. Das OWASP Risk Rating Modelist dabei nur eine von vielen möglichen Ansätzen, dieses Ziel zu erreichen.

7.1. Ausblick

Diese Masterthesis hat sich lediglich auf die Risikobewertung und Analyse möglicher Sicher-heitslücken eines FHIR-Repositories beschränkt, mit dem Ergebnis, dass nun eine Vielzahlvon möglichen Verwundbarkeiten identifiziert sind. Eine konsequente Fortführung dieser Arbeitwäre es daher, diese Bedrohungen aufzuspüren und nachhaltig durch sichere Varianten zu er-setzen. Hier bieten die vielen weiteren Referenzimplementierungen und Projekte von FHIR mit

83

Sicherheit genug Potential für weitere Tätigkeiten[40].Eine andere Möglichkeit für weiterführende Tätigkeiten dieser Analyse ist die Generierung

von Vergleichsdaten auf Basis eines anderen Risikobewertungsprozesses. Bei Betrachtungder gefunden Bedrohungen durch ein anderes Risikobewertungssystem wäre es interessant,ob Gemeinsamkeiten in den Bewertungsergebnissen existieren, beziehungsweise falls nicht,warum diese Unterschiede vorhanden sind. Eventuell erweist sich eine andere Methode auchals grundlegend besser oder schlechter geeignet, im speziellen Kontext sensibler Daten in We-banwendungen.

84

Literaturverzeichnis

[1] BAKER, M. und P. STARK: The ’application/xhtml+xml’ Media Type: RFC3236. Techn.Ber., The Internet Engineering Task Force, 2002. Zugriff am 19.04.2015, Online: https://www.ietf.org/rfc/rfc3236.

[2] BARTEL, M., J. BOYER, B. FOX, B. LAMACCHIA und E. SIMON: XML Signature Syntaxand Processing (Second Edition): W3C Recommendation 10 June 2008. Techn. Ber.,World Wide Web Consortium, 2008. Zugriff am 19.04.2015, Online: http://www.w3.org/TR/xmldsig-core/.

[3] BARTH, A.: The Web Origin Concept: RFC6454. Techn. Ber., The Internet EngineeringTask Force, 2011. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc6454.

[4] BENDER, D. und K. SARTIPI: HL7 FHIR: An Agile and RESTful approach to healthcareinformation exchange. In: RODRIGUES, P. P. (Hrsg.): Computer-Based Medical Systems(CBMS), 2013 IEEE 26th International Symposium on, Nr. ISBN 978-0-29-9240, S. 326–331, 2013.

[5] BERNERS-LEE, T., R. FIELDING und L. MASINTER: Uniform Resource Identifier (URI):Generic Syntax: RFC3986. Techn. Ber., The Internet Engineering Task Force, 2005.Zugriff am 19.04.2015, Online: https://www.ietf.org/rfc/rfc3986.

[6] BERNERS-LEE, T., L. MANISTER und M. MCCAHILL: Uniform Resource Locators (URL):RFC1738. Techn. Ber., The Internet Engineering Task Force, 1994. Zugriff am19.04.2015, Online: http://tools.ietf.org/html/rfc1738.

[7] BIRON, P. V. und A. MALHOTRA: XML Schema Part 2: Datatypes Second Edition: W3CRecommendation 28 October 2004. Techn. Ber., World Wide Web Consortium, 2004.Zugriff am 19.04.2015, Online: http://www.w3.org/TR/xmlschema-2/.

[8] BRAY, T.: The JavaScript Object Notation (JSON) Data Interchange Format: RFC7158.Techn. Ber., The Internet Engineering Task Force, 2014. Zugriff am 19.04.2015, Online:http://tools.ietf.org/html/rfc7158.

[9] BRAY, T.: The JavaScript Object Notation (JSON) Data Interchange Format: RFC7159.Techn. Ber., The Internet Engineering Task Force, 2014. Zugriff am 19.04.2015, Online:http://tools.ietf.org/html/rfc7159.

[10] BRAY, T., J. PAOLI, C. M. SPERBERG-MCQUEEN, E. MALER und F. YERGEAU: ExtensibleMarkup Language (XML) 1.0 (Fifth Edition): W3C Recommendation 26 November 2008.

85

https://www.ietf.org/rfc/rfc3236


http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/xmldsig-core/

http://tools.ietf.org/html/rfc6454



http://www.w3.org/TR/xmlschema-2/



Techn. Ber., World Wide Web Consortium, 2008. Zugriff am 19.04.2015, Online: http://www.w3.org/TR/xml/.

[11] BUCHMANN, J.: Introduction to cryptography . Nr. 0387950346 in Undergraduate texts inmathematics. Springer-Verlag, New York, 2001.

[12] BUSCHMANN, F., K. HENNEY und D. C. SCHMIDT: Pattern-oriented software architec-ture. Nr. ISBN 9780470059029 in Wiley series in software design patterns. John Wiley,Chichester, England and Hoboken, N.J., 2007.

[13] CAUMANNS, J., R. KUHLISCH, O. PFAFF und O. RODE: IHE IT-Infrastructure White Pa-per: Access Control . Techn. Ber., Integrating the Healthcare Enterprise IHE ITI, 2009.Zugriff am 19.04.2015, Online: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_IUA.pdf.

[14] COLES, M. und T. OATES: Credit Transfer and Mutual Trust: Study commissioned tothe Qualifications and Curriculum Authority, England . Techn. Ber., Office for Offici-al Publications of the European Communities, 2005. Zugriff am 19.04.2015, Online:http://www.voced.edu.au/content/ngv18854.

[15] COMMONS, C.: Attribution-ShareAlike 3.0 Unported: CC BY-SA 3.0. Techn. Ber., Creati-ve Commons, 2015. Zugriff am 19.04.2015, Online: http://creativecommons.org/licenses/by-sa/3.0/.

[16] CROCKER, D. H.: Standard for the Format of ARPA Internet Text Messages: RFC822.Techn. Ber., The Internet Engineering Task Force, 1998. Zugriff am 19.04.2015, Online:http://tools.ietf.org/html/rfc822.

[17] CROCKFORD, D.: The JSON Data Interchange Format: ECMA Standard-404. Techn.Ber., ECMA, 2013. Zugriff am 19.04.2015, Online: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf.

[18] DAVIS, M.: Healthcare Requirements for Emergency Access. Techn. Ber., Departmentof Veteran Affairs, 2009. Zugriff am 19.04.2015, Online: http://www.hl7.org/search/viewSearchResult.cfm?search_id=393442&search_result_url=\%2Fdocumentcenter\%2Fpublic\%2Fwg\%2Fsecure\%2FHL7\%20Emergency\%20Access\%2Edoc.

[19] DEUTSCHES BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK: Informa-tionssicherheit und IT-Grundschutz: BSI-Standards 100-1, 100-2 und 100-3. Nr. ISBN9783898176927 in Unternehmen und Wirtschaft . Bundesanzeiger-Verl, Köln, 2., über-arb. Aufl Aufl., 2008.

[20] DIERKS, T. und E. RESCORLA: The Transport Layer Security (TLS) Protocol Version1.2: RFC5246. Techn. Ber., The Internet Engineering Task Force, 2008. Zugriff am19.04.2015, Online: http://tools.ietf.org/html/rfc5246.

86

http://www.w3.org/TR/xml/


http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ ITI_Suppl_IUA.pdf


http://www.voced.edu.au/content/ngv18854

http://creativecommons.org/licenses/by-sa/3.0/

http://creativecommons.org/licenses/by-sa/3.0/


http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

http://www.hl7.org/search/viewSearchResult.cfm?search_ id=393442&search_result_ url=\%2Fdocumentcenter\%2Fpublic\%2Fwg\%2Fsecure\%2FHL7\%20Emergency\%20Access\%2Edoc




[21] ECKERT, C.: IT-Sicherheit: Konzepte, Verfahren, Protokolle. Nr. ISBN 3-486-77848-X inStudium. De Gruyter Oldenbourg, München, 9., aktualisierte u. korr. Aufl Aufl., 2014.

[22] FEDERAL COMPUTER INCIDENT RESPONSE CAPABILITY: Malicious HTML Tags Embed-ded in Client Web Requests. Techn. Ber., Federal Computer Incident Response Ca-pability, 2000. Zugriff am 19.04.2015, Online: https://www.cert.org/historical/advisories/CA-2000-02.cfm?

[23] FIELDING, R., J. GETTYS, J. MODUL, H. ERYSTYK, L. MASINTER, P. LEACH undT. BERNERS-LEE: Hypertext Transfer Protocol – HTTP/1.1: RFC2616. Techn. Ber., TheInternet Engineering Task Force, 2006. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc2616.

[24] FIELDING, R. und (KEINE ANGABE): Relative Uniform Resource Locators: RFC1808.Techn. Ber., The Internet Engineering Task Force, 1995. Zugriff am 19.04.2015, Online:http://tools.ietf.org/html/rfc1808.

[25] FIELDING, R. T.: Architectural Styles and the Design of Network-based Software Archi-tectures. Doktorarbeit, University of California, Irvine, 2000.

[26] FREED, N. und N. BORENSTEIN: Multipurpose Internet Mail Extensions (MIME) Part One:Format of Internet Message Bodies: RFC2045. Techn. Ber., The Internet EngineeringTask Force, 1996. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc2045.

[27] GESUNDHEIT, B. BUNDESMINISTERIUM FÜR: Elektronische Gesundheitsakte-Gesetz:ELGA-G. Zugriff am 19.04.2015, Online: http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Gesetze_u.a._Rechtsgrundlagen/BGBLA_2012_I_111.pdf,14.12.2012.

[28] GESUNDHEIT, B. BUNDESMINISTERIUM FÜR: Gesundheitstelematikverordnung 2012:GTelV 2012. Zugriff am 19.04.2015, Online: http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Gesetze_u.a._Rechtsgrundlagen/BGBLA_2012_II_483.pdf,21.12.2012.

[29] GESUNDHEIT, B. BUNDESMINISTERIUM FÜR: Gesundheitstelematikverordnung 2013:GTelV 2013. Zugriff am 19.04.2015, Online: http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Gesetze_u.a._Rechtsgrundlagen/GTelV_2013.pdf,23.12.2013.

[30] GESUNDHEIT, B. BUNDESMINISTERIUM FÜR: Verordnung des Bundesministers fürGesundheit zur Implementierung von ELGA: ELGA-VO. Zugriff am 19.04.2015, On-line: http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Gesetze_u.a._Rechtsgrundlagen/Verordnung_des_Bundesministers_fuer_Gesundheit_zur_Implementierung_von_ELGA__ELGA-Verordnung_-_ELGA-VO_.pdf, 23.12.2013.

87

https://www.cert.org/historical/advisories/CA-2000-02.cfm?

https://www.cert.org/historical/advisories/CA-2000-02.cfm?





http://www.elga.gv.at/fileadmin/user_ upload/uploads/download_Papers/Gesetze_ u.a._Rechtsgrundlagen/BGBLA_2012_ I_111.pdf

http://www.elga.gv.at/fileadmin/user_ upload/uploads/download_Papers/Gesetze_ u.a._Rechtsgrundlagen/BGBLA_2012_ I_111.pdf

http://www.elga.gv.at/fileadmin/user_ upload/uploads/download_Papers/Gesetze_ u.a._Rechtsgrundlagen/BGBLA_2012_ II_483.pdf

http://www.elga.gv.at/fileadmin/user_ upload/uploads/download_Papers/Gesetze_ u.a._Rechtsgrundlagen/BGBLA_2012_ II_483.pdf

http://www.elga.gv.at/fileadmin/user_ upload/uploads/download_Papers/Gesetze_ u.a._Rechtsgrundlagen/GTelV_2013.pdf

http://www.elga.gv.at/fileadmin/user_ upload/uploads/download_Papers/Gesetze_ u.a._Rechtsgrundlagen/GTelV_2013.pdf

http://www.elga.gv.at/fileadmin/user_ upload/uploads/download_Papers/Gesetze_ u.a._Rechtsgrundlagen/Verordnung_ des_Bundesministers_fuer_ Gesundheit_zur_Implementierung_ von_ELGA__ ELGA-Verordnung_-_ELGA-VO_.pdf



[31] GMBH, E.: Definition der Rollen für das ELGA-Berechtigungssystem. Verweist auf dieNomenlkatur der Healthcare-Provider Rollen in Österreich. EHSREG. Techn. Ber., EL-GA GmbH, 2011. Zugriff am 19.04.2015, Online: https://www.gesundheit.gv.at/OID_Frontend/oiddetail.htm?smallView=true&actualOid=1.2.40.0.34.10.26.

[32] GÖTZE, W.: Statistik: Lehr- und Übungsbuch mit Beispielen aus der Tourismus- und Ver-kehrswirtschaft . Nr. ISBN 3-486-27233-0 in Managementwissen für Studium und Praxis.Oldenbourg, München, 2002.

[33] GRIEVE, G.: FHIR RESTful API: FHIR DSTU. Techn. Ber., Health Level Seven Interna-tional, 2014. Zugriff am 19.04.2015, Online: http://hl7.org/fhir/http.html.

[34] GROTH, P. und L. MOREAU: An Overview of the PROV Family of Documents: W3C Wor-king Group Note 30 April 2013. Techn. Ber., World Wide Web Consortium, 2013. Zugriffam 19.04.2015, Online: http://www.w3.org/TR/prov-overview/.

[35] HAERDER, T. und A. REUTER: Principles of Transaction-Oriented Database Recovery .Computing Surveys, 1983(Vol 15, No 4):288–317, 1983.

[36] HARDT, D.: The OAuth 2.0 Authorization Framework: RFC6749. Techn. Ber., The In-ternet Engineering Task Force, 2012. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc6749.

[37] HL7: FHIR Security: FHIR DSTU. Techn. Ber., Health Level Seven International, 2014.Zugriff am 19.04.2015, Online: http://hl7.org/fhir/security.html.

[38] HL7: FHIR Security Labels: FHIR DSTU. Techn. Ber., Health Level Seven International,2014. Zugriff am 19.04.2015, Online: http://hl7.org/fhir/security-labels.html.

[39] HL7: FHIR XML Schema and Schematron: FHIR DSTU. Techn. Ber., Health Level Se-ven International, 2014. Zugriff am 19.04.2015, Online: http://www.hl7.org/FHIR/xml.html.

[40] HL7: Open Source FHIR implementations: FHIR DSTU. Techn. Ber., Health Level Se-ven International, 2014. Zugriff am 19.04.2015, Online: http://wiki.hl7.org/index.php?title=Open_Source_FHIR_implementations.

[41] HL7: CDA Release 2: Primary Standards. Techn. Ber., Health Level Seven International,2015. Zugriff am 19.04.2015, Online: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186.

[42] HL7: FHIR Signature Type Codes: FHIR DSTU. Techn. Ber., Health Level Se-ven International, 2015. Zugriff am 19.04.2015, Online: http://hl7.org/fhir/2015May/valueset-signature-type.html.

[43] HL7: HL7 Version 2 Product Suite: Primary Standards. Techn. Ber., Health Level Se-ven International, 2015. Zugriff am 19.04.2015, Online: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185.

88

https://www.gesundheit.gv.at/OID_ Frontend/oiddetail.htm?smallView=true&actualOid=1.2.40.0.34.10.26

https://www.gesundheit.gv.at/OID_ Frontend/oiddetail.htm?smallView=true&actualOid=1.2.40.0.34.10.26

http://hl7.org/fhir/http.html

http://www.w3.org/TR/prov-overview/



http://hl7.org/fhir/security.html

http://hl7.org/fhir/security-labels.html

http://www.hl7.org/FHIR/xml.html

http://wiki.hl7.org/index.php?title=Open_ Source_FHIR_implementations

http://wiki.hl7.org/index.php?title=Open_ Source_FHIR_implementations

http://www.hl7.org/implement/standards/product_ brief.cfm?product_id=186


http://hl7.org/fhir/2015May/valueset-signature-type.html

http://hl7.org/fhir/2015May/valueset-signature-type.html



[44] HL7: HL7 Version 3 Product Suite: Primary Standards. Techn. Ber., Health Level Se-ven International, 2015. Zugriff am 19.04.2015, Online: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186.

[45] HUTCHISON, D., T. KANADE, J. KITTLER, J. M. KLEINBERG, F. MATTERN, J. C. MIT-CHELL, M. NAOR, O. NIERSTRASZ, K. NYBERG, C. PANDU RANGAN und B. STEFFEN:Fast Software Encryption: 15th International Workshop, FSE 2008, Lausanne, Switzer-land, February 10-13, 2008, Revised Selected Papers. Nr. ISBN 978-3-540-71038-7 inLecture Notes in Computer Science. Springer, Berlin and Heidelberg, 2008.

[46] IHE: Audit Trail and Node Authentication. Techn. Ber., Integrating the Healthcare En-terprise IHE ITI, 2015. Zugriff am 19.04.2015, Online: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_IUA.pdf.

[47] IHE: Document Digital Signature (DSG): Trial Implementation. Techn. Ber., Integratingthe Healthcare Enterprise IHE ITI, 2015. Zugriff am 19.04.2015, Online: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_IUA.pdf.

[48] INTERNATIONAL, A.: Standard Guide for Electronic Authentication of Health Care Infor-mation: ASTM E1762-95 (2013). Techn. Ber., ASTM International, West ConshohockenPA19428, 2013. Zugriff am 19.04.2015, Online: http://www.astm.org/Standards/E1762.htm.

[49] IRS: Exemption Requirements - 501(c)(3) Organizations. Techn. Ber., U.S. Depart-ment of the Treasury - Internal Revenue Service, 2015. Zugriff am 19.04.2015,Online: http://www.irs.gov/Charities-&-Non-Profits/Charitable-Organizations/Exemption-Requirements-Section-501(c)(3)-Organizations.

[50] JONES, M. und D. HARDT: The OAuth 2.0 Authorization Framework: Bearer Token Usa-ge: RFC6750. Techn. Ber., The Internet Engineering Task Force, 2012. Zugriff am19.04.2015, Online: http://tools.ietf.org/html/rfc6750.

[51] JOSEFSSON, S. und (KEINE ANGABE): The Base16, Base32, and Base64 Data Enco-dings: RFC4648. Techn. Ber., The Internet Engineering Task Force, 2006. Zugriff am19.04.2015, Online: https://www.ietf.org/rfc/rfc4648.

[52] KE, W., M. MUTHUPRASANNA und S. KOTHARI: Preventing SQL injection attacks instored procedures. In: Software Engineering Conference, 2006. Australian, Nr. ISBN 0-7695-2551-2, S. 8 pp, 2006.

[53] KEMPER, A.: Datenbanksysteme: Eine Einführung. Nr. ISBN 3486273922. Oldenbourg,München, 5., aktual. und erw. Aufl Aufl., 2004.

[54] KLEIN, A.: DOM Based Cross Site Scripting or XSS of the Third Kind . Techn. Ber.,Web Application Security Consortium, 2005. Zugriff am 19.04.2015, Online: http://www.webappsec.org/projects/articles/071105.txt.

89







http://www.astm.org/Standards/E1762.htm

http://www.astm.org/Standards/E1762.htm

http://www.irs.gov/Charities-&-Non-Profits/Charitable-Organizations/Exemption-Requirements-Section-501(c)(3)-Organizations

http://www.irs.gov/Charities-&-Non-Profits/Charitable-Organizations/Exemption-Requirements-Section-501(c)(3)-Organizations



http://www.webappsec.org/projects/articles/071105.txt

http://www.webappsec.org/projects/articles/071105.txt

[55] KLYNE, G. und C. NEWMAN: Date and Time on the Internet: Timestamps: RFC3339.Techn. Ber., The Internet Engineering Task Force, 2002. Zugriff am 19.04.2015, Online:http://www.ietf.org/rfc/rfc3339.txt.

[56] KÖNIGS, H.-P.: IT-Risiko-Management mit System: Von den Grundlagen bis zur Realisie-rung - Ein praxisorientierter Leitfaden. Nr. 3834899933 in Edition <kes>. Vieweg+TeubnerVerlag / Springer Fachmedien Wiesbaden, Wiesbaden, Wiesbaden, 3., überarbeitete underw. Aufl. Aufl., 2009.

[57] KRAMER, E.: FHIR Resource References: FHIR DSTU. Techn. Ber., Health Level Se-ven International, 2014. Zugriff am 19.04.2015, Online: http://www.hl7.org/implement/standards/fhir/references.html.

[58] KRAMER, R. M. (Hrsg.): Organizational trust: A reader . Nr. ISBN 9780199288496 inOxford management readers. Oxford Univ. Press, Oxford, 2006.

[59] LEACH, P., M. MEALLING und R. SALZ: A Universally Unique IDentifier (UUID) URNNamespace: RFC4122. Techn. Ber., The Internet Engineering Task Force, 2005. Zugriffam 19.04.2015, Online: https://www.ietf.org/rfc/rfc4122.txt.

[60] LEVINSTON, E.: Content-ID and Message-ID Uniform Resource Locators: RFC2392.Techn. Ber., The Internet Engineering Task Force, 1998. Zugriff am 19.04.2015, Onli-ne: http://tools.ietf.org/html/rfc2392.

[61] LODDERSTEDT, T., M. MCGLOIN und P. HUNT: OAuth 2.0 Threat Model and Securi-ty Considerations: RFC6819. Techn. Ber., The Internet Engineering Task Force, 2013.Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc6819.

[62] MANDEL, J.: CDA Security Issue Description. Techn. Ber., Health Level Seven Inter-national, 2014. Zugriff am 19.04.2015, Online: http://wiki.hl7.org/index.php?title=CDA_Security_Issue_Description.

[63] MARSHALL, G.: Security Audit and Access Accountability Message XML Data Definitionsfor Healthcare Applications: RFC3881. Techn. Ber., The Internet Engineering Task Force,2004. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc3881.

[64] MAYER, R. C., J. H. DAVIS und F. D. SCHOORMAN: An integrative model of organiza-tional trust . In: Organizational trust : a reader , Nr. ISBN 978-0-19-928850-2, S. 82–108.Oxford Univ. Press, Oxford [u.a.], 2007.

[65] MCKENZIE, L.: FHIR Resource Profile: FHIR DSTU. Techn. Ber., Health Level Se-ven International, 2014. Zugriff am 19.04.2015, Online: http://www.hl7.org/implement/standards/fhir/profile.html.

90

http://www.ietf.org/rfc/rfc3339.txt

http://www.hl7.org/implement/standards/fhir/references.html

http://www.hl7.org/implement/standards/fhir/references.html

https://www.ietf.org/rfc/rfc4122.txt



http://wiki.hl7.org/index.php?title=CDA_ Security_Issue_Description

http://wiki.hl7.org/index.php?title=CDA_ Security_Issue_Description


http://www.hl7.org/implement/standards/fhir/profile.html

http://www.hl7.org/implement/standards/fhir/profile.html

[66] MCKENZIE, L.: FHIR RESTful API - Atom Bundle Representation: FHIR DSTU. Techn.Ber., Health Level Seven International, 2014. Zugriff am 19.04.2015, Online: http://www.hl7.org/implement/standards/fhir/xml.html#atom.

[67] MCKENZIE, L.: FHIR RESTful API - OMG hData RESTful Transport: FHIR DSTU. Techn.Ber., Health Level Seven International, 2014. Zugriff am 19.04.2015, Online: http://hl7.org/implement/standards/fhir/http.html#hdata.

[68] MCKENZIE, L.: FHIR RESTful API - Paging: FHIR DSTU. Techn. Ber., Health Le-vel Seven International, 2014. Zugriff am 19.04.2015, Online: http://hl7.org/implement/standards/fhir/http.html#paging.

[69] MCKENZIE, L.: FHIR Tags: FHIR DSTU. Techn. Ber., Health Level Seven International,2014. Zugriff am 19.04.2015, Online: http://hl7.org/fhir/extras.html#tags.

[70] MEIER, J., A. MACKMAN und B. WASTELL: Threat Modeling Web Applications. Techn.Ber., Microsoft Corporation, 2005. Zugriff am 19.04.2015, Online: https://msdn.microsoft.com/en-us/library/ms978516.aspx.

[71] MITRE CORPORATION: Common Vulnerabilities and Exposures - CVE-2012-3451.Techn. Ber., MITRE Corporation, 2012. Zugriff am 19.04.2015, Online: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451.

[72] MITRE CORPORATION: Common Vulnerabilities and Exposures - CWE-285 ImproperAuthorization. Techn. Ber., MITRE Corporation, 2014. Zugriff am 19.04.2015, Online:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451.

[73] NATIONAL ELECTRICAL MANUFACTURERS ASSOCIATION: Digital Imaging and Commu-nications in Medicine (DICOM): Part 15: Security and System Management Profiles.Techn. Ber., National Electrical Manufacturers Association, 2011. Zugriff am 19.04.2015,Online: http://medical.nema.org/DICOM/2011/11_15pu.pdf.

[74] NEEDHAM, R. M.: Proceedings of the 1st ACM Conference on Computer and Communi-cations Security, Fairfax, Virginia, November 3-5, 1993. Nr. 0-89791-629-8. ACM Press,New York, N.Y., 1993.

[75] NIST: Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules. Techn. Ber., NISTNational Institute of Standards and Technology, 2015. Zugriff am 19.04.2015, Online:rc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm.

[76] NOTTINGHAM, M.: Feed Paging and Archiving: RFC5005. Techn. Ber., The InternetEngineering Task Force, 2007. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc5005.

91

http://www.hl7.org/implement/standards/fhir/xml.html#atom

http://www.hl7.org/implement/standards/fhir/xml.html#atom

http://hl7.org/implement/standards/fhir/http.html#hdata

http://hl7.org/implement/standards/fhir/http.html#hdata

http://hl7.org/implement/standards/fhir/http.html#paging

http://hl7.org/implement/standards/fhir/http.html#paging

http://hl7.org/fhir/extras.html#tags

https://msdn.microsoft.com/en-us/library/ms978516.aspx

https://msdn.microsoft.com/en-us/library/ms978516.aspx

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451



http://medical.nema.org/DICOM/2011/11_15pu.pdf

rc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm



[77] NOTTINGHAM, M. und R. SAYRE: The Atom Syndication Format: RFC4287 . Techn.Ber., The Internet Engineering Task Force, 2005. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc4287.

[78] OWASP EUROPE: OWASP VZW Modelstatuten. Techn. Ber., OWASP Europe, 2013. Zu-griff am 19.04.2015, Online: https://www.owasp.org/images/9/90/126741_OWASP_vzw_modelstatuten_v0.9_EN_REV.pdf.

[79] OWASP FOUNDATION INC: OWASP Guide to Authorization. Techn. Ber., OWASPFoundation Inc, 2009. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/Guide_to_Authorization.

[80] OWASP FOUNDATION INC: OWASP Local Chapter ByLaws. Techn. Ber., OWASP Foun-dation Inc, 2011. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/Local_Chapter_ByLaws.

[81] OWASP FOUNDATION INC: Brute force attack . Techn. Ber., OWASP Foundation Inc,2013. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/Brute_force_attack.

[82] OWASP FOUNDATION INC: OWASP TOP 10 Project . Techn. Ber., OWASP Founda-tion Inc, 2013. Zugriff am 19.04.2015, Online: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf.

[83] OWASP FOUNDATION INC: OWASP CAL9000 Project . Techn. Ber., OWASP Foundati-on Inc, 2014. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/OWASP_CAL9000_Project.

[84] OWASP FOUNDATION INC: OWASP CSRF Tester Project . Techn. Ber., OWASP Foun-dation Inc, 2014. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project.

[85] OWASP FOUNDATION INC: OWASP WebScarab Project . Techn. Ber., OWASP Founda-tion Inc, 2014. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/OWASP_WebScarab_Project.

[86] OWASP FOUNDATION INC: OWASP Application Security Verification Standard Project .Techn. Ber., OWASP Foundation Inc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/ASVS.

[87] OWASP FOUNDATION INC: OWASP CSRF Guard Project . Techn. Ber., OWASPFoundation Inc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/CSRFGuard.

92



https://www.owasp.org/images/9/90/126741_ OWASP_vzw_modelstatuten_ v0.9_EN_REV.pdf

https://www.owasp.org/images/9/90/126741_ OWASP_vzw_modelstatuten_ v0.9_EN_REV.pdf

https://www.owasp.org/index.php/Guide_to_ Authorization

https://www.owasp.org/index.php/Guide_to_ Authorization

https://www.owasp.org/index.php/Local_ Chapter_ByLaws

https://www.owasp.org/index.php/Local_ Chapter_ByLaws

https://www.owasp.org/index.php/Brute_ force_attack

https://www.owasp.org/index.php/Brute_ force_attack

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf

https://www.owasp.org/index.php/OWASP_ CAL9000_Project

https://www.owasp.org/index.php/OWASP_ CAL9000_Project

https://www.owasp.org/index.php/Category:OWASP_ CSRFTester_Project

https://www.owasp.org/index.php/Category:OWASP_ CSRFTester_Project

https://www.owasp.org/index.php/OWASP_ WebScarab_Project

https://www.owasp.org/index.php/OWASP_ WebScarab_Project

https://www.owasp.org/index.php/ASVS

https://www.owasp.org/index.php/ASVS

https://www.owasp.org/index.php/CSRFGuard

https://www.owasp.org/index.php/CSRFGuard

[88] OWASP FOUNDATION INC: OWASP DOM based XSS Prevention Cheat Sheet . Techn.Ber., OWASP Foundation Inc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet.

[89] OWASP FOUNDATION INC: OWASP Risk Rating Methodology . Techn. Ber., OWASPFoundation Inc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology.

[90] OWASP FOUNDATION INC: OWASP Threat Agent . Techn. Ber., OWASP FoundationInc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/Category:Threat_Agent.

[91] OWASP FOUNDATION INC: OWASP Threat Modeling. Techn. Ber., OWASP Foundati-on Inc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/Threat_modeling#Objectives_of_Threat_Modeling.

[92] OWASP FOUNDATION INC: OWASP XSS Filter Evasion Cheat Sheet . Techn. Ber.,OWASP Foundation Inc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet.

[93] OWASP FOUNDATION INC: OWASP Zed Attack Proxy Project . Techn. Ber., OWASPFoundation Inc, 2015. Zugriff am 19.04.2015, Online: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project.

[94] PEMBERTON, S., M. ALTHEIM, D. AUSTIN, F. BOUMPHREY, J. BURGER, A. W. DONO-HO, S. DOOLEY, K. HOFRICHTER, P. HOSCHKA, I. MASAYASU, P. KING, P. KLANTE,S. MCCARRON, A. NAVARRO, Z. NIES, D. RAGGETT, P. SCHMITZ, S. SCHNITZENBAU-MER, P. STARK, C. WILSON, T. WUGOFSKI und D. ZIGMOND: XHTML 1.0 The Extensi-ble HyperText Markup Language (Second Edition): W3C Recommendation 26 January2000. Techn. Ber., World Wide Web Consortium, 2000. Zugriff am 19.04.2015, Online:http://www.w3.org/TR/xml/.

[95] PERVEZ, U., O. HASAN, K. LATIF, S. TAHAR, A. GAWANMEH und M. S. HAMDI: 2014IEEE 16th International Conference on e-Health Networking, Applications and Services(Healthcom 2014): Natal-RN, Brazil, 15 - 18 October 2014 ; [including workshops] . Nr.ISBN 9781479966448. IEEE, Piscataway, NJ, 2014.

[96] PERVEZ, U., O. HASAN, K. LATIF, S. TAHAR, A. GAWANMEH und M. S. HAMDI: Formalreliability analysis of a typical FHIR standard based e-Health system using PRISM. In: e-Health Networking, Applications and Services (Healthcom), 2014 IEEE 16th InternationalConference on, S. 43–48, 2014.

[97] PHILIPS, A. und M. DAVIS: Matching of Language Tags: RFC4647 . Techn. Ber., TheInternet Engineering Task Force, 2006. Zugriff am 19.04.2015, Online: https://www.ietf.org/rfc/rfc4647.txt.

93

https://www.owasp.org/index.php/DOM_based_ XSS_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/DOM_based_ XSS_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/OWASP_Risk_ Rating_Methodology

https://www.owasp.org/index.php/OWASP_Risk_ Rating_Methodology

https://www.owasp.org/index.php/Category:Threat_Agent

https://www.owasp.org/index.php/Category:Threat_Agent

https://www.owasp.org/index.php/Threat_ modeling#Objectives_of_Threat_ Modeling

https://www.owasp.org/index.php/Threat_ modeling#Objectives_of_Threat_ Modeling

https://www.owasp.org/index.php/XSS_Filter_ Evasion_Cheat_Sheet

https://www.owasp.org/index.php/XSS_Filter_ Evasion_Cheat_Sheet

https://www.owasp.org/index.php/OWASP_Zed_ Attack_Proxy_Project

https://www.owasp.org/index.php/OWASP_Zed_ Attack_Proxy_Project




[98] PHILIPS, A. und M. DAVIS: Tags for Identifying Languages: RFC4646. Techn. Ber., TheInternet Engineering Task Force, 2006. Zugriff am 19.04.2015, Online: https://www.ietf.org/rfc/rfc4646.

[99] RAGGETT, D.: HTML 4.01 Specification: Form Content Types. Techn. Ber., WorldWide Web Consortium, 1999. Zugriff am 19.04.2015, Online: http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type.

[100] SABUTSCH, S. und A. MENSE: Object Identifier (OID) Konzept für das Österreichi-sche Gesundheitswesen. Techn. Ber., Technikum Wien GmbH, Wien, 2010. Zu-griff am 19.04.2015, Online: https://www.gesundheit.gv.at/OID_Frontend/OID_Konzept_1-1-0.pdf.

[101] SCHADOW, G. und C. J. MCDONALD: The Unified Code for Units of Measure. Techn.Ber., Regenstrief Institute and Indiana University School of Informatics, 2013. Zugriff am19.04.2015, Online: http://unitsofmeasure.org/ucum.html.

[102] SEMERSHEIM, J.: Lightweight Directory Access Protocol (LDAP): The Protocol: RFC4511.Techn. Ber., The Internet Engineering Task Force, 2006. Zugriff am 19.04.2015, Online:http://tools.ietf.org/html/rfc4511.

[103] SNELL, J.: The Atom "deleted-entryËlement: RFC6721. Techn. Ber., The Internet En-gineering Task Force, 2012. Zugriff am 19.04.2015, Online: http://tools.ietf.org/html/rfc6721.

[104] STEVEN, J.: Threat Modeling - Perhaps It’s Time. Security & Privacy, IEEE, 8(3):83–86,2010.

[105] TABACEK, S.: The Definitive Guide to the Factor Analysis of Information Risk(FAIR). Techn. Ber., CXOWARE, 2012. Zugriff am 19.04.2015, Online: http://fairwiki.riskmanagementinsight.com/.

[106] WEIS, U.: Risikomanagement nach ISO 31000: Risiken erkennen und erfolgreich steuern; [Grundlagen und Einführung in das Thema Risikomanagement ; Inhalt der ISO 310000:der Geltungsbereich und die wesentlichen Inhalte ; Risikobewertungsmethoden] . Nr.ISBN 978-3-8276-3916-5 in WEKA-Praxislösungen. WEKA-Media, Kissing, 2009.

[107] WEST, M., A. BARTH und D. VEDITZ: Content Security Policy Level 2: Candidate Recom-mendation, 19 February 2015. Techn. Ber., World Wide Web Consortium, 2015. Zugriffam 19.04.2015, Online: http://www.w3.org/TR/CSP2/.

94



http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type

http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type

https://www.gesundheit.gv.at/OID_ Frontend/OID_Konzept_1-1-0.pdf

https://www.gesundheit.gv.at/OID_ Frontend/OID_Konzept_1-1-0.pdf

http://unitsofmeasure.org/ucum.html




http://fairwiki.riskmanagementinsight.com/

http://fairwiki.riskmanagementinsight.com/

http://www.w3.org/TR/CSP2/

Abbildungsverzeichnis

Abbildung 1. Beispielaufbau einer FHIR XML Ressource (Quelle:http://www.hl7.org/FHIR/shot.png) . . . . . . . . . . . . . . . . . . . . . . . 6

Abbildung 2. Die 4 Paradigmen der Interoperabilität (Quelle:http://www.corepointhealth.com/geni/interoperability-paradigms-hl7-fhir) . . 7

Abbildung 3. Ressourcen in FHIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Abbildung 4. UML Ressourcendefinition (Quelle:

http://hl7.org/implement/standards/fhir/formats.html) . . . . . . . . . . . . . 11Abbildung 5. Bundles in FHIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Abbildung 6. Übersicht Datentyp simple und primitive (Quelle:

http://www.hl7.org/fhir/datatypes.html) . . . . . . . . . . . . . . . . . . . . . 14Abbildung 7. Datentyp complex Teil 1 (Quelle: http://www.hl7.org/fhir/datatypes.html) . . 17Abbildung 8. Datentyp complex Teil 2 (Quelle: http://www.hl7.org/fhir/datatypes.html) . . 18Abbildung 9. Sonstige Datentypen (Quelle: http://www.hl7.org/fhir/datatypes.html) . . . . 19Abbildung 10. FHIR API Schnittstellenkonzept (Quelle: http://hl7.org/fhir/security.html) . . 45Abbildung 11. FHIR Provenance Schema (Quelle: http://www.hl7.org/fhir/provenance.html) 48Abbildung 12. FHIR Provenance Konzept (Quelle: http://www.hl7.org/fhir/provenance.html) 48Abbildung 13. Darstellung SecurityEvent Ressource (Quelle:

http://www.hl7.org/fhir/securityevent.html) . . . . . . . . . . . . . . . . . . . 49Abbildung 14. OAuth Schema Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Abbildung 15. OWASP Angriffs-

verlauf (Quelle http://owasptop10.googlecode.com/files/OWASP Top 10 -2013.pdf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Abbildung 16. Gesamtrisiko aller Bedrohungen, nach ID sortiert . . . . . . . . . . . . . . 79Abbildung 17. Gesamtrisiko aller Bedrohungen, nach Gesamtrisiko sortiert . . . . . . . . 80Abbildung 18. FHIR Conformance Request Schema . . . . . . . . . . . . . . . . . . . . . 112

95

Tabellenverzeichnis

Tabelle 1. Was ist eine Ressource? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Tabelle 2. Übersicht einfache Datentypen (Quelle: http://www.hl7.org/fhir/datatypes.html) 15Tabelle 3. Übersicht Datentypen primitive (Quelle: http://www.hl7.org/fhir/datatypes.html) 16Tabelle 4. API Methodenaufrufe R-benötigt, O-optional (Quelle:

http://hl7.org/implement/standards/fhir/http.html) . . . . . . . . . . . . . . . . . 33Tabelle 5. API Methodenantworten R-benötigt, O-optional (Quelle:

http://hl7.org/implement/standards/fhir/http.html) . . . . . . . . . . . . . . . . . 34Tabelle 6. SecurityEvent Protokolleinträge . . . . . . . . . . . . . . . . . . . . . . . . . . 50Tabelle 7. Tabellenübersicht Schutzziele . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Tabelle 8. Berechnung der durchschnittlichen Wahrscheinlichkeit . . . . . . . . . . . . . 62Tabelle 9. Berechnung der Auswirkungen (technisch, geschäftlich) . . . . . . . . . . . . 63Tabelle 10. Bewertungsskala Wahrscheinlichkeit und Auswirkung . . . . . . . . . . . . . . 63Tabelle 11. Berechnungstabelle für den Schweregrad . . . . . . . . . . . . . . . . . . . . 63Tabelle 12. OWASP Risikoprofil (Quelle http://owasptop10.googlecode.com/files/OWASP

Top 10 - 2013.pdf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Tabelle 13. OWASP Risikoprofil A1

- Injection (Quelle http://owasptop10.googlecode.com/files/OWASP Top 10 -2013.pdf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Tabelle 14. OWASP Risikoprofil A2 - Broken Authentication and Session Management(Quelle http://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf) . 67

Tabelle 15. OWASP Risikoprofil A3 - Cross-Site Scripting XSS (Quelle http://owasptop10.googlecode.com/files/OWASPTop 10 - 2013.pdf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Tabelle 16. OWASP Risikoprofil A4 - Insecure Direct Object References (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf) . . . . . . 70

Tabelle 17. OWASP Risikoprofil A5 - Securi-ty Misconfiguration (Quelle http://owasptop10.googlecode.com/files/OWASPTop 10 - 2013.pdf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Tabelle 18. OWASP Risikoprofil A6 - Sensitive DataExposure (Quelle http://owasptop10.googlecode.com/files/OWASP Top 10 -2013.pdf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Tabelle 19. OWASP Risikoprofil A7 - Missing Function Level Access Control (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf) . . . . . . 73

96

Tabelle 20. OWASP Risikoprofil A8 - Cross-Site Request Forgery CSRF (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf) . . . . . . 73

Tabelle 21. OWASP Risikoprofil A9 - Using Known Vulnerable Components (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf) . . . . . . 74

Tabelle 22. OWASP Risikoprofil A10 - Unvalidated Redirects and Forwards (Quellehttp://owasptop10.googlecode.com/files/OWASP Top 10 - 2013.pdf) . . . . . . 75

Tabelle 23. Ergebnis der Risikoanalyse Zusammengefasst . . . . . . . . . . . . . . . . . 81Tabelle 24. OWASP Risk Rating Model - Indentifizierte Threats . . . . . . . . . . . . . . . 116Tabelle 25. OWASP Risk Rating Model - Analysematrix . . . . . . . . . . . . . . . . . . . 120Tabelle 26. OWASP Full Attack List Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Tabelle 27. OWASP Full Attack List Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

97

Quellcodeverzeichnis

Quellcode 1. XML Ressourcendefinition Beispiel . . . . . . . . . . . . . . . . . . . . . . 9Quellcode 3. FHIR XML Beispiel Nachrichtenaufbau . . . . . . . . . . . . . . . . . . . . 14Quellcode 4. XML Datentyp ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Quellcode 5. Allgemeine Suche mittels HTTP GET . . . . . . . . . . . . . . . . . . . . . 28Quellcode 6. Suche nach Ressourcentyp mittels HTTP GET . . . . . . . . . . . . . . . 29Quellcode 7. Suche nach Compartments mittels HTTP GET . . . . . . . . . . . . . . . . 29Quellcode 8. XML Aufruf für einen Conformance Request . . . . . . . . . . . . . . . . . 30Quellcode 9. HTTP POST einer Transaktion . . . . . . . . . . . . . . . . . . . . . . . . . 30Quellcode 10. Referenzlink als Atom–Link . . . . . . . . . . . . . . . . . . . . . . . . . . 32Quellcode 11. HTTP GET Suchaufruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Quellcode 12. Suche über die id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Quellcode 13. Aufruf mittels read über die id . . . . . . . . . . . . . . . . . . . . . . . . . 35Quellcode 14. Suche über Datum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Quellcode 15. Suche über Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Quellcode 16. Suche über Codewert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Quellcode 17. Suche über codierten Code . . . . . . . . . . . . . . . . . . . . . . . . . . 38Quellcode 18. Suche über die Menge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Quellcode 20. Suche über Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Quellcode 21. Verkettete Suchparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Quellcode 22. Kombinierte Suchparameter . . . . . . . . . . . . . . . . . . . . . . . . . . 40Quellcode 23. Suchparameter mit Relevanzinformationen . . . . . . . . . . . . . . . . . . 40Quellcode 24. Rekursive Suchparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Quellcode 25. Suchergebnis mit externen Referenzen . . . . . . . . . . . . . . . . . . . . 41Quellcode 26. XML Datentyp Quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Quellcode 27. XML Datentyp Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Quellcode 28. XML Datentyp Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Quellcode 29. XML Datentyp Codeable Concept . . . . . . . . . . . . . . . . . . . . . . . 103Quellcode 30. XML Datentyp Attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Quellcode 31. XML Datentyp Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Quellcode 32. XML Datentyp Sampled Data . . . . . . . . . . . . . . . . . . . . . . . . . 104Quellcode 33. XML Datentyp Human Name . . . . . . . . . . . . . . . . . . . . . . . . . 104Quellcode 34. XML Datentyp Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Quellcode 35. XML Datentyp Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Quellcode 36. XML Datentyp Contact Point . . . . . . . . . . . . . . . . . . . . . . . . . . 105

98

Quellcode 37. XML Datentyp Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Quellcode 38. XML Datentyp Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Quellcode 39. XML Datentyp Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Quellcode 40. XML Datentyp Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Quellcode 41. XML Nachricht interne Referenz Typ 1 . . . . . . . . . . . . . . . . . . . . 107Quellcode 42. XML Nachricht interne Referenz Typ 2 . . . . . . . . . . . . . . . . . . . . 107Quellcode 43. XML Nachricht interne Referenz Typ 3 . . . . . . . . . . . . . . . . . . . . 107Quellcode 44. XML Bundle im ATOM Format . . . . . . . . . . . . . . . . . . . . . . . . . 107Quellcode 45. XML Conformance Request Antwort . . . . . . . . . . . . . . . . . . . . . 109Quellcode 46. Liste aller HTTP Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 121

99

Abkürzungsverzeichnis

ACDE Access Control Decision Engine

API Application Programming Interface

APP Atom Publishing Protocol

APT Advanced Persistent Threat

AS Assessment Scope

ASF Atom Syndication Format

ASTM American Society for Testing and Materials

ASVS Application Security Verification Standard Project

ATNA Audit Trail and Node Authentication

BSI Bundesamt für Sicherheit in der Informationstechnik

CDA Clinical Document Architecture

CSP Content Security Policy

CSRF Cross-Site Request Forgery

CXF CeltiXFire

DLL Dynamic Link Library

DOM Document Object Model

DoS Denial of Service

DSG Document Digital Signature

EKG Elektrokardiogramm

FHIR Fast Healthcare Interoperability Resources

GDA Gesundheitsdiensteanbieter

HCS Healthcare Classification System

100

HIPPA Health Insurance Portability and Accountability Act

HIV Humane Immundefizienz-Virus

HL7 Health Level 7

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

IETF Internet Engineering Task Force

IHE Integrating the Healthcare Enterprise

IUA Internet User Authorization

J2EE Java Platform Enterprise Edition

JACHO Joint Commission on Accreditation of Healthcare Organizations

JSON JavaScript Object Notation

KPI Key Performance Indicator

LDAP Lightweight Directory Access Protocol

MAC Media Access Control

NEMA National Electrical Manufacturers Association

NIST National Institute of Standards and Technology

OID Object Identifier

OMG Object Managment Group

OS Operating System

OWASP Open Web Application Security Project

PCI Payment Card Industry

PHP Hypertext Preprocessor

REGEX Regular Expression

REST Representational State Transfer

RFC Request for Comments

SM System Modeling

101

SQL Structured Query Language

SSL Secure Sockets Layer

TCP Transmission Control Protocol

TLS Transport Layer Security

UCUM The Unified Code for Units of Measure

URI Uniform Resource Identifier

URL Uniform Resource Locator

W3C World Wide Web Consortium

WASC Web Application Security Consortium

XHTML The Extensible HyperText Markup Language

XML Extensible Markup Language

XSS Cross-Site Scripting

102

A. Quellcodes



3 <value value="[decimal]"/>

4 <comparator value="[code]"/>

5 <units value="[string]"/>

6 <system value="[uri]"/>

7 <code value="[code]"/>

8 </[name]>

Quellcode 26: XML Datentyp Quantity



3 <low></low>

4 <high></high>

5 </[name]>

Quellcode 27: XML Datentyp Range



3 <system value="[uri]"/>

4 <version value="[string]"/>

5 <code value="[code]"/>

6 <display value="[string]"/>

7 <primary value="[boolean]"/>

8 <valueSet></coding>

4 <text value="[string]"/>

5 </[name]>

Quellcode 29: XML Datentyp Codeable Concept

103



3 <contentType value="[code]"/>

4 <language value="[code]"/>

5 <data value="[base64Binary]"/>

6 <url value="[uri]"/>

7 <size value="[integer]"/>

8 <hash value="[base64Binary]"/>

9 <title value="[string]"/>

10 </[name]>

Quellcode 30: XML Datentyp Attachment



3 <start value="[dateTime]"/>

4 <end value="[dateTime]"/>

5 </[name]>

Quellcode 31: XML Datentyp Period



3 <origin></origin>

4 <period value="[decimal]"/>

5 <factor value="[decimal]"/>

6 <lowerLimit value="[decimal]"/>

7 <upperLimit value="[decimal]"/>

8 <dimensions value="[integer]"/>

9 <data value="[string]"/>

10 </[name]>

Quellcode 32: XML Datentyp Sampled Data



3 <use value="[code]"/>

4 <text value="[string]"/>

5 <family value="[string]"/>

6 <given value="[string]"/>

7 <prefix value="[string]"/>

8 <suffix value="[string]"/>

9 <period></period>

10 </[name]>

Quellcode 33: XML Datentyp Human Name

104



3 <use value="[code]"/>

4 <label value="[string]"/>

5 <system value="[uri]"/>

6 <value value="[string]"/>

7 <period></period>

8 <assigner></assigner>

9 </[name]>

Quellcode 34: XML Datentyp Identifier



3 <event></event>

4 <repeat> 

5 <frequency value="[integer]"/>

6 <when value="[code]"/>

7 <duration value="[decimal]"/>

8 <units value="[code]"/>

9 <count value="[integer]"/>

10 <end value="[dateTime]"/>

11 </repeat>

12 </[name]>

Quellcode 35: XML Datentyp Schedule



3 <system value="[code]"/>

4 <value value="[string]"/>

5 <use value="[code]"/>

6 <period></period>

7 </[name]>

Quellcode 36: XML Datentyp Contact Point

105



3 <use value="[code]"/>

4 <text value="[string]"/>

5 <line value="[string]"/>

6 <city value="[string]"/>

7 <state value="[string]"/>

8 <postalCode value="[string]"/>

9 <country value="[string]"/>

10 <period></period>

11 </[name]>

Quellcode 37: XML Datentyp Address



3 <reference value="[string]"/>

4 <display value="[string]"/>

5 </[name]>

Quellcode 38: XML Datentyp Reference

1 <[name] xmlns="http://hl7.org/fhir" url="Link zur Beschreibung der Erweiterung

(uri)"> doco


3 <value[x]></value[x]>

4 </[name]>

Quellcode 39: XML Datentyp Extension



3 <status value="[code]"/>

4 <div xmlns="http://www.w3.org/1999/xhtml"> 

</div>

5 </[name]>

Quellcode 40: XML Datentyp Narrative

106

1 <Document xmlns="http://hl7.org/fhir">

2 <extension>...</extension>

3 <text>...</text>

4 <contained>

5 <Organization id="org1">

6 

7 </Organization>

8 </contained>

9 <information>

10 

11 <custodian>

12 <reference value="#org1" />

13 </custodian>

14 

15 <information>

16 </Document>

Quellcode 41: XML Nachricht interne Referenz Typ 1

1 \begin{lstlisting}

2 <Patient xmlns="http://hl7.org/fhir">

3 <text>

4 <status value="generated"/>

5 <div xmlns="http://www.w3.org/1999/xhtml">

6 <p>... <span idref="dob"/>30-11-1972</span>

7 </div>

8 </text>

9 <birthDate id="dob" value="1972-11-30" />



2 <Patient xmlns="http://hl7.org/fhir">

3 <text>

4 <status value="generated"/>

5 <div xmlns="http://www.w3.org/1999/xhtml">

6 <p>... <img src="#pic1"/>. ....</p>

7 </div>

8 </text>

9 <contained>

10 <Binary id="pic1" contentType="image/gif">MEKH....SD/Z</Binary>

11 </contained>



2 <feed xmlns="http://www.w3.org/2005/Atom"> doco

3 <title></title>

4 <id></id>

5 <link rel="self" href="[building application url (Service base on

REST)]"/>

107

6 <link rel="first" href="[paging: url for first page of result]"/>

7 <link rel="previous" href="[paging: url for previous page of result]"/>

8 <link rel="next" href="[paging: url for next page of result]"/>

9 <link rel="last" href="[paging: url for last page of result]"/>

10 <link rel="fhir-base" href="[base path to resolve local urls in this

bundle]"/>

11 <os:totalResults xmlns:os="http://a9.com/-/spec/opensearch/1.1/"></os:totalResults>

13 <updated></updated>

14 <author>

15 <name></name>

16 <uri></uri>

17 </author>

18 <category term="[Tag Term]" label="[Tag Label]" scheme="[Tag Scheme]"/> 

19 <entry>

20 <title></title>

21 <id></id>

22 <link rel="self" href="Version Specific reference to Resource"></link>

23 <updated></updated>

24 <published></published>

25 <author>

26 <name></name>

27 <uri></uri>

28 </author>

29 

30 <category term="[Tag Term]" label="[Tag Label]" scheme="[Tag Scheme]"/> 

31 <content type="text/xml">

32 <[ResourceName] xmlns="http://hl7.org/fhir">

33 

34 </[ResourceName]>

35 </content>

36 <summary type="xhtml">

37 <div xmlns="http://www.w3.org/1999/xhtml"></div>

38 </summary>

39 </entry>

40 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

41 

42 </Signature>

43 </feed>

Quellcode 44: XML Bundle im ATOM Format

108

1 <Conformance xmlns="http://hl7.org/fhir"> doco

2 

3 <identifier value="[string]"/>

4 <version value="[string]"/>

5 <name value="[string]"/>

6 <publisher value="[string]"/>

7 <telecom></telecom>

8 <description value="[string]"/>

9 <status value="[code]"/>

10 <experimental value="[boolean]"/>

11 <date value="[dateTime]"/>

12 <software> 

13 <name value="[string]"/>

14 <version value="[string]"/>

15 <releaseDate value="[dateTime]"/>

16 </software>

17 <implementation> 

18 <description value="[string]"/>

19 <url value="[uri]"/>

20 </implementation>

21 <fhirVersion value="[id]"/>

22 <acceptUnknown value="[boolean]"/>

23 <format value="[code]"/>

24 <profile></profile>

25 <rest> 

26 <mode value="[code]"/>

27 <documentation value="[string]"/>

28 <security> 

29 <cors value="[boolean]"/>

30 <service></service>

31 <description value="[string]"/>

32 <certificate> 

33 <type value="[code]"/>

34 <blob value="[base64Binary]"/>

35 </certificate>

36 </security>

109

37 <resource> 

38 <type value="[code]"/>

39 <profile></profile>

40 <operation> 

41 <code value="[code]"/>

42 <documentation value="[string]"/>

43 </operation>

44 <readHistory value="[boolean]"/>

45 <updateCreate value="[boolean]"/>

46 <searchInclude value="[string]"/>

47 <searchParam> 

48 <name value="[string]"/>

49 <definition value="[uri]"/>

50 <type value="[code]"/>

51 <documentation value="[string]"/>

52 <target value="[code]"/>

53 <chain value="[string]"/>

54 </searchParam>

55 </resource>

56 <operation> 

57 <code value="[code]"/>

58 <documentation value="[string]"/>

59 </operation>

60 <query> 

61 <name value="[string]"/>

62 <definition value="[uri]"/>

63 <documentation value="[string]"/>

64 <parameter></parameter>

65 </query>

66 <documentMailbox value="[uri]"/>

67 </rest>

68 <messaging> 

69 <endpoint value="[uri]"/>

70 <reliableCache value="[integer]"/>

71 <documentation value="[string]"/>

72 <event> 

73 <code></code>

110

74 <category value="[code]"/>

75 <mode value="[code]"/>

76 <protocol></protocol>

77 <focus value="[code]"/>

78 <request></request>

79 <response></response>

80 <documentation value="[string]"/>

81 </event>

82 </messaging>

83 <document> 

84 <mode value="[code]"/>

85 <documentation value="[string]"/>

86 <profile></profile>

87 </document>

88 </Conformance>

Quellcode 45: XML Conformance Request Antwort

111

B. Weitere Abbildungen

Abbildung 18.: FHIR Conformance Request Schema

112

C. Identifizierte Threats

ID Identifizierte Threats Bereich Bedrohungsgruppen

1 MA im Krankenhaus kann sich einloggen FHIR Sicherheitssystem Angestellte

2 MA kann Daten von einem anderen Krankenhaus abfragen FHIR Sicherheitssystem Angestellte

3 MA im Krankenhaus wird entlassen FHIR Sicherheitssystem Angestellte

4 MA schickt Befunde an ein anderes Krankenhaus API Angestellte

5 MA schickt falsche Befunde an ein anderes Krankenhaus (unbewusst) API Angestellte

6 MA schickt falsche Befunde an ein anderes Krankenhaus (bewusst) FHIR Sicherheitssystem Angestellte

7 MA löscht einen Patienten aus versehen API Angestellte

8 Verschiedene MA verwenden idente Zugangsdaten FHIR Sicherheitssystem Angestellte

9 Ärztliches Personal lässt seine Arbeit durch Hilfspersonal erledigen Betrieb Angestellte

10 Notbetrieb (break-the-glass) ohne Veranlassung FHIR Sicherheitssystem Angestellte

11 MA steckt einen USB Stick im KH an Betrieb Angestellte

12 MA surft im Internet während er in FHIR eingeloggt ist Betrieb Angestellte

13 MA meldet sich nicht ordnungsgemäß ab Sozial Angestellte

14 MA merkt sich das Kennwort nicht (Zettel am Monitor) Betrieb Angestellte

15 Vergabe der Zugangskennungen zum Repository ungenügend Implementierung Angestellte

16 Zentraler Zugriff via GDA? Rollenkonzept? FHIR Sicherheitssystem Angestellte

17 VIP Patient im Krankenhaus möchte auf seine Befunde zugreifen Betrieb Menschen (unbeabsichtigt)

18 AdministratorIn im Krankenhaus Betrieb Menschen (unbeabsichtigt)

113

19 AdministratorIn bekommt Geld geboten für Zugriff Sozial Menschen (beabsichtigt)

20 Putzfrau bekommt Geld geboten für Zugriff Sozial Menschen (beabsichtigt)

21 Updates werden nicht eingespielt Kosten Angestellte

22 Patchen beim Bekanntwerden von Lücken in FHIR Kosten Angestellte

23 Sicherheitsunterschiede je nach FHIR Implementierungsvariante Implementierung Menschen (unbeabsichtigt)

24 Patient im Krankenhaus will auf seine Daten zugreifen FHIR Sicherheitssystem Menschen (unbeabsichtigt)

25 MA ist technisch versiert und versucht Zugriff zu bekommen API Menschen (beabsichtigt)

26 MA via VPN von extern Betrieb Menschen (beabsichtigt)

27 Laborgerät schickt Daten an FHIR API Nicht Zielspezifisch

28 Laborgerät empfängt Daten von FHIR API Nicht Zielspezifisch

29 Zwei Repositories synchronisieren sich gegenseitig API Andere Unternehmen

30 Wer kontrolliert das Authentifizierungssystem? FHIR Sicherheitssystem Angestellte

31 Sicherung (Backup) von FHIR Daten Betrieb Angestellte

32 Kontrolle der Zugriffe Betrieb Angestellte

33 DoS Angriffe auf das Webservice Extern Organisiertes Verbrechen

34 Unterschiede interner Zugriff, externer Zugriff Extern Menschen (beabsichtigt)

35 Externe links in Ressourcen FHIR Spezifikation Organisiertes Verbrechen

36 Manipulierte Antworten FHIR Spezifikation Organisiertes Verbrechen

37 Zu große Dateien FHIR Spezifikation Organisiertes Verbrechen

38 Legacy System fehlerhaft und überschreibt Daten API Menschen (beabsichtigt)

39 Datentyp Narrative verwundbar gegen alle XHTML vulnerabilities FHIR Spezifikation Organisiertes Verbrechen

40 Patient möchte über Handy seine Befunde abrufen API Menschen (beabsichtigt)

41 Patient möchte über PC seine Befunde abrufen API Menschen (beabsichtigt)

42 Frau vom Patient möchte seine Befunde abrufen API Menschen (beabsichtigt)

43 Krankenhaus bietet Patientenservice auf derselben Infrastrutkur wie FHIR an API Menschen (beabsichtigt)

44 Brute-Force auf einen Patientenaccount –> dieser wird gesperrt API Organisiertes Verbrechen

114

45 Admin-Zugang über die API API Organisiertes Verbrechen

46 Patient hat einen Virus am Computer API Menschen (unbeabsichtigt)

47 API erkennt, das das Device verwundbar ist API Organisiertes Verbrechen

48 Fortlaufende Vergabe von IDs API Organisiertes Verbrechen

49 OAuth Lücken checken Betrieb Organisiertes Verbrechen

50 BenutzerIn mit demselben OAuth Account noch bei einem anderen Service Betrieb Menschen (unbeabsichtigt)

51 Regex checken API Organisiertes Verbrechen

52 Unterschiede FHIR in den einzelnen Programmiersprachen API Organisiertes Verbrechen

53 Patient postet Zugangsdaten, sonstiges Sozial Menschen (unbeabsichtigt)

54 Sicherheitsunterschiede je nach FHIR Variante? FHIR Spezifikation Menschen (beabsichtigt)

55 Webprogrammierer noch unerfahren Implementierung Menschen (unbeabsichtigt)

56 Webservice ist extern gehostet Implementierung Andere Unternehmen

57 Krankenhausverbund hat Partner –> wie ist deren Zugriff geregelt? Implementierung Andere Unternehmen

58 Webservices werden nicht korrekt gepatcht Implementierung Menschen (unbeabsichtigt)

59 Interner Zugriff, Audit log gefälscht Implementierung Angestellte

60 Fertiges Framework aus dem Netz, da billig, schnell, kostensparend Implementierung Angestellte

61 Mobile App ist nicht vertrauenswürdig Implementierung Organisiertes Verbrechen

62 Google-Browser (Android) vulnerable für alle Apps API Organisiertes Verbrechen

63 Konfigurationsfehler in der Middleware Implementierung Angestellte

64 Q/P System Implementierung Menschen (unbeabsichtigt)

65 Entwickler-Backdoors API Organisiertes Verbrechen

66 Unsichere Konfigurationen (Ciphers, Libraries, etc) Implementierung Organisiertes Verbrechen

67 Aus Kompatibilitätsgründen alte Protokolle aktiv Implementierung Organisiertes Verbrechen

68 Fehler zwischen den Versionen (mobile Version, Browser-Flags geändert,etc. . . )

API Organisiertes Verbrechen

69 php.info (Versionsnummern) Implementierung Menschen (unbeabsichtigt)

115

70 Anderes Krankenhaus wird Konkurent Sozial Andere Unternehmen

71 Pharamaindustrie hat großes interesse an Daten Sozial Andere Unternehmen

72 Auswertung der Zugriffe, Statistiken Sozial Andere Unternehmen

73 Big Data –> Datenzugriff via OpenData gewünscht Extern Andere Unternehmen

75 Geräte im KH liefern Daten, müssen immer laufen, Kennwörter gesperrt API Menschen (unbeabsichtigt)

76 API Suche –> Verwundbarkeit, Auslastung API Menschen (unbeabsichtigt)

77 Partner zieht sich über einen längeren Zeitraum Daten Betrieb Menschen (beabsichtigt)

78 Webservice Fehlertoleranz. Bekomme ich was erwartet wurde? API Organisiertes Verbrechen

79 CSS von exterenen quellen Implementierung Organisiertes Verbrechen

80 Stylesheets nachladen (durch Browser automatisch) Implementierung Organisiertes Verbrechen

81 Agiles Datenbanksystem (PostgreSQL) Implementierung Menschen (unbeabsichtigt)

82 Fertige Implemenierungen mit Fehlern Implementierung Menschen (unbeabsichtigt)

83 Fertige Apps mit Fehlern Implementierung Menschen (unbeabsichtigt)

Tabelle 24.: OWASP Risk Rating Model - Indentifizierte Threats

116

D. Analysematrix

Assessment Scope Technisch Geschäftlich Auswirkung Risiko

Thre

at

Fach

wis

sen

Mot

ivat

ion

Mög

lichk

eit

Grö

ße

Find

en

Aus

nütz

en

Bek

annt

heit

Erk

enne

n

Wah

rsch

einl

ichk

eit

Bew

ertu

ng

Vert

raul

ichk

eit

Inte

gritä

t

Verfü

gbar

keit

Vera

ntw

ortli

chke

it

Aus

wirk

ung

tech

nisc

hab

s

Aus

wirk

ung

tech

nisc

h

Fina

nzie

llerS

chad

en

Rep

utat

ion

Ges

etze

slag

e

Priv

atsp

häre

Aus

wirk

ung

gesc

häftl

ich

abs

Aus

wirk

ung

gesc

häftl

ich

Aus

wirk

ung

gesa

mta

bs

Aus

wirk

ung

gesa

mt

Ges

amtr

isik

o

1 4 1 7 4 7 5 6 8 3,75 mittel 2 1 1 1 1,25 gering 1 1 5 5 3,00 mittel 2,13 gering sehr gering

2 4 1 7 4 7 5 6 8 3,75 mittel 6 3 1 1 2,75 gering 1 5 5 5 4,00 mittel 3,38 mittel gering

3 4 9 7 4 7 5 6 8 4,75 mittel 7 7 5 1 5,00 mittel 3 5 9 3 5,00 mittel 5,00 mittel mittel

4 4 1 7 4 7 5 6 8 3,75 mittel 6 3 1 1 2,75 gering 1 1 5 3 2,50 gering 2,63 gering sehr gering





9 4 1 7 4 3 5 6 3 2,63 gering 6 1 1 7 3,75 mittel 1 1 5 5 3,00 mittel 3,38 mittel mittel



117


13 4 1 7 4 7 5 6 8 3,75 mittel 6 3 1 7 4,25 mittel 1 1 5 3 2,50 gering 3,38 mittel mittel





18 1 4 7 2 3 5 4 9 3,38 mittel 9 9 9 1 7,00 hoch 3 5 9 3 5,00 mittel 6,00 hoch kritisch


20 9 9 7 6 3 3 4 8 5,13 mittel 6 7 5 7 6,25 hoch 3 5 9 3 5,00 mittel 5,63 mittel hoch


















118















52 3 4 7 4 3 3 9 8 2,88 gering 2 1 1 7 2,75 gering 1 1 5 5 3,00 mittel 2,88 gering sehr gering





57 4 1 0 5 3 5 4 8 2,75 gering 6 7 5 7 6,25 hoch 1 1 5 5 3,00 mittel 4,63 mittel hoch

58 3 4 7 9 7 3 9 3 3,38 mittel 7 7 9 9 8,00 hoch 3 5 9 9 6,50 hoch 7,25 hoch kritisch






119


65 1 4 0 2 3 5 4 9 2,50 gering 6 7 5 7 6,25 hoch 3 5 9 3 5,00 mittel 5,63 mittel hoch













79 9 1 7 6 3 3 4 9 4,25 mittel 2 3 5 7 4,25 mittel 3 5 9 7 6,00 hoch 5,13 mittel mittel

80 9 1 7 6 7 3 4 8 4,63 mittel 2 3 5 7 4,25 mittel 3 5 9 7 6 hoch 5,13 mittel mittel

81 3 1 4 2 3 3 4 9 2,63 gering 2 1 1 7 2,75 gering 1 1 5 3 2,5 gering 2,63 gering sehr gering

82 3 4 7 6 7 3 4 9 4,38 mittel 7 7 5 9 7 hoch 3 1 9 7 5 mittel 6 hoch kritisch

83 9 4 7 6 7 3 4 8 5 mittel 7 7 5 9 7 hoch 3 1 9 7 5 mittel 6 hoch kritisch

Tabelle 25.: OWASP Risk Rating Model - Analysematrix

120

E. HTTP Status Codes

1 Value Description Reference

2 100 Continue [RFC7231, Section 6.2.1]

3 101 Switching Protocols [RFC7231, Section 6.2.2]

4 102 Processing [RFC2518]

5 103-199 Unassigned

6 200 OK [RFC7231, Section 6.3.1]

7 201 Created [RFC7231, Section 6.3.2]

8 202 Accepted [RFC7231, Section 6.3.3]

9 203 Non-Authoritative Information [RFC7231, Section 6.3.4]

10 204 No Content [RFC7231, Section 6.3.5]

11 205 Reset Content [RFC7231, Section 6.3.6]

12 206 Partial Content [RFC7233, Section 4.1]

13 207 Multi-Status [RFC4918]

14 208 Already Reported [RFC5842]


16 226 IM Used [RFC3229]


18 300 Multiple Choices [RFC7231, Section 6.4.1]

19 301 Moved Permanently [RFC7231, Section 6.4.2]

20 302 Found [RFC7231, Section 6.4.3]

21 303 See Other [RFC7231, Section 6.4.4]

22 304 Not Modified [RFC7232, Section 4.1]

23 305 Use Proxy [RFC7231, Section 6.4.5]

24 306 (Unused) [RFC7231, Section 6.4.6]

25 307 Temporary Redirect [RFC7231, Section 6.4.7]

26 308 Permanent Redirect [RFC7538]


28 400 Bad Request [RFC7231, Section 6.5.1]

29 401 Unauthorized [RFC7235, Section 3.1]

30 402 Payment Required [RFC7231, Section 6.5.2]

31 403 Forbidden [RFC7231, Section 6.5.3]

32 404 Not Found [RFC7231, Section 6.5.4]

33 405 Method Not Allowed [RFC7231, Section 6.5.5]

34 406 Not Acceptable [RFC7231, Section 6.5.6]

35 407 Proxy Authentication Required [RFC7235, Section 3.2]

36 408 Request Timeout [RFC7231, Section 6.5.7]

37 409 Conflict [RFC7231, Section 6.5.8]

38 410 Gone [RFC7231, Section 6.5.9]

39 411 Length Required [RFC7231, Section 6.5.10]

40 412 Precondition Failed [RFC7232, Section 4.2]

41 413 Payload Too Large [RFC7231, Section 6.5.11]

42 414 URI Too Long [RFC7231, Section 6.5.12]

121

43 415 Unsupported Media Type [RFC7231, Section 6.5.13]

44 416 Range Not Satisfiable [RFC7233, Section 4.4]

45 417 Expectation Failed [RFC7231, Section 6.5.14]


47 421 Misdirected Request [RFC-ietf-httpbis-http2-17, Section

9.1.2]

48 422 Unprocessable Entity [RFC4918]

49 423 Locked [RFC4918]

50 424 Failed Dependency [RFC4918]

51 425 Unassigned

52 426 Upgrade Required [RFC7231, Section 6.5.15]

53 427 Unassigned

54 428 Precondition Required [RFC6585]

55 429 Too Many Requests [RFC6585]

56 430 Unassigned

57 431 Request Header Fields Too Large [RFC6585]


59 500 Internal Server Error [RFC7231, Section 6.6.1]

60 501 Not Implemented [RFC7231, Section 6.6.2]

61 502 Bad Gateway [RFC7231, Section 6.6.3]

62 503 Service Unavailable [RFC7231, Section 6.6.4]

63 504 Gateway Timeout [RFC7231, Section 6.6.5]

64 505 HTTP Version Not Supported [RFC7231, Section 6.6.6]

65 506 Variant Also Negotiates [RFC2295]

66 507 Insufficient Storage [RFC4918]

67 508 Loop Detected [RFC5842]

68 509 Unassigned

69 510 Not Extended [RFC2774]

70 511 Network Authentication Required [RFC6585]


Quellcode 46: Liste aller HTTP Status Codes

122

F. OWASP Full Attack List

ATTACK LINK

Account lockout attack https://www.owasp.org/index.php/Account_lockout_attack

Asymmetric resource consumption (amplification) https://www.owasp.org/index.php/Asymmetric_resource_consumption_(amplification)

Binary planting https://www.owasp.org/index.php/Binary_planting

Blind SQL Injection https://www.owasp.org/index.php/Blind_SQL_Injection

Blind XPath Injection https://www.owasp.org/index.php/Blind_XPath_Injection

Brute force attack https://www.owasp.org/index.php/Brute_force_attack

Buffer overflow attack https://www.owasp.org/index.php/Buffer_overflow_attack

Cache Poisoning https://www.owasp.org/index.php/Cache_Poisoning

Cash Overflow https://www.owasp.org/index.php/Cash_Overflow

Code Injection https://www.owasp.org/index.php/Code_Injection

Command Injection https://www.owasp.org/index.php/Command_Injection

Comment Injection Attack https://www.owasp.org/index.php/Comment_Injection_Attack

Content Security Policy https://www.owasp.org/index.php/Content_Security_Policy

Content Spoofing https://www.owasp.org/index.php/Content_Spoofing

CORS OriginHeaderScrutiny https://www.owasp.org/index.php/CORS_OriginHeaderScrutiny

CORS RequestPreflighScrutiny https://www.owasp.org/index.php/CORS_RequestPreflighScrutiny

Credential stuffing https://www.owasp.org/index.php/Credential_stuffing

Cross Frame Scripting https://www.owasp.org/index.php/Cross_Frame_Scripting

Cross Site History Manipulation (XSHM) https://www.owasp.org/index.php/Cross_Site_History_Manipulation_(XSHM)

Cross Site Tracing https://www.owasp.org/index.php/Cross_Site_Tracing

Cross-Site Request Forgery (CSRF) https://www.owasp.org/index.php/Cross_Site_Request_Forgery_(CSRF)

Cross-site Scripting (XSS) https://www.owasp.org/index.php/Cross_site_Scripting_(XSS)

Cross-User Defacement https://www.owasp.org/index.php/Cross_User_Defacement

Cryptanalysis https://www.owasp.org/index.php/Cryptanalysis

CSRF https://www.owasp.org/index.php/CSRF

Custom Special Character Injection https://www.owasp.org/index.php/Custom_Special_Character_Injection

Denial of Service https://www.owasp.org/index.php/Denial_of_Service

Direct Dynamic Code Evaluation (’Eval Injection’) https://www.owasp.org/index.php/Direct_Dynamic_Code_Evaluation_’Eval_Injection’)

Execution After Redirect (EAR) https://www.owasp.org/index.php/Execution_After_Redirect_(EAR)

Forced browsing https://www.owasp.org/index.php/Forced_browsing

Format string attack https://www.owasp.org/index.php/Format_string_attack

Full Path Disclosure https://www.owasp.org/index.php/Full_Path_Disclosure

HTTP Request Smuggling https://www.owasp.org/index.php/HTTP_Request_Smuggling

HTTP Response Splitting https://www.owasp.org/index.php/HTTP_Response_Splitting

Tabelle 26.: OWASP Full Attack List Part 1

123

ATTACK LINK

Injection SQL https://www.owasp.org/index.php/SQL_Injection

LDAP injection https://www.owasp.org/index.php/LDAP_injection

Man-in-the-browser attack https://www.owasp.org/index.php/Man_in_the_browser_attack

Man-in-the-middle attack https://www.owasp.org/index.php/Man_in_the_middle_attack

Mobile code: invoking untrusted mobile code https://www.owasp.org/index.php/Mobile_code_invoking_untrusted_mobile_code

Mobile code: non-final public field https://www.owasp.org/index.php/Mobile_code_non_final_public_field

Mobile code: object hijack https://www.owasp.org/index.php/Mobile_code_object_hijack

One-Click Attack https://www.owasp.org/index.php/One_Click_Attack

Overflow Binary Resource File https://www.owasp.org/index.php/Overflow_Binary_Resource_File

Page Hijacking https://www.owasp.org/index.php/Page_Hijacking

Parameter Delimiter https://www.owasp.org/index.php/Parameter_Delimiter

Path Manipulation https://www.owasp.org/index.php/Path_Manipulation

Path Traversal https://www.owasp.org/index.php/Path_Traversal

Reflected DOM Injection https://www.owasp.org/index.php/Reflected_DOM_Injection

Regular expression Denial of Service - ReDoS https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_ReDoS

Relative Path Traversal https://www.owasp.org/index.php/Relative_Path_Traversal

Repudiation Attack https://www.owasp.org/index.php/Repudiation_Attack

Resource Injection https://www.owasp.org/index.php/Resource_Injection

Server-Side Includes (SSI) Injection https://www.owasp.org/index.php/Server_Side_Includes_SSI_Injection

Session fixation https://www.owasp.org/index.php/Session_fixation

Session hijacking attack https://www.owasp.org/index.php/Session_hijacking_attack

Session Prediction https://www.owasp.org/index.php/Session_Prediction

Setting Manipulation https://www.owasp.org/index.php/Setting_Manipulation

Special Element Injection https://www.owasp.org/index.php/Special_Element_Injection

Spyware https://www.owasp.org/index.php/Spyware

SQL Injection https://www.owasp.org/index.php/SQL_Injection

Traffic flood https://www.owasp.org/index.php/Traffic_flood

Trojan Horse https://www.owasp.org/index.php/Trojan_Horse

Unicode Encoding https://www.owasp.org/index.php/Unicode_Encoding

Web Parameter Tampering https://www.owasp.org/index.php/Web_Parameter_Tampering

Windows ::DATA alternate data stream https://www.owasp.org/index.php/Windows_DATA_alternate_data_stream

XPATH Injection https://www.owasp.org/index.php/XPATH_Injection

XSRF https://www.owasp.org/index.php/XSRF

Tabelle 27.: OWASP Full Attack List Part 2

124