Sicherheitskonzept für die Arztpraxis und die Telematikinfrastruktur der Praxis

Work in Progress — Der Artikel wird permanent erweitert. Stand: 19.09.2021

Die Grundlagen sind für uns Ärzt:innen bei der KBV – definiert. Rechtsgrundlage ist der § 75 SGB V

Detailinformationen der Anforderungen können bei der KBV nachgelesen werden.

Eine Handreichung zum Überleben bei IT Sicherheitsvorfällen

Weitergehende Informationen:

Der Einsatz der Telematikkomponenten (Konnector & Lesegerät) in der Arztpraxis ist defacto zwingend vorgeschrieben. Für einen Großteil der Komponenten sind dabei die Betreiber der Infrastruktur verantwortlich.

Auf der anderen Seite steht der Schutz der eingenen Infrastruktur. Die eigene Infrastruktur stellt dabei die IT in der Arzpraxis dar. Grundlegende Gedanken für den Schutz von Netzwerken hat Microsoft zusammengefasst.

Was ist Zonierung überhaupt

Zonierung oder Segmentierung schafft Schutzzonen, die bei möglichen Angriffen verhindern sollen, dass der Angreifer auf alle Geräte im Netzwerk direkten Zugriff erhält. Dazu werden entsprechende Zonen bzw. Segmente festgelegt, in denen sich bestimmte Dienste oder Applikationen befinden.

Der Zugriff auf die einzelnen Geräte im lokalen Netzwerk wird dabei durch unterschiedliche Methoden eingeschränkt, sodass der Anwender nur Zugriff auf die Systeme hat, die er wirklich braucht. Das Konzept folgt also der Maxime Zugriff nur wenn nötig und entspricht damit auch den üblichen Firewall-Konzepten, dass erst einmal alles verboten ist, was nicht erlaubt ist.

Wesentlich für das Konzept der Zonierung, ist das Überlegungen angestellt werden, was überhaupt an Geräten zum Einsatz kommt und welche Schäden entstehen könnten.

Die vorhandene Technik

Bei uns in der Praxis gibt es etliche Geräte von unterschiedlichsten Herstellern, hier einige Beispiele

Einteilung in Schutzzonen

Obige Komponenten werden alle zu unterschiedlichen Zwecken benötigt. Nur ein kleiner Teil hat eine direkte erforderliche Verbindung zu den Patienten-Daten, einige Systeme brauchen Ärzt:innen und das Praxispersonal. Viel von der erforderlichen Technik wird nur von Administratoren betreut.

Für die direkte Kommunikation mit den Patienten ist Telefon, FAX, Email, eine Website und die Verbindung zu Providern von Körpermessdaten erforderlich. Eine Einteilung in die Schutzonen ermöglicht es die Risiken zu bewerten und wenn möglich zu reduzieren.

Kurzer Ausflug in die Angriffsvektoren

Die wesentlichen Angriffe in den Jahren 2019-2021 können dabei drei groben Szenarien zugeordnet werden.

Die wichtigste ZeroDay Attacke war 2021 der Angriff die Microsoft Exchange Server (Hafnium). Die zu einem BSI Alert TLP RED führte. Wohlgemerkt, war es das zweite mal, dass das BSI TLP RED ausrief.

Ransomware Attacken basieren heute fast immer auf dem Szenario, dass relativ unverdächtiger Code ins Netzwerk eingeschleust wird und dann den wirklichen Schadcode erst nachlädt und ausführt. Die Funktionsweise von Emotet ist gut beschrieben Allgemeiner geht das Cert New Zealand auf Ransomware ein.

Supply-Chain Attacken, sind etwas ganz übles. Hier werden die Hersteller von Software angegriffen und der Schadecode befindet sich dann in der eigentlich vertrauenswürdigen Software der Hersteller. Auch da gab es bereits mehrere Angriffe in den letzten Jahren. 2021 hat der SolarWinds Hack traurige Berühmtheit erlangt und den halben Globus geschädigt.

Schutzzonen

