Wie kann Vertrauen in die Sicherheit komplexen Systeme gewonnen werden?

Evaluierung komplexer Systeme durch die IT-Sicherheitskriterien

16.11.1990

Nachdem mittlerweile Erfahrungen mit den deutschen Kriterien für die Beurteilung der Vertrauenswürdigkeit von informationstechnischen Systemen, den bekannten "IT-Sicherheitskriterien", vorliegen, ist es an der Zeit, sich danken über den zukünftigen Verlauf der Standardisierung von Sicherheitskriterien zu machen. Es zeigt sich, daß verstärkt eine differenzierte Beurteilung der Komponenten eines komplexen Systems, wozu sowohl Vernetzte Systeme als auch umfangreiche Betriebssysteme zählen gefordert ist.

Obschon in den deutschen IT-Sicherheitskriterien durch das gegenüber dem legendären "Orange Book" neue Konzept der Funktionalitätsklassen das Potential dazu angelegt ist, kann der Standard erst dann für -solche komplexen Systeme adäquat sein, wenn neue und differenzierte Funktionalitätsklassen geschaffen werden. Eine Weiterentwicklung der IT-Sicherheitskriterien in dieser Hinsicht muß zum einen die Grundzüge des OSI-Modells einschließen und zum anderen Normen für die Grundfunktionalitäten eines

Betriebssystems entwickeln, soweit diese Gegenstand von Sicherheitsanforderungen werden können.

TNI liefert zwei Maßstäbe

Als "komplex" werden hier solche Systeme aufgefaßt, die unter dem Aspekt der Evaluierung nicht angemessen behandelt werden, wenn man sie "monolithisch", also als geschlossenes Ganzes betrachtet. Bei solchen Systemen haben aus verschiedenen Gründen Teilkomponenten Bedeutung, deren Sicherheitseigenschaften separat beurteilt und vermittelt werden müssen. Dazu gehören vernetzte Systeme, deren Zerlegung in Teilkomponenten bereits die "Trusted Network Interpretation" (TNI) des Orange-Book leistet. Die Praxis der Evaluation von umfangreichen Betriebssystemen zeigt darüber hinaus, daß auch diese im genannten Sinn komplex zu nennen sind.

Die "Trusted Network Interpretation" für vernetzte Systeme, die seit 1987 vorliegt,- verfehlt in ihrer charakteristischen Zweiteilung das wesentliche Ziel der Normierung. Sie betrachtet zum einen Netze als abgeschlossene komplette Systeme, die als Ganzes evaluiert werden, wobei im wesentlichen das Orange Bock Anwendung findet. ("Single Trusted System View"). Die andere angebotene Sichtweise respektiert, daß Netze auch aus geprüften Komponenten zusammensetzbar ein müssen ("Interconnected Accredited Systems View") und führt zu problematischen "Composition Rules" (etwa das "Cascading Problem"). In jedem Fall liefert die TNI zwei Maßstäbe, deren Äquivalenz nicht gezeigt werden kann. Vernetzte Systeme unterliegen heute oft einer Dynamik in Aufbau und Umfang, so daß die Beurteilung von Komponenten aller Art in den Vordergrund rückt. Eine scharfe Trennung zwischen einer Akkreditierung und einer Evaluierung des gesamten Netzes ist praktisch nicht mehr möglich. Vielmehr wird eine Vielzahl von zusammenhängenden und gegebenenfalls aufeinander auf bauenden Teilevaluierungen von Komponenten und Subkomponenten notwendig. Dies verlangt die "Kommunizierbarkeit" von differenzierten Prüfergebnissen (die wesentlich auch allgemeine Funktionalitäten umfassen müssen) zwischen den separaten Prüfprozessen, wodurch unmittelbar ein Normierungsbedarf entsteht.

Bei der Frage, was nun sinnvollerweise als Teilkomponente eines Netzes zu betrachten ist, trifft man auf eine zum Teil sehr dogmatisch geführte Auseinandersetzung. Die Positionen können überspitzt wie folgt charakterisiert werden: Die eine Seite

