Institut für Informatik III Universität Bonn

Proseminar Grundlagen der Computersicherheit

Thema: Grundbegriffe der Computersicherheit

Leitung: Adrian Spalka

Referent: Martin Löhnertz

1. Inhaltsverzeichnis

1. Inhaltsverzeichnis

2. Überblick

3. Allgemeine Begriffe

3.1. Definition des Sicherheitsbegriffes

3.2. Verschiedene Stufen der Spezifikation

4. Ziele der Sicherheitsbestrebungen

4.1. Geheimhaltung

4.2. Integrität

4.3. Nachweisbarkeit

4.4. Verfügbarkeit

4.5. Ergonomie

5. Risikoanalyse

5.1. Bedrohungsformen und Sicherheitslücken

5.1.1. Angriffsziele und Angriffsvarianten

5.1.2. Schwachstellen

5.2. Klassifizierung von Systemtypen

5.3. Analyse des Gesamtrisikos

6. Methoden des Schutzes ("countermeasures")

6.1. Das Umfeld

6.1.1. Andere Bestandteile der Policen

6.1.1.1. Aufteilung der Verantwortlichkeiten

6.1.1.2. Ausbildung der Benutzer

6.1.2. Physikalischer Schutz

6.1.2.1. Schutz des Rechners

6.1.2.2. Datentransport

6.2. Modelle und Hilfsmittel

6.2.1. Zugriffskontrolle

6.2.2. Das Flußmodell

6.2.3. Authentifizierung

6.2.3.1. Identifikation von Personen

6.2.3.2. Identifikation anderer Computer

6.2.4. Autorisierung

6.2.4.1. Subjekte und Objekte

6.2.4.2. Kontrolle der Autorisierung

6.2.5. Präventive Beobachtung

6.2.5.1. Protokollierung

6.2.5.2. Aktive Beobachtung

6.2.5.3. Konsistenzprüfung

6.2.5.4. Probleme mit dem Datenschutz

6.2.6. Kontrolle der Ressourcen

6.2.7. Kryptographie

6.3. Folgenbegrenzung

6.3.1. Sicherheitskopien

6.3.2. Nachweismethoden

6.4. Schwachstellen der beschriebenen Methoden

6.4.1. Schutz der Sicherheitskopien und Mitschnitte

6.4.2. Notfallmechanismen

7. Anforderungen an die Systementwicklung

7.1. Bedrohungen durch fehlerhafte oder manipulierte Programme

7.1.1. Logische Bomben

7.1.2. Falltüren

7.1.3. Tunneln

7.2. Verifikation

7.2.1. Testen 16 7.2.2. Herkömmliche Verifikation

7.2.3. Beweisen

7.2.4. Der "sichere Kern"

7.3. Schutz vor nachträglicher Veränderung

7.3.1. Troianische Pferde

7.3.2. Würmer

7.3.3. Viren

7.3.4 Schutzmaßnahmen

8. Ausblick

9.Literaturverzeichnis

2. Überblick

Der vorliegende Beitrag versteht sich als Glossar und soll in erster Linie dazu dienen, innerhalb des Proseminars eine einheitliche Terminologie zu schaffen, die das beständige Neudefinieren von Begriffen überflüssig machen könnte. Kapitel 3 führt zunächst einige grundlegende Begriffe ein, die Basis für das Verständnis des folgenden sind. Primär geht es dabei um den Sicherheitsbegriff, den Begriff der Sicherheitspolitik und die verschiedenen Stufen auf dem Weg zur Rechnerimplementation, für die im Rahmen der übrigen Begriffe kein sinnvoller Platz blieb.

Da sich die Sicherheitsbestrebungen nach dem Willen der Anwender zu richten haben, folgt als nächstes in Kapitel 4 eine eingehende Diskussion der zu erreichenden Ziele. Danach kommt eine Übersicht über die Risiken und möglichen Angriffsmethoden, die ob deren Anzahl natürlich nur exemplarisch sein kann, und in erster Linie darauf abzielt, eine grobe Vorstellung von den Gegebenheiten zu schaffen.

In Kapitel 5 wird zunächst kurz auf das Umfeld eingegangen, da eine Absicherung des Computersystems ohne Sicherung der Hardware und das Einhalten bestimmter organisationsinterner Prozeduren illusorisch ist. Danach wird auf die Modelle und Hilfsmittel eingegangen, die sich im Laufe der Zeit als nützlich herausgestellt haben und die heute zumeist verwendeten sind.

All dies muß dann seinen Niederschlag in der Methode der Systementwicklung finden, da dies die einzige Stelle ist, an der der Informatiker zur Sicherheit des Systems beitragen muß. Die hierzu üblichen Vorgehensweisen werden in Kapitel 6 behandelt.

Der Ausblick befaßt sich mit der Veränderung der Anforderungen, die sich durch die Ausweitung der globalen Vernetzung ausgehen und beinhaltet eine (leichte) Kritik an der grundlegenden Vorgehensweise bei der Installation sicherer Systeme.

3. Allgemeine Begriffe

3.1. Definition des Sicherheitsbegriffes

Verwendet man im Deutschen den Begriff der Sicherheit, so meint man damit eigentlich zwei verschiedene Dinge, denen in der englischen Sprache auch zwei Begriffe zugeordnet werden: "Safety" und "Security". "Safety", im folgenden mit "Stabilität" bezeichnet, meint die Resistenz eines Datenverarbeitungssystems (Computer, Mitarbeiter, Fahrzeuge etc.) gegen "natürliche" Einflüsse, denen kein gezieltes Handeln zugrundeliegt (Feuer, Fehleingaben etc.). "Security" hingegen bezeichnet den Schutz gegen gezielte, geplante Angriffe auf das System, die die Existenz eines menschlichen Angreifers voraussetzen. Die beiden Typen beeinflussen einander natürlich: Ein Zusammenbruch durch mangelnde Stabilität eröffnet neue Schwachstellen für einen Angreifer, und dessen Aktivität wiederum kann die Stabilität entscheidend verringern.

Ein entscheidender Unterschied zwischen den beiden Typen liegt darin, daß nach einem Vorfall die Wahrscheinlichkeit eines erneuten Auftretens in Sinne von Stabilität gleich bleibt (d.h. die Vorfälle stochastisches Verhalten zeigen), während sie im Sicherheitskontext zunimmt, da ein einmal gefundenes Sicherheitsloch schnell bekannt und dann häufig ausgenutzt wird.

Ein großes Problem besteht darin, eine mathematische Definition von Sicherheit zu finden, da Sicherheit keine Eigenschaft ist, die dadurch gegeben ist, daß sie für einzelne Komponenten eines Systems erfüllt ist. Sowohl ein induktives als auch ein deduktives Vorgehen ("Bottom up" und "top down") sind somit schwierig, da man eine sichere Spezifikation in ein unsicheres System "verfeinern" kann und eine Prozedur, die zwei sichere Unterprozeduren aufruft nicht selbst sicher sein muß. Daher wird anstatt von "Sicherheit" häufig der Begriff "Vertrauen" ("Trust") verwendet, da dieser quantifizierbar und daher mathematischen Operationen zugänglicher ist (s. vgl. [SIM93]).

3.2. Verschiedene Stufen der Spezifikation

Grundlage aller Spezifikationen ist die sogenannte Sicherheitspolice (oder Sicherheitspolitik, "Policy"). In der Literatur finden sich mehrere verschiedene Definitionen dieses Begriffes. Die wohl allgemeinste wird in [NRC90] gegeben: "Eine Sicherheitspolice ist eine kompakte Aussage derjenigen, die für das System verantwortlich sind, bezüglich des Wertes der Informationen, Verantwortlichkeiten für Schutzmechanismen und organisatorischen Pflichten". Einige Kapitel später findet sich, mehr auf konkrete Computeranlagen bezogen die Definition "informale Spezifikation der Regeln, gemäß denen bestimmten Personen Zugriffsrechte auf ein Computersystem gewährt werden, um Informationen zu lesen, zu schreiben oder Ressourcen zu verwenden "1. [RUS91] definiert (weniger allgemein) eine Police als "die Menge von Regeln und Praktiken, die regulieren, wie eine Organisation gefährdete Daten verwaltet, schützt und verteilt." Die genauen, aus der Police abgeleiteten Anforderungen an ein Sicherheitssystem werden zunächst natürlichsprachig in der sogenannten "Beschreibenden Hauptspezifikation" ("Descriptive Top-Level Spefication", DTLS) bestimmt. Insbesondere wird darin auch der zu sichernde Bereich ("security-perimeter" , "security zone") festgelegt.

Hieraus können dann sog. Sicherheitsmodelle abgeleitet werden. Diese unterscheiden sich von der Police dadurch, daß sie sich nur noch auf die Sicherheitsmechanismen - d.h. in erster Linie auf den Computer - beziehen und bereits so formal sind, daß sich ein mathematischer Sicherheitsbeweis daraus ableiten läßt. Diesen Prozeß der weiteren Verfeinerung der Spezifikationen bezeichnet man als "Refinement".

Bei Systemen mit höheren Sicherheitsanforderungen wird zudem verlangt, daß aus der DTLS und dem Modell eine "Formelle Hauptspezifikation" ("Formal Top-Level Specification", FTLS) erstellt wird, die dann als Basis der Implementierung fungieren kann.

Das Endprodukt wird allgemein als "Automatische Informationsverarbeitungsanlage" ("automated information system", AIS) bezeichnet.