Aus dem oben gesagtem ergeben im Prinzip vier sehr abstrakte Schutzzonen.

  • Betriebssystem und Applikation
  • Netzwerk
  • Speichersysteme
  • Human-Factor

Betriebssystem und Applikation

Die Aufteilung der Schutzonen ist dabei sehr grob und es sollte eine granularere Aufteilung vorgenommen werden. Bisher war es oft so, dass in der Praxis mit Sicherheitskonzepten oft lediglich das Thema Virenscanner verbunden wurde. Der Virenscannner schützt dabei lediglich den Bereich Betriebssystem und Applikation. Die Schutzwirkung ist dabei wie wir an den Angriffen der letzten Zeit gesehen haben jedoch sehr begrenzt, da moderne Ransomware in der Regel kaum eigenen gefährliche Code mitbringt. Was die Angreifer in der Regel druchführen bezeichnet man in der Fachwelt als „Living on the Land“ Attacke. Kurz gesagt wird dabei mit den auf dem Zielrechner vorhandenen Komponenten die tatsächliche Schadaktion ausgeführt. Diese sind von Virenscannern faktisch nur äußerst schwer erkennbar, lediglich Anomalien im Verhalten der Systeme könnte hinweise geben. Hier kann KI durch statistisches Training des normalen Verhaltens in der Zukunft viel zur Erkennung von Angriffen beitragen.

Nach der Ausführung und der Übernahme des ersten Rechners beginnt in der Regel die horizontale und vertikale Ausbreitung (auch East-West Traffic) und die „Privilege Escalation„. Diese Escalation ist häufig in kleinen Installationen nicht einmal erforderlich, da eh alle mit dem User arbeiten, der bei der Installation eingerichtet wurde.

Der Schutz auf den Betriebssystemen ist aus dieser Sicht der Dinge, zwar wirksam aber aufgrund des Angriffsverhaltens nicht ausreichend. Bei genauer Betrachtung der Situation eines Angriffs, ziehlt der Angreifer auf unsere Daten ab. Die Daten liegen dabei immer Speichermedien. Speichermedien sind überlicherweise Festplatten. Ob die Festplatten klassische Festplatten oder SolidStateDisks sind, ist egal.

Günstig für die Verfügbarkeit der Betriebsysteme ist es dabei die von der Hardware zu entkoppeln. Die Entkopplung erfolgt dabei durch Virtualisierung. Auf Servern ist Virtualisierung heute vollkommmen normal. Pro Argumente und Contra Argumente sind im Netz beschrieben. Gegen die Virtualisierung auf Servern spricht nichts. Virtualisierungsprodukte sind als open Source als auch kommerziell erhältlich. Die Kosten sind, zumindes bei kleinen Installationen, vernachlässigbar. Wir virtualisieren in unser Praxis Server-Betriebssysteme und auch die Arbeitsplatz-Computer.

Auch bei den Betriebssystemen und Applikationen kann es Sinn machen bereits eine Zonierung vorzunehmen. Wir haben für uns entschieden, eine planbare IT – Triage zu machen. Damit haben wir ein bestimmbares Minimum an Leistung, dass im Notfall auf einem gut ausgestatten PC betrieben werden kann.

Beispiel der Betriebssystem Zonierung einer Arztpraxis mit Aufteilung in Mission Critical, Normal Operation und Comfort Zone

Netzwerk

Das Netzwerk selber ist dabei wesentlicher Bestandteil der Ausbreitungsstrategien. Denn ohne Netzwerk keine Ausbreitung und nur begrenzter Schaden. Im Netzwerk muss also eine Ausbreitung in horizontaler, als auch vertikaler Richtung möglichst erschwert bzw. was kaum möglich erscheint verhindert werden. Hier kommt das Zonierungskonzept des Netzwerkes zum Tragen.

Beispiel von Netzwerkzonen

Die technische Umsetzung der Arztpraxis wird noch im Detail beschrieben.

Speichersysteme

