Die vier Pfade zu einer Security-Entscheidung (German Version)

Wie Security-Entscheidungen im Software Engineering, Requirements Engineering und System Engineering funktionieren

Die Security-Entscheidung

Was ist für Sie eine Security-Entscheidung? Um den Einstieg zu erleichtern, beginnen wir nicht zu formalistisch, sondern mit einem Beispiel. Unten ist ein typisches OT-Netzwerk abgebildet, mit Sensoren und Aktoren auf der Feldebene unten in hellblau, Steuerungen in dunkelblau darüber, dann grüne Steuersystemkomponenten und Büro-IT in gelb. In diesem Netzwerk habe ich ein paar Dinge rot markiert, die als Security-Entscheidungen betrachtet werden können.

Wir müssen hier nicht näher auf jede dieser Entscheidungen eingehen, aber es gibt zwei allgemeine Beobachtungen:

1. Security-Entscheidungen sind nicht groß und monolithisch. Es geht nicht um eine einzige Architekturänderung. Es geht nicht darum, ein einziges super-smartes Security-Gateway einzuführen. Stattdessen sind Security-Entscheidungen ein Sammelsurium aus vielen kleinen Konfigurationen, die zusammengenommen due Security Ihrer Systeme ausmachen.
2. Security-Entscheidungen sehen auf den ersten Blick nicht immer nach Security-Entscheidungen aus. Es steht nicht immer “Security” darauf. Sie werden auch oft von anderen Fachbereichen als der Security getroffen.

Das heißt, ganz gleich, ob Sie sich um Sicherheit kümmern oder nicht, ob Sie eine Security-Engineering-Methode anwenden oder nicht, ob Sie es wollen oder nicht: Sie treffen die ganze Zeit Security-Entscheidungen. Die Sache ist die:

Es ist unmöglich, keine Security-Entscheidungen zu treffen. Aber wir müssen sichtbare, bewusste Entscheidungen daraus machen.

Wir versuchen uns jetzt, an einer formelleren Definition von “Security-Entscheidung”. Dazu müssen wir ein wenig Kontext liefern. Nehmen wir an, wir haben eine Architektur, ein System, das geschützt werden soll. Diese Architektur hat Security-Probleme, denen mit Security-Anforderungen begegnet werden soll, die wiederum als Security-Lösugnen implementiert werden sollen.

In diesem Szenario können wir rot umranden, was eine Security-Entscheidungen im Allgemeinen ist: Die Festlegung einer Security-Anforderung, um ein Security-Problem zu lösen.

Natürlich sind ein “Security-Problem” und “Security-Anforderung” immer noch vage Begriffe. Dazu kommen wir gleich noch.

Pfade zur Security-Entscheidung

Nächste Frage: Wie kommt man zu einer Security-Entscheidung? Im Rahmen unseres Forschungsprojekts IDEAS haben wir Security-Engineering-Ansätze von Disziplinen durchforstet, die sich schon lange mit Security by Design beschäftigen — im Vergleich zu Automatisierungsingenieuren. Wir haben uns Methoden aus der IT angeschaut: Software Engineering, Requirements Engineering und Systems Engineering.

Es gibt viele verschiedene Methoden, die jeweils aus der in den jeweiligen Nischen vorherrschenden Denkweise erwachsen sind. Aber wenn man einen Schritt zurücktritt und vergleicht, nehmen alle diese Methoden einen von vier möglichen Pfaden für Security-Entscheidungen: risikogetrieben, zielgetrieben, compliance-getrieben oder bibliotheksgestützt.

Der risikogetriebene Weg kommt Ihnen wahrscheinlich am ehesten bekannt vor, wenn Sie einen IT- oder OT-Security-Hintergrund haben. Dabei wird die zu schützende Architektur aus der Sicht eines Angreifers betrachtet, der potenzielle Angriffsszenarien als Security-Probleme identifiziert, z. B. den Verlust vertraulicher Informationen. Die Security-Entscheidung auf diesem Weg ist eine Entscheidung zur Risikominderung: Sie definieren eine Security-Anforderung, die das durch ein Angriffsszenario verursachte Risiko mindern soll.

Für Verfechter des risikobasierten Ansatzes mag das überraschend sein, aber es gibt neben dem risikogetriebenen auch andere legitime Wege zu einer Security-Entscheidung. Vor allem im Requirements Engineering ist es üblich, die Security lediglich als eine weitere Dimension nichtfunktionaler Anforderungen zu betrachten und sie so zu erarbeiten, wie alle anderen Anforderungen auch — und das ist meist zielgetrieben. Im Gegensatz zur Angreiferperspektive, die im risikogetriebenen Weg eingenommen wurde, nimmt man also die Perspektive des Verteidigers ein, oder — ohne die Kriegsrhetorik — einfach die Perspektive eines Ingenieurs. Als Ingenieur entscheiden Sie, welche Security-Ziele Ihre Architektur erfüllen muss, z. B. die Vertraulichkeit von Kundendaten zu schützen. Die Security-Entscheidung ist dann eigentlich “nur” eine Konkretisierung: Sie definieren Security-Anforderungen, die Ihre Security-Ziele präzisieren.

