header-photo

Sichere Software-Architektur durch Threat Models

Im Rahmen verschiedener Projekte bin ich immer wieder auf die Einstellung "Sicherheit muss natürlich sein! Wir haben schließlich eine vernünftige Benutzerverwaltung und nutzen HTTPS. Wenn im Sicherheitstest was auffällt, dann bauen wir das halt noch ein." gestossen.

Ich kann bei solchen Äußerungen nur den Kopf schütteln. In der Software ist es zumindest beim Thema Sicherheit nunmal doch ein wenig anders, als im Bauwesen, auch wenn in beiden Bereichen von "Architektur" geredet wird.

Ein Haus kann auch zu einem Zeitpunkt nach dem Bau ohne größere Probleme sicherheitstechnisch aufgerüstet werden. Bei Software wird das in den wenigsten Fällen funktionieren. Ist ein Softwaresystem unsicher entworfen, dann erinnern alle Versuche, dieses System abzusichern, an Scratch im zweiten Teil von Ice Age. Jedes verstopfte Leck ruft sofort an anderer Stelle ein neues hervor.

Sicherheit muss bereits beim Entwurf eine Rolle spielen, zum einen bzgl. der verwendeten Systemarchitektur (Welche Netzstruktur, welche Hardware, welche Betriebssysteme, wie verteilt sich die Anwendung) als auch beim Design der eigentlichen Software und vor allem auch bei der Auswahl der verwendeten Frameworks und Bibliotheken. Es ist erschreckend, dass es nach wie vor Online-Banking-Lösungen gibt, die auf PHP aufsetzen, einer Technologie, die nicht gerade für ihre sichere Seite bekannt ist. Oder Seiten auf denen sensible Daten angezeigt, bzw. eingegeben werden, die Flash-Werbung einbetten. Macht man die Verantworltlihen darauf aufmerksam erntet man oftmals Unverständnis ("Das ist die Standardtechnologie für Umsetzungsprojekte bei uns.", oder "Wir vertrauen unseren Werbepartnern"). Die Liste ließe sich beliebig fortsetzen, ich will aber an dieser Stelle keine Flamewars lostreten, sondern nur einen Denkanstoß geben, gewohnte Sichtweisen und Paradigmen einmal aus einiger Entfernung zu betrachten.

Wie gesagt, zu einem sicheren System gehört, dass man sich von Anfang an Gedanken um die Sicherheit macht, und zwar sowohl im Hinblick auf Safety als auch auf Security. Diese englischen Ausdrücke, die sich beide mit "Sicherheit" übersetzen lassen, bedeuten unterschiedliche Dinge: Safety steht für die Stabilität, die Absturzsicherheit einer Software, Security für die Sicherheit in Bezug auf Angriffe von aussen und innen. Eines der Dinge, die hierbei oft übersehen werden, ist, dass Probleme im Bereich der Safety sehr schnell zu Problemen im Bereich der Security werden können. Man denke hier nur an die häufigen Meldungen zu Bufferoverflows. Jeder Bufferoverflow, der ein Programm zum Absturz bringt, lässt sich theoretisch dazu verwenden, Schadcode auszuführen. Das gilt im Prinzip auch für jedes andere unvorhergesehene Verhalten von Software bei Abstürzen.

Es stellt sich natürlich die Frage, wie kann man bei einem großen System die Übersicht über die relevanten Punkte in Bezug auf Sicherheit erkennen? Das ist doch irrsinnig aufwendig und fast nicht lösbar!? Aus dieser weitverbreiteten Sicht kommt dann auch die oben genannte Einstellung.

Um im Vorfeld einen Überblick über die verschiedenen Bedrohungen zu bekommen, denen das zu entwerfende System ausgesetzt sein wird, sollte man ein Threat Model erstellen. Siehe auch https://www.owasp.org/index.php/Application_Threat_Modeling. Hiermit habe ich bereits gute Erfahrungen gesammelt (U.a. Kunden davon überzeugt, dass von bestimmten Wünschen eher abzuraten ist). Der Aufwand kann hierbei in vertretbaren Grenzen bleiben, das Ergebnis ist aber im weiteren Verlauf des Entwurfs und der Entwicklung unbezahlbar (solange man sich dieses Ergebnis immer wieder vor Augen hält ;-)). Mittels diesem Threat Model lassen sich z.B. die Hotspots relativ einfach entdecken, auf die beim Entwurf besonders Rücksicht genommen werden sollte.

Natürlich spielen dann beim Entwurf weitere Kriterien eine Rolle, die jeweils vom Kontext der Anwendung abhängen. Ob man z.B. statt POLP (Principle of least Privilege) das POLA (Principle of least Authorization) nutzt, mag davon abhängen, wie feingranular eine Autorisierung nötig, bzw. wie sicherheitskritisch einzelne Funktionen sind.

Ein hervorragendes Buch zu diesen Themen ist übrigens "Sichere Systeme" von Walter Kriha und Roland Schmitz (Nein, ich bekomme keine Provision, ich finde das Buch nur sehr gut und umfassend!)

Dass nach dem Entwurf eines sicheren Systems dann Richtlinien für sicheres Programmieren für die eigentliche Entwicklung gelten sollten, versteht sich dann quasi von selbst. ;-).