ePA-Sicherheitslücken: Lehren für Kundenportale im Mittelstand
Was bei der ePA passiert ist
Die elektronische Patientenakte gehört zu den sensibelsten IT-Systemen, die in Deutschland aktuell im Einsatz sind. Sie enthält Diagnosen, Medikationspläne, Arztbriefe und andere Daten, die zu den schützenswertesten überhaupt zählen. Genau deshalb war es überfällig, dass Sicherheitsforscher die Clients, also die Anwendungen, über die Ärzte, Apotheken und Versicherte auf die Akte zugreifen, sowie die dahinterliegende Telematikinfrastruktur genauer unter die Lupe genommen haben.
Laut der Berichterstattung von heise Security sind dabei kritische Schwachstellen aufgefallen, die inzwischen behoben wurden. Im Interview erklärt der Sicherheitsforscher Dr. Simon Weber, dass die Implementierungen blinde Flecken hatten. Das ist eine bemerkenswerte Formulierung, denn sie beschreibt genau das Problem, das in der IT-Sicherheit am häufigsten zu ernsten Vorfällen führt: Nicht die grundsätzliche Architektur eines Systems ist fehlerhaft, sondern die konkrete Umsetzung an einzelnen Stellen wurde nicht zu Ende gedacht oder nicht ausreichend getestet.
Details zu den einzelnen Lücken, etwa welche konkreten Angriffsszenarien möglich waren, nennt die verfügbare Zusammenfassung nicht. Wichtig ist an dieser Stelle aber weniger die technische Tiefe des Einzelfalls, sondern das Muster dahinter: Ein hochreguliertes, mit erheblichem Aufwand entwickeltes System, an dem viele Fachleute über Jahre gearbeitet haben, hatte trotzdem Schwachstellen, die erst durch gezielte Sicherheitsforschung ans Licht kamen.
Warum "blinde Flecken" das eigentliche Problem sind
Der Begriff blinder Fleck trifft es gut. Entwicklerteams bauen ein System nach Spezifikation, testen die vorgesehenen Abläufe, prüfen die Kernfunktionen und übersehen dabei Randbereiche, die außerhalb des ursprünglichen Denkrahmens liegen. Klassische Beispiele sind Schnittstellen zwischen zwei Systemen, die jedes für sich sauber funktionieren, deren Zusammenspiel aber nie unter Sicherheitsaspekten geprüft wurde. Oder Funktionen, die für einen bestimmten Anwendungsfall gedacht waren und später in einem anderen Kontext weiterverwendet werden, ohne dass jemand die neuen Risiken bewertet hat.
Bei der Telematikinfrastruktur kommt erschwerend hinzu, dass viele unterschiedliche Akteure beteiligt sind: Softwarehersteller, Betreiber der Infrastruktur, Praxen, Apotheken, Kassen. Jede Schnittstelle zwischen diesen Beteiligten ist ein potenzieller blinder Fleck, weil niemand allein die volle Verantwortung und den vollen Überblick über das Gesamtsystem hat. Genau dieses Muster, viele Beteiligte, viele Schnittstellen, viel Komplexität, findet sich in kleinerer Form in fast jedem mittelständischen IT-Projekt wieder, sobald ein Onlineshop an eine Warenwirtschaft angebunden wird, ein Kundenportal mit einer Buchhaltungssoftware spricht oder ein Buchungssystem Daten an ein CRM weiterreicht.
Der entscheidende Punkt für Unternehmer ist deshalb nicht die Frage, ob die eigene Software genauso kritisch ist wie eine elektronische Patientenakte. Der entscheidende Punkt ist, dass dieselbe Art von Fehlern, unklare Verantwortlichkeiten an Schnittstellen, ungetestete Randfälle, nachträglich erweiterte Funktionen ohne neue Sicherheitsprüfung, in praktisch jedem System auftreten kann, das über die Zeit gewachsen ist.
Was das für Unternehmen mit eigenen Datenbeständen bedeutet
Viele Mittelständler denken bei IT-Sicherheit zuerst an Antivirensoftware, Firewalls und E-Mail-Filter. Das ist wichtig, greift aber zu kurz, sobald ein Unternehmen eigene digitale Anwendungen betreibt, in denen Kundendaten liegen. Das betrifft längst nicht nur Arztpraxen oder Kliniken. Ein Handwerksbetrieb mit Kundenportal für Angebote und Rechnungen, ein Online-Händler mit eigenem Konto-Bereich, ein Dienstleister mit Terminbuchung und hinterlegten Kontaktdaten, ein B2B-Shop mit individuellen Preislisten je Kunde, sie alle verwalten personenbezogene oder geschäftskritische Daten in selbst entwickelten oder individuell angepassten Systemen.
Genau diese Individualentwicklungen und Anpassungen sind der Nährboden für blinde Flecken. Eine Standardsoftware wird zumindest vom Hersteller mit einer gewissen Regelmäßigkeit geprüft und aktualisiert. Eine intern gebaute Schnittstelle, ein selbst geschriebenes Plugin, eine Sonderlösung, die vor drei Jahren "schnell mal" für einen einzelnen Kunden gebaut wurde und seitdem niemand mehr angefasst hat, wird dagegen oft nie wieder auf Sicherheit geprüft. Genau solche vergessenen Ecken sind es, die bei einem echten Angriff oder bei einem Website-Audit zuerst auffallen, weil sie schlicht aus dem Blick geraten sind.
Ein zweiter Aspekt betrifft die Frage, wie ein Unternehmen überhaupt erfährt, dass es eine Lücke gibt. Im Fall der ePA war es gezielte Sicherheitsforschung, die die Probleme aufgedeckt hat, bevor sie ausgenutzt wurden. Viele mittelständische Systeme werden dagegen nie systematisch geprüft, weder von externen Fachleuten noch intern. Die Lücke fällt dann oft erst auf, wenn bereits etwas passiert ist, ein Datenabfluss, ein kompromittiertes Konto, eine Erpressung. An diesem Punkt ist der Schaden bereits entstanden, während eine vorherige Prüfung ihn hätte verhindern können.
Konkrete Handlungsschritte für den Mittelstand
Aus dem ePA-Fall lassen sich einige sehr praktische Lehren ziehen, die sich unabhängig von der Branche umsetzen lassen.
Erstens: Schnittstellen und Randbereiche gezielt prüfen lassen. Die Kernfunktionen einer Anwendung werden meist ausreichend getestet, weil sie im täglichen Betrieb ständig genutzt werden und Fehler dort schnell auffallen. Schnittstellen zu Drittsystemen, alte Funktionen, die nur noch selten gebraucht werden, oder Zugänge für externe Partner werden dagegen leicht vergessen. Ein regelmäßiges IT-Sicherheit Assessment, das gezielt nach solchen Randbereichen fragt, deckt genau diese blinden Flecken auf, bevor es jemand anderes tut.
Zweitens: Verantwortlichkeiten klar zuordnen. Wenn mehrere Systeme oder Dienstleister zusammenarbeiten, muss klar sein, wer für die Sicherheit welcher Schnittstelle verantwortlich ist. Fehlt diese Klarheit, entsteht genau die Situation, die auch bei komplexen Infrastrukturen wie der Telematikinfrastruktur zum Problem wird: Jeder verlässt sich darauf, dass der andere schon geprüft hat.
Drittens: Alte Systeme nicht einfach weiterlaufen lassen. Software, die vor Jahren gebaut wurde und seitdem nicht mehr aktiv gepflegt wird, sammelt über die Zeit Sicherheitsschulden an. Neue Schwachstellenklassen werden bekannt, alte Bibliotheken werden nicht mehr aktualisiert, Verantwortliche wechseln und das Wissen über das System geht verloren. Wer seine Infrastruktur in professionelle Hände gibt, etwa über Managed Hosting, reduziert dieses Risiko, weil Updates und Sicherheitspatches systematisch statt zufällig eingespielt werden.
Viertens: Regelmäßige, unabhängige Prüfung statt einmaliger Abnahme. Ein System, das bei der Einführung als sicher galt, kann Monate später durch neue Funktionen, neue Integrationen oder neu bekannt gewordene Schwachstellenklassen angreifbar sein. Eine einmalige Sicherheitsprüfung beim Launch reicht deshalb nicht aus. Sinnvoll ist ein wiederkehrender Rhythmus, in dem Anwendungen und ihre Schnittstellen erneut geprüft werden, gerade nach größeren Änderungen.
Fünftens: Regulatorische Vorgaben als Anlass nutzen, nicht als lästige Pflicht. Mit der NIS2 & IT-Sicherheit Richtlinie rückt genau dieses Thema für immer mehr Unternehmen in den Fokus, auch für solche, die sich bisher nicht als kritische Infrastruktur verstanden haben. Wer die Vorgaben ernst nimmt, statt sie nur formal abzuhaken, bekommt nebenbei genau die systematische Überprüfung der eigenen Systeme, die auch im ePA-Fall den Unterschied gemacht hat.
Was das für den Mittelstand bedeutet
Für ein kleines oder mittleres Unternehmen ist die praktische Konsequenz aus dem ePA-Fall nicht, in Panik zu verfallen, sondern nüchtern die eigene Angriffsfläche zu kennen. Wer weiß, welche Systeme personenbezogene oder geschäftskritische Daten verarbeiten, wer Zugriff darauf hat und welche Schnittstellen dabei im Spiel sind, kann gezielt dort investieren, wo es zählt.
Konkret heißt das: Eine Bestandsaufnahme aller Systeme mit sensiblen Daten erstellen, auch der vermeintlich unwichtigen Nebenanwendungen. Für jedes dieser Systeme klären, wer für Wartung und Sicherheitsupdates zuständig ist, intern oder extern. Individuallösungen und alte Sonderanfertigungen besonders kritisch betrachten, weil sie am seltensten geprüft werden. Und schließlich: nicht warten, bis ein Vorfall zum Handeln zwingt, sondern die Prüfung aktiv anstoßen. Ein Ausfall oder ein Datenverlust lässt sich im Nachhinein oft nur noch begrenzen, während eine vorbeugende Prüfung ihn von vornherein verhindert. Sollte trotz aller Vorsicht doch einmal etwas schiefgehen, etwa durch einen Systemausfall nach einem Angriff, zeigt sich auch, wie wichtig ein durchdachtes Backup-Konzept und im Ernstfall eine funktionierende Datenrettung sind.
Wer sich unsicher ist, wo die eigenen blinden Flecken liegen könnten, sollte sich nicht scheuen, extern draufschauen zu lassen. Genau das hat im ePA-Fall am Ende funktioniert: Externe Sicherheitsforscher haben etwas gefunden, das intern offenbar über längere Zeit unentdeckt geblieben war. Diese Rolle des externen, unvoreingenommenen Blicks lässt sich für jedes Unternehmen organisieren, unabhängig von der Unternehmensgröße.
Der Blick über die Gesundheitsbranche hinaus
Die elektronische Patientenakte ist ein Extrembeispiel, weil sie besonders sensible Daten enthält und besonders stark reguliert ist. Genau deshalb wurde sie auch besonders genau geprüft, was letztlich dazu geführt hat, dass die Lücken gefunden und geschlossen wurden, bevor größerer Schaden entstand. Für viele mittelständische Systeme gibt es diese Art der externen Aufmerksamkeit nicht automatisch. Ein regionaler Onlineshop, ein Kundenportal eines Handwerksbetriebs oder eine Buchungsplattform eines Dienstleisters stehen selten im Fokus von Sicherheitsforschern, was einerseits weniger Risiko bedeutet, andererseits aber auch heißt, dass Schwachstellen dort deutlich länger unentdeckt bleiben können, wenn niemand aktiv danach sucht.
Das ist ein wichtiger Unterschied zur öffentlichen Wahrnehmung. Viele Unternehmer gehen davon aus, dass ihr System "zu klein" oder "zu unwichtig" sei, um für Angreifer interessant zu sein. In der Praxis suchen automatisierte Angriffswerkzeuge aber nicht nach großen, prominenten Zielen, sondern nach verwundbaren Systemen, unabhängig von deren Größe. Ein ungepatchtes Content-Management-System, ein veraltetes Plugin oder eine offene Schnittstelle wird gefunden, weil danach systematisch gesucht wird, nicht weil das dahinterstehende Unternehmen besonders bekannt ist.
Wer ohnehin eine neue Website oder ein neues Kundenportal plant, sollte Sicherheit deshalb von Anfang an mitdenken, nicht als nachträgliche Ergänzung. Bei einem sauber geplanten Webdesign Projekt gehört die Absicherung von Formularen, Logins und Schnittstellen zum Standard, nicht zur Kür. Das ist deutlich günstiger und wirksamer, als eine bestehende, gewachsene Lösung im Nachhinein abzusichern.
Auch beim laufenden Betrieb lohnt sich ein Blick auf die eigenen Fernzugriffe. Viele Sicherheitsvorfälle im Mittelstand entstehen nicht über spektakuläre Zero-Day-Lücken, sondern über schlecht abgesicherte Zugänge, etwa für Wartung und Support. Eine sauber konfigurierte Fernwartung mit klaren Zugriffsrechten und Protokollierung schließt genau diese Art von Einfallstor, das in vielen Unternehmen jahrelang offensteht, ohne dass es jemandem auffällt.
Fazit
Der ePA-Fall zeigt exemplarisch, was in der IT-Sicherheit fast immer das eigentliche Problem ist: nicht die grundsätzliche Idee eines Systems, sondern die Details der Umsetzung, die Schnittstellen, die Randfälle, die im Alltag leicht übersehen werden. Dass die Lücken gefunden und behoben wurden, bevor größerer Schaden entstand, ist ein gutes Ergebnis, aber es war das Ergebnis gezielter, externer Sicherheitsforschung. Für den Mittelstand ist die Lehre daraus klar: Wer eigene Datenbestände verwaltet, sollte nicht darauf warten, dass jemand von außen zufällig eine Lücke findet, sondern die eigene Angriffsfläche aktiv und regelmäßig prüfen lassen, gerade an den Stellen, die im Alltag am leichtesten aus dem Blick geraten.
Häufige Fragen
Betrifft das Thema nur Unternehmen aus dem Gesundheitswesen?
Nein. Der konkrete Fall betrifft die elektronische Patientenakte, das zugrunde liegende Problem, nämlich Sicherheitslücken durch unvollständig durchdachte Implementierungen an Schnittstellen und Randbereichen, betrifft jedes Unternehmen mit eigenen digitalen Systemen und Kundendaten.
Wie finde ich heraus, ob mein eigenes System solche blinden Flecken hat?
Am zuverlässigsten geht das über eine externe, unvoreingenommene Prüfung, die gezielt nach Schnittstellen, Sonderfunktionen und selten genutzten Bereichen fragt, nicht nur nach den Kernfunktionen. Eine solche Prüfung sollte nicht einmalig bleiben, sondern nach größeren Änderungen wiederholt werden.
Reicht eine Firewall und ein aktueller Virenscanner nicht aus?
Diese Maßnahmen schützen vor bestimmten Angriffsarten, aber nicht vor Fehlern in der eigenen Anwendungslogik, etwa fehlerhaft abgesicherten Schnittstellen oder Formularen. Genau solche Lücken lassen sich nur durch eine gezielte Prüfung der Anwendung selbst finden.
Was sollte ich zuerst tun, wenn ich mir unsicher bin?
Am Anfang steht eine ehrliche Bestandsaufnahme: Welche Systeme verarbeiten sensible Daten, wer ist für ihre Wartung zuständig und wann wurden sie zuletzt geprüft. Auf dieser Basis lässt sich entscheiden, wo eine Prüfung am dringendsten ist.
Sind alte, selbst gebaute Sonderlösungen wirklich riskanter als Standardsoftware?
In der Tendenz ja, weil Standardsoftware meist regelmäßiger aktualisiert und von mehr Menschen genutzt und damit indirekt geprüft wird. Individuallösungen, die einmalig für einen speziellen Zweck gebaut wurden, geraten dagegen leicht in Vergessenheit und werden selten erneut auf Sicherheit geprüft.
Muss ich als kleines Unternehmen wirklich mit gezielten Angriffen rechnen?
Die meisten Angriffe richten sich nicht gegen bestimmte Unternehmen, sondern werden automatisiert gegen viele Systeme gleichzeitig gefahren, um verwundbare Ziele zu finden. Unternehmensgröße spielt dabei kaum eine Rolle, entscheidend ist, ob eine Schwachstelle vorhanden und auffindbar ist.