Wie oben beschrieben sind die Speichermedien wesentlicher Teil auf den die Angriffe ausgeführt werden. Viele Angreifer wollen auf die eine oder andere Art persitieren, Daten abschöpfen oder Daten unbrauchbar machen. Persistieren dient dabei oft dem Überleben eines Neustarts. Daten abschöpfen oder unbrauchbar machen wird in letzter Zeit für Erpressungszwecke genutzt. Häufg stehen auch Angriffe im Vordergrund, die Spionage zum Ziel haben. Regelmäßig kommen dabei, zumindest bei bestimmten Gruppen auch beide Ziele zum Einsatz. Die Gestaltung der Speichersysteme ist die letzte Verteidigungslinie um Datenverlust zu verhindern bzw. zu reduzieren. Datenabfluss können Speichersysteme aufgrund Ihrer Funktion nicht verhindern. Der Diebstahl der Hardware als auch die Beschlagnahme durch Behörden und der damit einhergehende mögliche Datenabfluss kann nur durch das Speichersystem verhindert werden. Hier wirkt ein sinvolles Verschlüsselungskonzept Wunder. Offtpoic: Passwörter schützen ohne Verschlüsselung der Speichermedien lediglich zur Laufzeit des Systems.

Wesentlich ist dabei, dass Speichersystemen im Konzept der Sicherheitsarchitektur mehr Aufmerksamkeit geschenkt werden muss. Speicher ist mehr als das Speichermedium selber. Die besondere Präsenz von Speichersystemen kann man an den viel zitierten Backup- und Recovery-Konzepten erkennen. Wie bereits erwähnt sind die Speichersysteme die „last-line-of-defence“ wenn es um Datenverlust bzw Datenkonistenz geht.

Fragen, die sich nach meiner Erfahrung kaum ein Verantwortlicher oder ein Administrator stellt sind dabei von existenzieller Bedeutung. Die Schlagworte sind RPO, RTO und die Recovery-Fähigkeit an sich.

Was ist RPO?

Recovery Point Objective (RPO) bezieht sich im Allgemeinen auf die Datenmenge, die innerhalb eines für ein Unternehmen relevanten Zeitraums verloren gehen kann, bevor ein signifikanter Schaden entsteht, und zwar vom Zeitpunkt eines kritischen Ereignisses bis zum vorhergehenden Backup.

Was ist RTO?

Recovery Time Objective (RTO) bezieht sich oft auf die Menge an Zeit, die eine Anwendung, ein System und/oder ein Prozess ausfallen kann, ohne dass ein signifikanter Schaden für das Unternehmen entsteht, sowie auf die Zeit, die für die Wiederherstellung der Anwendung und ihrer Daten benötigt wird.

RPO und RTO Darstellung
Recovery-Fähigkeit

Mit Recovery-Fähigkeit ist gemeint, ob die Backups an sich wiederherstellbar sind. Die einzelnen Systeme wiederherzustellen ist den meisten Fällen einfach und gelingt. Komplexer wird die Sache, wenn mehrere einzelne Systeme den zeitlich gleichen Stand haben müssen, um eine funktionsfähige Landschaft zu bilden. Heutige Betriebssysteme unterstüzen die Wiederherstellung in der Regel mit Mechanismen wie VSS und ähnlichen Verfahren auf dem lokalen Rechner gut.

Verteilte Umgebungen benötigen einen etwas höheren Aufwand in der Planung. Besondere Vorsicht ist bei wachsenden Infrastrukturen walten zu lassen. Aus meiner Erfahrung als IT-Notfallmanager bei einem der größten IT-Dienstleister in Deutschland gibt es an dieser Stelle regelmäßig größte Probleme.

Weitere Fragen, die zur Sicherstellung eines Backup- und Desaster-Recovery-Konzepts sind reglmäßig, die Fragen nach den Schutzzielen. Diese Schutziele könnten zum Beispiel sein:

  • Virus Attack/Ransomware
  • Data corruption and Bit-Rod
  • Festplatten-Ausfälle
  • Rebulid-/ Wiederherstellungsfehler
  • System-Fehler
  • Brand
  • Stromausfall
  • Naturkatastrophen
  • Diebstahl/Vandalismus
  • Menschliche Fehler
  • Downtime

