Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.02.1989 - 

Referenzmonitor soll Mißverständnisse zwischen Juristen, Organisatoren und Informatikern verhüten:

Sicherheit nur auf gemeinsamer Basis möglich

In den Jahren l987 und 1988 zeigten spektakuläre Einbrüche in Rechnersysteme, daß die Sicherheit dieser Systeme und der von ihnen bearbeiteten Daten oft auf eine viel subtilere Art bedroht ist, als man das bis dahin allgemein angenommen hatte. Diese Bedrohungen sind nicht neu, aber sie treten erst letzt in das Bewußtsein der Öffentlichkeit.

Hier wird ein altes Dilemma jeglicher Sicherheitsdiskussion offenkundig: Solange Schutzverletzungen nicht wirklich erfolgen, bestehen alle Sicherheitsmaßnahmen letztlich aus einem Kampf gegen nicht existierende Vorgänge, dessen Nutzen oft nur schwer abzuschätzen ist und auch vielfach nicht gesehen wird. Wenn dann aber einmal ein größerer Schaden auftritt, rächen sich die Unterlassungen auf diesem Gebiet - doch es nützt nichts, den Wert der bearbeiteten Daten erst dann zu erkennen, wenn sie schon zerstört oder verfälscht sind.

Organisatorische Mängel machen es Hackern leicht

Was war nun eigentlich geschehen? Betrachten wir die beiden Vorfälle, die in der Presse am meisten diskutiert wurden:

- Beim sogenannten "NASA-Hack" drangen Hacker der Reihe nach in 135 VAX-Computer ein und manipulierten das Betriebssystem so, daß sie die völlige Kontrolle über diese Maschinen erhielten und unerkannt mit den Rechnern arbeiten konnten. Möglich wurde dies durch eine Reihe von Umständen, von denen vor allem über die Auswirkungen eines Fehlers im Betriebssystem viel geschrieben wurde. Dieser Fehler erlaubte es zwar einem legalen Benutzer, sich beliebige Rechte im Rechner anzueignen und damit dessen Sicherheit zu unterlaufen; damit die einzelnen Rechner sich jedoch für die Hacker öffneten, mußten weitere Fehler hinzukommen - und diese Fehler lagen nicht in der Technik, sondern in deren falscher Bedienung durch Menschen. Damit die Hacker nämlich überhaupt in die Maschinen eindringen konnten, mußten sie wenigstens ein Paßwort kennen, und dieses besorgten sie sich für jede einzelne der 135 Maschinen! Dies wäre in jedem Falle zu verhindern gewesen, wenn der Verwaltung der Benutzer und ihrer Paßwörter von seiten der Rechner-Betreiber mehr Aufmerksamkeit geschenkt worden wäre.

- Ende 1988 legte ein Wurm-Programm etwa 6000 Rechner, davon etliche SUN-Workstations, im amerikanischen Rechnernetz ArpaNet lahm, indem es sich in kürzester Zeit über all diese Maschinen verbreitete und sie dabei so stark belastete, daß normale Arbeit kaum noch möglich war. Bei dieser Invasion wurde eine (zu Wartungszwecken vorhandene) Lücke im Sicherheitssystem der Rechner ausgenützt, um Zugang zu den Maschinen zu erlangen.

Man sieht an diesen beiden Beispielen, daß die Ursachen für eine Verletzung des Schutzes von Rechnern an den verschiedensten Stellen liegen können, wobei nicht nur technische Fehler, sondern auch Mängel im organisatorischen Umfeld dem potentiellen Angreifer die Türen öffnen können. Dies wird besonders deutlich, wenn man bedenkt, daß in einer Reihe der beim NASA-Hack kompromittierten Maschinen auch drei Wochen nach Bekanntwerden des Falles die von den Hackern benutzten Paßwörter noch nicht geändert waren! Man darf also sehr skeptisch sein, ob aus diesen Vorfällen wirklich dauerhafte Lehren für die Zukunft gezogen werden.

Datenschutz erfordert systematischen Ansatz

