Generationen von Security-by-Design-Methoden

Einige unserer Probleme sind schon 30 Jahre alt

Ausgelatscht? Wieso, funktioniert doch noch! — Photo by Oziel Gómez on Unsplash

Security by Design ist die Frage danach, wie wir Security-Entscheidungen früh genug in bestehende Engineeringprozesse integrieren können, um wichtige Design-Entscheidungen noch zu beeinflussen.
Für den Engineering-Prozess für Automatisierungssysteme gibt es noch keine praxistaugliche Antwort auf diese Frage. Im Rahmen des IDEAS-Projektes versuchen wir, eine zu geben — und graben dabei auch in Methoden aus angrenzenden Disziplinen. Security by Design ist ja kein reines OT-Security-Problem — vielleicht können wir von der IT oder dem Software Engineering lernen?

Wenn man sich die Arbeit macht, den Staub von etwas in die Jahre gekommenen Texten zu wischen, kann man dabei auf verblüffende Einsichten stoßen — zum Beispiel in diesen zwei etwas in die Jahre gekommenen Texten: Richard Baskerville (1993): Information systems security design methods: implications for information systems development und Richard Baskerville und Mikko Siponen (2001): A new paradigm for adding security into IS development methods.

Generationen von Security-by-Design-Methoden

Der ältere Text wird — man muss sich das auf der Zunge zergehen lassen — nächstes Jahr 30 Jahre alt. Er unterteilt die damals im Software Engineering üblichen Methoden zur Ableitung von Security-Anforderungen in drei “Generationen”: Checklisten-Methoden, mechanistische Methoden und logisch-transformative Methoden. Zunächst zu den ersten beiden:

• Checklisten-Methoden verdienen eigentlich kaum die Bezeichnung “Methode”: Eine Liste möglicher Lösungen wird gegeben, aus denen man sich die für seine Systeme zutreffenden auswählt. Die individuellen Eigenschaften der eigenen Systeme spielen fast keine Rolle.
• Die mechanistischen Methoden versuchen, individuellere Lösungen zu schaffen, indem sie das zu schützende System in seine Komponenten — Assets — herunterbrechen und Bedrohungen analysieren, die in eine Liste individueller Security-Anforderungen münden. Die Systeme werden dabei meist rein physisch, immer aber rein technisch betrachtet — daher auch der Begriff “mechanistisch”.

Kommt Ihnen bekannt vor? Tja, so gehen wir Security auch heute, 30 Jahre später, noch an. Weil sich die Methoden so sehr bewährt haben — oder aus Gewohnheit?
Gewohnheiten sollte man ab und an mal hinterfragen, und das Paper eignet sich wunderbar dazu — denn es erklärt die Gegebenheiten, die zu diesen Gewohnheiten geführt haben.

Der Grund für die Checklisten-Methoden ist gemäß Baskerville eindeutig: In der Anfangszeit der Security war der technische Lösungsraum so begrenzt, dass man einfach alle möglichen Lösungen auflisten (und oft auch umsetzen) konnte.

Interessant ist auch die Rolle der Risikoanalyse in den damaligen Methoden, denn sie ergibt sich direkt daraus: Irgendwann wurde “alles umsetzen” zu aufwendig. Die Risikoanalyse war also eher eine Cost-Benefit-Analyse: Wenn ich diesen Haufen Maßnahmen habe — welche davon setze ich um?
Das ist ein feiner, aber methodisch gewichtiger Unterschied für die Frage, die wir heute oft mit Risikoanalysen beantworten: Wenn ich diesen Haufen Bedrohungen habe, für welche davon überlege ich mir überhaupt Maßnahmen?

Probleme der Methoden — vor 30 Jahren wie heute

Baskerville ist schon 1993 mit den existierenden Methoden nicht glücklich. Er formuliert Probleme dazu — viele davon übrigens sowohl im Text von 1993 als auch in dem von 2001, und weil die Methoden unseren heutigen so sehr ähneln, tun es auch ihre Probleme:

• Beschränkung des Lösungsraums: Da das Modell des zu schützenden Systems schon sehr konkret ist (physische Komponenten mit Spezifikationen), sind es auch die Security-Lösungen. Sie haben einen sehr beschränkten Lösungsraum zur Verfügung.
• Trennung vom Engineeringprozess (“development duality”): Weil die mechanistischen Security-Methoden ein so genaues Systemmodell voraussetzen, können sie erst loslegen, wenn das System schon so genau spezifiziert ist. Der funktionale Engineeringprozess und der Security-Engineering-Prozess laufen daher getrennt und damit unabgestimmt. Baskerville sieht das Problem neben der Beschränkung des Security-Lösungsraums vor allem in möglicherweise entstehenden Konflikten: “if the security designer fixes “ vulnerabilities” that the functional designer purposely opened as “features.”
• Kein expliziter Bezug zum Problem: Es gibt oft keine nachvollziehbare Verbindung zwischen der Security-Lösung und dem Problem, das sie lösen soll — und damit ebensowenig zu dem Nutzen, den die Lösung der Organisation (nicht nur dem technischen System!) bringt.
  Zitat: “the needs of organizations are replaced by ideal protection techniques based on the intuition of security gurus, and organizations are required to follow these as “a gift from the heaven”