4. Ziele der Sicherheitsbestrebungen

Das Ziel jeglicher Art von Sicherheitsvorkehrungen ist es, die Existenz einer Bedrohung ("Threat") eines Systems für den Benutzer transparent werden zu lassen (wie z.B. das "Paging" bei der Speicherverwaltung). D.h. der Anwender soll nicht feststellen müssen, daß ihm in irgendeiner Weise Schaden zugefügt wurde, und - was antagonistisch zu ersterem ist - aber auch nicht, daß er davor bewahrt wurde. Die konkreten Ziele lassen sich daraus ableiten: Schutz vor Diebstahl (Geheimhaltung), Schutz vor Manipulation (Integrität), keine Störung des Betriebsablaufes (Verfü gbarkeit), keine Beeinträchtigung durch die Sicherheitsmaßnahmen (Ergonomie); um dennoch aufgetretene Schäden zu begrenzen: Nachweisbarkeit. Die konkreten Gewichtungen der einzelnen Gebiete sind anwendungsspezifisch. Ein System, das ein Flugzeug steuert, bedarf eher einer starken Verfügbarkeit (nie ausfallen), während ein System zur Verwaltung von Forschungsdaten hin und wieder ausfallen darf, aber die Geheimhaltung unbedingt gesichert bleiben muß.

4.1. Geheimhaltung

Unter Geheimhaltung ("Confidentiality") versteht man den Ausschluß bestimmter Personengruppen von der Semantik einer Information. D.h. Mitglieder dieser Gruppen dürfen durchaus Zugriff auf diese Daten haben, solange ihnen deren Sinn verschlossen bleibt (z.B. da diese verschlüsselt sind, oder in irrelevante Daten eingebettet wurden ("concealment system")). Andererseits muß aber auch dafür gesorgt werden, daß ein Angreifer nicht Informationen aus vermeintlich unwichtigen Daten (z.B. Statistiken) erschließen kann. Im Ausmaß des Verlangens nach Geheimhaltung äußert sich der Wert der Information. Nach diesen richten sich aber auch der Aufwand, den ein daran interessierter Ausgeschlossener, also ein Angreifer ("Intruder"), betreiben wird, um in Besitz der Information zu gelangen, und somit die Kosten die entstehen, will man den Aufwand, der zum Erlangen dieser Informationen notwendig ist, über dieses Maß heben. Eine Möglichkeit, diese gering zu halten, ist es die Gesamtinformation nach ihrer Wichtigkeit in Sicherheitsklassen einzuteilen, die dann gemäß ihrem Wert geschützt werden, so daß kein Aufwand darauf verwendet wird, unwichtige Informationen geheimzuhalten. Diese Sicherheitsklassen können dann z.B. durch eine einfache lineare Einteilung charakterisiert werden (unwichtig, geheim, streng geheim), aber auch durch Inklusionsordnungen ("Forschung" + "Marketing" ist wertvoller als "Forschung" oder "Marketing" alleine).

Die Geheimhaltung kann nochmals verschiedene Ausprägungen haben: Diese unterscheidet man nach der Form der Reaktion auf eine Anfrage bezüglich der spezifischen Daten: Man kann durch eine Ablehnung des Zugriffs zu erkennen geben, daß die entsprechende Information tatsächlich existiert, kann durch eine allgemeine Fehlermeldung keinerlei Auskunft darüber geben oder die Existenz der Daten abstreiten.

In den Bereich der Geheimhaltung fällt aber auch der Schutz persö nlichkeitsbezogener Daten ("Privacy"). Die diesbezüglichen Ziele sind z.B. in den USA staatlich vorgegeben und nochmals unterteilt:2 "Offenheit": Es darf keine nicht öffentlich bekannten Computersysteme geben, in denen Individualdaten gespeichert werden.

"individueller Zugriff, individuelle Mitbestimmung": Jeder darf alle über ihn gespeicherten Daten einsehen, kopieren und korrigieren.

"Umfangssbeschränkung": Eine Organisation darf nur im Rahmen ihres Bedarfes Informationen über Personen speichern.

"Beschränkung von Gebrauch und Veröffentlichung"

"Haftung": die Organisation verpflichtet sich, die allgemeinen Prinzipen der Sicherheit anzuwenden und haftet für auftretende Mißbräuche.

4.2. Integrität

Die Integrität (Unberührtheit, "Integrity") von Daten meint, daß diese vorher definierten Qualitätsanforderungen genügen. Im Sinne von Sicherheit ist die Integrität einer Information ist gegeben, wenn sichergestellt werden kann, daß diese vom ausgewiesenen Autor erzeugt wurde, und dessen Intention entspricht. Das Ziel von Manipulationen, die die Integrität einer Information zu beeinträchtigen versuchen, ist es, denjenigen, der die Information empfängt, zu Handlungen zu veranlassen, die im Sinne des Angreifers, aber nicht des Angegriffenen sind (z.B. eine Überweisung). Um die Integrität gewährleisten zu können, werden Prüfsummen, Einwegfunktionen und asymmetrische Verschlüsselungsverfahren verwandt. Im Sinne von Stabilität soll verhindert werden, daß Fehleingaben oder Übertragungsfehler die Informationen verfälschen. Hier bieten sich fehlerkorrigierende Kodierungsverfahren (Hamming-Code o. ä.) und Konsistenzprüfungen (s.u.) an. Somit zählen aber auch z.B. Rundungsfehler von Fließkommaoperationen zu den Problemen, mit denen sich diese Richtung beschäftigt. Integrität wird insbesondere dort zum Problem, wo mit verteilten Datenbeständen gearbeitet wird, z.B. in Datenbanken mit Mehrbenutzerbetrieb, in denen die Synchronisation gewährleistet und das gleichzeitige Benutzen derselben Bestände unterbunden werden muß.

4.3. Nachweisbarkeit

Die obigen Überlegungen gehen immer davon aus, daß alle berechtigten Personen im Sinne der Sicherheit zusammenarbeiten. Dies ist aber meist nicht der Fall. Im Gegenteil geht der überwiegende Teil der Verstöße gegen die Sicherheitspolice von autorisiertem Personal aus. Ziel ist es also, diese Manipulationen zu entdecken, zu korrigieren und eindeutig dem Urheber zuzuordnen, so daß dieser auf juristischem Wege dafür zur Verantwortung gezogen werden kann ("Accountability"). Nachweisbarkeit wird durch Beobachten der Benutzeraktivitäten erzielt (s. dort).

4.4. Verfügbarkeit

Verfügbarkeit ("Availibility") meint die Tatsache, daß berechtigten Personen die ihnen zugänglichen Daten und Ressourcen schnell und zuverlä ssig zur Verfügung stehen. Ist dies nicht der Fall, spricht man von "denial of service". Dieser Wunsch ist den ersten dreien entgegengesetzt ausgerichtet, denn ein vollkommen abgeschlossenes System, das mit niemandem kommuniziert ist, das sicherste System überhaupt. Im Sinne von Stabilität meint Verfügbarkeit, daß im Normalbetrieb die Anlagen eine bestimmte, in der Police festgelegte Ausfallrate nicht überschreiten soll. Im Sicherheitskontext meint dieser Begriff, daß nach einer erfolgten Attacke auf das System der Normalbetrieb möglichst schnell wieder hergestellt wird, bzw. das System erst gar nicht ausfällt.

4.5. Ergonomie

Im engen Zusammenhang mit der Verfügbarkeit ist die Ergonomie (Benutzerfreundlichkeit, "operational ease") zu sehen. Ist das System nicht verwendbar, da der Aufwand, der von den Benutzern für die Sicherheit erbracht werden muß, zu hoch ist (dauert es z.B. eine Stunde eine oft benutzte Tür zu öffnen), so werden auch vertrauenswürdige Benutzer anfangen, die Sicherheitsmechanismen außer Kraft zu setzen (die Türe nicht schließen). Es ist klar, daß zufällig erzeugte Passworte eine höhere Sicherheit aufweisen als vom Benutzer gewählte. Diese haben aber den Nachteil, daß sie meist nicht zu memorieren sind, der Benutzer sie also irgendwann notiert und somit ein unsicherer Zustand erreicht wird, als er mit wählbaren Passworten gegeben gewesen wäre. Daher stellt mangelnde Ergonomie nicht nur eine Verringerung der Verfügbarkeit, sondern auch der allgemeinen Sicherheit und Stabilität dar.

5. Risikoanalyse

Voraussetzung für eine erfolgreiche Sicherung ist es zunächst, Klarheit darüber zu gewinnen, auf welchen Gebieten die größte Gefährdung besteht. Diese ergibt sich sowohl aus dem jeweils möglichen Schaden, als auch aus der Wahrscheinlichkeit seines Eintritts.

5.1. Bedrohungsformen und Sicherheitslücken

Der folgende Abschnitt zielt nicht darauf, detailliert Angriffsmö glichkeiten und Lücken zu beschreiben. Vielmehr soll nur eine generelle Vorstellung davon erzeugt werden, was ein Angreifer will, um die Formen der Schutzmechanismen verständlich zu machen.

5.1.1. Angriffsziele und Angriffsvarianten

Die Ziele des Angreifers ("intruders") korrespondieren direkt mit den Zielen der Sicherheit: Ein Unterlaufen der Geheimhaltung kann versucht werden, indem Datenübertragungskanäle abgehört werden ("Sniffer-Attack",s.u.), indem elektromagnetische Emissionen aufgespürt oder indem Daten herunterklassifiziert werden.

