Seit den diversen Berichten über Sicherheitslücken in elektronischen Gesundheitsakten ab dem Herbst 2018 wird in den Medien wieder heiß debattiert: Wo sind Gesundheitsdaten sicher? Was liegt vor, wenn eine Gesundheits-App gehackt wird – menschliches Versagen von Management und Entwicklern? Oder eine unausweichliche Folge der Digitalisierung, die nur mittels Risikomanagement abgemildert, aber nie ganz ausgeschlossen werden kann? Um diese Fragen zu beantworten, muss man klar definieren, worüber überhaupt gesprochen wird. Wie werden Sicherheitslücken in Gesundheits-Apps und anderen IT-Systemen im Gesundheitswesen aufgedeckt? Was ist überhaupt eine
Sicherheitslücke?
Hier zeigt sich schnell: Sicherheitslücke ist nicht gleich Sicherheitslücke, und eine offene Angriffsflanke läutet nicht zwangsläufig das Ende der Vertraulichkeit von Gesundheitsdaten ein. Das rechtfertigt allerdings ebensowenig ein undiszipliniertes Vorgehen nach dem Motto „Digitalisierung first, Bedenken second“. Vielmehr können zahlreiche Probleme vermieden oder in ihren Auswirkungen begrenzt werden, wenn der Informationssicherheit von vornherein bei der Entwicklung ein hoher Stellenwert eingeräumt wird, im Sinne des Prinzips „Security by Design“.
Was ist eine Sicherheitslücke?
Eine Sicherheitslücke ist eine Eigenschaft einer Anwendung, die es Angreifern möglich macht, in die Anwendung selbst oder sogar das System, auf dem sie läuft, einzudringen. Dort können sie – je nach Natur der Sicherheitslücke und den eigenen Fähigkeiten – Daten einsehen, löschen, bearbeiten oder für den eigenen Gebrauch kopieren, oder auch die Anwendung oder das System sabotieren.
Für IT-Entwickler steht bei der Arbeit an einem Projekt normalerweise nicht die Sicherheit im Vordergrund. Priorität haben Funktionalität und Benutzerfreundlichkeit der Anwendung: Sie soll ihre Aufgabe erfüllen, und zwar so, wie der Benutzer es von ihr erwartet. Diese herkömmliche Herangehensweise, bei der der imaginäre Benutzer jemand mit guten Absichten ist, der allenfalls aus Versehen einmal eine falsche oder sinnlose Eingabe tätigt, wird in vielen Unternehmen nach und nach vom Prinzip „Security by Design“ abgelöst.
Auch eine von vornherein als sicher konzipierte Anwendung wird jedoch in fast allen Fällen Sicherheitslücken haben. Diese aufzudecken ist das Ziel von Tests, bei denen verschiedene Angriffe auf ein System simuliert werden.
Zunehmende Nachfrage nach Pentesting
Fachleute, die auf diese Art der Prüfung von Anwendungen spezialisiert sind, nennen sich selbst Pentester (von „pentesting“, kurz für „penetration testing“), White-Hat-Hacker (im Gegensatz zu illegal operierenden Black-Hat-Hackern), oder Ethical Hacker. Andere Bezeichnungen für diese Disziplin sind Red Team (im Gegensatz zu Blue Team, das sich aus der Perspektive der Verteidigung Gedanken um die Sicherheit des Systems macht) oder Offensive Security.
Was passiert beim Pentest?
Art und Umfang eines Pentests werden zwischen dem Dienstleister und dem Kunden explizit vereinbart, und der Umfang wird – allein schon aus Haftungsgründen (§ 202a ff StGB) – ohne Absprache nicht erweitert. Selbst Maßnahmen, die vom Vertrag abgedeckt sind, sind deshalb noch nicht rechtlich unbedenklich: So dürfen keine Rechte Dritter verletzt werden, etwa indem das Pentesting-Team sich als Angehörige einer unbeteiligten Drittfirma ausgibt.
Sascha Schimmler, Senior Security Consultant bei G DATA Advanced Analytics, erklärt den üblichen Ablauf eines Pentests: „Am Anfang steht eine sogenannte Reconnaissance, auch als Footprinting bezeichnet – aktive oder passive Informationsgewinnung über das Prüfobjekt. Für die passive Reconnaissance ist Google ein guter Ausgangspunkt: Hier können Hintergrundinformationen über das Produkt oder die Firma gefunden werden, aber auch durch eine dateitypenspezifische Suche Dateien gefunden werden, die von Entwicklern versehentlich öffentlich hochgeladen wurden, etwa in ein GitHub-Repository. Für das Social Engineering sind soziale Netzwerke nützlich. So kann etwa aus einer Stellenausschreibung auf XING darauf geschlossen werden, welche Technologien das Unternehmen einsetzt oder zukünftig einsetzen möchte.“
Informationen sammeln jenseits von Google
Die passive Informationsgewinnung wird so bezeichnet, da sie – anders als aktive Maßnahmen – völlig unbemerkt vom Kunden durchgeführt werden kann. Wie viele Informationen tatsächlich öffentlich zugänglich sind, wird gemeinhin unterschätzt. Dies gilt umso mehr, wenn man Mainstream-Suchmaschinen wie Google verlässt und die Informationsgewinnung mit spezialisierten Suchmaschinen wie Shodan (https://www.shodan.io) weiterführt. Shodan durchsucht nicht nur Webseiten wie Google, sondern auch von anderen Protokollen als HTTP(S) bereitgestellte Informationen, etwa Login-Aufforderungen von FTP-Ports oder IoT-Geräten.
Wenn Informationen über Ports (im Netzwerkverkehr auf TCP-Ebene verwendete Adressen) und dort bereitgestellte Dienste nicht aus einer solchen Suchmaschine bezogen, sondern vom Pentester selbst gesammelt werden, etwa mithilfe eines sogenannten Portscanners, ist die Grenze zur aktiven Reconnaissance überschritten.
Bekannte Sicherheitslücken ausnutzen
Aus welcher Quelle auch immer die Informationen stammen: Der nächste Schritt ist nun, sie sinnvoll zu verknüpfen und relevante Sicherheitslücken zu finden, etwa in Services, die auf bestimmten Ports des Angriffsziels angeboten werden. Bekannte Sicherheitslücken werden etwa von der US-amerikanischen Non-Profit-Organisation MITRE (https://www.mitre.org/) anhand eindeutiger Nummern (CVE) gesammelt und entsprechend ihres Schweregrades von 0 bis 10 klassifiziert.
Wenn der eigentliche Angriff innerhalb des Pentests beginnt, müssen Pentester und Kunde die Limitationen der künstlich herbeigeführten Situation in Kauf nehmen. Sascha Schimmler dazu: „Der Pentest einer klassischen Webseite hat einen Umfang von fünf bis zehn Manntagen. Bei umfangreicheren Systemen werden auch bis zu 60 Manntage eingeplant. Ein echter Angreifer unterliegt aber unter Umständen nicht solchen Restriktionen.“
„Accept the Breach“ Approach
So komme es vor, dass die Pentester innerhalb ihres Auftrags keine Sicherheitslücke identifizieren könnten, die ein Eindringen ins System ermöglichte. In diesem Fall könne man mit einem „Accept the breach“-Ansatz weiterarbeiten: Angenommen, der Angreifer hätte ausreichend Ressourcen gehabt, um erfolgreich ins System einzudringen – wie könnte er nun weitermachen? Hier werde dann beispielsweise nach Sicherheitslücken gesucht, die es dem Angreifer ermöglichten, vom ersten System auf weitere Systeme zu kommen (Lateral Movement), oder einen persistenten Zugang zu erhalten, auch nachdem die erste Sicherheitslücke gepatcht wurde.
Häufig werden beim Pentest künstliche Daten hinterlegt, anhand derer die White-Hat-Hacker im Nachgang beweisen können, dass sie tatsächlich ins System eingedrungen sind. Dem gleichen Zweck dienen Screenshots. Anders als im Fall eines realen Angriffs spielt die Verschleierung der Spuren im Nachhinein beim Pentesting kaum eine Rolle.
Report für Technik und Management
„Der letzte Schritt im Pentesting ist für den Kunden der wichtigste“, so Schimmler, „nämlich eine vernünftige technische Niederschrift: Was habe ich getan, wie habe ich es getan, was können Sie dagegen tun. Wichtig sind ein Management Summary als klare Zusammenfassung sowie eine technisch detaillierte Version für die technischen Abteilungen. Bei der Präsentation sollten auch wichtige andere Stakeholder anwesend sein – im Krankenhaus zum Beispiel Ärztinnen und Ärzte.“
Die Handlungsempfehlungen müssten gegebenenfalls nicht nur an die technischen Gegebenheiten, sondern auch an regulatorische Hürden angepasst werden: „Bei medizinischen Großgeräten ist die Umgebung manchmal so fragil, dass Sicherheitslücken nicht gepatcht werden können. Technisch ist das Schließen der Sicherheitslücke vielleicht möglich, aber vertraglich oder regulatorisch nicht – das System darf nicht angefasst werden. In diesem Fall ist sogenanntes Containment das Ziel: Maßnahmen, um zu verhindern, dass vorhandene Sicherheitslücken ausgenutzt werden und durch das betroffene System die Übernahme anderer Systeme möglich wird.“
Pentesting als Baustein der Sicherheitsstrategie
Sascha Schimmler verzeichnet in den letzten Monaten eine steigende Nachfrage nach Pentesting und verwandten Dienstleistungen, vor allem aus der Gesundheitsbranche. Seinem Empfinden nach machen Softwareentwickler aus der Gesundheits-IT sich nicht allein wegen der gesetzlichen Vorgaben Gedanken um die Sicherheit ihrer Produkte, sondern seien überdurchschnittlich häufig intrinsisch motiviert – durch die Sorge um die Sicherheit der persönlichen Daten, die ihren Apps anvertraut werden.
Michael Pöhlsen, Geschäftsführer des ebenfalls im Gesundheitswesen tätigen Informationssicherheitsdienstleisters Vasgard, sieht Pentesting als sogenannte erkennende Schutzmaßnahme als wichtigen Bestandteil jeder IT-Sicherheitsstrategie an. Allerdings nicht unbedingt von Anfang an: „Wenn die ISMS-Prozesse eines Kunden noch in den Kinderschuhen stecken, dann sollte man das Pentesting eher auf später verschieben. Wenn im Pentest Schwachstellen identifiziert werden, ist ein funktionierender Prozess notwendig. Was passiert beispielsweise konkret, wenn ein ungepatchter Server gefunden wird? Wenn kein Risk-Treatment-Prozess um das Pentesting herum vorhanden ist, hat die Identifikation einer Schwachstelle keine Konsequenzen und Schutzmaßnahmen laufen ins Leere.“
Dabei ist auch bei einem reifen ISMS ein Pentest keine Maßnahme, die einmalig durchgeführt wird und den Kunden dann für die nächsten Monate und Jahre ruhig schlafen lässt. Matteo Cagnazzo von der AWARE7 GmbH dazu: „Ein einzelner Penetrationstest ist meist nicht zielführend. Das Pentesting muss als kontinuierlicher Prozess betrachtet werden. Nur so kann langfristig sichergestellt werden, dass Sicherheitslücken immer wieder gefunden und kontinuierlich geschlossen werden.“
Die Zukunft des Pentests
Das Pentesting muss sich stets weiterentwickeln, um mit neuen Sicherheitslücken und Angriffsvektoren, aber auch mit neuen IT-Architekturen Schritt zu halten. Die Ruhr-Universität Bochum und die FH Münster führen in Zusammenarbeit mit G DATA Advanced Analytics und anderen Firmen hierzu in den nächsten drei Jahren ein Projekt durch, in dem Sicherheitslücken in den Protokollen DICOM und HL7 untersucht werden und ein nicht-invasiver Schwachstellenscanner entwickelt werden soll.
Wie sieht die Zukunft des Pentesting aus? Dazu Carsten Marmulla (carmasec Ltd. & Co. KG): „Je agiler und dynamischer meine Infrastruktur ist, desto kürzer ist der Zyklus, in dem ich technische Sicherheitsüberprüfungen durchführen muss. Im Kontext von DevOps, also beispielsweise bei agiler Softwareentwicklung in Cloud-Infrastrukturen, können im Sprint-Rhythmus von typischerweise zwei bis vier Wochen neue Software-Artefakte entstehen und in die Produktivsysteme integriert werden. In diesem Fall sind die Ergebnisse der vorherigen Sicherheitsüberprüfungen nicht mehr gültig, und ich muss neu testen. Bedingt durch den Testaufwand und die Verfügbarkeit der Sicherheitsexperten ist dies mit manuellen Mechanismen nur bedingt leistbar.“
In Zukunft müsse das Pentesting also noch weiter automatisiert werden: „Grundsätzlich lässt sich natürlich auch die Informationsbeschaffung im Vorfeld automatisieren. Der Scan selbst läuft eigentlich schon immer weitgehend automatisiert ab. Die anschließende Analyse der Testergebnisse, Dokumentation, Definition der Maßnahmenplanung ist aktuell noch der große manuelle Aufwandstreiber bei Penetrationstests – zumal das auch der eigentliche Tester eher ungern macht.“
Hier lässt sich schließlich eine Parallele zwischen Pentesting und Patientenversorgung ziehen: In beiden Bereichen steht ein Fachkräftemangel einem zunehmenden Bedarf an gut ausgebildetem und spezialisiertem Personal gegenüber. Automatisierung und der Einsatz intelligenter Verfahren, um Fachkräftestunden einzusparen, werden in beiden Feldern zumindest Teil der Lösung sein.