betrachtet Netze im wesentlichen als eine Sammlung von klassischen "monolithischen" Hosts, die über die "unproblematische kleine Zusatzfunktion" verfügen,. Daten austauschen zu können ("Bit-Shipping-Net"). Dies ist der Kern des "Interconnected Accredited Systems View" der TNI. Diese eher von Praktikern vertretene Sichtweise versucht, Komponenten so festzulegen, daß deren Schnittstellen mit Physischen Schnittstellen identifizierbar werden.

Die andere eher von Theoretikern vertretene Position besagt, daß das Netz im wesentlichen ein verteiltes (distributed) System, bestehend aus OSI-Layern und Kommunikationsprotokollen, darstellt. Endsysteme sind hier wenig mehr als Träger von ausfahrenden Prozessoren für die "Application Entities" (In dieser eher ganzheitlichen Sichtweise von Netzen finden sich ironischerweise deren Befürworter zum Teil gerade mit jenen vereint, die in der Vergangenheit überhaupt jedes spezielle Problem bei Netzen bestritten und die Perspektive des "Single Trusted System View" in der TNI durchsetzten.)

Inzwischen ist hier eine Annäherung zu verzeichnen. Die einen beginnen zu verstehen, daß die Sicherheit in Netzen nicht allein auf die Vertrauenswürdigkeit der Endsysteme zurückzuführen ist, beziehungsweise nicht allein damit verständlich werden

kann, sondern daß auch Sicherheitsmaßnahmen in den Kommunikationsprotokollen berücksichtigt werden müssen (und damit ist nicht nur Datenverschlüsselung gemeint). Die anderen sehen ein, daß die schönsten Verschlüsselungsprotokolle nichts nützen, wenn die Endsysteme nicht in der Lage sind, die Schlüssel vertrauenswürdig aufzuheben.

Es ist also zu akzeptieren, daß als sinnvolle Teilkomponenten sowohl Hardwarekomponenten (zum Beispiel Router oder andere Netz-Devices), als auch Softwarekomponenten (wie ein verteiltes Softwarepaket zur Implementierung von Kommunikationsprotokollen) anzusehen sind.

An einem solchen Kommunikationsprotokoll für die Schichten 3 und 4 (Network Layer, Transport Layer) des OSI-Modells sei nun die Anwendbarkeit der IT-Sicherheitskriterien geprüft.

Es zeigt sich, daß eine Vielzahl der dort angebotenen Funktionalitätsklassen von Relevanz ist (Abbildung 1). Da der Transportservice des Systems insbesondere von Sicherheitsmechanismen in höheren Protokollen genutzt werden soll, gewinnt nahezu die gesamte Funktionalität des Systems - die Bereitstellung eines OSI-Transportservices - den Rang einer Sicherheitsfunktion.

Die Voraussetzungen müssen angegeben werden

Systeme mit hohen, Anforderungen an die "Gewährleistung der Funktionalität" werden in der Funktionalitätsklasse "F7" zusammengefaßt. Verschiedene Sicherheitsgrundfunktionen sind implizit gefordert, die in verschiedenen anderen Funktionalitätsklassen angesiedelt sind.

Das Zertifikat beziehungsweise die Prüfergebnisse müssen detailliert die Voraussetzungen angeben, unter denen das Produkt sicher, das heißt gemäß seinen Anforderungen, läuft.

Dies sind zum Beispiel die Dienste des Data-Link-Layers sowie die technische "Infrastruktur, in die das Produkt eingebettet wird (etwa hinreichend schnelle Prozessoren).

Das Beispiel demonstriert zum einen, daß im allgemeinen Sicherheitsfunktionen- und sonstige Funktionalität wesentlich stärker zusammenhängen als nur über den bekannten Konflikt "Sicherheit versus Performance", denn Sicherheitsfunktionen sind insbesondere Systemfunktionen und nutzen beliebige andere Systemfunktionen.