Die Verfügbarkeit kann durch den Einbau von Programmfehlern, das Einschmuggeln von Viren oder die Zerstörung von Hardware bewirkt werden. Um die Integrität zu unterlaufen wird häufig versucht, sich dem System als eine andere Person zu präsentieren, also eine Scheinidentität anzunehmen. Dieses Vorgehen wird als "Spoofing", "Masquerading" oder "Mimicricking" bezeichnet.

Derartige Angriffe ("Attacks", "Hacking") werden häufig auch kombiniert angewandt. Man unterscheidet zwischen "aktiven" und "passiven" Attacken. Letztere bestehen im reinen Abhören von Datenübertragungen. Den Zustand einer Bedrohung, ohne daß ein tatsächlicher Angriff erfolgt, bezeichnet man als "threat". Einen erfolgreichen Angriff bezeichnet man auch als Kompromitierung ("compromise","penetration"). Des weiteren kann der Angreifer versuchen, den Computer als Hilfsmittel für ein sonstiges Verbrechen zu mißbrauchen.

[HSI79] sehen als mögliche Angriffsziele: Störung (d.h. Unterbrechung ohne Beeinträchtigung der Daten), Diebstahl (lesen oder Kopieren), Veränderung und Zerstörung (Löschen).

5.1.2. Schwachstellen

Die Schwachstellen ("Vulnerabilities") eines Systems werden klassifiziert nach dem Bereich, in dem sie auftreten können: physikalische Schwächen, Medienschwächen u. ä.3, und die Gesamtsicherheit richtet sich nach der größ ten Schwachstelle. Das Problem ist, daß derartige Schwachstellen nicht unbedingt innerhalb des "Perimeters" liegen müssen, sondern z.B. auch in eng verbundenen anderen Organisationen zu finden sind. Die Kosten, die diese für ihre Sicherheit nicht aufbringen, werden somit auf die angeschlossenen Systeme verlagert. Bietet beispielsweise ein Forschungsinstitut einer Universität eine enge Verbindung an, so muß es zusätzliche Ausgaben einkalkulieren, um sich gegenüber dem oft weniger gesicherten Universitätsnetz zu schützen.

5.2. Klassifizierung von Systemtypen

Das "dark green Book" des DoD unterscheidet verschiedene "modes of operation"4:

"Dedicated Mode": Jeder Benutzer, der irgendwie mit dem System Kontakt aufnehmen kann, ist berechtigt, alle Informationen einzusehen, die in dem System gespeichert werden, besitzt sämtliche Zugriffsrechte und muß auch im Rahmen seines Auftrages mit all diesen Daten arbeiten.

"System High Mode": Dieser Modus unterscheidet sich von dem vorangegangenen dadurch, daß nicht jeder Benutzer alle Daten tatsächlich benötigt.

"Compartmented Mode": Alle Benutzer sind zwar für die höchste Sicherheitsstufe zugelassen, haben aber nur Zugang zu den Daten, die sie wirklich benötigen.

"Multilevel Mode": Es gibt Personen, die nicht für alle Sicherheitsklassen zugelassen sind. Alle haben nur Zugang zu den Daten, die sie wirklich benö tigen.

Hsiao et alt. [HSI79] klassifizieren nach:

1) "geschlossen" (identisch mit "compartment mode"): "Nur eine kleine Anzahl von Operatoren haben direkten Zugriff auf den Rechner. " Jeder Prozeß wird von einem Operator überwacht.

2) "offen" (ähnlich dem Multilevel Mode) im Prinzip hat jeder Zugang, muß aber dazu persönlich ins Rechenzentrum kommen.

3.)"unbegrenzt". "Unbegrenzt" bedeutet, daß jede Person über öffentliche Telephonleitungen Kontakt zum System aufnehmen kann und im Prinzip niemals das Rechenzentrum betreten muß.

5.3. Analyse des Gesamtrisikos

Die normale Methode, um das Gesamtrisiko abzuschätzen, ist recht einfach: Man multipliziert die Wahrscheinlichkeit, daß ein bestimmter Fall eintritt, mit dem Schaden, den dies verursachen würde und bildet die Summe über all diese Produkte (Erwartungswert). Die Erfahrung zeigt allerdings, daß die so gewonnenen Schätzungen im allgemeinen zu positiv sind, da das Eintreten eines Schadens häufig mehrere andere mit sich bringt (d.h. die Wahrscheinlichkeiten nicht unabhängig sind). Dieser Wert ist aber nicht allein entscheidend für das Ausmaß an Sicherheitsvorkehrungen. So. z.B. wird selbst bei hohem Gesamtrisiko keine Schutzmaßnahme getroffen werden, deren Kosten den Wert des zu schützenden Objektes übersteigen. Des weiteren kann die Information für die verschiedenen Beteiligten von unterschiedlichem Wert sein. Man muß hier auß er dem Wert für den Besitzer ("keeper", Halter) und den Angreifer, auch den Wert für den Erzeuger ("source") berücksichtigen. Hsiao et alt. [HSI79] Unterscheiden hier zwischen

- Kritischer Arbeitsinformation z.B. Schichtpläne haben für den Besitzer einen höheren Wert als für den Erzeuger oder Eindringling.

- Persönliche Daten haben für die Quelle höheren Wert als für den Halter oder Eindringling

- Vorbereitende Informationen, z.B. Verkaufsvoraussagen haben für den Eindringling einen höheren Wert als für den Besitzer oder Erzeuger, da diese z.B. die Analyse der Daten bereits abgeschlossen haben könnten.

6. Methoden des Schutzes ("countermeasures")

6.1. Das Umfeld

Es ist natürlich nicht ausreichend, ein sicheres System zu designen, um es dann in einer vollkommen unsicheren Umgebung einzusetzen. Es muß also dafü r gesorgt werden, daß die Sorgfalt bei der Anwendung dem Sicherheitsniveau der Computeranlage adäquat ist.

6.1.1. Andere Bestandteile der Policen

Die nicht rechnerbezogenen Vorschriften zur Sicherheit des Systems sind nicht Bestandteil der "DTLS" und in den Sicherheitsmodellen nicht mehr auf, sie sind nur in der Police festgelegt. Dies sind diejenigen Regeln, an die sich die Benutzer des Systems zu halten haben, die aber nicht im Rahmen der Programmierung erzwungen werden können ("administrative security").

6.1.1.1. Aufteilung der Verantwortlichkeiten

Gegenüber den anderen Sicherheitssystemen treten im Computerbereich drei neue Aufgabenfelder hervor, die überwiegend von Personen besetzt werden, die nichts mit dem übrigen Firmengeschehen zu tun haben: Der Administrator, der Operator und der Systemprogrammierer. Konnte bisher beispielsweise ein Ingenieur, der ein Gerät erfindet, sicher sein, daß seine Pläne in seinem Safe sicher sind, kann er das von seinem Computer nicht mehr sagen. Er ist abhängig von den drei obengenannten. Wie schon aus herkömmlichen Sicherheitssystemen bekannt, empfiehlt es sich, daß nicht eine einzelne Person die unumschränkte Kontrolle über das System erhält. Insbesondere sollten die Funktionen von Administrator, Operator und Programmierer getrennt sein. Im Idealfall ist jede der drei Personen nicht für die Arbeit der anderen qualifiziert (Was häufig nicht der Fall ist, da die Karriereleiter üblicherweise vom Operator zum Systemprogrammierer führt.). Der kritischste Posten hierbei ist der des Systemprogrammierers, da sein Tä tigkeitsfeld teilweise in Bereichen liegt, die nicht durch Beobachtung (s. d.) kontrolliert werden können. Die Aktionen von Administrator und Operator hingegen können beobachtet und die so gewonnenen Daten auf nur beschreibbare Medien gespeichert werden, um ein Löschen unmöglich zu machen. Im militärischen Bereich kommt häufig noch ein "Sicherheitsoffizier" hinzu, dessen Berufsbild allerdings in ähnlicher Form bereits vor Einfü hrung von Computeranlagen existiert hat.

6.1.1.2. Ausbildung der Benutzer

Relativ häufig geht dem eigentlichen Angriff ein sog. "Social-Hack" voraus, d.h. der Angreifer versucht, die Benutzter des Systems zu ungewö hnlichen Aktionen zu verleiten, z.B. indem er am Telephon einen Anwender simuliert, der angeblich sein Passwort vergessen hat. Andererseits muß jeder Benutzer darauf achten, daß die Sicherheit durch ihn nicht beeinträ chtigt wird, und mithelfen, das System zu beobachten, da eine vollkommene Überwachung durch die Administration zumeist nicht möglich ist. Des weiteren muß er sich der Tatsache bewußt sein, daß er Passwörter oder systeminterne Informationen (IP-Adressen usw.) nicht an Dritte weitergeben darf. Daher gehört eine Schulung der Angestellten zu den unbedingt notwendigen Vorkehrungen.

6.1.2.

Physikalischer Schutz Im Sinne von Stabilität meint "physikalischer Schutz" Maßnahmen gegen Brand, Wasserschäden und ähnliches. Im Sinne von Sicherheit meint es die grundlegendste Art der Zugangskontrolle:

6.1.2.1.

Schutz des Rechners Jegliche Abschirmung des Systems wird illusorisch, wenn ein Angreifer Zugang zur Hardware erhält und beispielsweise ganze Steckkarten einfach austauschen kann. Hier greifen sämtliche Sicherheitsmechanismen, die seit jeher bei Banken, Gefängnissen o.ä. verwendet werden.