Die Liste stellt dabei keinen Anspruch auf Vollständigkeit dar.

Stark vereinfachte klassische Praxis
On- und Off-Site Replication der Daten

Mit der USB-Festplatte wird ein Backup durchgeführt.

Daten müssen zur Sicherstellung der Verfügbarkeit repliziert bzw. kopiert werden. Wikipedia definiert ein Backup :“Die auf einem Speichermedium redundant gesicherten Daten werden als Sicherungskopie, engl. Backup, bezeichnet.“ Der Storage wird durch die Virtualisierung auch virtualisiert. Durch die Virtualisierung sind die Backups deutlich einfacher. Es handelt sich um einige wenige Dateien. Diese sind jeoch sehr groß. Im einfachsten Fall können nun also nicht mehr die Daten nur die Daten der Systeme selbst gesichert werden sondern komplette Betriebssysteme mit Ihren Daten. Für die komplexen Installationen der Arztinformationssysteme ist dies von erheblichen Vorteil.

Ein sinnvolles Backup der Maschinen ist dabei nur möglich, wenn die virtuellen Maschinen ausgeschaltet sind. Dies kann zu erheblichen Laufzeitproblemen beim Backup führen. Laufzeiten von 24 Stunden dürfen auf keinen Fall überschritten werden. In der Regel steht für das Backup jedoch nur die Nacht zur Verfügung, da am nächsten Tag wieder gearbeitet werden muss. Bei Anwendung der Best-Praxis für die Backups entstehen zusätzlich sehr große Datenmengen.

In unserer Praxis ergaben sich schon beim Backup immer größere Herausforderungen bei den Laufzeiten, den Volumen und der Handhabung der Medien.

Ein Ansatz war dann nur geänderte Daten zu sichern. Damit hätten wir aber den Comfort und den Zeitgewinn einer vollständigen Systemsicherung verlieren. Dieses Szenariao war für uns nicht akzeptabel.

Die Lösung ist also den Storage, der an dem Virtualiserungslayer hängt zu virtualisieren. Damit hatten wir die Kontrolle über unsere Daten zurück. Die Virtualisierung von Storage ist in großen IT-Landschaften vollkommen normal und funktioniert in der Regel ohne Probleme. Einfache Raid-Systeme sind keine Virtualisierung von Storage, denn die Kontrolle verbleibt im Host.

Virtualisierte Server mit Speicher-Server

Mit der Virtualisierung des Storage konnte nun quasi von Außen festgestellt welche Daten sich verändert hatten. Durch die sehr abstrakte Sichtweise kann allerdings nicht mehr gesagt werden welche Datei vom Betriebssystem geändert wurde. Aus der Sicht des Storage existiert nur ein große Datei und der einzelne Blöcke geändert werden. Als Bild kann man sich ein Buch denken, in dem auf einzelne Seiten geschrieben wird. Das Buch sieht von außen immer gleich aus, der Inhalt ändert sich.

Der Speicher-Server ist wie der Name schon sagt auch nur ein Server. Warum also zwei Stück Blech ins haus holen, wenn doch eines ausreichend ist. Der Speicher-Server braucht grob gesagt CPU, Arbeitsspeicher und natürlich Speichermedien. Klingt so als könnte man den Speicher-Server virtualisieren. Gesagt getan.

Virtualisierte Server mit virtualisieten Speicher-Server

OK. Jetzt halten mich viele für jemanden, der die Quadratur des Kreises beschreibt.

Jetzt holen wir uns unser Backup.

Der Speicherserver weiß also welche Daten-Blöcke geändert wurden und kann diese feststellen. Jetzt hänge ich meine USB-Festplatte an den Speicherserver und lasse ganz einfach nur die geänderten Datenblöcke permanent auf die USB-Festplatte schreiben. Zur Sicherung gegen Festplattenausfälle kommt ein Raid zum Einsatz.

