„Es ist schwierig, Sicherheit erst später einzubauen.“

Frau Koziolek, Sie gehen der Frage nach, wie Entwurfsentscheidungen mit Sicherheitsbezug geeignet modelliert und dokumentiert werden können. Was kann man sich darunter vorstellen?

Noch bevor die erste Zeile Programmcode geschrieben werden kann, müssen sich die Softwareentwickler mit den Anforderungen an ein System auseinandersetzen. Im ersten Schritt entscheiden sie, wie das System gebaut werden soll. Auf der Grobebene nenne wir das Softwarearchitektur. Ähnlich wie ein Architekt bei einem Gebäude, entwerfen wir einen Plan für das große Ganze. Dann kommen die Feinentwürfe. Hier legen wir zum Beispiel fest, wie Schnittstellen aussehen sollen, welche Klassen das System haben soll und welche Objekte zur Laufzeit auf welche Weise miteinander interagieren. Es ist ein riesiges Netz von Entscheidungen, das in einem solchen Projekt aufgespannt wird. Viele dieser Entscheidungen beeinflussen auch die Sicherheit des Systems. Bin ich später zum Beispiel mit dem Internet verbunden, muss ich mir Sicherheitsmechanismen überlegen: Wie sollen sich die Nutzer authentifizieren? Welche Art der Verschlüsselung benutze ich an welchen Stellen? - Die Erfahrung zeigt, wie schwierig es ist, solche sicherheitsrelevanten Mechanismen erst später einzubauen. Denn mit jedem Entwicklungsschritt wachsen die Abhängigkeiten zwischen einzelnen Teilen des Systems, es wird immer komplexer. Damit wird es auch immer schwerer, mögliche Sicherheitslücken im Nachhinein aufzudecken. Deshalb ist es wichtig, die Sicherheit als Anforderung von Anfang an mitzudenken. Dann lässt sich der Entwurf zum Beispiel schon mit schlanken Schnittstellen gestalten. Diese haben nur die absolut nötigste Funktionalität, damit zwei Module fehlerfrei miteinander kommunizieren können. So soll verhindert werden, dass Sicherheitslücken überhaupt erst entstehen.

Ihr besonderes Augenmerk liegt auf der Dokumentation von Annahmen, die auch die Grundlage von Sicherheitsnachweisen sind. Warum ist das wichtig?

Ohne Annahmen kann ich die Sicherheit eines Systems nicht bewerten. Wenn ich über Sicherheit nachdenke, dann muss ich zumindest einmal annehmen, dass ich irgendjemandem vertrauen kann – zum Beispiel dem Nutzer oder dem Administrator, der Zugriff auf die Datenbank mit den Passwörtern hat. Und wenn ich nicht allen Admins vertraue, dann wenigstens den meisten. Ich muss auch über die Umgebung des Systems Annahmen treffen: Was kann da passieren? Welche Anfragen oder Nachrichten können an das System geschickt werden? - Wir wollen das insbesondere für den Entwurf dokumentieren, da Sicherheitsnachweise oftmals nur für einzelne Teile des Systems geführt werden oder nur einzelne Aspekte betreffen. Es ist aber wichtig zu wissen, ob bestimmte Annahmen für einen Teil des Systems auch zu den anderen Teilen passen. Nur so lassen sich verschiedene Aspekte der Sicherheit zu einem konsistenten Bild eines hoffentlich sicheren Gesamtsystem zusammenführen. Was passiert, wenn das nicht konsequent verfolgt wird, zeigt ein Beispiel aus der Fahrzeugbranche. Hier läuft die Kommunikation zwischen den Steuergeräten über den CAN-Bus. Früher waren da keine Sicherheitsmechanismen nötig. Denn die Geräte waren nur per Kabel vernetzt und die lagen sicher im Auto. Also kam dort niemand von außen heran. Mit der Zeit haben Autos aber immer mehr vernetzte Funktionalität erhalten. Die ursprüngliche Annahme, dass man auf den CAN-Bus nicht zugreifen kann, gilt eben heutzutage nicht mehr. Wie das geht, haben Forscher bei einem amerikanische Geländewagen gezeigt. Über das internetfähige Radio des Wagens haben sie sich aus dem Netz heraus auf den CAN-Bus einhacken und den Wagen zu einem gewissen Grad fernsteuern können. Von welchen Annahmen die Entwickler des Autos genau ausgingen, wissen wir nicht. Aber offensichtlich haben sie hier einen Angriffspunkt falsch eingeschätzt oder übersehen.

Und an dieser Stelle kommt die von Ihnen untersuchte Dokumentation der Annahmen ins Spiel?