Andererseits muß aber auch verhindert werden, daß die vom Rechner oder Bildschirm ausgehende Strahlung erfaßt werden kann. Derartige rein physikalische Informationsflüsse bezeichnet man als Emissionen ("emanations"), solche, die kritische Information tragen, als kompromittierende Emissionen.

Ebenfalls zu den physikalischen Problemen zählt die "Remanenz" (lat. "remanere" = Zurückbleiben) von Informationen auf vermeintlich gelöschten Speichermedien, da z.B. häufig nur Verzeichnisse, nicht aber die Daten selbst beseitigt werden. Das vollständige Löschen derartiger Daten (z.B. durch Zerstörung des Mediums) bezeichnet man als "Sanitizing". Zu den Vorkehrungen im Sinne von Stabilität zählen Sprinkleranlagen, Spannungsfilter usw.

6.1.2.2. Datentransport

Einen sicheren Datenübertragungsweg bezeichnet man als "sicheren Kanal" ("secure channel, overt channel"), wobei mit "Kanal" jeder Weg gemeint ist, über den zwei oder mehr Systemkomponenten kommunizieren können5. In den meisten Fällen kann die Sicherheit durch Verschlüsselung (s. dort) gewä hrleistet werden. Ist aber ein expliziter physikalischer Schutz gefordert, so wird häufig ein Kabel mit einer elektrischen Abschirmung verwendet, so daß man einen Einschnitt nachweisen kann. Die exotischste (und wohl sicherste) Variante besteht darin, das Kabel in ein Rohr zu legen, das man unter hohen Druck setzt, so daß man einen Angriff mit einem Druckmesser nachweisen kann6. Bei Netzwerken tritt häufig das Problem auf, das sä mtliche angeschlossene Rechner auf jede Datenübertragung zugreifen können (da sie z.B. am selben Bus angeschlossen sind). D.h es ist keinerlei physikalische Abschirmung eines konkreten Kanals möglich, ohne das gesamte Netzwerk lahmzulegen.

6.2. Modelle und Hilfsmittel

Es stellt sich nun die Frage, wie die definierten Ziele erreicht werden kö nnen. Hierzu soll zunächst auf eine Auswahl verbreiteter Sicherheitsmodelle eingegangen werden, d.h. diejenigen, die (laut [RUS91]) im sog. "Orange Book"7 des DoD erwähnt werden. Im Anschluß daran werden die in der Literatur angesprochenen Hilfsmittel ("Services") vorgestellt, die die jeweiligen Modelle unterstützen.

6.2.1. Zugriffskontrolle

Das Zugriffskontrolle-Modell postuliert, an jeden Zugang ein Kontrollsystem zu stellen, das nur autorisierten Personen Zutritt gewährt. Hierbei bezeichnet man mit "granularity" die "Größe" der einzelnen Objekte, die ein Kontrollsystem erhalten (z.B. Datei oder Ordner). Derjenige der Zugriff hat, kann dann die Information zumeist beliebig, d.h. auch an Komponenten mit geringerer Sicherheitsstufe (s. vgl. 6.2.2), weiterleiten. Diese Eigenschaft charakterisiert eine sogenannte "discretionary access control" (DAC). Dieses Modell ist als Teilmodell im Flußmodell (s.u.) enthalten und wird durch den Vorgang der "Autorisierung" umgesetzt.8

6.2.2. Das Flußmodell

Das Flußmodell geht von einer Einteilung der Verarbeitungseinheiten in Sicherheitsklassen aus. Eine Information darf immer nur von einer niedrigeren zu einer vergleichbar höheren Sicherheitsklasse fließen. D.h. der Informationsfluß kann Fluß auf einem azyklischen, gerichteten Graph modelliert werden. Die Sicherheitsklasse einer Information ergibt sich dann aus der Klasse ("clearance") des letzten Bearbeiters. Am "oberen Ende"9 muß es dann Einrichtungen geben, die in der Lage sind, Informationen wieder herunterzuklassifizieren, wenn diese ihren Wert verloren haben, diese sind jedoch nicht Bestandteil des Modells. Die diesem zugrundeliegende Vorstellung wird auch als das "Bell- LaPadula"-Modell10 bezeichnet. Ein solches Kontrollsystem, in dem die Benutzer das Sicherheitslevel der ihnen zugänglichen Informationen nicht ä ndern können, bezeichnet man als "mandatory access control". Dieses Vorgehen richtet sich gegen das Problem der "Kontaminierung", der "Verseuchung" niedrig klassifizierter Daten durch höher klassifizierte.11 Es ist allerdings selten möglich, den Informationsfluß nach unten vollkommen auszuschließen. D.h. es ist meistens im informationstheoretischen Sinne eine Übertragungsmöglichkeit gegeben, mit der ein Sender einem Empfänger Mitteilungen machen kann. Eine solche nicht gewünschte Verbindung nennt man verdeckten Kanal "covert channel". Es ist letztlich ein gewöhnlicher Datenkanal, nur unterliegt er nicht den Regeln der Police. Derartige verdeckte Kanäle können im gemeinsamen Speicher zweier Prozesse liegen ("covert storage channel") oder durch Modulation des Ressourcenverbrauchs (z.B. durch regelmäßige Buszugriffe) erzielt werden ("covert timing channel"). Sogar im RSA-Signatursystem konnte ein verdeckter Kanal aufgespürt und (prinzipiell) geschlossen werden12: das System sieht vor, einen Parameter zufällig zu wählen; wählt man diesen gezielt, kann man damit Botschaften übertragen, deren Existenz nicht nachgewiesen werden kann.

6.2.3. Authentifizierung

Unter Authentifizierung ("Authentification") versteht man die Zuordnung von Operationen zu ihren Urhebern. Dies ist eine wesentliche Voraussetzung sowohl für die Nachweisbarkeit, als auch für die Mechanismen der Zugriffskontrolle.

Um die einzelnen Komponenten ("Principals") eines Systems richtig behandeln zu können, muß zunächst deren Identität eindeutig festgestellt, und ihnen dann der entsprechende, sie betreffende Datensatz zugeordnet werden. Hierzu muß das System jeder Komponente zunächst einen eindeutigen Namen zuordnen. Diese Zuordnung muß

- vollständig sein, d.h. es gibt keine unbenannten Objekte, da es ansonsten nicht möglich ist, diesen irgendwelche Rechte einzuräumen oder Beschränkungen aufzuerlegen.

- eindeutig sein, d.h. zwei unterschiedlichen Komponenten müssen unterschiedliche Namen zugeordnet werden, auch wenn diese die selbe Funktion wahrnehmen.

- sicher sein, d.h. es muß klar sein, auf Basis welcher anderer Authentifikationen (z.B. Operator) diese zustandegekommen ist.13

Die Zuordnung von Namen zu Komponenten muß aber nicht injektiv sein. Eine Komponente kann durchaus mehrere Namen haben; einen solchen weiteren Namen bezeichnet man dann als Rolle. Z.B. wird im Normalfall der Systemadministrator sowohl eine "mächtige", als auch eine "normale" Rolle haben, wobei er durch Verwenden der "normalen" Rolle dafür sorgt, daß er nicht versehentlich größeren Schaden anrichtet. Das Wort "Authentifizierung" wird häufig auch benutzt, um den Prozeß des Nachweisens der Integrität zu bezeichnen.

6.2.3.1. Identifikation von Personen

Ein Mensch kann entweder anhand äußerlicher Eigenschaften (Fingerabdrücke, Augenhintergrund etc.,"biometrics"), oder anhand ihm übergebener Identifikationshilfen, die sowohl materiell (Magnetkarte), als auch immateriell sein können (Wissen um ein Passwort), identifiziert werden. Letzteres hat den Nachteil, daß er diese Identifikationshilfen verlieren, weitergeben und duplizieren kann, wobei es im Falle von immateriellen Merkmalen noch nicht einmal von ihm selbst bemerkt werden muß. Hinzu kommt, daß die Übertragung eines Passwortes von dritten beobachtet werden kann. Dafür sind bei diesem Verfahren die Anforderungen an das Terminal deutlich geringer.

6.2.3.2. Identifikation anderer Computer