Wegen der Komplexität der Schutz-Problematik und der - im NASA-Hack demonstierten - Verwobenheit von technischen und organisatorischen Problemen ist es erforderlich, den Schutz eines Rechenzentrums umfassend und unter Berücksichtigung aller relevanten Aspekte zu planen und zu realisieren. Dies kann nur dann mit einigem Erfolg geschehen, wenn man systematisch vorgeht und sich dazu auf ein Schutzmodell abstützt, das die juristische, die organisatorische und technische Seite des Schutzes in konsistenter Weise behandelt.

So ergeben sich aus der Datenschutz-Gesetzgebung eine Reihe von Fragen an den Betreiber eines Rechenzentrums, für die er mit seinem Schutz-Instrumentarium geeignete Antworten und Lösungen finden muß, um gesetzeskonform zu bleiben. Beispielsweise sind zum Komplex des Datenschutzrechts Fragen zur Zulässigkeit und Ordnungsgemäßheit der Datenspeicherung, -veränderung, -übermittlung und so weiter zu beantworten.

Datenzugriff muß auch technisch verankert sein

Daraus ergeben sich Vorgaben für einen organisatorischen Rahmen, in dem Verfahren für die Durchführung der einzelnen Datenverarbeitungsaufgaben festgelegt werden müssen, und diese müssen durch entsprechende Vorschriften explizit festgelegt werden. Neben den Angaben, welche Daten auf welche Arten zu verarbeiten und zu schützen sind, muß hier auch festgelegt werden welche Benutzer mit dem System arbeiten dürfen und welche Rechte man jedem einzelnen von ihnen geben oder auch verweigern muß. (So sollte man tunlichst nicht jedem Angestellten das Recht geben, in einer Personal-Datenbank sein eigenes Gehalt beliebig zu verändern.)

Aus den organisatorischen Vorgaben ergibt sich schließlich eine Liste von technischen Maßnahmen, die man ergreifen muß, um - soweit dies machbar und wirtschaftlich vertretbar ist - diese Vorgaben durch Abläufe im Rechner zu unterstützen oder auch zu erzwingen. Beispielsweise können geeignete Zugriffskontrollsysteme die Möglichkeiten der Benutzer eines Systems, illegale Operationen durchzuführen, drastisch beschneiden, oder ein mitlaufendes Audit-Log erlaubt jederzeit den Nachweis, was mit bestimmten Informationen gemacht wurde.

Modell als Grundlage sämtlicher Spezifikationen

Eine ganz große Schwierigkeit bei diesem Vorgehen ist jedoch, daß hier Probleme auf ganz verschiedenen Ebenen und in ganz verschiedenen fachlichen Umfeldern in konsistenter Weise gelöst werden müssen. Dabei treten erfahrungsgemäß oft nicht unbeträchtliche Sprachschwierigkeiten zwischen Juristen, Organisations-Fachleuten und Informatikern auf, die zu erheblichen Reibungsverlusten, Mißverständnissen oder sogar unsinnigen Gesamtlösungen führen können. Dies ist kaum verwunderlich, da die einzelnen Fachsprachen sehr unterschiedlich sind und von Fachleuten anderer Gebiete meist nur unvollständig oder überhaupt nicht verstanden werden.

Diese Schwierigkeiten sich erheblich verringern, wenn man sich auf ein gemeinsames Modell als Bezugsrahmen einigen kann, das dann von allen Beteiligten als Grundlage sämtlicher Sicherheitsspezifikationen verwendet wird. Ein solches Modell, das mittlerweile auch schon von Juristen eingesetzt wird obwohl es ursprünglich aus der Informatik stammt, ist das des Referenzmonitors. Dieses Modell stellt ein Rechnersystem als eine Menge von Subjekten und Objekten dar, deren erlaubte Beziehungen in einer Datenbasis beschrieben sind und durch einen aktiven Systemteil, eben den Referenzmonitor geregelt werden, wobei dieser gegebenenfalls Einträge in ein Audit-Log vornimmt.