Moment, ich habe ein permantes Backup, was sogar zur Laufzeit existiert, dass ich mitnehmen kann? Ich schreibe nur die Änderung der Daten auf die Festplatte? Das soll funktionieren? Die Antwort ist wie JAEIN. Im Prinzip kann ich die USB Festplatte in dem Speicherserver als RAID 1 betrachten. Das funtkioniert sogar, hat aber den Nachteil, das die Antwortzeiten durch die langsame externe USB Platte in den Keller gehen. Synchrone Datenübertragung als Backup scheidet also aus. Nachteilig bei der synchronen Übertragung ist, dass die Backup-Daten immer synchron mit den produktiven Daten sind. Einen Angriff mit Ransomware kann damit nicht wirksam begegnet werden.

Was kann ein Speicherserver. Der Speicher-Server ist in der Lage Snapshots der Daten zu machen. Das Funktioniert so ähnlich wie das oben beschriebene VSS bei Windows. Die Snapshots sollten dabei möglichst effizient verwaltet werden. Es kommt daher nur ein Copy-on-Write System in betracht. Die anderen Systeme funktionieren, jedoch nicht so effizient.

Jetzt übertrage ich die Snapshots asynchron, also mit etwas zeitlichem Verzug, auf meine USB Festplatte. Je nach Einstellung der Systeme entsteht jetzt z.B. jede Stunde ein Snapshot der auf die USB – Festplatte übertragen werden kann.

Kurzer Rücksprung zu den Zielen von oben. Mit dem Snapshots auf der USB-Festplatte kann ich mich gegen Ransomware schützen. Das RAID schützt gegen Festplatten-Fehler. Lesefehler können bei klassichen RAID-System bedingt aufgefangen werden. Echter BIT-ROD und Datacorruption und ähnliches werden bei einfachen Systemen nicht wirksam verhindert. Enterprise-Systeme haben da weniger Probleme. BIT-ROD lässt sich dadurch verhindern, dass die Datenblöcke redundant auf der Festplatte abgelegt werden. Das ist typisch für ein Raid System. Die Daten müssen beim lesen jedoch validiert werden. Bei Hardware-RAID-Systemen erfolgt dies oft auf der Basis von Parity-Bits.

Wirklich sicher lässt sich BIT-ROD damit nicht erkennen. Eine kryptographische Absicherung der Redundanzinformationen erzeugt einen deutlich höheren Wahrheitswert als Parity-Bits. Es wird also ein System mit entsprechenden Eigenschaften gebraucht. Mit BIT-ROD lassen sich Rebuild und Wiederherstellungsfehler vergleichen, die anzuwendenden Methoden sind technisch sehr ähnlich und hängen von der Anzahl der Redundanzen ab. System-Fehler können mit der USB-Festplatte nicht abgefangen werden. Defekte Netzteile oder Spannungsspitzen zerstören diesen oftmals mit. Eine Absicherung gegen Brand, Diebstahl, Vandalismus oder Naturkatastrophen haben wir mit der USB-Platte nur erreicht, wenn diese täglich aus der Praxis entfernt wird. Dabei entsteht jedoch erneut die Frage nach der RPO. In der jetzigen Systemumgebung haben wir etliche Ziele also noch nicht erreicht!

Offsite-Replication

Als Offsite-Replication wird dabei die Replikation der Daten an einen entfernten Ort verstanden. Die minimalen Anforderungungen sollten dabei so hoch gesteckt werden, dass grundlegende Gefahren, wie Brand, Diebstahl und ähnliches Ihre Wirkung verlieren.

Darstellung der Offsite Replication

Mit der Beachtung der Ziele an eine verfügbare Architektur ist durch die Offsite-Replication der Schutz vor wesentlichen Bedrohungen, wie Diebstahl, Brand, Stromstörungen (nicht Ausfälle) erreicht worden.

Wird der Offsite Server ausreichend dimensoniert, so kann dieser die On-Site Aufgaben, zumindest für die Mission Critical – Zone übernehmen.

— AB HIER STEHT EINE ÜBERARBEITUNG AN — Ist derzeit nicht aktuell

Annahmen zur Sicherheitsarchitektur