Ist der Benutzer nicht in der Installation selbst zugegen, sondern befindet sich an einem entfernten Terminal, oder versucht ein Computer Kontakt zum System aufzunehmen, so muß das Terminal oder der Computer identifiziert werden, da diese ansonsten falsche Informationen über die Person, die sie bedient oder beauftragt hat, übermitteln oder deren Befehle verfälschen könnten. Im Gegensatz zur Identifikation von Personen kann hier nur die im anfragenden Rechner vorhandene Information zur Überprü fung verwandt werden. Dafür machten es die höhere Datenübertragungsrate und die numerischen Fähigkeiten des Computers möglich, beispielsweise das Wissen um einen Codeschlüssel abzufragen, ohne daß dieser selbst ü bertragen werden muß ("Challenge-Response-Verfahren). Hierzu wird vom "Herausforderer" eine zufällige Zeichenkette generiert und an den Kommunikationspartner geschickt. Dieser verschlüsselt diese dann mit einem asymmetrischen Schlüssel (s. unten) und sendet das Ergebnis zurück, dies wird dann vom Ursprungsrechner dekodiert und mit dem Ursprungstext verglichen. Eine andere Möglichkeit stellt die "Authentifizierung durch Rü ckruf" ("Call-Back-Authentification") dar. Hier wird die Verbindung zunä chst abgebrochen und das anfragende System zurückgerufen. Im Fall von "Spoofing" erhält der Angreifer also keine Verbindung, solange er nicht in der Lage ist, den Rückruf umzuleiten.

6.2.4. Autorisierung

Nachdem nun der Teilnehmer eindeutig bestimmt ist, kann er anfangen, im System zu arbeiten. Dieses muß nun darauf achten, daß er seine Kompetenzen nicht überschreitet. D.h. die der Autorisierung zugrundeliegende Vorstellung entspricht weitgehend der der Zugriffskontrolle. Hierzu müssen Relationen zwischen aktiven und passiven Bestandteilen des Systems hergestellt werden.

6.2.4.1. Subjekte und Objekte

Man teilt die beteiligten Einheiten, die "Principals", zunächst in eine Gruppe von Subjekten und Objekten. Dabei kann ein "Principal" zu verschiedenen Zeitpunkten durchaus beide Rollen einnehmen. Wird der Code eines Programms geändert, so ist es ein Objekt. Verändert das Programm eine Datenbank, so ist es ein Subjekt.14 Eigentlich müßte nun jedem Tupel von Objekt, Subjekt, Operation, Zeitpunkt, verwendetem Terminal, Grund der Anfrage etc. d.h. fast jedem Systemzustand eine Information zugeordent werden, ob das Subjekt auf dem Opjekt die Operation ausführen darf oder nicht.15 Die Relation wird zumeist hergestellt, indem man entweder den Subjekten eine Menge von Rechten, oder Objekten eine Menge von Zugriffsmö glichkeiten ("Access Control List") zuordnet. Meist ist es möglich, die Subjekte und Objekte nochmals in Gruppen zusammenzufassen, um den Aufwand, diese Realetionen zu ermitteln, weiter zu senken. Hsiao et alt. [HSI79] differenzieren hier zwischen spezifischen Dokumenten (d.h. Nr. 12345), Rollen (Bücherliste o.ä.) und funktionsbezogenen Zusammenhängen. Meistens ist es möglich, daß ein Subjekt zeitweilig die Rechte eines anderen übertragen bekommen kann, bzw. mit eigenen Rechten für ein anderes eine Aufgabe ausführt16. Dies bietet einerseits die Möglichkeit, unterprivilegierten Benutzern eingeschränkten Zugriff auf höher klassifizierte Daten zu gewähren, wie z.B. das Ändern des eigenen Passwortes, das üblicherweise in einer Datei steht, auf die ein normaler Benutzer nicht zugreifen darf. Andererseits ist es möglich vergleichbar zu den Rollen bei Principals einzelne Programme mit geringeren Rechten auszustatten, als sie ihr Besitzer oder Aufrufer hat. Ein solches nicht menschliches Subjekt mit geringen Rechten bezeichnet man auch als geschü tztes Subsystem.

Es gibt viele Möglichkeiten, auf Versuche, gegen die vorgegebenen Relationen zu verstoßen, zu reagieren: Eine direkte Meldung an den Operator, Verweigerung der Operation und - was in höherentwickelten Datenbanken häufiger gegeben ist- eine Modifikation des verstoßenden Befehls ("query modification"). D.h. z.B. daß bei Zugriffsversuchen auf geschützte Datenbestände diejenigen Daten ausgegeben werden, deren Einsicht im gegebenen Kontext unkritisch ist, während die anderen zurü ckgehalten werden.

6.2.4.2. Kontrolle der Autorisierung

Derjenige Datensatz (bzw. diejenige Datenbank), in dem die Rechte, bzw. Zugriffsmöglichkeiten gespeichert werden, ist natürlich wenigstens so wichtig, wie die wichtigste Information des Gesamtsystems, da durch seine Manipulation Zugriff zu dieser erlangt werden kann. Hieraus erwächst für kleinere Anlagen die Schlußfolgerung, daß nur der Administrator Zugriff auf diese Datei haben darf. In größeren Systemen ist dies aber unmöglich. Hier muß der jeweilige Abteilungsleiter vom Management beauftragt und autorisiert werden, diese Aufgabe zu übernehmen. Dies impliziert aber, daß nun zusätzlich die einzelnen Abteilungen gegeneinander abgeschirmt werden müssen, da z.B. gleichlautende Namen in verschiedenen Abteilungen auftreten können. [HSI79] klassifizieren die unterschiedlichen Mö glichkeiten, die Autorisierung vorzunehmen:

1. Zentralisiert: Eine Einzelperson oder gesonderte Abteilung übernimmt die Steuerung.

2. Hierarchisch dezentralisiert: Rechte können von der zentrale in Untereinheiten ausgelagert werden

3. Individuell: der Erzeuger einer Information vergibt deren Zugriffsrechte. Diese Variante erlaubt es innerhalb der Organisation private Daten zu speichern, auf die auch der Systemadministrator nicht zugreifen kann.

6.2.5. Präventive Beobachtung

Es kann natürlich nicht ausreichen, ein Sicherheitssystem einmal zu installieren, und sich dann darauf zu verlassen, daß dies einwandfrei funktioniert. Vielmehr muß aktiv nach Angriffen gesucht werden, um die Schwachstellen zu beseitigen, die Folgen zu begrenzen, und die Urheber zur Verantwortung zu ziehen. Allgemein bezeichnet man das Einrichten von Fallen, mit denen man einen Eindringling finden will, als "entrappment".

6.2.5.1. Protokollierung

Die einfachste Form von Beobachtung ist es, sämtliche Datenströme zu duplizieren ("Auditing", "automated security monitoring"), und die so gewonnen Daten in einen nur den Sicherheitskräften zugänglichen Bereich zu kopieren. Somit lassen sich im Nachhinein jede Fehleingabe, aber auch jeder Angriffsversuch feststellen und somit geeignete Gegenmaßnahmen festlegen. Das Problem ist, daß der Umfang der so gewonnenen Datenmengen meist viel zu groß ist, um diese effektiv nach Auffälligkeiten zu durchsuchen, und, sollten diese gefunden werden, der Vorfall meist schon zu lange zurückliegt. Hsiao et alt. [HSI79] führen als Funktionen den Auditings folgende Punkte an: Aufspürung von Eindringlingen, Nachverfolgen von Transaktionen (insbes. im finanziellen Bereich), die Verwendung von Auditing-Daten zur Rekonstruktion verlorener Datenbestände, Fehlerkorrektur und Abschreckung. Als Nebenprodukt erhält man häufig einen "History-Mechanismus" wie z.B. bei der tc-Shell.

6.2.5.2. Aktive Beobachtung

Eine wesentlich aufwendigere Variante von Beobachtung ist es, einen einzelnen Datenstrom gezielt von einem Angestellten oder Prozeß beobachten zu lassen ("Monitoring"). Aufgrund der großen Anzahl derartiger Verbindungen kann dies nur geschehen, wenn bereits ein konkreter Verdacht vorliegt. Hier wird besonders darauf geachtet, daß die Sicherheitsmechanismen nicht umgangen werden . Man kann z.B. ein scheinbares Sicherheitsloch ("pseudo-flaw") einbauen, dessen Benutzung ü berwacht werden kann. Eine weitere Möglichkeit besteht darin, Abstraktionen größerer Datenflüsse, die man z.B. statistisch erhalten kann zu beobachten, um allgemeine Tendenzen festzustellen, was außerdem auch zur Optimierung der normalen, nicht sicherheitskritischen Betriebsabläufe verwenden kann.

6.2.5.3. Konsistenzprüfung

Da es also unmöglich ist, alles von Menschen beobachten zu lassen, muß also eine rechnergestützte Variante gefunden werden. Neben Versuchen mit kü nstlicher Intelligenz17 haben werden hier insbesondere Konsistenzprüfungen angewandt. Wird z.B. an eine unbekannte Adresse viel Geld überwiesen, liegt der Verdacht nahe, daß eine policewidrige Handlung vorgenommen wurde. Allerdings scheinen selbst diese Überprüfungen angesichts der enormen Datenfluten zu aufwendig zu sein.

6.2.5.4. Probleme mit dem Datenschutz

Generell ist es so, daß der Schutz persönlicher Daten und die Sicherheitsbestrebungen einander zuwiderlaufen. Je mehr die Sicherheitsbeauftragten über die Benutzer wissen, desto eher können sie abschätzen wann jemand versuchen wird, die Sicherheitsbestimmungen zu umgehen.

Insbesondere "Auditing" ist aber dazu geeignet, jeden persönlichen Fehler am Rechner zu registrieren und sogar zur Leistungsbewertung heranzuziehen (wieviele Tippfehler pro Seite etc.) Im Sinne der Ergonomie ist es also empfehlenswert, dem Benutzer anzuzeigen, daß er beobachtet wird, und ihn zu informieren, welche Personen Zugriff auf die entsprechenden Dateien haben. Da derartige Einrichtungen die Arbeitsfreude des Personals senken, muß bei der Erstellung der Police also sorgfältig zwischen dem Ausmaß von Sicherheit und Datenschutz abgewogen werden.

Des weiteren ist es so, daß bei zentraler oder hierarchisch dezentraler Kontrolle der Autorisierung für den Angestellten keinerlei Möglichkeit bleibt, private Daten auf dem Rechner zu verwalten. Es ist dann beispielsweise nicht mehr möglich, daß ein Angestellter dadurch in der Firma aufsteigt, daß er eine Idee früher als sein Vorgesetzter hatte, da dieser dessen diesbezügliche Aufzeichnungen einsehen konnte.

6.2.6. Kontrolle der Ressourcen

Eng verbunden mit dem Problem der "Verfügbarkeit" ist das der Verteilung der Arbeitsleistung des Systems zu sehen. So ist dafür zu sorgen, daß untergeordnete Vorgänge die Rechnerkapazität nicht derart auslasten, daß fü r die wichtigen Dinge nicht mehr genügend Leistung zur Verfügung steht. Eine genaue Kontrolle der Verteilung kann zudem helfen Würmer (s. dort) abzuwehren. Eine Kontrolle darüber ob ein gewisses Programm verwendet wird, kann man wie eine Zugriffsberechtigung handhaben (entsprechend gibt es unter UNIX die Rechte lesen, schreiben und ausführen). Das Ausmaß der Benutzung läßt sich durch starre Schranken ("Quotas"), bzw. durch Vorgabe von Verhältnismäßigkeiten18 festlegen.

6.2.7. Kryptographie

Können die Daten vor dem Zugriff eines Angreifers nicht mit ausreichender Zuverlässigkeit gesichert werden, versucht man, diesem die darin enthaltene Information vorzuenthalten, indem man sie verschlüsselt. D.h. mittels eines invertierbaren Rechenverfahrens wird der Originaltext ("Plain Text") in einen Chiffretext umgewandelt, wobei das gesamte Rechenverfahren oder ein Teil davon ("Schlüssel","Key") geheimgehalten wird. Kann man aus dem Kodierungsverfahren das Dekodierungsverfahren herleiten, spricht man von einem symmetrischen Verfahren, ansonsten von einem asymmetrischen. Als eine absolut sichere Verschlüsselung bezeichnet man in diesem Zusammenhang Verfahren, bei denen sich das Wissen des Angreifers sowohl über den Inhalt, als auch über das Verschlü sselungsverfahren als solches durch das Abhören der verschlüsselten Daten nicht vergrößert. Durch die Bestrebungen, die Verwendung von Codes zu verbieten, hat sich zudem der Wunsch, die Tatsache der Verschlüsselung als solche zu verbergen, entwickelt. Dies wird z.B. erreicht, indem die Daten auf Bilder oder das Hintergrundrauschen einer Tondatei aufmoduliert werden. Diese Verfahren werden als steganographische Verfahren bezeichnet.

6.3. Folgenbegrenzung

Nach einem erfolgreichen Angriff gilt es, zunächst den Normalbetrieb mö glichst schnell wieder herzustellen und den Gewinn des Angreifers mö glichst zu verringern. Dies kann z.B. dadurch geschehen, daß die gesamte Computeranlage mehrfach vorhanden ist. Da der physikalische Schutz aber meist gegeben ist, genügt es, sich auf die Daten zu beschränken. Bei einem konkreten Rechner unterscheidet man zwischen "fail safe", d.h. der gesamte Arbeitsspeicher wird gesichert, und "fail soft", d.h. nur wichtige Bestä nde werden gerettet.

6.3.1. Sicherheitskopien

Hier unterscheidet man Systeme mit vollkommener und partieller Redundanz. Bei vollkommener Redundanz sind alle Daten auf jedem Computer vorhanden, und ein einzelnes Gerät kann auch dann noch betrieben werden, wenn alle anderen ausfallen. Hier tritt allerdings das Problem auf, diese alle zu synchronisieren. Bei partieller Redundanz werden die Sicherheitskopien eines Rechners auf verschieden andere verteilt. Dies impliziert einerseits weniger Verwaltungsaufwand, andererseits ist dieses System trotzdem noch arbeitsfähig, wenn eine beschränkte Anzahl von Computern ausfällt.

6.3.2. Nachweismethoden

Die letzte verbleibende Möglichkeit ist es, den Täter zu fassen und vor Gericht zu bringen. Hier bleibt allerdings nur noch die Möglichkeit, das Protokoll des Auditings, Videoaufzeichnungen o.ä. zu verwenden. Können die Aktionen einem Benutzer zugewiesen werden, ist dies meist kein Problem; wenn nicht, d.h. wenn die Authentifizierung umgangen wurde, können Eigenschaften wie z.B. der charakteristische Rhythmus der Tastaturbenutzung verwandt werden. Bei vielen Organisationen haftet zudem die Firma, die das Computersystem geliefert hat, mit.

6.4. Schwachstellen der beschriebenen Methoden

Ein Hauptproblem all dieser Verfahren ist es, daß durch ihre Anwendung neue Schwachstellen entstehen, und daß somit das System im Wechselspiel von Angriff und Verteidigung sozusagen einem evolutionären Prozeß unterworfen ist, was die Entwicklungskosten extrem vergrößert.

6.4.1. Schutz der Sicherheitskopien und Mitschnitte

Häufig ist es der Fall, daß der Sicherheit der Sicherheitskopien weniger Aufmerksamkeit geschenkt wird als der der Originale, was insbesondere im Sinne der Geheimhaltung ein großes Risiko darstellt. Häufig lassen sich aber auch aus den Daten des "Auditing" ganze Informationsbestände rekonstruieren, oder sogar Möglichkeiten (z.B. Passwörter) herausfiltern, die diversen Sicherheitsmechanismen zu umgehen. Daher müssen diese Daten zumindest dieselbe Klassifizierung erhalten, wie die am höchsten eingestuften auf diesem Wege angreifbaren Daten. Werden diese Kopien gelö scht, so müssen die verwendeten Medien vollkommen zerstört werden ("sanitisizing", s. vergleichend physikal. Sicherheit).

6.4.2. Notfallmechanismen

Ein großes Problem der beschriebenen Mechanismen ist ihre mangelnde Flexibilität in Bezug auf Notfälle. So kann es sein, daß ein Arzt auf Daten seiner Kollegen zugreifen können muß, wenn eine Notoperation ansteht. Es sollte also eine Möglichkeit geben, die es unter besonderen Umständen erlauben, die Sicherheitsmechanismen abzuschwächen. Dies wird hä ufig durch eine Schaltung im Rechnerraum ("Emergency Button") realisiert, die dann sämtliche Zugriffssperren lahmlegt. Es sollten allerdings nach einem solchen Vorfall alle auch nur indirekt beteiligten Parteien automatisch (d.h. vom Computersystem) darüber informiert werden.

7. Anforderungen an die Systementwicklung

Nachdem die Anforderungen nun beschrieben worden sind, stellt sich die Frage, welche Methoden verwandt werden müssen, um den rechnerbasierten Teil des Sicherheitssystems so zu implementieren, daß er seiner Spezifikation in der Police entspricht, und welche Gefahren hierbei auftreten können.

7.1. Bedrohungen durch fehlerhafte oder manipulierte Programme

Bei den bisherigen Betrachtungen wurde immer davon ausgegangen, daß verwandten Komponenten ihre Spezifikationen genau erfüllen. Dies ist bereits im Hinblick auf die Stabilität nicht gegeben, da fehlerfreie Programme kaum zu erzielen sind. Einen solchen unabsichtlich erzeugten Programmfehler bezeichnet man als "loophole" oder "bug". Hat der Programmierer aber die Absicht, später selber ein Angreifer zu werden, kann er gezielt "bösartige Befehle" ("malicious code") einfügen. Beim amerikanischen Verteidigungsministerium z.B. muß daher jeder Programmierer auch für das Sicherheitslevel zugelassen sein, das seine Programme nachher verwalten sollen. Im allgemeinen hat es sich als sinnvoll herausgestellt, höhere Programmiersprachen zur Entwicklung sicherer Systeme zu verwenden, da diese leichter verifizierbar sind, weil weniger Programmtext benötigt wird und der Parser des Übersetzers viele Überprüfungen automatisch vornehmen kann. Diese sind dann allerdings anfällig gegen "Tunneln" (s. dort). Insbesondere über die "Laufzeitbibliotheken" des Übersetzers kann unkontrolliert bösartiger Code eingeschleppt werden. Ein weiteres Problem ist es, daß ein System dessen Komponenten sicher sind, nicht insgesamt sicher sein muß. Insbesondere gibt es noch kein Verfahren, Sicherheitspolicen oder Spezifikationen zuverlässig zu kombinieren. Es werden zu Kompromitierung von Programmen überwiegend folgende Methoden verwandt:

7.1.1. Logische Bomben

Die sogenannten "logical bombs" sind Programmstücke, die aktiv werden, wenn eine bestimmte Situation eintritt. Handelt es sich um einen festgelegten Zeitpunkt, so spricht man auch von "time bombs". Diese werden häufig von Mitarbeitern angelegt, die der Firma schaden wollen.

7.1.2. Falltüren

Diese werden teilweise auch Hintertüren genannt ("trapdoor","backdoor"). Es handelt sich um vom Programmierer hinterlassene Zugangsmöglichkeiten zum System, häufig um Hilfsmittel, die Authentifizierung zu umgehen. Diese werden häufig auch ohne bösartige Absicht angelegt, um später Wartungsarbeiten leichter ausführen zu können ("maintenance hook").

7.1.3. Tunneln

Unter "Tunneling" versteht man einen Angriff auf einem niedrigeren Abstraktionslevel (Maschinenlevel), als das System erzeugt wurde, z.B. indem ein Fehler in dem Compiler gefunden wird, mit dem das Sicherheitssystem erzeugt wurde, oder durch Manipulation der verwendeten Hardware zum Zeitpunkt deren Entwicklung. Derartige Angriffe zählen zu den "High Level Treats" und sind nur zu erwarten, wenn der Angreifer ein Staat oder eine große Organisation ist, die über ausreichende Mittel verfügt.

7.2. Verifikation

Ist die Software erst einmal entwickelt, muß überprüft werden, daß sie den Spezifikationen entspricht. Dies richtet sich nicht nur gegen Programmfehler, sondern auch gegen bösartige Manipulationen. Mit Voraussetzung für die Verifikation aber auch für die spätere Anwendung ist es, daß sämtliche Sicherheitsmechanismen auf allen Abstraktionsebenen sorgfältig dokumentiert werden, um eine leichtere Überprüfung und einen sorgfältigen Umgang mit diesen möglich zu machen. Durch die Verifikation wird die Gewißheit ("Assurance") des späteren Benutzers, daß das System seine Funktion erfüllt, erhöht. Nach Aussage einiger Autoren19, avanciert diese "Gewißheit" zu einem immer wichtigeren Problem, wobei man sie einteilt nach "Überzeugung" ("confidence"), und Auswertbarkeit ("evaluability"), d.h. der Tatsache, daß jemand das System versteht und bewerten kann.

7.2.1. Testen

Die einfachste Form der Verifikation ist das Testen. Man simuliert die zukü nftige Arbeitsumgebung des Computersystems und betrachtet den Test als erfolgreich, wenn das System in jeder der simulierten Situationen korrekt reagiert. Da man aber meistens nicht alle Situationen überprüfen kann, muß eine Auswahl getroffen werden. Man ([NRC90]) unterscheidet hier folgende drei Varianten:

1. zufälliges Testen ("random testing")

2. strukturelles Testen: Die Testfälle werden aus der Programmstruktur abgeleitet, d.h. man versucht die Maschine gezielt in einen bestimmte Zustand zu versetzen. Diese Zustände können z.B. durch "Hazard"-Analyse bestimmt werden, d.h. durch das Analysieren von nicht erstrebenswerten Ereignissen.

3. funktionales Testen: die einzelnen Aufgaben des Systems werden getrennt überprüft.

7.2.2. Herkömmliche Verifikation

Unter herkömmlicher Verifikation versteht man einen nichtformellen Beweis der Korrektheit eines Programms, der durch Annahmen über (Scheifen-)Invarianten oder Zusicherungen ("assertions") geführt wird. Diese Art der Programmverifikation ist in nicht sicherheitsrelevanten Bereichen seit jeher üblich, jedoch nach Meinung der meisten Autoren nicht ausreichend, um "sichere" Software zu produzieren.

7.2.3. Beweisen

Die einzige Möglichkeit die Korrektheit einer Implementation sicher nachzuweisen, ist es, einen mathematischen Beweis hierfür zu führen (z.B. nach dem Hoare-Kalkül), in dem auch die zugrundeliegende Hardware betrachtet wird. Dies ist meistens zu aufwendig, weshalb man einzelne Programmteile unterschiedlichen Sicherheitsklassen zuordnet, und so wenig beweist wie nötig. Das "Bell-LaPadula" Modell verwendet hierzu ein Übergansgschema, in dem immer nur von einem sicheren Zustand zum anderen gewechselt werden kann. Da der Ausgangszustand sicher ist, kann die Gesamtsicherheit somit induktiv bewiesen werden.

7.2.4. Der "sichere Kern"

Die zahlreichen Inderdependenzen zwischen den diversen Komponenten einer AIS machen die Verifikation des Gesamtsystems zu einem sehr aufwendigen Unterfangen Analog zu Aufteilung der Daten in Sicherheitsklassen kann man auch bei Programmen versuchen, den Aufwand zu reduzieren, indem man die sicherheitsrelevanten Prozeduren zusammenfaßt und gesondert beweist. Beim verbleibenden Rest können dann weniger präzise Methoden verwandt werden. Den so herausgelösten Bestandteil des Systems bezeichnet man auch als "Trusted Computing Base (TCB)". Dieser sollte insbesondere - möglichst klein sein, um eine Verifikation, oder sogar einen Beweis seiner Korrektheit zuzulassen.

- so konstruiert sein, daß sämtliche Zugriffe auf sicherheitsrelevante Daten von der "TCB" bemerkt werden ("reference Monitor"); d.h. Hardware und Betriebssystem zählen größtenteils zur TCB.

- eine Manipulation der "TCB" selbst nicht möglich ist.

Auf der Hardwareseite kann man versuchen, die TCB klein zu halten, indem man z.B. durch Verschlüsselung Kabel aus der TCB entfernt, oder gesonderte, einfache Prozessoren einsetzt, deren einzige Funktionen die sicherheitskritischen sind. Das Betriebssystem wird häufig in einen Sicherheitsrelevanten Kern "kernel" und die restlichen Komponenten aufgeteilt. Es wird meistens versucht, dafür zu sorgen, daß Applikationen nicht zur TCB zählen müssen. Hierzu müssen Hardware und Betriebssystem Mö glichkeiten bieten, die einzelnen Prozesse voreinander zu schützen, d.h. Zugriffe auf die Speicherplätze oder den Code anderer Programme zu unterbinden. Meistens muß es aber dennoch "trusted" Programme geben, wie z.B. zur Änderung des Passwortes.

Der Benutzer muß später eine verläßliche Möglichkeit haben, mit der "TCB" in Kontakt zu treten ("secure path"), z.B. durch eine Tastenkombination. Ist dies nicht gegeben, kann ein anderes Programm als "TCB" auftreten oder sich dem Kern als Benutzer präsentieren.

7.3. Schutz vor nachträglicher Veränderung

Nachträgliche Manipulation, auch "Tampering" genannt, bietet im allgemeinen dieselben Möglichkeiten wie der Einbau bösartiger Anweisungen zum Implementationszeitpunkt. Da es aber zumeist unmöglich ist, die installierte Software in dem Maße zu analysieren, wie dies zum unauffä lligen Einbau z.B. einer "Bombe" notwendig wäre, wird zumeist Programmcode hinzugefügt, sei es als ganz neues Programm oder als eigenständiges Unterprogramm.

7.3.1. Troianische Pferde

Als troianische Pferde bezeichnet man Programme, die vorgeben, etwas Harmloses zu tun, die aber im Hintergrund bösartige Befehle ausführen. Trojanische Pferde müssen von einem Benutzer oder Angreifer eingeschleppt und zur Ausführung gebracht werden.

7.3.2. Würmer

Ein sog. "Wurm" ist ein eigenständiges Programm, das sich selbst in andere Computersysteme übertragen kann. Der bekannteste Wurm ("Internet-Wurm") nutzte einen Fehler im Programm "fingerd", um sich auf ca. 6000 Systeme zu übertragen. Würmer können selbst Viren enthalten:

7.3.3. Viren

Ein Virus ist ein Programmstück, das in der Lage ist, sich in andere Programme hineinzukopieren und diese somit in Trojanische Pferde zu verwandeln. Ein Virus wird ausgeführt, wenn das Programm, das ihn enthält gestartet wird, und durchsucht alle ihm zugänglichen Datenbestände nach Programmen (bzw. anderen Bootblocks s.u.) und integriert seinen Code in diese. Man unterscheidet Boot-Viren (Bootblock), Systemviren (Allocation Table), Programmviren (normal), polymorphe Viren (mutierend) ,Stealth Viren (versteckt) , Retro-Viren (Zerstörung von Antiviren- Software) und Daten-Viren (Makros).

7.3.4 Schutzmaßnahmen

Um das System vor Viren und Trojanischen Pferden zu Schützen verwendet man häufig Filterroutinen, die bestimmte Muster im Programmcode, die für bekannte Viren oder Pferde charakteristisch sind, in Datenströmen aufzuspü ren. Häufig werden diese dann durch Überschreiben20 (z.B. mit NOP) deaktiviert, und dann wird versucht das Programm normal auszuführen. Eine andere Möglichkeit besteht darin geschützte Subsysteme zu verwenden, da z.B. Viren auf den Code anderer Programme zugreifen müssen um sich zu vermehren. Ist also einem Programm verboten auf den Code eines anderen zuzugreifen, so kann die Anwesenheit eines Virus durch Versuche gegen diese Sperre zu verstoßen festgestellt und seine Ausbreitung verhindert werden.

8. Ausblick

Die Einführung des Computers hat das Problem der Sicherheit stark vergröß ert. Um einen kompletten Konstruktionsplan (z.B. eines Flugzeugs) zu kopieren, hätte es früher vieler Arbeitsstunden mit Kopierern und Photoapparaten bedurft, heute ist dies eine Arbeit von wenigen Minuten. Aber im Gegensatz zu den vollkommen passiven Ordnern früherer Zeit kann ein AIS selbst an seiner Verteidigung "mitarbeiten". Es sind zahlreiche Methoden entwickelt worden, wie dies geschehen kann, die sich zumeist an bereits vorher existente Verfahren anlehnen, wie Zugangsbeschränkung, "clearance" für bestimmte Sicherheitsniveaus oder Beobachtung wie sie seit Jahrzehnten mit Videokameras vorgenommen wird.

Ich habe allerdings den Eindruck, daß die Entwicklung von Sicherheitseinrichtungen zumindest partiell von der falschen Seite angegangen wurde. Man nimmt immer an, daß man die Zugriffsrechte von Angreifern einschränkt, d.h. daß der normale Betriebsmodus derjenige ist, in dem jeder vollen Zugriff hat. In Wirklichkeit ist es aber genau umgekehrt. Im "normalen" Betrieb kann der Rechner die Speicherstellen, in die von der Hardware die Daten, die von außen kommen, geschrieben werden, vollkommen ignorieren. So ist z.B. ein Modem ein Gerät, das elektrische Felder auf einem Stromdraht mißt. Und genauso wie man die Daten einer Meß apparatur auswertet, werden letztendlich auch die Daten der Schnittstelle interpretiert. Diese Interpretation liegt nun aber vollkommen in der Hand des Benutzers. D.h. eigentlich ist nicht der Angreifer im Vorteil, der sich den Schwachpunkt aussuchen kann, sondern der Besitzer, der die Interpretation vollkommen kontrolliert - das Problem an dieser Vorstellung ist natürlich, daß sie voraussetzt, daß keinerlei bösartiger Code eingeschleppt wurde.) Die meisten Firmen wählen aber gerade den umgekehrten Weg. Da die Verfügbarkeit für den Kunden offenbar immer Vorrang vor der Sicherheit hat, werden viele Systeme im Zustand der niedrigsten Sicherheit ausgeliefert21, und der Administrator muß diese dann nach und nach erhöhen. Es gibt allerdings in letzter Zeit Bestrebungen diesem abzuhelfen.22