Zum anderen verweist das Beispiel darauf, daß die groben Funktionalitätsklassen der jetzigen IT-Sicherheitskriterien für solche Fälle sicher nicht adäquat, das heißt differenziert genug, sind.

Das war auch nicht anders zu erwarten, da die jetzigen Funktionalitätsklassen in erster Linie Entsprechungen zum "Orange Book" angeben wollen und darüber hinaus lediglich erste Vorschläge darstellen.

Es muß aber auch die Bedeutung der Sicherheitsgrundfunktionen diskutiert werden, die in den IT-Kriterien unter "Übertragungssicherung" subsumiert sind. Diese haben aus Anwendersicht - anders als die anderen Sicherheitsfunktionen, wie "Rechteverwaltung", "Identifikation und Authentisierung" etc. - deutlich eher die Eigenschaften von realisierenden Mechanismen als von "Services". Hier erscheint es wesentlich sinnvoller, sich nicht auf spezielle Maßnahmen zu beziehen, sondern die (sichere), "Übertragung von Daten" schlechthin als eine Sicherheitsgrundfunktion anzuerkennen. Das geschieht beispielsweise in einem in Vorbereitung befindlichen Standard der ECMA (/TC32/TG9: Security in Open Systems - A Security Framework"). Die dort definierten "Security Services" für den Gebrauch in der Anwendungsschicht 7 des OSI-Modells sind in der Mehrheit auf die Sicherheitsgrundfunktionen der IT-Sicherheitskriterien abbildbar. Statt der Übertragungssicherung wird hier aber ein Service "Secure Association" erkannt.

Um die vielfältigen Funktionalitäten von Teilkomponenten mit den IT-Sicherheitskriterien zu erfassen, das heißt durch Funktionalitätsklassen zu kategorisieren, müssen diese standardisiert sein und sich insbesondere durch eine normierte Zerlegung

von Netzen ergeben. Die Schnitte, mit denen ein vernetztes System sinnvoll und allgemein akzeptiert zerlegt wird, sind jedoch durch das OSI-Modell vorgezeichnet. So ist etwa die Definition von verschiedenen F-Klassen für die Dienstleistungen (Services) der OSI-Layers denkbar.

Bei der Evaluierung besonders umfangreicher Betriebssysteme stellen sich in der Praxis Probleme, deren Analyse zu ähnlichen Folgerungen führt wie bei vernetzten Systemen.

Zunächst beobachtet man, daß das untersuchte System ebenfalls einer Dynamik unterliegt. Ein umfangreiches Softwaresystem ist faktisch nie fertig, sondern befindet sich aufgrund ständiger Fehlerkorrekturen und Versionswechsel stets im Fluß.

Dadurch bekommt die Evaluierung den Charakter einer begleitenden Evaluierung - mit besonderen Problemen, wie etwa der stets unvollkommenen Dokumentation.

Ein anderer dynamischer Aspekt des Systems ergibt sich daraus, daß ein modernes Großrechner-Betriebssystem heute in der Regel für den Dauerbetrieb ausgelegt wird und daher Software-Änderungen dynamisch im laufenden Betrieb erfolgen. Dadurch werden einige früher eindeutige Begriffe der IT-Sicherheitskriterien wie "Systemstart", "Systemgenerierung", "Herstellung", "Wartung" etc. unscharf und müssen mit Mühe interpretiert werden. Insbesondere aber steigt die Bedeutung der Nachevaluierung des Systems, von Teilen des Systems oder der Zulässigkeit einer Einbindung von neuen geprüften Teilen.

Zudem weisen moderne Systeme deutlich selbst Phänomene der Vernetzung auf, beispielsweise wenn es sich um Mehrprozessor-Anlagen handelt oder wenn die Verbindung mit Peripheriesteuerungen wie ein Netz behandelt werden muß. Die Evaluierung konnte es sich bisher meist leisten, Aspekte der Vernetzung hier zu vernachlässigen ohne einen systematischen, das heißt einen für Netze adäquaten, Zugang zu wählen, weil diese Netze in der Regel noch homogen, klein und statisch, also leidlich überschaubar, sind.

Ein vertrauenswürdiges Bewertungsurteil auch für komplexe Systeme kann jedoch nur bei ausreichender Transparenz für die Evaluatoren erlangt werden. Es muß bezweifelt werden, daß diese erreichbar ist, wenn die faktisch gegebene Netzstruktur eines

solchen Systems vom Hersteller nicht auch so präsentiert wird, nur weil er selbst das System nicht als Netzwerk betrachtet.

Detailergebnisse müssen standardisiert sein

Ein weiteres Problem entsteht bei umfangreichen Systemen aus dem Umstand, daß die Evaluierung wegen des Arbeitsaufwandes im hohen Maß arbeitsteilig durchgeführt werden muß. Auch hier entsteht ein Bedarf nach der Festlegung von standardisierten Komponenten, deren Prüfergebnisse leichter "kommunizierbar", weil standardisiert sind. Es sollte zum Beispiel nicht davon ausgegangen werden, daß für die Evaluierung eine hinreichende Anzahl von Experten mit der nötigen Systemkenntnis zur Verfügung steht.

Die Einarbeitung von Nichtexperten in eine komplexe und umfangreiche Systemarchitektur aber ist teuer und zeitaufwendig.

In der Folge gewinnt die Betrachtung von Teilkomponenten also auch hier wie bei Netzen an Relevanz. Und dabei reicht es nicht, die jeweiligen Detailergebnisse der Prüfung neben dem Gesamtergebnis aufzuheben. Damit Prüfergebnisse von Komponenten später effektiv ausgenutzt werden können und die Ergebnisse von Nachevaluierungen dieselbe Glaubwürdigkeit besitzen wie das eigentliche Prüfergebnis, müssen die Detailergebnisse in einem gewissen Grade standardisiert sein.

Anders als für Netze gibt es für standardisierte Betriebssystem-Funktionen kein allgemeines Modell. Geeignete Ansätze sind jedoch in dem oben zitierten ECMA-Standard zu finden. Dort wird das komplexe Verhältnis von OSI-Elementen und der von ihnen genutzten, von den lokalen Endsystemen bereitzustellenden "Security Infrastructure" beleuchtet. Diese stellt sich als ein Ablauf-Environment für Applikations-Instanzen und Security-Services dar, für das eigene Sicherheitsfunktionalitäten im weiteren Sinn gefordert sind, die sich mit den IT-Sicherheitskriterien in der gegenwärtigen Form nicht erfassen lassen (Abbildung 2).

Die IT-Sicherheitskriterien bieten im Prinzip alle Mittel, um beliebige Systeme abseits der klassischen Betriebssysteme sinnvoll bewerten zu können. Voraussetzung für die Bewertung der hier komplex genannten Systeme, wie Netze und besonders umfangreiche Systeme, ist die Definition von differenzierteren Funktionalitätsklassen. Dabei müssen die IT-Kriterien jedoch einem Wildwuchs bei den Funktionalitätsklassen

steuernd vorbeugen. Sie müssen stärker als bisher die allgemeine Funktionalität für die Zwecke der Bewertung standardisieren. Es sollten nicht nur die Möglichkeiten genutzt werden, welche die Definition neuer Funktionalitätsklassen bietet, sondern es sollten auch die Sicherheits grundfunktionen einer Revision unterzogen werden.

Darüber hinaus ist zu diskutieren, ob nicht die Vertrauenswürdigkeit der Bewertungsurteile wächst, wenn aus differenzierten Funktionalitätsklassen Maßgaben für die Dokumentation eines Systems abgeleitet werden, die deren Transparenz erhöhen. Selbst wenn in verschiedenen hier angedeuteten Fragen noch kein Einverständnis zu erzielen ist, sollte die Diskussion jetzt beginnen, um der Entwicklung konkurrierender Standards vorzubeugen.