IT-Sicherheit im Gesundheitswesen „Impfen statt Pflaster“

Wir alle sind mit den Schlagzeilen vertraut: Massenhaft aufgedeckte Schwachstellen, geleakte Patientendaten, Krankenhäuser und andere Einrichtungen, die dank Malware komplett lahmgelegt werden. Leider sind die Erwartungen an die betreffenden Sicherheitsteams oft zu hoch. Das führt zu Terminüberschreitungen und Reibungspunkten mit den Produktteams sowie den betrieblichen Prozessen.

Nehmen wir als Beispiel ein imaginäres Unternehmen, Infuzimed, einen Hersteller von Infusionspumpen. Infuzimed produziert und vertreibt diese Pumpen seit vielen Jahren. Um den Bedienkomfort zu verbessern, hat das Unternehmen die Pumpen in den letzten 10 Jahren ans Netzwerk angeschlossen. Aufgrund der jüngsten Cyber-Sicherheitsvorfälle ist man nun (zu Recht) besorgt.

Das einfache Rezept gegen Hacker

Weil das Unternehmen es nicht besser weiß, stellt es einen Chief Security Officer (CSO) ein und bildet ein Team, das für die Sicherheit der Produkte verantwortlich zeichnet. Die Verantwortlichen entscheiden sich, in Sicherheitstests zu investieren, wie zum Beispiel die Quellcode-Analyse, die Software Composition Analysis und Fuzzing. Wenn ein Produkt dann kurz vor der Fertigstellung steht, wird es hinsichtlich seiner Sicherheit getestet, das Team berichtet die Ergebnisse, schlägt Verbesserungen und Abhilfemaßnahmen vor. Meistens dauert es nicht lange, bis solche Konstellationen zu einem der typischen Engpässe in der Produktentwicklung führen. Ein Grund: Sämtliche Produktteams stützen sich bei diesen Tests auf ein und dieselbe kleine Gruppe von Sicherheitsverantwortlichen.

Aus Sicht der Produktion sind Sicherheitstests ein Hemmnis, weil sie die Produktentwicklung an einer kritischen Stelle ausbremsen: Zunächst muss man warten, bis die Tests zeitlich überhaupt durchgeführt werden können, und dann müssen sich die Entwickler mit den Ergebnissen auseinandersetzen. Die kommen nicht selten überraschend und zu einem besonders ungünstigen Zeitpunkt im Entwicklungslebenszyklus des Produkts. Sind Änderungen unumgänglich, haben die Entwickler sich zwischenzeitlich schon um andere Produkte gekümmert, und man muss die Tests unter Umständen sogar erneut durchführen.

Ganz oft fehlt Produktentwicklern der nötige Kontext zu den Informationen, die sie von einem Sicherheitsteam bekommen. Da ist es kein Wunder, dass seitens der Produktion das Verständnis fehlt, warum welche Sicherheitstests unabdingbar sind. Haben die Tests sehr viele Erkenntnisse zu Tage gefördert, wird meistens Druck auf das Sicherheitsteam ausgeübt, die Probleme nach Priorität zu ordnen. Behoben werden dann nur diejenigen, die als besonders schwerwiegend eingestuft worden sind.

Wie Taylor Swift in ihrem Song ‚Bad Blood‘ singt: „helfen Pflaster nicht bei Einschusslöchern“. So ähnlich verhält es sich mit nachträglichen Sicherheitstests am Ende des Produktentwicklungszyklus. Sie sind kontraproduktiv und für alle Beteiligten frustrierend. Zurück zu unserem imaginären Unternehmen Infuzimed. Angesichts des endlos wachsenden Bergs anfallender Aufgaben und der feindseligen Stimmung seitens des Entwicklungsteams, verschlechtert sich die Moral des Sicherheitsteams zusehends.

Es wird schwieriger, Personal zu halten. Der CSO kämpft mit nervösem Zucken, schläft schlecht, nimmt unkontrolliert zu und hat aufgrund von zusätzlichem Stress bei der Arbeit Beziehungsprobleme zu Hause. Trotz aller Bemühungen entdecken die Sicherheitsexperten schwerwiegende Schwachstellen in den Infuzimed-Produkten, und die Folgen dieser Schwachstellen entwickeln sich zu einer PR-Katastrophe. Die Anleger geraten in Panik, der Aktienkurs stürzt ab, und der CSO steht am Ende der Woche auf der Straße.

Schwarzmalen Teil 2

Getreu der Maxime, dass alles immer noch viel schlimmer kommen kann, hätten interne oder externe Angreifer die Schwachstellen auch vor dem Sicherheitsteam finden und ausnutzen können – mit den oben skizzierten möglichen Folgen. Alles andere wäre wie gehabt, einschließlich des abstürzenden Aktienkurses und des arbeitslosen CSO, mit der zusätzlichen Möglichkeit von Straf- und Zivilprozessen.

Ein Sicherheitsteam ist kein Eimer

Eines der wesentlichen Probleme liegt darin, dass Sicherheitsteams gerne wie ein Eimer behandelt werden, in dem der Rest des Unternehmens sein Risiko abkippt. Viele fragen sich vielleicht sogar, warum nicht irgendjemand etwas dagegen unternimmt, vergessen dabei aber gerne, dass jeder Einzelne für Sicherheit verantwortlich ist. Das passiert nicht selten, wenn bestimmte Dinge in der Verantwortung aller liegen, ergreift schließlich niemand mehr die Initiative.