Ähnliche Veränderungen wie die Einführung des Computers wird auch die zunehmende globale Vernetzung bewirken. Sind z.B. Daten mehrfach redundant über die Welt verteilt vorhanden, so kann ein Angreifer versuchen, jeweils die Bestände zu attackieren, die am wenigsten geschützt sind. Bisher wäre dazu eine weite physikalische Reise notwendig gewesen. Unterstützt wird er dabei von den inzwischen weit verbreiteten Suchmaschinen, die ihm das Problem der Suche nach Adressen und Hilfsinformationen vollkommen abnehmen, da sie eine nahezu vollständige Tiefensuche im gesamten Netzwerk ausführen. Auch der persönliche Datenschutz wird hierdurch gefährdet, da diverse Organisationen Daten über Personen im Netz zur Verfügung stellen, die für sich genommen vollkommen harmlos sind - z.B. zusammenfassende Berichte über Konferenzen- , die aber im Zusammenhang die Erstellung eines Persönlichkeitsbildes ermöglichen. Das bisher eher stiefmütterlich behandelte Feld der Integrität gewinnt im Rahmen dieser Entwicklung mehr und mehr an Bedeutung. Die Wehrlosigkeit der SMTP-Server des Internets gegen "Masquerading", das vermehrte Aufkommen direkter bildloser Kommunikation über Rechner und insbesondere auch die Simulation virtueller Umgebungen, in denen mehrere Menschen, durch ihre Avatare vertreten miteinander zusammenarbeiten, verlangen, daß insbesondere die Authentifizierung sicher durchgeführt werden kann. Dies ist in einem geschlossenen System kein gravierendes Problem, aber sollen beispielsweise zwei Systeme im Internet auf diese Weise kommunizieren, so muß die Authentifizierung eines vom Fremdsystem akzeptierten Users vorgenommen werden, ein Vorgang, der in Form der r-Befehle unter UNIX (rsh, rlogin) bereits heute Probleme bereitet.