Subjekte sind dabei aktive Elemente, die - im Auftrag realer Personen - Zugriffe auf Informationen ausführen. Objekte sind dagegen die passiven, zu schützenden Informationsträger. Die Autorisations-Datenbasis definiert die Sicherheitsanforderungen des Systems, indem sie festlegt, welche Subjekte - für welche Benutzer - in welcher Weise auf welche Objekte (als Informationsträger) zugreifen dürfen. Je nach den in der Datenbasis festgelegten Vorschriften können - erfolgreiche oder abgewiesene - Zugriffsversuche bestimmter Subjekte auf bestimmte Objekte zu Einträgen im Audit-Log führen.

Der Referenzmonitor erzwingt die Einhaltung der Sicherheitsvorschriften, indem er die Erzeugung von Subjekten vermittelt, den Subjekten gemäß den Vorschriften der Datenbasis Zugriffsrechte auf Objekte verleiht und bei Bedarf Ereignisse im Audit-Log protokolliert. In einem idealen System muß der Referenzmonitor die folgenden drei Forderungen erfüllen:

- Er muß jeden Zugriffsversuch eines Subjektes auf ein Objekt vermitteln; Zugriffe am Referenz-Monitor vorbei müssen unmöglich sein.

- Er muß eine gegen unberechtigte Manipulationen zuverlässig geschützte Datenbasis und ein Audit-Log zur Verfügung stellen, das gegen unautorisierte Beobachtung und Modifikation geschützt ist.

- Er muß klein, einfach und klar strukturiert sein, so daß seine Effektivität in bezug auf seine Rolle als Vermittler von Sicherheit sichergestellt werden kann.

Es hat sich gezeigt, daß dieses konzeptuell, sehr einfache Modell gut geeignet ist, eine gemeinsame Verständigungsbasis zwischen Juristen, Organisatoren und Informatikern zu schaffen, da sich die dort verwendeten Begriffe relativ einfach und klar auf die jeweiligen Fachsprachen abbilden lassen. Zu seiner Anwendung müssen die jeweils relevanten Subjekte und Objekte identifiziert und für die zwischen ihnen möglichen Rechtsbeziehungen geeignete Regeln aufgestellt werden, die beispielsweise die juristischen Vorgaben abbilden und letztlich als Zugriffsalgorithmen implementieren.

Idealerweise wird ein Rechner verwendet, dessen interne Zugriffskontrollverfahren das Konzept des Referenzmonitors (mehr oder weniger genau) implementieren, so daß die technische Ebene des Schutzes ziemlich direkt aus ihren Vorgaben folgt. Wenn dies jedoch - vor allem bei historisch gewachsenen Umgebungen - nicht der Fall ist, so lassen sich dennoch die fehlenden Teile mit tragbarem Aufwand ergänzen - schlimmstenfalls durch organisatorische Regeln, die bestimmten Benutzern den Zugriff auf bestimmte Daten verbal verbieten, wenn das eingesetzte EDV-System schon nicht in der Lage ist, dieses Verbot technisch zu erzwingen. Aber selbst in diesem Fall ist die Schutzproblematik dadurch wesentlich einfacher und überschaubarer geworden, daß man durch das verwendete Modell gezwungen wurde, Subjekte, Objekte und Zugriffsregeln explizit festzulegen.

Validierung als Qualitätsgarantie

Ein Problem bleibt jedoch auch dann noch ungelöst, wenn man alle Schutzmaßnahmen korrekt und vollständig geplant und realisiert hat: Es ist dann immer noch möglich, daß der ganze Schutz in sich zusammenbricht, weil das verwendete EDV-System interne Schwächen hat, von denen man aber nichts wußte, so daß man sich auf unzuverlässige Maßnahmen verläßt. Wer kann nun aber zuverlässig feststellen, ob ein bestimmtes System die versprochenen Schutzfunktionen auch tatsächlich bietet?

Kriterienkatalog für Prüfung angestrebt

