Secure Development Lifecycle

Das NovaHealth-Entwicklerteam hat das neue Laborergebnis-Modul fertig entwickelt. Jetzt soll ein Penetrationstester die Anwendung prüfen, bevor sie in Produktion geht. Das Ergebnis ist ernüchternd: Drei kritische Schwachstellen, die tief in der Architektur stecken. Die Behebung erfordert, dass zentrale Teile der Anwendung umgebaut werden. Das bedeutet zwei Wochen zusätzliche Arbeit, der Release-Termin platzt.

Der SDL (Secure Development Lifecycle) ist ein strukturierter Prozess, der Sicherheitsaktivitäten in jede Phase der Softwareentwicklung integriert. Statt Sicherheit als nachträgliche Prüfung zu behandeln, wird sie zum festen Bestandteil des gesamten Lebenszyklus.

Ein bekanntes Modell stammt von Microsoft, das den SDL bereits 2004 eingeführt hat. Es besteht aus sieben Bestandteilen. Genau genommen sind es fünf Kernphasen und zwei unterstützende Sicherheitsaktivitäten. Die Kernphasen sind Anforderung(en), Design, Implementation, Verification und Release. Training steht davor, Response folgt nach der Veröffentlichung:

Diese Phasen müssen nicht streng nacheinander ablaufen. Wichtig ist, dass keine Phase ohne Sicherheitsfrage bleibt.

Ein anderes wichtiges Referenzmodell ist das NIST SSDF (Secure Software Development Framework). NIST beschreibt darin sichere Entwicklungspraktiken, die in unterschiedliche Entwicklungsmodelle integriert werden können.

SDL heißt: Sicherheit wird geplant, umgesetzt, geprüft und nach dem Release weitergeführt. Außerdem gilt: Je später ein Sicherheitsfehler gefunden wird, desto weniger ist er ein kleiner Fix und desto eher wird er ein Umbau. Daher ist es entscheidend Sicherheit bereits früh im Entwicklungsprozess zu integrieren.

Als Beispiel: Bei NovaHealth hätte eine klare Anforderung früh geholfen, wie folgende:

Jeder Abruf eines Laborergebnisses prüft serverseitig, ob die angemeldete Person Zugriff auf genau dieses Ergebnis hat.

Daraus hätte im Design eine zentrale Autorisierungsprüfung entstehen müssen. In der Verifikation würde daraus ein konkreter Testfall entstehen:

Patient A versucht, ein Laborergebnis von Patient B abzurufen.
Erwartung: Zugriff wird verweigert.

Threat Modeling mit STRIDE

Besonders wichtig ist das Threat Modeling in der Design-Phase. Dabei werden systematisch Bedrohungen identifiziert, bevor Code geschrieben wird.

Für das Laborergebnis-Modul würde das Team zuerst grob skizzieren, welche Komponenten beteiligt sind. Danach werden Datenflüsse und Vertrauensgrenzen betrachtet. Eine Vertrauensgrenze ist eine Stelle, an der Daten von einem weniger vertrauenswürdigen Bereich in einen stärker geschützten Bereich wechseln. Ein Beispiel ist der Übergang vom Browser des Patienten zur NovaHealth-API.

Ein verbreitetes Modell für Threat Modeling ist STRIDE. STRIDE ist ein Akronym für sechs Bedrohungskategorien:

• S – Spoofing (Identitätsvortäuschung): Kann sich jemand als ein anderer Benutzer oder Dienst ausgeben? Beispiel: Ein Angreifer gibt sich als Laborsystem aus und sendet gefälschte Ergebnisse.
• T – Tampering (Datenmanipulation): Können Daten verändert werden? Beispiel: Ein Laborwert wird auf dem Weg zur API manipuliert.
• R – Repudiation (Abstreitbarkeit): Kann jemand eine Aktion später abstreiten? Beispiel: Ein Arzt behauptet, er habe ein Ergebnis nie freigegeben. Dieses Konzept kennst du bereits als Nicht-Abstreitbarkeit aus Modul B1.
• I – Information Disclosure (Informationsabfluss): Können vertrauliche Daten offengelegt werden? Beispiel: Patienten können fremde Laborergebnisse abrufen.
• D – Denial of Service (Dienstverweigerung): Kann der Dienst lahmgelegt werden? Beispiel: Die Laborergebnis-API wird mit sehr vielen Anfragen überlastet.
• E – Elevation of Privilege (Rechteausweitung): Kann ein Benutzer höhere Rechte erlangen? Beispiel: Ein Patient erreicht Funktionen, die nur Ärzte nutzen dürfen.

Threat Modeling in Bezug auf SDL heißt, sich vor dem Bauen der Anwendung bereits zu fragen: Was kann schiefgehen? STRIDE kann dafür sorgen, dass diese Frage nicht aus dem Bauch heraus, sondern strukturiert gestellt wird.