Die "Availibility" wird von einem indirekten zu einem direkten Problem, da vielfach Rechenanlagen dritten zu Verfügung gestellt werden, und ein dann eintretender "Denial of Service" unmittelbare Verluste zur Folge hat. Dies würde durch die Einführung von Computern, deren gesamte Software im Netz liegt, wie dies von einigen Firmen geplant wird, noch verstärkt.

Ein anderes Problem ist die unwahrscheinliche Zahl neuer Benutzer von Computersystemen, die zwar über keinerlei geheimes Wissen oder Wissen um Sicherheitsaspekte verfügen, aber gefährliche Operationen vornehmen wollen (z.B. bargeldlos bezahlen). Dies bringt einerseits mit sich, daß ein Groß teil derjenigen Aktionen, die bisher von Systemadministratoren und Sicherheitsbeauftragten wahrgenommen wurden, ab sofort automatisiert werden müssen. Hierzu gehören kritische Operationen, wie das Anlegen von Subjekten, die Vergabe von Zugriffsrechten, das Auswerten von Auditing-Informationen und ggf. sogar die Einleitung juristischer Schritte. Andererseits kann man nicht mehr auf eine ausreichende Aufmerksamkeit oder gar Wachsamkeit der Benutzer hoffen, da diese über das benötigte Wissen gar nicht verfügen, und z.B. nicht registrieren, daß mehrere erfolglose Authentifizierungsversuche unter ihrem Namen vorgenommen wurden. Ein drittes, von der von mir bearbeiteten Literatur nur wenig beachtetes Problem sind diejenigen Schnittstellen, die vom Rechner in die reale Welt zurückführen. Bei allen Betrachtungen ist davon ausgegangen worden, daß eine Korruption des Systems im Extremfall zu einem Zusammenbruch einer Firma, bzw. zum Diebstahl einer Information führt, die von militärischer Bedeutung ist. Menschenleben sind bei diesen beiden Vorgängen nur indirekt gefährdet. Das Manipulieren einer Bandstraße, das Täuschen eines elektronischen Abwehrsystems, oder die Kontrolle über einen autonomen Robot können hingegen benutzt werden, um Personen direkten Schaden zuzufü gen. Diese Einbrüche sind für die Systementwicklung vollkommen identisch zu denen des ersteren Typs, ihre Auswirkungen aber sind grundverschieden, da die ausführenden Maschinen im Gegensatz zu einem Menschen keinerlei moralisches Empfinden kennen, und der Auslösende vollkommen unbeteiligt bleibt, da er ggf. viele Kilometer entfernt ist.