Man könnte argumentieren, dass der risikogetriebene und der zielgerichtete Weg nur unterschiedliche Formulierungen für ein und dieselbe Situation sind: Das Angreiferziel könnte einfach die negierte Version des Verteidigerziels sein. Security ist jedoch kein Nullsummenspiel: “Im Fußball sind die Tore, die ein Angreifer erzielt, genau die Tore, die der Verteidiger verliert. Bei der Security ist das anders: Es besteht nicht unbedingt ein Verhältnis zwischen den Verlusten des Systembetreibers und den Gewinnen des Angreifers.” Das bedeutet, dass es zwei verschiedene Wege für das Finden sinnvoller Security-Anforderungen gibt, einen aus der Sicht des Angreifers und einen aus der Sicht des Ingenieurs (des Verteidigers), und beide bringen möglicherweise unterschiedliche Erkenntnisse.

Der dritte Entscheidungsweg ist einfach, aber sehr häufig. Man kümmert sich dabei nicht groß um die Architektur, die man schützen will, und ihre Security-Probleme. Auf dem compliance-getriebenen Entscheidungspfad besteht nämlich das einzige Security-Problem darin, eine bestimmte Vorschrift einzuhalten — sei es per Gesetz oder durch Unternehmensrichtlinien -, so dass die Security-Anforderungen bereits festgelegt sind. Die einzige Entscheidung, die Sie noch treffen müssen, ist eine Anwendbarkeitsentscheidung: Trifft diese Vorschrift auf meine Situation zu?

Es gibt noch einen vierten Weg, der ein Sonderfall ist, aber wir betrachten ihn trotzdem kurz, weil so viele Security-Engineering-Methoden, insbesondere im Software Engineering, davon Gebrauch machen. Bei bibliotheksgestützten Security-Entscheidungen bauen Sie Ihre Entscheidungsfindung auf ähnlichen Entscheidungen auf, die Sie zuvor für ähnliche Architekturen und/oder Probleme getroffen haben.

Die Security-Entscheidungsbasis

Letzte Frage: Auf der Grundlage welcher Informationen treffen Sie Ihre Security-Entscheidungen, oder kürzer: Was ist Ihr Security-Entscheidungsbasis?

Diese Frage ist etwas komplizierter. Es geht um Konzepte, die Sie zur Darstellung Ihrer Architektur, Ihrer Security-Probleme, Security-Anforderungen und deren Umsetzung verwenden. Oft nimmt man die vertrauten Konzepte als selbstverständlich hin, obwohl sie je nach Fachgebiet und auch je nach dem Security-Entscheidungspfad sehr unterschiedlich sind.

In the below image is an overview over concepts (white rectangles) that we deemed useful fot automation engineering, which also do not restrict the decision-making path you can choose. Why we decided to include each specific concept is too lengthy to explain here, but you can read it in our research paper “A Security Decision Base”. Here, we just briefly explain the core concepts, and provide examples and related concepts.

In der folgenden Abbildung finden Sie eine Übersicht über Konzepte (weiße Rechtecke), die wir für die Automatisierungstechnik als nützlich erachtet haben und die den Entscheidungsweg, den Sie wählen können, nicht einschränken. Die Gründe für die Aufnahme jedes einzelnen Konzepts sind zu umfassend, um sie hier zu erläutern, aber Sie können sie in unserem Forschungsbeitrag “A Security Decision Base” nachlesen. Hier erklären wir nur kurz die Kernkonzepte und nennen Beispiele und verwandte Konzepte.

Funktion

Das Funktionskonzept zieht sich durch alle Phasen des Entscheidungsprozesses. Wir haben es ein wenig modifiziert, um nicht nur technische Details, sondern auch Informationen über die Intention einer Funktion und die beteiligten Personen zu erfassen — denn das sind wesentliche Informationen für die Security.
So können Funktionen zur Beschreibung der zu schützenden Architektur, der Risikoszenarien, der Security-Funktionen oder der “security-enhanced” Funktionen (um Security-Anforderungen angereicherte Funktionen) und auch der Lösungsarchitektur verwendet werden.

Beispiele: Programmieren einer PLC, Backup der PLC-Logik

Verwandte Konzepte: Anwendungsfall (Use Case), Akteur / Stakeholder, Aufgabe, Ressource, Abhängigkeit, Datenfluss

Unerwünschtes Ereignis

