Durch Modellbasierte Risikoanalyse zum Secure Development Life Cycle
Im Zeitalter der Digitalisierung und Vernetzung ist es unerlässlich, Software im Rahmen des Entwicklungsprozesses auf Gefährdungspotenzial zu analysieren. In diesem Artikel erfahren Sie, wie Sie mit einer modellbasierten Analyse die Risiken wie z. B. nach Freigabe Fehlerbehebungen ausbringen zu müssen, Reputation zu verlieren, vertrauliche Daten zu offenbaren und Systemübernahmen hinnehmen zu müssen, mindern können.
Doch wie optimiert man nun einen System Development Life Cycle zu einem Secure Development Life Cycle? Um die Sicherheit einer Applikation zu gewährleisten, wird die Frage, wie eine Threat and Risk Analysis (TRA) durchgeführt werden soll, immer wichtiger. Denn die Zeit zwischen dem Bekanntwerden einer Verwundbarkeit und einer möglichen Ausnutzung wird immer kürzer und verhindert eine erfolgreiche Patchinstallation auf vielen Maschinen.
Eine weitere Alternative ist das Einbinden von Sicherheitsüberlegungen in alle Phasen des SDLC – vom Design über Entwicklung, Test und Freigabe bis zur Wartung. Hierbei sollten Modelle zur Risikobewertung möglichst bald im SDLC generiert und entwicklungsbegleitend verfeinert werden.
Diese werden in Zusammenarbeit von Systemarchitekten, Entwicklern und Sicherheitsexperten erstellt und berücksichtigen die folgenden Aspekte:
- Hacker verstehen ihre Arbeit
- der Entwickler hält sich an vorgegebene Regeln, der Hacker nicht
- der Entwickler hat das ganze System im Blick, der Hacker ein Detail
- der Entwickler kennt geschlossene Exploits, der Hacker sucht / kennt Neue
Modelle zur Risikobewertung beantworten mindestens diese Fragen:
- Was kann schiefgehen?
- Ist dies wahrscheinlich?
- Wie drastisch sind die Folgen?
- Kann das Risiko behoben werden?
Die Risiko-/ Bedrohungsanalysen können aus Listen und Diagrammen bestehen, aber auch aus Modellen, wie sie aus dem Modellzentrierten Testen bekannt sind. Für beide Vorgehensweisen gibt es Vorgaben und Werkzeuge.
Der Modellzentrierte Ansatz bietet zum einen den Vorteil, Zusammenhänge zu visualisieren sowie zum anderen Testfälle automisch abzuleiten.
Ein Beispiel:
Erklärung zum Schaubild:
Die beiden “Geldsäcke” stehen für das schützenswerte Objekt des Systems (EU Verordnung 2016/679), in diesem Fall Patientendaten.
Zwei Wege, um Patientendaten von der bildgebenden Modalität in ein Archiv zu senden, werden bewertet:
Rechts der klassische Versand der Daten über DICOM Port 104, links der verschlüsselte Versand über DICOM Port 2762.
Über den Versand mit DICOM Port 104 hackt der “Angreifer” die Netzwerkübertragung und kann wegen des unverschlüsselten Versands (Verwundbarkeit) den Datenstrom mitlesen und die Patientendaten entwenden.
Ist der Versand über Port 2762 verschlüsselt, kann der Datenstrom immer noch mitgelesen werden, aber um ihn zu entschlüsseln ist eine schlechte Konfiguration und oder sehr gutes Verständnis der Kommunikation notwendig; der Diebstahl der Patientendaten ist daher sehr unwahrscheinlich.