Richtig. Haben wir alle Annahmen erst einmal aufgeschrieben, können wir mögliche Sicherheitslücken bereits in der Entwicklungsphase erkennen. Außerdem können wir beim späteren Arbeiten am System auf die ursprünglichen Annahmen zurückgreifen. Eine lange Liste für das Gesamtsystem kann ich jedoch später schwer durcharbeiten. Deshalb ist unser Ansatz, die Annahmen mit den einzelnen Entwurfsentscheidungen zu verknüpfen – also zum Beispiel für eine bestimmte Schnittstelle oder sogar für eine einzelne Methode des Systems. Die Idee dahinter: Schauen wir uns später diese Methode nochmals an, finden wir in unserer Entwicklungsumgebung eben auch die Annahmen, die wir gemacht haben. So kann ich als Entwickler abgleichen, ob alle früheren Annahmen ihre Gültigkeit behalten. Das hilft mit zum Beispiel bei anstehenden Änderungen am System enorm. Aktuell erforschen wir noch, wie man solche Annahmen modellieren und verknüpfen kann. Unser längerfristiges Ziel ist aber, diese Funktionalität tatsächlich in eine Entwicklungsumgebung einzubauen.

Mit Ihrer Forschung wollen Sie modellbasiertes Software-Engineering mit agiler Softwareentwicklung in Einklang bringen. Könnten Sie diese beiden Ansätzen genauer erklären?

Modellbasierte Entwicklung geht davon aus, dass wir Menschen Abstraktionen benötigen, um mit komplexen Systemen umzugehen. Das bedeutet, anstelle fünf Millionen Zeilen Sourcecode zu betrachten, müssen wir uns immer Modelle bilden, um überhaupt über so ein Softwaresystem reden zu können. Diese Abstrahierung ist Kern der modellbasierten Entwicklung. Die agile Softwareentwicklung ist eher – aber nicht ausschließlich – codezentriert. Hier stehen schnelle Feedbackzyklen im Vordergrund. Anstatt erst einen Plan zu erarbeiten und diesen dann Teilschritt für Teilschritt umzusetzen, wird hier so schnell wie möglich ein Minimum Viable Product geschaffen. Das präsentiert man dann dem Kunden, um dessen Feedback einzuarbeiten. Ansätze wie das Extreme Programming haben die agile Softwareentwicklung auf die Spitze getrieben. Hier lautete das Credo: Ich benötige nur den Code als Artefakt. Alles andere drumherum; Anforderungen aufschreiben; einen Entwurf machen; ein schönes Dokument mit Diagrammen erstellen; das alles sei unnötig. Es würde uns nur davon ablenken, funktionierenden Programmcode zu schreiben. Zu einem gewissen Grad stimmt das auch, denn wenn man diese Dinge zum Selbstzweck macht, sind sie oft nicht nützlich. Modellierung muss immer dem Ziel dienen, funktionierende und qualitativ hochwertige Software zu schreiben.

Sie wollen also die Vorzüge beider Ansätze in einem neuen bündeln. Was bringt das für die Softwareentwicklung der Zukunft?

Genau, wir untersuchen in unserer Forschung die Möglichkeiten, das Beste aus diesen beiden Ansätzen zu vereinen. Modellierung wird heute immer noch als zu großer Ballast gesehen, der hohe Kosten verursacht. Oft wird noch am Whiteboard gearbeitet, das wird abfotografiert und die Bilder verschwinden anschließend in einer Ablage. Eher selten werden computergestützte Modelle erstellt und dann vielleicht auch mit dem Projekt gepflegt. Deshalb schauen wir uns an, wie wir die Kosten für die Erstellung eben solcher Modelle reduzieren können. Das macht es einfacher, Modelle in computerlesbarer Form vorzuhalten und auch mitzupflegen. Einer unserer Ansätze ist es, Softwarearchitekturmodelle direkt aus dem Quellcode abzuleiten. Mit einem solchen Startpunkt wird es dann überhaupt erst möglich, die Modell zu aktualisieren, wenn sich die Implementierung ändert. Pflege und Wartung der Modelle können wir so zu einem großen Grad automatisieren. Unsere Idee ist es, Werkzeuge zur Verfügung stellen zu können, die mit wenig oder sogar keinem Zusatzaufwand so eine Sicht auf das System ermöglichen. Das reduziert einerseits die Kosten und bietet andererseits den Vorteil, auf die Modelle zugreifen zu können. Auf diese Weise können wir die IT-Sicherheit steigern.

Wie lassen sich IT-Systeme sicherer machen?