Unternehmen im Gesundheitswesen haben das Konzept der Patientensicherheit durchaus verstanden. Wenn Infuzimed ein Produkt entwirft und baut, wird ständig an Sicherheit gedacht: wenn das Produkt entwickelt wird, wenn es gebaut wird und wenn es getestet wird. Dabei ist keine bestimmte Gruppe allein für die Sicherheit verantwortlich. Vielmehr ist die Sicherheitskultur in den Produktentwicklungsprozess eingebettet. Cybersicherheit sollte genauso funktionieren. Sicherheit sollte Teil jeder Phase der Produktentwicklung sein und ebenso Teil der Denkweise aller Mitarbeiter werden.

Es ist nichts falsch daran, einen CSO einzustellen und ein Sicherheitsteam aufzubauen. Das sind ausgezeichnete erste Schritte. Doch anstatt das Cybersicherheitsrisiko sozusagen intern abzulegen, sollte das Sicherheitsteam sein Wissen und seine Expertise mit dem gesamten Unternehmen teilen. So wie ein Impfstoff den Körper lehrt, die richtige Immunantwort zu geben und sich so selbst gegen Krankheiten zu wappnen.

Das Sicherheitsteam kümmert sich um sichere Entwicklungspraktiken und die passende Kombination aus Sicherheitstesttools. Statt zum Flaschenhals zu werden, unterstützt das Sicherheitsteam die Produktentwickler bei der Automatisierung und Integration von Sicherheitstests in etablierte Produktentwicklungsprozesse. So lassen sich Sicherheitsschwachstellen und Fehler mit lediglich minimalen Reibungsverlusten beheben.

Deshalb gehört es zu den Aufgaben eines gut eingespielten Sicherheitsteams:

• einen SDLC aufzubauen und das Produktteam bei der Einführung zu unterstützen,

• Sicherheitsrichtlinien für die Produkte zu definieren,

• seine Expertise im Bereich Cybersicherheit mit dem Unternehmen zu teilen und Mitarbeiter zu schulen,

• Experten für Sicherheitstesttools zu sein und DevOps-Teams dabei zu unterstützen, Sicherheitstests zu automatisieren und die Ergebnisse in bestehende Arbeitsabläufe zu integrieren.

Applikationssicherheit – nahtlos integriert

Wenn Applikationssicherheit in den Prozess der Softwarenentwicklung integriert wird, gibt das eher einen Schub nach vorn, als dass es den Prozess verlangsamt. Das automatische Testen der Software ist im besten Falle so implementiert, dass der Vorgang für das Entwicklungsteam nahezu unsichtbar abläuft. Der Schlüssel liegt darin, Sicherheit bei den entscheidenden Ereignissen innerhalb der Softwareentwicklung zu implementieren, nämlich solchen, die den Programmfluss steuern. Etwa bei den Commits, also der bestätigenden Freischaltung von einer oder mehreren Änderungen oder bei den Pull-Requests innerhalb des bestehenden Source Code Management (SCM) Systems.

Solche Ereignisse können unterschiedliche Tools zum Testen der Sicherheit aktivieren. Art und Umfang der Tests lassen sich anhand der gewünschten Risikogrenzwerte konfigurieren, nach der Art der getätigten Änderungen, aber auch nach den bisherigen Ergebnissen innerhalb der Testhistorie und mehr. Aus Sicht der Entwickler passiert das einfach und sie müssen sich dazu weiter keine Gedanken machen.

Ein weiteres wichtiges Puzzleteil ist es, die Resultate der Sicherheitstest in den normalen Entwickler-Workflow zu integrieren. Entwicklungsteams benutzen üblicherweise Tracker wie eine To-Do-Liste, um Probleme nachzuverfolgen. Dabei handelt es sich um eine gemeinsam genutzte Ressource, in der erfasst wird, was mit der Software im Rahmen der Entwicklung passiert und was für die Zukunft geplant ist. Sendet man nun die Ergebnisse der Sicherheitstests an genau diesen Tracker, dann werden sie zu einem normalen Teil der alltäglichen Arbeitsabläufe innerhalb der Entwicklung. Im gleichen Maß lassen sich dadurch Geschäftsrisiken senken, die eine Folge funktionaler Probleme sein können.

Risiken minimieren durch bessere Softwareentwicklung

Firmen, die lieber auf die obigen Erfahrungen des imaginären Unternehmens Infuzimed verzichten möchten, sollten Sicherheit in jede Phase der Softwareentwicklung angemessen einbetten. App-Sec-Teams verfügen über die notwendige Expertise, um Entwickler dabei zu unterstützen, Sicherheit zu einem Bestandteil des Softwaredesigns zu machen, sie korrekt zu implementieren, zu testen und die Produkte dementsprechend zu warten. Wer Softwaretests in das bestehende Source Code Management und die bestehende Problemnachverfolgung integriert, der gibt Entwicklungsteams einen straffen und effizienten Prozess an die Hand, um Sicherheitsrisiken zu erkennen und zu beheben. Und zwar bevor das Produkt freigegeben wird und auf den Markt kommt.

Wenn die Voraussetzungen stimmen, kann ein Sicherheitsteam optimal arbeiten, seine Kenntnisse vermitteln und das Risiko im gesamten Unternehmen senken.

*Der Autor: Jonathan Knudsen, Senior Security Strategist bei Synopsys

(ID:46894611)