Alles in allem kann man sagen, daß sich die Brisanz des Themas Computersicherheit in den nächsten Jahren ebenso exponentiell erhöhen wird, wie die Zahl der an Computernetze angeschlossenen Rechner exponentiell wächst. Die entwickelten Verfahren sind aber zumeist Methoden, die älteren Zeiten entstammen und Erlebnisse wie das Durchbrechen des "Bell-LaPadula"-Modells durch "covered timing channels" werden denjenigen, die sich mit diesem Thema beschäftigen, auch in der Zukunft nicht erspart bleiben.

9. Literaturverzeichnis

[BAA86] Baaske, Hartmut:

Datenspeicher und Methoden der Sicherung.

Vaterstetten: 1986.

[DOD] Department of Defence (USA):

Glossary of Computer Security Terms.

National Computer Security Center

NTSC-TG_004

http://cliffie.nosc.mil/~NADOC/docprj/security/

[DOD89] Deparment of Defence (USA):

Guide To Understanding Trusted Facility Management.

National Computer Security Center

NCSC-TG-O15

Library No. S-231, 429

http://cliffie.nosc.mil/~NADOC/docprj/security/

[HSI79] Hsiao, David K., Douglas S. Kerr und Stuart E. Madnic:

Computer Security.

New York: Academic Press, 1979.

[IEE93] Zurko M.E. : "Panel: What are the Foundations of Computer Security ?".

Computer Security Foundations Workshop VI-1993, S. 85-98.

[KYA96] Kyas,Othmar:

Sicherheit im Internet: Risikoanalyse - Strategien - Firewalls.

Bergheim: 1996.

[NRC90] National Research Council.

Computers at Risk. Kap. 1-4.

o.O. 1990.

[RUS91] Deborah Russel und G.T. Gangemini Sr. :

Computer Security Basics.

Sebastopol: 1991.

[SIM93] Simmons, Gustavus J.:

An Introduction to the Mathematics of Trust in Security Protocols

Computer Security Foundations Workshop VI-1993, S. 121-127.

1 [NRC90],S. 77

2 [HSI79]

3 s. vgl. [RUS91]

4 s. [DOD]

5 [NRC90]

6 [RUS91] S.212

7 Department of Defence Trusted Computer System Evaluation Criteria DoD 5200.28-STD

8 Nähreres findet sich daher in diesem Kapitel.

9 d.h. in den Senken des Flußes auf dem Graphen

10 (genauer gesagt ist es ein Aspekt des BLP-Modells)

11 In einem Zugriffskontrollmodell kann eine MAC z.B. durch Schranken realistert werden, die der Benutzer bei der Einstufung der von ihm erzegten Daten nicht überschreiten darf.

12 [SIM93]

13 s. vgl. [NRC90]

14 Das "Orange Book" verlangt hier laut [RUS91] eine strikte Trennung.

15 s. vgl. [HSI79]

16 Wie dies besipielsweise unter UNIX mit dem "suid-Bit" realisiert wird.

17 s. vgl. [NRC90]

18 wie z.B. die "nice"- Werte unter UNIX

19 Robert Morris in [IEE93]

20 z.B. das Programm "Disinfectant" auf Macintosh-Rechnern

21 So z.b. ist im Auslieferungszustand bei SUN-Rechnern ein Wildcard-Zeichen in der datei .hostsequiv eingetragen, was jedem verbundenen Fremdrechner vollständige Zugriffsrechte einräumt.

22 Die Firma Apple z.B. liefert seit neuem ihre Rechner mit deaktiviertem Gast-Zugang aus, was bisher nicht der Fall war.