Der Anwender ist hier mit Sicherheit überfordert, da eine gründliche Sicherheitsüberprüfung eines Systems auf eine minuziöse Analyse der gesamten Hard- und Software hinausläuft - ein Unterfangen also, dessen Umfang meist in Mannjahren zu rechnen ist und das höchste Qualifikation der Prüfer verlangt. Andererseits braucht eine solche Überprüfung auch nicht für jede Anwendung neu durchgeführt zu werden; wenn sie für einen Anwender erfolgt ist, können ihre Ergebnisse meist auch von einer Reihe anderer Anwender mit übernommen werden.

Gemäß dieser Argumentation wurde Anfang der 80er Jahre vom amerikanischen Verteidigungsministerium ein Kriterienkatalog, das sogenannte "Orange Book" entworfen, in dem die Grundlagen eines allgemeinen Prüf- und Bewertungsverfahrens für EDV-Systeme, und zwar mit dem Schwerpunkt Betriebssysteme, gelegt wurden. Nach diesem Katalog wurden und werden seitdem in den USA eine Reihe von Betriebssystemen und Sicherheitspaketen auf ihre Tauglichkeit hin untersucht und bewertet.

Der Einsatz eines als sicher bewerteten Systems nimmt dem Anwender wenigstens teilweise die Verpflichtung ab, Aussagen über die Sicherheit der verwendeten EDV-Anlage zu erarbeiten; er kann sich statt dessen auf die Ergebnisse des Bewertungsverfahrens abstützen. Allerdings ist auch hierdurch keine absolute Sicherheit zu erreichen; auch als sicher bewertete Systeme können noch Fehler enthalten, die bei der Untersuchung nicht bemerkt wurden, doch ist generell in bewertete Systeme ein wesentlich höheres Vertrauen zu setzen als in unbewertete.

Für Nicht-Amerikaner unangenehm ist jedoch, daß es extrem schwierig bis unmöglich ist, außerhalb der USA entstandene Systeme dort auf ihre Sicherheit hin bewerten zu lassen. Aus diesem Grund bestehen in einer Reihe von Staaten seit einiger Zeit Bestrebungen, eigene Bewertungskriterien zu entwickeln und eigene Institutionen aufzubauen, die auf nationaler Ebene die Prüfung und Bewertung der Sicherheit von EDV-Systemen vornehmen, so daß damit zu rechnen ist, daß in absehbarer Zeit Systeme zur Verfügung stehen, die im jeweiligen Einsatzland für "sicher" befunden wurden.

Ausblick: Interdisziplinäre Kooperation

Die vorangegangenen Abschnitte gaben einen kurzen Abriß über die Problematik, der sich eine für die Sicherheit von EDV-systemen zuständige Planungsgruppe typischerweise gegenübersieht. Dabei stellte es sich als eines der wesentlichen Probleme heraus, eine gemeinsame Verständigungsbasis für die verschiedenen, an der Planung beteiligten Fachleute aufzubauen. Hier ist dringend eine bessere Kooperation zwischen technisch und juristisch geschulten Mitarbeitern erforderlich. Dabei kann das hier skizzierte Schutzmodell helfen, Sprachprobleme zu verringern und so die Kommunikation zwischen den Disziplinen (zumindest für diesen Problembereich) zu verbessern, indem es hilft, eine gemeinsame Verständigungsbasis zu schaffen.

Juristen und Informatiker an einem Tisch

Dies zeigte sich zum Beispiel in mehreren Kooperationsseminaren, die der Autor jeweils zusammen mit einem juristischen Co-Referenten durchgeführt hat: Bei diesen, von der Zeitschrift Computer und Recht veranstalteten Seminaren war es möglich, ausgehend vom juristischen Rahmen über eine Behandlung der Organisationsstrukturen bis hin zur technischen Vorführung einer Implementierung der Schutzmaßnahmen die Sicherheit von EDV-Systemen in konsistenter Weise zu behandeln.

Dies wurde von Teilnehmern beider Fachrichtungen begrüßt, da es ihnen die Möglichkeit gab, jeweils einen Einblick in Probleme des anderen Fachs in ihrer eigenen Terminologie zu erhalten und so zu einem besseren Verständnis zu gelangen.