Unter der Maßgabe, dass aus der Sicht des BSI und anderer Beteiligter die Arztpraxen als unsichere Strukturteilnehmer eingeschätzt werden ist davon auszugehen, dass der Konnektor, als auf das Kartenterminal ein ausreichendes Schutzniveau aufweisen und die Kommunkation vollständig abgesichert sein sollte.

Spannend ist dabei, dass die Kommunikation der Praxissoftware zum Konnektor nur über http mit Port 80 erfolgt. Hier ist bei Gelegenheit zu prüfen, welche Daten dabei übermittelt werden.

Im Vordergrund dieses Artikels steht jedoch der Schutz IT-Infrastruktur der Arzpraxis.

Unter der oben gemachten Annahme, dass die Arztpraxis als unsicher angesehen wird, kann man den Konnektor ebenso als unsicher aus der Sicht der Arztpraxen definieren.

Durch die Definition des Konnektors und des Kartenlesegerätes als unsicher bzw. feindlich ergibt sich der logische Standort des Konnektors. Der Konnektor ist durch seine feindliche Betrachtung nicht unter der Kontrolle der Arztpraxis und gehört damit eigentlich nicht einmal mehr in die DMZ.

Wir haben daher den Konnektor auf das Niveau der freundlichen Patienten und deren Mobilphones gesetzt. Damit steht der Konnektor aus unserer Sicht in der gegen das Praxisnetz abgesicherten „Roten/Blauen Zone“.

Zonierungskonzept Praxis

Denkbare Umsetzung

Dies hat nun jedoch zur Konequenz, dass der Konnektor aus der „Grünen Zone“ nicht mehr erreichbar ist, da dieser nun über ein eigenes eigenes xxx.xxx.xxx.xxx/24 Netz verfügt. Das einrichten von Routen zum dem Konnektor kann aus Sicherheitsgründen nicht erfolgen, da dieser dann ja die Grüne Zone kennen würde. Es gilt also zu vermeiden, dass die Grüne Zone dem Konnektor bekannt gemacht wird.

Der Konnektor ist dabei leider etwas zickig was den Zugriff von fremden Netzen angeht. Zugriffe sind anscheinend nur aus dem lokalen Subnetz zulässig.

An dieser Stelle kommen zwei mögliche und erprobte Verfahren zum Einsatz. Das erste Verfahren ist einfaches NAT über die Firewall. Diese Verfahren verschleiert dabei die wirklich IP des AIS beim zugriff auf den Konnektor.

NAT wird bei praktisch jedem Internetrouter verwendet, wie zum Beispiel der bekannten Fritz Box von AVM. Durch das NAT werden also nur Zugriffe von der Grünen Zone in die Rot/Blaue Zone erlaubt und das AIS muss den Zugriff initialisieren. Den Rückweg kennt dabei nur der Router, der die Session hält. Damit ist sehr gute Verschleierung möglich und Zugriffsverhinderung möglich.

Der zweite praktische Weg ist auf der anderen Seite der gute alte Proxy. Hier kann durchaus SQUID zum Einsatz kommen, da wie bereits oben dargestellt ein Zugriff auf den Konnektor per schlichtem HTTP erfolgt.

Praktische Umsetzung

Aufgrund der bereits vorhandenen komplexen Infrastrukturen unserer Praxis war die Integration in das feindliche Netzwerk Patienten WLAN (auch das WLAN für die Mobilgeräte der Mitarbeiter) relativ einfach zu realisieren. Die erforderlichen Netzwerksegmente waren bereits vorhanden und wurden genutzt.

Lediglich die Integration der notwendigen Firewall und Router-Regeln hatte ein wenig Aufwand zur Folge.
Da aktuell kein Proxy auf unserem Firewallsystem aktiviert war haben wir uns für die NAT Lösung entschieden.

Praktischer Aufbau Zonierung

Technische Umsetzung des Konzeptes

  • DSL Verbindung
  • Hardware
  • Virtualisierung
  • Storage-Server
  • VPN-Verbindung
  • Firewalls
  • Switche

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*
*