• Komplexität: Checklisten berücksichtigen das individuelle System zu wenig, aber jede seiner Komponenten einzeln zu betrachten und die Security-Lösung individuell zuzuschneiden ist sehr aufwendig und erfordert eine Menge an Wissen, die nur schwierig vone einer Person bzw. Domäne abgedeckt werden kann: Detailliertes Wissen über die zu schützenden Systeme (gerade in der Automatisierungstechnik ist das allein schon nicht mehr durch eine Person abdeckbar) plus detailliertes Wissen über Security-Bedrohungen und -Anforderungen.

Lösungsansätze: Lösungsneutrale Modelle, Integration in den Entwicklungsprozess

Mit zehn Jahren Abstand präsentieren die Autoren unterschiedliche Lösungsansätze. Der eine findet sich in der dritten Methoden-Generation, die ich oben unterschlagen habe: Die logisch-transformativen Methoden sind Baskervilles Vorschlag von 1993, um die bestehenden Probleme der vorangehenden Generationen zu lösen. Sie basieren vor allem darauf, das zu schützende System mit Hilfe eines abstrakteren Modells gründlich zu verstehen, und nicht direkt auf konkrete Lösungen zu verfallen.

Schon im Ausblick des ersten Papers analysiert Baskerville außerdem, dass eine Integration der Security in die bestehenden Entwicklungsprozesse notwendig sei.

Im zweiten Paper, knapp zehn Jahre später, haben Siponen und Baskerville als Zielbild die Definition von “integrativen” Methoden erweitert: Sie sollen Security in bestehende Entwicklungsprozesse integrieren, aber auch in die Ziele eines Unternehmens und in ihr soziales Gefüge. Gewissermaßen ist das die Adressierung von allen oben genannten Problemen in einer Lösung.

Allerdings scheinen die beiden auch etwas desillusioniert: eine Integration in die sich stets verändernden Entwicklungsprozesse sei zum Scheitern verurteilt, schreiben sie — auch, weil diese in der Praxis nie so gelebt würden wie auf dem Papier. Stattdessen schlagen sie ein Konzept für eine “Meta-Notation” vor, mit der man Security quasi als “Plug-In” in alle bestehenden Prozesse integrieren kann.

Wir haben nun den Luxus, 30 bzw. 20 Jahre später auf die Lösungsansätze zurückzublicken. Was auffällt: Keiner der Ansätze hat sich durchgesetzt — zumindest nicht in der OT. Die Probleme wälzen wir noch immer. Und: Wir versuchen es auch immer noch mit ähnlichen Lösungsansätzen.

Weiterdenken?

Was nehmen wir aus all dem mit, wenn keine Lösungen? Wohl vor allem Denkanstöße. Hier sind drei Fragen, mit denen Sie mit Blick auf Ihren Security-Alltag weiterdenken können:

• Die “Best-Practice”-Kultur, stets direkt in konkreten technischen Security-Lösungen zu denken, haben wir auch heute noch. Sie ist so sehr in unserer Denkweise verankert, dass wir es kaum mehr bemerken. Es ist ganz selbstverständlich, dass “Security-Anforderungen” eigentlich direkt Lösungs-, wenn nicht sogar Produkthinweise sind: Virenschutz installieren. Ein VPN implementieren. Eine Firewall und ein Intrusion-Detection-System einbauen. Wie müssten lösungsneutrale Formulierungen dazu aussehen?
• Security-Engineering enthält nicht automatisch eine Risikoanalyse, und falls doch, hat der Zweck dieser Risikoanalysen natürlich einen Einfluss auf die Auswahl einer Risikoanalysemethode. Eine Risikoanlayse ist immer ein Filter, aber es ist ein Unterschied, was sie filtern bzw. priorisieren soll: Auswirkungen, die für Sie relevant sind? Systeme, mit deren Security sie sich beschäftigen? Bedrohungen, gegen die Sie sich schützen wollen? Maßnahmen, die sich lohnen? Welche Frage wollen Sie eigentlich mit Ihrer Risikoanalyse beantworten?
• Klar, Security bedenkt man am besten möglichst früh in der Systementwicklung. Aber wie Security-Engineering aussehen muss, um es in den bestehenden Entwicklungsprozess zu integrieren, ist in hohem Maße von diesem Entwicklungsprozess abhängig — und der ist hoch individuell. Was wäre in Ihrem Unternehmen der Prozess, in den Sie Security integrieren müssten, um “Security by Design” zu erreichen?

Dieser Beitrag ist auch im monatlichen “Security-Briefing für Hard Hats” erschienen.