Ein unerwünschtes Ereignis ist der Ausgangspunkt eines jeden Risikoszenarios: Das Ereignis, das Systembetreibern einen wirklich schlechten Tag bescheren würde; das Ereignis, das auf keinen Fall eintreten darf. Risikoszenarien führen zu mindestens einem unerwünschten Ereignis.

Beispiele: Überdruck im Reaktor, Bekanntwerden von Rezepturen bei Konkurrenten, “Loss of View” im Leitsystem

Verwandte Konzepte: Auswirkung, high-consequence-event (bekannt aus der CCE-Methode des Idaho National Laboratory), Worst-Case-Szenario, gefährliches Ereignis, “anti-goal”, Absicht des Angreifers, Ziel des Angreifers

Security-Ziel

Wir verwenden das Konzept des Security-Ziels, um die verschiedenen Entscheidungspfade zusammenzuführen: Sie alle enden in einem Security-Ziel. Danach wird der Prozess auf die gleiche Weise fortgesetzt, unabhängig davon, welchen Pfad man eingeschlagen hat, um zur Entscheidung zu gelangen. Daher definieren wir ein Security-Ziel recht flexibel. Es kann ein Compliance-Ziel sein (“diese Vorschrift einhalten”), aber auch ein herkömmliches Security-Ziel, das sich aus Vertraulichkeit, Integrität und Verfügbarkeit zusammensetzt.

Beispiele: Vertraulichkeit von Rezeptdaten, Integrität der SPS-Logik, Nichtabstreitbarkeit von Buchhalter-Handlungen bei der Rechnungsstellung, Vertrauenswürdigkeit der Engineering-Station = {Integrität, Authentizität, Rechenschaftspflicht} der Engineering-Station

Verwandte Konzepte: “security objective”, Schutzziel, “soft goal”

Security-Parameter

Erinnern Sie sich an unsere Beispiele für Security-Entscheidungen zu Beginn dieses Artikels? Das Sammelsurium an kleinen Konfigurationen, die alle irgendwie die Security beeinflussen und die wir sichtbar machen mussten?
Nun, diese werden durch das Konzept der Security-Parameter repräsentiert. Security-Parameter sind alles, was sich, wenn es verändert wird, auf die Security Ihres Systems auswirkt.

Beispiele: Wahl eines Kommunikationsprotokolls, Integritätsschutz der SPS-Logik, Mechanismus zur Änderung der Betriebsmodi, Benutzerkonten (z.B. Standard oder individuell)

Verwandte Konzepte: keine

Angriffspunkte

Angriffspunkte sind ähnlich wie Security-Parameter. Auch sie sind dazu da, etwas sichtbar zu machen, was sonst nur selten explizit erwähnt wird. Alles, was dazu benutzt werden könnte, ein unerwünschtes Ereignis herbeizuführen, ist ein Angriffspunkt. Man könnte sagen, das ist doch eine Schwachstelle — und das stimmt auch, Schwachstellen sind Teil der Angriffspunkte. Aber insbesondere bei Automatisierungssystemen gibt es so viele Möglichkeiten, zu einem Risikoszenario beizutragen, die nicht wirklich Schwachstellen, sondern legitime, vorgesehene Funktionen sind — sie sind “insecure by design”. Dazu gibt es die Angriffspunkte: Um “insecure by design” sichtbarer zu machen.
Oft ist ein Angriffspunkt ein Security-Parameter, der einen Wert annimmt, der ihn potenziell in einem Risikoszenario ausnutzbar macht.

Beispiele: CVE bezogen auf eine Komponente,
Integritätsschutzmechanismus für SPS-Logik: keine,
Benutzerkonten: Standard

Verwandte Konzepte: Schwachstelle / “vulnerability”, “weakness”

Ich weiß, dass die Lektüre über Security-Entscheidungen und noch mehr die über theoretische Konzepte für eine Security-Entscheidungsbasis eher trockener Stoff ist. Deshalb ist das nächste Ziel unseres Forschungsprojekts, die oben genannten Konzepte in Diagrammen zu visualisieren. Diagramme, die alle relevanten Informationen, die ein Mensch für Security-Entscheidungen braucht, für Menschen einfach verdaulich aufbereiten. Denn ich bin überzeugt, dass es auch in Zukunft Menschen sein werden, die Security-Entscheidungen treffen.

Und diese Menschen brauchen keine Methode, kein Tool, dass ihnen ihre Security-Entscheidungen abnimmt. Sie brauchen eine Methode, die ihre Security-Entscheidungen unterstützt. Eine Methode, die hilft, das Sammelsurium impliziter, unbewusster Security-Entscheidungen in explizite, bewusste und informierte Security-Entscheidungen zu verwandeln.

Dieser Text basiert auf einem wissenschaftlichen Paper, das erstmals auf der EKA-Konferenz in Magdeburg am 23. Juni 2022 vorgestellt wurde. Die Forschung wird vom deutschen Bundesministerium für Bildung und Forschung gefördert.