Sicherheit in der Informationstechnik: Einführung in Probleme, Konzepte und Lösungen [2., völlig überarbeitete Auflage. Reprint 2018] 9783486787641, 9783486231793

Citation preview

Sicherheit in der Informationstechnik Einführung in Probleme, Konzepte und Lösungen von Dr. Heinrich Kersten 2., völlig überarbeitete Auflage

R. Oldenbourg Verlag München Wien 1995

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Kersten, Heinrich: Sicherheit in der Informationstechnik : Einführung in Probleme, Konzepte und Lösungen / von Heinrich Kersten. 2., völlig Überarb. Aufl. - München ; Wien : Oldenbourg, 1995 1. Aufl. u.d.T.: Kersten, Heinrich: Einführung in die Computersicherheit ISBN 3-486-23179-0

© 1995 R. Oldenbourg Verlag GmbH, München Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitimg in elektronischen Systemen. Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München

ISBN 3-486-23179-0

Inhalt Vorwort

7

Einleitung

9

1. Beispiele aus der Praxis

23

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9

23 24 34 40 55 61 62 62 66

Einfuhrung Einzelaspekte bei speziellen Systemen Bewegliche Datenträger Berechtigungen und Kontrollen Programme mit Schadenfunktionen Beweissicherung Abstrahlsicherheit Verfügbarkeit und Datensicherung Datenübertragung, lokale und öffentliche Netze

2. Grundbegriffe 2.1 Informationen, Daten, Verarbeitung, IV- und IT-System 2.2 Ordnungsmäßigkeit, IV-Sicherheit, IT-Sicherheit 2.3 Verfügbar, vertraulich, integer, verbindlich 2.4 Analysen von Bedrohungen, Risiken und Schäden 2.5 Subjekte, Aktionen, Objekte 2.6 Unterschiedliche Modellvorstellungen von Sicherheit

71 71 72 75 79 80 84

3. Sicherheitsfunktionen 3.1 Grundsätzliches 3.2 Zugriffsschutzmodelle 3.3 Funktionalitätsklassen 3.4 Praxis der Funktionalitätsklassen

87 87 105 120 134

4. Das Sicherheitsniveau 4.1 Grundsätzliches 4.2 Sicherheitsniveaus in Kriterienwerken

137 137 140

5. Entwicklung 5.1 Grundsätzliches 5.2 Vorgehensmodell 5.3 Produkt-Entwicklung 5.4 Qualitätssicherung 5.5 Konfigurationsmanagement

155 155 157 157 170 173

5

Inhalt

5.6 Werkzeuge 5.7 Wartung

176 179

6. Evaluierung 6.1 Reduktion der Komplexität 6.2 Dokumentation 6.3 Der Evaluierungsprozeß 6.3 Produktion, Auslieferung und Verteilung 6.4 Release-Wechsel und Weiterentwicklung 6.5 Kombinationen evaluierter Produkte 6.6 Bewertungsbeispiele für Mechanismen

181 182 185 188 191 192 194 196

7. Anwendungen 7.1 Einleitung 7.2 Strategien der IT-Sicherheit 7.3 Konzeptionelles Vorgehen 7.4 Strategie der Vertrauenswürdigkeit 7.5 Aufgaben für praktische Analysen 7.6 Kritik und Ausblick

205 205 206 212 216 223 225

Anhang A. Quellen

227

Anhang B. Zertifizierte Produkte B.l Orange Book B.2 ITSEC B.3 UKL B.4 IT-Sicherheitskriterien

231 231 234 235 237

Anhang C. Glossar

239

Anhang D. Abkürzungen

263

Anhang E. Stichwortverzeichnis

265

6

Vorwort Das vorliegende Buch stellt die zweite, vollständig überarbeitete Auflage des 1991 erschienenen Buches Einführung in die Computersicherheit dar. Der Titel wurde geändert, weil der Begriff Computersicherheit die Thematik der Informationssicherheit nur teilweise abdeckt und in der heutigen technischen Landschaft mit all ihren Möglichkeiten der Vernetzung nicht mehr zeitgemäß ist. Das Thema der Informationssicherheit erfreut sich immer noch eines ungebrochenen Interesses: Seit dem Erscheinen der ersten Auflage dieses Buches im Jahre 1991 haben sich rasante Entwicklungen in der internationalen Diskussion, im Gebiet der Sicherheitskriterien und der damit zusammenhängenden Strukturen, bei technischen Lösungen, aber auch hinsichtlich neuer Risiken ergeben. Das einleitende Kapitel schildert diese Entwicklungen. Damit dieses Buch in dieser Situation auch weiterhin eine aktuelle Einführung in das Gebiet der Informationssicherheit bleiben kann, wurde es im Vergleich zur Erstausgabe vollständig überarbeitet und neu konzipiert. Davon betroffen waren alle Kapitel der Erstausgabe. An einer Reihe von Stellen wurden die Schwerpunkte neu gesetzt: Während sich z.B. die Erstausgabe mit den seinerzeit aktuellen nationalen Sicherheitskriterien verschiedener Staaten beschäftigte, ist im Zuge der internationalen Harmonisierung die Begriffswelt der europäischen Sicherheitskriterien ITSEC zugrundegelegt worden - ohne dabei die neuen Entwicklungen zu gemeinsamen Sicherheitskriterien von Europa und Nordamerika ("Common Criteria") zu ignorieren; neue Erkenntnisse und Erfahrungen auf dem Gebiet der Sicherheitsanalysen wurden ebenfalls einbezogen. Dieses Buch kann dennoch nur eine Einführung in die Thematik der Informationssicherheit bieten: Kapitel 1 enthält eine Sammlung praktischer Sicherheitsprobleme und Lösungen und stellt eine Stoffsammlung für die weiteren Kapitel dar. Die weiteren Kapitel behandeln die Definition grundlegender Begriffe (Kapitel 2), eine systematische Darstellung der Sicherheitsfunktionen und ihrer Mechanismen einschließlich der verschiedenen Zugriffsschutzmodelle (Kapitel 3), die Problematik der Vertrauenswürdigkeit und der verschiedenen Sicherheitsniveaus (Kapitel 4), die Entwicklung (Kapitel 5), Evaluierung (Kapitel 6) und Anwendung (Kapitel 7) von IT-Systemen. Im Anhang finden sich neben einem Literaturverzeichnis und Listen zertifizierter Produkte ein umfangreiches Glossar der Fachbegriffe, ein Abkürzungsverzeichnis und ein Stichwortverzeichnis.

7

Vorwort

Zur Methodik: Es wurde bewußt auf eine tiefergehende Behandlung mathematischer Fragen (Kryptographie, Software-Verifikation) und die detaillierte Aufarbeitung von Standardisierungsproblemen verzichtet; hierfür ist gute Fachliteratur verfügbar. Abgesehen von Kapitel 1 (Beispielsammlung) wurde auf einen linearen Aufbau ohne Vorwärtsverweise Wert gelegt. Wichtige neue Begriffe werden durch Schrägstellung hervorgehoben. Bilder und Grafiken werden dort verwendet, wo sie Sachverhalte leichter erfaßbar machen. In einigen Abschnitten finden sich Aufzählungen von neuen Begriffen, die unterstrichen sind; hierdurch soll angedeutet werden, daß entsprechende Definitionen bzw. Erläuterungen der Reihe nach in den folgenden Absätzen gegeben werden. Dies bewahrt den Leser vor hektischem Nachschlagen und fuhrt zu einer besseren Strukturierung der komplexen Sachverhalte. Im Bereich der Informationssicherheit ist ein großer Teil der Literatur in englischer Sprache gehalten. Aus diesem Grunde wurden bei Fachbegriffen vielfach auch die entsprechenden englischen Begriffe aufgeführt.

Das vorliegende Buch ist nicht zuletzt ein Ergebnis von zahlreichen Diskussionen mit Teilnehmern von Kongressen, Seminaren und anderen Veranstaltungen: Viele Anregungen und Kommentare sind eingearbeitet worden, ohne daß die Betreffenden hier namentlich genannt werden können. Dennoch möchte ich allen, die mittelbar oder unmittelbar zu diesem Buch beigetragen haben, herzlich danken. Allen Kritikern und Rezensenten der ersten Auflage möchte ich für ihre Anregungen und Verbesserungsvorschläge danken und gleichzeitig bitten, auch dieses Buch kritisch zu kommentieren. Dem Oldenbourg-Verlag möchte ich meinen Dank dafür aussprechen, daß auch diese Neuauflage schnell und unkompliziert erscheinen konnte. Im November 1994 Heinrich Kersten

8

Einleitung Unzureichende Sicherheit bei der elektronischen Datenverarbeitung wird für die Öffentlichkeit immer dann deutlich, wenn in den Medien über entsprechende Vorkommnisse berichtet wird: Hacker und Computer-Freaks brechen erfolgreich in Systeme ein, personenbezogene Daten und Finanzdaten werden mißbraucht bzw. manipuliert (Computerkriminalität), immer neue ComputerViren treten auf, Spionage und Sabotage im Bereich der Forschung und der Industrie unter Einsatz und Ausnutzung der Computer und Netzwerke, Dienstleistungen der Telekommunikation werden unbefugt bzw. unkontrolliert durch Phreaks (Phone-Freaks) ausgenutzt.

Manipulationen

Anzumerken ist hier, daß im gesamten Bereich der Manipulationen an und in datenverarbeitenden Systemen von einer hohen Dunkelziffer auszugehen ist. Von Spionage wird eher selten offen berichtet; dies mag einerseits daran liegen, daß ein Nachweis über erfolgte Spionage im Kontext der Informationsverarbeitung nur äußerst schwer zu erbringen ist, andererseits solche Berichte oft mit einem Ansehensverlust für die Betroffenen verbunden sind. Welche einseitigen Vorteile sich durch geschickte illegale Nutzung von Computer-Systemen und Netzwerken z.B. bei Börsenspekulationen, Termingeschäften usw. erzielen lassen, wurde in jüngster Vergangenheit mehrfach deutlich. Die sich abzeichnende Einführung von Chipkarten im Gesundheitswesen ist dagegen eine Angelegenheit, von der jeder Einzelne unmittelbar betroffen ist - und zwar in einem zweifachen Sinne: Einerseits wird er Nutzer bzw. Anwender dieser Technik, andererseits sind es seine eigenen (personenbezogenen) Daten, die der mißbräuchlichen Nutzung ausgesetzt sein können. Die sehr medienwirksamen Berichte über Hacker-Fälle und Computer-Viren dürften im Hinblick auf den entstandenen Schaden eher von untergeordneter Bedeutung sein - im Gegensatz zu den Aktivitäten der Phreaks, die bei den Betreibern von Telekommunikationsanlagen erhebliche wirtschaftliche Schäden verursachen.

Schäden und Dunkelziffer

Weniger medienträchtig - aber mindestens genauso wichtig - sind Probleme der Ausfallsicherheit 1 : Die rechtzeitige Bereitstellung von Daten und Dienstleistungen und deren Aufrechterhaltung sind entscheidende wirtschaftliche Faktoren, können in sicherheitskritischen Systemen sogar von lebenswichtiger Bedeutung sein; zu nennen sind hier Bereiche wie die elektronische Verkehrssteuerung, die Flugsicherung, Steuerung von medizinischen Geräten und industrieller Prozesse (z.B. in Kernkraftwerken).

Ausfallsicherheit

In der deutschen Sprache fallen alle genannten Probleme unter den Begriff der Sicherheit; im Englischen wird zwischen Security (Sicherheit vor Manipulationen) und Safety (Sicherheit als Garantie der korrekten, permanenten Funktion) unterschieden.

9

Einleitung

Stellenwert

Zielrichtung

Technische Entwicklungen

Konkrete Schadenzahlen liegen aus einer Umfrage in Großbritannien aus dem Jahre 1991 vor, bei der ca. 1000 Unternehmen nach Schäden im Bereich der Informationstechnik befragt wurden. Das Ergebnis waren Gesamtschäden in Höhe von mehr als 1 Mrd. britische Pfund jährlich, die sich zu je ca. 50 % auf Manipulationen und mißbräuchliche Zugriffe einerseits, auf materielle Schäden wie Diebstahl, Hardware-Defekte usw. andererseits verteilen. Dabei wurden nur unmittelbare Schäden, aber keine Folgeschäden berücksichtigt. Bei der hohen Bedeutung, die Computer-Systeme und Netzwerke in unserem täglichen Leben haben, der steigenden Abhängigkeit vom reibungslosen Funktionieren solcher Systeme und der immer deutlicher zutage tretenden Anfälligkeit gegenüber Manipulationen müssen zukünftig die Ansprüche an die Sicherheit steigen: Die informationelle Selbstbestimmung des einzelnen Bürgers und die Informationen und Dienstleistungen des Staates und der Wirtschaft stellen Werte dar, die nicht schutzlos preisgegeben werden können. In manchen Bereichen hängt darüber hinaus die Gesundheit und das Leben von Menschen von informationstechnischen Systemen ab. Wird diesem steigenden Sicherheitsanspruch nicht Rechnung getragen, wird die Akzeptanz der Informationstechnik, deren Vorteile unbestritten sind, erheblich leiden - vielleicht könnte eine solche Entwicklung sogar langfristig zur Ablehnung dieser Technik fuhren. Aus diesen wenigen Anmerkungen wird deutlich: Die Entwicklung, daß die "informationstechnische" Sicherheit in der Öffentlichkeit zunehmend Beachtung findet und immer breiter diskutiert wird, ist in jedem Fall zu begrüßen und muß noch verstärkt werden. Keineswegs soll in diesem Buch ein vordergründiges Horror-Gemälde der Bedrohungen und Schäden gezeichnet werden. Zielrichtung ist es vielmehr, für den Leser einen systematischen Zugang zur "Informationssicherheit" zu eröffnen, dort, wo es sinnvoll ist, Historisches anzumerken, die aktuelle Entwicklung zu beschreiben und Tips zur praktischen Gestaltung von Informationssicherheit zu geben. Auf der technologischen Seite waren die letzten Jahrzehnte durch ein immer schnelleres Wachstum auf allen Ebenen gekennzeichnet: Die Miniaturisierung der Computer-Bausteine, ihre steigende Leistungsfähigkeit und ihr fallender Preis führten dazu, daß sich die "elektronische Intelligenz" ein immer breiteres Anwendungsfeld eroberte. In vielen Geräten des täglichen Bedarfs sind heute schon integrierte Schaltkreise vorhanden. Ein großer Teil der industriellen Prozeßsteuerungs- und Kontrollsysteme ist heute mit Mikroprozessoren ausgerüstet und letztlich davon abhängig. Die Steuerung kritischer Prozesse etwa in Kernkraftwerken, der Raumfahrt, bei der Verkehrslenkung und in der Medizintechnik ist ohne Informationstechnik kaum denkbar, oftmals sogar gänzlich unmöglich. Ebenso kaum mehr ohne Computer-Technik vorstellbar sind das Rechnungswesen einschließlich der Lohn- und Gehaltsabrechnungen und das gesamte Banken- und Versicherungswesen.

10

Einleitung

Seit Anfang der 80er Jahre zeichnet sich ein starker Trend zur dezentralen Datenverarbeitung ab: Hierzu hat vor allem die Verbreitung der Personal Computer (PC) beigetragen. Bis vor wenigen Jahren wurden im Leistungsniveau zwischen PCs und der klassischen Groß-EDV sogenannte Mehrplatzsysteme ("Etagenrechner") z.B. auf der Basis des Betriebssystems Unix eingesetzt; inzwischen hat der Preisverfall und die Fortentwicklung dieser Systeme dazu geführt, daß entsprechende Workstations mit hoher Rechenleistung und in der Preiskategorie von PCs mittlerweile für jeden Arbeitsplatz einsetzbar sind. Gleichzeitig hat die Technik der lokalen Vernetzung einen kommerziell nutzbaren Standard erreicht, der jede Art von Datei-, Datenbank- und Kommunikationsdiensten am Arbeitsplatz zugänglich macht. PCs und Workstations können mit jeder Art kleiner oder großer zentraler "Intelligenz" verbunden werden und eignen sich darüber hinaus wegen der technischen Flexibilität für viele Spezialaufgaben. Neue Ansätze wie die Client-Server-Architekturen, leichter zu handhabende Bedienungsoberflächen (Window- und Icon-basiert, Notebook-Style) haben Einsatzgebiete und Akzeptanz dieser Informationstechnik erhöht. Verschiedenste Anbieter machen unter Nutzung öffentlicher Netzwerke internationale Mail-, News- und Dateidienste direkt am Arbeitsplatz verfügbar.

Dezentrale D V

Innerhalb des nächsten Jahrzehnts wird die Weiterentwicklung der Informationstechnik eine Vielzahl neuer Anwendungsmöglichkeiten eröffnen und zu einem erheblich erweiterten Einsatz dieser Technik fuhren. Es darf hier die Prognose gewagt werden, daß gerade die Flexibilität der PCs und Workstations den Trend zur dezentralen Datenverarbeitung in der nahen Zukunft noch verstärken wird. Das moderne Stichwort Multimedia2 macht den Horizont deutlich, auf den hingearbeitet wird. Es ist sehr wahrscheinlich, daß andererseits Großrechner-Systeme zukünftig nur noch in solchen Bereichen zu finden sein werden, in denen höchste Rechen- und Transaktionsleistung gefordert werden - also z.B. im Forschungsbereich -, während andererseits im Dienstleistungsbereich zumindest für Neuinvestitionen den kleinen und mittleren Systemen (mit Vernetzung) der Vorzug gegeben werden wird. Ein diese Entwicklung verstärkender Faktor ist das heute breit gestreute Grundwissen über PCs, das zu einer höheren Akzeptanz bei der Einführung dezentraler DV-Unterstützung auf PC-Basis führt - und dies nicht nur bei der jüngeren Generation von Anwendern. Kurzum: Die technische Seite ist vordergründig in der Lage, unserem ständig steigenden Bedarf an Dienstleistungen, Kommunikation und Information Rechnung zu tragen.

Perspektiven

2

Integration v e r s c h i e d e n s t e r T e c h n i k e n w i e z . B . S p r a c h a u f z e i c h n u n g und -Weiterverarbeitung, V i d e o b e a r b e i t u n g , K o m m u n i k a t i o n s d i e n s t e zur N u t z u n g aller I n f o r m a t i o n s m e d i e n an e i n e m Arbeitsplatz.

11

Einleitung

Informationssicherheit

Realität der IT-Sicherheit

Bedrohungen

Im Gegensatz dazu stehen die vielfach negativen Erfahrungen der Anwender von Informationstechnik, daß Hardware unzuverlässig arbeitet, Software nicht korrekt programmiert ist, Inkompatibilitäten zwischen verschiedenen Systemen vorliegen, kaum Sicherheit vor Datendiebstahl und Manipulation besteht. Aus dieser unbefriedigenden Situation heraus ist schon vor ca. 20 Jahren das Gebiet der Informationssicherheit entstanden. Ursprünglich weitgehend auf militärische Bedürfnisse ausgerichtet, ist die Informationssicherheit heute ein breites, interdisziplinäres Gebiet, zu dem Aspekte des Datenschutzes, der Ordnungsmäßigkeit der Datenverarbeitung, die Betrachtung von Qualität und entsprechender Normen und Standards, verbesserte Entwicklungsmethoden und Werkzeuge vor allem zur Software-Herstellung, die Untersuchung von Manipulationsmethoden und entsprechender Gegenmaßnahmen gehören. Im Zusammenhang mit Informationssicherheit wird vielfach auch von IT-Sicherheit3, Computersicherheit, Datensicherheit, Datensicherung und Datenschutz gesprochen - Begriffe, die zwar nicht gleichbedeutend sind, aber zum gleichen Kontext gehören, nämlich der sicheren Verarbeitung von Informationen. Die technischen Systeme (Computer, Netzwerke, ...) werden als lT-Systeme bezeichnet, die Produkte (Hardware, Software) als IT-Produkte. Während Informationssicherheit der umfassende Begriff ist, beziehen sich die Begriffe Computersicherheit und IT-Sicherheit eher auf die technischen Sicherheitsaspekte in IT-Systemen und -Produkten. Datensicherheit ist ein älterer Begriff für Informationssicherheit - konzentriert sich aber im Schwerpunkt nur auf die Sicherheit der Daten. Datensicherung bezeichnet das Teilgebiet der sicheren Speicherung von Daten. Datenschutz kennzeichnet die rechtlichen, administrativen und technischen Vorgaben bei der Verarbeitung und Speicherung von personenbezogenen Daten gemäß der Datenschutzgesetze. Bei der Begutachtung der Sicherheitseigenschaften von IT-Systemen und -Produkten zeigt sich, daß zur Zeit nur wenige einen tolerierbaren Sicherheitsstandard besitzen. Die Sicherheit trat bisher weit hinter den Merkmalen der Rechen- und Transaktionsleistung, der Übertragungsgeschwindigkeit und der Speicherkapazität zurück. Daß ganz allgemein in den informationsverarbeitenden Systemen öffentlicher und privater Betreiber große Sicherheitslücken bestehen, ist eine Tatsache. Die zu betrachtenden Bedrohungen lassen sich grob einteilen in Verlust oder Einschränkung der Verfügbarkeit von Daten und Dienstleistungen, der Vertraulichkeit von Informationen, der Unversehrtheit (Integrität) von Daten und Systemen, der Verbindlichkeit von Daten und Dienstleistungen.

Die Abkürzung IT für Worte w i e "informationstechnische", "Informationstechnik" usw. ist d e m gängigen Sprachgebrauch entnommen und soll hier beibehalten werden - auch wenn dies in manchen Fällen grammatische oder sprachliche Fehler verursacht ( w i e z.B. in "IT-Technologie").

12

Einleitung

Aus Bedrohungen und Sicherheitslücken resultierende Risiken und Schäden kann man sich leicht ausmalen: direkte finanzielle Schäden (in Folge von Datenverlusten), Ansehensverlust (bspw. im Bankenbereich), gesundheitliche Schäden (z.B. durch fehlerhafte Steuerung von medizinischen Behandlungsgeräten), unerwünschte Weitergabe von Know-How und Verlust von Marktanteilen (Forschung und Industrie), sensitive staatliche bzw. militärische Informationen geraten in die falschen Hände, Minderung oder gar Verlust von Grundrechten (z.B. die informationelle Selbstbestimmung) u.v.m. Je nach Anwendungsgebiet ist der Sicherheitsbedarf sehr unterschiedlich: Während in militärischen Bereichen schon immer ein sehr hohes Sicherheitsniveau und z.T. extrem hohe Anforderungen bestanden, ist dies im Bereich der Schutzes personenbezogener Daten - also des Datenschutzes - nicht mehr so extrem; im privaten Bereich kann IT-Sicherheit sogar von geringer Bedeutung sein. Andererseits verarbeiten auch Wirtschaftsunternehmen Daten, die eine sehr hohe Sensitivität bzw. einen sehr hohen Wert besitzen. Die Forschung hat sich des Sicherheitsthemas bereits seit langem angenommen und Algorithmen und Architekturen vorgeschlagen, mit denen vielen Bedrohungen entgegengewirkt werden kann. Bis vor wenigen Jahren wurden solche theoretischen Ansätze kaum in die Praxis umgesetzt. Sicherheit war keine Forderung des Marktes und wurde deshalb von den Herstellern kaum in Betracht gezogen. Inzwischen ist ein Wandel eingetreten: Immer mehr Hersteller werben mit Untersuchungen, Gutachten und Zertifikaten, in denen Aussagen über die Sicherheitseigenschaften ihrer Produkte gemacht werden. Kunden fragen nach den Sicherheitsmerkmalen von IT-Produkten. Diese Tendenzen sind insbesondere auf eine steigende Sensibilisierung der Anwender zurückzufuhren, die sich in Anforderungen bei der Beschaffung von IT-Systemen niederschlägt. Dem Sicherheitsstandard der IT-Systeme kommt auch im internationalen Wettbewerb zunehmend Bedeutung zu, wobei nach Meinung des Autors in einer Reihe von Staaten die Informationssicherheit eine höhere Beachtung findet als bei uns... Es darf grundsätzlich nicht verkannt werden, daß unzureichend organisierte Datenverarbeitung, wenig sensibilisierte Personen, niedriger Ausbildungsstand und Fahrlässigkeit von Mitarbeitern einen hohen Anteil an der desolaten Sicherheitslage haben. Daß IT-Sicherheit bisher eher vernachlässigt worden ist, mag einen weiteren Grund darin haben, daß der Problemdruck bei der traditionellen Datenverarbeitung in zentralen Großrechnern (klassische Rechenzentren) scheinbar nicht so hoch war: Auch heute wird noch vielfach die Meinung vertreten, GroßrechnerSysteme seien "sicher" oder zumindest "sehr viel sicherer" als etwa PCs oder PC-Netzwerke. Dieser pauschalierenden Meinung muß widersprochen werden! Gerade die Anhäufung von riesigen Datenmengen unterschiedlichster Natur, mit zum Teil sensitivem Informationsgehalt produziert eine Art "kritische Mas-

13

Schäden

Sicherheitsbedarf

Ursachen

Zentralisierte Groß-DV

Einleitung

Unix und PC

Schwachstellen

Korrektheit

Beherrschbarkeit

Maßnahmen

se" und macht viele Großrechner erst für Manipulationsversuche interessant bis hin zu kriminellen Handlungen. Schaut man ins Detail, so stellt sich außerdem heraus, daß es mit der viel gelobten Sicherheit der Großrechner und ihrer Betriebssysteme nicht so gut bestellt ist, wie landläufig behauptet wird. Man hat gelegentlich den Eindruck, daß der vermeintlich hohe Sicherheitsstandard hauptsächlich darin besteht, daß sich nur eine geringe Zahl von Personen mit den Interna der komplexen Systeme auskennt. Damit kommt ein weiterer Faktor ins Spiel: der Wissensstand über die betroffenen technischen Systeme. Sobald man nämlich auf mittlere und kleinere Systeme schaut, ändert sich die Situation: Die Anzahl der Unix-Anwender und -Kenner steigt ständig, Kenntnisse über Personal Computer und die dort verwendeten Betriebssysteme zählen heute schon fast zum Allgemeingut. Es kann dann nicht verwundern, daß sich die Zahl der Manipulationsfälle bei diesen weit verbreiteten, sicherheitstechnisch schwachen und schwächsten System-Typen konzentriert. Ursachen für die Schwachstellen von IT-Systemen sind zu suchen in der unzureichenden Qualität von IT-Produkten (Entwurf, Implementierung, Qualitätssicherung, Dokumentation), einer unzureichenden Betriebssicherheit, Mängeln in der Konzeption und Organisation beim Betrieb der IT-Systeme - mit den schon genannten Schadenfolgen. Qualitativ hochwertige IT-Systeme zu entwerfen ist heute weniger ein Problem der Architekturen und Methoden. Eine Schwierigkeit besteht in der korrekten Implementierung und ihrer Verifikation: Besitzt ein System exakt die geforderten funktionellen Eigenschaften? Sind diese Eigenschaften korrekt implementiert? Wie verläßlich sind die Methoden zum Nachweis der Korrektheit? Die Vorbehalte und Diskussionen zum Thema Korrektheit der Steuerungssoftware von Flugzeugen macht die Problematik extrem deutlich. Ein anderes Hindernis ist der zu treibende Aufwand und damit die ökonomische Seite: Je höher die Fehlerfreiheit, desto teuerer die Software! Je ausfallsicherer die Hardware sein soll, um so höher ist ihr Preis. Bei dem landläufig akzeptierten Niveau kommerzieller Produkte und der immer höher werdenden Komplexität der zusammenwachsenden IT-Systeme stellt sich allerdings sehr schnell die Frage nach der Beherrschbarkeit zukünftiger Informationstechnik. Im Kontext des Schutzes personenbezogener Daten wird verschiedentlich gefragt, ob nicht angesichts der Beherrschbarkeitsprobleme Grundrechte (z.B. das Grundrecht auf informationelle Selbstbestimmung) außer Kraft gesetzt werden. Was ist auf der Anwenderseite zu tun? Maßnahmen zur Minderung von Risiken und Schäden müssen in ein Gesamtkonzept für die sichere Anwendung der IT eingebettet sein. Als Maßnahmen sind zu betrachten: Sensibilisierungs- und Ausbildungsmaßnahmen für das mit den Systemen arbeitende Personal, der Einsatz möglichst sicherer IT-Produkte, eine saubere Integration solcher Pro-

14

Einleitung

dukte zu einem IT-System, eine offene Informationspolitik bzgl. der realen Bedrohungen und der Effektivität von Schutzeinrichtungen. Es gibt inzwischen zahlreiche gesetzliche Bestimmungen, Richtlinien, Erlasse und Vorschriften, die die Informationssicherheit tangieren: das Bundesdatenschutzgesetz und entsprechende Gesetze der Länder (Schutz personenbezogener Daten) - in einigen Bereichen ergänzt durch das Sozialgesetzbuch, die staatlichen VS-Richtlinien4, viele ergänzende Konzepte, Richtlinien und Bestimmungen in der Öffentlichen Verwaltung (z.B. die Pflicht zur Erstellung von Sicherheitskonzepten bei Bundesbehörden, Vorgaben ftir die angemessene Verwendung staatlicher Finanzmittel), nationale Richtlinien und NATO-Bestimmungen im militärischen Bereich, staatliche Vorgaben für solche Firmen, die an behördlichen Aufträgen arbeiten, interne Anweisungen in Firmen und Unternehmen. Alle diese Anforderungen sind trotz ähnlicher Zielrichtung kaum harmonisiert. Es besteht in manchen Bereichen sogar eher die Gefahr, daß wegen der Vielzahl von Vorschriften diese nicht mehr überschaubar, in sich widersprüchlich und kaum operationalisierbar sind und nicht zuletzt deshalb von den Betroffenen kaum akzeptiert werden (können). In der Praxis muß IT-Sicherheit einfach und überschaubar sein, um von den Betroffenen inhaltlich getragen zu werden. Dies beginnt im Regelungsbereich, gilt ebenso für das individuelle Sicherheitskonzept sowie schließlich für die eingesetzte Technik, deren Möglichkeiten und Grenzen beachtet werden müssen. Es muß allerdings festgehalten werden, daß es keine absolut sicheren IT-Systeme gibt oder zukünftig geben wird. Die Sensibilisierung der Anwender darf deshalb nicht zu überzogenen Anforderungen an die Sicherheit der Systeme fuhren. Die Angemessenheit der Maßnahmen ist stets zu wahren. Aus dem Angemessenheitsprinzip folgt, daß sich der zu treibende Sicherungsaufwand am Sicherheitsbedarf zu orientieren hat. Es sind also Maßstäbe für den Sicherheitsbedarf und den Sicherungsaufwand festzulegen und zueinander in Beziehung zu setzen. Mehr Sicherungsaufwand zu treiben, macht nur Sinn, wenn damit in der Bilanz eine Minderung von Risiken und Schäden zu verzeichnen ist. Somit sind Maßstäbe erforderlich, die die Sicherheit selbst betreffen: Die Sicherheitsleistung der IT-Systeme muß durch Sicherheitsstufen ausdrückbar sein. In vielen Sicherheitskriterien werden Maßstäbe bzw. Metriken der zuvor beschriebenen Art definiert. Wer gibt solche Kriterien heraus und was sind deren Ziele? In vielen Ländern wird das Thema der Informationssicherheit neben anderen durch staatliche Institutionen bearbeitet. Ihre Aufgaben sind zumeist die BeraV S ist die Abkürzung für Verschlußsache^j,

i.e. geheimzuhaltende (staatliche) Informa-

tionen.

15

Richtlinien, Vorschriften, Gesetze

Überschaubarkeit

Einfachheit

Angemessenheit

Sicherheitsstufen

Sicherheitskriterien

Institutionen

Einleitung

USA

Orange Book

tung der Anwender (Analysen, Konzepte, Maßnahmen), die Herausgabe von Sicherheitskriterien zur Prüfung und Bewertung von Produkten und Systemen, die Durchführung solcher Prüfungen und die Förderung der IT-Sicherheit durch Entwicklungs- und Forschungsprojekte. Nach längerer Vorlaufzeit wurde 1981 in den USA das National Computer Security Center (NCSC, heute Teil der National Security Agency - NSA) ins Leben gerufen, um die Sicherheit beim Einsatz von IT-Systemen im Verteidigungsbereich zu erhöhen. Ein wesentliches Ergebnis des NCSC ist ein Kriterienkatalog zur Prüfung und Bewertung von IT-Systemen. Der Katalog wurde 1983 (2. Auflage 1985) unter dem Titel Trusted Computer System Evaluation Criteria herausgegeben und wird wegen seines orange-farbenen Einbands als Orange Book bezeichnet. Vom technischen Inhalt her ist es an der Sicherheitspolitik und entsprechenden Vorschriften im Verteidigungsbereich ausgerichtet. IT-Systeme werden in Sicherheitsstufen C l , C2, Bl, B2, B3, A I eingeordnet. Das Orange Book behandelt fast ausschließlich Fragen der Vertraulichkeit von (militärischen) Informationen. Aus diesem Kontext wird klar, warum IT-Systeme amerikanischer Hersteller ab einer hohen Sicherheitsstufe strengen Export-Restriktionen unterworfen werden. Technisch gesehen definiert das Orange Book funktionale Anforderungen an IT-Systeme, beschreibt aber meist nur implizit die Prüfung bzw. Evaluierung dieser Anforderungen. Die mit dem Orange Book letztlich verbundene Zielrichtung war, nur solche IT-Systeme für die Verarbeitung sensitiver (staatlicher) Daten einzusetzen, die entsprechend den Anforderungen des Orange Book evaluiert wurden. Dieses Ziel konnte aus verschiedenen Gründen nur in Teilbereichen verwirklicht werden. Auch wenn eine Reihe von Produkten - hauptsächlich Großrechner-Betriebssysteme - gemäß dem Orange Book evaluiert worden sind, konnte keine flächendeckende Richtlinie zum Einsatz evaluierter Produkte umgesetzt werden 5 . Darüber hinaus kam aus Richtung der IT-Industrie massive Kritik an den Prüfverfahren - vor allem wegen des zu hohen zeitlichen und finanziellen Aufwandes und der Problematik, Produktänderungen nicht ausreichend schnell evaluieren zu können und somit an den Markterfordernissen vorbeizuarbeiten. Das zivile, der Industrie nahe stehende National Institute of Standards and Technology (früher National Bureau of Standards - NBS) wurde deshalb um 1990 beauftragt, neue Wege zu suchen und akzeptablere Verfahren vorzuschlagen. Eines der Ergebnisse war die Herausgabe eines Entwurfs von Federal Criteria (1992), die eine dringend notwendige technische Weiterentwicklung des Orange Book darstellen. Damit verbunden war auch die Absicht, kommerzielle Prüfstellen zur Durchführung von Evaluierungen einzurichten, um die geschilderten zeitlichen Probleme in den Griff bekommen zu können. Ob dies

Das Ziel "C2 b y 92"

- die IT-Systeme in Behörden mit sensibler Datenverarbeitung

sollten ab 1992 mindestens der Klasse C2 genügen - konnte nicht realisiert werden.

16

Einleitung ses Programm umgesetzt oder ad acta gelegt wird, steht noch nicht definitiv fest. In der NATO sind immer noch die 1987 herausgegebenen NATO Trusted Computer System Evaluation Criteria - oft als Blue Book bezeichnet - gültig. Sie stimmen inhaltlich mit dem Orange Book überein. Die kanadische Behörde Communications Security Establishment (CSE) gab 1989 die erste Fassung der Canadian Trusted Computer Product Evaluation Criteria heraus, die technisch eine Revolution gegenüber dem Orange Book darstellten: Es wurde erstmalig zwischen Sicherheitsfunktionalität und Assurance (Vertrauenswürdigkeit) unterschieden. Assurance meint dabei das Maß an Garantie, daß ein Produkt oder System nicht penetriert werden kann. Darüber hinaus wurden Verfügbarkeit und Integrität in die kanadischen Kriterien einbezogen. Man darf ohne Übertreibung sagen, daß Kanada hinsichtlich der Innovation auf dem Kriterienmarkt eine herausragende Stellung zukommt. Inzwischen sind weitere Versionen der kanadischen Kriterien veröffentlicht worden. Gelegentlich hört man allerdings auch die Kritik - natürlich bezogen auf alle Kriterienwerke -, daß sich deren Release-Wechsel langsam dem Takt der Produktänderungen anpaßt... In Großbritannien befassen sich im staatlichen Bereich vor allem die Communications-Electronics Security Group (CESG) und das Department of Trade and Industry (DTI) mit Fragen der IT-Sicherheit. Es wurden 1989 die UK Systems Security Confidence Levels, das Evaluations Levels Manual und das Security Functionality Manual herausgegeben. Dabei waren die Assurance (Vertrauenswürdigkeit) und ihre Evaluierung zentrale Punkte, funktionale Anforderungen eher untergeordnet. Die Evaluierungen konzentrierten sich zunächst auf installierte IT-Systeme, später dann auch auf einzelne IT-Produkte. Bis heute wurden ca. 30 Produkte nach den britischen Kriterien durch kommerzielle Prüfstellen evaluiert. Die Verlagerung auf kommerzielle Auftragnehmer machte einerseits eine staatliche Überwachung ihrer Prüfungen und die Bestätigung der Ergebnisse erforderlich (die Zertifizierung), andererseits wurden Marktmechanismen wirksam, die zu einer erheblichen Beschleunigung der Prüfverfahren führten. Im Jahre 1991 wurden die europäischen Kriterien ITSEC übernommen, die sowohl der System- als auch der Produktsicht Rechnung tragen. Die Zertifizierung von Produkten und Systemen wird vom UK ITSEC Scheme (Kooperation von CESG und DTI) durchgeführt. In Frankreich hat der Service Central de la Sécurité des Systèmes d'Information (SCSSI) 1989 Sicherheitskriterien erstellt, die allerdings nicht öffentlich verfügbar sind. Es ist nicht bekannt, ob hierauf aufbauend Produkte evaluiert wurden. Das SCSSI wendet heute ebenfalls die ITSEC an. Es muß davon ausgegangen werden, daß sich in Frankreich einige Produkte in der ITSECEvaluierung befinden.

17

NATO

Kanada

Großbritannien

Frankreich

Einleitung

Japan

Deutschland

Europa und ITSEC

In Japan waren lange keine Entwicklungen zur IT-Sicherheit erkennbar. Um so überraschender war 1992 die Herausgabe von Japanese Computer Security Evaluation Criteria. Inwieweit diese in die Praxis Eingang gefunden haben, ist noch nicht erkennbar. Es verdichten sich allerdings die Gerüchte, daß in Japan ein Zertifizierungsschema aufgebaut wird. Bis einschließlich 1990 wurden in Deutschland Aufgaben der IT-Sicherheit im staatlichen Bereich unter anderem durch die Zentralstelle für Sicherheit in der Informationstechnik (ZSI) wahrgenommen. Zum Jahresbeginn 1991 wurde als Nachfolger das Bundesamt für Sicherheit in der Informationstechnik (BSI) durch Parlamentsbeschluß gegründet. Es ist für den Behördenbereich beratend tätig, führt für den staatlichen VS-Bereich Zulassungen für den Einsatz bestimmter IT-Komponenten durch und bietet Dienstleistungen für Hersteller hinsichtlich der Entwicklung, Prüfung und Zertifizierung von kommerziellen IT-Systemen und -Produkten an. Ähnlich wie in Großbritannien und Frankreich wurden 1989 IT-Sicherheitskriterien herausgegeben, die insofern eine Fortentwicklung des Orange Book darstellen, als sie zwischen Funktionalität und Qualität unterscheiden; andererseits entsprechen die funktionalen Anforderungen teilweise den Klassen des amerikanischen Orange Books. Nach diesen Kriterien wurden einige (weniger als 10) Produkte evaluiert. Dabei bediente man sich ähnlich wie in Großbritannien kommerzieller Prüfstellen. Mit der Verabschiedung der ITSEC im nationalen Kontext wurden diese die Basis für alle neuen Evaluierungen des BSI. In einer Reihe von europäischen Staaten (z.B. den Niederlanden, Schweden und der Schweiz) sind Behörden mit Aufgaben der IT-Sicherheit beauftragt, beobachten die internationale Entwicklung auf dem Gebiet der Sicherheitskriterien, der Evaluierung und Zertifizierung und wirken dabei teilweise mit. Die von den genannten Institutionen in Großbritannien, Frankreich, Deutschland und den Niederlanden harmonisierten Sicherheitskriterien ITSEC (1990, 1991) sind inzwischen ein de facto Standard in Europa. Nach diesen Kriterien sind europaweit in der Größenordnung 100 Produkte evaluiert worden bzw. in der Evaluierung. Die ITSEC stellen gleichermaßen eine Harmonisierung und eine Fortentwicklung aller zuvor genannten, in Europa entwickelten Sicherheitskriterien dar. Durch die produktspezifischen und vom Hersteller festzulegenden Sicherheitsvorgaben (TOE, Target of Evaluation) wird die staatliche Reglementierung von Produktanforderungen vermieden und damit mehr Markt geschaffen; im Zentrum der Betrachtung steht die Vertrauenswürdigkeit (Assurance) der Sicherheitseigenschaften und nicht so sehr die Funktionalität. Andererseits lassen die ITSEC auch System-Evaluierungen zu, bei denen der Anwender die Vorgaben für sein spezifisches IT-System macht. Zur Zeit werden solche System-Zertifizierungen allerdings im staatlichen Bereich wohl ausschließlich in Großbritannien durchgeführt.

18

Einleitung

Es hat Versuche gegeben, Sicherheitskriterien - wie die zuvor genannten - in die internationale Standardisierung (z.B. in die ISO) einzubringen. Diese stets langwierigen Prozesse sind bis heute noch nicht von Erfolg gekrönt. Unabhängig davon haben Hersteller-Vereinigungen für ihre Produktsparten Security Guidelines (bspw. X/OPEN für Offene Systeme, ECMA für C2-ähnliche Betriebssysteme) herausgegeben. Sie können zur Durchfuhrung von Konformitätsprüfungen herangezogen werden, reduzieren die Assurance-Betrachtung aber auf die funktionale Konformität zu den Standards. Darüber hinaus existieren Normen und Standards, die bereichsspezifische Sicherheitsanforderungen stellen. Ein Beispiel hierzu ist die DIN V V D E 0801/ 01.90 "Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben".

Abbildung 1 : Historie der Sicherheitskriterien In der Abbildung 1 sind viele Zwischenversionen von Kriterienwerken nicht aufgeführt. Dennoch führt auch diese reduzierte "Kriterienlandschaft" sofort zu folgenden Problemen: Unterschiedliche Bewertungskriterien stellen ein Problem für den Anwender dar, da sie einen Vergleich der Sicherheitseigenschaften entsprechend geprüfter Systeme erschweren, wenn nicht sogar unmöglich machen. Für die Hersteller von Systemen ist diese Situation aus wirtschaftlichen Gesichtspunkten untragbar: Mehrfache Prüfungen ihrer Produkte nach unter-

19

ISO, X/OPEN, ECMA

Einleitung

Internationale Harmonisierung

Aktuelle Diskussion

Common Criteria

HerstellerErklärungen

schiedlichen Sicherheitskriterien in unterschiedlichen Staaten sind kosten- und zeitmäßig nicht akzeptabel. Eine gegenseitige Anerkennung von Prüfergebnissen könnte dieses Problem lösen. Andererseits hört man oft die Meinung, jede Anerkennung von "ausländischen" Zertifikaten schwäche die Marktposition der eigenen Industrie. Die wesentlichen "Kontrahenten" sind dabei zweifelsohne der europäische und der amerikanische Markt. Eine Anerkennung von Zertifikaten anderer Stellen ist aber auch technisch eine Herausforderung: Selbst dann, wenn die gleichen Kriterienwerke zugrunde liegen, müssen die Prüfverfahren abgeglichen werden, da Prüfergebnisse weitgehend auch davon abhängen, wie geprüft wird. Sind unterschiedliche Kriterienwerke zu betrachten, muß darüber hinaus ein qualitativer und teilweise quantitativer Vergleich erfolgen, aus dem ersichtlich ist, welche Sicherheitsstufe eines Kriterienwerks welcher Stufe des zweiten Kriterienwerks entspricht - was aber selten präzise der Fall sein dürfte. Die Harmonisierung der Kriterien und der Prüfverfahren ist 1993/94 innerhalb der Europäischen Union erreicht worden. Die gegenseitige Anerkennung von Zertifikaten hat sich allerdings als ein sehr schwieriges Unterfangen herausgestellt, das noch nicht erfolgreich abgeschlossen werden konnte. Dabei spielen nicht zuletzt juristische Probleme wie z.B. Haftungsfragen eine Rolle. 1992 wurden zwischen der EG und Nordamerika Arbeiten zur Erstellung von Common Criteria (CC) aufgenommen, in denen einerseits die US-amerikanischen Federal Criteria und die kanadischen CTCPEC, andererseits die europäischen ITSEC zu einem "harmonischen" Ganzen zusammengefügt werden sollen. Bei der unterschiedlichen Struktur und Methodologie der beteiligten Kriterienwerke dürfte klar sein, daß der Trend von einfach zu verstehenden Kriterien (Orange Book), über kompliziertere (CTCPEC, ITSEC) zu sehr komplexen Kriterien (CC?) anhält. Es ist heute schon feststellbar, daß nur noch Spezialisten in der Lage sind, die Inhalte von Kriterienwerke, ihre Auswirkungen auf Evaluierungen und auf die Sicherheit bei der Anwendung der Produkte zu verstehen. In technischer Hinsicht dürfte in den CC vor allem die Definition von Sicherheitsprofilen, die Unterscheidung von Development Assurance und Evaluation Assurance interessant sein. Die Gründe für die Aufteilung der Assurance auf zwei Bereiche wird in den nächsten Absätzen klar werden... Im Zusammenhang mit Sicherheitskriterien und Evaluierungen durch staatliche Stellen kam schon früh die Frage auf, ob nicht die Industrie die Prüfungen selbst durchfuhren solle (First Party Evaluierung). Die First Party Evaluierung von IT-Produkten wird natürlich besonders von den Herstellern favorisiert, die sogar darauf basierend Hersteller-Erklärungen abgeben und unabhängige Zertifizierungen vermeiden möchten. Bei genauerer Betrachtung stellt sich hierbei

20

Einleitung aber heraus, daß kaum Aufwand gegenüber einer Third Party Evaluierung 6 einzusparen ist, andererseits die Vergleichbarkeit und Anerkennung solcher Hersteller-Erklärungen neue Schwierigkeiten mit sich bringt. Eine andere Richtung tat sich mit der Einfuhrung der Norm ISO 9000 auf: Sie definiert in sehr abstrakter Form den Begriff der Qualität und beschreibt, welche Anforderung z.B. bei der Entwicklung von Produkten für eine - individuell festzulegende - Qualität zu stellen sind. Nach dieser Norm können Entwicklungslaboratorien bzw. deren Entwicklungs- und Produktionsprozeß zertifiziert werden. Diese Zertifizierung ist prozeßbezogen, aber nicht produktbezogen. Eine Qualitätsgarantie dieser Art ist sicher von Vorteil, bringt aber für die ITSicherheit zunächst nichts: Ein Qualitätsprodukt in diesem Sinne kann absolut unsicher sein, ein sicheres Produkt kann andererseits von schlechter Qualität sein. Die Qualitätsanforderungen müßten vielmehr in ihrem Niveau an die Sicherheitserfordernisse angepaßt werden; dennoch wird man auf diese Weise kaum eine produktbezogene First Party oder Third Party Evaluierung ersetzen können. Aus solchen Diskussionen wurde 1993 das Konzept der Development Assurance geboren: Hierunter wird das direkte Einbringen von Sicherheits- und Qualitätsforderungen in den Entwicklungsprozeß von IT-Systemen verstanden. Inwieweit solche Verfahren durch Dritte, z.B. staatliche Stellen, geprüft und überwacht werden sollen, ob hierauf Hersteller-Erklärungen oder unabhängige Zertifizierungen folgen sollen, ist noch ungeklärt. Auch wenn die Erhöhung von Qualität und Sicherheit bereits in der Konstruktion von IT-Produkten ein guter Ansatz ist, kann er jedoch neutrale Produkt-Evaluierungen und den damit verbundenen Gewinn an Vertrauenswürdigkeit und Sicherheit nicht überflüssig machen. Da der mit First/Third Party Evaluierungen verbundene Kosten- und Zeitaufwand natürlich nicht im Interesse der Industrie liegt, ist leicht erklärbar, warum der Zug in Richtung Development Assurance in starkem Maße durch die ITHersteller beschleunigt wird... Stellt sich also die Frage nach Wirtschaftspolitik versus Sicherheit? Auf der Anwenderseite ist zu beobachten, daß in den letzten Jahren in verschiedenen Staaten Regelwerke, Empfehlungen oder zumindest Guidelines herausgegeben worden sind, in den versucht wird, für IT-Installationen den Sicherheitsbedarf qualitativ oder quantitativ zu erfassen und hieran Maßnahmen zu koppeln. Dabei liegt der Schwerpunkt überwiegend auf administrativen Sicherheitsmaßnahmen, wodurch in aller Regel nur Anwendungen mit geringem und geringstem Sicherheitsbedarf befriedigt werden können. Umfangreiche theoretische Konzepte, Richtlinien und Verhaltensmaßregeln haben im Zeitalter vernetzter Systeme noch keinen Hacker, Manipulanten oder gar Spion bzw. 6

First Party meint den Hersteller, Second Party den Anwender, Third Party unabhängige Prüfstellen.

21

'SO 9000

Development Assurance

Anwender

Einleitung

Ausblick

Saboteur abgehalten! Hier besteht also noch ein erheblicher Nachholbedarf vor allem auf der Seite der Sensibilisierung und Einsicht darin, welche exorbitanten Schwachstellen in der heutigen Technik und ihrer Anwendung gegeben sind... Die geschilderten Entwicklungen in der IT-Sicherheit zeigen, daß wir noch weit von stabilen, transparenten Strukturen und Verfahren entfernt sind, die in anderen Bereichen (z.B. der Safety) teilweise schon seit Jahrzehnten vorhanden sind. Es fragt sich nur, ob angesichts der schnellen technologischen Entwicklung noch viel Zeit bleibt... Inzwischen sind aber auch positive Entwicklungen erkennbar: IT-Sicherheit ist nicht mehr nur eine nationale Angelegenheit. IT-Sicherheit wird nicht mehr ausschließlich als eine Domäne von und für Experten angesehen. Die IT-Sicherheit macht sich die in angrenzenden Sicherheitsbereichen (z.B. Safety) vorhandenen Erfahrungen zunutze. IT-Sicherheit hat Eingang in die Entwicklungslaboratorien von Herstellern kommerzieller Produkte gefunden und wird von den Anwendern der IT zunehmend nachgefragt. Bei der Dynamik der geschilderten Entwicklungen darf man gespannt sein, ob nicht in zwei bis drei Jahren für dieses einführende Kapitel wiederum eine vollständige Neufassung erforderlich sein wird...

22

1. Beispiele aus der Praxis Statt sofort in Grundsatzdiskussionen und die Theorie einzusteigen, erscheint es sinnvoller, zunächst eine Reihe von praktischen Beispielen zu diskutieren und die üblichen Standardprobleme durchzuspielen, und zwar noch ohne die volle begriffliche Schärfe einer systematischen Aufarbeitung.

1.1 Einführung Für die Lösung von Sicherheitsproblemen stehen oft mehrere Alternativen zur Verfügung. In den seltensten Fällen gibt es die optimale Lösung. Mögliche Lösungen unterscheiden sich in den Kosten, dem organisatorischen Aufwand und dem Maß an notwendiger Sensibilisierung und Mitwirkung der Nutzer und last but not least hinsichtlich der erreichbaren Sicherheit. Bei letzterem steht man vor der Frage, welche der möglichen Alternativen sicherheitsmäßig höher oder niedriger einzustufen sind. Vertraut man mehr auf organisatorische Maßnahmen - trotz der bekannten Schwachstelle "Mensch"? Oder eher auf technische Lösungen - trotz der Kosten und der möglicherweise fehleranfälligen Technik? Müßte sich eine genaue Analyse nicht auf Statistiken über aufgetretene Fälle, Täterprofile, Schadenhöhen und -Wahrscheinlichkeiten stützen? Gibt es solche Untersuchungen?

Lösungen

Diese Fragen sollen andeuten, daß vielfach noch objektive Maßstäbe und gesicherte Erfahrungswerte fehlen. Dies ist eine typische Situation in der Informationssicherheit! Wenn objektive Maßstäbe fehlen, ist man auf subjektive Einschätzungen angewiesen; dabei wird man sich gerne auf Aussagen vertrauenswürdiger Dritter stützen. Wer aber ist in diesem Sinne vertrauenswürdig, und auf welchen Untersuchungsmethoden beruhen seine Aussagen? Welche Art von Garantien werden gegeben? Diskutieren wir diese Problematik an einem kurzen Beispiel; dabei wird klar werden, daß Begriffe wie Bedrohung, Risiko, Funktionalität, Sicherheit, Vertrauenswürdigkeit, Kontrolle bzw. Revision eine zentrale Rolle spielen. Nehmen wir an, es soll ein Rechner so abgesichert werden, daß unautorisierten Personen der Zugriff auf die gespeicherten Daten verwehrt bleibt. Nach einer Markt-Recherche stellt sich heraus, daß es für den betreffenden Rechner ein Schutzprogramm gibt, das jeden Benutzer zunächst zur Eingabe eines Paßwortes auffordert. Ein solches Programm wird erworben und installiert. Was nützt diese Schutzvorrichtung aber, wenn sie leicht zu umgehen ist, kurze und leicht erratbare Paßwörter zugelassen werden oder Paßwörter nicht häufig genug gewechselt werden?

Maßstäbe

23

Funktionalität

1. Beispiele aus der Praxis

Sicherheit

Nachweisführung

Verantwortlichkeit

Lebenszyklus

An diesem Beispiel wird klar: Das reine Vorhandensein einer Paßwort-Funktion (die Funktionalität) ist natürlich nicht ausreichend. Die durch das Schutzprodukt erreichbare Sicherheit ist hier der zentrale Punkt: Wieviel Sicherheit kann ein solches Produkt bieten? Welche organisatorischen Rahmenbedingungen müssen eingehalten werden? Das erforderliche Maß an Sicherheit ergibt sich aus der Schutzwürdigkeit der Daten. Je sensitiver die Daten und damit je interessanter sie für Unautorisierte sind, um so "standfester" muß die Paßwort-Funktion technisch und organisatorisch ausgelegt sein. Bleiben wir bei dem Beispiel und nehmen an, ein Hersteller sichert eine ausreichende Sicherheit seines Schutzproduktes zu. Vielleicht basiert seine Zusicherung auf Unkenntnis bestimmter Penetrationstechniken. Wer erbringt also den verläßlichen Nachweis, daß beim Einsatz dieses Produktes die Sicherheit tatsächlich ausreichend hoch ist? Gibt es vertrauenswürdige, neutrale, erfahrene Institutionen, die den geforderten Nachweis erbringen können? Gehen wir im Beispiel einmal davon aus, daß ein solcher Nachweis erfolgt ist. Dennoch bleibt die Verantwortlichkeit für die Sicherheit in der Regel beim Betreiber des IT-Systems. Er wird deshalb Möglichkeiten zur Revision fordern, um beispielsweise erfolgreiche oder nicht erfolgreiche illegale Eindringversuche nachverfolgen zu können. Desweiteren ist es in der Praxis oft so, daß während der Lebenszeit eines ITSystems sein Einsatzzweck, die Ausstattung durch Hinzunahme neuer Komponenten usw. geändert wird. In jedem Fall ist eine permanente Kontrolle erforderlich, um zu garantieren, daß das Sicherheitskonzept und der Schutz noch angemessen sind. Damit wird klar, daß für die Sicherheit "vor Ort" nicht nur die technische Sicherheit von IT-Produkten allein maßgebend ist, sondern zusätzlich ein erheblicher Aufwand in Konzeption und Organisation zu leisten ist, um eine ausreichend hohe Gesamtsicherheit erreichen zu können. Diese gesamte Spannweite der Informationssicherheit vorausgesetzt, sollen dennoch zunächst eine Reihe von Einzelproblemen diskutiert werden, die später für ein Gesamtkonzept wesentlich sind.

1.2 Einzelaspekte bei speziellen Systemen 1.2.1 Überblick über Betriebsformen In der Praxis kommen bestimmte Betriebsformen und Einsatzumgebungen vor. Daran anknüpfend läßt sich eine Rangfolge der Schwierigkeit, Sicherheit zu garantieren, aufstellen. In der Abbildung 1-1 gilt: Die Erarbeitung des Sicherheitskonzeptes und die Realisierung von Sicherheitsfunktionen wird immer komplexer, j e weiter man

24

1.2 Einzelaspekte bei speziellen Systemen

auf den Achsen X, Y, Z nach außen geht. Die in der Abbildung 1-1 auftretenden Begriffe und Bezeichnungen sollen nun näher erläutert werden. Unter Stand-Alone wird ein eigenständiges IT-System verstanden, daß keine Verbindung zu anderen IT-Systemen besitzt. An einem Stand-Alone-System können j e nach T y p mehrere Benutzer nur nacheinander oder aber gleichzeitig arbeiten (Einzelplatz- oder Mehrplatzsystem). Dieser Typ repräsentiert immer noch eine beachtliche Zahl von Systemen.

Stand Alone

Die Stufe Host-Anschluß kennzeichnet solche Systeme, die zwei Betriebsformen haben: einen lokalen Betrieb wie bei Stand-Alone und einen Emulationsbetrieb, indem unter Einsatz bestimmter Software ein Standardterminal wie etwa V T 5 2 oder V T 1 0 0 eines Hosts (i.d.R. ein Großrechner) emuliert wird. Sicherheitsprobleme ergeben sich, wenn - wie in der Praxis üblich - zwischen beiden Betriebsformen hin und her geschaltet wird und z.B. Daten unkontrolliert ausgetauscht werden können.

Host-Anschluß

Multi-funktional

—

X4

Netzwerk Host-Anschluß Stand-Alone

Applikationsrechner

Betriebssystem

SoftwareHardwareEntwicklung Entwicklung

Abbildung 1-1: Betriebsformen(X), Einsatzformen(Y) und Benutzerstruktur(Z)

Mit Netzwerk sind Systeme gemeint, die lokal oder von einem Netz-Server gebootet werden und dann Zugriff auf ihren lokalen und einen gemeinsamen Datenbestand auf einem oder mehreren Servern haben. Hierzu ist ein Transportsystem (Leitungen, Funk) erforderlich.

25

Netzwerk

1. Beispiele aus der Praxis

Multi-funktional

Multimedia

Applikationsrechner

Betriebssystem

SoftwareEntwicklung

HardwareEntwicklung

Single-User

Multi-User

Multi-Level

In multi-funktionalen Systemen ist es möglich, auf verschiedene Server eines Netzwerks - z.B. im Client-Server Betrieb - und auf Großrechner zuzugreifen, über DFÜ Kommunikation mit weit entfernten Systemen aufzubauen und gleichzeitig meist in eine lokale Architektur (z.B. eine Bürokommunikation) eingebunden zu sein, in der z.B. auch ein Multimedia-Betneb möglich ist: die Nutzung von Medien wie Video- und Sprachaufzeichnungen, Integration von FAX, E-Mail und anderen Kommunikationsdiensten machen diese Betriebsform aus. Unter Applikationsrechner wird hier ein System verstanden, das dem Benutzer nur Menüs mit einzelnen Auswahlpunkten zur Verfugung stellt, ihm aber den direkten Zugriff z.B. auf Betriebssystem-Kommandos verwehrt. Ein Sicherheitsproblem kann allerdings dann entstehen, wenn einzelne Applikationen das Absetzen von System-Kommandos oder das vollständige Aussteigen auf die System-Ebene erlauben. Dies ist vielfach im PC-Bereich bei den bekannten Software-Paketen und vielen Terminal-Emulatoren der Fall. Sind dagegen dem Benutzer System-Kommandos zugänglich, kann er diese und andere Programme in beliebiger Kombination selbst starten, so muß das System in die Kategorie Betriebssystem eingestuft werden. Sind darüber hinaus Programmierumgebungen mit Compilern, Assemblern, Software-Werkzeugen und Testhilfen vorhanden, befinden wir uns in der Abteilung Software-Entwicklung der Abbildung 1-1. Wird der Rechner für Hardware-Tests/-Messungen - meist mit geöffnetem Gehäuse - eingesetzt, liegt die Kategorie Hardware-Entwicklung vor. Unter Single-User wird hier ein System verstanden, das entweder einem einzigen Benutzer oder aber mehreren gleichberechtigten Benutzern zugeordnet ist. Letzteres bedeutet, daß alle Benutzer die gleichen Zugriffsrechte haben. Die Situation Multi-User liegt vor, wenn mehrere Benutzer unterschiedliche Rechte haben: Zugriffe auf das Dateisystem und andere Ressourcen sind nicht jedem Benutzer gleichermaßen gestattet. Die übliche Vorgehensweise besteht darin, daß der Besitzer einer Datei anderen Benutzern Zugriffsrechte wie z.B. das Lesen, Schreiben, Ausführen und Erweitern zubilligen kann - aber nicht muß. Fast ausschließlich militärischen Systemen ist die Multi-Level-Klasse vorbehalten: Hier wird ein Zugriffsrecht zu Daten erst dann erteilt, wenn der betreffende Benutzer prinzipiell ermächtigt ist, Daten der betreffenden Klasse (z.B. vertraulich, geheim, streng geheim) einsehen zu dürfen. Man spricht hier auch vom Schutzklassen-Konzept.

26

1.2 Einzelaspekte bei speziellen Systemen

1.2.2 PC-Sicherheit In diesem Abschnitt sollen einige Aspekte der Sicherheit von Stand-Alone PCs behandelt und ein Rohentwurf für einen Maßnahmenkatalog entworfen werden. Welche Sicherheitsprobleme existieren in solchen Systemen? Gehen wir zunächst von der Situation aus, daß die Dateien auf der Festplatte gegen unbefugten Zugriff geschützt werden soll. Der Zugriff sei nur einem einzigen Benutzer oder einer Gruppe von Benutzern mit identischen Rechten gestattet (Fall Single-User aus Abbildung 1-1). "Zugriff' bedeute hier das Lesen und Schreiben von Daten und das Starten von Programmen. Beginnen wir in der Analyse mit den unbefugten Personen, die keinerlei Rechte in diesem System besitzen. Sie sollen von der Nutzung (Lesen, Schreiben von Daten; Starten von Programmen) ausgeschlossen werden. Folgende Fälle sind denkbar: a) Durch Starten des PC kann jeder Unbefugte an Ort und Stelle auf die Daten zugreifen. b) Durch Diebstahl oder zeitweiliges Entwenden kann die Festplatte temporär in einen anderen PC eingebaut und dann kopiert werden. Damit sind alle Daten und Programme der Festplatte zugänglich. c) Im Wartungsfall sind alle Daten der Festplatte dem Wartungstechniker zugänglich. Zur Abwehr von Fall a muß das Starten des PC nur für Befugte möglich sein. Dies kann organisatorisch durch Kontrolle des Zugangs erreicht werden; w o dies nicht möglich oder nicht ausreichend wirksam ist, können folgende technischen Lösungen diskutiert werden: a . l ) Nutzung eines ggf. vorhandenen BIOS-Paßworts. Dieser Schutz hilft nur kurzfristig, da durch Abklemmen der CMOS-Batterie der Rechner zum "Vergessen" des Paßworts verleitet werden kann. a.2) Nutzung einer Sicherheitssoftware, die auf der Festplatte installiert ist und beim Start des Rechners zur Eingabe eines Paßwortes auffordert; sie gibt die weitere Bedienung erst frei, wenn ein gültiges Paßwort eingegeben wurde. Dieser Schutz ist nur von beschränktem Wert, da Unbefugte mit einer eigenen Boot-Diskette den Rechner starten und somit die erst beim Festplatten-Boot aktivierte Sicherheitssoftware umgehen können; eine partielle Lösung ist das Vorschreiben der Boot-Reihenfolge in der BIOS-Konfiguration: Es gilt aber hinsichtlich der Schutzwirkung das unter a.l Gesagte. Deshalb muß diese Alternative a.2 "verstärkt" werden: a.2.1) Wie a.2, aber zusätzlich wird eine Bootschutz-Hardware eingesetzt; sie erlaubt nur das Booten von der Festplatte. Nachteil: Diese Ergänzung kann leicht ausgebaut werden und ist damit nur von beschränkter Sicherheit. a.2.2) Wie a.2, die Sicherheitssoftware verschlüsselt zusätzlich alle Nutzdaten (Dateien) auf der Festplatte - aber nicht die Systemspuren; der erforderliche

27

Single-User

1. Beispiele aus der Praxis

Schlüssel wird beim Booten abgefragt oder ist sicher (!) gespeichert. Dem Unbefugten wird zwar der Start des Rechners nicht verwehrt - ein lesender Zugriff auf Nutzdaten ist aber nicht möglich. Daten können jedoch überschrieben oder zerstört werden. Desweiteren können "Experten" in manipulativer Absicht ein trojanisches Pferd einbauen, da der gesamte Boot-Vorgang im unverschlüsselten Modus abläuft. Auf diese Weise ist letztendlich sogar ein Zugriff auf die gültigen Paßwörter möglich 1 . a.2.3) Wie a.2.2, jedoch ist die gesamte Festplatte einschließlich der Systemspuren verschlüsselt; die Verschlüsselung wird durch einen Hardware-Baustein erbracht; der erforderliche Schlüssel wird von diesem beim Booten abgefragt oder ist sicher (!) gespeichert. Diese Lösung hat eine gute Schutzwirkung gegen unbefugte Kenntnisnahme der Nutzdaten und ist allen anderen vorzuziehen. Allerdings kann auch sie ein Zerstören der Daten (Löschen, Überschreiben) nicht verhindern, wenn die Festplatte ausgebaut, in einen anderen Rechner (zeitweilig) eingebaut und mit den bekannten Utilities am Betriebssystem vorbei beschrieben wird 2 . Für die Bedrohungen b und c sind a.2.2 und a.2.3 ebenfalls als Abwehrmaßnahmen geeignet. Allerdings sind hier auch organisatorische Lösungen denkbar (Bewachung; keine Wartung, sondern direkter Austausch von defekten Komponenten, sichere Lagerung). Nun zu den befugten Nutzern des Systems: Sie müssen vom System zweifelsfrei erkannt werden, sonst wird auch ihnen der weitere Zugriff verwehrt. Eine Lösung ist bereits unter a.2 beschrieben worden (Paßwort); ggf. kann der unter a.2.2 und a.2.3 verlangte Schlüssel mit dem Paßwort identisch sein. In der Bilanz ergeben sich folgende Forderungen: Forderung 1. Unbefugten Benutzern ist z.B. durch ein Paßwort-System oder durch administrative Sicherheitsmaßnahmen der Zugriff zu den Daten des PC zu verwehren. Wird dieser Punkt technisch im PC gelöst, sollte eine Protokollierung der erfolgreichen und nicht erfolgreichen Anmeldeversuche stattfinden, um Eindringversuche unbefugter Benutzer zumindest nachträglich erkennen zu können. Sind allerdings solche Versuche aufgrund von Paßwortdiebstahl erfolgreich gewesen, kann natürlich nichts Außergewöhnliches registriert werden: Für den PC bzw. die Sicherheitssoftware ist der "Hacker" dann identisch mit dem autorisierten Benutzer. Hier kann der "richtige" User später anhand der Aufzeichnungen von Datum und Uhrzeit unter Umständen erkennen, daß sich jemand anderes für ihn ausgegeben hat. Diese Funktion wurde früher als Protokollierung, wird heute aber meistens als Beweissicherung bezeichnet.

1

Dieser Angriff soll hier nicht weiter detailliert beschrieben werden.

2

Physische Zerstörung ist grundsätzlich immer möglich (mechanischer Schock, starke Magnetfelder) !

28

1.2 Einzelaspekte bei speziellen Systemen

Forderung 2. Der Schutz der auf der Festplatte gespeicherten Daten gegen unbefugte Kenntnisnahme muß auch in Ausnahmefällen (Wartungsfall, PC-Diebstahl, Direktzugriff auf die Daten unter Umgehung des Betriebssystems) gegeben sein, was durch Verschlüsselung der Festplatte erreicht werden kann. Wie im Fall des Zuschließens eines Raums muß die Platte unter Einsatz eines Schlüssels (Folge von Zeichen) gegen Zugriff gesichert werden: Offene Daten

Verschlüsselungsbaustein

^

geheimer Schlüssel

(Software / Hardware)

M/ Verschlüsselte Daten

Abbildung 1-2: Prinzipielle Funktion eines Verschlüsselungsbausteins Der hierzu nötige Schlüssel muß entweder durch die autorisierte Person manuell eingegeben werden, geschützt gespeichert sein oder aus für Dritte nicht rückverfolgbaren Daten berechnet werden können - andernfalls stellt er kein Geheimnis dar. Die Maßnahme unter 1. verhindert natürlich nicht, daß man mit entsprechenden technischen Einrichtungen (Hardware und Software) die Daten auf der Festplatte lesen kann. Eine Verschlüsselung aller Daten auf der Festplatte macht dies aber zunächst unmöglich. Eine Verschlüsselung allein reicht aber auch nicht aus, da im Normalbetrieb ja zwischen autorisierten und nicht autorisierten Personen unterschieden werden muß - nur letzteren soll das Arbeiten mit dem Rechner gestattet werden. In der Summe werden also die Sicherheitsfunktionen Identifizierung und Authentisierung - kurz: I & A -, ggf. die Beweissicherung sowie die Verschlüsselung der Festplatte gefordert. Je nach den Ergebnissen der Bedrohungsanalyse kann auch der Schutz von Daten auf wechselbaren Datenträgern (Disketten, Tapes) vor unbefugtem Lesen, Kopieren, Weitergeben usw. gefordert sein. Mit der Verschlüsselung von Datenträgern erledigt sich auch oft das Problem der "Nutzung" von Programmen und Daten auf dem Privat-PC des Mitarbeiters. Dieser PC ist nicht in der Lage, die kopierten, aber verschlüsselten Datenträger zu lesen.

29

I&A

Private Nutzung

1. Beispiele aus der Praxis

Single User f" Verschlüsselung

ö .

I ox)

Abbildung 1-3: "Sichere" Single-User Station Multl-User

Wiederaufbereitung

Beweissicherung

Einsatzumgebung

Etwas komplizierter liegt der Fall, daß mehrere befugte Nutzer des PC mit unterschiedlichen Rechten existieren. Über die Maßnahmen 1. und 2. hinaus gilt folgendes: Die Authentisierung muß stets technisch, also im PC realisiert werden. Ein Betriebssystem muß ja zunächst sicher wissen, wer Daten anfordert, bevor es entscheiden kann, ob der Zugriff erlaubt wird. Eine organisatorische Lösung scheidet also aus! Forderung 3. Eine Zugriffskontrolle muß sicherstellen, daß nur erlaubte Zugriffe ausgeführt werden. Eine Zugriffskontrolle verwaltet normalerweise eine matrixartige Tabelle mit Namen von Benutzern und Dateien. Darin werden die erlaubten Zugriffsarten eingetragen. Jeder PC-Benutzer weiß, daß das Löschen von Dateien nur den Datei-Namen im Directory als ungültig deklariert: der Name selbst bleibt teilweise erhalten, vor allem aber sind die Daten der Datei physisch immer noch vorhanden. Da solche Dateien mit üblichen Hilfsmitteln des Betriebssystems restauriert oder durch Nutzung bekannter Utilities direkt gelesen werden können, ist eine physische Löschung z.B. durch Überschreiben mit einem Zufallsmuster erforderlich. Im einfachsten Fall muß das Löschen von Dateien auf DOS-Ebene mit einem Überschreiben des Dateibereichs verbunden werden. Diesen Vorgang nennt man Wiederaufiereitung des Speicherplatzes. Wird dies nicht durchgeführt, macht eine Zugriffskontrolle wenig Sinn, da jeder Nutzer wie beschrieben die Daten anderer Nutzer für sich lesbar machen kann. Somit folgt: Forderung 4. Es ist erforderlich, Speicherbereiche (vor allem auf der Festplatte) wiederaufzubereiten, bevor Speicherplatz anderen Nutzern zur Verfugung gestellt wird. Sofern später Nachweise über die Dateizugriffe der Benutzer benötigt werden, sind vom Betriebssystem Aufzeichnungen über diese Vorgänge anzulegen: Forderung 5. Es sind Aufzeichnungen über erfolgte und ggf. über versuchte Dateizugriffe zu machen (Beweissicherung). Da PCs von Natur aus "offene Systeme" sind, müssen für sensitive Anwendungen gewisse Randbedingungen gestellt werden. Wesentlicher Punkt ist, daß das

30

1.2 Einzelaspekte bei speziellen Systemen

Öffnen des PCs und Eingriffe in die Hardware, unerlaubte Mitnahme oder Einbau/Ausbau einzelner Systemteile unterbunden werden oder zumindest registrierbar sein müssen.

MultiUser

Abbildung 1-4: "Sichere" Multi-User-Station Die aufgezählten Forderungen unter Single-User und Multi-User lassen sich durch auf dem Markt erhältliche PC-Sicherheitsprodukte abdecken - wenn auch mit zum Teil sehr unterschiedlichem Sicherheitsniveau. Man beachte die Diskussion der Fälle unter a.l, a.2 im Fall Single-User und messe hieran die Sicherheit der sogenannten PC-Sicherheitsprodukte. Die zuvor beschriebenen Maßnahmen schützen vor dem Verlust der Vertraulichkeit der gespeicherten Daten. Der Schutz vor unbefugten Änderungen der Software auf dem PC (z.B. durch Viren) ist ein zweites Sicherheitsziel. Dieses Ziel kann im PC-Bereich wie schon angedeutet nur begrenzt erreicht werden. In Abschnitt 1.5 sind wichtige Verhaltensweisen und Verfahren beschrieben. Ein Manipulationsschutz für das Betriebssystem und weitere sensitive Software könnte technisch wie folgt realisiert werden: Eine mit EPROMs bestückte Erweiterungskarte enthält diese sicherheitsempfindlichen Software-Anteile. Das Betriebssystem wird von hier aus gebootet, wodurch ein sicherer Systemstart gewährleistet ist. Die EPROM-Karte wird in der Folge vom Betriebssystem als logisches Laufwerk verwaltet. Von dort kann weitere "manipulationssichere" Software geladen werden. Als Vorteil ergäbe sich, daß die Ladezeiten für die Software sehr kurz werden - zumindest ein Beispiel, in dem Sicherheit nicht immer auf Kosten der Performance gehen muß. Man beachte, daß der Schutz nur für die gespeicherte Software gilt; sobald sie im Arbeitsspeicher abläuft, ist sie wieder vollkommen ungeschützt... Generell stellt sich im PC-Bereich mit den Betriebssystemen MS-DOS und OS/2 das Problem, daß durch Aufsetzen von Sicherheitsprodukten ein unsicheres Betriebssystem nur graduell verbessert werden kann. Die wahrlich nicht nebeneffektfreien Schnittstellen dieser Betriebssysteme zu den Anwendungen sind wenig gesichert und darüber hinaus unvollständig dokumentiert. Das

31

Integritätsverlust

Manipulationsschutz, sicherer Systemstart

Käseglocke

1. Beispiele aus der Praxis

OS/2, W i n d o w s N T

Single Sign-On

Aufsetzen von Sicherheitsprodukten - die sogenannte Strategie der Käseglocke - stellt nur einen Notbehelf dar. Neue Entwicklungen auf dem Betriebssystem-Sektor (OS/2 ab Version 2.2, Windows NT) lassen hoffen, daß die aufgezählten Sicherheitsfiinktionen in den gängigen Betriebssystemen der Zukunft integriert und damit in der Breite nutzbar sein werden, ohne zusätzliche Produkte kaufen und einbauen zu müssen. Fazit: Dem Problem der PC-Sicherheit kann man sich auf verschiedenen Wegen nähern. Durch organisatorische Maßnahmen ist eine erste Sicherheitsstufe erreichbar. Durch eine Kombination mit marktgängigen Sicherheitsprodukten erreicht man eine Stufe, auf der Manipulanten mit geringen Ressourcen (Zeit, Geld, Kenntnissen) auch geringe Chancen haben. Gegenüber ernsthaften Manipulationsversuchen durch "Experten" werden aber erst die neuen Architekturen wirksamen Schutz bieten können. 1.2.3 Sicherheit in PC-LANs Unter dieser Überschrift sollen stichwortartig Sicherheitsprobleme in einem lokalen Netzwerk (LAN) mit PCs als Arbeitsstationen diskutiert werden. Dabei wird von folgenden Rahmenbedingungen ausgegangen: Die im Netz integrierten Arbeitsstationen seien vom Typ Applikationsrechner (vgl. 1.2.1), zu denen jeweils mehrere Benutzer Zugang haben; das Netzwerk besitze einen File-Server, der nicht als Arbeitsstation genutzt wird. Was ist in dieser Konfiguration zu sichern? Die einzelnen Arbeitsstationen sollten wie im voranstehenden Abschnitt geschildert abgesichert werden. Die getroffenen Sicherungsmaßnahmen sind mit den für das Netz geltenden Sicherungsmaßnahmen abzustimmen - was nicht unproblematisch ist. Verlangt z.B. das lokal installierte Schutzprodukt vom Benutzer ein Paßwort, so muß dieser beim Login in das Netz eventuell ein zweites Mal ein Paßwort eingeben. Sind mehrere Server oder andere Stationen über Gateways erreichbar, müssen unter Umständen sehr viele Paßwörter abgefragt werden - was bei den Nutzern des Netzwerks meist zu sehr geringer Akzeptanz führt. Hier wird deshalb die Forderung nach einem einzigen Anmeldevorgang gestellt: Die Arbeitsstation fragt ein Paßwort ab und generiert daraus - transparent für den Nutzer - entsprechende Anmeldevorgänge für alle gewünschten Stationen. Es ist klar, daß mit diesem Single Sign-On Sicherheitsprobleme verbunden sind: Hat der Benutzer ein einheitliches Paßwort für alle Systeme, ist bei Kompromittierung dieses Paßworts ein großes "Scheunentor" aufgerissen. Werden für das automatische Anmelden unterschiedliche Paßwörter verwendet, müssen diese zwangsläufig lokal gespeichert werden - was natürlich besonders kritisch zu bewerten ist. Lösungen für diese Problematik sind die Verwendung von Challenge-Response-Verfahren für die netzweite Anmeldung (das lokale Paßwort ist die geheime Information, vgl. Abschnitt 1.4.2) oder die geschützte lo-

32

1.2 Einzelaspekte bei speziellen Systemen kale Speicherung der verschiedenen Paßwörter (etwa durch Verschlüsselung mit dem lokalen Paßwort als Schlüssel). Unter Umständen kann eine lokale und netzweite Sicherung dadurch erreicht werden, daß keine der Arbeitsstationen über Disketten- oder Plattenlaufwerke verfugt, sondern das Betriebssystem und alle Applikationen von einem Server geladen werden. Hierdurch ist ein sicherer Systemanlauf für die Arbeitsstation sichergestellt; Zugriffsrechte zu Dateien werden durch das Server-Betriebssystem kontrolliert. Das Sicherheitsproblem ist damit weitgehend auf den Server verlagert. In diesen Fällen, aber auch grundsätzlich für Server in einem Netzwerk sind folgende Forderungen zu stellen: Forderung 1. Fernhalten unbefugter Benutzer z.B. durch ein Paßwort-System (Authentisierung). Forderung 2. Registrierung der Anmeldeversuche und der (versuchten) Ausübung von Rechten (Beweissicherung). Forderung 3. Vergabe und Prüfung von Zugriffsrechten auf Datei- bzw. Directory-Ebene (Zugriffskontrolle). Forderung 4. Wiederaufbereitung von Speichern - zumindest dann, wenn Benutzer auf dem Server Applikationen zum Ablauf bringen können (Wiederaufbereitung). Forderung 5. Wahrung der Betriebssystem-Integrität. Forderung 6. Übertragungssicherung auf dem Transportsystem (Verkabelung, Funk). I&A

J

Zugriffskontrolle

LANServer

Beweissicherung ^Wiederaufbereitung System-Integrität itat (

J

Verschlüsselung (Datenpakete)

LAN-Anschluß

Abbildung 1-5: "Sichere" Server-Station in einem LAN Die ersten drei Anforderungen sind bei den üblichen Betriebssystemen von PCNetzwerken funktionell meistens erfüllbar. Bei der Anforderung 4 sieht es schon schlechter aus.

33

Diskless Workstal

1. Beispiele aus der Praxis

Massivste Sicherheitsprobleme gibt es aber, da weder eine ausreichende Integritätswahrung noch eine verschlüsselte Übertragung von Nutz- und Verwaltungsdaten vorhanden sind. Verfügbarkeit

C2

Datenschutz

Auch die in diesem Abschnitt nicht weiter diskutierte Verfügbarkeit des Netzes ist nicht ausreichend gewährleistet: Benutzer können die Ressourcen (Transport, Speicher) so stark in Anspruch nehmen (z.B. Einspielen von DummyDaten), daß andere Benutzer Netzwerkdienste nicht mehr oder nur in vermindertem Umfang nutzen können. Von Übertragungssicherung im engeren Sinne kann also keine Rede sein. Alle neueren Versionen marktüblicher LAN-Betriebssysteme verschlüsseln aber im Rahmen des Anmelde- bzw. Login-Vorgangs zumindest Paßwörter vor dem Transfer zum Server. Die unter 1 - 5 aufgeführten Sicherheitsfunktionen sind typisch für kommerzielle Betriebssysteme (Großrechner, Unix). In Anlehnung an veröffentlichte Sicherheitskriterien werden sie C2-Systeme genannt. Mit diesen Systemen ist es z.B. möglich, den Forderungen des Datenschutzes in technischer Hinsicht weitestgehend zu entsprechen.

1.3 Bewegliche Datenträger Unter beweglichen Datenträgern versteht man Disketten, Wechselplatten, Streamer-Tapes, Magnetbänder usw. Das klassische "Papier" ist hier ebenfalls einzuordnen. Eine technisch neue Entwicklung sind Speichermodule (z.B. mit PCMCIA-Schnittstelle) in der Größe von Scheckkarten, die Speicherkapazitäten von 40 MB und mehr aufweisen können. Im wesentlichen lassen sich vier Problemkreise unterscheiden: Verwalten, Kennzeichnen, Kopieren und Einspielen von Datenträgern.

Registrierung

Wiederaufbereitung

1.3.1 Verwalten von beweglichen Datenträgern Generell ist es bei sensitiver Datenverarbeitung unerläßlich, eine zentrale Registrierung der Datenträger einzurichten. Die ausgegebenen Datenträger, ihre Kennzeichen und ihr Verbleib sind listenmäßig zu erfassen. Verbrauchte, defekte oder aus anderen Gründen nicht mehr zum Einsatz kommende Datenträger sensitiven Inhalts sind zentral zu vernichten bzw. wiederaufzubereiten. Wiederaußereitet sind Datenträger dann, wenn sie anderen Nutzern zur Verfügung gestellt werden können, ohne daß Reste von Daten aus früheren Verwendungen noch lesbar sind. In der Regel heißt dies, daß die Datenträger entweder mit Dummy-Daten zu überschreiben oder durch ein starkes Magnetfeld zu löschen sind. Die gängige Lehrmeinung sagt allerdings, daß nach solchem Löschen ein Restaurieren von "alten" Daten - mit einem allerdings beachtlichen technischen Aufwand und

34

1.3 Bewegliche Datenträger

speziellem Equipment - nicht ganz aussichtslos ist, da die Löschdämpfung begrenzt ist...

Datenträger-Liste

: 1 B V l I

II L J I

Abbildung 1-6: Datenträger-Registrierung Es sei noch daran erinnert, daß im PC-Bereich das Formatieren von Disketten die Inhalte überschreibt - ausgenommen Quick-Format. Dies gilt aber meist nicht für intakte Sektoren von Festplatten. Formatieren ist also hierfür kein Mittel der Wiederaufbereitung - abgesehen vom sogenannten Hard-Formatting. Allen PC-Anwendern bekannte Utilities erlauben aber auch bei Festplatten eine physische Löschung durch Überschreiben. Besonders problematisch stellt sich hier das Problem der Reparatur von defekten Festplatten dar. Ist eine Festplatte vom Betriebssystem nicht mehr lesbar, kann ein defekter Boot- oder Partitionssektor die Ursache sein. Aber auch "harte" Fehler können mit wenig aufwendigen technischen Zusatzeinrichtungen repariert oder umgangen werden. Bei hoch sensitiven Daten ist somit kein Austausch der Festplatte durch den Wartungstechniker tolerierbar, es ist vielmehr eine Neubeschaffung angesagt. Die "alte" Platte ist entsprechend gesichert zu lagern oder zu zerstören! Wie man allerdings auch Anforderungen dieser Art überziehen kann, zeigt folgendes Beispiel, daß so (oder so ähnlich) real stattgefunden hat: Die Vernichtung von Festplatten scheiterte zunächst an den relativ stabilen Gehäusen der Laufwerke. Sie mußten deshalb demontiert werden, um an die eigentlichen Platten heranzukommen. Da eine mechanische Zertrümmerung wiederum ausschied, bot sich als Lösung zur Vernichtung ein Säurebad an, in dem die magnetische Schicht abgelöst werden konnte. Bei diesem Prozeß erhielt man größere Flocken des Beschichtungsmaterials. Der Einwand, man könne noch Daten von diesen Flocken restaurieren, konnte nicht gänzlich ausgeräumt werden, so daß man beschloß, die Flocken zu verbrennen. Damit nicht genug:

35

Formatieren

Festplatten

1. Beispiele aus der Praxis

Die verbleibende Asche einfach in den Müll zu geben, wurde als unpassend (und ökologisch fragwürdig) empfunden. Ein Ausstreuen in einen Fluß oder die Verwendung beim Straßenbau (natürlich nur auf besonders vertrauenswürdigen Straßen) wurden diskutiert...

Einstufung, Sachgebiet

Kennzeichnung

Administration

Attribute

1.3.2 Fehlende Kennzeichnung von Datenträgern Der Wert von Informationen ist in bestimmten Anwendungsbereichen durch e j n e Einstufung wie etwa "Geheim", "Top Secret", "Firmen-vertraulich" oder durch ihre Zugehörigkeit zu Sachgebieten wie "Personaldaten" oder "Kundendatei" gegeben. Ziel ist es, anhand dieser Kennzeichnung von vornherein den Zugriff solchen Personen zu verwehren, die nicht entsprechend ermächtigt oder berechtigt sind. Im Falle des Datenträgers "Papier" geht man einfach so vor, daß durch einen Stempelaufdruck ("Geheim"), wasserzeichenartige Prägung des Papiers oder Kopfzeilen mit entsprechenden Angaben die Einstufung sichtbar gemacht wird. Solche Kennzeichnungen sind bei eingestuften Dokumenten Inhalt der einschlägigen Vorschriften. Es hat nicht an Versuchen gefehlt, solche Verfahren auf Datenträger zu übertragen: Im PC-Bereich verwendet man bei Disketten mangels intelligenterer Lösungen einfachste - allerdings wenig manipulationssichere - Kennzeichnungen durch Klebeschilder, Prägestempel und Lochungen, die der administrativen Kontrolle unterliegen, aber vom IT-System nicht ausgewertet werden können. Aus Erfahrung sei noch erwähnt, daß das mit solchen Aktionen beauftragte Personal darauf hingewiesen werden muß, z.B. Lochungen nur an bestimmten Stellen einer Diskettenhülle vorzunehmen... Die im vorhergehenden Abschnitt angesprochene Datenträger-Verwaltung muß in diesem Zusammenhang natürlich die Einstufungen berücksichtigen und die hierfür notwendigen Vorgaben machen. Bei der automatisierten Verarbeitung eingestufter Dateien und Datenträger m u ß aber eine solche Kennzeichnung im Rahmen der Zugriffskontrolle vom IT-System gelesen werden können. Die Kennzeichnung muß darüber hinaus ausreichend sicher gegen Manipulation geschützt sein. Betriebssysteme müssen deshalb Datenträger und Dateien, die ihrer Verwaltung unterstehen, durch ein entsprechendes Attribut (Einstufung, Sachgebiet) kennzeichnen. Die meisten marktüblichen Betriebssysteme - vor allem im PCBereich - erlauben keine Attribute dieser Art. Anders verhält es sich bei hierauf spezialisierten Betriebssystemen 3 wie etwa bei den sogenannten Compartment Mode Workstations (CMW). Unix- und Großrechner-Systeme mit Namenszusätzen wie ES (Enhanced Security), MLS (Multi-Level-Security) und Trusted sind weitere Beispiele.

3

36

Z u m e i s t sind dies Betriebssysteme, die den Forderungen der B-Klasse des Orange B o o k oder anderer Sicherheitskriterien genügen.

1.3 Bewegliche Datenträger

1.3.3 Unerlaubtes Kopieren von Datenträgern Es sind viele Methoden des Kopierschutzes bekannt, die sich aber allesamt nicht durchsetzen konnten. Das Kopieren kommerziell erhältlicher Produkte ist letztlich technisch nur mit hohem Aufwand zu unterbinden und für den Benutzer mit Unbequemlichkeiten verbunden. Im Kern führt dies auf eine sehr geringe Akzeptanz der Benutzer, der kommerzielle Erfolg eines Produktes kann hieran scheitern... Auch wenn dieser Themenkreis im juristischen Sinne durchaus ein "Sicherheitsproblem" für ein Unternehmen sein kann, soll hier ein anderer Punkt behandelt werden: Durch das Kopieren von Datenträgern kann die Vertraulichkeit von Informationen verletzt werden. Sind sensitive Daten eines Unternehmens zugänglich, so ist es in der Regel eine Angelegenheit von wenigen Sekunden, eine Kopie dieser Daten auf eine Diskette oder auf eine PCMCIA-Speicherkarte zu ziehen. Daten jeder Art können auf diesem Wege leicht das Unternehmen "verlassen". Andererseits ist aber das Anfertigen von Kopien für die Datensicherung oft unerläßlich. Man steht also vor dem Dilemma, daß bei Entzug der individuellen Kopiermöglichkeiten auch keine individuelle Datensicherung mehr durchgeführt werden kann. Eine weitere Folge ist, daß zumindest bei Stand-Alone-Systemen die Installation neuer Software nicht mehr möglich ist. Generell ist zunächst die Frage zu beantworten, welche Personen als "Kopierer" anzusehen sind: Sind es die befugten Benutzer eines Systems selbst? Sind es unbefugte Benutzer? Im ersten Fall ist festzuhalten, daß diese Personen ja legalerweise Zugang zu den gespeicherten Daten haben. Hier kann es also nur darum gehen, ggf. dem "Massenproblem" abzuhelfen: Auf Disketten, Streamer-Tapes, Speichermodulen usw. lassen sich ja große Datenmengen "auf einen Schlag" transportieren. Die Gefahr einer Entdeckung ist auch bei Kontrollen eher gering, da sich die genannten Datenträger wegen ihrer geringen Größe überall leicht "verstauen" lassen. Im zweiten Fall geht es um Personen, die gezielt oder mehr zufällig Gelegenheit finden, Kopien von Datenbeständen zu ziehen, für die sie kein Zugriffsrecht besitzen. Eine nur auf organisatorischen Maßnahmen beruhende Lösung für diesen Fall sieht so aus: Der Rechner steht in einem Raum, zu dem nur berechtigte Mitarbeiter Zugang haben (Raumsicherung durch Schloß). Die Datenträger werden darüber hinaus registriert und verschlossen aufbewahrt. Werden Datenträger zwischen verschiedenen Rechnern ausgetauscht, so muß ihr Verbleib listenmäßig erfaßt werden. Kritik: Diese Lösung verlangt ein gewisses Maß an Sensibilisierung bei den Betroffenen. Die Registrierungspflicht und die Pflicht zum Verschließen der Datenträger und des Raums lassen sich in der Praxis nicht immer so präzise durchhalten. Oftmals ist es sogar erforderlich, daß betriebsfremdes Personal

37

Kopierschutz

Vertraulichkeit

Datensicherung

Organisation

1. Beispiele aus der Praxis

Zentralisierung

Verschlüsselung

(z.B. zu Reinigungszwecken) - auch unbeaufsichtigt - Zutritt zu den betreffenden Räumen haben muß. Folgende Alternative bringt Abhilfe in vernetzten Systemen: Die Arbeitsstationen enthalten keine Kopiermöglichkeiten, d.h. Diskettenlaufwerke sind nicht vorhanden. Damit ist das individuelle Kopieren von Datenträgern ausgeschlossen. Dies hat zur Folge, daß solche Einrichtungen zumindest in zentralen Netzknoten vorhanden sein müssen - sei es zum Zweck der Datensicherung oder zum Einspielen neuer Software. Zwangsläufig unterliegen dann solche Netzknoten ("Netz-Server") strengen Anforderungen an die physische Sicherheit: Sie sind in der Regel gegen Zugang und Zugriff unbefugter Personen in besonderer Weise zu sichern (mehrere Sicherungsstufen). Kritik: Gegenüber der ersten Alternative sind hier die Sicherheitsanforderungen auf die zentralen Netzknoten verlagert worden, zu denen ja in der Regel nur wenige - allerdings dann um so vertrauenswürdigere (!) - Personen Zugang haben müssen. Die Vernetzung von Arbeitsplatzrechnern wirft aber ihrerseits neue Sicherheitsprobleme auf (Abschnitt 1.2). Meist ergibt sich für die Arbeitsstationen noch das Problem, daß ihre frei zugänglichen Schnittstellen verplombt oder funktionsuntüchtig gemacht werden müssen, um ein Kopieren der Daten hierüber auszuschließen. Eine dritte Alternative ist der Einsatz von Verschlüsselungstechniken: Hierzu wird ein "sicheres" Verschlüsselungsverfahren benötigt, das in der Regel durch eine Kombination von Hard- und Software in einem Rechner realisiert wird. Produkte dieser Art sind auf dem Markt erhältlich. Ein solches Produkt muß so aufgebaut sein, daß a) pro Datenträger ein vom Benutzer auszuwählender Schlüssel vergeben werden kann, b) das im Rechner eingebaute Verschlüsselungssystem einen weiteren, gerätespezifischen Schlüssel besitzt, der z.B. in der Verschlüsselungshardware auslesegeschützt untergebracht sein muß. Im laufenden Betrieb werden nun Datenträger nur verschlüsselt beschrieben und beim Lesen wieder entschlüsselt. Das Ver- und Entschlüsseln muß für den Benutzer transparent sein, d.h. der gesamte Vorgang muß sich für ihn wie eine normale Lese- und Schreiboperation darstellen. Wirksam ist bei jeder Operation die Kombination aus dem vom Benutzer gewählten Schlüssel und dem gerätespezifischen Schlüssel.

38

1.3 Bewegliche Datenträger

Datenträger

1H !D*### /fv

Schlüssel für den Datenträger

1 Verschlüsselungsbaustein (Software / Hardware)

'

gerätespezifischer Schlüssel

]

Abbildung 1-7: "Sichere" Datenträger-Verschlüsselung Zwar ist das Kopieren einer so verschlüsselten Diskette nicht prinzipiell ausgeschlossen, das Entschlüsseln der Daten ist aber auf einem zweiten Rechner nicht möglich: Selbst wenn - wie im Fall 1 - der Benutzerschlüssel bekannt ist und auf dem zweiten Rechner der gleiche Typ von Verschlüsselungseinrichtung benutzt wird, besitzt das zweite Gerät nicht den gleichen Geräteschlüssel. Die einzige Möglichkeit, um dennoch an die Daten heranzukommen, besteht in der Entwendung des Verschlüsselungsbausteins von Rechner 1 oder im Extremfall des gesamten Rechners. Kritik'. Die beschriebene Alternative verlangt ein technisch hochwertiges Verschlüsselungssystem, das eine hohe Verschlüsselungsgeschwindigkeit besitzen muß und nicht nur auf Software basieren sollte. Die Geräteschlüssel müssen durch vertrauenswürdige Stellen produziert werden. Das Lesen unverschlüsselter Datenträger (Einspielen von Standardsoftware oder Daten) muß möglich sein. Beim Anwender ist außerdem ein entsprechendes Schlüsselmanagement erforderlich, um in der Praxis die erwünschte Wirkung zu erzielen und ein Mindestmaß an Austauschbarkeit von Datenträgern innerhalb des Unternehmens zu gewährleisten. Insgesamt sind hohe Kosten und Aufwand in der Organisation in Kauf zu nehmen.

39

1. Beispiele aus der Praxis

Virenproblem

Korrekte Funktions-

1.3.4 Einspielen von unbekannten Datenträgern Besonders kritisch sind Datenträger, deren Inhalt unbekannt ist oder bei denen der Zweck und erst recht die Sicherheitseigenschaften der gespeicherten Programme unbekannt ist. Datenträger dieser Art können Träger von Programmen mit Schadenfunktionen, insbesondere Computer-Viren sein. Solche Datenträger dürfen nicht in Systeme mit sensitiven Daten eingespielt werden. Einspielen bedeutet in diesem Zusammenhang schon das Einlegen eines Datenträgers (z.B. Diskette) in ein Laufwerk und das Starten eines gespeicherten Programms, insbesondere das Booten von einem solchen Datenträger. Was die funktionelle Sicherheit anbetrifft, also die Garantie der korrekten Funktionsweise, sollten auf isolierten Anlagen Tests gefahren werden, bevor neue Software z.B. in ein LAN eingespielt und den Benutzern zur Verfügung gestellt wird. Das Ausprobieren von Software auf Anlagen, die für die Verarbeitung sensitiver Daten gedacht sind, muß unterbleiben. Es sind Fälle bekannt, in denen z.B. Computer-Viren auf Public Domain Disketten, aber auch auf Originaldisketten von renommierten Herstellen gespeichert waren... Das umfangreiche Gebiet der Programme mit Schadenfunktionen wird im Abschnitt 1.5 behandelt.

1.4 Berechtigungen und Kontrollen Zugangskontrolle

Zugriffskontrolle

Identifizierung, Authentisierung

Unter Zugangskontrolle versteht man die Kontrolle des physischen Zugangs: Personen sollen sich nicht unkontrolliert einem IT-System, einem DatenträgerArchiv usw. nähern können. Gelegentlich wird die Authentisierungsfiinktion in einem Rechner noch der Zugangskontrolle zugerechnet. Die Zugriffskontrolle soll den logischen Zugriff innerhalb eines Rechners oder Netzwerks auf bestimmte Daten kontrollieren. Personen, die zwar prinzipiell autorisiert sind, mit dem IT-System zu arbeiten, sollen aber nur solche Programme und Daten im Zugriff haben, die für sie freigegeben sind. Eine wirksame Zugriffskontrolle setzt zunächst voraus, daß Benutzer sich gegenüber dem betreffenden IT-System • identifizieren = eine Namen/eine Identität nennen und • authentisieren = ihre Identität nachweisen. Somit sind die Funktionen Identifizierung und Authentisierung zentraler Bestandteil "sicherer" IT-Systeme. Technisch kann die Authentisierung z.B. durch die Kenntnis geheimer Paßwörter, PINs 4 oder Schlüssel, durch Besitz bestimmter Gegenstände (Chipkarten,

g e h e i m e Zahlenkombination (PIN = Personal Authentication N u m b e r )

40

1.4 Berechtigungen und Kontrollen

Tokens) oder durch eindeutige Merkmale (biometrische Eigenschaften wie Fingerabdrücke, Retina-Muster,...) realisiert werden. Die Identifizierung und Authentisierung kann auch durch organisatorische Maßnahmen realisiert werden, indem etwa eine Zugangskontrolle die Prüfung von Personalausweisen als Nachweisverfahren nutzt. Problematisch ist hierbei allerdings, daß das IT-System selbst keine Kenntnis von dem Ergebnis dieser Prüfung erhält, so daß es alle Nutzer grundsätzlich als autorisiert und gleichberechtigt akzeptieren muß: Eine personenbezogene differenzierte Rechtevergabe für den Zugriff auf einzelne Dateien ist auf dieser Basis nicht möglich. Fazit: Sobald wir die übliche Multi-User-Problematik haben - eine Vielzahl von Nutzern mit unterschiedlichen, zu kontrollierenden Rechten -, kann nur noch eine Zugriffskontrolle durch das Betriebssystem des Rechners oder des Netzwerks helfen. 1.4.1 Paßwort-Management Ein sehr verbreitetes Verfahren zur Authentisierung stellt das User-ID/Paßwort-Schema dar. Hierbei identifiziert sich ein Benutzer durch Angabe seines Namens und authentisiert sich durch Angabe eines (hoffentlich) nur ihm bekannten Paßworts. Sicherheitsrelevante Aspekte des Paßwort-Verfahrens sind die Vergabe-Art. Länge und Zeichenvorrat der verwendeten Paßwörter, Ausschlußlisten über gängige Paßwörter, Ersatzpaßwörter. Paßwortwechsel und -historie. geschützte Speicherung der Paßwörter, Regeln der Paßwort-Verwaltung bei neuen, ausscheidenden, als Vertretung agierenden Mitarbeiter, Merkbarkeit von mehreren Paßwörtern in heterogener Systemumgebung. Bei zentraler Vergabe von Paßwörtern ist ein hoher Aufwand in der Administration erforderlich. Es muß erfahrungsgemäß eine permanent ansprechbare Stelle vorhanden sein, die neue Paßwörter vergibt und den regelmäßigen Wechsel durchführt. Die Urlaubszeit bringt hier besonderen Arbeitsanfall, da viele Mitarbeiter verständlicherweise ihre Paßwörter vergessen haben, wenn sie sich nach mehrwöchigem Urlaub erstmalig ihrem IT-System nähern... Bei räumlich verteilten IT-Systemen (etwa Unternehmen mit Filialen an vielen verschiedenen Orten) muß eine dezentrale Vergabe eingerichtet werden. Solche Probleme fuhren meistens dazu, daß man es lieber den einzelnen Benutzern selbst überläßt, sich Paßwörter auswählen. Dann ist aber eine Unterweisung der Benutzer unerläßlich: Es ist ein gesteigertes Sicherheitsbewußtsein beim Umgang mit Paßwörtern nötig, um ein Mindestmaß an Sicherheit erreichen zu können. Ganz ohne Zentralismus kommt man allerdings auch hier nicht aus: Bei der Neuinstallation von Rechnern oder im Falle des Vergessens von Paßwörtern muß stets eine autorisierte Person ein neues Paßwort einrichten können...

41

Vergabe

1. Beispiele aus der Praxis

Paßwortlänge

In der Theorie ist es sinnvoll, Paßwörter größerer Länge zu verwenden, um die

Sonderzeichen

Zahl möglicher Kombinationen zu vergrößern, was wiederum die Erfolgsaussichten für "Paßwortdiebstahl durch Ausprobieren" vermindert. In der Praxis sieht das aber so aus: Je länger Paßwörter sind, desto höher ist die Wahrscheinlichkeit, daß sie irgendwo schriftlich niedergelegt werden. (Klebeschild am Bildschirm, unter der Tastatur,...). Kurzum: Theorie und Praxis stehen hier in einem gewissen Widerspruch! Gelegentlich werden 6-8 Zeichen für Paßwörter als ausreichend bezeichnet. Solche allgemeinen "Regeln" taugen wenig: Im Kern ist die Frage zu beantworten, in welchem Verhältnis die Mindestlänge und der Zeichenvorrat für die Wahl der Paßwörter stehen. Besteht der Zeichenvorrat z.B. nur aus Großbuchstaben A-Z, so sind insgesamt 6-8 Zeichen kaum als sicher anzusehen - zumal Paßwörter selten als zufällige Zeichenkombination, sondern als merkbare Wörter gewählt werden. Dies schränkt die Zahl der Kombinationsmöglichkeiten noch einmal erheblich ein. Vielfach wird empfohlen, bei der Wahl von Paßwörtern Sonderzeichen zu ver-

Ausschlußliste

wenden. Es gibt bspw. Regeln wie "im Paßwort muß mindestens ein Sonderzeichen enthalten sein". Tatsächlich ist eine solche "globale" Regel - wenn sie allgemein und damit auch im Kreis der potentiellen Manipulanten bekannt ist eher von Nachteil: Die Kenntnis dieser Tatsache ist eine Information, die statistisch die Zahl der auszuprobierenden Bits vermindert. Je umfangreicher und somit je informationsträchtiger - solche Regeln sind, desto mehr erleichtert man den Paßwortdiebstahl. Eine Regel wie "Das Paßwort muß aus sechs Zeichen bestehen, erstes Zeichen ein Großbuchstabe, weiterhin mindestens zwei Ziffern und ein Sonderzeichen" vermindern die Zahl möglicher Kombination leicht um den Faktor 1000 ! Selbst wenn die Parameter Zeichenvorrat und Paßwortlänge vernünftig festge-

Zeichenvorrat

Ersatzpaßwörter

legt sind, zeigt die Praxis, daß als Paßwörter gerne Namen von Personen, Städten, Autokennzeichen, Jahreszeiten usw. gewählt werden. Ein vernünftiges Paßwort-Management muß deshalb eine Ausschlußliste beinhalten, die bei der Paßwortauswahl Beschränkungen auferlegt. Gängige Paßwörter müssen abgelehnt werden. Viele Systeme werden mit voreingestellten Paßwörtern (default) ausgeliefert. Dies gilt insbesondere für Rollen wie den System-Verwalter und die SoftwareWartung. Solche Default-Paßwörter werden auch eingestellt, wenn ein SystemVerwalter neue Benutzer in ein System einbringt. In allen diesen Fällen muß durch technische oder organisatorische Maßnahmen gewährleistet sein, daß beim ersten Anmeldevorgang die betreffenden Benutzer zur Wahl neuer Paßwörter aufgefordert werden. Diese Maßnahme ist aber allein nicht ausreichend. Es sind Fälle bekannt geworden, in denen deshalb kein Wechsel der Default-Paßwörter vorgenommen wurde, weil sich die betreffenden Benutzer über einen längeren Zeitraum gar nicht im System anmeldeten. Das voreingestellte Paßwort (typischerweise die

42

1.4 Berechtigungen und Kontrollen

User-ID) konnte somit über längere Zeit von "jedermann" benutzt werden. Als Maßnahme ist hier vorzusehen, daß beim Einrichten neuer Benutzer in einem System sofort der erste Anmeldeversuch mit Wechsel des Paßworts durchgeführt werden muß. Daß ein Benutzer in regelmäßigen Abständen sein Paßwort ändern sollte, ist bei den vielen Schwachstellen der Paßwort-Methode ein Muß. Er kann nicht darauf vertrauen, daß sein Paßwort über längere Zeit ein Geheimnis bleibt. Es kommt z.B. öfter vor, daß besonders "schnelle" Mitarbeiter ihre User-ID und ihr Paßwort mit hoher Geschwindigkeit eintippen und dabei nur auf ihre Tastatur schauen; irgendein Fehlerzustand kann bewirken, daß gar nicht wie erwartet die dunkelgesteuerte Zeile für das Paßwort angezeigt wird, sondern das System immer noch bei der offen angezeigten User-ID Zeile ist; Resultat: Das geheime, bereits eingetippte Paßwort erscheint offen auf dem Bildschirm! Freude bei den in der Nähe sitzenden Kollegen! Das Intervall zum Wechseln der Paßwörter darf andererseits nicht zu kurz gewählt werden, da sonst nach einiger Zeit keinem Benutzer mehr vernünftige Paßwörter einfallen oder sie dazu neigen, "neue" Paßwörter zyklisch aus einer kurzen Liste zu wählen. Diese "Bedrohung" hat dazu geführt, daß in vielen Betriebssystemen eine Paßwort-Historie geführt wird: Wählt der Benutzer ein Paßwort, das von ihm bereits schon früher verwendet wurde, wird es abgelehnt. Man sollte sich informieren, wie viele Paßwörter in dieser Historie gespeichert werden... Generell kann es von Vorteil sein, wenn das Betriebssystem bei jedem LoginVorgang Datum und Uhrzeit des vorhergehenden Login-Vorgangs des gleichen Benutzers anzeigt. Der betreffende Mitarbeiter hat dann die Möglichkeit, nicht vom ihm selbst ausgeführte Logins unter seiner User-ID zu erkennen und schleunigst sein Paßwort zu ändern... Auf die Paßwort-Liste dürfen nur dazu autorisierte System-Verwalter zugreifen können. Dabei wäre es absolut sinnvoll, nur schreibenden Zugriff zu gestatten: Die Aufgabe des System-Verwalters sollte sich auf die Vergabe von Erst-Paßwörtern für neue Benutzer, die Vergabe von Paßwörtern im Falle des Vergessens sowie das Anlegen und Löschen der Verwaltungsdaten für neue bzw. ausscheidende Benutzer beschränken. Da die Paßwort-Liste in einer Datei gespeichert ist, kann die Zugriffskontrolle des Betriebssystems garantieren, daß die betreffende Paßwort-Datei nur dem System-Verwalter (ggf. nur schreibend) zugänglich ist. Ist eine Verwehrung des Lesens nicht möglich, kann die Kenntnisnahme von Paßwörtern durch den System-Verwalter (und ggf. durch Unbefugte) auch durch die Verschlüsselung der einzelnen Paßwörter ausgeschlossen werden. Dabei wird in aller Regel eine sogenannte Einwegverschlüsselung verwendet. Hierunter versteht man mathematische Verfahren, bei denen man verschlüsselte Daten nicht mehr entschlüsseln kann. Das unverschlüsselte Paßwort wird ja

43

Paßwortwechsel

Paßwort-Historie

Login-Historie

Zugriffe

Einwegverschlüsselung

1. Beispiele aus der Praxis

Lexikon-Angriff

auch nicht mehr benötigt: Soll nämlich ein eingegebenes Paßwort auf Gültigkeit geprüft werden, werden die eingegebenen Zeichen zunächst verschlüsselt; das Ergebnis wird sodann mit den Eintragungen der Paßwort-Liste verglichen. Bei Übereinstimmung ist davon auszugehen, daß die unverschlüsselten Paßwörter identisch sind (s. Abbildung 1-8). Auf eine mathematische Diskussion von Verschlüsselungsverfahren soll in diesem Buch verzichtet werden. Der interessierte Leser findet aber in (RUL93) ein sehr gute Einfuhrung. in vielen älteren Unix-Betriebssystemen sind die Paßwörter zwar (einweg-) verschlüsselt, stehen aber in einer allgemein zugänglichen Datei. Die Verschlüsselung schützt zwar vor Kenntnisnahme der Paßwörter, macht aber den sogenannten Lexikon-Angriff möglich: Eine Liste der häufigsten Paßwörter wird angelegt; alle Eintragungen dieser Liste werden als Paßwörter verschlüsselt; danach werden die so gewonnenen Werte mit den verschlüsselten Eintragungen in der Paßwort-Datei verglichen. Die Treffer-Rate dürfte im allgemeinen recht hoch sein... Dieses "Verfahren" kann auf einem zweiten Rechner mit gleichem Betriebssystem (unter gewissen, hier nicht weiter ausgeführten Voraussetzungen) "in aller Ruhe" durchgespielt werden. Folgerung: Sofern man die Wahl hat, sollte man sich für solche Betriebssysteme und Betriebssystem-Versionen entscheiden, bei denen entweder die sicherheitsrelevanten Verwaltungsdaten nicht der normalen Dateiverwaltung unterliegen oder die Zugriffsrechte zu ihnen auf wenige Personen bzw. Rollen und dabei auf ein notwendiges Mindestmaß beschränkt sind.

eingegebenes Paßwort

Liste

User

->

Verschlüsselung

verschlüsseltes Paßwort

Meier

XC6&0\ä.

Schulze

zz:l1%&77

Vergleich

Abbildung 1-8: Einwegverschlüsselung von Paßwörtern Heterogene Systeme

In Unternehmen mit heterogener System-Umgebung, in der z.B. Personal Computer als Arbeitsstationen in einem LAN integriert sind und dabei auf Unix-Rechner und Großrechner über Standardprotokolle (z.B. TerminalEmulation, File-Transfer) durchgreifen können, ergibt sich ein ganz einschneidender Konflikt: Mitarbeiter, die Zugriff zu mehreren Systemen

44

1.4 Berechtigungen und Kontrollen

haben sollen, müssen sich entsprechend viele Paßwörter "merken". Dies fuhrt in der Praxis zu der bekannten "Zettelwirtschaft" oder ähnlich unsicheren Methoden. Oft werden von den betreffenden Benutzern Listen solcher Paßwörter in Dateien aufbewahrt - zur besonderen Freude der Hacker, die sich dieser Informationen gerne annehmen... Um der geschilderten Problematik vieler unterschiedlicher Paßwörter zu begegnen, werden zwei Verfahren verfolgt: 1. Je Benutzer wird ein einheitliches Paßwort fiir alle Netzknoten eingerichtet. Die vollständige Paßwort-Liste ist auf allen Knoten des Netzes gleichermaßen vorhanden. Entsprechende Systemprogramme in den Workstations sorgen in sinnvollen Abständen für die Synchronisierung der Paßwort-Listen auf den verschiedenen angeschlossenen Rechnern. Problem: Gelingt der "Einbruch" in eines der Systeme z.B. durch Erraten eines Paßwortes, so ist wegen der Paßwortgleichheit der Durchbruch zu allen übrigen geschafft. Somit fallt infolge der Synchronisation die "Sicherheit" des gesamten Systems. Abgesehen von der Frage, ob die Synchronisierungsdienste selbst ausreichend sicher sind - sie müssen schließlich hochsensitive Informationen (Paßwörter oder andere Berechtigungen) über ein Netz austauschen -, haben die einzelnen Rechner in der Regel einen unterschiedlich hohen Sicherheitsstandard. Es mag deshalb vorkommen, daß bei einem Rechner aufgrund schwächerer Sicherungsverfahren ein Zugriff zur Paßwort-Liste eher gelingt als bei den anderen Systemen... Die Synchronisation von Paßwörtern ist also nur dann sinnvoll, wenn alle beteiligten Systeme einem gleich hohen Sicherheitsstandard genügen und die Synchronisierungsdienste ausreichend gegen unbefugte Kenntnisnahme geschützt sind. Vorteil dieser Synchronisationsmethoden ist, daß bei Ausfall eines Servers im Netz dennoch weitere Benutzer authentisiert werden können, da die Paßwörter ja auf allen Anlagen vorhanden sind. 2. Eine andere Lösung besteht darin, in einem Netzwerk einen zentralen Authentisierungsserver {Authentication Server) vorzusehen, dessen Aufgabe darin besteht, Authentisierungsdaten (hier Paßwörter) zentral - also nur einmal - vorzuhalten und auf Anforderung einer Arbeitsstationen ein übermitteltes Paßwort auf Richtigkeit zu prüfen. Problem: Hierzu sind zwischen dem Authentication Server und den Workstations Sicherheitsprotokolle zu fahren: Die Workstations müssen sicher sein, tatsächlich mit dem Authentication Server zu kommunizieren und haben für eine verschlüsselte Übertragung der Paßwörter zu sorgen. Notwendig ist also eine gegenseitige Authentisierung und die Verschlüsselung bestimmter Verwaltungsdaten. An die Verfügbarkeit solcher Security-Dienste sind natürlich hohe Anforderungen zu stellen. Der Ausfall eines zentralen Authentisierungsservers hätte zur Folge, daß eine Anmeldung im Netz nicht mehr möglich ist! Keine Lösung ohne Probleme!

45

Synchronisation

Authentication Server

1. Beispiele aus der Praxis

Workstation

Workstation

—L. Synchronisation \

LAN

i

\

Workstation

Workstation

Paßwortliste

Paßwortliste

Abbildung 1-9: LAN mit Synchronisation der Authentisierungsdaten

Workstation

Workstation

Authentication Server

Paßwortliste

File-Server

Workstation

Workstation

Abbildung 1-10: LAN mit Authentication Server Zeitrestriktionen

Ein letzter Tip zur Authentisierungsfunktion: Sofern Betriebssysteme entsprechende Möglichkeiten bieten, sollte der Zeitraum der normalen Arbeitszeit ("montags bis freitags 8 - 1 7 Uhr") als erlaubter Zeitrahmen für Arbeiten im System festgelegt werden. Login-Vorgänge außerhalb dieser Zeiten sind dann nicht mehr möglich. Damit kann teilweise die Problematik des Datenzugriffs durch Fremdpersonal außerhalb der Arbeitszeiten (Putzkolonne, Wartungstechniker) gelöst werden.

46

1.4 Berechtigungen und Kontrollen

1.4.2 Andere Authentisierungsverfahren Man erkennt aus der vorausgegangenen Diskussion, daß die Paßwort-Verfahren immanente Schwächen haben. Es hat deshalb nicht an Versuchen gefehlt, bessere und zumindest leichter zu handhabende Methoden zu entwickeln. Die Nutzung einfacher Magnetstreifen- oder Speicherkarten mit einer geheimen Information (PIN) hat ein etwas höheres Sicherheitsniveau als das Paßwort-Verfahren, da gleichzeitig eine geheime Information und der Besitz der richtigen Karte vorausgesetzt werden. Von höherem Sicherheitsniveau ist die Nutzung von Challenge-Response-Verfahren, bei denen ein Sicherheitsprotokoll zwischen der Person und der Authentisierungskomponente (AK) gefahren wird: Schritt 1. Die Person erhält von der AK Daten X - z.B. eine Zeichenkette übermittelt; die AK verwendet bei jedem Authentisierungsvorgang andere, zufällige Daten, ("challenge"). Schritt 2. Die Person besitzt eine nur ihr bekannte Information Y - wie beispielsweise eine PIN oder ein Paßwort. Schritt 3. Mit X und Y führt die Person - ggf. unter Nutzung eines separaten Gerätes - eine vereinbarte Berechnung durch und übermittelt das Ergebnis an die AK. ("response"). Schritt 4. Die AK kann anhand des Ergebnisses nunmehr entscheiden, ob die Person authentisch ist. Die geheime Information Y, der bekannte Berechnungsgang und die zufällig ausgewählte Information X garantieren dies. Dieses komplizierte Verfahren kann vereinfacht werden, indem die Berechnung z.B. mit einem Taschenrechner durchgeführt wird und die Übermittlung der Daten zwischen AK und Person automatisch erfolgt. Solche Lösungen sind auf dem Markt erhältlich: Ein Token ist z.B. so konstruiert, daß er gleichzeitig Taschenrechner und Übertragungseinheit ist. Es besitzt eine optische Schnittstelle, mit deren Hilfe die Übertragung über den Bildschirm des Rechners geschieht, bei dem man sich authentisieren möchte. Die Eingabe der PIN erfolgt über eine kleine Zahlentastatur auf dem Token. Ein zweites Beispiel ist die Verwendung von intelligenten Chipkarten (Smartcards), die mit den gleichen mathematischen Verfahren (aber mit anderen Übertragungswegen) arbeiten. Hierfür ist aber ein spezielles Lesegerät mit eigener Tastatur für die Eingabe der PIN erforderlich; ein Anschluß zum Rechner muß hergestellt werden. Auf dem Markt werden außerdem Geräte angeboten, die biometrische Verfahren verwenden. Dabei stößt man stets auf das Problem, daß diese entweder wegen vermeintlich oder tatsächlich gesundheitsschädlicher Auswirkungen (z.B. bei der Abtastung des Musters des Augenhintergrundes durch einen Laserstrahl) oder aufgrund von angenommener sozialer Herabsetzung (Abnehmen von Fingerabdrücken, Behandlung wie bei Kriminellen) von den Betroffenen abgelehnt werden. Davon abgesehen sind die Methoden sehr zuverlässig...

47

Challenge-Response

Token

Chipkarte

Biometrik

1. Beispiele aus der Praxis

Rechte-Erfassung

1.4.3 Verwaltung der Zugriffsrechte Nach der erfolgten Authentisierung kommt nun die Zugriffskontrolle zum Zug. Die Verwaltung von Zugriffsrechten zerfällt in folgende Einzelthemen: Erfassung aller Subjekte und Objekte, die Uberschaubarkeit der Rechtebeziehungen, die Vermeidung ungewollter Rechtebeziehungen. Schutz der Verwaltungsdaten - auch bei der Datensicherung, Regeln für neue, ausscheidende, als Vertretung agierende Mitarbeiter, Weitergabe und Synchronisation von Rechten in heterogenen Systemumgebungen. Um ein Zugriffskontrollsystem aufzubauen, müssen die der Kontrolle unterliegenden Subjekte - die Benutzer bzw. die von ihnen gestarteten Prozesse 5 - und die zu schützenden Objekte (Dateien, Übertragungskanäle, Datenträger, Speicherbereiche, Prozesse) festgelegt und tabellarisch gegenübergestellt werden. In diese Rechtematrix werden nun für jedes Paar Subjekt - Objekt die erlaubten Zugriffsarten (Lesen, Schreiben, Löschen,...) eingetragen. Für die Zugriffskontrolle ist diese Tabelle die Entscheidungsgrundlage für das Erlauben oder Verweigern von Zugriffen. Datei A

Datei B

Datenträger 1

Speicherbereich xxxx-yyyy

Person 1

Lesen

Schreiben

alles

nichts

Prozeß 2

Schreiben

Schreiben

Lesen

Löschen

Person 7

Lesen

nichts

Lesen

nichts

usw.

usw.

Tabelle 1-1: Beispiel für eine Zugriffskontrollmatrix Überschaubarkeit

Gruppenkonzept

Insbesondere in großen Systemen mit vielen Schutzobjekten und vielen Subjekten stellt sich sehr schnell die Frage nach der Überschaubarkeit der Rechtebeziehungen. Während z.B. in Unix pro Datei nur drei unterschiedliche Zugriffsarten (Read, Write, Execute) und nur drei Subjekte (der Besitzer, eine Gruppe, alle übrigen) unterschieden werden, gibt es in anderen Systemen (Großrechner, LAN-Betriebssysteme, PC-Sicherheitsprodukte) die Möglichkeit, jede Kombination von Benutzer und Datei mit unterschiedlichen Zugriffsrechten auszustatten. In solchen Fällen kann die Menge der Verwaltungsdaten gewaltig ansteigen. Sind einige Benutzer mit identischen Rechten ausgestattet, so ist es sinnvoll, sie nicht als Einzelpersonen, sondern als Mitglieder einer Gruppe zu führen; die Zugriffsrechte werden dann auf Basis einer Gruppen-ID (statt User-ID) vergeben. Dieses Verfahren verkleinert die Rechtematrix und erleichtert die s

48

Vereinfacht ausgedrückt ist ein Prozeß ein ablaufendes Programm.

1.4 Berechtigungen und Kontrollen

Verwaltung. Gleiches gilt für die Methode, die Objekte in Gruppen (Objektklassen) zu führen und Zugriffe auf dieser Basis zu regeln. Ein anderes Verfahren besteht darin, neue Benutzer explizit mit den Rechten bereits registrierter Benutzer auszustatten (Security Equivalence). Dies vereinfacht den Vorgang der Rechtevergabe erheblich. Werden solche Verfahren aber extensiv benutzt, steigen auch die Sicherheitsprobleme: Es können nicht überschaubare, ungewollte, sogar zyklische Rechtebeziehungen entstehen. Beim Löschen der Rechte eines Benutzers in so verwobenen Beziehungsketten können interessante Effekte auftreten... Die Verwaltungsdaten (Rechte zwischen Subjekten und Objekten) müssen natürlich verfügbar, integer und teilweise vertraulich sein. Sie sind damit besonders schutzbedürftig. Sie werden in der Praxis entweder in internen Strukturen eines Betriebssystems untergebracht oder in Dateien abgelegt, die durch die Zugriffskontrolle implizit geschützt sind. Ein besonderes Problem ergibt sich bei der Datensicherung: Werden auch die Verwaltungsdaten mitgesichert? Ein Eingeben aller dieser Daten nach Plattencrash ist höchst aufwendig und fehlerträchtig bzw. mangels anderer Aufzeichnungen meist gar nicht durchfuhrbar. Werden diese Daten aber bei der Datensicherung berücksichtigt, müssen die Sicherungsmedien gegen Integritäts- und Vertraulichkeitsverlust besonders gesichert werden. Verschlüsselungstechniken bieten sich auch hier als eine Lösung an. Die Probleme der Datensicherung werden im Abschnitt 1.8 näher behandelt. Ein besonderes Sicherheitsproblem stellt die Übertragung einer Datei von einem System zu einem anderen dar (Import/Export). Zunächst gelten Zugriffsrechte nur innerhalb eines bestimmten Rechners. Seine Zugriffskontrolle ist bestenfalls geeignet, lokal Schutz zu bieten. Wird nun die Datei von System A zum System B kopiert, werden dabei die Zugriffsrechte in aller Regel nicht mit übertragen. Dies macht allerdings auch nicht immer Sinn, da die im System A bekannten Benutzer möglicherweise im System B völlig unbekannt sind. Eine Übertragung der Zugriffsrechte dürfte allerdings in allen lokalen Netzwerken sinnvoll sein. Schwierig wird es, wenn sich die Zugriffskontrollen zweier unterschiedlicher Rechner nicht miteinander verständigen können... Anders liegt der Fall in Systemen, die die Technik der Einstufung von Dateien beherrschen 6 : Hier gibt es für den Import und Export von Schutzobjekten globale Regeln, deren Einhaltung von den beteiligten Betriebssystemen garantiert werden muß (vgl. Bell-LaPadula Modell). Dabei werden Attribute stets mit übertragen. Die Komplexität der Rechteverwaltung kann in vernetzten, heterogenen Systemen alle Grenzen sprengen. Eine manuelle Vergabe von Rechten zwischen

6

Multi-Level-Systeme gemäß den B-Klassen des Orange Books oder vergleichbarer Sicherheitskriterien.

49

Default-Rechte

Rechtebeziehungen

Verwaltungsdaten

Import/Export

Heterogene Systeme

1. Beispiele aus der Praxis

Subjekten und Objekten auf jedem einzelnen Netzknoten unter Wahrung der logischen Konsistenz ist praktisch nicht mehr machbar. Eine technische Lösung stellt die zentrale Administration für ein gesamtes Netzwerk dar. Dabei sind mehrere Ansätze möglich: 1. Die für einen Knotenrechner relevanten Verwaltungsdaten (für seine Ressourcen) sind auch in diesem Knoten gespeichert. Die Verwaltungsdaten können aber an einem zentralen Rechner eingegeben, verändert, gelöscht werden. Damit ist nur die Verwaltungsfunktion zentralisiert. Nachteil: Sind viele unterschiedliche Systemtypen, vielleicht sogar proprietäre Systeme im Netz integriert, dürfte es sehr schwierig werden, geeignete Administrationsprodukte auf dem Markt zu finden... 2. Ein anderer Ansatz ist die Einführung eines Security Servers, der zentral alle Rechtebeziehungen speichert und verwaltet. Hinsichtlich des Verfügbarkeitsproblems und des sicheren Protokolls gelten sinngemäß die Ausführungen zum Authentication Server.

Synchronisation

Laptops,

Notebooks

Die Kontrolle der Ausübung von Rechten kann im Fall 2 auf zwei Arten geschehen: a) Durch den Security Server selbst. Nachteil: Je nach Tiefe der Zugriffskontrolle wird ein beachtlicher Teil der Übertragungskapazität des Netzwerks für das Frage- und Antwortspiel zwischen den Netzknoten und dem Security Server aufgewendet. Hochkritisch: Ein Ausfall des Servers bringt das gesamte Netz zum Erliegen. Vorteil: Alle Verwaltungsdaten sind genau einmal vorhanden, eine unbefugte Weitergabe kann praktisch ausgeschlossen werden. b) Durch jeden lokalen Rechner für seine Ressourcen. Nachteil: Der lokale Rechner muß periodisch einen Auszug der Verwaltungsdatenbank des Security Servers erhalten (Synchronisation), um aktuelle Entscheidungen treffen zu können. Es muß also ein ständiger Abgleich zwischen den Rechteprofilen auf dem Security Server und den lokalen Rechnern stattfinden. Vorteil: Das Verfügbarkeitsproblem ist nicht kritisch. Ein zeitlich beschränkter Ausfall des Security Servers kann toleriert werden. Die Lösung b hat einen entscheidenden Vorteil für Geräte wie Laptops und Notebooks. Bei vielen Unternehmen müssen Außendienst-Mitarbeiter aktuelle Daten auf Laptops oder Notebooks mit sich führen. Sie werden nur zeitweilig an ein LAN angeklemmt, um eine Datenaktualisierung (in beiden Richtungen) zu ermöglichen. Damit ist der Laptop/Notebook zeitweilig Bestandteil eines LAN, andererseits im offline-Zustand durch seine offene Einsatzumgebung besonders gefährdet. Die Methode b ermöglicht den offline- wie auch den onlineBetrieb unter Wahrung aller Zugriffskontrollen.

50

1.4 Berechtigungen und Kontrollen

Zeitweilige logische Erweiterungen eines lokalen Netzes (z.B. Freigabe von Verbindungen an öffentliche Netze, Herstellen einer Verbindung für die Fernwartung) oder die Verbindung verschiedener LANs untereinander über öffentliche Netzwerke stellen die Betreiber aus Sicht der Sicherheit zumeist vor größte Probleme. Andererseits mehren sich die Einsätze solcher Corporate LANs, da sie besonders geeignet sind, der verteilten räumlichen Struktur von Unternehmen Rechnung zu tragen. Zwischen den verschiedenen LANs oder zwischen LAN und einem externen, über das öffentliche Netz kommenden "Anrufer" müssen Protokolle zur gegenseitigen Authentisierung gefahren werden; gleichzeitig muß eine Zugriffskontrolle nach Typ a oder vorzugsweise Typ b erfolgen. Ein typisches Problem ergibt sich, wenn infolge von Urlaubs- oder anderen Abwesenheitszeiten Mitarbeiter Vertretungsfunktionen übernehmen müssen. Dieses Vertretungsproblem muß entweder in den benutzten IT-Systemen technisch oder durch organisatorische Maßnahmen gelöst werden. Im Normalfall ist das Paßwort eines Mitarbeiters seinem Vertreter mitzuteilen und die zeitlich limitierte Vertretungsfunktion im betreffenden Betriebssystem einzurichten. Dies führt zur Forderung, daß Zugriffsrechte temporär einrichtbar und zeitlich begrenzbar sein müssen. Eine andere Technik besteht darin, Zugriffsrechte nicht an einzelne Personen, sondern an ihre Funktionen bzw. Aufgaben zu binden. Man spricht in diesem Zusammenhang von Rollen. Eine Rolle ("Sachbearbeiter für Personalangelegenheiten") kann real durch mehrere Personen besetzt sein. In der Praxis heißt dies, daß das Betriebssystem eines Rechners die einzelnen Rollen und die ihnen zugewiesenen Personen kennen muß. Das Vertretungsproblem läßt sich hiermit elegant lösen, indem notfalls ein weiterer Mitarbeiter der Rolle zugewiesen wird. Technisch können Rollen durch das bereits erwähnte Gruppenkonzept realisiert werden. Schwieriger wird es aber dann, wenn die einer Rolle zugewiesenen Personen nicht gleichzeitig, sondern nur zeitlich nacheinander Zugriff erhalten sollen (eher typisch für Vertretungsfunktionen). Technisch ist dies realisierbar, sofern das Betriebssystem es zuläßt, die Zahl der gleichzeitig bestehenden Logins pro User- oder Gruppen-ID zu begrenzen (nämlich hier auf 1). In sehr sensitiven Umgebungen wird vielfach die Einhaltung des Vier-AugenPrinzips gefordert: Bestimmte sicherheitskritische Verarbeitungen sollen nur durchgeführt werden, wenn zwei Personen explizit damit einverstanden sind. Zunächst erhebt sich die Frage, wie an einer Workstations zwei Personen angemeldet und in der gleichen Session tätig sein können. Folgender "Trick" läßt sich immer anwenden: Die sicherheitskritischen Arbeiten werden nur einem bestimmten Subjekt gestattet. Der Name des Subjektes ist zwei Personen bekannt. Das Paßwort für dieses Subjekt wird entsprechend lang gewählt; jede Person bekommt nur eine Hälfte zur Kenntnis. Bei der An-

51

Corporate L A N

Vertretungsfunktion

Rollen

Begrenzung

Vier-Augen-Prinzip

1. Beispiele aus der Praxis

H o h e Privilegien

Prozesse

meidung im System müssen demzufolge beide Personen anwesend sein. Dies bietet natürlich noch keine Gewähr dafür, daß beide auch bei den nun folgenden Arbeiten tatsächlich anwesend sind. Hier spielt wieder das sicherheitsgerechte Verhalten der Personen eine wichtige Rolle... Ein besonderes Problem stellt die Kontrolle von Subjekten mit höheren Privilegien wie z.B. des System-Verwalters in einem Netzwerk dar. In der Praxis müssen die Personen, die solche Rollen ausfüllen, sowohl in den technischen Eigenschaften des benutzten IT-Systems, als auch insbesondere in den Sicherheitsbelangen ausgebildet sein. Mit ihrem Verhalten steht und fällt die Sicherheit des gesamten IT-Systems. Meist haben sie unbeschränkten Zugriff zu allen Ressourcen - obwohl es hierfür eigentlich gar keinen Grund gibt. Sie sind vielfach in der Lage, die Protokollierung ihrer eigenen Aktivitäten zu unterbinden (wenn sie überhaupt stattfindet) oder die Eintragungen nachträglich zu löschen. Auch für diese Situation besteht eigentlich gar kein Grund; in manchen Produkten ist deshalb ein separater System-Auditor als Rolle vorgesehen, der als einziger die Protokollierung ein- bzw. ausschalten und die Aufzeichnungen bearbeiten darf. In jedem IT-System gibt es Programme, deren Aufgabe es ist, sicherheitskritische Verarbeitungen auszuführen: Verwaltungsprogramme für die Rechteprofile, transaktionsorientierte Programme bei Datenbanken, systeminterne Programme für den sicheren Systemanlauf und die Datensicherung usw. Diese Programme benötigen in der Regel sehr hohe Rechte, um ihre Aufgaben ausfuhren zu können 7 . Entsprechend hohen Schaden können sie verursachen, wenn sie manipuliert werden können oder nicht korrekt funktionieren. Der Nutzer eines IT-Systems soll aber nur solche Programme starten dürfen, die seinen Rechtehorizont nicht überschreiten. Diese an sich richtige Philosophie läßt sich systemtechnisch nicht immer durchhalten. Ein Beispiel hierfür sind die setuid/setgid-Programme unter Unix, die - von einem normalen Benutzer gestartet - während ihres Laufs vom Betriebssystem höhere Rechte zugewiesen bekommen müssen. Ein Beispiel hierfür sind einige Unix-Editoren, soweit sie im Rahmen des Mail-Systems eingesetzt werden. Der berüchtigte "Hacker aus Hannover" benutzte eine solche Schwachstelle, um sich Supervisor-Rechte in Unix-Systemen zu verschaffen. Mögliche andere Auswirkungen dieser Privileg-Erhöhung werden im Abschnitt 1.5 (Programme mit Schadenfunktionen) behandelt.

D i e Datensicherung ist hier ein schönes Beispiel: Sie macht j a nur Sinn, w e n n wirklich auf alle Daten (gleich welcher Schutzwürdigkeit) zugegriffen werden kann.

52

1.4 Berechtigungen und Kontrollen

1.4.4 Informationsflußkontrolle Gerade in sehr sensiblen IT-Systemen ist es ein Ziel der Sicherheitspolitik, einen unerlaubten Informationsfluß zu verhindern: Hoch sensitive Daten dürfen nicht zu solchen Subjekten (Personen, Prozesse,...) gelangen, die nur Daten geringerer Sensitivität bearbeiten dürfen. Hierzu reicht es zunächst, mit Mitteln der Zugriffskontrolle zu arbeiten: Dateien werden hinsichtlich ihrer Sensitivität unterschiedlich hoch eingestuft; vor einem Zugriff wird geprüft, ob das betreffende Subjekt eine entsprechend hohe Ermächtigung besitzt 8 . In solchen sensiblen Kontexten müssen aber auch Informationskanäle beachtet werden, die "quasi am System vorbei" genutzt werden können. Ein Informationsfluß zwischen zwei Benutzern kann z.B. dann nicht verhindert werden, wenn Speicherbereiche, zu denen beide Benutzer Zugriff haben könnten, nicht korrekt wiederaufbereitet werden. Hierüber können j e nach Lage gezielt (asynchrone) Kommunikationsbeziehungen aufgebaut werden (Speicherkanäle). Dabei schreibt Benutzer A sensitive Daten in einen nicht der Wiederaufbereitung unterliegenden Speicherbereich, Benutzer B holt sie dort ab. Insbesondere unter DOS/Windows ist eine Wiederaufbereitung von Arbeitsspeicher und freigegebenem Speicher auf externen Medien von Natur aus nicht gegeben. Ein Löschen von Dateien führt normalerweise nur zum Löschen des Datei-Namens in der Datei-Liste (Directory). Die Nutzdaten selbst bleiben solange erhalten, bis ihr Speicherplatz durch neue Dateien überschrieben wird. Reste von Daten lassen sich mit Mitteln des Betriebssystems immer lesen, z.T. können Dateien sogar vollständig wiederhergestellt werden. Selbst das Ausschalten eines PC kann nicht immer verhindern, daß die im Arbeitsspeicher stehenden Daten ausreichend schnell gelöscht werden. Die Speicherbausteine können je nach Typ Daten noch über Stunden erhalten. Der nächste Benutzer eines PC kann Datenreste durch einfaches Suchen im Arbeitsspeicher finden. Lösen läßt sich dieses Problem nur durch explizites Überschreiben des Arbeitsspeichers vor dem Abschalten oder unmittelbar nach dem Einschalten. Gute PC-Sicherheitsprodukte bieten solche Möglichkeiten! Neben den Speicherkanälen existieren auch (synchrone) Zeitkanäle: Die Systemzeit kann als Synchronisation für einen taktgesteuerten Informationsfluß genutzt werden. Zwei Beispiele hierzu: 1. In älteren Unix-Systemen kann jeder Benutzer sich über das ps-Kommando einen Überblick über die im System laufenden Prozesse anderer Benutzer verschaffen. Nehmen wir an, Benutzer A will Informationen (eine Folge von Bits)

Eine solche an Einstufungen orientierte Zugriffskontrolle heißt globale Zugriffskontrolle im Unterschied zu der diskreten Zugriffskonirolle, die Rechte zwischen einzelnen Subjekten und Objekten betrachtet.

53

Informationsfluß

Speicherkanäle

Löschen von Dateien

Zeitkanäle

1. Beispiele aus der Praxis

Verdeckte Kanäle

unter Umgehung des Betriebssystems an Benutzer B senden. Beide vereinbaren, sich nach der Systemuhr des Betriebssystems zu richten und ab einem vereinbarten Zeitpunkt Bit für Bit zu "senden". Immer wenn das nächste zu sendende Bit eine 1 ist, startet A zur nächsten vollen Minute einen (Dummy-) Prozeß und beendet ihn erst nach einigen Sekunden. Ist das Bit gleich 0, so startet er den Prozeß nicht! Dieses Spiel wiederholt er bis zum Ende seiner BitFolge. Benutzer B kann nun zu jeder vollen Minute mit dem ps-Kommando prüfen, ob der Dummy-Prozeß läuft. Ist dieser Prozeß nicht existent, so weiß B, daß im Bit-Strom eine 0 gesetzt ist, andernfalls eine 1. 2. Noch trickreicher ist ein Verfahren, bei dem Prozeß A bestimmte Ressourcen des IT-System regelmäßig und in kurzen Abständen entweder voll in Anspruch nimmt oder nicht nutzt, während Prozeß B dies im gleichen Takt versucht. Wird ihm die Ressource zugewiesen, war das Informationsbit z.B. eine 1, sonst eine 0. Als Ressource kann jede Art von Speicher, Statusbit, Register, sogar die Prozessor-Zeitscheibe genutzt werden... Unterliegen solche Kanäle nicht der Zugriffskontrolle, so spricht man von verdeckten Kanälen (Covert Channels). Hierbei wird als Kriterium für eine Bewertung die Bandbreite eines solchen Kanals angegeben, d.h. die Menge von Bits pro Zeiteinheit, die über diesen Kanal transportiert werden kann. In dem geschilderten Beispiel 1 ist die Bandbreite des Kanals 1 Bit/Minute. Einer Verkürzung der Synchronisationsintervalle und entsprechend der Laufzeit des Dummy-Prozesses (z.B. auf 1 Sekunde oder noch weniger) sind Grenzen gesetzt, da • A und B im Rahmen des normalen Multi-Tasking überhaupt mit dem Starten von Prozessen zum Zuge kommen müssen, • Benutzer B aus gleichem Grund innerhalb der Lebenszeit des Dummy-Prozesses definitiv sein ps-Kommando ausführen können muß. Dennoch käme man sicher je nach Systemauslastung auf eine Bandbreite in der Größenordnung von 1 Bit pro Sekunde. Gleiches gilt sinngemäß für Beispiel 2; nutzt man einfachste Ressourcen wie Statusbits oder Semaphoren, läßt sich des unkomplizierten Zugriffs wegen sogar eine sehr große Bandbreite erzielen. 1.4.5 Vertrauenswürdiger Pfad Das logische Gegenteil eines verdeckten Kanals ist ein vertrauenswürdiger Pfad (Trusted Path). Dabei handelt es sich um einen gesicherten Kommunikationskanal zwischen zwei System-Instanzen, z.B. zwischen zwei Prozessen. Die Daten, die über diesen Pfad laufen, sind authentisch, Absenden und Empfangen von Daten sind zweifelsfrei nachzuweisen. Ein wichtiger Anwendungsfall ist die Identifizierung und Authentisierung eines Benutzers an einem Rechner. Der Benutzer soll sicher sein, daß er sich dem Rechner und seinem Betriebssystem gegenüber authentisiert und nicht etwa

54

1.5 Programme mit Schadenfunktionen

gegenüber einem anderen Rechner, der virtuell das Terminal nutzt (wie so häufig bei Unix üblich), oder einem Spoofing-Programm: Das sind Programme, die in manipulativer Absicht Sicherheitsfunktionen vortäuschen. Der vertrauenswürdige Pfad kann hierbei wie folgt implementiert werden: 1. Das Betätigen einer bestimmte Taste oder Tastenkombination führt hardwaremäßig zu einem Alarm im Sicherheitskern des Betriebssystems, das seinerseits eine nicht filterbare Verbindung zur Tastatur und zum Bildschirm aufbaut und hierfür gegebenenfalls laufende Prozesse für diese Einheiten unterbricht. 2. Mit Hilfe von Smartcards (Chipkarten mit Prozessor und eigenem Betriebssystem) und einem entsprechenden kryptografischen Protokoll kann eine gegenseitige Authentisierung (Benutzer —> Betriebssystem, Betriebssystem —> Benutzer) durchgeführt werden. Man vergleiche die Beschreibung des Challenge-Response-Verfahrens in 1.4.2. Bei beiden Verfahren ist ein Vortäuschen des Login-Vorgangs z.B. durch ein Spoofing-Programm nicht möglich. Vertrauenswürdige Pfade werden in allen Sicherheitskriterien für Systeme einer hohen Sicherheitsstufe für die Identifizierung und Authentisierung gefordert.

1.5 Programme mit Schadenfunktionen 1.5.1 Begriffe Zu diesen Programmen werden trojanische Pferde. Würmer. Zeitbomben, logische Bomben. Programme mit Falltüren und Viren gerechnet. Nicht dazu zählen sogenannte Enten, die in letzter Zeit vermehrt auftreten: Die erwünschte und teilweise erreichte Sensibilisierung der Anwender schlägt gelegentlich schon ins Gegenteil um: Alle Unregelmäßigkeiten im Verhalten von Betriebssystemen und Programmen werden sofort irgendwelchen Viren angelastet. Dabei handelt es sich um nichts anderes als die klassischen Programmierfehler (Bugs, Wanzen), die sich in den Systemen immer noch sehr viel häufiger bemerkbar machen als Viren. Unter einem trojanischen Pferd wird ein Programm verstanden, das neben der geplanten Funktion vom Programmierer beabsichtigte Schadenfunktionen ausführen kann. Ein typisches Beispiel für ein trojanisches Pferd: Ein Benutzer sieht auf seinem Terminal die ihm bekannte Login-Maske, die ihn zur Eingabe seiner User-ID und seines Paßworts auffordert. In der Praxis wird nun jeder arglos seine Daten eingeben - ohne zu wissen, ob das Login-Programm "echt" ist. Hat ein anderer, böswilliger Benutzer ein Spoofing-Programm geschrieben, das eine solche Login-Maske auf dem Bildschirm anzeigt, so gelangt er schnell in

55

Enten, Bugs und Wanzen

Trojanisches Pferd

Spoofing

1. Beispiele aus der Praxis

Bomben

Falltüren

Viren

Wirt

den Besitz von Paßwörtern. Dies ist insofern für ihn ungefährlich, als er die eingegebenen Daten sofort an das (echte) Login-Programm weitergeben oder eine Meldung wie "...falsches Paßwort..." ausgeben kann. Der arglose Benutzer wird vermuten, er habe sein Paßwort falsch eingetippt, und den Login-Vorgang noch einmal wiederholen! Zu den trojanischen Pferden gehören die Unterarten Bomben und Falltüren. Unter Bomben werden solche Programme zusammengefaßt, die bei Eintreten gewisser Auslöser von ihrem normalen Programmablauf abweichen und vom Programmierer beabsichtigte Schadenfunktionen ausführen. Je nach Typ des Auslösers werden Zeitbomben (Auslöser ist ein bestimmtes Datum oder die Uhrzeit) und logische Bomben (Auslöser sind bestimmte logische Bedingungen, z.B. Systemzustände oder Inhalte von Dateien) unterschieden. Falltüren sind Pfade in einem Programm, die in der Konzeption des Programms nicht vorgesehen waren, aber durch den Programmierer zu Testzwecken oder in manipulativer Absicht eingebaut wurden. Ist das betreffende Programm Teil eines Sicherheitssystems, z.B. das Login-Programm oder das Protokollierungsprogramm, so können diese speziellen Programme zur Umgehung aller Sicherheitsvorkehrungen benutzt werden. Ein Programmierer kann sich auf diesem Wege z.B. Zugang zu allen Anlagen verschaffen, auf denen "sein" Login-Programm läuft. Das Programm kann ihn anhand einer sonst nicht vorkommenden User-ID oder eines speziellen Paßworts erkennen, ggf. auch durch eine spezielle Tastenkombination (Hot Key). Ist auch das Protokollierungsprogramm entsprechend "ausgerüstet", können sogar alle Aufzeichnungen für diesen speziellen Benutzer unterdrückt werden. Seine Anwesenheit im System ist dann nicht mehr nachweisbar. Viren zählen zu den Programmen mit Fortpflanzungseigenschaften. Der Ausbreitungsmechanismus bei Viren sieht in der Regel so aus: Ein Urprogramm wird um einige Befehle ergänzt, deren Funktion darin besteht, nach Start des betreffenden Programms noch nicht infizierte Programme zu suchen. Werden sie fiindig, kopieren sie sich selbst und ggf. ein Programmteil mit Schadenfunktionen in diese Programme hinein. Die infizierten Programme verhalten sich folglich bei einem Start wie das Urprogramm: Sie suchen nach weiteren, noch nicht infizierten Programmen und infizieren sie unter Weitergabe der Schadenfunktion. Durch bestimmte Auslöser (s. Bomben) tritt die Schadenfiinktion in Aktion. Hierbei ist jedes Horror-Szenario denkbar: im Extremfall das Löschen aller Daten. Für die beschriebene Art der Fortpflanzung benutzt ein Virus in der Regel die zulässigen Systemaufrufe eines Betriebssystems. Wichtig: Ein Virus ist kein eigenständiges Programm, sondern benötigt für seine Funktion wie geschildert einen "Wirt". Dies hat zur Folge, daß befallene Programme in der Regel ihre Länge ändern. Auch Datumsangaben im Directo-

56

1.5 Programme mit Schadenfunktionen

ry können sich durch die Schreiboperation beim Infizieren ändern. Treten Effekte dieser Art innerhalb eines Systems auf, so ist dies ein erstes, aber schon ernstes Warnzeichen! Der zuvor beschriebene Virustyp ist eigentlich schon ein Spezialfall, nämlich der sogenannte Link-Virus9. Ein weiterer, besonders im PC-Bereich häufig auftretender Virus ist der sogenannte Boot-Sektor-Virus: Beim Start eines Systems von einer infizierten Diskette installiert er sich im Arbeitsspeicher und kopiert sich in den Boot-Sektor jeder neuen, ins System eingebrachten Diskette - sofern dort nicht der Schreibschutz aktiviert ist. Viren können sich auch im Arbeitsspeicher eines PC häuslich niederlassen, nachdem sie auf irgendeinem Wege (Booten von einer verseuchten Diskette, Start eines infizierten Programms) in den PC gelangt sind. Von dort aus kann natürlich eine Verbreitung besonders gut erreicht werden. Anti-Viren-Produkte müssen deshalb auch den Arbeitsspeicher mit in ihre Prüflingen einbeziehen. Es ist nicht Ziel dieses Buches, über die unzähligen Viren-Typen und ihre Varianten zu informieren, deren Zahl permanent zunimmt. Existierende Anti-VirenProdukte scheitern aber oft an neuen Arten von Viren: Mutierende Viren ändern bei ihrer Ausbreitung ihre Gestalt und können deshalb nur von hoch qualifizierten Suchprogrammen "sicher" erkannt werden, die weniger nach bestimmten Byte-Folgen als nach typischen Mutationsalgorithmen suchen. Gleiches gilt sinngemäß für sich selbst verschlüsselnde Viren. Eine neue Bedrohung geht von Tarnkappen-Viren aus, die ihre Anwesenheit in einem IT-System verbergen können. Ist z.B. die Virenausbreitung mit einer Änderung der Länge der infizierten Programme verbunden, könnte ein Tarnkappen-Virus den DIR-Befehl von MS-DOS so beeinflussen, daß bei der Directory-Anzeige stets die Originallänge der Programme auftaucht. Damit würde die Infektion von Programmen anhand der Längenänderung zunächst nicht erkannt werden können! Bei einem Wurm handelt es sich um ein eigenständiges Programm (oder ein System von Programmen), das die Schwachstellen und Programmierfehler, aber auch die normalen Mechanismen in Netzwerken und Betriebssystemen zur Verbreitung ausnutzt. Seine Schadenfiinktion kann z.B. in der Übertragung von trojanischen Pferden bestehen oder im Denial of Service, d.h. der Blockierung z.B. von Leitungswegen durch die lawinenartig ansteigenden Übertragungsoperationen. 1.5.2 Integritätsverletzungen und Gegenmaßnahmen Die Programme mit Schadenfunktionen bedrohen zumeist die Unversehrtheit (Integrität) von gespeicherten Daten und Programmen. Welche praktischen

Mit einem Programm verbunden.

57

Link-Virus, BootSektor-Virus

Residenter Virus

Würmer

1. Beispiele aus der Praxis

Gegenmaßnahmen Sensibilisierung

Diskettenprobleme

Viren-Suchprogramme

Signatur-Systeme

Ansätze können die von Programmen mit Schadenfunktionen ausgehenden Gefahren vermindern? Der Schutz vor Viren und ähnlichem Getier hat zwei Aspekte: Sensibilisierung und Technik. Es bedarf einer Reihe von Verhaltensweisen und Maßnahmen außerhalb des unmittelbar technischen Bereichs. Dies schließt im Großen ein, Programmieranleitungen oder sogar den vollständigen Quellcode von Programmen mit Schadenfunktionen nicht zu verfassen oder zu veröffentlichen bzw. gegen deren Verbreitung vorzugehen. Im Kleinen müssen sich die Nutzer von PCs aber darüber klar sein, daß jeder fremde Datenträger virenverseucht sein kann. Angepaßte Verhaltensweisen der Nutzer sind zur Reduzierung der Gefahren unerläßlich. Meistens haben Benutzer die Möglichkeit, Daten über Diskettenlaufwerke in ihr System einzuspielen. Dies ist der klassische Infektionswegl Seine Effizienz ist - wie die Erfahrung zeigt - sehr groß. Von der Häufigkeit her sind andere Datenträger wie Wechselplatten und Streamer-Tapes weniger betroffen. Natürlich ist festzuhalten, daß in den meisten Fällen die autorisierten Nutzer eines Systems nicht absichtlich Viren importieren, sondern Disketten in Unkenntnis des Virenbefalls verwenden. Folgerung: Sofern aus betrieblichen Gründen zulässig sollten diese Hauptinfektionskanäle "dicht" gemacht werden; einfachste Maßnahme ist der Ausbau von Diskettenlaufwerken oder ihre mechanische bzw. logische Verriegelung 10 . Ist dies nicht möglich, kann schon die einfache Vorsichtsmaßnahme, den Schreibschutz bei Disketten zu nutzen, die Verbreitung von Viren eindämmen. Dies gilt besonders für Boot-Disketten! Ist aber eine gezielte, d.h. absichtliche Infektion von Programmen durch autorisierte Benutzer in Betracht zu ziehen, so sind die genannten Maßnahmen nicht ausreichend: Es gibt gerade im PC-Bereich weitere - quasi "verdeckte" Kanäle, die eine Infektion möglich machen... Die Nutzung von Viren-Suchprogrammen bringt zwar keinen Schutz vor der Infektion, kann aber erfolgte Infektionen entdecken und deren Beseitigung erleichtern. Dabei greifen solche Suchprogramme auf eine Bibliothek typischer Code-Sequenzen von Viren zurück und prüfen andere Programme auf das Vorhandensein solcher Zeichenfolgen oder versuchen, Viren anhand bestimmter Merkmale zu identifizieren. Schwachpunkte von Viren-Suchprogrammen sind vor allem das Veralten (neue Viren sind dem Programm nicht a priori bekannt) und die eigene Anfälligkeit gegenüber Manipulation ("Virus infiziert VirenSuchprogramm"). Würde ein PC Veränderungen an seinen Programmen vor deren Start sicher erkennen, wäre den Viren weitestgehend das Handwerk gelegt. Infektionen würden damit zwar nicht verhindert, aber infizierte Programme würden nicht ge10

58

Hierzu existieren auf dem Markt preiswerte Produkte.

1.5 Programme mit Schadenfiinktionen

startet und könnten damit nicht zur Ausbreitung eines Virus beitragen. Für den PC-Bereich (DOS/Windows und OS/2) sind in letzter Zeit Produkte angeboten worden, die ausführbare Dateien mit Prüfsummen oder komplizierteren elektronischen Signaturen versehen und diese bei jedem Programmstart überprüfen. Bei Abweichungen wird das Programm nicht gestartet und der Benutzer entsprechend unterrichtet. Auch solche Signatur-Produkte sind natürlich selbst "anfällig" gegenüber Infektionen und müssen daher mit entsprechenden Selbsttestverfahren ausgerüstet sein! In Systemen, die ihre Programme "von Natur aus" gegen unbefugten Schreibzugriff schützen können - dies gilt für viele Großrechner-Systeme, NetzwerkBetriebssysteme oder Unix-Systeme -, haben Viren von vorneherein einen schlechteren Stand - es sei denn, daß diese Systeme schlecht administriert sind und schreibenden Zugriff auf ausfuhrbare Programme gestatten. Ist eine Infektion zustande gekommen, so stellt sich die Frage, welche Zugriffsrechte hat ein Virus? In den meisten Betriebssystemen - sofern sie überhaupt eine Zugriffskontrolle besitzen - werden den von einem Benutzer gestarteten Prozessen die Rechte des betreffenden Benutzers zugewiesen. Ein Virus kann damit genau das tun, was der betreffende Benutzer tun darf: Die im Zugriff stehenden Programme können infiziert werden. Wäre dies das einzige, könnte man noch von einem begrenzten Schaden sprechen. In der Realität ist es aber so, daß Applikationen aus verschiedenen Gründen zentral z.B. in einem Netz zur Verfügung gestellt werden. Eine Infektion dieses zentralen Bestandes würde zur Folge haben, daß alle weiteren Benutzer, die hierauf zugreifen, sich ihrerseits für ihren lokalen bzw. privaten Bestand den Virus einfangen. Dieser Verbreitung kann nur durch besondere Zugriffsrechte oder Datei-Attribute entgegengewirkt werden: Existiert im System ein wirksames (!) ReadOnly- oder Execute-Only-Attribut, so läßt sich bei vernünftiger Organisation die geschilderte Ausbreitung von Viren verhindern. Man beachte in diesem Zusammenhang, daß das Read-Only-Bit bei MS-DOS und OS/2 eine Datei bestenfalls vor Bedienungsfehlern (unbeabsichtigter Schreibversuch) oder Programmfehlern schützen kann. Eine besondere Gefahr stellen in diesem Zusammenhang Benutzer mit hohen Privilegien dar: Verhält sich z.B. der Supervisor eines Systems so, daß er unter seiner Supervisor-Kennung solche Programme aufruft, die auch von normalen Anwendern genutzt werden können und damit einer Infektion ausgesetzt sind, so sind seine System-Utilities (Rechteverwaltung, Audit, ...), sogar das gesamte Betriebssystem stark gefährdet. Eine vollständige Trennung zwischen den normalen Applikationen und den System-Verwaltungsprogrammen ist aber in der Praxis oft nicht durchführbar, da sie vielfach gemeinsame Hilfsprogramme nutzen. Routinen, die von Personen oder Prozessen unterschiedlichen Privilegs genutzt werden können, müssen deshalb besonders gesichert sein! Als außergewöhnlich kritisch anzusehen sind Programme, die zur Ausführung ihrer Aufgabe ein höheres Privileg brauchen, als der sie startende Benutzer

59

Zugriffskontrolle

Rechte eines Virus

Rollen mit höheren Privilegien

Unix, setgid, setuid

1. Beispiele aus der Praxis

besitzt. Ein Beispiel sind hier etwa die bekannten setuid- b z w . setgid-Programm e unter Unix. Sie stellen quasi logische Verbindungen zwischen unterschiedlich privilegierten Stufen eines Systems dar und können deshalb z . B . Viren immer "höher" in ein System einschleusen. Fazit: Bei entsprechender Disziplin und ausreichenden Kenntnissen der Personen mit höheren Privilegien läßt sich die Gefahr der Vireninfektion stark vermindern. Dennoch sind eine Reihe technischer Unzulänglichkeiten in realen Betriebssystemen auszumerzen, bevor von einer angemessenen

Virenresistenz

gesprochen werden kann. I n f e k t i o n e n bei der

Eine besonders "sichere" Ausbreitung mit hoher Geschwindigkeit ist dann ge-

Herstellung

geben, wenn der Hersteller Programme mit Schadenfunktionen als (unbeabsichtigte) Beigabe zu seinen Produkten an seine Kunden ausliefert. Fälle dieser A r t sind bereits mehrfach aufgetreten. Handelt es sich um einen Virus, dessen Schadenfunktion erst ab einem gewissen Datum aktiviert wird, und andererseits um ein Produkt mit hohem Marktanteil, so ist zum Zeitpunkt der Erkennung des Virus bereits ein hoher Infektionsgrad gegeben: D i e Folgen sind katastrophal - sowohl für die Kunden, aber erst recht für das Image des Herstellers!

Produktions-

Infektionen v o n Programmen schon während der Herstellung oder bei der

umgebung

A u s l i e f e r u n g rühren daher, daß im PC-Bereich Herstellungsprozesse (Entwicklung, Programmierung, Auslieferung) selten mit Zugriffskontrollen ausgestattet sind. Systeme und Produkte können aus diesem Grund nur dann als qualitativ hochwertig und vertrauenswürdig angesehen werden, wenn sie in gesicherten U m g e b u n g e n und mit kontrollierten Verfahren hergestellt werden. Dies ist aber auch heute leider nur in Teilbereichen gegeben.

Werkzeuge

Für den Hersteller ergibt sich ein zusätzliches Problem dadurch, daß er in der Regel auf Produkte anderer Hersteller angewiesen ist. Dies trifft z . B . für Entw i c k l u n g s w e r k z e u g e , insbesondere Compiler und Linker zu. Gerade bieten

einen hervorragenden

Verteilungsmechanismus

für Programme

diese mit

Schadenfunktionen: Die tückischen Lines o f C o d e werden j e d e m Programm mitgegeben, das von diesem Compiler übersetzt oder v o m Linker zusammengesetzt wird. Verteilte Systeme

D e r Verbreitung v o n Programmen mit Schadenfunktionen besonders zuträglich sind logisch oder physisch vernetzte Systeme. Hier sind eine hohe Übertragungsgeschwindigkeit und nicht vorhandene b z w . einfachste Zugriffskontrollmechanismen beste Bedingungen für eine Ausbreitung von Programmen mit Schadenfunktionen.

60

1.6 Beweissicherung

1.6 Beweissicherung Die in früheren Zeiten als Protokollierung, heutzutage zumeist als Beweissicherung bezeichnete Funktion dient der Aufzeichnung aller ausgeübten Rechte, insbesondere auch aller sicherheitsrelevanten Ereignisse. Im englischen Sprachgebrauch unterscheidet man zwischen Accounting undifferenziertes Aufzeichnen aller Aktionen, z.B. für die Kostenrechnung bei der Auftragsabwicklung - und Audit. Letzteres meint die Aufzeichnung und Auswertung von sicherheitsrelevanten Ereignissen. Der Zweck besteht also in der nachträglichen Entdeckung von Ereignissen und damit unter anderem der Beweisführung bei Manipulationen. Zu diskutieren sind die Stichworte Vollständigkeit der Protokollsätze, die Untäuschbarkeit des Protokollierungssystems, das Protokollieren der Aktionen von Benutzern mit hohen Privilegien. Es ist klar, daß eine Beweissicherung ihren Namen nur dann verdient, wenn sie lückenlos aufzeichnet und alle zur Beweisführung notwendigen Informationen (zumindest Benutzer, Uhrzeit, Datum, Art der Aktion) speichert. Das Ziel der Beweissicherung bestimmt, was im Detail zu erfassen ist. Wenn Benutzer oder Prozesse in der Lage sind, den Umfang der Protokollierung selbst festzulegen, die Protokollierung ganz auszuschalten oder selbst beliebige Einträge in der Protokolldatei zu erzeugen, ist die Beweissicherung täuschbar und erfüllt somit nicht ihren Zweck.

A c c o u n t i n g , Audit

Aktionen des System-Verwalters und anderer privilegierter Personen sollten sicher protokolliert werden können - was aber in der Praxis vielfach nicht geschieht oder technisch nicht möglich ist. Andererseits müssen in einem IT-System privilegierte Rollen eingerichtet werden können, denen das Recht zur Bearbeitung von Protokollaufzeichnungen, zum Löschen nicht mehr aktueller Aufzeichnungen, zum Einstellen der Protokollparameter und zur Auswahl aufzeichnungswürdiger Aktionen übertragen wird (Auditor-Rolle). Sinnvoll ist eine Beweissicherung letztlich nur dann, wenn Auswerteprozeduren vorhanden sind, mit denen die gesamten Aufzeichnungen nach sicherheitskritischen Ereignissen durchsucht und damit manipulative Aktionen entdeckt werden können. Diese Prozeduren müssen natürlich auch regelmäßig angewendet werden. Die Zeiten, in denen viele Magnetbänder mit Protokollierungsdaten unbearbeitet irgendwo im Archiv verstauben, sollten für sensitive IT-Systeme eigentlich vorbei sein ... Eine eher präventive Methode der Entdeckung sicherheitsrelevanter Vorkommnisse besteht darin, typische Verhaltensweisen der Benutzer zu erfassen und bei signifikantem Abweichen von diesem Normalprofil Alarm zu geben. Methoden dieser Art werden als Intrusion Detection Monitoring bezeichnet. Damit wird aber nur die Wahrscheinlichkeit einer Entdeckung von Sicherheitsverletzungen

Privilegien

61

Vollständigkeit

Umtauschbarkeit

Prokollauswertung

Intrusion D e t e c t i o n

1. Beispiele aus der Praxis

erhöht. Andererseits ist es nur mit dieser Methode technisch möglich, Manipulanten zu entdecken, die sich Paßwörter illegal verschafft haben und damit aus Systemsicht formal autorisiert sind: Diese Personen werden sich vielfach durch ihre Verhaltensweisen "verraten", die dem Profil des "echten" Nutzers nicht entsprechen. Wegen der Speicherung und möglichen Auswertung personenbezogener Daten (z.B. Verhaltensprofile) gibt es natürlich juristische, vor allem datenschutzrechtliche Probleme mit dieser Methode.

1.7 Abstrahlsicherheit Hochfrequenz

Gegenmaßnahmen

Akustik

Einstrahlung

Geräte wie Bildschirme und Prozessoren erzeugen während ihres Betriebs funktionsbedingt hochfrequente Signale. Durch Kabelsysteme, Netzzuleitungen, geometrische Anordnung bestimmter Bauteile o.ä. können solche hochfrequenten Signale wie bei einem normalen Sender abgestrahlt werden. Mit einem gewissen technischen Aufwand können diese Abstrahlungen aufgefangen und dekodiert werden. Auf diese Weise ist z.B. das Sichtbarmachen von Bildschirminhalten in einiger Entfernung von der Strahlungsquelle möglich - ein typisches Beispiel für die Bedrohung "Verlust der Vertraulichkeit". Gegenmaßnahmen stellen die Verwendung abstrahlsicherer (tempest) oder zumindest abstrahlarmer Geräte oder die Abschirmung des Aufstellungsortes der Geräte dar. Diese kostenaufwendigen Maßnahmen sind in der Abwägung nur dann angemessen, wenn hoch- und höchstsensitive Informationen auf dem Spiel stehen. Prinzipiell ist auch die akustische Abstrahlung zu betrachten. Die von Tastaturen und Druckern erzeugten akustischen Schwingungen lassen sich über gewisse Entfernungen anpeilen, auffangen und auswerten. l n diesem Zusammenhang ist auch eine andere Gefährdung zu diskutieren: Durch entsprechende Feldstärken können Störsignale auch in empfindliche Geräte einstrahlen und ggf. deren Funktion beeinflussen. Was dies für Sicherheitskomponenten bedeuten könnte, kann man sich leicht ausmalen...

1.8 Verfügbarkeit und Datensicherung Verfügbarkeit

Das Problem der Datensicherung (Backup) wurde bereits einige Male kurz angesprochen. Letztlich handelt es sich um das Problem der Verfügbarkeit von Daten. Sie ist durch technischen Defekt der speichernden Geräte, Alterung von Datenträger-Medien oder manipulative Blockade und Zerstörung bedroht. Hinsichtlich der Maßnahmen ist zu unterscheiden, ob kurze (Sekunden), mittlere (Stunden) oder lange (Tage) Ausfallzeiten toleriert werden können.

62

1.8 Verfügbarkeit und Datensicherung

Sollen die Daten einer Festplatte auch bei Defekten praktisch unterbrechungsfrei zur Verfugung stehen, hilft nur eine Spiegelung der Daten auf einer zweiten Festplatte, die zeitlich verlustfrei oder mit kurzer Verzögerung im Sekundenbereich ansprechbar ist und für den Zeitraum der Reparatur der defekten Festplatte einspringt. Danach wird durch geeignete Synchronisierungsverfahren die Spiegelung wiederhergestellt. Systeme preislich höherer Kategorie bieten weitere Sicherungsmaßnahmen wie fehlerkorrigierende Codes, doppelte Speicherung wichtiger Daten und doppelte Steuerelektronik. Ein klassisches Backup auf externen Medien sollte aber grundsätzlich zusätzlich in Betracht gezogen werden. In allen Systemen gibt es für die "Reparatur" von Festplatten Hilfsprogramme, mit denen einfache Defekte wie z.B. Inkompatibilitäten in System- und Archivspuren auf Datenträgern und Bad Blocks beseitigt werden können. Selbst wenn Datenträger mit normalen Mitteln nicht mehr reparierbar sind, bieten spezielle Laboratorien die Möglichkeit, mit aufwendigem technischen Analysegeräten die Fehlerursachen zu finden und die Datenträger instandzusetzen. Für alle Lösungen gilt: Dies kostet Zeit und Geld - was selten ausreichend vorhanden ist.

Spiegelung

Reparatur

Die Verfügbarkeit von Daten kann auch einfach durch Unterbrechung der Stromversorgung verletzt sein, da die zur Bearbeitung der Daten notwendigen IT-Systeme nicht mehr arbeiten. Einem solchen vollständigen Systemausfall kann durch eine unabhängige Stromversorgung vorgebeugt werden. Dabei gilt grob die Regel, j e länger die garantierte Überbrückungszeit um so teuer sind die entsprechenden Einrichtungen. Für Rechner (z.B. Netz-Server) werden Geräte ( U S V = unabhängige Stromversorgung) angeboten, die die Versorgung für wenige Minuten aufrechterhalten, so daß der Server alle laufenden Applikationen ordnungsgemäß abschließen und ggf. eine Statussicherung für das spätere Wiederaufsetzen durchfuhren kann. In Bereichen, in denen es auf eine extrem hohe Verfügbarkeit der Dienstleistungen ankommt, steht man in einer solchen Situation vor der Entscheidung, soll das System mit Notstrom wie geschildert heruntergefahren und geschlossen werden, oder soll der normale Betrieb in der Hoffnung auf kurzfristige Wiederherstellung der regulären Energieversorgung fortgesetzt werden? Eine Entscheidung für die falsche Alternative kann in einem solchen Kontext hohe Kosten verursachen...

Stromversorgung

Sind Daten durch Manipulation zerstört, muß hier zunächst die Ursache ermittelt werden, weil andernfalls nach der Wiederherstellung der Daten der gleiche Verlust ein zweites Mal droht! Die Ursache zu ermitteln ist aber ebenfalls zeitaufwendig und nicht immer von Erfolg gekrönt!

Manipulation

Können mittlere Ausfallzeiten toleriert werden, hat es sich in Ergänzung aller sonstigen technischen Maßnahmen als sehr sinnvoll erwiesen, Datenbestände in regelmäßigen Abständen auf anderen Datenträgern (Disketten, Bänder, Wechselplatten) zu sichern.

Datensicherung

63

1. Beispiele aus der Praxis

Material

Intervall

Verfahren

Aufbewahrung

Die Praxis zeigt allerdings, daß bei dieser den meisten Anwendern einsichtigen Datensicherung vieles falsch gemacht oder aus Bequemlichkeit unterlassen wird. Datenträger für Zwecke der Datensicherung werden gelegentlich aus Restbeständen ("weil doch so viele Medien benötigt werden") oder aus Sonderangeboten mit zweifelhafter Qualität requiriert. Muß noch erwähnt werden, daß genau das Gegenteil richtig ist? Datenträger für Datensicherung müssen hoch verläßlich sein. Da mit zunehmenden Gebrauch die Datenspeicherung unzuverlässiger wird, müssen die Medien von Zeit zu Zeit erneuert werden. In welchen zeitlichen Abständen Daten zu sichern sind, hängt davon ab, mit welchem Zeitaufwand die zwischen letzter Datensicherung und aufgetretenem Defekt ausgeführten Verarbeitungen nachgezogen werden können. Arbeitet man nur gelegentlich ohne große Datenänderungen an seinem PC, mag es ausreichend sein, wöchentlich oder gar nur monatlich zu sichern. In einem lokalen Netzwerk einer Büroumgebung mit Textverarbeitung, Tabellenkalkulation, Vorgangsbearbeitung und vielleicht 20 arbeitenden Stationen ist eine tägliche Sicherung oft noch zu kurz gegriffen - wenn nicht andere Maßnahmen (z.B. Spiegelserver) getroffen wurden. Es ist zu beobachten, daß Personen ihre Daten auf den gleichen Datenträgern sichern, die bereits bei der letzten Sicherung verwendet wurden. Daß dies wenig sinnvoll ist, müßte einleuchten: Durch das Überschreiben mit den neuen Daten werden die alten Aufzeichnungen zerstört. Fällt während der neuen Sicherung der Rechner aus oder hat der Datenträger plötzlich einen Defekt, sieht man sich in der Situation, keine gesicherten Daten zu besitzen! Deshalb sollte man immer so vorgehen, daß auf einem zweiten Satz von Datenträgern gesichert wird, während der alte Satz sicher aufbewahrt wird und frühestens (!) beim dritten Mal wieder an der Reihe ist {Vater-Sohn-?nnz\^). In größeren Netzwerken und Rechenzentren werden allerdings weit mehr Sicherungssätze aufbewahrt. Bei vorhandener Plattenspiegelung erfüllt eine Sicherungskette bestehend aus täglicher Sicherung (je Wochentag einen neuen Datenträger-Satz), Wochensicherung und Monatssicherung schon hohe Ansprüche. Die Datenträger mit den gesicherten Daten sind so aufzubewahren, daß sie nicht den gleichen Risiken unterliegen, wie die im IT-System gespeicherten Daten: Bricht z.B. in einem Rechenzentrum Feuer aus, ist es wenig hilfreich, wenn die Datenträger an gleichem Ort gelagert waren. Sinnvoll ist es aber, wenn diese wichtigen Datenträger in Schränken aufbewahrt werden, die einbruchssicher, feuersicher, ggf. gegen magnetische Felder gesichert sind. Ihr Aufstellungsort sollte dennoch möglichst nicht der Platz der Verarbeitung sein! Daß kommerzielle Rechenzentren diese Probleme erkannt haben und ernst nehmen, ist an dem getriebenen Aufwand erkennbar: Vielfach wird mehrmals täglich eine volle Sicherung aller Daten durchgeführt; die Bänder werden aus-

64

1.8 V e r f ü g b a r k e i t und D a t e n s i c h e r u n g

gelagert. E s wird sogar soweit gegangen, daß die Fahrt zum A u f b e w a h r u n g s o r t m i t täglich w e c h s e l n d e r Fahrtroute durchgeführt wird... I m F a l l der F ä l l e sind die gesicherten Daten w i e d e r in das I T - S y s t e m einzuspie-

Restore

len. Hierbei hat schon m a n c h e r P C - B e s i t z e r , der artig seine D a t e n a u f Disketten gesichert hatte, eine b ö s e Überraschung erlebt: Z u m Restaurieren benötigt m a n in der R e g e l ein spezielles R e s t o r e - P r o g r a m m . W a s tun, w e n n durch den D e f e k t der Festplatte auch dieses R e s t o r e - P r o g r a m m zerstört wurde und an anderer Stelle nicht m e h r verfügbar ist? Schlußfolgerung: E s ist stets (mindestens) e i n e Diskette vorzuhalten, die b o o t f ä h i g ist und das R e s t o r e - P r o g r a m m (ggf. mit allen O v e r l a y s ) enthält. B e i dieser G e l e g e n h e i t m a c h t es sich ebenfalls bemerkbar, o b der B e n u t z e r das

Notfalltraining

Restaurieren v o n D a t e n v o r h e r geübt hat. W e r an dieser S t e l l e unsicher ist oder gar nicht weiß, w a s zu tun ist, sieht sich in einer kritischen Situation. D e s h a l b : B a c k u p und R e s t o r e dokumentieren und einige M a l e üben, damit e s "sitzt"! P C - B e n u t z e r haben sicher s c h o n bemerkt, daß die B a c k u p - und R e s t o r e - P r o -

Inkompatibilität

g r a m m e verschiedener D O S - V e r s i o n e n nicht miteinander klar k o m m e n . D a s Installieren einer neuen D O S - V e r s i o n ist deshalb aus S i c h t der Datensicherung ein kritischer Prozeß. D i e Installationsprogramme für die aktuellen D O S - V e r sionen bieten aber an, eine D i s k e t t e zu erstellen, mit deren H i l f e das S y s t e m wieder in seinen alten Zustand versetzt werden kann. D i e s e M ö g l i c h k e i t sollte man in j e d e m Fall nutzen. D i e s e D i s k e t t e ist zumindest solange aufzubewahren, bis die D a t e n s i c h e r u n g vollständig a u f die neue B e t r i e b s s y s t e m - V e r s i o n umgestellt worden ist. Letzteres sollte unmittelbar nach der Installation einer neuen B e t r i e b s s y s t e m - V e r s i o n g e s c h e h e n ! B e s o n d e r s interessant wird es, wenn das R e s t o r e - P r o g r a m m nur unter W i n dows oder vergleichbaren S y s t e m - E r w e i t e r u n g e n lauffahig ist. D i e s e E r w e i t e rungen muß man bei Plattendefekt natürlich zunächst installieren ( v o n den hoffentlich noch vorhanden Originaldisketten), was bedeutet, daß die Datensicherung und -Wiederherstellung im Einzelfall ein dornenreicher, zeitaufwendiger, aber unvermeidbarer W e g i s t . . . E i n besonderes P r o b l e m gibt es mit d e m B a c k u p in M u l t i - P r o c e s s i n g - S y s t e -

Multi-Processing

m e n : Hier sollte im E i n z e l f a l l geprüft werden, ob das B a c k u p - P r o g r a m m auch s o l c h e Dateien sichert, die z u m Zeitpunkt der Datensicherung von anderen Prozessen genutzt werden. Insbesondere, wenn diese Prozesse schreibberechtigt sind, kann es zu einer inkonsistenten Sicherung dieser D a t e i e n k o m m e n . M a n c h e B a c k u p - R o u t i n e n lassen geöffnete D a t e i e n bei der S i c h e r u n g aus. D i e s ist m e i s t e n s vernünftig, sofern der S y s t e m - V e r w a l t e r hierüber e i n e Mitteilung erhält und die fraglichen D a t e i e n ggf. später sichert. I m F a l l eines vollständigen A u s f a l l s der speichernden G e r ä t e oder der R e c h n e r

Ausweichrechen-

sind Spiegelung und B a c k u p keine Lösung. Hier hilft nur n o c h das Vorhalten

zentrum

von Ersatzgeräten - meist an e i n e m anderen Ort. S o l c h e Ausweichinstallationen benötigen im F a l l der F ä l l e e i n e b e s t i m m t e Anlaufzeit (Systeminstallation,

65

1. Beispiele aus der Praxis

Systemstart, Dateneinspielung), so daß bis zur Verfügbarkeit der Daten Stunden oder sogar Tage vergehen können. Der hohen Kosten solcher Ausweichinstallationen wegen werden diese oft von mehreren Firmen genutzt oder sogar von entsprechenden Dienstleistern transportabel angeboten. Mit der Staffelung der Maßnahmen (Spiegelung - Backup - Ausweichsysteme) ist das heute technisch und administrativ Mögliche getan. Auf die Notwendigkeit, alle Verfahren regelmäßig zu üben (Notfalltraining), kann nicht oft genug hingewiesen werden! Archivierung

Ein der Datensicherung verwandtes Problem ist das der Langzeit-Archivierung von Daten, die zum Teil in Vorschriften und Gesetzen für juristisch relevante Daten und Verfahren geregelt ist. Durch die Möglichkeit, optische Datenträger (WORM, Write Once Read Many) nutzen zu können, liegen langzeitstabile Medien vor, die den klassischen Bändern und Kassetten eindeutig vorzuziehen sind. Dabei werden aber nur Daten abgeschlossener Vorgänge gesichert. Auf kurze Zugriffszeiten kommt es dabei weniger an, vielmehr auf die Langzeitverfügbarkeit.

1.9 Datenübertragung, lokale und öffentliche Netze Die prinzipiellen Gefahren bei der Datenübertragung sind gleichermaßen in einem LAN, einem Corporate L A N " oder einem WAN 1 2 gegeben: • Abhören von gesendeten Daten, • Wiedereinspielen von Daten in die Übertragungsstrecke (Replay), • Blockieren von Netzwerkdiensten (Denial of Service), • Maskerade, d.h. der Manipulant gibt sich für eine andere Person oder Station aus, • Verändern von Daten anderer Nutzer während der Übertragung. Übertragungsmedium

Geht man von einem Manipulanten aus, der nur Zugriff zu den Übertragungsstrecken (Leitungen, Funk) hat, so sind diese Bedrohungen j e nach Übertragungsmedium unterschiedlich zu bewerten: Sind die Stationen durch klassische Verkabelung (Draht, Koaxial-Kabel) miteinander verbunden, sind alle aufgezählten Manipulationen möglich. Bei Lichtwellenleitern ist das Abhören stark erschwert, aber nicht gänzlich ausgeschlossen - die übrigen Bedrohungen dürften hier aber weniger relevant sein. Bei kabellosen Verbindungen (Funk, Infrarot, z.B. Wireless LAN) sind vor allem die ersten vier Bedrohungen in Betracht zu ziehen. 11

Verbindung mehrerer L A N s über ein öffentliches N e t z , z.B. bei Firmen mit vielen Standorten.

12

66

W i d e Area Network, Weitverkehrsnetz.

1.9 Datenübertragung, lokale und öffentliche Netze

Bei der Funkübertragung ist das Abhören relativ leicht durchfuhrbar. In lei- Abhören tungsgebundenen Netz-Topologien von LANs können die zu übertragenden Daten an vielen, oft sogar an allen Arbeitsstationen vorbeilaufen: Dies gilt für logische Ring- und Busstrukturen. Durch Manipulationen an der Treiber-Software in einer Arbeitsstation oder durch Verwendung von Geräten zur Wartung und Überprüfung von lokalen Netzwerken ( S n i f f e r ) ist es in der Regel möglich - ohne vom Netzwerk registriert zu werden und unter Umgehung der vorhandenen Zugriffskontrollen -, alle auf dem Netz zirkulierenden Datenpakete aufzuzeichnen, sie nach Empfänger und Absendern zu sortieren und die eigentlichen Nutzdaten auszuwerten. Bei logischen sternförmigen Netzen sind diese Bedrohungen sehr viel geringer einzustufen, da hier Datenpakte nur auf der Strecke zwischen Server und der Zielstation laufen13. Mit etwas höherem Aufwand können aufgefangene oder selbst erzeugte Pakete Verändern, wiedereingespielt werden, um sich in bestehende Kommunikationsbeziehungen Wiedereinspielen einzuschalten und ggf. manipulierte Nutzinformationen einzuschleusen. Die gängigen Übertragungssysteme und Netzwerk-Betriebssysteme besitzen nur unzureichende Schutzmaßnahmen zur Verhinderung eines solchen Replays oder einer Manipulation der Nutzdaten. Es ist relativ leicht, durch dauernde Inanspruchnahme von Netzwerkdienstlei- Blockieren stungen (z.B. Übertragung großer Datenmengen) das Netzwerk so auszulasten, daß anderen Benutzern die Arbeitsmöglichkeiten reduziert oder ganz blockiert werden (Denial of Service). Eine weitere Angriffsmöglichkeit stellt der Versuch einer Arbeitsstation dar, Maskerade sich z.B. in einem LAN als ein Server auszugeben. Diese je nach Verkabelungssituation mehr oder weniger erfolgversprechende Strategie - es sind einige Timing-Probleme vorhanden - kann dazu genutzt werden, die Login-Versuche anderer Arbeitsstationen abzufangen und auf diesem Wege an die User-IDs und Paßwörter zu gelangen - sofern diese bei der Übertragung nicht geeignet geschützt werden. Eine Verschlüsselung ist allein nicht ausreichend: Es reicht dem Manipulanten, den aufgefangenen verschlüsselten Wert seinerseits an den Server weiterzuleiten, um erfolgreich authentisiert zu werden. Abhilfe ist nur dadurch möglich, daß in die Verschlüsselung Daten wie die Stationskennung oder die Uhrzeit eingehen, die vom Manipulanten nicht ohne weiteres reproduziert werden können. Versuche dieser Art werden dann vom echten Server als ungültig erkannt. An eine "sichere" Datenübertragung bzw. ein "sicheres" Netzwerk müssen des- Anforderungen halb folgende Forderungen gestellt werden: • Sicherung der Nutz- und Verbindungsdaten (Adressen) gegen Verlust der Vertraulichkeit und Unversehrtheit, 13

Es ist zu unterscheiden z w i s c h e n der physikalischen und der logischen Netzstruktur; erstere gibt die Verkabelungsart an, letztere den Datenfluß. Ein physikalischer Stern kann z.B. logisch als Ring betrieben werden.

67

1. Beispiele aus der Praxis

• Sicherung des Netzwerks gegen Replay und Maskerade, • Verfügbarkeit von (unverfälschten) Netzwerkdiensten. Maßnahmen

Wie sehen Maßnahmen gegen den Verlust der Vertraulichkeit bzw. Integrität aus? Ist die Übertragung leitungsgebunden, kann in beschränkten Umgebungen die Verwendung von geschützt verlegten Kabeln helfen. Im Extremfall müssen gepanzerte, unter Überdruck stehende Rohre mit Druckmeldern zum Entdecken des "Anbohrens" verwendet werden - was allerdings beträchtliche Kosten verursacht. Sind einfache physische Sicherungen nicht möglich, bleibt im Prinzip nur noch der Einsatz von Verschlüsselungstechniken. Kommunizieren nur zwei Partner miteinander, reicht es aus, Ende-zu-Ende zu verschlüsseln, was leicht durch Einsatz von PC-Equipment und Nutzung eines öffentlichen Netzes möglich ist. Solche "kleinen" Lösungen sind aber schnell und kostengünstig durch die Nutzung marktgängiger Verschlüsselungskarten für PCs realisierbar.

Öffentliches

I Abbildung 1-11: Übertragungssicherung vom Typ "Ende-zu-Ende" Liegt ein Netzwerk im engeren Sinne vor (viele Kommunikationspartner mit hohem Datenaufkommen) sind Sicherungsmaßnahmen auf verschiedenen Ebenen erforderlich: 1. In unsicherer Umgebung sind materielle Objekte zu sichern (Sicherung des Aufstellungsortes von Netz-Servern, Sicherung der Workstations gegen unbefugtes Öffnen und gegen Manipulation von Adapter-Karten, Verplomben von Steckern der Netzverkabelung, Vermeiden von "freien" Anschlußdosen usw.). 2. In unsicherer Umgebung sind Software-Manipulationen z.B. an den Netzwerk-Treibern zu verhindern. Hierzu sind wirksame Zugriffskontrollen auf den Arbeitsstationen oder sogar weitergehende Maßnahmen zur Wahrung der Integrität erforderlich. 3. Auf der Übertragungsstrecke sind Verschlüsselungsverfahren einzusetzen.

68

1.9 Datenübertragung, lokale und öffentliche Netze

Dabei kann in den Arbeitsstationen • mit festen Schlüsseln (geringerer Sicherheitsgrad) oder • mit sitzungsabhängigen, also schnell wechselnden Schlüsseln (höherer Sicherheitsgrad) gearbeitet werden. Bei Punkt 3 ist ein vertrauenswürdige Schlüsselerzeugung (Key Server) und Schlüsselverteilung (Key Distribution) erforderlich. Unter Umständen können diese Funktionen in anderen Netzeinrichtungen wie z.B. einem File Server integriert sein. Workstation

Workstation

Workstation

Workstation

Abbildung 1-12: "Sicheres" LAN mit Schlüsselverteilung Der Austausch von Schlüsseln muß natürlich geschützt verlaufen, d.h. in aller Regel sind die Schlüssel selbst verschlüsselt zu übertragen. Hierfür und für die Verarbeitung der Nutzdaten müssen die Arbeitsstationen und die Server über Einrichtungen zur Ver- und Entschlüsselung der übertragenen Daten verfugen. Wegen der Komplexität der Netze, der oft frei zugänglichen Infrastruktur (Schaltkästen, Hausanschlüsse, Knotenbetriebsstellen) und der Nutzung von Funkstrecken (einschließlich Satelliten) sind die Sicherheitsprobleme bei Öffentlichen Netzen ganz massiver Art. Sie sind zwar konzeptionell behebbar, Lösungen sind jedoch aus Kosten- und Akzeptanzgründen schwerlich in die traditionellen Netze zu integrieren. Für den transparenten, flächendeckenden Einsatz in öffentlichen Netzen sind sichere und gleichzeitig ausreichend schnelle Verschlüsselungsmethoden erforderlich. Gleichzeitig muß der finanzielle Aufwand zur Integration solcher Dienstleistungen in öffentlichen Netzwerken durch einen entsprechenden Bedarf der Nutzer wirtschaftlich vertretbar sein. Neue digitale Systeme wie das ISDN kommen hier eher in Frage; zur Zeit wird an Verschlüsselungsdiensten für ISDN gearbeitet.

69

Key Server/ Distribution

1. Beispiele aus der Praxis

Sicherheitsdienste

Generell stellt sich aber das Problem, ob der Netzbetreiber alle Nutz- und ggf. auch Protokolldaten verschlüsselt, Verschlüsselungsdienste nur wahlweise anbietet, Authentisierungsverfahren und Notarfunktionen14 vorsieht, oder aber alle diese Probleme dem Endbenutzer überläßt. Dieser kann mit einigem finanziellen Aufwand die meisten Funktionen auch über spezielle Geräte Endezu-Ende abwickeln.

Verfügbarkeit

Verfügbarkeit bei der Datenübertragung ist vor allem durch redundante Übertragungssysteme und sichere Betriebssysteme zur Betriebsmittelbegrenzung (und damit zum Ausschluß des Denial of Service) erreichbar.

Admin-Hilfe

Für die Verwaltung von komplexen vernetzten Systemen, der Analyse sicherheitsrelevanter Ereignisse und der Planung von Neu- und Erweiterungsinstallationen ist es sehr hilfreich, folgende Informationen verfügbar zu haben: 1. Alle relevanten Hardware- und Software-Daten der Knoten (Rechner, Gateways, Bridges, Repeater usw.), 2. Aufstellungsort der Knoten, 3. Verwendungszweck der Knoten, 4. zur Nutzung der Knoten berechtigte Personen, 5. getroffene Sicherungsmaßnahmen, 6. logische und physikalische Verbindungen zwischen den betrachteten Knoten und zu anderen Systemen, 7. Verkabelungsart und Verkabelungsführung. Die Informationen können in schriftlicher Form aufbewahrt, besser noch in Datenbanken, ggf. sogar in entsprechenden Expertensystemen abgelegt werden. Spezielle Produkte für diesen Zweck sind auf dem Markt erhältlich. Ist eine Verbindungsliste nach Punkt 6 erstellt worden, offenbart sie insofern oft schon einige Überraschungen, als plötzlich deutlich wird, welche Kommunikationsverbindungen überhaupt möglich und damit Gegenstand wie Träger von Manipulationen sein können.

14

70

Ein neutraler Dritter bestätigt die "Echtheit" von Transaktionen.

2. Grundbegriffe 2.1 Informationen, Daten, Verarbeitung, IV- und ITSystem Das Gebiet der Informationssicherheit (Information Security) beschäftigt mit allen Fragen der sicheren Verarbeitung von Informationen. Vielfach wird auch der Begriff IV-Sicherheit1 verwendet. Das Adjektiv sicher beschreibt einen sehr breiten Bereich von Anforderungen: Ordnungsmäßigkeit, Qualität, Sicherheit vor Manipulationen, Ausfallsicherheit, Korrektheit u.v.m. Eine genauere Definition des Begriffs Sicherheit soll etwas später erfolgen. Informationen werden zur (automatisierten) Verarbeitung codiert und in dieser Form dann als Daten bezeichnet. Beispiele für Codes sind binäre Darstellungen, Änderungen des magnetischen Flusses (z.B. auf Datenträgern), elektrische oder optische Signale (z.B. bei der Datenübertragung). Daten können unter anderem in Dateien, Sätzen von Dateien, Feldern einer Datenbank, in Datenpaketen von Kommunikationsprotokollen, aber auch in Betriebssystem-internen Strukturen wie Buffers, Pipes, Queues organisiert und gespeichert sein. Programme sind Daten in dem zuvor skizzierten Sinne: Sie sind Darstellung eines Verfahrens in codierter Form. Speichermedien für Daten sind z.B. Papier, magnetische/optische Medien, Speicherchips. Unter Verarbeitung fallen hier insbesondere die Erfassung, die Ein- und Ausgäbe, Speicherung, Verknüpfung und Auswertung sowie die Übertragung von Daten. Mit Hilfe von Hard- und Software können aber auch Vorgänge wie das Steuern von Produktionsabläufen, Messen und Regeln, Überwachen und Kontrollieren usw. ausgeführt werden. Solche Verfahren fallen ebenfalls unter den Begriff Verarbeitung. Die Informationsverarbeitung erfolgt heutzutage immer mehr durch technische Systeme (Computer, Netzwerke) bestehend aus Hard- und Software; solche Systeme werden als IT-Systeme bezeichnet. IT-Systeme sind in eine administrative und technische Infrastruktur eingebettet. Man denke bspw. an die komplexe Struktur eines großen Rechenzentrums mit all seinen administrativen Verfahren und der technischen Infrastruktur (Zugangssicherung, Feuermelder, Datensicherungsschränke, ausfallsichere Stromversorgung usw.) sowie den handelnden Personen - oder etwa an den Fall eines komplexen öffentlichen Netzwerks. IV = Informationsverarbeitung

71

Sicherheit

Daten

Verarbeitung

IT-System

2. Grundbegriffe

IV-System

Ein solches umfassendes informationsverarbeitendes System wird als

IV-

System bezeichnet. Um in einem IV-System eine sichere Informationsverarbeitung zu realisieren, müssen sowohl die administrativen Verfahren, die Infrastruktur, der personelle Bereich als auch das IT-System betrachtet werden.

IV-System:

Abbildung 2-1: Abgrenzung IV-System versus IT-System IT-Verfahren

Das IV-System stellt Dienstleistungen wie z.B. Gehaltsabrechnung, SoftwareProduktion, Online-Transaktion bereit. Diese einzelnen Dienstleistungen werden auch als IT-Verfahren2 bezeichnet. Sie werden durch alle Komponenten eines IV-Systems gemeinsam erbracht. Sie stellen eine logische Zusammenfassung verschiedener Dienstleistungen innerhalb und außerhalb des IT-Systems dar.

2.2 Ordnungsmäßigkeit, IV-Sicherheit, IT-Sicherheit

Ordnungsmäßigkeit

Funktionsgarantie

Bei dem Versuch, den zunächst noch unklaren Begriff der Sicherheit näher zu präzisieren, stößt man in der Literatur und in der Fachdiskussion auf sehr unterschiedliche Zielvorstellungen: Vielfach wird Sicherheit als Ordnungsmäßigkeit definiert. Hierunter versteht man das Ziel oder die Eigenschaft, Daten so zu verarbeiten, wie es der Vorstellung des Betreibers eines IV-Systems entspricht. Entsprechende Verfahrensvorschriften werden auch Spezifikationen genannt. Wird also ein IV-System so betrieben, daß die IT-Verfahren gemäß der Spezifikation ablaufen, spricht man von ordnungsgemäßer Datenverarbeitung. Ordnungsmäßigkeit umfaßt folgende Eigenschaften: Garantie der Funktion in normalen und kritischen Situationen, Kontroll- und Revisionsmöglichkeiten. Qualitätssicherung. Rechtssicherheit. Die Vorsorge vor technischem Ausfall bzw. Versagen aufgrund der Alterung der technischen Systeme, schlechter technischer Qualität oder von Naturereig2

72

Eigentlich m ü ß t e es hier

¡V-Verfahren heißen;

dieser Begriff ist aber nicht gebräuchlich.

2.2 Ordnungsmäßigkeit, IV-Sicherheit, IT-Sicherheit

nissen wie Feuer, Wassereinbruch, Blitzschlag usw. ist ein wesentliches Element der Ordnungsmäßigkeit. Ein ordnungsgemäßes System funktioniert also auch in den genannten kritischen Situationen wie spezifiziert. Ein zweites Element der Ordnungsmäßigkeit ist die Kontrolle von Verfahren und Ergebnissen. Plausibilitätskontrollen bei der Datenein- und -ausgabe mit dem Ziel, fehlerhafte Eingaben bzw. Bedienungsfehler erkennen zu können, sind eine Funktion der Ordnungsmäßigkeit. Die Qualitätsprüfung und -Sicherung der Ergebnisse sind ebenfalls der Ordnungsmäßigkeit zuzurechnen. Ein weiteres wichtiges Ziel der Ordnungsmäßigkeit ist die Nachvollziehbarkeit bzw. Revisionsfähigkeit von Abläufen. Dies dient dazu, im nachhinein die korrekte Ausfuhrung von Verarbeitungen oder verfahrensbedingte Fehler nachweisen zu können. Das Aufzeichnen aller Aktionen in einem Betriebssystem (Beweissicherung/ Protokollierung, im Englischen: Accounting) hat genau diesen Zweck, ist somit eine Funktion der Ordnungsmäßigkeit. Im Zusammenhang mit Dienstleistungen ist auch die Rechtssicherheit zu betrachten. Nicht vorhandene Kontrollmöglichkeiten und fehlende Aufzeichnungen können im Streitfall die eigene Rechtsposition entscheidend schwächen. Weitere Aspekte sind die Rechtsverbindlichkeit von elektronischer Kommunikation und Fragen der (Produkt-)Haftung. Ordnungsmäßigkeit kann durch solche Testverfahren nachgewiesen werden, die eine Konformität zur Spezifikation bestätigen oder verneinen können. Im engeren IT-System sind damit Methoden zu betrachten, durch die z.B. das korrekte Funktionieren der Software gegenüber der Spezifikation nachgewiesen wird. Die Konformitätsprüfung {Conformance Testing) ist deshalb eine Nachweismethode für die Ordnungsmäßigkeit; sie wird oft zum Nachweis der Kompatibilität zu einem Standard (z.B. Schnittstellenstandard bei X/OPEN) eingesetzt. Zusammenfassend ergibt sich: • Ordnungsmäßigkeit ist eine verfahrensbezogene Eigenschaft. • Da IT-Verfahren durch die Gesamtheit des IV-Systems realisiert werden, ist Ordnungsmäßigkeit im Kontext des IV-Systems zu betrachten. • Nachweismethode ist vor allem das Conformance Testing. IT-Sicherheit befaßt sich dagegen schwerpunktmäßig mit der automatisierten Verarbeitung von Daten in IT-Systemen; hier geht es darum, Daten so in IT-Systemen zu verarbeiten, daß ein angemessenes Maß an Schutz gegenüber Manipulationsversuchen gegeben ist. Begriffe wie Authentisierung und Zugriffskontrolle kennzeichnen Funktionen der IT-Sicherheit, da sie unautorisierte Zugriffe auf Daten abweisen können. Das Auswerten von Protokollaufzeichnungen eines Betriebssystems (im Englischen: Audit) mit dem Ziel, Manipulationsversuche oder bereits erfolgte Si-

73

Kontrollfunktion

Qualitätssicherung Revision

Rechtssicherheit

Conformance Testing

IT-Sicherheit

2. Grundbegriffe

Penetrationstests

cherheitsverstöße aufzuspüren, ist eine weiteres Beispiel für eine typische Funktion der IT-Sicherheit. Dabei wird ein Unterschied zur Ordnungsmäßigkeit deutlich: Die IT-Sicherheit betrachtet schutzwürdige Objekte (z.B. Daten oder Dateien) in einem IT-System, ist also objektbezogen und nicht verfahrensbezogen. Zur Prüfling der IT-Sicherheit werden unter anderem Penetrationstests verwendet. Sie sollen Sicherheitslücken aufspüren. Dabei kann man allerdings nur auf Erfahrung, Systemkenntnisse und Intuition der Prüfer vertrauen - eine sicher zum Ziel führende Methode existiert letztlich nicht. Solche Penetrationstests sind Teil von Evaluierungen nach Sicherheitskriterien (aber kaum Gegenstand von Konformitätsprüfungen). Zusammenfassung: • IT-Sicherheit ist eine objektbezogene Eigenschaft. • IT-Sicherheit wird im Kontext des IT-Systems betrachtet. • Nachweismethoden sind vor allem Penetrationstests - eingebettet in Evaluierungen. Hinsichtlich der Überschneidung der Begriffe Ordnungsmäßigkeit und IT-Sicherheit sei noch folgendes erwähnt: 1. Technische Defekte oder Systemausfälle können in manipulativer Absicht herbeigeführt werden. Die IT-Sicherheit versucht solche Intentionen zu vereiteln, ggf. die Schadenauswirkungen zu mindern oder die Vorfälle zumindest zu entdecken. Die Ordnungsmäßigkeit dagegen betrachtet nicht Manipulationen, sondern "normale" technische Defekte z.B. aufgrund von Materialermüdung bzw. Materialalterung, zufällige Katastrophenereignisse (Feuer, Blitzschlag, ...) und Organisationsmängel. 2. Es ist klar, daß eine ordnungsgemäße Verarbeitung noch keine sichere Verarbeitung sein muß, und umgekehrt IT-Sicherheit noch keine Ordnungsmäßigkeit garantiert. Während Ordnungsmäßigkeit garantierte Abläufe voraussetzt, setzt Sicherheit die Abwesenheit (oder ausreichende Minderung) von Gefahren voraus. Kurz und etwas vereinfachend: • ordnungsgemäß = tut, was es soll • sicher = tut nichts, was es nicht soll. 3. Ein IT-System wird sich in aller Regel aus einer Reihe von einzelnen Komponenten bzw. Produkten (Hard- und Software) zusammensetzen. Diese Komponenten müssen so entworfen, hergestellt, integriert und eingesetzt werden, daß den gesteckten Zielen (Ordnungsmäßigkeit oder/und IT-Sicherheit) Rechnung getragen werden kann. Andernfalls sind Schwachstellen die Folge. Diese können konstruktionsbedingt oder einsatzabhängig sein.

74

2.3 Verfugbar, vertraulich, integer, verbindlich

Im Hinblick auf Konstruktionsmängel spielen somit Maßnahmen und Verfahren eine große Rolle, die die Zahl von • zufälligen oder verfahrensimmanenten Fehlern bzw. • "absichtlichen" Fehlern im Entwurfs-, Herstellungs- und Auslieferungsprozeß von IT-Produkten reduzieren können. Eine unsachgemäßer Einsatz der technischen Systeme kann einerseits Sicherheitslücken, andererseits nicht ordnungsgemäße Abläufe und Ergebnisse zur Folge haben. 4. Bei der Integrität, Verfügbarkeit, Korrektheit und teilweise auch bei der Vertraulichkeit sind sowohl IT-Sicherheit wie Ordnungsmäßigkeit betroffen, diskutieren aber unterschiedliche Arten von Garantien. Ein vielleicht etwas gewagter Ansatz ist es, Ordnungsmäßigkeit und Sicherheit als zwei unterschiedliche Strategien für das gleiche Ziel zu betrachten: die Qualität der Informationsverarbeitung. Die eine Strategie versucht, Qualität durch garantiertes Funktionieren zu erreichen, die andere durch Ausschluß von Sicherheitslücken. Dies legt die Definition nahe, Qualität als Ordnungsmäßigkeit und Sicherheit festzulegen. Für den Begriff der IV-Sicherheit gibt es zwei unterschiedliche Definitionen: Ersetzt man in der obigen Betrachtung der IT-Sicherheit das Kürzel IT durch IV, so hat IV-Sicherheit die gleichen Ziele wie die IT-Sicherheit - nur im Kontext des größeren IV-Systems. Diese Bedeutung wird in diesem Buch zugrundegelegt. Die zweite Bedeutung ist: IV-Sicherheit ist die Zusammenfassung von Ordnungsmäßigkeit und IT-Sicherheit.

Konstruktion

Anwendung

Qualität

IV-Sicherheit

2.3 Verfügbar, vertraulich, integer, verbindlich In diesem Abschnitt sollen die Grundwerte oder Grundziele • Verfügbarkeit von Daten, Dienstleistungen und Maschinen, • Vertraulichkeit von Informationen, • Unversehrtheit (Integrität) von Daten und Systemen, • Verbindlichkeit von Daten und Dienstleistungen näher beschrieben werden. Verlust oder Einschränkung solcher Grundwerte stellen stets Bedrohungen dar. Unter Verfügbarkeit (Availability) wird die Eigenschaft von Daten bzw. Dienstleistungen verstanden, immer dann "verfugbar" zu sein, wenn ein (autorisierter) Benutzer sie bearbeiten bzw. in Anspruch nehmen will. Bei Daten ist Verfügbarkeit im Sinne von "Zugriff ist in akzeptabler Zeit möglich" gemeint. Dienstleistungen sind dann verfügbar, wenn sie abrufbar sind und in akzeptabler Zeit ausgeführt werden. Maschinen sind dann verfugbar,

75

Verfügbarkeit

2. Grundbegriffe

wenn ihre Funktion aufrechterhalten bleibt oder nur in akzeptablem Rahmen verzögert ist. Die Verfügbarkeit kann durch mehr zufällige Faktoren wie Katastrophen (Feuer, Wasser usw.), technisches Versagen (durch schlechte Qualität, Alterung, ungeeignete Umweltbedingungen usw.), unbeabsichtigte Aktionen von Personen (Bedienungsfehler, Fehler bei der Wartung usw.) beeinträchtigt werden. Dies betrifft den Bereich der Ordnungsmäßigkeit. Aber auch absichtliche Aktionen (Manipulation, Sabotage) mindern die Verfügbarkeit: Zerstörung von Daten, Beeinträchtigung der Zugriffsmöglichkeiten auf Daten, absichtliche Zerstörung von Hardware-Komponenten, Einbau von Software-Fehlern und Einbringen von Schadenprogrammen. Dies ist der Kontext der IT-Sicherheit. Beispiel: Die klassische Dienstleistung im Bereich der Netzwerke ist der Datentransport, dessen Verfügbarkeit betriebsbedingt durch hohes Datenaufkommen oder durch technische Defekte vermindert werden kann. Eine andere Gefahr ist der Denial of Service: Ein Netzwerk wird absichtlich so mit Datenpaketen "vollgepumpt", daß andere Benutzer lange Wartezeiten in Kauf nehmen müssen oder überhaupt keinen Zugriff mehr auf die Netz-Ressourcen haben. Ein IT-System, das solchen Bedrohungen gegen die Verfügbarkeit widerstehen soll, benötigt zuverlässige Hard- und Software-Komponenten mit einem angemessenen Grad an Korrektheit, Methoden der Fehlererkennung und Fehlerüberbrückung, eine Zugriffskontrolle zur Abwehr von illegalen Aktionen und zur Begrenzung von Betriebsmitteln. Vertraulichkeit

Vertraulichkeit

(Confidentiality)

beinhaltet die Forderung, daß Informationen

nur den dazu im Einzelfall autorisierten Personen zu Kenntnis gelangen dürfen. Zwei Beispiele: In einem Netzwerk könnten Datenpakete auf dem Leitungsbzw. Übertragungswege abgehört oder an einen falschen Empfänger geleitet werden. Im Zusammenhang mit dem angedachten Einsatz z.B. von Chipkarten im Gesundheitswesen (sensitive personenbezogene Daten) stellt sich das Problem, daß die auf der Chipkarte gespeicherten Daten nicht jedermann zugänglich sein sollen, sondern nur den Ärzten, den Krankenkassen und dem Patienten selbst. Sollen Informationen vertraulich bleiben, dürfen nur autorisierte Subjekte Zugriffsrechte zu den Daten erhalten. Dies hat zur Konsequenz, daß ein entsprechendes IT-System über eine Zugriffskontrolle verfugen muß. Sie basiert auf der Möglichkeit, für die Subjekte eine Identifikation und Authentisierung durchfuhren zu können.

76

2.3 Verfügbar, vertraulich, integer, verbindlich

Unversehrtheit oder Integrität (Integrity) umfaßt inhaltlich die Problematik der unerwünschten Änderung von Daten und Systemen mit der Folge, daß • Daten inhaltlich inkorrekt sind, darauf aufbauende Schlußfolgerungen unzutreffend sind oder Dienstleistungen falsch oder unvollständig erbracht oder nur vorgetäuscht werden, • Zeitbedingungen nicht mehr eingehalten werden können, Steuerungen inkorrekt ablaufen.

Unversehrtheit

Die Integrität kann durch Bedienungsfehler, Fahrlässigkeit oder technischen Defekt (einschließlich inkorrekt funktionierender Hard- und Software) verletzt werden. Dies kann zu einem anderen technischen Verhalten, Funktionsausfällen oder inkonsistenten Daten fuhren. Dies ist ein Aspekt der Ordnungsmäßigkeit. Integritätsverletzungen können aber auch beabsichtigt sein (Manipulation, Sabotage). Viele Programme mit Schadenfiinktionen (z.B. Viren) verletzen die Integrität der Programme und Prozesse. Die Zielrichtung, dies zu verhindern oder zumindest zu entdecken, wird bei der IT-Sicherheit verfolgt. Gegen Integritätsverlust wirken Plausibilitätskontrollen (z.B. bei der Dateneingabe), fehlerkorrigierende Codes (bei der Datenübertragung und -speicherung), Integritäts- und Signaturprüfungen (z.B. bei Datenbanken, Betriebssystemen und wichtigen Programmen - auch im Kontext von Viren), aber auch die Zugriffskontrolle und damit zusammenhängende Funktionen. Ein besonderes Problem stellt die Verbindlichkeit von Kommunikation und vertraglichen Transaktionen dar, die auf elektronischem Wege zustande kommen. Dies ist zunächst vor allem ein Problem der juristischen Akzeptanz von elektronischen Verfahren. Technisch beinhaltet es die Authentizität von Kommunikationsinhalten sowie Fragen des Anerkennens bzw. Leugnens von Kommunikationsbeziehungen. Diese Aspekte können sowohl im Hinblick auf Manipulationen als auch im Kontext von technischen und menschlichen Fehlern betrachtet werden. Ein IT-System muß zur Abwehr dieser Bedrohung die Korrektheit von Daten, die Nachweisbarkeit des Absendens und Empfangens, elektronische Unterschriften, die Möglichkeit neutraler Gutachter (Notare) garantieren.

Verbindlichkeit

Vor allem im Safety-Bereich ist es üblich, die Inkorrektheit 3 von Software als eine Bedrohung aufzufassen. Dabei wird von der Integrität von Software im Sinne der Korrektheit bzw. des korrekten Funktionierens gesprochen. Im engeren Security-Bereich wird Korrektheit aber erst dann diskutiert, wenn es um die Realisierung von Sicherheitsfunktionen (in Hard- und Software)

Inkorrektheit

3

Im S i n n e der folgenden A b s c h n i t t e ist Inkorrektheit eine P r i m ä r - B e d r o h u n g der S a f e t y , a b e r w e d e r e i n e Primär- noch e i n e S e k u n d ä r - B e d r o h u n g der S e c u r i t y .

77

2. Grundbegriffe

geht. Die Korrektheit nachzuweisen ist dort ein Ziel von Evaluierungen. Die Möglichkeit, Software in manipulativer Absicht inkorrekt zu machen, wird zwar als Bedrohung aufgefaßt, aber unter anderen Überschriften eingeordnet: • bei der Herstellung von Software unter Sicherheit in der Entwicklungsumgebung und • bei der Anwendung unter Abgrenzung sicherheitsrelevanter Funktionen gegenüber "unsicheren" Komponenten, Prozessen, Aktionen von Benutzern. Allen aufgeführten Grundbedrohungen ist gemein, daß sie betriebsbedingt, durch technischen Defekt, durch Fahrlässigkeit oder durch Manipulation gegeben sein können. Sie sind dadurch stets sowohl unter Ordnungsmäßigkeit wie auch unter IT-Sicherheit zu diskutieren. Interessant ist noch, wann eine Verletzung der Grundziele eigentlich auffällt: Bei der Vertraulichkeit ist gar nicht sicher, daß eine Verletzung überhaupt bemerkt wird; bei der Integrität fällt eine Verletzung nur mit zeitlicher Verzögerung auf - nämlich dann, wenn sich als Folgerung nicht integerer Daten augenfällig falsche Ergebnisse oder grob abnormales System-Verhalten einstellt. Ein Verlust der Verfügbarkeit z.B. von Dienstleistungen wird sofort bemerkt, wenn diese Dienstleistung in Anspruch genommen werden soll. Bei der Verbindlichkeit wird ein Verlust erst im Streitfall - also erst nach erfolgter Verarbeitung der Daten - relevant. Die folgende Abbildung veranschaulicht diese Überlegungen.

Verfügbarkeit

, . Integrität

1 frühzeitig

1 bald

w

Vertraulichkeit Verbindlichkeit 1 sehr spät oder gar nicht

Abbildung 2-2: Zeitpunkt der Entdeckung des Verlustes eines Grundziels

78

>

2.4 Analysen von Bedrohungen, Risiken und Schäden

2.4 Analysen von Bedrohungen, Risiken und Schäden In der klassischen Sicherheitsdiskussion sind Begriffe wie Bedrohungsanalyse, Risikoanalyse, Schadenanalyse und Restrisiko zentrale Begriffe. Die sich dahinter verbergenden Ansätze sind sowohl für den Bereich der Ordnungsmäßigkeit als auch für die Sicherheit anwendbar - wenn auch in unterschiedlichem Maße.

Analysen,

Aufgabe der Bedrohungsanalyse ist es, alle realen Bedrohungen (Threats) der vorgegebenen Ziele zu erkennen, zu analysieren und zu dokumentieren. Man unterscheidet • prinzipielle Bedrohungen oder Primär-Bedrohungen, wie Verlust der Vertraulichkeit, Integrität, Verfügbarkeit und Verbindlichkeit, von • spezifischen Bedrohungen oder Sekundär-Bedrohungen wie z.B. Ausbreitung eines Virus oder Ausfall einer Hardware-Komponente.

Bedrohungsanalyse

Dual zu den Bedrohungen werden im positiven Sinne (Primär-, Sekundär-) Ziele festgelegt - wie etwa die Wahrung von Vertraulichkeit. Aus den prinzipiellen Bedrohungen ergibt sich leider nicht automatisch eine vollständige Aufzählung aller spezifischen Bedrohungen. Diese sind vielmehr für ein spezielles IV-System einzeln zu erfassen, um danach beurteilen zu können, welche Maßnahmen entgegenwirken (können). Dabei wird diese Bedrohungsanalyse stets unvollständig sein. Die Risikoanalyse (Risk Analysis) bewertet die Ergebnisse der Bedrohungsanalyse: Welche spezifischen Bedrohungen können zu Schäden führen? Wie hoch ist die Wahrscheinlichkeit für einen Schadenfall? Risiken sind immer zurückzuführen auf Schwachstellen des IV-Systems und können zu Schadenereignissen führen, wenn die betreffenden Schwachstellen des Systems ausgenutzt werden. In der Realität wird eine Wahrscheinlichkeit der genannten Art kaum rechnerisch ermittelbar sein. Man kann sich bestenfalls auf entsprechende Schätzwerte beschränken und muß somit von Häufigkeiten statt von Wahrscheinlichkeiten sprechen. Versucht man solche Schätzwerte für den Bereich der IT-Sicherheit zu ermitteln, muß beachtet werden, daß wegen der bekanntlich hohen Dunkelziffer Zahlen stets mit Vorsicht zu genießen und somit bestenfalls als Untergrenze für die Häufigkeiten anzusehen sind. Die Schadenanalyse geht vom Eintreten eines Schadens aus und versucht, die Höhe des materiellen oder immateriellen Schadens zu quantifizieren.

79

Restrisiko

Risikoanalyse

Schadenanalyse

2. Grundbegriffe

Risiken und Schäden können gemindert, ggf. praktisch sogar ausgeschlossen werden, wenn Maßnahmen greifen. Es verbleibt allerdings in aller Regel ein Restrisiko und ein daraus sich ableitender zu tolerierender Schaden. Die folgende Skizze sagt im wesentlichen aus, daß Bedrohungen, die auf Schwachstellen treffen, zu Risiken fuhren können, die im Falle des Eintretens Schäden produzieren werden.

Bedrohungen

Schwachstellen

Risiken

Schaden

Abbildung 2-3: Zusammenhang der Begriffe bei den verschiedenen Analysen Solange man sich im Kontext von Sicherheit auf Erfahrungswerte, Statistiken, Verträge und Garantien Dritter usw. stützen kann, können die erwähnten Analysen einen sinnvollen Beitrag zur Sicherheitskonzeption leisten. Für die IT-Sicherheit sind diese Betrachtungsweisen jedoch weniger anwendbar - hierauf soll aber später noch eingegangen werden.

2.5 Subjekte, Aktionen, Objekte

Akteure Personen

Zur Durchführung der erläuterten Analysen aber auch für die Evaluierung von IT-Systemen ist es sinnvoll, das Subjekt-Objekt Modell einzuführen. Dies soll zunächst für den Gesamtkontext der IV-Sicherheit geschehen; später beschränken wir uns auf die IT-Sicherheit. Akteure sind die aktiven Instanzen in einem IV-System, also Personen und Maschinen. Die umfassende IV-Sicherheit ist natürlich entscheidend von Personen und ihren Verhaltensweisen abhängig. Die Unterscheidung nach betriebszugehörigen und betriebsfremden Personen, nach vertrauenswürdigen und weniger vertrauenswürdigen Personen, im Extremfall nach Außentäter und Innentäter tragen maßgeblich zu einer umfassenden Bedrohungsanalyse bei. Im staatlichen Verschlußsachenbereich gibt es Ermächtigungen für Personen. Hierdurch werden global Zugriffsrechte auf Daten vergeben. Aber auch in vie-

80

2.5 Subjekte, Aktionen, Objekte

len anderen Bereichen gibt es unter den Stichworten Kompetenzen, Zuständigkeiten usw. ähnliche Vorgaben für Personen. Ein weitergehend sicherheitsrelevanter Aspekt ist die Frage, wie stark ein Unternehmen oder eine Behörde von den Kenntnissen und Erfahrung einzelner Mitarbeiter im Zusammenhang mit der IT abhängt. Hierdurch kann eine besondere Gefährdungslage gegeben sein, die konzeptionelle Änderungen erfordert. Ganz unabhängig davon ist die Unterscheidung nach Funktionen bzw. Rollen, die unterschiedlich sensitiv sein können. Hinsichtlich der Maschinen gilt, daß die IV-Sicherheit maßgeblich von der Verfügbarkeit, insbesondere der Zuverlässigkeit der Systeme und der Einfachheit ihrer Nutzung abhängt. Durch Vorschriften und Richtlinien werden die Tätigkeiten von Personen geregelt. Programme und Prozeduren bestimmen das Verhalten von Maschinen. Diese Vorgaben werden abstrakt als Anweisungen bezeichnet. Sie regeln also das gewünschte Verhalten von Akteuren. Eine in der Ausführung befindliche Anweisung wird als Prozeß bezeichnet. Wichtig ist: Prozesse in einem Rechner (laufende Programme) können sich gegenseitig beeinflussen: Prozeß A kann Prozeß B unterbrechen oder zu falschen Aktionen veranlassen. Prozesse sind deshalb schützenswerte Objekte. Eine Gruppe miteinander verzahnter Prozesse bildet ein IT-Verfahren, welches Dienstleistungen bereitstellt.

Maschinen

Anweisungen

Prozeß

IT-Verfahren

Akteure Anweisungen Prozesse Verfahren

Abbildung 2-4: Aufbau der Grundbegriffe Oft sind weniger die einzelnen Akteure als ihre Funktionen und Verantwortlichkeiten relevant. Man spricht in diesem Zusammenhang von Rollen. Eine Person schlüpft z.B. in die Rolle eines Anwenders, Personalsachbearbeiters, Programmierers, Supervisors, Auditors oder Revisors. Eine Maschine hat zu einem bestimmten Zeitpunkt bspw. die Rolle eines Netzknotens, eines Servers oder eines Arbeitsplatzrechners. Mit jeder Rolle wird eine bestimmte Gruppe von Aufgaben, Rechten und Pflichten verbunden sein. Eine Rolle kann z.B. durchaus mit mehreren realen Personen besetzt sein, die die zugestandenen Rechte entweder • einzeln und nacheinander (Beispiel: Vertretungsprinzip), • alle gleichzeitig (Beispiel: mehrere Sachbearbeiter im gleichen Gebiet),

81

Rollen

2. Grundbegriffe

• oder nur gemeinsam und gleichzeitig (Beispiel: Vier-Augen-Prinzip) ausüben können. Subjekte

Unter Subjekten verstehen wir Akteure, Rollen und die von ihnen initiierten Prozesse. Jeder Nutzer eines IT-System ist ein Subjekt in diesem Sinne. Aber auch der Revisor - gleich welche Person diese Rolle innehat - ist ein Subjekt. Ein von einem Subjekt gestarteter Prozeß ist ein weiteres Subjekt, das über andere Zugriffsrechte - geringere oder weitergehende - verfugen kann.

Objekte

Unter Objekten werden Daten, Prozesse, Verfahren, Maschinen verstanden. Objekte in einem IV-System sind dann schutzbedürftig, wenn sie für den Betreiber des IV-Systems einen Wert besitzen. Der Wert kann ein direkter materieller Wert (Geld) oder ein ideeller Wert (Ansehen, Vertrauen, Qualität) sein. Ideelle Werte können materielle Werte zur Folge haben: Das Ansehen einer Bank bei ihren Kunden wird zu Erhöhung oder Wahrung des Umsatzes fuhren. Einen Wert haben physische Objekte und logische Objekte - aber auch IT-Verfahren. die auf den zuvor genannten Objekten beruhen. Zu den physischen Objekten zählen z.B. Rechner, Datenübertragungsanschlüsse, periphere und Infrastruktur-Einrichtungen. Sie sind zunächst deshalb schützenswert, weil sie einen materiellen Wert besitzen; da sie weiterhin Bestandteil von Verfahren und fur die reibungslose Bereitstellung von Dienstleistungen unverzichtbar sind, ergibt sich ein zusätzlicher Wert. Der materielle Wert von Hardware-Einrichtungen ist gleichzusetzen mit Kosten für ihre Wiederbeschaffung; der zusätzliche Wert ergibt sich durch die Betrachtung möglicher Verluste durch Ausfallzeiten sowie deren Folgekosten. Physische Objekte können sogar - etwa im staatlichen Verschlußsachenbereich - unterschiedlich eingestuft sein. Eine solche Einstufung wird z.B. für die Leitungswege in einem LAN vergeben, wenn hierauf Informationen einer entsprechenden Geheimhaltungsstufe übertragen werden sollen. Damit können physische Objekte auch zu immateriellen Werten beitragen. Zu den logischen Objekten zählen Informationen. Daten (einschl. Programme) und Prozesse. Der Wert einer Information ist keine objektiv meßbare, absolute Größe, sondern hängt ab von dem Kontext der Information, von den Personen, die die Information verwerten oder verwerten möchten, dem Schaden bzw. Nutzen, den diese Information mit sich bringt, vielfach auch von der abstrakten Klassifizierung oder Einstufung, die einer Information zugeteilt wird. Der Wert von Informationen kann unmittelbar finanzieller Art oder rein ideeller Art oder eine Mischung von beidem sein. Selbst wenn Informationen keinen oder geringen Wert besitzen, kann es sein, daß ihre codierte Darstellung - also die Daten - einen großen Wert besitzt. Man

Physische Objekte

Logische Objekte

82

2.6 Unterschiedliche Modellvorstellungen von Sicherheit

denke an die Kundendatei eines Unternehmens: Informationen über die Kunden mögen einen bestimmten Wert haben; die Tatsache aber, daß alle Kundenangaben in einer Datei gespeichert sind, wird Ausgangspunkt für viele wichtige Abläufe sein: Serienbriefe, Werbeaktionen, Statistiken usw. Die gespeicherte Form der Informationen hat deshalb einen eigenständigen Wert. Schützenswert sind vielfach auch Prozesse, da sie während ihrer Laufzeit bzw. Existenz einen Wert darstellen - indem sie bspw. sichere Transaktionen durchzufuhren haben und hierbei ggf. durch andere Prozesse beeinflußt werden können. IT-Verfahren beruhen auf den schon genannten physischen und logischen Objekten. Es genügt deshalb in aller Regel, sich auf diese Objekte zu beschränken, wenn Bedrohungen und Maßnahmen für das IT-System diskutiert werden sollen. Die Dokumentation von IT-Verfahren beinhaltet Daten, die in aller Regel schutzwürdig sein werden; dabei werden Verfiigbarkeits- und Integritätsaspekte im Vordergrund stehen, seltener die Vertraulichkeit. Unter Aktionen werden Handlungen von Subjekten an Objekten verstanden. Beispiele: Ein Prozeß greift auf eine Datei zu, eine Person bearbeitet ein Feld einer Datenbank, ein Prozeß gibt Daten auf einem Peripherie-Gerät aus; die Vergabe von Rechten bzw. Berechtigungen durch den System-Verwalter; ein Wartungstechniker repariert einen Knotenrechner in einem LAN; ein Vermittlungsrechner schaltet einen externen Anrufer auf ein internes Gerät. Je nach Typ des Objektes sind verschiedene Aktionsarten denkbar. Bei Dateien unterscheidet man unter anderem zwischen den Aktionen bzw. Zugriffsarten Read, Write, Execute, Delete.

Subjekte: Akteure

IT-Verfahren

Aktion

Aktionsarten

Objekte: Aktionen

Rollen Prozesse

Maschinen Daten Prozesse Verfahren

Abbildung 2-5: Subjekt-Objekt-Beziehungen Das zuvor beschriebene Subjekt-Objekt-Modell eines IV-Systems ist sehr abstrakt. Es betrachtet alle Parameter auch jenseits der Technik und ist damit für eine umfassende Analyse eines IV-Systems geeignet.

83

Subjekt-ObjektMode "

2. Grundbegriffe

2.6 Unterschiedliche Modellvorstellungen von Sicherheit Beschränken wir uns nunmehr auf den engeren technischen Kontext eines ITSystems: Akteure sind die mit dem IT-System direkt arbeitenden Personen (User) und die Maschinen, Rollen sind die im IT-System bekannten Rollen (System-Verwalter, Auditor usw.), Prozesse nur solche, die in den Maschinen ablaufen, Daten nur die im IT-System gespeicherten oder von dort zugänglichen Daten (einschließlich der Programme). Ein IT-System stellt so gesehen die Zusammenfassung von Objekten, Subjekten und möglichen Aktionen dar. Nach der Festlegung des Systembegriffs stellt sich nunmehr die Frage, wie der Begriff der IT-Sicherheit definiert werden kann: 1. Definition durch Ausschluß: Ein IT-System wird als sicher bezeichnet, wenn keine der genannten Primär-Bedrohungen zu Schäden fuhre'n kann. Bewertung: Diese Definition hat natürlich nur theoretischen Charakter. 2. Restrisiko-Definition\ Ein IT-System wird als sicher bezeichnet, wenn die Risiken stets unterhalb eines tolerierbaren Restrisikos bleiben. Bewertung: Diese Definition ist schon eher praktikabel, hat aber den Nachteil, quantitative Bezugsgrößen zu verwenden, die in der Realität ganz selten bestimmbar sind. 3. Induktive Definition: Ein System muß nach Abschluß der Installation oder zu einem anderen definierten Zeitpunkt als sicher angenommen werden. Das ITSystem ist danach solange als sicher anzusehen, wie kein Subjekt Aktionen ausfuhren kann, die die Sicherheitsziele beeinträchtigen. Bewertung: Diese Definition ist Ausgangspunkt für einen System-Begriff in der Informatik (Zustandsautomat). Sie geht davon aus, daß unter den betrachteten Aktionen alle möglichen Manipulationen erfaßbar sind. Die Praxis zeigt, daß dies nicht der Fall ist (vgl. die Problematik der verdeckten Kanäle). Problematisch sind erst recht solche Manipulationen, die gar nicht betrachtet werden konnten, da sie nicht bekannt waren. 4. Sicherheit als Vertrauenswürdigkeif. Ein System ist dann sicher, wenn die festgelegten Anforderungen gemäß der Strategie der Vertrauenswürdigkeit in die Praxis umgesetzt wurden. Zu den Anforderungen zählen insbesondere die erforderlichen Sicherheitsfunktionen sowie ein Maß für die Garantie, daß diese Funktionen in der Praxis korrekt und wirksam ablaufen. Das Erbringen einer solchen Garantie (Vertrauenswürdigkeit) ist Gegenstand von Evaluierungen nach Sicherheitskriterien. Bewertung: Es dürfte in der Praxis schwierig sein, alle Komponenten eines ITSystems anhand von Sicherheitskriterien so zu analysieren, daß eine vergleichbare Stufe der Vertrauenswürdigkeit erreicht wird. Dennoch ist diese Defini-

84

2.6 Unterschiedliche Modellvorstellungen von Sicherheit

tion unter den mehrfach erläuterten Randbedingungen (keine quantitativen Analysen möglich, Komplexitätsproblem, fehlendes Know-How für Sicherheitsanalysen) nach Meinung des Autors die einzig sinnvolle. Der Begriff der Vertrauenswürdigkeit (Trustworthiness) wird uns in den folgenden Kapiteln noch eingehender beschäftigen.

85

3. Sicherheitsfunktionen 3.1 Grundsätzliches Unter einer Sicherheitsfunktion1 eines IT-Systems oder IT-Produktes versteht man eine Funktion, die gegen mindestens eine (Primär-, Sekundär-) Bedrohung gerichtet ist, diese Bedrohung (ggf. im Verbund mit anderen Sicherheitsfunktionen) unwirksam macht oder zumindest die Auswirkungen im Schadenfall begrenzen kann. Die Diskussion wird sehr vereinfacht, wenn man sich auf einen Satz typischer, quasi standardisierter Sicherheitsfunktionen einigt. Diese sollten in ihrer Anzahl überschaubar bleiben, möglichst überschneidungsfrei sein, so allgemein definiert sein, daß möglichst viele Ausprägungen von real vorhandenen Sicherheitsfunktionen erfaßt werden können, und so nahe an der Praxis sein, daß die Beschreibung eines IT-Systems durch sie für den Anwender noch verwertbare Aussagen bringt. Beispiele für solche Sicherheitsfunktionen sind die Authentisierung und die Zugriffskontrolle, die unter anderen im folgenden Abschnitt näher diskutiert werden. Jede Sicherheitsfunktion kann durch unterschiedliche technische Verfahren und mathematische Algorithmen - sogenannte Sicherheitsmechanismen (Security Mechanisms) - realisiert werden. Beispiel: Die Authentisierung verlangt einen Beweis, daß der Benutzer derjenige ist, für den er sich ausgibt. Wie wird ein solcher Beweis erbracht? Eine Möglichkeit ist, den Benutzer - nachdem er seinen "Namen" (User-ID) angegeben hat - nach einem geheimen Code zu fragen, durch dessen Kenntnis er sich ausweist. Ein solcher Code ist das Paßwort. Ist nun das User-ID/PaßwortSchema eine Sicherheitsfunktion oder ein Sicherheitsmechanismus? Hinsichtlich des Abstraktionsniveaus gilt: Eine Sicherheitsfunktion gibt an, was geleistet wird; ein Sicherheitsmechanismus beschreibt, wie es geleistet werden soll2. Die Sicherheitsfunktion Identifizierung und Authentisierung ist so zu definieren, daß Benutzer namentlich erfaßt und ihre Identität nachgewiesen werden soll. Es handelt sich also um eine Beschreibung vom "was"-Typ. Die Angabe, daß hierzu User-ID und Paßwort verwendet werden sollen, gibt das

1

2

In den verschiedenen Sicherheitskriterien werden Sicherheitsfunktionen (Security Functions) auch Grundfunktionen oder Generische Oberbegriffe (Generic Headings) genannt. Eine solche Definition ist natürlich nicht eindeutig; jede Beschreibungsebene kann letztlich als das "wie" der nächst höheren "was"-Ebene aufgefaßt werden.

87

Sicherheitsfunktion

SicherheitsMechanismen

3. Sicherheitsfunktionen

Stärke

Kompensation

Zusammenwirken

Implementierung

"wie" an - beschreibt also einen Sicherheitsmechanismus, wozu allerdings noch einige Daten (z.B. Paßwortlänge, Zeichenvorrat) erforderlich sind. Die Mechanismen zur Realisierung einer Sicherheitsfiinktion können unterschiedlich wirksam sein, wenn es darum geht, Manipulationsversuchen oder technischem Versagen entgegenzuwirken: Man spricht von der Stärke (Strength) eines Sicherheitsmechanismus. Für die Stärke müssen nun Bewertungsstufen festgelegt werden. Ausgehend von der "gesicherten" Erkenntnis, daß kein Mechanismus absolut sicher ist, geht es darum festzustellen, welche Kenntnisse, welcher zeitliche und finanzielle Aufwand, welche Hilfsmittel und welche personelle Mitwirkung Dritter nötig sind, um einen Mechanismus zu "brechen". Je höhere Ressourcen dieser Art erforderlich sind, desto stärker ist der Mechanismus. In der Praxis können Schwächen einzelner Mechanismen durch andere Mechanismen oder durch organisatorische Maßnahmen im Umfeld eines IT-Systems kompensiert werden. Insbesondere können sich in der Gesamtbeurteilung der Mechanismenstärke Unterschiede zwischen IT-System und IV-System ergeben. Generell gilt: Beim Zusammenwirken unterschiedlich starker Mechanismen kann weder die geringste noch die höchste vorkommende Einzelstärke maßgebend sein. Denkbar ist einerseits, daß Schwächen eines Mechanismus durch einen anderen Mechanismus kompensiert werden können, andererseits kann ein Mechanismus auch genutzt werden, um einen anderen zu manipulieren. In den später zu behandelnden Sicherheitskriterien werden (unterschiedliche) Definitionen von Bewertungsstufen für die Stärke von Sicherheitsmechanismen gegeben. Im folgenden wollen wir uns zunächst damit begnügen, qualitative Aussagen zu machen. Es bleibt noch zu erwähnen, daß auch die Implementierung (Umsetzung in Hard- oder Software) von Mechanismen fehlerhaft sein kann. Aspekte dieser Art fallen aber nicht unter die Bewertung der Stärke von Mechanismen, sondern betreffen Korrektheitsaspekte (s. Kapitel 5 und 6). Die Abbildung 3-1 veranschaulicht die Struktur eines IT-Systems aus Sicht der IT-Sicherheit: Die Resistenz gegenüber Manipulationen und anderen betrachteten Bedrohungen ist durch die "Dicke" der Schutzschicht angedeutet; die Nahtstellen zwischen den Funktionsblöcken stellen die Notwendigkeit des Zusammenwirkens der Sicherheitsfunktionen (SF) und Mechanismen heraus. Lediglich SF1 und SF4 arbeiten zufriedenstellend zusammen. Die Pfeile sollen Manipulationsversuche darstellen, deren Erfolg durch die Tiefe des Eindringens in den inneren Kern charakterisiert wird.

88

3.1 Grundsätzliches

Abbildung 3-1: Modell eines IT-Systems 3.1.1 Identifizierung und Authentisierung Identifizierung:

Bestimmung der Identität eines Subjekts

Das Wort "Bestimmung" bedeutet, daß das betreffende Subjekt seine Identität selbst angibt oder diese durch ein technisch-administratives Verfahren ermittelt wird. Eine Prüfung, ob die angegebene Identität "echt" ist, fällt aber nicht unter die Sicherheitsfunktion Identifizierung (Identification). Eine schwache Sicherheitswirkung durch die Identifizierung besteht darin, daß nur registrierte Subjekte zum Zuge kommen. Da aber in den allermeisten Fällen lediglich der Name abgefragt wird, dürfte man als Hacker mit Namen großer Häufigkeit leichtes Spiel haben - wenn sich nicht eine Authentisierung anschließen würde. Es ist festzulegen, welche Subjekte identifiziert werden müssen, wodurch die Identifizierung erfolgt (z.B. Eintippen einer ID, Spracheingabe des Namens), ob Eindeutigkeit erzwungen wird, wie hoch gegebenenfalls die Wahrscheinlichkeit einer falschen Identifizierung durch Namensgleichheit ist. Ein typisches Beispiel für einen Mechanismus zur Identifizierung ist die Abfrage der User-ID am Terminal eines Rechners.

Definition

Da es sich um eine rein deklarative Funktion ohne Beweiswert handelt, ist zunächst keine besondere Bedrohung gegeben, gegen die diese Funktion wirkt. Ein Abweisen nicht registrierter Subjekte kann durch diese Funktion nur bedingt erreicht werden.

Bedrohungen

89

Spezifikation

Mechanismen

3. Sicherheitsfunktionen

Verwaltung

Kann aber z.B. in einem Betriebssystem eine User-ID für mehrere Personen stehen und erfolgt keine Authentisierung, ist keine eindeutige Zuordnung von Aktionen zu Subjekten möglich; dies würde die Revisionsfähigkeit stark einschränken. Für die Sicherheitsfunktion der Identifizierung müssen einige Verwaltungsmöglichkeiten gegeben sein: das Hinzufügen neuer Identitäten und das Ändern oder Löschen von vorhandenen Identitäten. Authentisierung:

Definition

Spezifikation

Mechanismen

Besitztum

Wissen

Nachweis einer Identität

Die Sicherheitsfunktion Authentisierung (Authentication) hängt stark mit der zuvor definierten zusammen: Hier wird - im Rahmen der Möglichkeiten - der Nachweis erbracht, daß das Subjekt genau dasjenige ist, für das es sich bei der Identifizierung ausgegeben hat. Eine Authentisierung kann nur dann unterbleiben, wenn eine fehlerhafte Identifizierung ausgeschlossen werden kann. Dies ist z.B. denkbar, wenn die eigentliche Authentisierung bereits im Umfeld eines IT-Systems durchgeführt wurde (etwa Ausweiskontrolle) und die vertrauenswürdige Person lediglich ihren Namen angibt, um ihre Arbeitsumgebung im IT-System zugewiesen zu bekommen. Es ist durchaus denkbar, daß Identifizierung und Authentisierung gleichzeitig erfolgen: Die Kenntnis eines bestimmten Geheimnisses (Paßwort, PIN, Schlüssel) kann an ein bestimmtes Subjekt gebunden sein; es würde sich also durch Angabe dieses Codes gleichzeitig identifizieren und authentisieren. Es ist im Einzelfall festzulegen, welche Subjekte authentisiert werden müssen, unter welchen Umständen eine Authentisierung erfolgen muß, wann eine Authentisierung als erfolgreich anzusehen ist, welche Aktionen bei nicht erfolgreicher Authentisierung ergriffen werden müssen. Hierzu gehören auch die Verfahren, die die Anzahl möglicher Authentisierungsversuche begrenzen. Es sind Anforderungen an die Integrität und Verfügbarkeit der Authentisierungsdaten zu stellen; ihre Änderung oder Blockierung durch Unbefugte oder technischen Defekt muß verhindert werden. Vor der Bewertung der möglichen Mechanismen muß nach der Art der Authentisierung unterschieden werden: Authentisierung durch Besitz eines Gegenstandes (z.B. eines Schlüssels, einer Key Card, eines Tokens), durch Wissen bestimmter Informationen (z.B. Paßwort, PIN, Schlüssel), durch Erkennen von Merkmalen (z.B. biometrische Merkmale wie Retina- und Stimmenmuster, Fingerabdruck). Bei der Authentisierung durch Besitztum sind die Möglichkeit zum Entwenden und der Aufwand zum Fälschen des benutzten Gegenstandes zu untersuchen. Im Fall der Authentisierung durch Wissen muß der Aufwand zur Erlangung des Wissens diskutiert werden.

90

3.1 Grundsätzliches

Bei der Authentisierung durch Merkmale stellt sich generell die Frage nach dem Aufwand zum Fälschen der Merkmale. Ohne die Funktion der Authentisierung könnte eine unbefugte Nutzung von ITSystemen nicht ausgeschlossen werden. Die Funktion selbst ist durch eine Reihe von denkbaren Attacken bedroht: Der Vorgang der Identifizierung und Authentisierung kann durch Dritte beobachtet werden, und zwar physisch durch Zuschauen oder Abhören ("Mitlesen" des Paßworts) oder durch programmtechnisches Abfangen durch Spoofing-Programme. Unter Umständen ist also die Kommunikation zwischen Subjekt und IT-System nicht vertrauenswürdig. Darüber hinaus können die Authentisierungsdaten (z.B. Paßwort-Listen) unzureichend gegen Zugriffe durch Unberechtigte geschützt sein. Generell ist zu fragen: Existieren Möglichkeiten zur Täuschung des Authentisierungsmechanismus? Können Unbefugte auf Authentisierungsdaten zugreifen oder sie blockieren? Für die Sicherheitsfunktion der Authentisierung müssen einige Verwaltungsmöglichkeiten gegeben sein: die Erzeugung und Vergabe von Authentisierungsmitteln (Paßwörter, PINs, Tokens), das Ändern und ggf. Sperren solcher Mittel; ggf. auch das Erfragen von Authentisierungsdaten beim IT-System. 3.1.2 Zugriffskontrolle Die Sicherheitsfunktion Zugriffskontrolle (Access Control) umfaßt einerseits die Kontrolle des Informationsflusses zwischen Subjekten (Benutzer, Prozesse) und andererseits die Kontrolle der Betriebsmittelnutzung durch Subjekte. Beim zweiten Punkt geht es aus Sicht der IT-Sicherheit um die Begrenzung der Betriebsmittel. Die folgende Definition erfaßt beide Zielrichtungen: Zugriffskontrolle:

Merkmale Bedrohungen

Spoofing

Verwaltung

Informationsfluß

Betriebsmittel

Überprüfung, ob ein bestimmtes Subjekt berechtigt ist, eine bestimmte Aktion mit einem Objekt durchzufuhren

Durch die Zugriffskontrolle soll die unbefugte Ausübung von Aktionen verhindert werden. Neben den klassischen Lese- und Schreibzugriffen geht es auch um die Erzeugung oder Löschung von Objekten und die Weitergabe von Zugriffsrechten, die Anforderung von Betriebsmitteln (Speicherplatz, Prozessor-Zeiten). In bestimmten Situationen (z.B. bei Multi-User-Datenbanken) kann es erforderlich sein, den gleichzeitigen (schreibenden) Zugriff mehrerer Benutzer auf das gleiche Objekt zu verhindern, um die Konsistenz der Daten nicht zu gefährden. Solche temporären Einschränkungen von Rechten und ihre Überprüfung werden ebenfalls unter die Zugriffskontrolle eingeordnet. Es sind folgende Fragen zu diskutieren: Bei welchen Aktionen und zu welchem Zeitpunkt erfolgt eine Zugriffskontrolle? Erfaßt die Zugriffskontrolle alle ge-

91

Definition

Spezifikation

3. Sicherheitsfunktionen

Verwaltung

Mechanismen

Reihenfolge

wünschten Objekte und Aktionen? Welche Maßnahmen werden vom System bei dem Versuch ergriffen, eine Aktion ohne das zugehörige Recht auszufuhren? Gibt es Ausnahmen bei der Zugriffskontrolle? Wie steht es mit der Verfügbarkeit und Integrität der Entscheidungsdaten? Betriebssysteme wickeln den Dateizugriff eines Prozesses meist wie folgt ab: Der Prozeß fordert das Öffnen einer Datei an und gibt dabei vielfach an, daß er sie später zu lesen oder/und zu beschreiben gedenkt. Erfaßt die Zugriffskontrolle nur das Öffnen einer Datei, aber nicht mehr die eigentlichen Lese- oder Schreibzugriffe? Wird bereits beim Öffnen die Zugriffskontrolle ausgeführt oder erst beim tatsächlichen Lese- oder Schreibzugriff? Was passiert, wenn während der Bearbeitung das Zugriffsrecht durch den System-Verwalter entzogen wird? Wird dies sofort wirksam - könnte inkonsistente Dateien nach sich ziehen - oder erst beim nächsten Versuch des Öffnens? Bei der Verwaltung sind das Erzeugen, Ändern und Löschen von Rechtebeziehungen zu betrachten. Dies schließt einfache Subjekt-Objekt-Beziehungen ebenso ein wie regelbasierte Vorgaben, z.B. die Vergabe von Einstufungen. Wichtige Fragen sind: Welche Subjekte, Objekte und Aktionen unterliegen der Verwaltung? Sind alle Beziehungen vollständig erfaßt? Welche Arten von Rechten existieren? Gibt es Default-Rechte 3 ? Welche Regeln sind bei der Verwaltung der Rechtebeziehungen einzuhalten? Wer darf wann Rechte vergeben, ändern oder löschen? Welche Subjekte benötigen und besitzen besonders hohe Privilegien? Gibt es eine automatische Vererbung von Rechten? Die Zugriffskontrolle ist in der Regel ein Teil eines Betriebssystems, läuft in geschützten Speicherbereichen als privilegierter Prozeß ab und ist so dem Zugriff der Nutzer entzogen. Es benutzt dabei Tabellen oder wendet übergeordnete Zugriffsregeln an. Erläuterungen zu diesen Mechanismen sind im Kapitel 1 enthalten; entsprechende Mechanismen werden im Abschnitt 3.2 näher beschrieben. Es ist denkbar, daß sich widersprechende Rechtebeziehungen eingerichtet werden. Nach welchen Regeln geht die Zugriffskontrolle in einem solchen Fall vor? Oft hängt die Entscheidung von der Reihenfolge des Auswertens der Entscheidungsdaten ab! Wird z.B. mit impliziten (voreingestellten) und expliziten Rechten (z.B. aus einer Rechtetabelle) gearbeitet, so kann das Ergebnis einer Zugriffsprüfung davon abhängen, in welcher Reihenfolge diese Rechte geprüft werden: Es sei z.B. dem Benutzer A per Ersatzwert Lesen und Schreiben bei einem Objekt erlaubt, während die Tabelle für das Objekt den Zugriff auf Lesen einschränkt. Sinnvollerweise muß hier die Prüfungsreihenfolge "zuerst Tabelle, dann Ersatzwert" gewählt werden.

3

Bei U n i x wird z.B. durch eine benutzerspezifische Maske gesteuert, w e l c h e Rechte der Eigentümer und andere Subjekte an neuen Dateiobjekten erhalten.

92

3.1 Grundsätzliches

Hat ein Benutzer Rechte, die an seine User-ID gebunden sind, darüber hinaus aber noch Rechte aus seinen Gruppenzugehörigkeiten, so wird es kompliziert: Welche Rechteprofile haben eine höhere Priorität (und werden demzufolge zuerst ausgewertet)? Oder werden etwa alle User- und Gruppenprofile einfach additiv zusammengeführt (Summe aller Einzelrechte)? Bei IT-Systemen mit vielen Subjekten und Objekten kann vor allem die Überschaubarkeit der Rechtebeziehungen eine große Bedrohung sein. Kann der System-Verwalter leicht fiir jedes Subjekt und jedes Objekt eine Aufstellung der Zugriffsrechte abrufen? Durch Unkenntnis oder Fahrlässigkeit könnte Rechtebeziehungen so eingerichtet oder geändert werden, daß autorisierte Subjekte ihnen zugestandene Rechte nicht mehr ausüben können. In manchen Systemen kann der System-Verwalter seine eigene User-ID löschen und sich so den Zugriff zum System (zumindest zeitweilig) versperren. Ein besonderes Problem sind verdeckte Rechteänderungen. Sie entstehen meist in folgender Situationen: Ein Subjekt erhält dadurch Rechte, daß er hinsichtlich seiner Zugriffsmöglichkeiten einem anderen Subjekt gleichgesetzt wird (Security Equivalences). Werden für diesen nun Rechte geändert, so ist das zweite Subjekt automatisch betroffen. Dies kann erwünscht sein, kann aber auch ungewollt sein. Ein Blockade-Problem besonderer Art stellen nicht mehr änderbare Rechtebeziehungen dar. Ein bekanntes Netzwerk-Betriebssystem (ältere Version) erlaubte die Vergabe von Execute-Only-Attributen an Programmdateien. Da diese Datei danach nur ausgeführt werden durfte, war auch das Ändern der Zugriffsattribute ausgeschlossen. Insbesondere konnte einer solchen Datei das Execute-Only-Attribut nicht mehr entzogen, die Datei also nicht mehr gelöscht werden! Gehört eine solche Datei zu einer Standardsoftware, kann es sogar Probleme mit dem Einspielen neuer Versionen solcher Software-Pakete geben, da die alte Version nicht überschrieben werden kann. Eine besondere Bedrohung stellt die Ableitung von Informationen durch Zusammenfügen von legitim zugänglichen Daten dar. Wer Zugriff zu vielen Daten eines IT-Systems hat, kann daraus interessante Schlüsse über bestimmte Sachverhalte ziehen. Im Rahmen der Sicherung staatlicher Verschlußsachen stellt sich die Frage, ob viele Informationen z.B. der Stufe vertraulich in der Summe vielleicht sogar geheim einzustufen sind. Inwieweit solche Aggregationen durch eine Zugriffskontrolle überwacht oder verhindert werden können, sei dahingestellt. Spezielle Arten der Zugriffskontrolle (diskret, regelbasiert) und ihre Zielrichtungen werden im nächsten Abschnitt 3.2 behandelt.

93

Aggregation

3. Sicherheitsfunktionen

3.1.3 Beweissicherung und Protokollauswertung Beweissicherung:

Definition

Spezifikation

Mechanismen

Verdeckter

Kanal

Protokollierung der Ausübung bzw. der versuchten Ausübung von Rechten

Banal: Ziel der Beweissicherung ist es, Beweise zu sichern. Es stellt sich aber die Frage, zu welchem Zweck die Aufzeichnungen dienen sollen: Ressourcenabrechnung im Rahmen von Projekten meist in Zusammenhang mit einer Betriebsmittelbegrenzung, Revision von Abläufen, nachträgliches Entdecken von Sicherheitsverstößen. In jedem Fall sind Informationen aufzuzeichnen, um später Benutzern Aktionen zuordnen und sie für ihre Handlungen verantwortlich machen zu können. Der englische Fachbegriff ist Accounting. Wichtige Einzelfragen sind: Welche Aktionen werden protokolliert? Welche Informationen werden dabei aufgezeichnet? Sind diese vollständig und beweiskräftig? Wo werden die Aufzeichnungen gespeichert? Welche Regeln gelten für den Zugriff auf die gespeicherten Aufzeichnungen? Nach welchen Kriterien werden diese Informationen ausgewertet? Der Schutz der aufgezeichneten Daten vor unbefugter Änderung und möglicher Blockade sind wichtige Punkte der Diskussion. Werden auch die Aktionen besonders privilegierter Subjekte (z.B. System-Verwalter) aufgezeichnet? Die Aufzeichnung wird in Betriebssystemen dadurch erreicht, daß die Aktionen des An- und Abmeldens von Subjekten und alle Aufrufe für den Zugriff auf Objekte "gefiltert" werden und je nach Einstellung zu Einträgen in der Aufzeichnungsdatei führen. In Netzwerken gibt es die beiden Varianten, lokale Ereignisse lokal oder auf einem speziellen Server aufzuzeichnen. Grundsätzlich kann in einer benutzerspezifischen Datei oder in einer einzigen System-Datei protokolliert werden. Das Accounting muß zumindest im zweiten Fall transaktionsorientiert durchgeführt werden. Wichtig ist noch folgende Präzisierung: Möchte ein Benutzer eine Datei lesen, für die er gar kein Zugriffsrecht besitzt, deren Name er aber kennt, so stellt sich die Frage, ob das Betriebssystem ihm diese Datei überhaupt im Directory anzeigt; wenn ja, dann kann der Leseversuch als unerlaubt protokolliert werden; wenn nein, dann wird ein "gutes" System dem Benutzer mitteilen, daß die gewünschte Datei gar nicht vorhanden ist - ob dann der Lese-Versuch protokolliert werden muß, sei dahingestellt. Ein weniger gutes System wird dem Benutzer eine Meldung des Typs "Kein Zugriffsrecht..." übergeben, woran der Benutzer aber erkennen kann, daß es eine Datei dieses Namens offensichtlich gibt. Damit haben wir die Situation, daß ein verdeckter Kanal (Covert Channet) geschaffen ist: Die Bestätigung der Existenz oder Nicht-Existenz der Datei ist ein Bit Information; zwei Benutzer könnten diesen schwachen Mechanismus ausnutzen, um eine verdeckte Datenübertragung zu arrangieren...

94

3.1 Grundsätzliches

Da für die Aufzeichnung Speicherplatz benötigt wird, stellt sich sofort die Frage, was passiert, wenn der Speicherplatz erschöpft ist? Dieser vor allem auf kleinen Systemen relevante Fall ist nicht einfach zu handhaben: Die sicherste, aber meist nicht praktikable Lösung besteht darin, keine weitere Aktionen zuzulassen, das System zu stoppen und diesen Zustand nur durch den SystemVerwalter beseitigen zu lassen. Die weniger "brutale" Lösung ist, einige Zeit vor dem Speicherüberlauf Warnmeldungen zu geben, die wiederum den System-Verwalter auf den Plan rufen müssen. Aus Sicht der Sicherheit bedenklich ist es natürlich, wenn das System weiterläuft (und dies dann meistens sogar schneller) und die Protokollierung eingestellt wird. Damit werden natürlich keine Beweise mehr gesichert; dies könnte sogar manipulativ ausgenutzt werden, indem man vor der beabsichtigten unzulässigen Aktion erst einmal das Accounting zum Überlauf bringt... Werden Aktionen des System-Verwalters nicht (sicher) aufgezeichnet, besteht die Gefahr, daß Unbefugte sich das Supervisor-Paßwort beschaffen (gezielt oder durch Erraten) und die Spuren ihrer Aktionen anschließend verwischen. Eine ganz andere Gefahr besteht darin, daß aufgezeichnete Informationen eine Leistungskontrolle der Mitarbeiter ermöglichen, was aus rechtlicher Sicht bedenklich ist... Protokollauswertung:

Bedrohungen

Privilegierte Sub ekte

j

Entdeckung und Untersuchung sicherheitsrelevanter Ereignisse, insbesondere der versuchten Ausübung nicht zugestandener Rechte

Die bei der Beweissicherung aufgezeichneten Daten müssen dahingehend ausgewertet werden, ob tatsächlich Sicherheitsverstöße vorgekommen sind, wer sie ausgelöst hat und welche Objekte oder sonstigen Betriebsmittel davon betroffen waren. Der englische Fachbegriff ist Audit. Die Protokollauswertung "erfährt" Sicherheitsverstöße erst dann, wenn sie bereits passiert sind. Eine sinnvolle Methode besteht aber darin, bei sehr kritischen Sicherheitsverstößen einen Alarm an einen Sicherheitsbeauftragten zu leiten, der sofort aktiv werden kann, um das Sicherheitsproblem zu lösen. Die Protokollauswertung kann auch für eine präventive Trendanalyse genutzt werden. Im Kapitel 1 ist hier das Stichwort Intrusion Detection näher erläutert worden. Es ist festzulegen, welche Ereignisse als sicherheitsrelevant einzustufen sind, wie diese aus den Aufzeichnungen erkannt werden können und welche Maßnahmen sich hieran anschließen sollen. Im Zusammenspiel zwischen Accounting und Audit ist die Frage zu lösen, nach welcher Zeit Aufzeichnungen gelöscht werden können, wohin sie ggf. sicher ausgelagert werden können, wer überhaupt Auswertungen durchfuhren darf. Bei komplexen Systemen mit hohem Datenaufkommen wird nichts anderes übrig bleiben, als eine eigene Datenbank mit der Protokollauswertung zu be-

95

Definition

Spezifikation

Mechanismen

3. Sicherheitsfunktionen

schäftigen. Eine Person mit manuellem Suchen in der Aufzeichnungsdatei zu beauftragen, wird nur in den seltensten Fällen sinnvoll sein, da dies bekanntlich meist unterlassen wird oder "raffinierte" Sicherheitsverletzungen nicht erkannt werden. 3.1.4 Wiederaufbereitung Wiederaufbereitung:

Definition

Spezifikation

Verwaltung

Mechanismen

Aufbereitung wiederverwendbarer dem nächsten Gebrauch

Speicher

vor

Wiederverwendbare Speicher sind z.B. der Speicherplatz im Hauptspeicher, auf peripheren Massenspeichern, auf transportablen Datenträgern wie Disketten, sowie Bildschirminhalte und Register-Inhalte. Wiederaufbereitung (Object Reuse) bedeutet in aller Regel das Löschen der nicht mehr benötigten Daten. Damit soll natürlich verhindert werden, daß der Nutzer solcher Betriebsmittel Kenntnisse von Informationen seiner "Vorgänger" erhält. Etwas abstrakter: Durch diese Sicherheitsfunktion soll ein unerlaubter Informationsfluß zwischen zwei Subjekten über (speichernde) Medien verhindert werden. Zu stellen sind folgende Fragen: Welche Betriebsmittel müssen wiederaufbereitet werden? Nach bzw. vor welchen Aktionen muß eine Wiederaufbereitung erfolgen? Durch welches technische Verfahren soll die Wiederaufbereitung erfolgen? Es sind auch Verfahren zum Initialisieren oder zum Löschen nicht mehr zu verwendender Datenträger zu betrachten. Statt Löschen kommt unter Umständen nur ein physisches Vernichten oder eine gesicherte Dauer-Lagerung in Frage. Bei der System-Generierung oder auch im laufenden Betrieb können SystemVerwalter bei vielen Betriebssystemen einstellen, ob und ggf. wie Speicherplatz wiederaufbereitet werden soll. Auch wenn ein Überschreiben Zeit und Performance kostet: Ist Vertraulichkeit gefordert, muß diese Option eingeschaltet werden. Auch im privaten Bereich bei der PC-Nutzung sollte sich jeder klar machen, daß bei der Weitergabe von Disketten der Empfänger ganz leicht an nur scheinbar gelöschte private Daten herankommt: Deshalb Disketten zunächst formatieren, dann Daten speichern, anschließend die Diskette weitergeben! Im Kapitel 1 sind mögliche Verfahren der Wiederaufbereitung am Beispiel diskutiert worden; zumeist wird das Überschreiben mit konstanten oder zufallig verteilten Datenmustern gewählt. In sensiblen Bereichen wird das Überschreiben mehrfach durchgeführt, um ein physikalisches Restaurieren auszuschließen bzw. erheblich zu erschweren. Nicht überall vorhanden, aber sehr sinnvoll sind spezielle Löschgeräte ("Bulk Eraser") für Datenträger wie Disketten und Bänder.

96

3.1 Grundsätzliches

Die Bedrohungen liegen auf der Hand: Das unzureichende oder gar nicht vorhandene Wiederaufbereiten von Speicherbereichen erlaubt einen Informationsfluß, der dem Sicherheitsziel der Vertraulichkeit zuwiderläuft.

Bedrohungen

3.1.5 Unverfälschtheit Unverfälschtheit:

Gewährleistung der Korrektheit und Konsistenz von Daten und Relationen

Es soll sichergestellt sein, daß Objekte und Beziehungen zwischen Objekten korrekt sind und daß Objekte zwischen einzelnen Prozessen ohne Änderungen (auch von Sender-/Empfänger-Angaben) übertragen werden. Die Funktion Unverfälschtheit (ITSEC: accuracy) ist unter anderem für Datenbanken und die Interprozeßkommunikation relevant. Es müssen Funktionen zur Einrichtung, Veränderung und Überprüfung von Relationen vorhanden sein. Es muß möglich sein, bei der Übertragung von Daten zwischen einzelnen Subjekten und Objekten Verluste, Ergänzungen oder Veränderungen zu entdecken. Zu untersuchen ist, wie Relationen geschützt werden, ob die verwendeten Mechanismen eine Integritätsverletzung sicher ausschließen oder nur nachträglich registrieren. Ein praktisches Beispiel ist die Verwendung von Viren-Scannern, um in einem regelmäßig ablaufenden Scan-Vorgang Infektionen z.B. von ausfuhrbaren Programm-Objekten in einem Betriebssystem entdecken zu können. Damit wird wenn auch zu einem späten Zeitpunkt - der Verlust der Integrität erkannt; dennoch ist dies kein sehr hoch einzustufender Mechanismus der Funktion Unverfälschtheit. Die Verwendung von Signaturen (kryptografische Prüfsummen, elektronische Unterschriften) ist dagegen höher einzustufen. So kann z.B. bei ProgrammObjekten vor jeder Ausführung die Signatur durch das Betriebssystem nachgerechnet und mit dem registrierten Wert verglichen werden. Änderungen würden (mit einer hohen Wahrscheinlichkeit) erkannt werden. Es bleibt noch die Gefahr, daß z.B. durch Tarnkappen-Viren diese Überprüfungsfunktion kompromittiert wird, was zu der Forderung fuhrt, daß das Betriebssystem selbst einen hohen Integritätsschutz benötigt. Die Unverfälschtheit ist dadurch bedroht, daß entweder Unbefugte (und ihre Prozesse) unzulässige Änderungen vornehmen, Änderungen durch technische Defekte verursacht werden oder autorisierte Subjekte unbeabsichtigt (Bedienungsfehler, Fahrlässigkeit) unzulässige Änderungen durchfuhren.

97

Definition

Verwaltung

Mechanismen

Viren-Scanner

Signaturen

Bedrohungen

3. Sicherheitsfunktionen

3.1.6 Verfügbarkeit, Verläßlichkeit, Zuverlässigkeit Die Überschrift deutet schon an, daß einige Begriffe mit verwandter Definition zu betrachten sind. Gehen wir aber zunächst aus von dem grundsätzlichen Ziel der Ordnungsmässigkeit: Gewünscht ist letztlich eine Garantie, daß ein definiertes Verfahren inhaltlich und zeitlich so ablaufen wird, wie es geplant ist. Wodurch kann dies beeinträchtigt werden? Abgesehen von Planungs-, Organisations- und Infrastrukturmängeln (IV-System!) sind für das IT-System zu nennen: SoftwareVersa gen. Hardware-Defekt, unzureichende Versorgung durch die Infrastruktur und zu hohe Auslastung der Betriebsmittel. Liegen solche Mängel im IT-System nicht vor, dürften sich hieraus keine Beeinträchtigungen für die Verfügbarkeit von Daten und Dienstleistungen (als Grundziel) ergeben. Beeinträchtigungen könnten sich aber noch aus Manipulationen ergeben. Infrastruktur

Betriebsmittel

Software

Aus der Infrastruktur können sich Probleme hinsichtlich

unzureichender

Stromversorgung, Über- oder Unterschreiten von Klimabedingungen, Sabotage, Katastrophen wie Feuer, Wassereinbruch usw. ergeben. Hierfür sind entweder technische Maßnahmen (Notstrom, Klimaanlagen, Gefahrenmeldesysteme, Löschsysteme) oder organisatorische Maßnahmen (Inspektion, Überwachung, manuelle Schadenbehebung...) im IV-System festzulegen. Können Verfahren zeitlich deshalb nicht wie geplant ablaufen, weil die Auslastung des Systems zu hoch ist, ist offensichtlich das System unterdimensioniert. Der andere Fall ist, daß nicht genügend Ressourcen zur Verfugung stehen, weil Subjekte in manipulativer Absicht oder unabsichtlich zu hohe Ressourcen (Prozessor-Zeit, Speicherplatz) in Anspruch nehmen. Damit haben wir die Frage der Betriebsmittelbegrenzung zu lösen. Sie wird aber normalerweise durch die Zugriffskontrolle gewährleistet und wird deshalb unter diesem Oberbegriff diskutiert. Betrachten wir nun die von Software ausgehenden Probleme. Zunächst kann Software inkorrekt sein, wobei dies den gesamten Lebenszyklus - beginnend beim Entwurf über die Implementierung bis zur Installation und zum normalen Betrieb - betrifft. Dabei gibt es unterschiedliche Ansätze: Höhere Garantie der Korrektheit durch Einsatz spezieller Entwurfs- und Implementierungstechniken (bis hin zu formal-mathematischen Methoden) oder aber der Einsatz diversitärer Programme: mehrere Programme, die durch verschiedene Entwickler/Programmierer hergestellt wurden, aber die gleiche Aufgabe erfüllen sollen, werden parallel betrieben; ihre Ergebnisse werden stets verglichen und nur bei Übereinstimmung oder nach einer "Mehrheitsentscheidung" als gültig anerkannt. In der IT-Sicherheit hat es sich eingebürgert, diese Probleme unter dem Stichwort Korrektheit, aber nicht unter funktionalen Gesichtspunkten zu betrachten.

98

3.1 Grundsätzliches Sobald eine korrekte Programmierung und Umsetzung in lauffähige Programme gewährleistet ist, kann von Software insofern keine Gefahr ausgehen, da sie im Gegensatz zur Hardware keiner Alterung oder keinem Verschleiß unterliegt. Es sind daher nur zufällig bedingte oder manipulativ erzwungene Änderungen an der Software zu betrachten - dies fällt aber unter den Punkt Verlust der Integrität und Unverfälschtheit. Bleibt noch die Hardware: Sie kann z.B. in Folge von Alterung bestimmte Funktionen nicht mehr oder nur teilweise ausfuhren. Solche Fehlfunktionen oder Defekte können unerkannt bleiben, zur Fehlerpotenzierung führen und Folgeschäden verursachen. Das Fehlverhalten kann transient (nur vorübergehend, kurzzeitig, nicht nachvollziehbar), überbrückbar oder fatal sein. Speziell für die Hardware ist die Sicherheitsfunktion Garantie der Betriebsbereitschaft wesentlich. Betriebsbereitschaft

Verfügbarkeit der Funktionalität zu jedem wünschten Zeitpunkt

Hardware

Betriebsbereitschaft

ge-

Das Ziel der Betriebsbereitschaft ist es, die durch die Hardware vermittelten Dienstleistungen immer dann zur Verfugung zu stellen, wenn sie abgerufen werden. In der Praxis geht es darum, für die permanente Betriebsbereitschaft eine Wahrscheinlichkeit zu garantieren - etwa in der Art "Über den Zeitraum von 1 Jahr wird Betriebsbereitschaft zu 99.75 % der Zeit zugesichert". Systeme, die solche Zusicherungen geben, heißen z.B. NonStop-Systeme. Die Betriebsbereitschaft wird im Englischen als Continuity of Service bezeichnet. Für die Hardware und das Zusammenspiel von Hardware und Software sind die Funktionen Rechtzeitigkeit. Fehlererkennung. Fehlerüberbrückung und Fehlerbehebung zu nennen. Rechtzeitigkeit

Dienstleistungen werden zu einem gewünschten Zeitpunkt oder innerhalb gewünschter Zeit erbracht

Nicht immer, aber oft ist entscheidend, daß die gewünschte Dienstleistung innerhalb einer bestimmten Zeit oder zu einem bestimmten Zeitpunkt erbracht wird. Damit sind wir bei dem Problem der Rechtzeitigkeif. Die gewünschte Verarbeitung wird zu dem gewünschten Zeitpunkt und/oder innerhalb eines akzeptierten Zeitrahmens ausgeführt. Es ist im einzelnen zu fragen, welche Funktionalität mit welcher Priorität zu gewährleisten ist, welche Reaktionen des Systems in welcher Zeit erfolgen müssen, unter welchen Randbedingungen die betreffende Funktionalität einzuhalten ist, welche Betriebsmittel in welchem Umfang und zu welchem Zeitpunkt zugänglich sein müssen.

99

Rechtzeitigkeit

Spezifikation

3. Sicherheitsfunktionen

Bedrohungen

Mechanismen, Echtzeit

Die Rechtzeitigkeit kann beeinträchtigt sein, wenn zeitkritische Aufgaben nicht genau zu dem Zeitpunkt durchgeführt werden, zu dem es erforderlich ist, wenn zeitunkritische Aufgaben in zeitkritische umgewandelt werden können, Betriebsmittel unnötig angefordert oder zurückgehalten werden. IT-Systeme, die die Rechtzeitigkeit von Verarbeitungen garantieren müssen im Englischen Real-Time Systems, geu n c j können werden Echtzeit-Systeme, nannt. Die zugehörigen Betriebssysteme besitzen bestimmte Mechanismen zur Verteilung der Prozessor-Zeit (Scheduling) und der Steuerung von Prioritäten, sowie der Verriegelung und Freischaltung von Verarbeitungen. EchtzeitSysteme werden typischerweise bei der Steuerung kritischer Prozesse (Produktion, Überwachung) verlangt. Fehlererkennung:

Spezifikation

Mechanismen

Bei der Fehlererkennung (Error Recognition) sind die Aspekte der Vollständigkeit und Korrektheit der Fehleranalyse zu betrachten; es ist wichtig festzulegen, welche Fehler unbedingt erkannt werden müssen. Vor allem in Systemen der höheren Preisklassen sind viele technische Komponenten (Speicherbausteine, Bus-System, Register usw.) mit Parity-Prüfungen ausgestattet, so daß sporadische oder auf Defekten beruhende Fehler erkannt, durch Verwendung fehlerkorrigierender Codes sogar korrigiert werden können. Das gleiche gilt für Bit-Fehler auf externen Speichermedien oder bei einer Datenübertragung. Fehlerüberbrückung:

Spezifikation

Mechanismen

Fehler werden an der Quelle oder zu einem möglichst frühen Zeitpunkt an ihren Auswirkungen erkannt

Vermeiden weiteren Fehlverhaltens oder Begrenzen der Auswirkungen des Fehlverhaltens eines Systems

Die Fehlerüberbrückung (Error Recovery) kann einen kontrollierten Abbruch oder den Versuch einer Fehlerkorrektur beinhalten. Es spielen folgende Einzelaspekte eine Rolle: Welche Fehlerklassen sollen überbrückt werden? In welcher Form soll die Fehlerüberbrückung erfolgen, z.B. durch kontrollierten Abbruch, Fixpunkt/Checkpoint und Wiederanlauf oder durch automatische Fehlerkorrektur? Welche Beeinträchtigungen - z.B. Daten-, Funktions- oder Zeitverlust - können in Kauf genommen werden? Bei der Fehlerkorrektur sind die Unabhängigkeit des Korrekturverfahrens von der Fehlerquelle und mögliche Fehlerquellen in der Fehlerüberbrückung selbst zu beachten. Bei Auftreten von Fehlerzuständen - nicht nur der Hardware, sondern auch bei den bekannten, meist nicht nachvollziehbaren Systemabstürzen - kann vielfach eine Kopie des Arbeitsspeichers und weiterer wichtiger Daten auf einen exter-

100

3.1 Grundsätzliches

nen Speicher geschrieben werden (Checkpoint, Dump). Nach Behebung möglicher Hardware-Fehler können Diagnose-Programme anhand dieser Kopie weitere Fehlerursachen und die Fehlerauswirkungen analysieren. Das Ergebnis kann zu einem Zurücksetzen des Systems und Neustart mit Verlust aller laufenden Tasks (Worst Case), zu einem Wiederaufsetzen auf einen früheren Stand (Backward Recovery), oder zu einem Wiederaufsetzen auf einen zukünftigen, korrekten Stand (Forward Recovery) fuhren. Ein weiterer wichtiger (aber teuerer) Mechanismus ist die Redundanz. Dabei werden wichtige Hardware-Komponenten doppelt oder mehrfach im System vorgehalten. Bei Ausfall oder Fehlern von Komponenten wird manuell oder automatisch auf funktionstüchtige Komponenten umgeschaltet. Das Auswechseln der fehlerhaften Komponenten kann anschließend erfolgen, während das System weiterläuft und die laufende Verarbeitung (wenn auch mit möglicher zeitlicher Verzögerung) abwickelt. Redundanz führt also zu fehlertoleranten Systemen (Fault-tolerant Systems). Unter Redundanz fallen auch Spiegelsysteme (meist in Zusammenhang mit Plattenspeichern), Ersatzrechenzentren und die klassische Datensicherung (Backup). Bei den letzten beiden Beispielen ist aber im Fehlerfall mit starken Verzögerungen zu rechnen. Die Verzögerungszeit muß deshalb durch Tests ermittelt werden; sie ist für die Höhe der Schäden oft ein entscheidender Faktor. Fehlerbehebung:

Redundanz

Spiegelung, Backup

Behebung eines Fehlers an der Quelle, so daß anschließend die Verarbeitung verlustfrei weitergeführt werden kann

Nur selten gibt es automatische Verfahren der Fehlerbehebung. In aller Regel sind defekte Komponenten manuell auszutauschen, Daten wiedereinzuspielen oder dislozierte Ersatzsysteme in Betrieb zu nehmen - was der Fehlerüberbrükkung zuzurechnen ist. Die verlustfreie Reparatur an der Fehlerquelle kommt aber in einem gewissen Sinne dort vor, wo Prozessor-Boards (oder ähnliches) im laufenden Betrieb einfach ausgewechselt werden dürfen, da durch kombinierte Hard- und Software-Maßnahmen sichergestellt ist, daß andere Prozessoren diesen Vorgang erkennen und die laufenden Tasks sofort übernehmen. In (ITSK89) werden Rechtzeitigkeit, Betriebsbereitschaft, Fehlererkennung und Fehlerüberbrückung unter dem Begriff Gewährleistung der Funktionalität zusammengefaßt. In (ITSEC91) wird der Begriff Zuverlässigkeit (der Dienstleistung) (Reliability of Service) in ähnlichem Sinne verwendet - allerdings steht hier der Aspekt der manipulativen (und nicht durch technischen Defekt bedingten) Minderung der Verfügbarkeit im Vordergrund.

101

Gewährleistung der Funktionalität

Zuverlässigkeit der Dienstleistung

3. Sicherheitsfunktionen

Safety

Verläßlichkeit

Im Bereich der Safety ist die Manipulation kaum Betrachtungsgegenstand, sondern vielmehr die einwandfreie permanente Funktion; die Gewährleistung der Funktionalität im zuvor beschriebenen Sinne ist somit eine wesentliche Funktion der Safety. Der Begriff Verläßlichkeit (Dependability) wird zunehmend als Oberbegriff der Security und Safety gesehen, meint also einwandfreies Funktionieren unter den realen technischen Randbedingungen wie auch Ausschluß von Manipulationen bzw. Minderung entsprechender Schäden. Verläßlichkeit ist damit ein Primär-Ziel, aber keine Sicherheitsfunktion. 3.1.7 Übertragungssicherung Übertragungssicherung: Sicherung von Daten beim Transport auf Übertragungswegen

Definition

Bedrohungen

Unter Übertragungswege fallen hier Leitungen, aber auch Funk oder optische Wege (Lichtleiter). Die Übertragungssicherung (Communication Security, ITSEC: Data Exchange) bezieht insbesondere Vertraulichkeit und Integrität in die Betrachtungen ein4. Die Datenübertragung ist generell bedroht durch unbefugte Kenntnisnahme (Abhören), unbefugtes Einspielen von Daten und Inanspruchnahme von Dienstleistungen der Übertragung, sowie Ändern von Daten. Aufgrund der stattfindenden Kommunikation zwischen verschiedenen Partnern ist die Verbindlichkeit der Datenübertragung ein wichtiges Ziel. Diesem kann das Leugnen von Kommunikationsbeziehungen, das Nichtanerkennen von Daten, das Leugnen des Empfangens und Absendens zuwiderlaufen. Mit der obigen Definition der Übertragungssicherung sind die vielfältigen Einzelaspekte offensichtlich nicht ausreichend erfaßt. Deshalb wird meist eine weitere Unterteilung entsprechend der ISO-Begriffswelt (ISSA88) vorgenommen. Die folgenden Unterfunktionen sind logisch zum Teil in den bereits in 3.1 definierten Sicherheitsfunktionen enthalten. Sie umfassen aber unter dem Stichwort "Übertragungssicherung" auch solche Subjekte, Objekte, Aktionen, die nicht durch die Zugriffskontrolle der Netzknoten erfaßt werden können. Wird z.B. eine Übertragungsleitung zum Zwecke des Abhörens angezapft, so fällt dies in der Regel den Netzwerk-Betriebssystemen nicht auf. Sie erfassen nur Aktionen an den registrierten Knoten.

4

Problemstellungen dieser Art wurden früher im Rahmen der Fernmeldesicherheit diskutiert; mit dem Zusammenwachsen von Kommunikation und Datenverarbeitung zur Informationstechnik ist eine solche Trennung nicht mehr sinnvoll.

102

3.1 Grundsätzliches

Partner-Authentisierung: Garantie, daß während einer Datenübertragung auch tatsächlich die gewünschten Partner miteinander kommunizieren Diese Funktion heißt in der ISO-Welt Peer Entity Authentication. Sie unterscheidet sich insofern von der zuvor diskutierten (einseitigen) Authentisierung, als die Betonung auf der gegenseitigen Authentisierung liegt. Bei der Definition der Sicherheitsfunktion Authentisierung ist nur eine einseitige Authentisierung (z.B. Subjekt beim Rechner bzw. Betriebssystem) gemeint. Zugriffskontrolle:

Ausschluß der unberechtigten Verwendung von Betriebsmitteln der Datenübertragung

Diese Funktion heißt in der ISO-Welt Access Control. Es ist zu verhindern, daß nicht autorisierte Benutzer bestimmte Betriebsmittel (z.B. das Leitungssystem) benutzen und dadurch unberechtigt (einseitige, zweiseitige) Kommunikationsbeziehungen aufbauen. Vertraulichkeit von Daten: Geheimhaltung der Daten während der Datenübertragung Der entsprechende ISO-Begriff ist Data Confidentiality. Unter das Stichwort "Daten" fallen hier die Nutzdaten, aber auch Adreßdaten und ergänzende Informationen wie z.B. die Länge der übertragenen Daten. Entsprechend den Erfordernissen kann über die Geheimhaltung der Nutzdaten hinaus auch die Vertraulichkeit solcher Verbindungsdaten gefordert sein. Andernfalls ist es Mithörern möglich, eine Verkehrsanalyse durchzuführen. Aus plötzlich auffällig häufigen Datenübertragungen zwischen zwei Partnern kann ein Dritter durchaus seine Schlüsse ziehen... Das Speichern der Verbindungsdaten ist unter Datenschutzgesichtspunkten ein heißes Diskussionsthema bei allen (digitalen) öffentlichen Netzwerken. Es wird dort aus Abrechnungs- und Nachweisgründen vorgenommen. Integrität von Daten:

Die relevanten Daten müssen bei der Übertragung an allen dazu erforderlichen Stellen zweifelsfrei aus dem Datenstrom rekonstruiert werden können

Relevant sind die Nutzdaten und die Verbindungsdaten (Sender, Empfänger). Es darf bei Manipulationsversuchen und bei technischen Fehlern nicht möglich sein, Adressen oder Nutzdaten zu verändern. Der ISO-Begriff ist Data Integrity.

103

Vertraulichkeit

Daten

von

3. Sicherheitsfunktionen

Die beiden folgenden Unterfunktionen behandeln das Nachweisproblem. Authentisierung des Senders: Identifizierung und Authentisierung des Urhebers eines Datenstromes Ziel dieser Funktion ist es, in einem Netzwerk z.B. vor dem Absenden einer Nachricht eine Identifizierung und Authentisierung des Urhebers der Nachricht durchzuführen, damit dieser später seine Urheberschaft nicht leugnen kann. Der ISO-Begriff ist Data Origin Authentication. Anerkennung von Daten: Nachweis des Ursprungs und des Empfangs von Daten Der ISO-Begriff ist Non-repudiation. Hier sind folgende Teilfunktionen gemeint: 1) Ein Empfanger eines Datenstroms möchte beweisen, daß der angebliche Sender auch tatsächlich der Sender ist. Dieser Teil ist quasi dual zur Sicherheitsfunktion Data Origin Authentication. 2) Der Sender eines Datenstroms möchte beweisen, daß der Adressat die Daten auch tatsächlich erhalten hat. Beide Aspekte treten z.B. in einem Netzwerk auf, in dem juristisch verbindliche Daten (Verträge, Terminschreiben,...) ausgetauscht werden. In einem Netz, das die Sicherheitsfunktion "Non-repudiation" besitzt, kann der Empfänger von Daten sich auf die Authentizität des Senders verlassen, der Sender darauf, daß seine Daten beim Empfänger tatsächlich eingetroffen sind. 3.1.8 Sonstiges Es gibt noch eine Reihe von sicherheitsrelevanten Funktionen, die in den zuvor definierten Sicherheitsfunktionen nicht enthalten sind bzw. ihnen nicht direkt zugeordnet werden können. Ein Beispiel ist die in vielen Produkten enthaltene Dunkelschaltung des Bildschirms. Durch Betätigen eines Hot Keys kann der Bildschirm verdunkelt und erst auf Eingabe eines Codewortes wieder reaktiviert werden. Diese Funktion vermeidet den Verlust der Vertraulichkeit, wenn der Benutzer kurzfristig seinen Arbeitsplatz verlassen möchte und auf dem Bildschirm vertrauliche Daten stehen. Diese Sicherheitsfunktion hat Berührungspunkte mit der Identifizierung und Authentisierung, sowie der Zugriffskontrolle, ist aber keiner Sicherheitsfunktion explizit zuzuordnen. Die zuvor definierten Sicherheitsfunktion dürfen also keinesfalls als abschließend aufgefaßt werden.

104

3.2 Zugriffsschutzmodelle

3.2 Zugriffsschutzmodelle 3.2.1 Allgemeines Eine der wesentlichen Sicherheitsfunktionen ist die Zugriffskontrolle. Sie erlaubt oder verwehrt Subjekten, bestimmte Aktionen mit Objekten auszufuhren. Dabei gibt es sehr unterschiedliche Regeln, nach denen eine Zugriffskontrolle arbeiten kann. Man spricht hier vom jeweiligen Modell der Zugriffskontrolle oder der Zugriffsschutzpolitik. Die Regeln, nach denen die Zugriffskontrolle arbeitet, können sich gegen den Verlust der Vertraulichkeit, der Integrität, der Verfügbarkeit und der Verbindlichkeit richten. Die Tabelle 3-1 zeigt einige Zugriffsschutzpolitiken und ihre Anwendungsbereiche. Die fett gedruckten Beispiele werden in den folgenden Abschnitten näher erläutert. Verfügbarkeit und Verbindlichkeit haben bisher kaum Eingang in standardisierte Modelle gefunden. Politik

Wahrung von

Anwendungsbereich

Diskrete Zugriffskontrolle

Vertraulichkeit, Integrität

Kommerzieller Bereich, Datenschutz

Zuständigkeitspolitik

Vertraulichkeit, Integrität

Kommerzieller Bereich, Datenschutz

Schutzklassen-Politik

Vertraulichkeit

Militärischer Bereich

Bell-LaPadula-Politik

Vertraulichkeit

Militärischer Bereich

System-High

Vertraulichkeit

Militärischer Bereich

Striktes Integritätsmodell nach Biba

Integrität

Kaum praktische Anwendungen

Clark-Wilson-Modell

Integrität

Integrität von Transaktionen, Funktionstrennung; Finanzwelt

Bre wer-Nash-Mode 11

Vertraulichkeit

Kundendaten; Finanzwelt

Landwehr-Modell

Vertraulichkeit, Integrität

Nachrichtenübermittlung

Rot-Schwarz-Trennung

Vertraulichkeit

Einsatz im Kryptobereich

Tabelle 3-1: Übersicht über Zugriffsschutzpolitiken

105

3. Sicherheitsfunktionen

DAC

Besitzer

Zugriffskontrollmatrix

3.2.2 Der diskrete Zugriffsschutz Beim diskreten Zugriffsschutz (Discretionary Access Control, kurz: DAC) sind die Zugriffsrechte zwischen einzelnen Subjekten und einzelnen Objekten in Form einer Tabelle geregelt. Für jedes Paar Subjekt/Objekt steht fest, ob eine bestimmte Aktion wie z.B. Lesen, Schreiben, Ausfuhren oder Löschen zugelassen oder ausgeschlossen ist. Meist ist in diesem Modell das Besitzer-Konzept vorgesehen: Der Besitzer eines Objektes kann selbst über die Weitergabe und Änderung von Zugriffsrechten zu seinem Objekt entscheiden. Statt von der diskreten Zugriffskontrolle spricht man in diesem Fall auch von der benutzerbestimmbaren Zugriffskontrolle. Bei der DAC können die Rechtebeziehungen durch eine Tabelle bzw. Matrix die Zugriffskontrollmatrix - dargestellt werden. Jeder Spalte entspricht ein Subjekt, jeder Zeile ein Objekt. In der Matrix selbst werden an den Kreuzungspunkten die für das Subjekt zulässigen Aktionen bezüglich des Objektes eingetragen. Beispiel: S| bezeichne Subjekte, Oj Objekte. Zugriffsarten seien durch Kürzel R (Read/Lesen), W (Write/Schreiben), X (Execute/Ausfuhren), D (Delete/ Löschen) und "-" für "kein Zugriff erlaubt" angedeutet.

o\s

O, o2 o3 o4

s2

s3

s4

s5

-

R

RW

RW

RWX

RWXD

X

-

-

-

-

-

-

-

R

XD

R

R

R

RW

S,

Tabelle 3-2: Beispiel für eine Zugriffskontrollmatrix

MatrixKomprimierung

Bei einem realen System mit vielen Subjekten und Objekten ist die Matrix sehr groß; viele Plätze werden möglicherweise unbesetzt sein - besser gesagt, es bestehen keine Zugriffsrechte. Da aus Performance-Gründen ein schneller Zugriff gegeben sein muß, wird die Zugriffskontrollmatrix im Arbeitsspeicher gehalten. Die Matrix blockiert damit teuere System-Ressourcen. Aus diesem Grund sind Konzepte der Matrix-Komprimierung interessant. Hierzu gibt es mehrere Möglichkeiten: Werden Subjekte mit gleichen Zugriffsrechten zu einer Gruppe zusammengefaßt, und wird nur diese Gruppe in der Zugriffskontrollmatrix eingetragen,

106

3.2 Zugriffsschutzmodelle

bringt dies unter Umständen eine erhebliche Reduktion der Größe (Zeilenzahl). Dabei dürfen einzelne Subjekte durchaus in mehreren Gruppen registriert sein. Gleichermaßen kann die Bildung von Objektgruppen (z.B. alle Dateien in einem Directory, Dateien mit gleichem Zugriffsprofil) die Matrix erheblich verkleinern, da damit die Spaltenzahl reduziert wird. Auch hierbei können einzelne Objekte in mehreren Objektgruppen auftauchen. Schließlich ist festzuhalten, daß in der Praxis viele Positionen der Matrix die Eintragung "-" (Zugriff ist nicht erlaubt) besitzen; damit können im Hinblick auf die Speicherung der Matrix viele Felder ausgespart bleiben - wenn auf andere Weise die Zuordnung zum richtigen Subjekt oder Objekt gewährleistet ist. Bei der Implementierung der DAC trifft man deshalb häufig auf folgende Verfahren: 1) Jedem Objekt wird eine Liste der Namen von Subjekten zugeordnet, die Zugriffsrechte zu diesem Objekt besitzen. Darin wird auch die Art des erlaubten Zugriffs eingetragen. Diese Liste heißt Access Control List (ACL); bei Datei-Objekten wird sie der betreffenden Datei vorangestellt oder angehängt. Diese Variante hat den Vorteil, daß schnell ersichtlich ist, wer für ein bestimmtes Objekt tatsächlich Zugriffsrechte besitzt; dafür ist die Administration aufwendiger, da sie jedes einzelne Objekt bearbeiten muß. Abhilfe bringt hier das Prinzip, gewisse Standardrechte voreinzustellen, so daß die ACL jeder neu erzeugten Datei noch leer bleiben kann; der Erzeuger oder Besitzer kommt stets über die Standardrechte zum Zug. Man beachte hier die Anmerkungen zur Reihenfolge der Rechteauswertung unter 3.1.2! 2) Jedem Subjekt ist eine Liste derjenigen Objekte zugeordnet, auf die das Subjekt Zugriffsrechte besitzt. Die Art des erlaubten Zugriffs wird eingetragen. Diese Liste wird gelegentlich Bindery genannt. Diese Variante ist administrativ oft einfacher zu handhaben, da vielfach die Zahl der Subjekte kleiner als die Zahl der Objekte sein dürfte; andererseits ist es schwieriger herauszufinden, wer alles auf ein bestimmtes Objekt zugreifen darf. Darüber hinaus macht diese Methode "verwaltungstechnisch" nur Sinn, wenn es gewisse Regeln über Standardrechte bei der Erzeugung neuer Dateien gibt. Grundsätzlich wird die Rechteverwaltung erheblich erleichtert, wenn es möglich ist, in solchen Listen Konstrukte wie "Alle Subjekte dürfen...", "Alle Subjekte außer ... dürfen","... dürfen alles" oder"... dürfen alles außer...". 3.2.3 Das Zuständigkeitsmodell Das Modell der Zuständigkeit ist ein Beispiel für eine globale oder regelbasierte Zugriffskontrolle. Sie richtet sich nicht nach einzelnen Subjekten und Objekten, sondern geht nach einer bestimmten inhaltlichen Regel vor, die global auf alle Zugriffsversuche angewendet wird. Beispiel: In einer Verwaltung sind unterschiedliche Arbeitsgebiete vertreten wie z.B. Personalreferat, Haushaltsreferat, Projektüberwachung. Mitarbeiter

107

Access Control List

Bindery

Regelbasiert

3. Sicherheitsfunktionen

Need-to-Know

sind diesen Aufgaben zugeordnet. Es macht Sinn, Mitarbeitern des Personalreferates Zugriff auf alle Personaldaten, Mitarbeitern des Haushaltsreferates Zugriff auf alle Budgetdaten zu gewähren. Dabei spielt es zunächst keine Rolle, welche speziellen Personen in einem Referat arbeiten bzw. welche speziellen Dateien diesem Referat zugeordnet sind. Die Zugriffsregel lautet also hier: Die für die jeweilige Aufgabe zuständigen Mitarbeiter haben Zugriff auf die zu ihrem Arbeitsgebiet gehörenden Daten. Abstrakter: Die Zugriffsrechte werden nach Zuständigkeitsbereichen bzw. Arbeitsgebieten vergeben. Aus Sicht der Sicherheit kann das erläuterte Beispiel auch so beschrieben werden: Zu Personaldaten dürfen nur solche Mitarbeiter zugreifen, die im Rahmen ihrer Aufgabe dazu ein Recht und einen Bedarf haben. Im Hinblick auf die Vertraulichkeit der Daten gilt also das Prinzip "Kenntnisnahme nur, wenn nötig". Dieses Prinzip wird im Englischen Need-to-Know genannt. Die verschiedenen Zuständigkeitsbereiche (im Englischen: Compartments, teilweise auch Partitions genannt) können beziehungslos nebeneinander stehen oder gewisse Übergänge zulassen. Man spricht dann von disjunkten oder assoziierten Bereichen.

assoziierte Compartments

disjunkte Compartments

Abbildung 3-2: Strukturen von Compartments

Realisierung

Da innerhalb jedes Zuständigkeitsbereiches unter Umständen noch zwischen verschiedenen Zugriffsarten wie Lesen und Schreiben zu unterscheiden ist, wird man zusätzlich bereichsbezogen eine diskrete Zugriffskontrolle einsetzen. l n der Praxis läßt sich das Modell der Zuständigkeit durch das Gruppenkonzept realisieren. Dabei muß das Betriebssystem die Möglichkeit bieten, einzelne Subjekte Gruppen zuzuordnen und auf Basis solcher Gruppen Zugriffsrechte zu vergeben. Alle Subjekte mit gleicher Zuständigkeit gehören einer entsprechenden Gruppe an. Umgekehrt kann auch auf Basis von Objektgruppen gearbeitet werden; dabei werden Zugriffsrechte an Benutzer für solche "grossen" Objekte vergeben. Ist in einem Betriebssystem die DAC mit Subjekt- und Objektgruppen realisiert, so faßt man die Personen einer bestimmten Zuständigkeit und die Daten

108

3.2 Zugriffsschutzmodelle

eines Arbeitsgebietes jeweils zu Gruppen zusammen und hat eine erhebliche Reduktion von Verwaltungsaufwand erreicht. Statt Zugriffsrechte aufgrund von (authentischen) User-IDs oder Gruppen-IDs zu vergeben, können auch geheime Codes verwendet werden: Die Erlaubnis zur Ausführung einer bestimmte Aktion auf einem Objekt ist an die Kenntnis einer geheimen Information gebunden. Nur wer diesen Code kennt, ist berechtigt und in der Lage, die gewünschte Operation auszuführen. Natürlich ist es sinnlos, ein System mit vielen Objekten und Aktionen allein auf der Basis solcher Codes zu verwalten. Ein Benutzer kann sich nur wenige solcher Codes merken. Sinn macht es erst, wenn Objekte in wenige Objektklassen zusammengefaßt sind, wobei ein Subjekt bei einer solchen Klasse z.B. entweder alles darf oder nur lesen. Damit wären pro Objektklasse nur zwei Codes vorhanden. Dieses Verfahren findet sich bei einigen Großrechner-Betriebssystemen und läuft unter den Bezeichnungen Leseschlüssel und Schreibschlüssel.

Codes

Die Rechteverwaltung beschränkt sich auf die Speicherung des Codewortes pro Objektklasse und Zugriffsart. Zum Entzug der Rechte muß lediglich das Codewort geändert werden, wodurch allerdings automatisch allen Subjekten das Zugriffsrecht entzogen wird. Nachteil dieser Methode ist die mangelnde Transparenz: Der System-Verwalter kann nie sicher wissen, wer im Besitz eines Codewortes ist, da dieses durch Ausspähen oder durch Fahrlässigkeit, vielleicht sogar vorsätzlich weitergegeben werden kann. Das Erzeugen von neuen Dateien kann erheblichen Verwaltungsaufwand erfordern. Die Methode der Codes wird in der Praxis nur in Kombination mit den übrigen erläuterten Verfahren eingesetzt. In realen Systemen ist es oft erforderlich, Daten zwischen verschiedenen Zuständigkeitsbereichen auszutauschen. Im eingangs aufgeführten Beispiel könnte das Referat Projektüberwachung ein berechtigtes Interesse daran haben, den Mittelabfluß für Projekte im Haushaltsplan einzusehen, also auf Daten des Haushaltsreferates zumindest lesend zuzugreifen. Damit liegt der Fall assoziierter Compartments vor: Den Zugriffsanforderungen kann leicht entsprochen werden, indem bestimmte Subjekte mehrere Zuständigkeiten besitzen. Formal ist also jedem Subjekt ein Liste von Zuständigkeiten zuzuordnen. Andererseits kann auch ein Objekt mehreren Arbeitsgebieten angehören, d.h. auch zu jedem Objekt gehört eine entsprechende Liste. Ein Subjekt darf nur dann auf ein Objekt zugreifen, wenn dieses in einer seiner Zuständigkeiten liegt. Etwas formaler: Wird das Subjekt mit S bezeichnet, und ist Z(S) die Menge der zu S gehörenden Zuständigkeiten, Z(O) die Menge der Arbeitsgebiete, denen das Objekt O angehört, so lautet Umsetzung der zuvor genannten Zugriffsregel:

109

Informationsaustausch

Regeln

3. Sicherheitsfunktionen

Zugriff von S auf das Objekt O ist erlaubt, wenn Z(S) und Z(O) mindestens einen gemeinsamen Bereich haben (mathematisch: Z(S)nZ(O)*0). Betrachten wir dazu Beispiele: Es seien S„ S 2 , S3, S 4 Subjekte. Bei den Zuständigkeitsbereichen stehe P für Personal, H für Haushalt, Ü für Projektüberwachung. Für die Zuständigkeiten gelte: Subjekt

s,

S2

S3

Zuständigkeiten

H

P

P,ü

s4 H, Ü, P

Tabelle 3-3: Zuständigkeitstabelle

Informationsfluß

Das Objekt O gehöre zu den Arbeitsgebieten H und Ü, d.h. Z(0)={H, Ü}. Dann dürfen nur S t , S 3 und S4 auf O zugreifen; Z(S 2 ) und Z(O) besitzen dagegen keinen gemeinsamen Bereich. Bei jeder regelbasierten Zugriffskontrolle ergibt sich das Problem des unerlaubten Informationsflusses: Wer wie S 3 und S4 auf die Bereiche P und Ü zugreifen darf, könnte Daten aus einem Objekt des Bereichs P in ein Objekt des Bereichs Ü schreiben. Soll also ein solcher Informationsfluß verhindert werden, also die Bereiche P und Ü getrennt bleiben, müssen für das Lesen und Schreiben getrennte Regeln definiert werden. Folgender Regelsatz verhindert den Informationsfluß zwischen Objekten, die in separierten Bereichen liegen: 1.

S darf auf ein Objekt O genau dann lesend zugreifen, wenn Z ( S ) n Z ( O ) * 0 gilt.

2.

S darf auf ein Objekt P genau dann schreibend zugreifen, wenn Z ( S ) c Z ( P ) gilt.«

Sind nämlich O und P zwei separierte Bereiche (Z(O)nZ(P)=0), und dürfte S das Objekt O lesen und Daten in das Objekt P schreiben, so wäre nach den obigen Regeln 0 * Z(S)nZ(0) c Z(P)nZ(0), was im Widerspruch zu unserer Annahme über die Separiertheit steht. Will man einen Informationsfluß schon dann unterbinden, wenn Z(O) und Z(P) nicht identisch sind6, muß man die Regel 1 wie folgt verschärfen: 1 a. S darf auf Objekt O genau dann lesend zugreifen, wenn Z ( 0 ) c Z ( S ) gilt.

5

6

Das Zeichen c meint die Untermenge, ist hier aber nicht strikt, d.h. Gleichheit ist zugelassen. Aber dennoch gemeinsame Zuständigkeitsbereiche bzw. Arbeitsgebiete besitzen können.

110

3.2 Zugriffsschutzmodelle

Unter Nutzung der Regeln la und 2 ergibt sich sofort, daß Lesen und Schreiben in das gleiche Objekt nur dann zugelassen ist, wenn Z(S)=Z(0) gilt. Diese kurze mathematische Diskussion zeigt, wie bereits bei einfachen Beispielen die Auswirkungen von Regeln zur Zugriffskontrolle nicht sofort nachvollziehbar ist, d.h. die Überschaubarkeit nicht mehr gegeben sein kann. 3.2.4 Das Schutzklassen-Konzept Das Schutzklassen-Konzept formuliert ebenfalls globale Regeln der Zugriffskontrolle. In der Praxis ist es im staatlichen Verschlußsachenbereich existent: Es werden Ermächtigungen (Clearances) für Subjekte und Einstufungen (Classifications) für Objekte vergeben. Dabei geht man von einer Skala mit den Werten offen « NfD 7 « vertraulich « geheim « streng geheim aus. Objekte O erhalten eine Einstufung E(O) aus dieser Skala, Subjekte S erhalten entsprechend bezeichnete Ermächtigungen E(S) aus dieser Skala (z.B. ermächtigt bis zur Stufe vertraulich). Es sind aber auch Systeme bekannt, in denen Einstufung und Ermächtigung durch eine Zahl (z.B. von 1 bis 10) gegeben sind. Prinzipiell spielt die Bezeichnung der Klassen keine Rolle. Wichtig ist, daß die Einstufungen und Ermächtigungen den gleichen Wertevorrat haben und die Werte linear angeordnet sind. Die Klassen haben eine vertikale Struktur: /N steigende Sensitivität

Abbildung 3-3: Schutzklassen Aktionen sind der Lesezugriff, der Schreibzugriff und das Erzeugen neuer Subjekte (=Prozesse). Dabei muß noch präzisiert werden, welche Aktionen unter Schreiben fallen. Das Erzeugen neuer Objekte und Füllen mit Inhalt ist ein Schreibvorgang. Das Hinzufügen von Informationen zu einem bestehenden Objekt fallt ebenfalls unter Schreiben. Zum Modifizieren von vorhandenen Objekten ist zunächst ein Lesevorgang, danach ein Schreibvorgang erforderlich, woraus sich später die entsprechende Zugriffsregel ableiten läßt.

7

N f D = nur für den Dienstgebrauch.

111

3. Sicherheitsfunktionen

Beim Konzept der Schutzklassen werden folgende Regeln vorgegeben:

Informationsfluß

Beispiel

1.

Lesen darf ein Subjekt ein Objekt nur, wenn die Ermächtigung des Subjektes mindestens so hoch ist wie die Einstufung des Objektes. (E(S) > E(O))

2.

Schreiben darf ein Subjekt nur dann in ein Objekt, wenn die Einstufung des Objektes mindestens so hoch ist wie die Ermächtigung des Subjektes (E(O) > E(S))

Die Lese-Regel - Read-Down genannt - ist intuitiv klar. Zur Erläuterung der Schreib-Regel betrachten wir die Situation beim Datenträger "Papier": Die Einstufung eines Dokumentes ist durch einen Stempelaufdruck in der Kopfzeile jeder Seite gegeben. Schneidet man diese Kopfzeile ab und kopiert danach die Seite, so erhält man ein formal nicht eingestuftes Dokument gleichen Inhalts. Der zum Lesen Befugte schreibt bei diesem Kopiervorgang den Inhalt des eingestuften Dokumentes in ein niedriger (offen) eingestuftes Objekt (leeres Papier). Etwas abstrakter: Wer Zugang zu einer höher eingestuften Information hat, könnte diese lesen und in ein niedriger eingestuftes Objekt hineinschreiben. Informationen würden auf diese Weise heruntergestuft - was in der Welt dieser Zugriffskontrolle ein Sakrileg bedeutet. Durch die obige Regel für den Schreibvorgang wird dies aber verhindert! Es wird erreicht, daß Informationen aus einem höher eingestuften Objekt nicht in ein niedriger eingestuftes Objekt fließen können: Hier wird also eine Informationsflußkontrolle ausgeübt. Ein Schreiben auf gleicher Ebene oder nach oben - Write-Equal oder Write-Up genannt - ist zulässig. Die nachfolgenden Tabellen geben Beispiele zur Veranschaulichung der Zugriffsregeln. Subjekt Ermächtigung Objekt Einstufung

s2

s,

offen

geheim

o,

NfD

o2

vertraulich

s3

streng geheim

o3

offen

Tabelle 3-4: Ermächtigungen und Einstufungen

112

o4

streng geheim

s4

NfD

os

offen

3.2 Zugriffsschutzmodelle

Entsprechend diesen Tabellen darf z.B. S2 die Objekte 0 3 und 0 5 lesen und in alle Objekte schreiben. S, darf alles außer 0 4 lesen, aber nur in 0 4 schreiben. Da ein Subjekt nicht nur Objekte, sondern auch neue Subjekte erzeugen kann z.B. kann ein Prozeß ein Programm starten und damit einen neuen Prozeß erzeugen - ist noch folgende Regel wichtig: 3.

Die von einem Subjekt S erzeugten Subjekte T dürfen höchstens die gleiche Ermächtigung wie ihr erzeugendes Subjekt erhalten. (E(T) < E(S))

Das erzeugte Subjekt kann dann keine Kenntnis von solchen Informationen erlangen, von denen auch das erzeugende Subjekt keine Kenntnis erhalten darf. 3.2.5 Das Bell-LaPadula-Modell Das Bell-LaPadula-Modell (BELP76) vereinigt in sich die beiden zuvor diskutierten Modelle der Zuständigkeit und der Schutzklassen. Dabei werden nur assoziierte Compartments betrachtet. Die Voraussetzungen in diesem kombinierten Fall lauten: 1) Jedem Objekt O ist ein Paar Z(0),E(0) zugeordnet, wobei Z(O) eine Menge von Compartments bezeichnet, zu denen das Objekt gehört, und E(O) die Einstufung des Objektes angibt. 2) Analog ist auch jedem Subjekt S ein Paar Z(S),E(S) zugeordnet - mit einer Menge Z(S) von Compartments und einer Ermächtigung E(S) des Subjektes. Der Wertebereich der Einstufungen bzw. Ermächtigungen ist linear geordnet. Man spricht hier auch von einem hierarchischen Merkmal. Im Gegensatz dazu sind die Compartments nicht zwingend in dieser Weise angeordnet. Deshalb werden sie nichthierarchisch genannt.

Compart. A

Compart. B

Compart. C

Compart. D

Compart. E

Stufe 4 Stufe 3 Stufe 2 Stufe 1

Abbildung 3-4: Bell-LaPadula Modell

113

Beschreibung des Modells

3. Sicherheitsfunktionen Regeln

Die Zugriffsrechte werden hier nach folgenden Regeln vergeben:

MAC Attribute bzw. Labels

Multi-Level Compartments

CMW

Performance

Cut and

Paste

1.

Lesen des Objektes wird gestattet, wenn Z(S) 2 Z(O) und E ( S ) > E ( 0 ) gilt.

2.

Schreiben des Objektes wird gestattet, wenn Z(S) c Z(O) und E ( S ) < E ( 0 ) gilt.

3.

Erzeugt S ein neues Subjekt T, so muß Z(T) c Z(S) und E(T) < E(S) sein.

Dieses Modell der Zugriffskontrolle wird vorgeschriebene Zugriffskontrolle, im Englischen Mandatory Access Control (kurz: MAC) genannt. Das Paar Z(0),E(0) bzw. Z(S),E(S) wird als Attribut des Objektes bzw. Subjektes bezeichnet. Es besteht also aus einem nichthierarchischen und einem hierarchischen Anteil. Im englischen werden die Attribute (Confidentiality) Labels genannt. Systeme, in denen das Bell-LaPadula-Modell implementiert ist, werden Multi¿eve/-Systeme genannt. Bei Bell-LaPadula sind darüber hinaus die Bereiche bzw. Compartments aus Z(O) bzw. Z(S) dahingehend verallgemeinert worden, daß sie nicht nur Zuständigkeiten oder Arbeitsbereiche, sondern übergeordnete Schutzbereiche kennzeichnen können; beispielsweise könnte ein Unternehmen Daten nach entwicklungsvertraulich(A), Firmen-intern(B) und allgemein zugänglich(C) klassifizieren und in den ersten beiden Bereichen eine detailliertere Einstufung einfuhren. Workstations im Unix-Bereich, die solche Klassenbildungen zulassen, werden Compartment Mode Workstations (CMW) genannt. Die Erfahrungen mit Multi-Level-Systemen zeigen folgendes: 1. Die Systeme verbrauchten vor nicht allzu langer Zeit einen ansehnlichen Teil ihrer Performance für das Auswerten der oben angeführten Zugriffsregeln. Man denke daran, daß für jede Prozeßerzeugung, jeden Schreib- und Lesezugriff, jeden zugewiesenen Speicherbereich intern und extern die Regeln durchzuspielen sind. Mit zunehmender Geschwindigkeit der heutigen Rechner ist dieses Argument allerdings wieder hinfällig. Bei leistungsstarken MultiLevel-Unix-Systemen machen sich Performance-Einbußen nur geringfügig bemerkbar. 2. Bei den heute vielfach verwendeten Bedienungsoberflächen vom WindowTyp besteht die Problematik des Cut and Paste. Sind nämlich auf dem Bildschirm zwei unterschiedlich eingestufte Fenster geöffnet, so könnte der Benutzer aus einem "geheimen" Fenster Daten in ein "vertrauliches" Fenster kopieren, was nicht gestattet ist.

114

3.2 Zugriffsschutzmodelle

3. Sofern das Write-Up implementiert ist, werden sich nach längerer Betriebszeit alle Informationen - gleich welcher Ausgangseinstufung - in Dateien der höchsten Einstufung wiederfinden, was letztlich nicht im Sinne dieser Politik ist. Als Abhilfe und zum Teil auch aus Implementierungsgründen haben viele Multi-Level-Systeme nur das Write-Equal vorgesehen, bei dem ein Subjekt genau dann in ein Objekt schreiben darf, wenn seine Ermächtigung mit der Einstufung des Objektes übereinstimmt. 4. Alle externen Geräte, die z.B. bedrucktes oder gelochtes Papier produzieren, müssen ebenfalls dem vorgeschriebenen Zugriffsschutz unterliegen: Alle auszugebenen Daten sind mit ihrem Attributwert zu kennzeichnen. Bei der Ausgabe auf einen Drucker könnte dies eine entsprechende Kopfzeile auf jeder gedruckten Seite sein. 5. Das gleiche gilt sinngemäß für bewegliche Datenträger wie Disketten und Bänder, bei denen Labels magnetischer Art geschrieben und gelesen werden müssen. 6. Wichtig ist, daß die Administration eines Multi-Level-Rechners oder MultiLevel-Netzwerks enorme Anforderungen an den System-Verwalter stellt, und zwar sowohl vom Aufwand her wie auch an seine theoretischen Kenntnisse über diese Zugriffsschutzpolitik. Da das Schutzklassen-Prinzip nicht an der Grenze eines Rechners Halt machen kann, ist noch folgendes zu beachten: In vernetzten Multi-Level-Systemen werden eingestufte Daten über Leitungen transportiert. Frei zugängliche Leitungen sollten keine hoch eingestuften Informationen übertragen, besonders geschützte dagegen unterliegen möglicherweise keinen Einschränkungen. Da in einem Netz meist noch besondere Einrichtungen wie Repeater, Gateways, Vermittlungsrechner usw. integriert sind, stellt sich die Frage, ob diese Systeme - die ja meist auch programmgesteuert sind - einen unerlaubten Informationsfluß ausschließen können. Probleme dieser Art fuhren dazu, die Verbindungskanäle {Importkanäle und Exportkanäle) zwischen zwei Systemen ebenfalls einzustufen und entsprechende Regeln vorzugeben. Kanäle sind einstufig, wenn sie Daten eines festen Attributwerts übertragen dürfen, mehrstufig, wenn sie Daten unterschiedlicher Attributwerte übertragen dürfen. Bei einstufigen Kanälen brauchen in der Regel die Attributwerte von Daten nicht übertragen zu werden, da sie sich aus der Einstufung des Kanals implizit ergeben. Problematisch ist hier, daß die Einstufung eines Kanals von einer autorisierten Person manuell festzulegen ist und durch die beteiligten IT-Systeme zuverlässig beachtet werden muß. Bei mehrstufigen Kanälen sind die Attributwerte von Daten in jedem Fall mit zu übertragen: Der Empfänger muß die Attribute sicher rekonstruieren und zuordnen können.

115

Migration

Write-Equal

Ausgaben

Administration

Vernetzung

Import, E x p o r t

Kanal

3. Sicherheitsfunktionen

Daten ohne Attribut

System-High

Integrity P o l i c y

Regeln

Stets ist an den Schnittstellen zwischen den IT-Systemen und den sie verbindenden Kanälen eine Aktion durch autorisierte Personen nötig, wenn nichtattributierte Daten ankommen. Ihr Attribut im Zielsystem ist festzulegen. 3.2.6 System-High Da i n früheren Zeiten kaum Systeme nach Bell-LaPadula arbeiteten, die wenigen Ausnahmen zudem teuer waren und meist auch noch Export-Restriktionen unterlagen, stellte sich die Frage, ob und wie man in Standardsystemen mit eingestuften Objekten verfahren könne. Hierzu wurde der sogenannte System///g/i-Betrieb als Notlösung eingeführt. Ihm liegen folgende Überlegungen zugrunde: 1) Besonderer Wert wird auf eine Abschottung "nach außen" gelegt, während autorisierte Benutzer als prinzipiell vertrauenswürdig angesehen werden. 2) Alle Sicherheitsmaßnahmen werden an der höchsten im System vorkommenden Einstufung der Objekte ausgerichtet. 3) Für diese höchste im System vorkommende Einstufung müssen alle autorisierten Benutzer ermächtigt sein. Damit kann ein Informationsfluß zu geringer ermächtigten autorisierten Personen nicht stattfinden (da ja keine vorhanden sind). 4) Die Einstufung der einzelnen Objekte wird von der Zugriffskontrolle nicht beachtet - was in einem klassischen Betriebssystem ja auch nicht möglich ist. 5) Die Regeln der Politik der Zuständigkeiten werden angewandt. (Sie können durch eine DAC mit Gruppenkonzept realisiert werden.) Man hat mit diesen Spielregeln alles auf die Kontrolle der Zuständigkeiten reduziert, das Problem der Einstufung aber durch entsprechend hohes Ermächtigen aller Benutzer "gelöst". 3.2.7 Das Biba-Modell Dieses Modell (BIBA77) ist in gewisser Weise dual zum Bell-LaPadulaModell, richtet sich aber gegen den Verlust der Integrität. Die Objekte, deren Integrität zu wahren ist, erhalten Einstufungen. Die Höhe der Einstufung spiegelt den Grad der Integrität wider, den das betreffende Objekt haben soll. Analog erhalten Subjekte Ermächtigungen zum Zugriff auf solche Objekte. Bei den Aktionen wird wieder zwischen Lese- und Schreibzugriff unterschieden. Während beim Bell-LaPadula-Modell verhindert werden soll, daß Informationen von oben nach unten fließen, wird beim Biba-Modell verlangt, daß die Integrität von höher eingestuften Objekten nicht durch niedriger ermächtigte Subjekte verletzt wird. Anders ausgedrückt: Es soll eine Modifikation von unten nach oben verhindert werden. Die anzuwendenden Regeln sind deshalb ein Spiegelbild der Regeln aus Abschnitt 3.2.5. Die Bereiche Z(O) und Z(S), sowie die Einstufungen E(O) und E(S) beziehen sich jetzt allerdings auf die Integrität.

116

3.2 Zugriffsschutzmodelle

1.

Lesen des Objektes wird genau dann gestattet, wenn Z(S) cz Z(O) und E(S) < E(O) gelten.

2.

Schreiben des Objektes wird genau dann gestattet, wenn Z(S) 2 Z(O) und E(S) > E ( 0 ) gelten.

3.

Erzeugt S ein neues Subjekt T, so muß Z(T) c Z(S) und E(T) < E(S) gelten.

Das Paar Z ( 0 ) , E ( 0 ) bzw. Z(S),E(S) wird als Integritätsattribut bzw. Subjektes bezeichnet, im Englischen Integrity Label.

des Objektes

3.2.8 Das Clark-Wilson-Modell Das in (CLAW87) beschriebene Modell formuliert einen Zugriffsschutz, der gegen den Verlust der Integrität gerichtet ist. Es ist vor allem auf Datenbanken und im Bereich von Finanztransaktionen anwendbar, wobei einerseits die gespeicherten bzw. übertragenen Informationen und andererseits die Abfrageund Verarbeitungsprozeduren schützenswert sind. Aktionen sind dabei typischerweise komplexe Transaktionen. Sie müssen entweder vollständig und korrekt ablaufen, oder die beteiligten Objekte sind in ihrem Ausgangszustand zu belassen bzw. darauf zurückzusetzen. Auf die betrachteten Objekte sollen im Clark-Wilson-Modell nur zwei Kategorien von Aktionen ausgeübt werden: die Überprüfung der Integrität (IVP, Integrity Verification Procedure) und erlaubte Transaktionen (TP, Transaction Procedures). Erlaubte Transaktionen sollen per definitionem die Integrität der Objekte nicht verletzen. Ob die IVPs und die TPs selbst integer bzw. vertrauenswürdig sind, kann nur durch eine Überprüfung außerhalb des Systems festgestellt werden. In (CLAW87) wird dieser Vorgang externe Zertifizierung genannt. Sie ist durch einen Sicherheitsbeauftragten auszufuhren. Es wird eine induktive Definition der Sicherheit zugrundegelegt: Das betrachtete System ist in einem integeren Zustand, wenn zu einem bestimmten Zeitpunkt die IVPs die Integrität der Objekte festgestellt haben und anschließend nur TPs abgelaufen sind. Das Clark-Wilson-Modell formuliert neun Regeln. Regeln des Typs (C...) beziehen sich auf externe Anforderungen z.B. an den Sicherheitsbeauftragten, Regeln des Typs (E...) müssen vom System selbst erzwungen werden.

117

Aktionen

Zertifizierung

Sicherer Zustand

Regeln

3. Sicherheitsfunktionen

Regeln des Clark-Wilson Modells

(El) (E2)

(E3) (E4) (Cl) (C2)

(C3) (C4)

(C5)

Innerhalb des Systems ist zu gewährleisten, daß nur die in (C2) definierten und im System gespeicherten Relationen zur Anwendung kommen. Im System muß eine Liste gespeichert sein, aus der hervorgeht, welches Subjekt welche TP auf welche Objekte anwenden darf. Nur hiermit im Einklang stehende Aktionen dürfen ausgeführt werden. Jedes Subjekt, das eine TP ausfuhren möchte, muß zuvor identifiziert und authentisiert sein. Nur derjenige, der die Funktion der Zertifizierung übernimmt, darf die Zugriffslisten (speziell im Hinblick auf TPs) ändern. Die IVPs müssen sicher feststellen können, ob alle Objekte in einem gültigen Zustand sind. Der Sicherheitsbeauftragte legt einen Satz von Relationen fest, die beschreiben, welche TPs auf welche Objekte zugreifen dürfen. Die TPs sind dahingehend zu zertifizieren, daß sie die Integrität der Objekte, auf die sie zugreifen dürfen, erhalten. Die Liste aus (E2) muß zertifiziert sein. Es muß ein Objekt für die fortlaufende Protokollierung aller Transaktionen existieren. Die TPs müssen dahingehend zertifiziert sein, daß sie alle Aktionen dort so aufzeichnen, daß sie anschließend wieder rückgängig gemacht, d.h. die Objekte in den vorherigen Zustand versetzt werden können. Können Objekte, die im System nicht von der Integritätspolitik erfaßt werden, als Eingabedaten für TPs verwendet werden, so muß gesichert sein (Zertifizierung!), daß die betreffende TP nur zulässige Verarbeitungen ausfuhrt oder die Objekte ggf. zurückweist.

3.2.9 Rot-Schwarz-Trennung Hierbei handelt es sich um ein Modell, das bei der Konzeption von Kryptosystemen zugrundegelegt wird: Geheimzuhaltende Informationen werden als rot bezeichnet. Werden die entsprechenden Daten verschlüsselt, ist das Ergebnis bei Unkenntnis des Schlüssels nicht mehr lesbar; verschlüsselte Daten werden als schwarz bezeichnet. Entschlüsseln von schwarzen Daten liefert rote Daten. Bei der Datenverarbeitung bzw. -Übertragung werden Speicherbereiche oder Leitungen, die rote Daten enthalten ebenfalls als rot bezeichnet; Speicherbereiche oder Leitungen, die ausschließlich schwarze Daten führen, werden schwarz genannt.

118

3.2 Zugriffsschutzmodelle

Ziel der Sicherheitspolitik ist es zu verhindern, daß "rote" Daten die Grenze zum "schwarzen" Bereich überschreiten. Die einzig zulässigen Möglichkeiten von Datenfluß sind durch folgende Beziehungen gegeben: 1. Verschlüsseln von (rot) liefert (schwarz). 2. Entschlüsseln von (schwarz) liefert (rot). 3.2.10 Domänen und Capabilities Die in den voranstehenden Abschnitten diskutierten Modelle der Zugriffskontrolle sind fast alle Spezialfälle von sogenannten Domänen {Domains): Gehen wir aus von dem üblichen Subjekt-Objekt-Modell. Es sei M eine (beliebige) Menge von Objekten; für jedes Objekt O aus M sei r(O) die Liste der erlaubten Operationen auf O. Als Domäne bezeichnet man die sich ergebende Liste von Paaren der Form ( O, r(O)). Beispiel: M bestehe aus zwei Objekten O und P. Die für O zulässigen Operationen seien R(ead) und W(rite) (also r(O) = {R,W}); für P sei Lesen und Anhängen (Append) erlaubt (also r(P)={R,A}). Die hier betrachtete Domäne D ist die Liste (O, {R,W}), (P, {R,A}). Hat man nun ein IT-System mit vielen Domänen, wobei Objekte durchaus mehreren Domänen gleichzeitig angehören können, so ergibt sich eine Tabelle, die Ähnlichkeit mit der Zugriffskontrollmatrix hat - aber keine Subjekte enthält. Jede Zeile steht für eine Domäne. Die Spalten enthalten alle betrachteten Objekte. Ist ein Objekt Bestandteil einer Domäne, so sind im Kreuzungspunkt die zulässigen Operationen eingetragen. Beispiel:

Domain

Objekt 0

Domäne

Ol

02

Dl

R,W

R,A

-

02

-

R

X,R

-

D3

-

-

R

-

Q3

4

-

Tabelle 3-5: Tabelle von Domänen und Capabilities Jede Zeile in dieser Tabelle heißt eine Capability List der betreffenden Domäne. Jedes Objekt kann in mehreren Domänen und somit in mehreren Tabellenzeilen auftauchen (z.B. O2 in D j und D2); jede dieser Zeilen wird eine Capability für das betreffende Objekt genannt. Betrachten wir nun ein Subjekt S, das Zugriff auf bestimmte Objekte O, P, Q besitzt, und zwar nach folgender Spezifikation: O darf gelesen, P gelesen und geschrieben, Q ausgeführt werden. Dann ergibt sich eine Domäne durch die Liste (O, {R}), (P, {R,W}), (Q, {X}). Somit ist jedem Subjekt eine spezielle Domäne zugeordnet. Definiert man Domänen ausschließlich über dieses Verfahren, so ist die obige Tabelle nichts anderes als die Zugriffskontrollmatrix bei

119

Capability

3. Sicherheitsfunktionen

einer DAC. Der Leser möge als Beispiel auch die anderen Zugriffskontrollmodelle auf Domänen abbilden!

3.3 Funktionalitätsklassen Funktionalität

Funktionalitätsklasse

Sicherheitskriterien

Als (Sicherheits-^Funktionalität bezeichnen wir hier die Gesamtheit aller Sicherheitsfunktionen eines IT-Systems. In der Regel wird sich die Funktionalität (Functionality) eines Systems aus den in 3.1 behandelten Sicherheitsfiinktionen mit unterschiedlicher Ausprägung und Differenzierung zusammensetzen. Für Anwendungen typische Sicherheitsfunktionen oder in bestimmten Architekturen übliche Sicherheitsfunktionen faßt man zur Vereinfachung der Diskussion in Funktionalitätsklassen (Functionality Classes) zusammen. Die folgenden Beispiele zeigen, wie Sicherheitsfunktionen untereinander inhaltliche Abhängigkeiten besitzen: 1) Will ein Subjekt Zugriffsrechte ausüben, so ist eine Zugriffskontrolle erst sinnvoll, wenn das Subjekt sich identifiziert und authentisiert hat. Eine Funktionalitätsklasse einfachster Art für den Bereich der Betriebssysteme - die Klasse C1 - setzt sich deshalb aus den Sicherheitsfunktionen Identifizierung und Authentisierung und Zugriffskontrolle zusammen. 2) Eine Beweissicherung kann ihrem Namen nur dann alle Ehre machen, wenn bei den Aufzeichnungen die Identität der Subjekte nicht in Zweifel zu ziehen ist. Eine nicht vorhandene Wiederaufbereitung macht eine Zugriffskontrolle oft obsolet, da vertrauliche Informationen am Betriebssystem "vorbeilaufen" können. Eine Funktionalitätsklasse umfassender Art für den Bereich der Betriebssysteme - die Klasse C2 - setzt sich deshalb aus den Sicherheitsfunktionen Identifizierung und Authentisierung, Zugriffskontrolle, Beweissicherung und Wiederaufbereitung zusammen. Die Zuordnung verschiedener Sicherheitsfunktionen zueinander und ihre inneren Abhängigkeiten sind in den bekannten Sicherheitskriterien (Orange Book (TCSEC85), IT-Sicherheitskriterien (ITSK89)) oft implizit vorgegeben. Erst in den kanadischen Kriterien (CTCPEC92) und in den ITSEC (ITSEC91) werden unter dem Stichwort Assurance of Effectiveness Anforderungen an eine sinnvolle Kombination von Sicherheitsfunktionen explizit gestellt. Generell gilt, daß Funktionalitätsklassen immer nur Beispiele für mögliche Anwendungsfälle sein können. Dabei werden manche Klassen mit anderen gar nicht vergleichbar sein. Es mag im Laufe der Zeit sogar günstig erscheinen, neue Klassen zu definieren - selbst dann, wenn diese Klassen nur neue Kombinationen von Sicherheitsfunktionen anderer Klasse beinhalten. Insofern sind Funktionalitätsklassen nicht als statisch zu betrachten.

120

3.3 Funktionalitätsklassen

Die nachfolgenden Abschnitte sollen einen Überblick über Funktionalitätsklassen und ihre Ziele geben, soweit diese in Sicherheitskriterien definiert sind. 3.3.1 Das Orange Book Das amerikanische Orange Book (TCSEC) legt vier Gruppen D, C, B, A fest, wobei C und B in einzelne Klassen unterteilt sind. D ist die Gruppe mit der niedrigsten, A die mit der höchsten Funktionalität. Gruppe D

Gruppe C

Gruppe B

Klasse

Klassen

Klassen

D

C1

B1

I

C2

Discretionary

steigende

B2

Gruppe A Klasse B3

A1

Access

Control

Mandatory

Access

Control

Vertrauenswürdigkeit

Abbildung 3-5: Funktionalitätsklassen im Orange Book Jede Klasse enthält gewisse Sicherheitsfunktionen. Die Klassen bauen hierarchisch aufeinander auf, d.h. B1 bspw. umfaßt alle Forderungen der Klasse C2, stellt aber bei den gleichen Funktionen zum Teil höhere Anforderungen, fügt prinzipiell neue Forderungen hinzu. In die Klasse D fallen alle die Systeme, die keine der höheren Klassen C, B oder A genügen. Ab der Klasse C1 aufwärts werden alle sicherheitsrelevanten Funktionen eines IT-Systems zur Trusted Computing Base (TCB) zusammengefaßt. Alles, was außerhalb der TCB liegt, ist per definitionem nicht sicherheitsrelevant. In den Klassen C1 und C2 ist die Discretionary Access Control (DAC) Basis der Sicherheitspolitik. Hierbei sind die Ressourcen - im wesentlichen Dateien jeweils einem bestimmten Eigentümer zugeordnet. Dieser kann für sein Eigentum über die Vergabe und den Entzug von Zugriffsrechten selbst entscheiden. Die zusammenfassende Beschreibung der Klassen C1 und C2 im Orange Book lautet: "Class (CI): Discretionary Security Protection. The Trusted Computing Base (TCB) of a class (CI) system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep other users from accidentally reading or destroying their data. The class (CI) environment is ex-

121

Gruppe D Gruppe C

CI

3. Sicherheitsfunktionen

pected to be one of cooperating users processing data at the same level(s) of sensitivity. Class (C2): Controlled Access Protection. Systems in this class enforce a more finely grained discretionary access control than (CI) systems, making users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation." Gruppe B

Referenz-Monitor

B1

B2

B3

In den B-Klassen kommt eine andere Art des Zugriffsschutzes hinzu, die bereits behandelte Mandatory Access Control (MAC), im deutschen vorgeschriebene (oder globale, regelbasierte) Zugriffskontrolle. Hiermit wird das Handling von eingestuften Objekten beschrieben. Jedem Objekt wird eine Einstufung zugeteilt, jedem Subjekt eine Ermächtigung für bestimmte Einstufungen gegeben. Hieran sind Regeln fur die Zugriffe geknüpft (vgl. Abschnitt 3.2.4). Ein weiterer zentraler Begriff des Orange Book ist der Referenz-Monitor. Er ist die (theoretische) Instanz in einer TCB, die jede Aktion eines Subjekts bzgl. eines Objektes auf Zulässigkeit überprüft und damit die Zugriffskontrolle realisiert. Die folgenden Auszüge aus dem Orange Book beschreiben die B-Klassen: "Class (Bl): Labeled Security Protection. Class (Bl) systems require all the features required for class (C2). In addition, an informal statement of the security policy model, data labeling, and mandatory access control over named subjects and objects must be present. The capability must exist for accurately labeling exported information. Any flaws identified by testing must be removed. Class (B2): Structured Protection. In class (B2) systems, the TCB is based on a clearly defined and documented formal security policy model that requires the discretionary and mandatory access control enforcement found in class (Bl) systems be extended to all subjects and objects in the ADP system. In addition, covert channels are addressed. The TCB must be carefully structured into protection-critical and non-protection-critical elements. The TCB interface is well-defined and the TCB design and implementation enable it to be subjected to more thorough testing and more complete review. Authentication mechanisms are strengthened, trusted facility management is provided in the form of support for system administrator and operator functions, and stringent configuration management controls are imposed. The system is relatively resistant to penetration. Class (B3): Security Domains. The class (B3) TCB must satisfy the reference monitor requirements that it mediate all accesses of subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this end, the TCB is structured to exclude code not essential to security policy enforcement, with significant system engineering during TCB design and implementation directed toward minimizing its complexity. A

122

3.3 Funktionalitätsklassen

security administrator is supported, audit mechanisms are expanded to signal security-relevant events, and system recovery procedures are required. The system is highly resistant to penetration." Um einer Begriffsverwirrung vorzubeugen: Der unter B3 auftauchende Begriff Security Domain - im Deutschen gelegentlich Schutzdomäne genannt - ist nicht identisch mit dem Begriff Domain aus Abschnitt 3.2.10. Das Orange Book meint die Compartments; diese sind natürlich ein Spezialfall der allgemeinen Domänen aus 3.2.10. Die Klasse AI unterscheidet sich funktionell nicht von der Klasse B3. Es werden formale Techniken der Spezifikation und Verifikation beim Entwurf des Systems gefordert und somit im Vergleich zu B3 lediglich die Korrektheitsanforderungen erhöht.

Gruppe A

3.3.2 Die deutschen IT-Sicherheitskriterien Bei den deutschen IT-Sicherheitskriterien (ITSK89) wurden die MAC- und DAC-Philosophien des Orange Book als Option miteinbezogen, dennoch wird aber in den Kriterien selbst keine Sicherheitspolitik fest vorgegeben. Darüber hinaus wurde der Nachteil der beschränkten Klassen des Orange Book beseitigt. Viele moderne Anwendungsbereiche wurden dort nicht erfaßt. Bei bestimmten Systemen liegt z.B. der Schwerpunkt auf der Verfügbarkeit (z.B. Prozeßrechner), die Gewährleistung von Vertraulichkeit kann zweitrangig sein; Integritätsforderungen sind bei Datenbanken ein zentrales Problem. In den deutschen IT-Sicherheitskriterien sind beispielhaft 10 Funktionalitätsklassen definiert: Die Klassen Fl bis F5 stellen funktionelle Anforderungen an Betriebssysteme. Die Klassen sind aufsteigend geordnet: Fl «

F2 «

F3 «

F4 «

F5

Sie sind vermöge der in Tabelle 3-6 dargestellten Zuordnung den Klassen des Orange Book angepaßt, weichen aber in einigen Details von diesen geringfügig ab. IT-Sicherheitskriterien

Orange Book

FI

C1

F2

C2

F3

B1

F4

B2

F5

B3/A1

Tabelle 3-6: Zuordnung von F-Klassen

123

Betriebssysteme

3. Sicherheitsfunktionen

Erfüllt ein IT-System die Forderungen einer Klasse Fl bis F5 der deutschen ITSicherheitskriterien, so sind auch die Forderungen der laut Tabelle zugeordneten Klasse des Orange Book erfüllt. Die Umkehrung gilt aber nicht! Bei der Terminologie gibt es ebenfalls Unterschiede; so wird z.B. die Zugriffskontrolle (Access Control) in den IT-Sicherheitskriterien in zwei Grundfunktionen aufgespalten, nämlich die Rechteverwaltung und die Rechteprüfung. Die Begriffe sind selbsterklärend. Die Anforderungen der Klasse Fl in den IT-Sicherheitskriterien lauten8: Fl

"Identifikation und Authentisierung: Das System muß Benutzer identifizieren und authentisieren. Diese Identifikation und Authentisierung muß vor jeder anderen Interaktion des Systems mit dem Benutzer erfolgt sein. Nur nach einer erfolgreichen Identifikation und Authentisierung dürfen andere Interaktionen möglich sein. Die Authentisierungsinformationen müssen so gespeichert sein, daß nur autorisierte Benutzer Zugriff dazu besitzen. Rechteverwaltung: Das System muß Zugriffsrechte zwischen Benutzern und/oder Benutzergruppen und Objekten, die der Rechteverwaltung unterliegen, kennen und verwalten. Dabei muß es möglich sein, Benutzern bzw. Benutzergruppen den Zugriff zu einem Objekt ganz zu verwehren. Vergabe und Entzug von Zugriffsrechten zu einem Objekt darf nur durch autorisierte Benutzer möglich sein. Rechteprüfung: Das System muß bei jedem Zugriffsversuch von Benutzern bzw. Benutzergruppen zu den der Rechteverwaltung unterliegenden Objekten die Berechtigung überprüfen. Unberechtigte Zugriffsversuche müssen abgewiesen werden."

F2

In der Klasse F2 ist die Rechteverwaltung etwas detaillierter. Es werden unterschiedliche Zugriffsarten (Lesen/Schreiben), Vergabe der Rechte an Objekten auf der Basis einzelner Benutzer und die kontrollierte Weitergabe von Rechten behandelt. Zusätzlich werden die neuen Sicherheitsfunktionen Beweissicherung und Wiederaufbereitung eingeführt. Im folgenden deuten drei Punkte ... an, daß Texte der vorhergehenden Klasse ausgelassen wurden. "Identifikation und Authentisierung:...Bei jeder durchgeführten Interaktion muß das System die Identität des Benutzers feststellen können. Rechteverwaltung:...Zugriff zu einem Objekt ganz zu verwehren sowie den Zugriff auf einen nicht-modifizierenden Zugriff zu beschränken. Außerdem muß es möglich sein, für jeden Benutzer separat die Zugriffsrechte zu einem Objekt festzulegen.... Die Weitergabe von Zugriffsrechten muß kontrollier-

8

In (ITSK.89) wird anstelle von Identifizierung

124

der Begriff Identifikation

gebracht.

3.3 Funktionalitätsklassen

bar sein. Ebenso darf das Einbringen neuer Benutzer sowie das Löschen bzw. Sperren von Benutzern nur durch autorisierte Benutzer möglich sein. Beweissicherung: Das System muß eine Protokollierungskomponente enthalten, die in der Lage ist, folgende Ereignisse mit folgenden Daten zu protokollieren: Benutzung des Identifikations- und Authentisierungsmechanismus (Daten: Datum; Uhrzeit; Benutzer-ID, die angegeben wurde; Kennung des Gerätes, an dem der Identifikations- und Authentisierungsmechanismus benutzt wurde (z.B. Terminal-ID); Erfolg bzw. Mißerfolg des Versuches). Zugriff zu einem der Rechteverwaltung unterliegenden Objekt (Daten: Datum; Uhrzeit; Benutzer-ID; Name des Objektes; Art des Zugriffsversuches; Erfolg bzw. Mißerfolg des Versuches). Anlegen bzw. Löschen eines der Rechteverwaltung unterliegenden Objektes (Daten: Datum; Uhrzeit; Benutzer-ID; Name des Objektes; Art der Aktion). Aktionen von Benutzern bzw. Rollen mit besonderen Rechten, die die Sicherheit des Systems betreffen (Daten: Datum; Uhrzeit; Benutzer-ID; Art der Aktion; Name des Objektes, auf das sich die Aktion bezog (Solche Aktionen sind z. B. Einbringen oder Löschen (Sperren) von Benutzern; Einbringen bzw. Entfernen von Datenträgern; Starten bzw. Stoppen des Systems)). Der Zugriff zu den Protokollinformationen darf nur dazu autorisierten Benutzern möglich sein. Es muß möglich sein, die Protokollierung auf einen oder mehrere beliebig wählbare Benutzer zu beschränken. Es müssen Auswerte- und Verwaltungsprozeduren für die Protokolldaten vorhanden und dokumentiert sein. Der Aufbau der Protokollsätze muß vollständig beschrieben sein. Wiederaufbereitung: Alle Speicherobjekte müssen vor einer Wiederverwendung durch andere Benutzer so aufbereitet werden, daß keine Rückschlüsse auf ihren früheren Inhalt möglich sind." Ab der Klasse F3 werden Attribute eingeführt und in den Forderungen berücksichtigt. Die MAC muß als Spezialfall realisiert werden können. Der diesbezügliche Text der Rechteverwaltung lautet: "Zusätzlich muß das System alle Subjekte und Speicherobjekte, die seiner Kontrolle unterliegen, mit Attributen versehen (dazu gehören z. B. Prozesse, Dateien, Speichersegmente, Geräte). Der Wert dieser Attribute muß dabei als Grundlage für regelbasierte ("mandatory") Zugriffsrechte dienen. Diese Regeln müssen festlegen, bei welchen Kombinationen von Attributwerten von Subjekt und Objekt ein Subjekt ein bestimmtes Zugriffsrecht zu diesem Objekt besitzen darf.

125

F3

3. Sicherheitsfunktionen

Beim Export eines attributierten Objektes müssen auch die Attribute so mit exportiert werden, daß der Empfänger deren Wert eindeutig rekonstruieren kann. Die regelbasierten Zugriffsrechte müssen so gestaltet sein, daß sich folgender Spezialfall realisieren läßt: Das Attribut besteht aus zwei Teilen. Ein Teil besitzt einen hierarchisch geordneten Wertebereich, der andere Teil ist nicht hierarchisch. Folgende Regeln müssen realisierbar sein: Lesender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wenn der Wert des hierarchischen Attributteils beim Subjekt größer oder gleich dem Wert des hierarchischen Attributteils beim Objekt ist, und der nicht-hierarchische Attributteil des Subjektes eine Obermenge des nicht-hierarchischen Attributteils des Objektes ist. Schreibender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wenn der Wert des hierarchischen Attributteils beim Subjekt kleiner oder gleich dem Wert des hierarchischen Attributteils beim Objekt ist, und der nichthierarchische Attributteil des Subjektes eine Teilmenge des nicht-hierarchischen Attributteils des Objektes ist. Der Benutzer darf nur Subjekte erzeugen, deren Wert des hierarchischen Attributteils kleiner oder gleich dem bei der Identifikation angegebenen Wert ist und dessen nicht-hierarchischer Attributteil eine Teilmenge des bei der Identifikation angegebenen ist. Beim Import von nicht-attributierten Daten müssen deren Attribute auf Anforderung des Systems durch einen autorisierten Benutzer festgelegt werden. Exportkanäle müssen entweder als einstufig oder als mehrstufig kennzeichenbar sein. Über als einstufig gekennzeichnete Kanäle dürfen nur Informationen gesendet oder empfangen werden, deren Attribut einen fest vorgegebenen Wert besitzt. In diesem Fall braucht der Attributwert nicht mit übertragen werden, da er implizit durch die Einstufung des Kanals festgelegt ist. Voraussetzung ist jedoch, daß die Einstufung des Kanals durch einen autorisierten Benutzer in einer nicht täuschbaren Weise festgelegt worden ist. Bei mehrstufigen Kanälen muß durch das Übertragungsprotokoll sichergestellt sein, daß die Empfängerseite alle Attributwerte vollständig rekonstruieren und in eindeutiger Weise der übertragenen Information zuordnen kann. Jede Änderung der Einordnung eines Kanals darf nur explizit durch autorisierte Benutzer erfolgen. Jede solche Änderung muß protokollierbar sein. Das System muß menschenlesbare Ausgaben mit Attributwerten kennzeichnen. Die Werte der Attribute leiten sich aus den im System formulierten Regeln ab. Die Art und der Ort der Darstellung der Attribute muß dabei von einem speziell autorisierten Benutzer festlegbar sein."

126

3.3 Funktionalitätsklassen

Der folgende Text für die Klasse F4 berücksichtigt nur wesentliche Änderungen (vertrauenswürdiger Pfad, Rollen, Protokollierung verdeckter Kanäle) gegenüber F3:

F4

"Identifikation und Authentisierung:...Identifikation und Authentisierung müssen über einen vertrauenswürdigen Pfad zwischen Benutzer und System abgewickelt werden, initiiert durch den Benutzer... Rechteverwaltung:...Zugriffsrechte müssen zu Rollen gruppierbar sein. Minimal müssen die Rollen von Operator und System-Administrator definierbar sein... ...Für mehrstufige Kanäle muß es möglich sein, den maximalen und minimalen Attributwert anzugeben, den die übertragene Information besitzen darf... ...Jede Änderung der Attributwerte aller Subjekte, die für einen Benutzer in einer laufenden interaktiven Sitzung aktiv sind, muß diesem Benutzer sofort angezeigt werden. Der Benutzer muß jederzeit die Möglichkeit haben, sich die Attributwerte aller Subjekte, die für diesen Benutzer in einer laufenden interaktiven Sitzung aktiv sind, anzeigen zu lassen... Beweissicherung:...Außerdem muß das System die Möglichkeit besitzen, bekannte Ereignisse zu protokollieren, die zu einem unerlaubten Informationsfluß durch Ausnutzung verdeckter Speicherkanäle führen können..." Unter Identifikation und Authentisierung wird die Existenz eines vertrauenswürdigen Pfads gefordert. Hiermit soll ausgeschlossen werden, daß z.B. durch Spoofing-Programme (vgl. Kapitel 1) ein Login vorgetäuscht wird. Der Benutzer soll sicher sein können, daß die für das Login zuständige Systeminstanz nicht täuschbar ist.

Vertrauenswürdiger

Die folgenden Auszüge aus dem Text der Klasse F5 enthalten nur die wesentlichen Änderungen (zusätzliche Authentisierung, weitere Rollen, ACL als Mechanismus, Online Sicherheitsalarm) gegenüber F4:

F5

"Identifikation und Authentisierung:..An den Sicherheitsanforderungen können neben dem Login weitere Aktionen festgelegt sein, vor deren Ausführung eine zusätzliche Identifikation und Authentisierung erforderlich ist... Rechteverwaltung:...Die Rollen von Operator, System-Verwalter und Sicherheitsverantwortlichem müssen klar getrennt sein... ...Es muß möglich sein, für jedes Objekt, welches der Kontrolle der diskreten Rechteverwaltung unterliegt, eine Liste von Benutzern sowie eine Liste von Benutzergruppen mit ihren jeweiligen Zugriffsrechten zu diesem Objekt anzugeben. Außerdem muß es möglich sein, zu jedem solchen Objekt eine Liste von Benutzern sowie eine Liste von Benutzergruppen anzugeben, die kein Zugriffsrecht zu diesem Objekt besitzen sollen...

127

Pfad

3. Sicherheitsfunktionen

Beweissicherung-....Ferner muß ein Mechanismus existieren, der das Auftreten von Ereignissen überwacht, die entweder besonders sicherheitskritisch sind bzw. durch ihr häufiges Auftreten zu einer kritischen Bedrohung der Sicherheit des Systems werden können. Dieser Mechanismus muß in der Lage sein, sofort einen speziellen Benutzer bzw. Benutzer mit einer speziellen Rolle über das Eintreten solcher Ereignisse zu informieren. Der Mechanismus soll auch in der Lage sein, in solchen Fällen selbsttätig Aktionen zu ergreifen, durch die ein weiteres Auftreten solcher Ereignisse unterbunden wird..." Anforderung an Integrität

F6

Typ-Konzept

Datenbank-Systeme und Expertensysteme sind typische Anwendungsbeispiele Systeme mit hohen Integritätsanforderungen. Aber auch in normalen Betriebssystemen gibt es Bibliotheken, die besonders gegenüber Manipulationen geschützt werden müssen, etwa die Bibliothek der Lademodule zur Ausführung von System-Kommandos. Für Anforderungen an die Integrität existiert im Orange Book keine eigene Klasse. Vor einigen Jahren ist aber eine Database Interpretation (TDI91) des Orange Book erschienen. Die Klasse F6 der IT-Sicherheitskriterien ist ein erster Schritt zur Behandlung des Integritätsproblems. Ihr liegen im wesentlichen die Forderung der Klasse F2 bzw. C2 (Orange Book) zugrunde, d.h. sie enthält die Sicherheitsfunktionen Identifikation/Authentisierung, Rechteverwaltung und Rechteprüfung (= Zugriffskontrolle) und die Beweissicherung. Der neue Aspekt ist das Typ-Konzept. Objekte werden zu bestimmten Typen zusammengefaßt - ähnlich wie bspw. Subjekte zu Gruppen. Beispiele für Typen von Objekten sind die zuvor erwähnten Lademodule, die Abfrageprozeduren zu einer Datenbank. Neue Typen zu definieren, alte zu ändern usw. ist in diesem Konzept eine privilegierte Aktion, die einer Autorisierung bedarf. Es bestehen Rechtebeziehungen zwischen Subjekten und Typen, die nur von speziell autorisierten Benutzern über vertrauenswürdige Pfade gepflegt werden dürfen. Es soll verhindert werden, daß der Informationsaustausch zwischen Benutzer und System z.B. von trojanischen Pferden nur vorgetäuscht wird. Die Anforderungen der Klasse F6 lauten: "Identifikation undAuthentisierung: (wie F2) Rechteverwaltung: Das System muß Zugriffsrechte zwischen Benutzern, Rollen und Prozessen zu speziellen Objekten kennen und verwalten. Rollen sind dabei als Benutzer mit speziellen Attributen zu verstehen. Dabei muß es möglich sein, den Zugriff von Benutzern auf diese Objekte so einzuschränken, daß dieser Zugriff nur über speziell festgelegte Prozesse möglich ist. Ferner muß es möglich sein, Objekte einem vordefinierten Typ zuzuordnen. Es muß möglich sein, für jeden Typ von Objekten festzulegen, welche Benutzer, Rollen oder Prozesse Zugriff einer bestimmten Art zu diesen Objekten besitzen können. Dadurch soll es möglich sein, den Zugriff von

128

3.3 Funktionalitätsklassen

Benutzern auf Objekte eines bestimmten Typs so einzuschränken, daß dieser Zugriff nur über festgelegte Prozesse möglich ist. Nur speziell autorisierten Benutzern darf es möglich sein, neue Typen zu definieren bzw. Zugriffsrechte zu Typen zu vergeben oder zu entziehen. Diese Aktionen müssen explizit von diesem Benutzer initiiert werden. Alle Kommunikationen zwischen dem System und dem Benutzer müssen bei diesen Aktionen über einen vertrauenswürdigen Pfad ablaufen. Dadurch soll verhindert werden, daß diese Aktionen durch trojanische Pferde mißbraucht werden können. Folgende Zugriffsrechte müssen mindestens existieren: Lesen, Schreiben, Anfügen, Löschen, Umbenennen (für Objekte); Ausführen, Löschen, Umbenennen (für ausführbare Objekte); Anlegen von Objekten eines bestimmten Typs, Löschen von Objekten eines bestimmten Typs. Rechteprüfung\ (wie F2) Beweissicherung: (zusätzlich zu F2:) Anlegen bzw. Löschen von Typen (Daten: Datum; Uhrzeit; Benutzer-ID; Art der Aktion; Name des Typs). Vergabe eines Typs für ein Objekt (Daten: Datum; Uhrzeit; Benutzer-ID; Name des Objektes; Name des Typs). Vergabe oder Entzug von Zugriffsrechten zu einem Objekt bzw. zu einem Objekttyp (Daten: Datum; Uhrzeit; Benutzer-ID; Art der Aktion; Art des Zugriffsrechtes; Name des Subjektes; Name des Objektes bzw. Name des Objekttyps)." Rechner zur Kontrolle und Steuerung von Prozessen (z.B. in der Produktion, Flugüberwachung) sind klassische Beispiele für Systeme mit hohen Verfügbarkeitsanforderungen. Im Orange Book existiert keine Klasse für diesen Anwendungsfall. In der Klasse F7 der IT-Sicherheitskriterien werden Fehlerüberbrückung für wichtige Hardware-Komponenten und Gewährleistung der Funktionalität (mit maximalen Reaktionszeiten bei bestimmten Aktionen) gefordert. Der Text lautet: "Fehlerüberbrückung: Das System muß in der Lage sein, den Ausfall bestimmter einzelner Hardwarekomponenten (z.B. einer Platte oder eines einzelnen Prozessors in einem Mehrprozessorsystem) so zu überbrücken, daß alle fortlaufend benötigten Funktionen auch in dem Restsystem kontinuierlich zur Verfügung stehen. Nach Reparatur der ausgefallenen Komponente muß diese so wieder in das System integriert werden können, daß eine kontinuierliche Aufrechterhaltung der fortlaufend benötigten Funktionen gegeben ist. Nach der Integration muß das System wieder den ursprünglichen Grad der Ausfallsicherheit erreicht haben. Für die Dauer eines solchen Reintegrationsprozesses müssen Maximalzeiten angegeben werden.

129

Verfügbarkeit

F7

3. Sicherheitsfunktionen

Gewährleistung der Funktionalität: Das System muß in der Lage sein, unabhängig von seiner momentanen Belastung für bestimmte festgelegte Aktionen eine maximale Reaktionszeit zu garantieren. Außerdem muß für festgelegte Aktionen die Verklemmungsfreiheit des Systems gewährleistet sein." Datenübertragung und Netzwerke

Für die Datenübertragung und Vernetzung von Systemen beinhalten die ITSicherheitskriterien drei Klassen F8 (Integrität), F9 (Vertraulichkeit) und F10

F8

(Zusammenfassung). Im Orange Book existieren keine äquivalenten Klassen. Eine Interpretation der Klassen des Orange Book für Netzwerke wird aber im sogenannten TNI - Trusted Network Interpretation (TNI87) behandelt. Die Klasse F8 fordert die Sicherheitsfunktionen Identifikation und Authentisierung, und zwar für beide Partner einer Kommunikation, Übertragungssicherung (Ausschluß der Manipulationen an Adreß- und Nutzdaten, Ausschluß der Wiedereinspielung von Daten) und die Beweissicherung. "Identifikation und Authentisierung:...(wie F2)...Vor dem Beginn einer Datenübertragung muß die Gegenseite (Rechner, Prozeß oder Benutzer) identifiziert und authentisiert werden. Nur nach erfolgreicher Identifikation und Authentisierung darf eine Übertragung von Nutzdaten erfolgen. Beim Empfang von Daten muß deren Sender identifiziert und authentisiert werden können. Alle Authentisierungsinformationen müssen vor unbefugtem Zugriff und vor Fälschung geschützt sein. Übertragungssicherung: Bei der Datenübertragung müssen Methoden zur Fehlererkennung und Fehlerkorrektur eingesetzt werden. Diese Verfahren müssen so gestaltet sein, daß auch absichtliche Manipulationen an den Adreßfeldern und den Nutzdaten erkannt werden können. Auch darf die bloße Kenntnis der bei den Verfahren eingesetzten Algorithmen ohne spezielle Zusatzkenntnisse nicht dazu fuhren, daß nicht erkannte Manipulationen an den oben genannten Daten durchgeführt werden können. Die dazu benötigten Zusatzkenntnisse müssen so geschützt sein, daß höchstens einige wenige speziell autorisierte Benutzer Zugang dazu besitzen. Außerdem müssen Verfahren eingesetzt werden, die auch ein unbefugtes Wiedereinspielen von alten Datenströmen sicher als Fehler erkennen. Beweissicherung: Das System muß eine Protokollierungskomponente enthalten, die in der Lage ist, folgende Ereignisse mit folgenden Daten zu protokollieren: Benutzung des Identifikations- und Authentisierungsmechanismus (Daten: Datum; Uhrzeit; Initiator der Identifikation und Authentisierung; Name des zu identifizierenden Subjektes; Erfolg oder Mißerfolg der Aktion). Erkannte Fehler bei der Datenübertragung (Daten: Datum; Uhrzeit; Partner bei der Datenübertragung; Art des Fehlers; Erfolg oder Mißerfolg beim Korrekturversuch).

130

3.3 Funktionalitätsklassen

Verbindungsaufbau zur Datenübertragung (Daten: Datum; Uhrzeit; Benutzer-ID des Initiators; Name des Subjektes (Rechner, Prozeß oder Benutzer) auf der Empfängerseite; Parameter des Verbindungsaufbaus (falls diese variabel sind)." In der Klasse F9 wird die Verschlüsselung der Nutzdaten gefordert. F10 ist eine Zusammenfassung der Forderungen in F8 und F9 (mit kleinen Ergänzungen). Der folgende Text beschreibt F10: "Identifikation und Authentisierung\...{vi'\t F8) Übertragungssicherung: Das System bietet die Möglichkeit einer Ende-zuEnde Verschlüsselung, die eine Geheimhaltung des Empfängers auf weiten Teilen des Übertragungsweges umfaßt. Ebenso ist die Geheimhaltung des Verkehrsaufkommens auf speziellen Datenübertragungsleitungen gegeben. Das System muß so gestaltet sein, daß unbefugte Manipulationen von Nutzdaten und Protokolldaten sowie das unbefugte Wiedereinspielen von alten Daten sicher als Fehler erkannt werden. Alle Parameter, die zu einer unbefugten Entschlüsselung benutzt werden können, sind so zu schützen, daß nur solche Personen Zugang zu diesen Daten besitzen, die diesen Zugang zur Erfüllung ihrer Aufgaben unbedingt benötigen. Beweissicherung:...(im wesentlichen wie bei F8)" 3.3.3 Die europäischen ITSEC Bezüglich der Funktionalitätsklassen ist die Systematik in den ITSEC die gleiche wie in den deutschen IT-Sicherheitskriterien. Die Funktionalitätsklassen wurden aber nach der Orange Book Terminologie bezeichnet: F-Cl

«

F-C2 «

F-Bl

«

F-B2 «

F-B3

F2

F3

«

F4

F5.

entspricht Fl

«

«

«

Die Bezeichnungen und Zuordnungen der übrigen Klassen sind: F-IN F-AV F-DI F-DC F-DX

= = = = =

Integrity Availability Data Integrity Data Confidentiality Data Exchange

= = = = =

F6, F7, F8, F9, F10.

131

F9 und F10

3. Sicherheitsfunktionen

Die Aspekte der Erweiterbarkeit der Klassen und einige andere Formalia sind in den ITSEC allerdings deutlicher formuliert: 1. Statt der vordefinierten Klassen können auch Sicherheitsanforderungen anderer internationaler Standards Verwendung finden. 2. Statt der in 3.1 aufgezählten Sicherheitsfunktionen können im Einzelfall neue Sicherheitsfunktionen festgelegt werden. 3. Statt sich auf vorgegebene Klassen oder Standards zu beziehen, können die individuellen Sicherheitsfunktionen eines Produktes oder Systems als Ziel einer Prüfung zugrundegelegt werden. 4. Zur Beschreibung neuer Funktionen und Klassen wird eine semiformale Sprache - die Claims Language - vorgeschlagen. Die Struktur und der Inhalt der Claims Language wird in einem Anhang der ITSEC beschrieben.

Sicherheitsprofile

3.3.4 Kanadische Kriterien Die kanadischen Kriterien (CTCPEC92) lehnen sich in der Begriffswelt und in der Festlegung einiger Funktionalitätsklassen an das amerikanische Vorbild an. Bezüglich der Funktionalität wurden aber Integritäts- und Verfügbarkeitsforderungen aufgenommen, die im Orange Book nicht enthalten sind. Die Funktionalität ist unterteilt in Criteria, Divisions und Levels. Criteria ist unterteilt nach den Aspekten Vertraulichkeit, Verfügbarkeit, Integrität und Beweissicherung (Accountability). Die Beweissicherung wird hier als eine eigene Funktionalitätengruppe betrachtet (vgl. Tabelle 3-7). Beispiel: Für die Funktionalität Confidentiality - Mandatory (Vertraulichkeit regelbasierte Zugriffskontrolle) gibt es vier verschiedene Levels CMO, CM1, CM2, CM3, CM4. In diesen Levels steigen mit der Nummer die Anforderungen an den jeweiligen Aspekt. Diese einzelnen "Päckchen" können nun zu Sicherheitsprofilen (Security Functionality Profiles) zusammengesetzt werden. Dabei machen natürlich nicht alle Kombinationen Sinn: Eine Validierung von Profilen ist also erforderlich. Einige Sicherheitsprofile sind in den kanadischen Kriterien vordefiniert. Man hat sich dabei unter anderem an die Klassen C2 - B3 des Orange Book angelehnt. Die folgende Tabelle 3-8 gibt einen Überblick über die "Orange Book"Profile.

132

3.3 Funktionalitätsklassen

Criteria

Division

C = Confidentiality

C = Covert Channel

0-3

D = Discretionary

0-4

M = Mandatory

0-4

R = Object Reuse

0- 1

D = Discretionary

0-4

M = Mandatory

0-4

P = Physical

0-4

R = Rollback

0-2

S = Separation of Duties

0-3

T = SelfTesting

0-4

C = Containment

0-3

R = Robustness

0-3

Y = Recovery

0-4

A = Audit

0-4

1 = Identification and Authentication

0-2

T = Trusted Path

0-3

I = Integrity

A = Availability

W = Mio

Level®

T a b e l l e 3 - 7 : F u n k t i o n a l i t ä t in d e n k a n a d i s c h e n Kriterien

TCSEC

Kanadische Kriterien

C2

Profile 1 CD2,CR1; ID1, IS 1, IT1; WA1,WI1

B1

Profile 2 C D 2 . C M 2 , CR1; ID/IM 1, ID1, IT1; WA1, WI1

B2

Profile 3 CC1, CD2, CM3, CR1; ID/IM 1, ID2, IT1; WA1, WI1, WT1

B3

Profile 4 CC1, CD3, CM3, CR1; ID/IM 1, ID2, IT1; WA2, WI1, WT2; AR1

T a b e l l e 3 - 8 : P r o f i l e in d e n k a n a d i s c h e n K r i t e r i e n

9

Level 0 meint dabei immer das Nicht-Erfüllen der Anforderungen.

133

3. Sicherheitsfiinktionen

FC und CC

Profite

Registrierung

3.3.5 Federal Criteria und Common Criteria Die gleiche Verfahrensweise wie in den kanadischen Kriterien - nämlich die Zusammensetzung von Sicherheitsprofilen aus einzelnen "Päckchen" oder "Bausteinen" (Building Blocks) - liegt auch den Federal Criteria (FC92) zugrunde. Die Sicherheitsprofile (Protection Profiles) umfassen aber in den FC (und voraussichtlich in den zukünftigen Common Criteria) nicht nur funktionale, sondern auch Assurance Aspekte (s. Kapitel 4). So werden Sicherheitsprofile zusätzlich Forderungen an Mechanismen, die Einsatzumgebung einschließlich der Bedrohungsszenarien, an Evaluation Assurance und Development Assurance beinhalten. Damit ist ein umfassenderer Ansatz als bei reinen Funktionalitätsklassen gewählt worden. Eine Validierung solcher Sicherheitsprofile muß den Nachweis der Sinnhaftigkeit der Anforderungen erbringen, kann aber weitgehend durch "paper work", also produktunabhängig ausgeführt werden. Die sinnvollen Sicherheitsprofile sollen von noch zu bestimmenden Institutionen registriert werden.

3.4 Praxis der Funktionalitätsklassen

Unix

Tatsächlich erfüllen nur wenige Systeme präzise die Anforderungen abstrakter Funktionalitätsklassen oder Sicherheitsprofile. Ein typisches Beispiel hierfür ist das Betriebssystem Unix. Sein Modell der Zugriffsrechte zwischen Benutzern und Dateien basiert auf dem Owner-GroupWorld - Konzept, d.h. für jede Datei können die Rechte des Besitzers (Owner), die Rechte einer Gruppe von Benutzern und die Rechte aller übrigen (World) festgelegt werden. Als Zugriffsarten werden R(ead), W(rite), E(X)ecute unterschieden. Legt man alle Benutzer, die (irgendein) Zugriffsrecht zu einer Datei besitzen sollen, in eine spezielle Group, alle übrigen demzufolge in World, so lassen sich alle Forderungen der Funktionalitätsklasse Fl 1 0 erfüllen: Fl unterscheidet prinzipiell nur zwischen 'Zugriff ja' und 'Zugriff nein' - unabhängig von der Zugriffsart R, W oder X. Ab der Klasse F2 wird zwischen verschiedenen Zugriffsarten unterschieden. Es muß für jeden Benutzer die genaue Rechtekombination festlegbar sein. Das folgende Beispiel kann aber unter Unix nicht abgebildet werden: Benutzer Rechte

A RWX

B RX

Tabelle 3-9: Rechtebeispiel für Unix 10

Oder C l im Orange Book, F-Cl in den ITSEC.

134

C X

D -

3.4 Praxis der Funktionalitätsklassen

Standard-Unix ist deshalb formal kein F2-System, besitzt also keine vollständige diskrete Zugriffskontrolle. Das Rechtesystem ist aber unstreitig differenzierter als bei einem reinen Cl - System. Im Orange Book ist dagegen die Klasse C2 so formuliert, daß der ProtectionBit-Mechanimus von Unix in Verbindung mit der Multiple Group Feature von Unix - Benutzer können Mitglied in mehr als einer Gruppe sein - als "diskret" angesehen wird: Entsprechende Unix-Systeme erhalten C2-Bewertungen. Kleine Unterschiede in den Kriterienwerken können also schon beachtliche Unterschiede nach sich ziehen.... Ähnlich wie bei Unix verhält es sich bei vielen anderen Systemen: Die Forderungen von Funktionalitätsklassen werden selten präzise erfüllt. Die Funktionalitätsklassen sind deshalb eher als Orientierungshilfe aufzufassen, nach der Systeme entwickelt werden können. Dieser Erfahrung Rechnung tragend ist in den ITSEC der Normierung der Funktionalität keine hohe Bedeutung mehr zugemessen worden. Vielmehr wird so verfahren, daß Hersteller für ihre Systeme die individuelle Funktionalität beschreiben und durch die Evaluierung festgestellt wird, daß diese Funktionalität mit entsprechender Korrektheit und Wirksamkeit implementiert ist. Durch die hohe Differenzierung der Forderungen in Sicherheitsprofilen können einerseits die Eigenschaften von Produkten und Systemen besser erfaßt werden. Die erforderliche Standardisierung solcher Profile wird aber andererseits wegen der Vielzahl von unterschiedlichen Systemen enormen Aufwand erfordern.

135

ITSEC

FC ICC

4. Das Sicherheitsniveau 4.1 Grundsätzliches In erster Näherung ist das Sicherheitsniveau eines IT-Systems dadurch bestimmt, daß es in definiertem Maße Schutz gegenüber Manipulationen und technischem Versagen bietet. Wie jeder aus der Praxis weiß, gibt es unterschiedliche Sicherheitsniveaus: Die Beispiele für Mechanismen der Authentisierung (Kapitel 3) machen dies noch einmal deutlich. Kann das Sicherheitsniveau in irgendeiner Form gemessen werden? Diese Frage ist im Kern das Hauptanliegen von Sicherheitskriterien. Je nach Historie und Typ des Kriterienwerks (vgl. Einleitung und 3.3) geht man allerdings von sehr unterschiedlichen Metriken aus, was wiederum dem Anwender die Vergleichbarkeit erschwert. Deshalb soll in den nächsten Abschnitten auf die Kriterienwerke und die dort definierten Sicherheitsniveaus näher eingegangen werden. Grundsätzlich gilt: Die Wirksamkeit (Effectiveness) gegenüber Manipulationen wird danach beurteilt, welche Ressourcen (Zeit, Kenntnisse, technische Ausstattung, Beteiligung von Personen mit hohen Privilegien) ein Manipulant benötigt, um die Schutzmechanismen des IT-Systems zu durchbrechen. Gibt man sich für die aufgezählten Parameter bestimmte Einteilungen vor, so hat man bereits eine Metrik definiert. Es sei das Beispiel der Zeit betrachtet. Verschiedene Stufen der Wirksamkeit lassen sich dadurch festlegen, daß man eine Mindestzeit angibt, für die eine Penetration des IT-Systems verhindert werden kann - etwa in der Stufe 3 Zeitaufwand mehr als ein Monat, Stufe 2 mehr als 1 Tag, Stufe 1 mehr als 10 Minuten, Stufe 0 weniger als 10 Minuten. Bei den übrigen Parametern (Kenntnisse, technische Ausstattung, ...) geht man ähnlich vor. Bei der Wirksamkeit gegenüber technischem Versagen geht man statt von einem Manipulanten vom "Zufall" aus, der bei den ausfallgefährdeten technischen Komponenten Alterungsprozesse, Störeinflüsse u.a. "verursacht". Hierbei kann eine ähnliche Zeitskala wie bei der Manipulation verwendet werden. Dabei sind allerdings die Zeitintervalle z.B. bei ausfallsicheren Systemen sehr viel kleiner. Vielfach sind Manipulationen deshalb möglich, weil vorhandene Sicherheitsfunktionen nicht korrekt funktionieren: Programmierfehler, Schnittstellen mit Nebeneffekten, undokumentierte Parameter, falsche Abläufe, vielleicht sogar absichtlich eingebaute Falltüren (Trap Doors). Die Wirksamkeit wie oben erläutert zu betrachten, ohne ein korrektes Funktionieren der Sicherheitsfunk

137

Wirksamkeit

4. Das Sicherheitsniveau

Korrektheit

tionen vorauszusetzen, macht also keinen Sinn. Die Wirksamkeitsbetrachtung muß noch durch eine Korrektheitsuntersuchung ergänzt werden. Bei der Korrektheit (Correctness) ist es aber nicht ganz so leicht, eine Metrik zu finden: Die Vorstellung bespielsweise, ein Programm funktioniere entweder korrekt oder nicht korrekt, ist so nicht haltbar; Korrektheit kann nur im Vergleich zu einer Aufgabenbeschreibung (Spezifikation) für das Programm geprüft werden; dabei stellt sich noch die Frage, nach welcher Methode und mit welcher Tiefe die Prüfung durchgeführt wird. Leider kann schon ein Programm oder eine Hardware mit wenigen Ein- und Ausgangsgrößen nicht mehr vollständig ausgetestet werden, da die Zahl der durchzuspielenden Fälle zu groß ist. Deshalb beschränkt man sich vielfach auf die Anwendung bestimmter Prüfverfahren wie z.B. Black Box und White Box Testing, semiformale und formale Verifikation, die allerdings eine sehr unterschiedliche Korrektheitsgarantie liefern. Damit haben wir aber auch schon die gesuchte Metrik: 1. Man ordnet vorab die Prüfverfahren in eine Rangfolge ein, die der Höhe ihrer Korrektheitsgarantie entspricht. 2. Je höher die Korrektheitsgarantie eines Prüfverfahrens ist, das ein Prüfobjekt (Hardware/Software) ohne Fehler durchläuft, um so höher ist per Definition der Korrektheitsgrad des Programms.

Kopplung

Nun kommt die Kopplung beider Begriffe: Es muß eine sinnvolle Relation zwischen der Wirksamkeits- und der Korrektheitsmetrik gefunden werden: Betrachtet man z.B. die Stärke der Mechanismen und die Korrektheit, so leuchtet sofort ein, daß es nicht sinnvoll sein dürfte, bei Systemen mit unüberwindbaren Mechanismen nur geringe Anforderungen an die Korrektheit zu stellen. Ebenso macht es wenig Sinn, bei Systemen mit schwachen Mechanismen eine mathematisch verifizierte Korrektheit zu verlangen. In beiden Fällen ist die Angemessenheit verletzt. Qualitativ soll eine Kopplung natürlich so aussehen, wie es die Abbildung 4-1 andeutet. Metrik der Vertrauenswürdigkeit

H Stufe 1

1 Stufe 2

1

1

1

...

1 Stufen >

steigender Korrektheitsgrad > steigende Wirksamkeit

Abbildung 4-1: Vertrauenswürdigkeit qualitativ

138

>

4.1 Grundsätzliches

Die noch zu definierende Kopplung wird als Metrik der Vertrauenswürdigkeit (Assurance Metrie) bezeichnet. Sie legt unterschiedliche Sicherheitsniveaus {Assurance Levels) fest. Auch in dieser Metrik unterscheiden sich die gängigen Sicherheitskriterien, was in den nächsten Abschnitten näher erläutert werden wird. Fragen wir uns aber zunächst, ob es Abhängigkeiten zwischen der Funktionalität und der Vertrauenswürdigkeit (Korrektheit und Wirksamkeit) gibt. Muß eine hohe Funktionalität auch eine hohe Vertrauenswürdigkeit nachsichziehen? Im amerikanischen Orange Book sind beide Aspekte in ein Klassenschema gepreßt worden, d.h. dort hat ein System hoher Funktionalität auch eine hohe Vertrauenswürdigkeit. Eine solche Kopplung von Funktionalität und Vertrauenswürdigkeit in einer einzigen Metrik bringt eine Reihe von Problemen mit sich: Es existieren dann keine Systeme mehr mit hoher Funktionalität, aber nur geringer oder mittlerer Vertrauenswürdigkeit. Gerade im Bereich zwischen der Verarbeitung gänzlich offener Daten und den Hochsicherheitsanforderungen mancher militärischer Installationen gibt es aber viele Stufen, in denen solche Systeme von Interesse sind. Ebenso nicht erfaßt werden Anwendungen, bei denen man sehr eingeschränkte Funktionalität, aber höchste Korrektheit fordert. Diese Situation liegt z.B. in vielen kritischen Prozeßsteuerungsanlagen und bei militärischen Gateways vor. Realistisch betrachtet ist es wohl so, daß nur Systeme geringer Funktionalität eine hohe Vertrauenswürdigkeit erlangen können, da aus Gründen der Komplexität (Prüfaufwand!) jede höhere Qualifizierung ausscheidet. In den moderneren Kriterienwerken (ITSEC91) und (CTCPEC92) werden Funktionalität und Vertrauenswürdigkeit deshalb als voneinander unabhängige Dimensionen der IT-Sicherheit festgelegt. Bei den in der Erstellung befindlichen Common Criteria wird man sich möglicherweise auch hiervon lösen und produktspezifische Sicherheitsprofile festlegen können, in denen sogar für die Korrektheit und Wirksamkeit voneinander unabhängige Anforderungen gestellt werden können. Bei der Zerfaserung in unterschiedlichste Metriken kann man aber auch über das Ziel hinausschießen: Viele Angaben zur Beurteilung der Sicherheit führen dazu, daß eine Vergleichbarkeit verschiedener bewerteter IT-Produkte für den Anwender kaum noch möglich ist. Wenn es einen Erfolg des amerikanischen Orange Book gab, dann den, daß es in seiner Struktur sehr einfach aufgebaut und für den Anwender nachvollziehbar war... Mit diesem mehr qualitativen Rüstzeug steigen wir nun in die Diskussion der Sicherheitsniveaus verschiedener Kriterienwerke ein.

139

Assurance Levels

Orange Book

ITSEC.CTCPEC

4. Das Sicherheitsniveau

4.2 Sicherheitsniveaus in Kriterienwerken 4.2.1 Das Orange Book Nachdem der Aufbau der Funktionalitätsklassen im Orange Book bereits erläutert worden ist, soll hier eine Passage für die Klasse C2 zitiert werden, die zeigt, wie Vertrauenswürdigkeit {Assurance) im Orange Book aufgefaßt wird. "2.2.3 Assurance 2.2.3.1 Operational Assurance 2.2.3.1.1 System Architecture The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements. 2.2.3.1.2 System Integrity Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. 2.2.3.2 Life-Cycle Assurance 2.2.3.2.1 Security Testing The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. Testing shall also include a search for obvious flaws that would allow violation of resource isolation, or that would permit unauthorized access to the audit or authentication data..." System Architecture beschreibt im wesentlichen die Trennung der TCB (Trusted Computing Base, Sicherheitskern) vom Rest des Systems und gibt einige funktionale Anforderungen (Subjekte/Objekte, Zugriffskontrolle, Beweissicherung). System Integrity verlangt nach Möglichkeiten, das korrekte Funktionieren der Hardware- und Firmware-Anteile im laufenden Betrieb überprüfen zu können. Unter Security Testing wird gefordert, daß durch Tests nachgewiesen wird, daß das System wie in der Dokumentation beschrieben funktioniert und keine einfache Penetration der Sicherheitsfunktionen möglich ist. Es kann festgehalten werden, daß im Orange Book Wirksamkeit immer im Sinne von "funktioniert oder funktioniert nicht" aufgefaßt wird. Insbesondere werden keine Stärken von Mechanismen diskutiert: Mechanismen werden hier quasi als Bestandteil der Funktion betrachtet. Assurance hat demzufolge im

140

4.2 Sicherheitsniveaus in Kriterienwerken

Orange Book das Ziel: "...to determine if the required features are present and functioning as intended". Die Klasse AI des Orange Book ist funktional identisch mit B3, stellt aber fur die Korrektheit höhere Anforderungen: Es wird die Verifikation zwischen dem formalen Sicherheitsmodell und der obersten Entwurfsebene verlangt: "Class (AI): Verified Design. Systems in class (AI) are functionally equivalent to those in class (B3) in that no additional architectural features or policy requirements are added. The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design..." 4.2.2 Die IT-Sicherheitskriterien Die Vertrauenswürdigkeit eines IT-Produktes oder eines IT-Systems wird in den deutschen IT-Sicherheitskriterien als Qualität bezeichnet. Die Stufen der Vertrauenswürdigkeit werden folglich Qualitätsstufen genannt. Sie beinhalten Anforderungen an die Korrektheit und die Wirksamkeit. Unter Wirksamkeit wird in den IT-Sicherheitskriterien im wesentlichen die (Mindest-)Stärke der Sicherheitsmechanismen verstanden. Der Begriff Sicherheitsmechanismus beinhaltet hier stets den gesamten Mechanismus (mathematische Algorithmen - sofern vorhanden technische Verfahren, Implementierungsdetails, ggf. sogar organisatorische Teilmechanismen). Damit ist die Mechanismenstärke die in der Praxis relevante Stärke eines Mechanismus. Es sind acht Qualitätsstufen definiert: QO ist die niedrigste, Q7 die höchste Stufe. Diese acht Stufen gliedern sich jeweils in folgende Einzelbetrachtungen: 1. Qualität der Sicherheitsanforderungen: Art der Darstellung der Sicherheitsanforderungen (z. B. verbal, semiformal oder formal), Konsistenz und Widerspruchsfreiheit der Sicherheitsanforderungen. 2. Qualität der Spezifikation der zu evaluierenden Systemteile: Art der Darstellung der Spezifikation (verbal, semiformal oder formal), Detaillierungsgrad sowie die Struktur der Spezifikation, Abbildung der Spezifikation auf die Sicherheitsanforderungen und ihre Nachvollziehbarkeit, Abbildung zweier benachbarter Hierarchiestufen der Spezifikation aufeinander und ihre Nachvollziehbarkeit, Nebeneffektfreiheit der Spezifikation, Qualität der bei der Spezifikation verwendeten Werkzeuge. 3. Qualität der verwendeten Mechanismen: Eignung der Mechanismen, Stärke der Mechanismen.

141

AI

Qualitätsstufen

4. Das Sicherheitsniveau

4. Qualität der Abgrenzung zu nicht zu evaluierenden Systemteilen: Umgehung, Täuschung, Mißbrauch der Sicherheitsfunktionen, Aufrechterhaltung der Integrität der Sicherheitsfunktionen. 5. Qualität des Herstellungsvorganges: Beurteilung der Qualität der Implementierung der Sicherheitsfunktionen, Implementierungssprache, Abbildung der Implementierung auf die Spezifikation, Korrektheit und Nachvollziehbarkeit dieser Abbildung, Nebeneffektfreiheit bezüglich der Sicherheitsanforderungen, Art und Qualität der verwendeten Werkzeuge (z. B. Compiler, Linker, Testwerkzeuge, Konfigurationsverwaltung), Qualität der Implementierungsumgebung (Versionskontrolle, Rollentrennung, Zugriffskontrolle auf Programme und Dokumente, Protokollierung der Zugriffe, Tests und Testmethoden und Werkzeuge, Vertrauenswürdigkeit des Entwicklungspersonals. 6. Betriebsqualität: Auslieferung/Verteilung, Konfigurierbarkeit, Einspielung des Systems, Generierung des Systems, Selbsttesteinrichtungen, sicheres Starten, Wartung (Hardware und Software), sicherer Wiederanlauf nach einem Fehler bzw. nach der Wartung. 7. Qualität der anwenderbezogenen Dokumentation: Korrektheit, Vollständigkeit, Verständlichkeit und Handhabbarkeit. Der folgende Ausschnitt zeigt die Anforderungen der Qualitätsstufe Q2, die in etwa der Stufe C2 des Orange Book bzw. der Stufe E2 der ITSEC vergleichbar ist. In der Gegenüberstellung zum vorhergehenden Abschnitt wird dennoch deutlich, wie unterschiedlich Assurance im Orange Book und in den IT-Sicherheitskriterien verstanden wird. Q2-Assurance

"Qualität der Sicherheitsanforderungen Anforderungen Es ist ein Dokument vorzulegen, in dem die Sicherheitsanforderungen an das System bzw. die Einzelkomponente mit Bezug zu den Bedrohungen und den Grundfunktionen dargelegt werden. Prüfvorgang Dieses Dokument darf keine Unstimmigkeiten enthalten. Qualität der Spezifikation Anforderungen Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponente ist eine Spezifikation vorzulegen, die in natürlicher Sprache formuliert sein kann. Diese Spezifikation muß die Art der Implementierung aller Sicherheitsfunktionen beschreiben. Es muß dargelegt werden, durch welche Teile der Spezifikation die einzelnen Sicherheitsanforderungen abgedeckt werden und welche Mechanismen dabei zum Einsatz kommen.

142

4.2 Sicherheitsniveaus in Kriterienwerken

Falls die Spezifikation hierarchisch aufgebaut ist, muß verbal beschrieben und nachvollziehbar sein, wie die einzelnen Hierarchiestufen aufeinander abzubilden sind. Die Abbildung der Sicherheitsanforderungen muß bis auf die niedrigste Hierarchiestufe der Spezifikation nachvollziehbar sein. In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch die Sicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. Bis auf die niedrigste Hierarchiestufe der Spezifikation wird überprüft, daß die Sicherheitsanforderungen erfüllt sind. Qualität der verwendeten Mechanismen Anforderungen Die zur Realisierung der Sicherheitsanforderungen verwendeten Mechanismen und Algorithmen sind in der Spezifikation zu beschreiben. Prüfvorgang Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein, die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmten Sicherheitsanforderung verwendete Mechanismus bzw. die verwendete Kombination von Mechanismen darf nicht schlechter als mit "mittelstark" bewertet worden sein. Es werden keine Ausnahmefalle zugelassen. Qualität der Abgrenzung zu nicht zu evaluierenden Systemteilen Anforderungen Die zu evaluierenden Systemteile müssen von nicht zu evaluierenden Teilen des Systems getrennt sein. Es muß dargelegt werden, warum die Sicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systems nicht umgangen werden können. Alle Schnittstellen zu nicht zu evaluierenden Systemteilen müssen mit ihren Aufgaben, ihren Parametern und Effekten dokumentiert sein. Prüfvorgang Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zu evaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheit mindestens mit "stark" bewertet worden sein. Durch Tests wird überprüft, daß die Schnittstellen in der beschriebenen Form existieren. Dabei dürfen keine Fehler gefunden werden, durch die Sicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. Qualität des Herstellungsvorganges Anforderungen Es werden keine Anforderungen hinsichtlich der Implementierungssprache sowie der verwendeten Werkzeuge gestellt. Es werden keine Voraussetzungen an die Implementierungsumgebung gemacht.

143

4. Das Sicherheitsniveau

Die auf der niedrigsten Hierarchiestufe der Spezifikation definierten Funktionseinheiten müssen identifizierbar sein. Ihre Schnittstellen untereinander müssen dokumentiert sein. Zusätzlich muß eine Bibliothek mit Testprogrammen sowie der zugehörigen Testdokumentation zur Verfugung stehen. Die Testdokumentation muß enthalten: Testplan, Zweck, Vorgehensweise und Ergebnisse der Tests. PrüfVorgang Es werden Tests durchgeführt, durch die Unklarheiten oder vermutete Schwachstellen, die sich bei der Prüfung der Spezifikation ergaben, aufgeklärt werden sollen. Dabei dürfen keine Wege gefunden werden, durch die Sicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. Ausgewählte Testbeispiele aus der Testbibliothek werden nachvollzogen und müssen die in der Dokumentation beschriebenen Ergebnisse liefern. Betriebsqualität Anforderungen Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen deren Auswirkungen auf die Sicherheitsanforderungen beschrieben sein. Diese Auswirkungen müssen auch in der Spezifikation erkennbar sein. Sofern durch unterschiedliche Konfigurationen auch unterschiedliche Sicherheitsanforderungen realisiert werden, muß dies in der Dokumentation erläutert werden. Alle Konfigurationsmöglichkeiten müssen dokumentiert sein. Bei der Generierung des Systems dürfen keine nicht protokollierten Eingriffe möglich sein, durch die Sicherheitsfunktionen auch nur teilweise außer Kraft gesetzt werden können. Es muß ein von der Prüfbehörde für diese Qualitätsstufe zugelassenes Verfahren eingesetzt werden, das sicherstellt, daß Übertragungsfehler bei der eingespielten Software erkannt werden. Falls Sicherheitsfünktionen im Falle einer Hardware- oder Softwarewartung außer Kraft gesetzt sind, muß dies im Handbuch für den SystemVerwalter dokumentiert sein. Das System muß Selbsttesteinrichtungen für einige der Hardwarekomponenten besitzen, deren korrekte Funktionalität Voraussetzung für das korrekte Ablaufen der zu evaluierenden Software ist. Prüfvorgang Die Auswirkungen unterschiedlicher Konfigurationen werden an Hand der Spezifikation sowie der Dokumentation auf Konsistenz mit den Sicherheitsanforderungen geprüft. Bei Unklarheiten oder vermuteten Fehlern werden Tests durchgeführt, durch die diese Unklarheiten aufgeklärt werden sollen.

144

4.2 Sicherheitsniveaus in Kriterienwerken

Es wird geprüft, welche Eingriffe bei der Generierung des Systems möglich sind, welche Auswirkungen sie haben und wie sie protokolliert werden. Die Wirksamkeit der Sicherheitsfunktionen im Wartungsfall wird auf Konsistenz mit der Dokumentation geprüft. Die Selbsttesteinrichtungen des Systems werden, soweit möglich, stichprobenhaft untersucht. Qualität der anwenderbezogenen Dokumentation Anforderungen Die Anwenderdokumentation muß für alle durch die Sicherheitsanforderungen definierten Rollen deren relevante Sicherheitsfiinktionen, ihre Aufgabe sowie ihre Benutzung beschreiben. PrüfVorgang Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Handhabbarkeit geprüft. Es dürfen keine Abweichungen zwischen realem Systemverhalten und der Dokumentation gefunden werden." Im Unterschied zum Orange Book sieht man das viel systematischere Vorgehen unter Einbeziehung einer Vielzahl von Qualitätsaspekten. Die übrigen Qualitätsstufen können hier aus Gründen des Umfangs nicht im Detail abgedruckt werden (vgl. aber (ITSK89) und (OLDB93)). Hinsichtlich der Korrektheit und ihrer Prüfung lassen sich die Qualitätsstufen wie folgt charakterisieren: QO - unzureichende Qualität "Die Evaluation ergab keine für eine höhere Stufe ausreichende Qualität." Q1 - getestet "Die Sicherheitsanforderungen sind verbal formuliert. Die Spezifikation beschreibt relativ grob die Art der Implementierung. Das System wurde mit Hilfe einfacher Tests auf Erfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keine Fehler gefunden." Q2 - methodisch getestet "Die Sicherheitsanforderungen sind verbal formuliert. Das System wurde an Hand der Spezifikation methodisch getestet und auf Erfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keine Fehler gefunden." Q3 - methodisch getestet und teilanalysiert "Die Sicherheitsanforderungen sind detailliert verbal beschrieben. Die Systemspezifikation wurde informell analysiert und auf Konsistenz mit den Sicherheitsanforderungen geprüft. Der Quellcode wurde stichprobenartig an Stellen, die als besonders kritisch angesehen wurden, analysiert. Das System wurde an Hand dieser Analysen methodisch getestet und auf Erfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keine Fehler gefunden."

145

QO - Q7

4. Das Sicherheitsniveau

Q4 - informell analysiert "Die Sicherheitsanforderungen sind detailliert verbal beschrieben. Systemspezifikation und Quellcode wurden informell analysiert und auf Konsistenz mit den Sicherheitsanforderungen geprüft. Das System wurde methodisch getestet und auf Erfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keine Fehler gefunden." Q5 - semi-formal analysiert "Die Sicherheitsanforderungen sind detailliert verbal beschrieben. Die wichtigsten Sicherheitsanforderungen sind formal spezifiziert. Die Systemspezifikation liegt auch in semi-formaler Notation vor. Systemspezifikation und Quellcode wurden mit semi-formalen Methoden analysiert und auf Konsistenz mit den Sicherheitsanforderungen geprüft. Das System wurde methodisch getestet und auf Erfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keine Fehler gefunden." Q6 - formal analysiert "Sicherheitsanforderungen und Systemspezifikation sind zusätzlich in formaler Notation niedergelegt und auf Konsistenz verifiziert worden. Der Quellcode wurde sorgfältig auf Konsistenz mit der Spezifikation geprüft. Das System wurde methodisch getestet und auf Erfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keine Fehler gefunden." Q7 - formal verifiziert "Sicherheitsanforderungen und Systemspezifikation sind zusätzlich in formaler Notation niedergelegt und auf Konsistenz verifiziert worden. Die Konsistenz zwischen Spezifikation und Quellcode wurde formal verifiziert. Das System wurde methodisch getestet und auf Erfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keine Fehler gefunden." Stärke der Mechanismen

Unter der schon aufgeführten Überschrift Qualität der verwendeten Mechanismen wird die Stärke der Sicherheitsmechanismen bewertet. Hierfür ist eine sechsstufige Metrik definiert: ungeeignet "Der Mechanismus ist nicht wirksam." schwach "Der Mechanismus ist lediglich als Abwehr unbeabsichtigter Verstöße gegen die Sicherheitsanforderungen geeignet, stellt jedoch kein ernsthaftes Hindernis gegen absichtliche Verstöße dar." mittelstark "Der Mechanismus bietet bereits Schutz bei absichtlichen Verstößen gegen die Sicherheitsanforderungen, ist jedoch mit mittelgroßem Aufwand von Personen mit normalen Kenntnissen des Systems zu überwinden."

146

4.2 Sicherheitsniveaus in Kriterienwerken

stark "Der Mechanismus bietet einen guten Schutz bei absichtlichen Verstößen gegen die Sicherheitsanforderungen und ist nur mit großem Aufwand bzw. unter Zuhilfenahme aufwendiger Hilfsmittel zu überwinden. Falls organisatorische Maßnahmen zur Aufrechterhaltung der Stärke des Mechanismus notwendig sind, müssen diese recht einfach geartet und wenig fehleranfällig sein. Bei fehleranfälligen organisatorischen Maßnahmen müssen im zu evaluierenden IT-System Methoden zur Erkennung und Vermeidung solcher Fehler implementiert sein. Die organisatorischen Maßnahmen sind im Evaluationsbericht zu beschreiben. Die Bewertung der Qualität dieser Methoden und der Korrektheit ihrer Implementierung ist dabei Teil der Evaluation." sehr stark "Der Mechanismus bietet einen sehr guten Schutz bei absichtlichen Verstössen gegen die Sicherheitsanforderungen und ist nach dem derzeitigen Stand der Technik nur mit sehr großem Aufwand und unter Zuhilfenahme sehr aufwendiger Hilfsmittel zu überwinden. Organisatorische Maßnahmen zur Aufrechterhaltung der Stärke des Mechanismus müssen relativ einfach geartet und wenig fehleranfallig sein. Mögliche Fehlerquellen bei der Handhabung der organisatorischen Maßnahmen müssen weitgehend vom zu evaluierenden System überwacht werden und Maßnahmen zur Fehlervermeidung müssen implementiert sein. Alle diese Kontrollfunktionen müssen Bestandteil der zu evaluierenden Software sein." nicht iiberwindbar "Der Mechanismus bietet einen zur Zeit nicht überwindbaren Schutz bei absichtlichen Verstößen gegen die Sicherheitsanforderungen. Zur Aufrechterhaltung seiner Stärke werden höchstens solche organisatorischen Maßnahmen eingesetzt, die durch systeminterne Überwachungsfunktionen praktisch vollständig gegen Fehler abgesichert sind. Alle diese Kontrollfunktionen müssen Bestandteil der zu evaluierenden Software sein." In den Bewertungsstufen für die Mechanismenstärke ist viel Spielraum für subjektive Auffassungen gegeben. Sehr deutlich wird dies an der Beschreibung der Manipulationsresistenz (erster, guter, sehr guter Schutz), des Aufwandes (mittelgroß, groß, sehr groß), der Kenntnisse und der Hilfsmittel (normal, aufwendig, sehr aufwendig). Auch die Vorkenntnisse und Erfahrungen des Bewertenden spiegeln sich in seiner Einschätzung wider: Mechanismen mit ihm bekannten Schwächen und neuartige Mechanismen wird er vom Ansatz her anders gewichten. Der gleiche Mechanismus in einem ihm sehr gut bekannten System wird anders eingestuft als in einem zweiten, vielleicht exotischen System. Probleme dieser Art lassen sich nur dadurch mindern, daß die Bewertung stets durch mehrere Personen erfolgt, in dem Experten für das betreffende System, Experten in Fragen der Interpretation der Kriterien und Personen mit Überblick über bereits erfolgte

147

Subjektivität

4. Das Sicherheitsniveau

Bewertungen vertreten sind. Es muß gewährleistet sein, daß bei aller vorhandenen Subjektivität der Bewertung zumindest überall "gleich subjektiv" verfahren wird. Dennoch ist eine präzise Abgrenzung zwischen den Bewertungsstufen sehr schwer festzulegen. Stufe

Stärke der Mechanismen 1

Korrektheit

QO

unwirksam/max. schwach

unzureichend

Ql

mittelstark mit Ausnahmen

getestet

Q2

mittelstark

methodisch getestet

Q3

stark mit Ausnahmen

methodisch getestet, teilanalysiert

Q4

stark

informell analysiert

Q5

sehr stark mit Ausnahmen

semiformal analysiert

Q6

sehr stark

formal analysiert

Q7

nicht überwindbar mit Ausnahmen

formal verifiziert

Tabelle 4-1: Qualitätsstufen der IT-Sicherheitskriterien Aus der Tatsache, daß in den Zertifizierungsergebnissen (s. Anhang B.4) die Mechanismenstärken nicht explizit ausgewiesen werden, kann man schon erkennen, daß sie in irgendeiner Form in die Q-Stufen integriert sein müssen. Das zitierte Beispiel der Stufe Q2 macht dies ebenfalls deutlich (s. Überschrift Qualität der verwendeten Mechanismen). Die Tabelle 4-1 zeigt, welche Mechanismenstärken und Korrektheitsanforderungen den Qualitätsstufen zugeordnet sind. 4.2.3 Die ITSEC In den ITSEC (ITSEC91) wird ebenfalls zwischen Korrektheit und Wirksamkeit unterschieden. Die Kombination beider Eigenschaften wird explizit als Vertrauenswürdigkeit (Assurance) bezeichnet. Sie wird unterteilt in Assurance of Correctness (Korrektheit) und Assurance of Effectiveness (Wirksamkeit). Es existieren sieben Stufen für die Assurance of Correctness. EO ist die niedrigste, E6 die höchste Stufe. Diese Stufen sind wie folgt charakterisiert: Stufe EO: "Diese Stufe repräsentiert unzureichende Vertrauenswürdigkeit."

Bei QO heißt es unwirksam/max. Stärke und Korrektheit.

148

schwach

oder unzureichende

Korrektheit, sonst stets

4.2 Sicherheitsniveaus in Kriterienwerken

Stufe El: "Auf dieser Stufe müssen für den EVG die Sicherheitsvorgaben und eine informelle Beschreibung des Architekturentwurfs vorliegen. Durch funktionale Tests muß nachgewiesen werden, daß der EVG die Anforderungen der Sicherheitsvorgaben erfüllt."

Stufe E2: "Zusätzlich zu den Anforderungen für die Stufe El muß hier eine informelle Beschreibung des Feinentwurfs vorliegen. Die Aussagekraft der funktionalen Tests muß bewertet werden. Ein Konfigurationskontrollsystem und ein genehmigtes Distributionsverfahren müssen vorhanden sein."

Stufe E3: "Zusätzlich zu den Anforderungen für die Stufe E2 müssen der Quellcode bzw. die Hardware-Konstruktionszeichnungen, die den Sicherheitsmechanismen entsprechen, bewertet werden. Die Aussagekraft der Tests dieser Mechanismen muß bewertet werden."

Stufe E4: "Zusätzlich zu den Anforderungen für die Stufe E3 muß ein formales Sicherheitsmodell Teil der Sicherheitsvorgaben sein. Die sicherheitsspezifischen Funktionen, der Architekturentwurf und der Feinentwurf müssen in semiformaler Notation vorliegen."

Stufe E5: "Zusätzlich zu den Anforderungen für die Stufe E4 muß ein enger Zusammenhang zwischen dem Feinentwurf und dem Quellcode bzw. den Hardware-Konstruktionszeichnungen bestehen."

Stufe E6: "Zusätzlich zu den Anforderungen für die Stufe E5 müssen die sicherheitsspezifischen Funktionen und der Architekturentwurf in einer formalen Notation vorliegen, die konsistent mit dem zugrundeliegenden formalen Sicherheitsmodell ist." Es fällt auf, daß diese Metrik eine Stufe weniger als die IT-Sicherheitskriterien enthält. Während die dort eingeführten Stufen QO bis Q6 weitestgehend den Stufen EO bis E6 entsprechen, existiert zur Stufe Q7 in den ITSEC kein Pendant...

149

4. Das Sicherheitsniveau

Die folgende Übersicht zeigt die Unterteilung der E-Stufen in einzelne Korrektheitsaspekte: • Korrektheit in der Entwicklung • Konstruktion - Der Entwicklungsprozeß Phase 1 - Anforderungen Phase 2 - Architekturentwurf Phase 3 - Feinentwurf Phase 4 - Implementierung • Konstruktion - Die Entwicklungsumgebung Aspekt 1 - Konfigurationskontrolle Aspekt 2 - Programmiersprachen und Compiler Aspekt 3 - Sicherheit beim Entwickler • Korrektheit im Betrieb • Betrieb - Die Betriebsdokumentation Aspekt 1 - Benutzerdokumentation Aspekt 2 - Systemverwalter-Dokumentation • Betrieb - Die Betriebsumgebung Aspekt 1 - Auslieferung und Konfiguration Aspekt 2 - Anlauf und Betrieb Wirksamkeit

Im Vergleich zu den IT-Sicherheitskriterien ist die Wirksamkeit etwas anders definiert. Wie die folgenden Zitate zeigen, geht es um die Eignung (Suitability) und das Zusammenwirken (Binding) von Funktionalitäten und Mechanismen, mögliche Schwachstellen, die Einfachheit der Systemverwaltung sowie um die Stärke von Mechanismen: "Bei der Evaluation der Wirksamkeit wird beurteilt, ob die sicherheitsspezifischen Funktionen und Mechanismen, die durch den EVG 2 zur Verfügung gestellt werden, wirklich die vorgegebenen Sicherheitsziele erreichen. Der EVG wird hinsichtlich der Eignung der Funktionalität, des Zusammenwirkens der Funktionen (ob die ausgewählten Funktionen synergetisch zusammenarbeiten), der Konsequenzen von bekannten und entdeckten Schwachstellen (sowohl bei der Entwicklung des EVG als auch bei der Art und Weise, wie er im echten Betrieb genutzt wird) und der Einfachheit der Anwendung beurteilt." "Zusätzlich wird bei der Bewertung der Wirksamkeit die Fähigkeit der Sicherheitsmechanismen des EVG, Widerstand gegen einen direkten Angriff zu leisten, bewertet (Stärke des Mechanismus). Für die Stärke der Mechanismen sind drei Stufen definiert - niedrig, mittel, hoch -, die ein Maß für das 2

E V G = Evaluationsgegenstand; meint das zu evaluierende Produkt oder System.

150

4.2 Sicherheitsniveaus in Kriterienwerken

Vertrauen sind, inwieweit die Sicherheitsmechanismen des EVG in der Lage sind, direkten Angriffen zu widerstehen." Bei einer Evaluierung der Wirksamkeit nach den ITSEC werden deshalb folgende Aspekte betrachtet:

Evaluierung

"a) die Eignung der sicherheitsspezifischen Funktionen des EVG, den in den Sicherheitsvorgaben aufgezählten Bedrohungen zu widerstehen; b) die Fähigkeit der sicherheitsspezifischen Funktionen und Mechanismen des EVG, in einer Weise zusammenzuwirken, daß sie sich gegenseitig unterstützen und ein integriertes, wirksames Ganzes bilden; c) die Fähigkeit der Sicherheitsmechanismen des EVG, einem direkten Angriff zu widerstehen; d) ob bekannte Schwachstellen in der Konstruktion des EVG in der Praxis die Sicherheit des EVG kompromittieren können; e) daß der EVG nicht in einer Weise konfiguriert werden kann, die unsicher ist, aber von der ein Systemverwalter oder ein Endnutzer vernünftigerweise glauben könnte, daß sie sicher ist; f) ob bekannte Schwachstellen beim Betrieb des EVG in der Praxis die Sicherheit des EVG kompromittieren können." Die Stärke der Mechanismen wird in dem Unterpunkt c der Wirksamkeit behandelt; wegen der Schwierigkeit der präzisen Abgrenzung bei einer größeren Zahl von Bewertungsstufen und der damit verbundenen Subjektivität der Bewertung hat man sich in den ITSEC für nur drei Stufen der Mechanismenbewertung entschieden. Das mögliche Umgehen, Täuschen oder Außerkraftsetzen von Sicherheitsfunktionen und deren Mechanismen wird unter den Aspekten a, b, d, e und f betrachtet. Die Bewertung eines Mechanismus unter c bezieht sich in den ITSEC deshalb nicht auf das gesamte "wie", sondern nur auf die Prinzipien einer Sicherheitsfunktion:

Mechanismenstärke

"Selbst wenn ein sicherheitsspezifischer Mechanismus nicht umgangen, außer Kraft gesetzt oder anders korrumpiert werden kann, kann es trotzdem möglich sein, ihn durch einen direkten Angriff zu überwinden, der auf Mängel in seinen zugrundeliegenden Algorithmen, Prinzipien oder Eigenschaften zurückzufuhren ist. " Als Beispiel für einen direkten Angriff werde die Authentisierung über Paßwort und das mehrfache Ausprobieren von Paßwörtern betrachtet: Auch bei perfekter Implementierung und Einbindung in das IT-System kann es Unbefugten

151

Direkter A n g r i f f

4. Das Sicherheitsniveau

Kritischer Mechanismus

durch Raten von Paßwörtern gelingen, sich Zugriff zum System zu verschaffen 3 . Das Problem ist hierbei das schwache Prinzip des Paßwort-Mechanismus. Alle Sicherheitsmechanismen, deren Versagen eine Sicherheitslücke hervorrufen würde - solche werden kritisch genannt werden hinsichtlich ihrer Fähigkeit bewertet, einem direkten Angriff zu widerstehen. Die Mindeststärke solcher Mechanismen wird entweder als niedrig, mittel oder hoch bewertet: Niedrig

"Damit die Mindeststärke eines kritischen Mechanismus als niedrig eingestuft werden kann, muß erkennbar sein, daß er Schutz gegen zufälliges unbeabsichtigtes Eindringen bietet, während er durch sachkundige Angreifer überwunden werden kann." Mittel

"Damit die Mindeststärke eines kritischen Mechanismus als mittel eingestuft werden kann, muß erkennbar sein, daß er Schutz gegen Angreifer mit beschränkten Gelegenheiten oder Betriebsmitteln bietet." Hoch "Damit die Mindeststärke eines kritischen Mechanismus als hoch eingestuft werden kann, muß erkennbar sein, daß er nur von Angreifern überwunden werden kann, die über sehr gute Fachkenntnisse, Gelegenheiten und Betriebsmittel verfügen, wobei ein solcher erfolgreicher Angriff als normalerweise nicht durchfuhrbar beurteilt wird." Der Nachteil der Beschränkung auf diese drei Stufen dürfte sein, daß die meisten Mechanismen in die mittlere Bewertungsstufe eingeordnet werden müssen. Dies läßt keine besonders differenzierte Bewertung zu. Zudem ist die Beschränkung auf die hinter einer Funktion oder einem Mechanismus stehenden Prinzipien oder Algorithmen letztlich für die Praxis nicht relevant: Für den Anwender ist nicht die theoretische, sondern die in der Praxis gegebene Manipulationssicherheit ausschlaggebend. Sie wird aber vor allem durch Angriffe wie Umgehen oder Täuschen beeinträchtigt, die von der Bewertung der Mechanismenstärke in den ITSEC nicht erfaßt wird. Natürlich werden solche Angriffe nicht ignoriert; sie sind vielmehr Gegenstand der weitergehenden Schwachstellenanalyse und gehen somit im Ergebnis in die E-Stufen ein. Das Problem ist also, daß die explizite Angabe der Stärken niedrig, mittel oder hoch in den Zertifizierungsergebnissen (s. Anhang B.2) für den Anwender wenig aussagekräftig ist.

3

Im Beispiel wird vorausgesetzt, daß das System das Ausprobieren ausreichend oft gestattet.

152

4.2 Sicherheitsniveaus in Kriterienwerken

4.2.4 Britische Kriterien Bei den älteren britischen Kriterien (UKL89) findet man die Überschriften • Specification of Security Requirements (entspricht den Sicherheitsvorgaben oder Sicherheitsanforderungen anderer Kriterienwerke), • Architectural Definition, Implementation, Documentation, Configuration Control (Korrektheitsaspekte), • Evaluation (Durchfuhrung der Prüfung, insbesondere Schwachstellenanalyse). Es fallt auf, daß hier die Wirksamkeit nur implizit im letzten Punkt angesprochen wird, die Bewertung von Mechanismenstärken gar nicht vorkommt. Die für Assurance definierte Metrik enthält sieben Stufen UKLO bis UKL6. Die zuvor aufgezählten Überschriften werden unter jedem Assurance Level abgehandelt und mit steigenden Anforderungen versehen. Das Stufenschema soll gemäß der Tabelle 4-2 grob den Klassen des Orange Book entsprechen. Orange Book

UKL Stufe(n)

Charakterisierung

D

UKLO

Unassured

CI

UKLI/UKL2

Vendor assured/ Independently tested

C2

UKL2/UKL3

Independently tested/ Independently Assured

B1

UKL3

Independently Assured

B2

UKL4

Structurally Sound

B3

UKL5

Rigorous Design

Al

UKL6

Assured Design

Tabelle 4-2: Abbildung UK Levels ./. Orange Book 4.2.5 Kanadische Kriterien In den kanadischen Kriterien (CTCPEC92) werden unter Assurance die folgenden Einzelthemen behandelt: • Architecture, • Development Environment (Life Cycle Process, Configuration Management), • Development Evidence (Functional Specification, Architectural Design, Detailed Design),

153

Kanadische Kriterien

4. Das Sicherheitsniveau

• Security Manuals (User's Guide, Trusted Facility Manual), • Security Testing, • Trusted Distribution and Generation. Die für Assurance definierte Metrik enthält acht Stufen TO bis T7. Der Buchstabe T steht fur Trust. Die obigen Überschriften werden unter jedem Assurance Level abgehandelt und mit steigenden Anforderungen versehen. Man sieht hier die Abkehr vom Assurance-Begriff des Orange Book - allerdings auch, daß die Wirksamkeit noch nicht in der Form ausgearbeitet ist, wie es in den 1TSEC der Fall ist.

Development Assurance

Evaluation Assurance

4.2.6 Ausblick auf Common Criteria Soweit bereits absehbar wird es in den Common Criteria (CC) eine Unterscheidung zwischen Evaluation Assurance und Development Assurance geben. Der Nachweis der Korrektheit wird dabei weitgehend als Bestandteil des Entwicklungsprozesses eines Produktes oder Systems angesehen und möglicherweise nicht mehr Aufgabe einer unabhängigen Evaluierung sein. Unter Development Assurance werden deshalb prozeßbezogene Vorgaben gemacht werden, die vom Entwickler oder Hersteller bereits in der Entwicklung zu beachten sind. Inwieweit dies noch Gegenstand einer Nachprüfung durch Dritte sein wird, ist noch offen. Eine Wirksamkeitsuntersuchung wird es voraussichtlich in zweierlei Hinsicht geben: Die Eignung von Funktionalitäten und Mechanismen, den Bedrohungen zu widerstehen, und ihr kooperatives Zusammenwirken wird im Rahmen der Validierung von Sicherheitsprofilen produktunabhängig nachgewiesen. Hier kommt wieder das Orange Book zum Vorschein ... Durch die Evaluierung eines Produktes bleibt dann noch eine Rest-Assurance zu erbringen, die sich hauptsächlich auf konstruktive und operationeile Schwachstellen beziehen dürfte. Ob diese grob skizzierte Methodik allerdings tragfähig ist, muß die Praxis erweisen. Der wesentliche Pluspunkt für die CC dürfte die Möglichkeit einer weltweiten internationalen Anerkennung von Evaluierungsergebnissen sein.

154

5. Entwicklung 5.1 Grundsätzliches Der Grundstein für Sicherheit und Ordnungsmäßigkeit von IT-Systemen wird zu einem großen Teil bereits bei der Entwicklung eines Systems oder seiner Komponenten gelegt. Letztlich impliziert das Ziel, die so verstandene Qualität erhöhen zu wollen, die Notwendigkeit, sich mit einer Vielzahl von Themen beschäftigen zu müssen: Vorgehensmodelle für die Entwicklung, der Korrektheitsbegriff, die Qualitätssicherung, Validierungs- und Evaluierungsmethoden und unterstützende Werkzeuge, Sicherheitskriterien und Qualitätsstandards. Interessant ist, daß bei praktisch allen Aspekten der Qualität die korrekte Funktionsweise von Hardware und Software ein zentrales Anliegen ist: • Sicherheit setzt korrekt ablaufende Sicherheitsfunktionen voraus, • Ordnungsmäßigkeit kann nicht mit inkorrekt arbeitenden Systemen erreicht werden. Demgegenüber steht die alltägliche Erfahrung, daß es um die Korrektheit in der Praxis schlecht bestellt ist. Die sehr schwachen - wenn überhaupt vorhandenen - Korrektheitsgarantien der Hersteller kommerzieller IT-Produkte sprechen Bände. In Anwendungsbereichen mit hohen Risiken (Menschenleben bedroht, höchste Gefahrdungen der Umwelt) oder mit extrem hoher Komplexität wurden deshalb Modelle, Methoden und Verfahren entwickelt, um das Korrektheitsproblem in den Griff zu bekommen. Dabei werden grundsätzlich zwei Denkansätze verfolgt: prozeßbezogene Qualität {process oriented) und produktbezogene Qualität (product oriented). Die produktbezogene Qualität ist uns schon aus den vorausgehenden Kapiteln bekannt; sie wird auf der Basis von Sicherheitskriterien oder Qualitätsstandards durch Evaluierung des betreffenden Produktes festgestellt. Die Evaluierung kann zeitlich durchaus mit der Produktentwicklung verzahnt sein oder aber nach der Produktfertigstellung erfolgen. Das Ergebnis ist letztlich, daß das Produkt seine (Sicherheits-)Anforderungen mit einem bestimmten Maß an Garantie erfüllt. Der Prozeß der Produktentwicklung (Verfahren, Design, Implementierung, Qualitätssicherung, Werkzeuge usw.) kann ebenso unter dem Stichwort Qualität betrachtet werden. Die Prozeßqualität wird durch eine Prüfung (z.B. Abnahme und Zertifizierung nach ISO 9000) festgestellt und durch regelmäßige

155

Prozeß

vs. Produkt

5. Entwicklung

Audits überwacht. Damit ist die Ordnungsmäßigkeit der Entwicklung sichergestellt. Die Hoffnung, daß ein ordnungsgemäßer Entwicklungsprozeß auch zu einem sicheren Produkt fuhrt, ist leicht zu widerlegen. Es ist möglich, mit dem besten Qualitätssicherungssystem absolut unsichere Produkte zu entwickeln. Praktisch heißt dies, daß ein Entwicklungsgang z.B. nach ISO 9000 ein Produkt hervorbringen kann, das nicht einmal der untersten Stufe von Sicherheitskriterien genügt. Beim Entwicklungsprozeß ist deshalb aus Sicht der Sicherheit zu fragen: Ist die Sicherheit bei der Entwicklung gewährleistet? Können Unbefugte Entwicklungsdokumente lesen, Werkzeuge oder Produktteile (z.B. Software-Module) verändern oder vorenthalten? Solche Manipulationsmöglichkeiten auszuräumen ist das Ziel jeder Sicherheitsbetrachtung. Sicherheitskriterien (z.B. ITSEC) betrachten deshalb die Sicherheit beim Entwickler als einen speziellen Prüfaspekt, beschäftigen sich also ebenfalls mit prozeßbezogenen Eigenschaften dies aber unter dem Gesichtspunkt der Sicherheit. Aber auch bei gegebener Ordnungsmäßigkeit und Sicherheit des Entwicklungsprozesses bleibt klar, daß dieses nicht zwangsläufig sichere Produkte oder Systeme zur Folge haben muß. Abbildung 5-1 verdeutlicht die Zusammenhänge. Produkt-Assurance

Evaluierung gemäß z. B. ITSEC Sicherheit der Entwicklung

Prozeßqualität z.B. nach ISO 9000

Prozeß-Assurance

Abbildung 5-1: Produkt- und Prozeß-Assurance

Outsourcing

Es ist also festzuhalten, daß sowohl prozeßbezogene als auch produktbezogene Verfahren zur Assurance beitragen können. Eine genaue Abgrenzung oder gar ein quantitativer Vergleich ist aber nicht möglich. Ein aktuelles Stichwort ist das Outsourcing von Dienstleistungen. Auf den Bereich der Produktentwicklung angewandt heißt dies, daß Teile der Entwick-

156

5.3 Produkt-Entwicklung

lung (in allen Phasen) durch externe Dienstleister erbracht werden können. Daß hierdurch massive Sicherheitsprobleme entstehen können, liegt auf der Hand: Sind beim Dienstleister gleich hohe Qualitätsansprüche umgesetzt? Läuft der zwangsläufig notwendige Austausch von Dokumentation, Software, Hardware gesichert ab? Wer übernimmt für was Garantien? Wie steht es mit der späteren (neutralen) Evaluierbarkeit der Produktionsergebnisse? Die Liste der Fragen läßt sich noch verlängern - grundsätzlich sind alle diese Fragestellungen unter dem Thema Qualität und Sicherheit der Entwicklung und Entwicklungsumgebung zu behandeln, auf das später eingegangen wird.

5.2 Vorgehensmodell Eine ordnungsgemäße Produktentwicklung benötigt zunächst eine vereinheitlichte Vorgehensweise. Ein Vorgehensmodell muß deshalb auf einer hohen Abstraktionsebene Aktivitäten, Ergebnisse und Rollen innerhalb eines Entwicklungsprozesses festlegen. Dabei spielen die Verfahrensblöcke ProjektmanageKonfigurationsmanagement, Produkt-Entwicklung, Qualitätssicherung und ment die entscheidende Rolle. Der Einsatz von Vorgehensmodellen soll die Produktentwicklung kontrollierbar, einheitlich und nachvollziehbar machen. Ein Vorgehensmodell spezifiziert weder Verfahren noch Methoden, erst recht nicht produktspezifische Vorgaben oder Entwicklungsziele. Diese werden erst im Rahmen einer konkreten Anwendung eines Vorgehensmodells festgelegt. Es ist deshalb leicht einsehbar, daß Normen wie etwa die ISO 9000 Reihe (Qualitätssicherung) und die verschiedenen Sicherheitskriterien hier als nachrangig betrachtet werden, aber durchaus unter ein Vorgehensmodell eingeordnet werden können. Auf die Notwendigkeit und mögliche Verfahren des Projektmanagements soll hier nicht weiter eingegangen werden. Die übrigen Verfahrensblöcke ProduktEntwicklung (Product Development), Qualitätssicherung (Quality Assurance) und Konfigurationsmanagement (Configuration Management) sollen nun näher diskutiert werden.

5.3 Produkt-Entwicklung 5.3.1 Phasenmodell und Prototyping Ein komplexes reales IT-System kann nicht durch einen einzigen, alle Details enthaltenden Gesamtplan erfaßt werden. Üblicherweise wird ein System mittels einer Abfolge immer detaillierterer Pläne oder Systemmodelle konstruiert. Eines der wesentlichen Ziele ist dabei die Steigerung der Korrektheit - vor allem bei der Erstellung großer Software-Systeme.

157

5. Entwicklung

Phasenmodell

Informelle Methoden

Semiformale Methoden

Formale Methoden

Das sogenannte Phasenmodell - teilweise ergänzt um das sogenannte Rapid Prototyping - hat sich einen Namen gemacht und Eingang in die Praxis gefunden. Die wichtigsten Stadien beim Phasenmodell werden im folgenden erläutert. Dabei werden in allen Ebenen Beschreibungen oder Spezifikationen erforderlich, so daß es sinnvoll ist, kurz auf die Darstellungsarten von Spezifikationen einzugehen. Man unterscheidet informelle, semiformale und formale Darstellungen. Diese Attribute kennzeichnen auch darauf aufbauende Methoden zum Nachweis der Korrektheit. Informelle Beschreibungen nutzen die Umgangssprache zur Formulierung der Spezifikation. Dabei muß mit der Ungenauigkeit solcher Beschreibungen gerechnet werden. Zum Teil aus Gründen des Umfangs und der Übersichtlichkeit, zum Teil auch der höheren Präzision wegen können • strukturierte Formen natürlicher Sprache mit beschränktem Begriffsvorrat und definierten Verknüpfungen, • graphische Hilfsmittel wie Fluß-/Ablaufdiagramme, Hierarchie-Bilder, Zustandsdiagramme zur Anwendung kommen. Man spricht hier von semiformalen Darstellungen. im Gegensatz dazu sind formale Darstellungen solche, bei denen Spezifikationen in einer mathematischen Sprache notiert werden - was zwar die Verständlichkeit auf Experten beschränkt, dafür aber ein Höchstmaß an Genauigkeit ermöglicht. Die Art und Weise, wie die Spezifikation dargestellt ist (informell, semiformal, formal), ist ein Faktor, der für spätere Korrektheitsnachweise und den erzielbaren Korrektheitsgrad wesentlich ist. Grundsätzlich dürfen an den Korrektheitsgrad eines Systems keine höheren Anforderungen gestellt werden, als die Spezifikationsmethode hergibt. Im folgenden werden die einzelnen Phasen des Phasenmodells beschrieben. Zieldefinition

Wozu

Hierunter fallen die Analyse der gestellten Aufgabe und das Erarbeiten der Ent-

Sicherheitsmodell

wicklungsziele. Für diese Arbeiten werden meist informelle Methoden verwendet, d.h. Basis ist die natürliche Sprache. Ergebnis dieser Phase ist ein Dokument mit den Entwicklungszielen, die ausdrücken, wozu etwas entwickelt werden soll. Im Kontext der IT-Sicherheit spricht man von den Sicherheitszielen. Ist im Rahmen der Sicherheitsziele die Einhaltung bestimmter Regeln (z.B. Zugriffsschutzregeln nach Bell-LaPadula für den Umgang mit eingestuften Informationen) gefordert, so spricht man von einem Sicherheitsmodell (Security Model). Ist es möglich, die Regeln formal-mathematisch aufzuschreiben, so handelt es sich um ein formales Sicherheitsmodell (Formal Security Model).

158

5.3 Produkt-Entwicklung

Vorgaben Hierunter fällt die Ermittlung und Beschreibung von technischen Anforderungen (Requirements). Damit wird beschrieben, was entwickelt werden muß, um die gesteckten Ziele erreichen zu können. Auch hier ist die natürliche Sprache das erste Beschreibungsmittel. Im Hinblick auf ein bestimmtes Qualitätsniveau können aber bereits Darstellungen in semiformaler (z.B. graphischer) oder formaler (mathematischer) Art genutzt werden; hiermit kann die Präzision der Beschreibungen erhöht werden. Im Kontext der Sicherheit spricht man von Sicherheitsvorgaben oder Sicherheitsanforderungen; sie sind also ein Teil der allgemeinen Vorgaben. Vorgaben können in sich widersprüchlich, ggf auch überhaupt nicht sinnvoll sein. Deshalb ist eine Validierung von Anforderungen notwendig. Nutzt man semiformale oder formale Sprachen zur Spezifikation, muß die übliche informelle Beschreibung der Anforderungen in eine semiformale oder formale Beschreibung umgesetzt werden. Da eine solche Umsetzung fehlerhaft sein kann, kann es zu Differenzen zwischen der informellen und der (semi-) formalen Beschreibung kommen. Überprüft werden kann bestenfalls, ob die (semi-) formale Beschreibung konsistent, also in sich widerspruchsfrei ist.

Was

Validierung

Entwurf Das Ziel dieser Phase ist die Modellierung des zu entwickelnden Produktes unter Beachtung der Vorgaben - aber ohne Betrachtung von Implementierungsdetails. Aufgrund der Vorgaben werden geeignete technischen Verfahren, Algorithmen und Prinzipien ausgewählt, die ihm Produkt verwendet werden sollen. Unter Nutzung bestimmter Beschreibungsmittel (informell, semiformal, formal) werden die Grobstruktur (Architectural Design) des zu entwickelnden Produktes und ggf. die Schnittstellen zwischen den großen Funktionsblöcken festgelegt. Die Prüfung auf Vollständigkeit und Konsistenz mit den Vorgaben ist durchzufuhren.

Was-Entwurf

Verfeinerungen Ausgehend von der Entwurfsbeschreibung wird das Wie nunmehr detailliert beschrieben. Die Systemhierarchie wird horizontal und vertikal entwickelt: Es wird eine Zerlegung in Module vorgenommen; diese werden mit ihren Aufgaben und erwünschten Ergebnissen beschrieben. Jedes Modul wird nunmehr - u.U. über mehrere Ebenen - in weitere Module zerlegt, die Schnittstellen, Parameter und globalen Variablen werden präzisiert.

159

Wie-Entwurf

5. Entwicklung

Abbildbarkeit

Nebeneffektfreiheit

Als Ergebnis liegt eine mehrstufige Systemspezifikation, der Wie-Entwurf, vor, die als schrittweise Verfeinerung der Entwurfsspezifikation betrachtet werden kann. Jede Stufe kann quasi als eine Implementierung der vorhergehenden angesehen werden. Zentrale Bedeutung hat die Abbildbarkeit der Spezifikationen zweier benachbarter Entwurfsebenen. Ist die Abbildung nachvollziehbar korrekt, so spricht man von einer korrekten Verfeinerung. Bei einer korrekten Verfeinerung fuhrt also die Ebene n+1 das aus, was die Ebene n spezifiziert. Nun könnte eine Hierarchiestufe mit der Nummer n+1 Funktionen implementieren, die in der Stufe n gar nicht spezifiziert worden sind: Die Verfeinerung ist damit nicht nebeneffektfrei. Eine Überprüfung auf Nebeneffektfreiheit ist notwendig, um z.B. trojanische Pferde auszuschließen. Nutzt man formale Beschreibungstechniken, können bei den Verfeinerungsschritten Methoden der Verifikation von Spezifikationsverfeinerungen eingesetzt werden: Damit kann bis zur niedrigsten Hierarchiestufe der Spezifikation die Korrektheit nachgewiesen werden. Implementierung

Source Code

Sprachen

Syntax

Semantik

Programmiersprachen

In der niedrigsten Hierarchiestufe der Spezifikation sind einzelne Funktionsblöcke identifizierbar (Basiskomponenten), deren Struktur nicht weiter verfeinert wird, deren Beschreibung vielmehr manuell, werkzeugunterstützt oder automatisch in ein Quellprogramm umgesetzt wird (Transformation). Hier sind die Korrektheit, Nachvollziehbarkeit und Nebeneffektfreiheit der Umsetzung zu betrachten. Ist der Nachweis positiv, so kann von einer korrekten Implementierung gesprochen werden. Werden zur Transformation formale Techniken genutzt, ist durch diese Verfeinerung der mathematische Nachweis erbracht, daß das Quellprogramm den (Sicherheits-)Vorgaben genügt. Das Programm liegt dabei als Text in einer bestimmten Sprache vor, der Implementations- oder Programmiersprache. Hinsichtlich der verschiedenen Sprachen ist folgendes zu unterscheiden: 1. Formale Sprache: Eine formale Sprache ist eine Menge von Zeichenketten. Die zur Sprache gehörenden Zeichenketten nennt man Formeln. Die Zugehörigkeit einer Formel zu einer formalen Sprache wird durch die Syntax der Sprache beschrieben. 2. Programmiersprache: Eine Programmier- oder Implementationssprache ist eine formale Sprache, deren Formeln man Programme nennt. Sie legt zugleich die Semantik ihrer Programme fest. Diese ist durch eine Abbildung von der Menge der Eingabedaten in die Menge der Ausgabedaten bestimmt. Die wichtigsten Typen von Programmiersprachen sind imperative (prozedurale) Sprachen und deklarative Sprachen.

160

5.3 Produkt-Entwicklung

Zu den imperativen Sprachen gehören konventionelle Sprachen wie C, FORTRAN, PASCAL, MODULA-2, ADA. Sie enthalten Sprachelemente zur Beschreibung der Datenstrukturen und der dazu gehörenden Operationen, sowie der Strukturierung des Programms. Es steht die ablauf- und effizienzorientierte Problemlösung, das Wie, im Vordergrund. Bei den deklarativen Sprachen werden Probleme in der ihnen eigenen Struktur beschrieben. Das Was steht im Vordergrund. Ablaufaspekte der Lösung werden nicht behandelt. Man unterscheidet • funktionale oder applikative Sprachen wie LISP, LOGO, FP, HOPE, deren einziges Mittel zum Programmaufbau der geschachtelte Funktionsaufruf ist, • objektorientierte Sprachen wie SMALLTALK, FLAVORS, LOOPS, SIMULA, bei denen Klassen von Objekten durch ihre Datentypen und die darauf zulässigen Operationen beschrieben werden, sowie • logische (prädikative) Sprachen wie PROLOG, PLANNER, bei denen die Problembeschreibung aus Fakten und Regeln für die Ableitung neuer Fakten aus bekannten Fakten besteht. Im nächsten Schritt der Implementierung wird das Quellprogramm durch einen Compiler unter Nutzung von Laufzeitbibliotheken für eine bestimmte Prozessor-Architektur in den lauffähigen Objectcode umgesetzt. Hinsichtlich der Korrektheit des gesamten Objectcodes eines Programms sind somit auch die Eigenschaften der Programmiersprache ("einwandfreie" Syntax und Semantik), ihre Umsetzung in die Maschinensprache (Anforderungen an Compiler), Eigenschaften der Maschinensprache (Struktur und Formalisierung) und des Prozessors (korrekte Ausfuhrung der Befehle) zu berücksichtigen. Überprüfung Es sind die Basiskomponenten auf korrektes Funktionieren zu prüfen. Von der Methodik her sind dafür sehr unterschiedliche Verfahren im Einsatz. Sie unterscheiden sich in ihrem Ablauf (manuelle, halbautomatische, automatische Verfahren) und im Niveau der Zusicherung (statistische Tests, Validierungen, Verifikationen). Insgesamt erhält man nach den Phasen der Anforderungen, des Entwurfs und seinen Verfeinerungen, der Implementierung und der Überprüfung ein modularisiertes Programmsystem in einer vorgegebenen Zielsprache, dessen Komponenten bzgl. der Entwurfsspezifikation korrekt sind - soweit dies die verwendete Nachweismethode garantieren kann.

161

Umsetzung

5. Entwicklung

Integration Integrationstest

Meist unter Nutzung von Werkzeugen werden die einzelnen Basiskomponenten mit ihrem aktuellen, durch die Konfigurationskontrolle erfaßten ReleaseStand zum vollständigen Produkt zusammengesetzt. Da die KomponentenPrüfung noch keine Gewähr für das Funktionieren des vollständigen Produktes bietet, muß also ein Integrationstest hier Klarheit bringen. Nach der Integrationsphase ist die eigentliche Softwareentwicklung abgeschlossen.

Prototyp

Erfahrungen mit dem skizzierten Phasenmodell zeigen, daß es sinnvoll ist, es nicht als rein sequentiellen Prozeß abzuarbeiten, sondern nach wichtigen Entwicklungsschritten einen Prototypen zu entwerfen, der das Produkt auf der betrachteten Ebene repräsentiert und im Rahmen einer Simulation dessen Eigenschaften aufdeckt. Solche Schritte könnten theoretisch in einer mehrstufigen Spezifikation in jeder Ebene eingeschoben werden. Die Erfahrungen mit dem jeweiligen Prototyp fließen in die darüberliegende Entwurfsebene (möglicherweise in noch höhere Ebenen) zurück. Die Vorteile des Prototyping liegen einfach darin, daß Fehlentscheidungen im Bereich des Entwurfs und der Spezifikation frühzeitig erkannt werden können und zu entsprechenden Korrekturen fuhren. Der Entwicklungsprozeß wird beschleunigt. Man spricht in diesem Zusammenhang auch von Rapid Prototyping. Bei diesem Verfahren ist die Produktentwicklung ein mehrstufiger, iterativer Prozeß. 5.3.2 Phasenmodell in Sicherheitskriterien Alle bekannten Sicherheitskriterien gehen implizit oder explizit davon aus, daß bei der Entwicklung von Software oder Hardware das Phasenmodell angewendet wird und eine phasenbezogene Dokumentation vorhanden ist. Dabei wird natürlich alles aus dem Blickwinkel der Sicherheit betrachtet. Die folgende Darstellung ist nicht als vollständige Analyse zu verstehen, sondern versucht, einen Überblick über die Anwendung des Phasenmodells in Sicherheitskriterien zu geben. Die IT-Sicherheitskriterien Für die IT-Sicherheitskriterien (ITSK89) und ihre Qualitätsstufen Q1 bis Q7 ist bereits in Kapitel 4 grob skizziert worden, welche Forderungen an den Nachweis der Korrektheit zu stellen sind. Im folgenden wird die Abbildung auf das Phasenmodell betrachtet.

162

5.3 Produkt-Entwicklung

Qualität der Sicherheitsanforderungen Die Anforderungen in den IT-Sicherheitskriterien beziehen sich auf Darstellung und Inhalt eines Dokumentes mit dem Namen Sicherheitsanforderungen. Es beschreibt die Phasen Zieldefinition und Vorgaben. Einen Überblick über die Anforderungen in den verschiedenen Qualitätsstufen gibt die nachfolgende Tabelle 5-1. Qualität der Spezifikation und der Implementierung Die IT-Sicherheitskriterien behandeln Anforderungen an die Abbildung der Spezifikation und der Implementierung auf die Sicherheitsanforderungen, die Identifizierbarkeit der Sicherheitsfunktionen in der Spezifikation, sowie Darstellungsart, Sprache, Tiefe und Struktur derselben. Die nachfolgende Tabelle 5-2 faßt die Forderungen zusammen. Im Phasenmodell handelt es sich um die Phasen Entwurf, Verfeinerung und Implementierung. Darstellung

Tiefe

Bezug

Sichcrheitsmodcll

Anforderungen

Prüfvorgang

1

informell

grob

-

-

-

Konsistenz

2

*

*

B

-

-

3

*

detailliert

*

-

-

4

*

*

*

-

-

5

*

*

*

Q

f ü r w e s e n t l i c h e An-

Konsistenz mit

f o r d e r u n g e n bzgl.

den A x i o m e n

Integrität und

* * *

Beweise nachvollziehen

Vertraulichkeit 6

*

*

*

7

*

*

*

f ü r alle A n f o r d e r u n g e n bzgl. Integrität und Vertraulichkeit

*

*

f ü r alle A n f o r d e r u n -

*

*

gen

Tabelle 5-1: Qualität der Sicherheitsanforderungen 1

L e g e n d e : B = B e z u g zu G r u n d b e d r o h u n g e n und G r u n d f u n k t i o n e n herstellen, - keine A n f o r d e r u n g , * g l e i c h e A n f o r d e r u n g w i e in v o r h e r g e h e n d e r Stufe, SIA = S i c h e r h e i t s a n f o r d e r u n g e n , N H S = niedrigste H i e r a r c h i e - S t u f e der S p e z i f i k a t i o n , sf = s e m i f o r m a l , D = detailliert, H = h i e r a r c h i s c h , Q C = Q u e l l c o d e

163

5. Entwicklung

Überprüfung Hinsichtlich der Überprüfungs-/Testphase wird ab der Stufe Q2 einheitlich die Existenz einer Bibliothek mit Testprogrammen sowie der zugehörigen Testdokumentation gefordert. Q Darstellung

Sprache

Tiefe Struktur Prüfung

l

verbal

natürliche Sprache

grob

2

*

3

*

4

*

5

-

-

-

*

ggf-H

ggf. Abbildung der Stufen

NHS

D

*

* + informelle Analyse

QC

sf Hilfsmittel

*

H

* + Abbildung der Stufen aufeinander

*

* + semiformal

eindeutige Syntax und sf definierte Semantik

*

*

* + sf Analyse, Abbildung durch eindeutige Regeln

*

6

* + formal

formal definierte Syntax und Semantik

*

*

* + formale Analyse, Verifikation oberste Ebene zu Sicherheitsmodell

*

7

*

*

*

*

* + Verifikation, benachbarte Ebenen

*+ Beweis

-

-

Tabelle 5-2: Qualität der Spezifikation und der Implementierung 2

2

Abbildung aufSIA von

Legende: s. S. 163

164

5.3 Produkt-Entwicklung

Integration Für die Integrationsphase gibt es in den IT-Sicherheitskriterien folgende Anforderungen: Q

Integration und A b n a h m e

2

-

3-4

Große Systeme: Software-Integrations- und -Abnahmeverfahren erforderlich (Rollentrennung: Entwickler, Tester, Abnahmeverantwortlicher)

5-7

Alle Systeme: Software-Integrations- und -Abnahmeverfahren erforderlich (Rollentrennung: Entwickler, Tester, Abnahmeverantwortlicher)

Tabelle 5-3: Anforderungen hinsichtlich Integration und Abnahme Britische Kriterien In der Tabelle 5-4 sind die Anforderungen aus (UKL89) extrahiert und im Überblick zusammengestellt. Requirements entspricht den Sicherheitsvorgaben, Architecture dem Entwurf. UKL

Requirements

Architecture

Implementation

1

natural language

-

-

2

*

disciplined

disciplined

3

Security Policy Model

distinct and identified trusted components

*

4

*

structured

*

S

formal Security Policy Model

rigorous

structured

6

*

formally verified

*

Tabelle 5-4: Assurance-Anforderungen bei UKL Die ITSEC Die grundsätzliche Struktur der ITSEC - Aufteilung der Entwicklung in Entwicklungsumgebung und Entwicklungsprozeß - wurde bereits in Kapitel 4 behandelt. Auch wenn dies sprachlich nicht ganz nachvollziehbar ist: Unter Entwicklungsprozeß werden die produktbezogenen Eigenschaften (vgl. Tabelle 55), unter Entwicklungsumgebung die prozeßbezogenen Eigenschaften diskutiert.

165

5. Entwicklung

E

Anforderungen

Architektur Feinentwurf Implementierung

1

Sicherheitsvorgaben

informell

-

2

*

*

informell

Nachweis für funktionale Tests

3

*

*

*

QC/HWZ, Nachweis für Tests der Mechanismen

4

semiformale funktionale Spezifikation, formales Sicherlieitsmodell

semiformal

semiformal

5

*

*

*

enger Zusammenhang zum Entwurf

6

formale Spezifikation der Funktionen

formal

*

*

Testnachweis (optional)

Tabelle 5-5: ITSEC: produktorientierte Aspekte - Entwicklung 3 5.3.3 Methoden des Software-Engineerings Um komplexe Software-Systeme in guter Qualität herstellen zu können, müssen gewisse Richtlinien befolgt werden: Die Planung der Software-Entwicklung muß dem gewünschten Grad an Korrektheit angemessen sein. Ordnungsgemäße Problemanalyse und entsprechender Programmentwurf tragen wesentlich zu hochwertiger Software bei. Dabei können heutige SoftwareWerkzeuge unterstützend wirken - wie z.B. CASE-Tools 4 . Bei der Software muß man vom "Spaghetticode" zum strukturierten Programm übergehen. Für gut strukturierte Programme lassen sich aussagekräftige Tests leichter definieren. Für die Analyse, den Entwurf und die Überprüfung von Software-Systemen sind eine Reihe von Methoden verfugbar. Man unterscheidet sie nach den Darstellungsarten für die benötigten Spezifikationen: informell, semiformal und formal. Diese Attribute kennzeichnen sowohl die schon erläuterten Beschreibungsarten als auch darauf aufbauende Methoden zum Nachweis der Korrektheit. Semiformale Analyse- und Entwurfsmethoden Die bekannteste semiformale Methode ist die Strukturierte Analyse nach DeMarco. Die Analyse des zu entwerfenden Systems erfolgt durch eine funktionale Modellierung: Hierfür stehen grafische Symbole für Prozesse, Datenflüs3 4

Legende: QC = Quellcode, HWZ = Hardware-Schaltpläne CASE = Computer Aided Software Engineering

166

5.3 Produkt-Entwicklung se, Speicher und Terminatoren zur Verfugung. Bei der strukturierten Analyse werden schwerpunktmäßig funktionale Zusammenhänge betrachtet. Für die Modellierung von Datenbeziehungen ist eher das Entity-RelationshipModell nach Chen geeignet. Im Lebenszyklus von Software-Systemen sind Datenbeziehungen oft stabiler als funktionale Zusammenhänge. Objektorientierte Analyse- und Entwurfsmethoden betrachten abstrakte Datentypen (Daten und die zugehörigen Operationen) als Objekte. Dabei wird versucht, das zu entwickelnde Software-System durch Klassen von abstrakten Datentypen zu beschreiben. Formale Entwurfsverfahren Formale Entwurfsverfahren benötigen eine formale Spezifikationssprache mit formal definierter Syntax und Semantik, um die gestellte Aufgabe und das erwünschte Systemverhalten eindeutig festlegen zu können. Bei diesem Entwurfsverfahren werden Verfeinerungen von Spezifikationen durch mathematische Abbildungen und Korrektheitsnachweise (Verifikation) durch mathematische Beweise erbracht. Bei manuell erstellten Programmen kamen dabei bisher die Methoden der klassischen (a posteriori) Programm-Verifikation zum Einsatz. Dabei werden Quellcode und Spezifikation eines Programms unabhängig voneinander erstellt: Die Verifikation wird danach durchgeführt. Im Gegensatz dazu garantiert die modernere Programm-Transformation a priori die Korrektheit des erzeugten Quellprogramms. Hierbei wird das Quellprogramm im letzten Verfeinerungsschritt aus den Spezifikationen erzeugt. Bekannte Spezifikationssprachen sind VDM, Z, CSP, VSE-SL für sequentielle Programme und Lotus und SDL für die Beschreibung von Übertragungsprotokollen. Es eignen sich besonders solche Sprachen, die in die Prädikatenlogik erster Stufe (PL1) übersetzbar sind. In der formalen Spezifikation werden die Menge der möglichen Eingabedaten und die Menge der möglichen Ausgabedaten definiert und die Elemente dieser Mengen in Relation gesetzt. Die wichtigsten Formen von formaler Spezifikation sind: 1. Operationelle Spezifikation: Hierbei wird durch eine Vor- und eine Nachbedingung die Relation zwischen Eingabedaten und Ausgabedaten bestimmt. Ein Programm ist Lösung der Aufgabenstellung, falls jedes Eingabedatum, das die Vorbedingung erfüllt, auf ein Ausgabedatum abgebildet wird, das die Nachbedingung erfüllt. 2. Spezifikation von abstrakten Datentypen: Ein abstrakter Datentyp bestimmt eine Menge von Daten und die auf dieser Menge zugelassenen Bearbeitungsoperationen. Die Beschreibung der Wirkungsweise dieser Operationen erfolgt durch ein Axiomensystem.

167

Post-Verifikation

Transformation

5. Entwicklung

Terminierung

Korrektheit

Modularisierung

Anweisungen einer Programmiersprache sind durch die Abbildung von der Menge der Eingabedaten in die Menge der Ausgabedaten bestimmt. Diese Abbildung ist im allgemeinen nur partiell, d.h. sie ist nur auf einer Teilmenge der theoretisch möglichen Eingabedaten definiert. Ein Programm terminiert für ein Eingabedatum, falls dieses zu dieser Teilmenge gehört, andernfalls nicht. Ein Programm heißt partiell korrekt, falls für jedes Eingabedatum, für das das Programm terminiert, das Ausgabedatum der obigen Relation entspricht. Ein Programm heißt total korrekt bzgl. der Spezifikation, falls es für jedes durch die Aufgabenstellung mögliche Eingabedatum terminiert und partiell korrekt ist. Unabhängig vom Spezifikationsstil und den Entwurfsmethoden ist die Modularisierung von Software ein entscheidender Quälitätsbeitrag. Für die Erstellung eines komplexen Systems wird vielfach die Methode der hierarchischen Modularisierung eingesetzt. Das Programmsystem wird in einzelne überschaubare Module zerlegt. Für jedes Modul wird deren Schnittstelle mit den zugehörigen Parametern sowie ggf. die globalen Variablen, auf die das Modul Bezug nimmt, spezifiziert. Die Spezifikation enthält weiterhin die Beschreibung der Datentypen und der gewünschten Funktionen. Die hierarchische Modularisierung führt in der Theorie auf zwei Verfahren: 1. Top-Down-Methode: Ausgehend von den noch nicht sehr detaillierten Vorgaben wird bei jedem Entwurfsschritt die Spezifikation von Modulen einer Ebene durch die Spezifikation der Module der nächsten Ebene konkretisiert. 2. Bottom-Up-Methode: Hierbei geht man umgekehrt vor: Schon spezifizierte Module einer Entwurfsebene werden auf der nächsthöheren Ebene zu Modulen zusammengefaßt, die der Lösung des Problems bzw. den Vorgaben näher kommen. In der Praxis hat man oft eine Mischung dieser beiden Strategien.

Implementierung

Bei der Implementierung soll ein Programm erstellt werden, das die in der letzten Spezifikationsstufe formulierte Aufgabenstellung erfüllt. Möglichkeiten zur Implementierung sind: 1. Manuelle Programmierung: Die Implementierung des Programms muß in überschaubaren, strukturierten Einheiten (Basiskomponenten) geschehen, so daß deren Beziehungen zur Spezifikation deutlich erkennbar und nachvollziehbar sind. 2. Programm-Transformation: Unter bestimmten Voraussetzungen können die Quellprogramme aus den Modulspezifikationen (halb-) automatisch generiert werden.

Überprüfung

Für die Überprüfung der Korrektheit sind verschiedene Verfahren möglich: 1. Test: Hiermit kann für eine begrenzte Anzahl von Eingabedaten überprüft werden, ob die entsprechenden Ausgabedaten eines Programms den geforder-

168

5.3 Produkt-Entwicklung

ten Bedingungen genügen. Ein Beweis der Korrektheit eines Programms bzgl. seiner Spezifikation ist durch Testen im allgemeinen nicht möglich, da dazu alle möglichen Eingabedaten und die entsprechenden Ausgabedaten überprüft werden müßten. Mit zunehmender Komplexität des Systems und zunehmender Zahl von Parametern wächst der Testaufwand schnell über alle Grenzen. Der Garantiewert von einfachen Tests ist beschränkt. 2. Validierung: Hierunter werden semiformale Verfahren verstanden, die Simulationstechniken, Schnittstellenanalyse, grafische Ablaufdiagramme, Zustandspläne usw. einsetzen. Im Ergebnis ist hier eine höhere Sicherheit der korrekten Funktionsweise als bei rein statistischen Tests zu erwarten. 3. Formale Verifikation: In solchen Verfahren wird die Korrektheit durch einen mathematischen Beweis erbracht. Gegenstand dieser Verifikation ist der Nachweis folgender Eigenschaften: 3.1 Ein Programm ist (total bzw. partiell) korrekt bzgl. einer gegebenen Spezifikation. Ausgangspunkt der klassischen Programm-Verifikation sind ein Quellprogramm und eine formale operationelle Spezifikation dieses Programms in Form einer Vor- und einer Nachbedingung. Zu beweisen ist die Korrektheit des Programms bzgl. der Spezifikation. Grundlegende Idee der klassischen ProgrammVerifikation ist die konsequente Pfadverfolgung durch das Programm (s. Abschnitt 5.6). 3.2 Eine formale Spezifikation ist eine Verfeinerung einer anderen formalen Spezifikation. Um einen Entwurf zu konkretisieren, werden Spezifikationen verfeinert. Eine formale Spezifikation S ist eine Verfeinerung einer formalen Spezifikation T, falls jedes S genügende Programm zugleich T genügt. Bei der Verifikation von Verfeinerungen muß also bei jedem Schritt überprüft werden, ob S eine (korrekte) Verfeinerung von T ist. 3.3 Die Transformation einer Spezifikation in eine imperative Programmiersprache ist korrekt. Bei der Programm-Transformation dürfen nur zulässige Transformationsregeln verwendet werden: Die Semantik des Programms muß erhalten bleiben. Damit kann schrittweise ein imperatives Programm erzeugt werden, das bzgl. der Ausgangsspezifikation korrekt ist. Angestrebt wird die weitestgehende Automatisierung der Lösung dieser Aufgaben 3.1 - 3.3 (vgl. Abschnitt 5.6 über Werkzeuge). Werkzeuge zur Unterstützung von Entwurf und Korrektheitsnachweis werden als Spezifikations- und Verifikationssysteme bezeichnet. Sie werden sinnvollerweise in die klassischen CASE-Tools integriert.

169

5. Entwicklung

5.4 Qualitätssicherung Der Hersteller eines Systems verfolgt mit der Qualitätssicherung das Ziel, im Rahmen seines Entwicklungs-, Produktions- und Auslieferungsprozesses auf die Einhaltung der Produkt- und Verfahrensspezifikationen zu achten. Eine solche Garantie wird allgemein als Qualitätsmerkmal angesehen. Aus der simplen Erfahrung, daß niemand seine eigenen Ergebnisse ausreichend sicher prüfen kann, folgt, daß eine Qualitätssicherung stets unabhängig von der Entwicklung erfolgen muß.

DIN EN 4 5 0 0 0

Die Qualitätssicherung (QS) ist Gegenstand der europäischen und internationalen Normung. Die QS bezieht sich auf alle ergebnisorientierten Prozesse wie z.B. die Entwicklung und die Evaluierung von Produkten. Die Normenreihe DIN EN 45000 regelt unter anderem den Bereich der Evaluierung und Zertifizierung von Produkten sowie der damit zusammenhängenden Akkreditierung von Prüflaboratorien (s. Tabelle 5-6). D I N EN 4 5 0 0 1 :

Rechtliche Identifizierbarkeit, Unparteilichkeit und Unabhängigkeit,

Betreiben von Prüf-

Qualifikation

laboratorien D I N EN 4 5 0 0 2 :

Verfahren, die bei der Begutachtung angewendet werden

Begutachten von Prüflaboratorien D I N EN 4 5 0 0 3 :

Verfahren, Organisation, Personal, Gutachter, Qualitätssicherungssy-

Akkreditieren v o n

stem, Vertraulichkeit, Aufzeichnungen

Prüflaboratorien D I N EN 4 5 0 1 1 :

Neutralität, Verfahren, Organisation, Personal, Qualitätssicherungs-

Zertifizieren von

system, Vertraulichkeit, Aufzeichnungen, Lenkungsgremium,

Produkten

Veröffentlichungen, Überwachung w e g e n Mißbrauch v o n Zertifikaten

Tabelle 5-6: Allgemeine Kriterien DIN EN 45000

ISO 9 0 0 0

Akkreditierungsstellen überprüfen Prüflaboratorien dahingehend, ob diese qualifiziert sind, die Prüfungen nach bestimmten technischen Regelwerken (z.B. Sicherheitskriterien) durchzufuhren. Eine Zertifizierungsstelle erkennt nach erfolgter Akkreditierung die Ergebnisse eines Prüflaboratoriums an. Die DIN ISO 9000 bis 9004 geben Vorgaben, nach denen ein modernes Qualitätssicherungssystem aufgebaut werden kann. Ein solches QS-System besteht aus verschiedenen Bausteinen, die je nach Einsatzbereich an die Gegebenheiten angepaßt werden können (Tailoring).

170

5.4 Qualitätssicherung

DIN ISO 9 0 0 0

Überblick, Leitfaden, Klärung verschiedener Grundbegriffe und Konzepte

DIN ISO 9 0 0 1 / 2 / 3

Modell der Qualitätssicherung in Design, Entwicklung und Produktion

DIN ISO 9 0 0 4

Leitfaden für alle Phasen der Qualitätssicherung

Tabelle 5-7: Kriterien ISO 9000 Das gemäß ISO 9001 zu erstellende QS-Handbuch enthält die konkreten Verfahrensbeschreibungen einer Entwicklung und die Methoden zu ihrer Überwachung. Die Einhaltung der Norm selbst ist keine Garantie für eine hohe Produktqualität, sondern bestenfalls für eine gleichbleibende Qualität. Die Normen ISO 9001, 2, 3 stellen Forderungen an die Nachweise. Das Regelwerk legt drei Stufen der Nachweisführung fest: 9001 ist die stärkste, 9003 die schwächste Anforderung. Diese Normen werden ergänzt durch einzelne Leitfäden wie ISO 9000 Teil 2 (Leitfaden für Qualitätssicherungssysteme für Dienstleistungen), ISO 9000 Teil 3 (Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software). Der Leitfaden ISO 9000 Teil 3 behandelt alle erforderlichen Aktivitäten, um hinreichendes Vertrauen darin schaffen zu können, daß ein Produkt die gewünschte Qualität besitzt. Das Vertrauen basiert aber hauptsächlich darauf, daß der Entwicklungsprozeß gemäß dieser Norm durchgeführt wurde. Anforderungen an das Produkt werden hier nicht gestellt. Im Hinblick auf die - auch für die Sicherheit wichtigen - Anforderungen bei der Software-Entwicklung definiert ISO 9000 Teil 3 die in Tabelle 5-8 aufgeführten Elemente des QS-Systems. Phasenmodell

Spezifikation der Anforderungen; Planung der Entwicklung und Qualitätssicherung; Design und Implementierung; Testen und Validieren; Abnahme; Vervielfältigung und Auslieferung; Wartung

Unterstützende

Konfigurationsmanageinent; Dokumentation;

Tätigkeiten

Qualitätsaufzeichnungen; Werkzeuge und Techniken; Schulung

Rahmenbedingungen

Qualitätssicherungssystem; Interne Auditierung; Korrekturmaßnahmen

Tabelle 5-8: ISO 9000 Teil 3 Entsprechend solcher Normen kann ein Qualitätssicherungssystem aufgebaut werden - ohne daß dabei die Qualität für einzelne Produkte festgelegt wird.

171

5. Entwicklung

Prozeß vs. Produkt

Zeitpunkt

Wartung

Spezifikation

Überprüfung

Worin besteht nun der Unterschied zwischen solchen allgemeinen Qualitätsanforderungen und den Anforderungen von Sicherheitskriterien? Qualitätsstandards wie oben aufgeführt beziehen sich auf die Prozeßqualität der Entwicklung, während Sicherheitskriterien zwar auch den Prozeß betrachten, aber im Schwerpunkt die Produkteigenschaften im Hinblick auf den Ausschluß oder die Minderung von Gefahren behandeln. Produktstandards und entsprechende Konformitätsprüfungen dagegen garantieren bestimmte Produkteigenschaften wie das Einhalten der Spezifikation, das Vorhandensein bestimmter Funktionen und Merkmale, die Korrektheit usw. Der Unterschied zwischen Prozeß- und Produktqualität wird auch noch an einem anderen Fakt deutlich: Das QS-System wird vor der Entwicklung von Produkten beschrieben und ggf. geprüft. Diese Prüfungen werden von neutralen Begutachtern durchgeführt. Bei der Anwendung von Sicherheitskriterien im Rahmen von Evaluierungen werden die Produkteigenschaften dagegen während oder nach der Entwicklung geprüft. Schnittpunkte gibt es immer dann, wenn Sicherheitskriterien Prozeßeigenschaften wie Konfigurationskontrolle und Sicherheit beim Entwickler fordern. Die ISO 9001 fordert Auditierungen, woran sich Korrekturen am QS-System anschließen können, sofern Beanstandungen vorliegen. Sicherheitskriterien betrachten solche Maßnahmen nur im Zusammenhang mit Re-Evaluierungen bei Produktänderungen. Hierbei können sich Produkt-Spezifikationen ändern. Es ist zumeist Sache von Zertifizierungsstellen, für diese Art von Wartung, aber auch für die Behandlung von nachträglichen neuen Erkenntnissen zum zertifizierten Produkt Verfahren festzulegen, die ein Update möglich machen. ISO 9001 fordert die Erstellung von Produkt-Spezifikationen, deren Einhaltung durch die QS bejaht oder verneint wird. Die Aussagen der Norm beschränken sich auf die anzuwendenden Verfahren. Die Sicherheitsvorgaben (und die weiteren Dokumente der verschiedenen Entwurfsebenen) z.B. nach ITSEC beinhalten Aussagen über Sicherheitsziele, die Bedrohungen und den entgegenwirkenden Funktionen, sowie der Wirksamkeit. ITSEC beschreibt auch die zur Überprüfung anzuwendenden Verfahren. Die bei Test- und Validierungsverfahren nach ISO 9001 auftauchenden Produktmängel werden recherchiert und fuhren möglicherweise zu einer späteren Änderung in der Entwicklung. Bei Evaluierungen nach den Sicherheitskriterien müssen erkannte Mängel sofort behoben werden; ansonsten kann eine Zertifizierung nicht erfolgen. Dort, wo Sicherheitskriterien Prozeßeigenschaften fordern - z.B. bei der Produktintegration und -abnahme, Konfigurationskontrolle, Vervielfältigung, Auslieferung, Installation und Inbetriebnahme -, können diese als eine mögliche Konkretisierung der Anforderungen von ISO 9001 angesehen werden. Beispiel: Sowohl bei ISO 9001 als auch etwa bei den ITSEC wird Konfigurationskontrolle im wesentlichen deshalb durchgeführt, um eine Nachvollziehbarkeit des Entwicklungsprozesses zu gewährleisten - wenn auch mit anderer

172

5.5 Konfigurationsmanagement

Zielrichtung: ISO 9001 will Konformität zum QS-System nachweisen, ITSEC will unbefugte Manipulation an den Produktkomponenten und ihrer Dokumentation ausschließen, d.h. es sind entsprechende materielle, organisatorische und personelle Sicherungsmaßnahmen in der Entwicklungsumgebung zu treffen. Werkzeuge werden nach ISO 9 0 0 1 insbesondere zur Lenkung von Prozessen, in Sicherheitskriterien dagegen zum Nachweis des Ausschlusses von Sicherheitslücken eingesetzt. Beide Ansätze - prozeßbezogene Qualitätsnormen und produktbezogene Sicherheitskriterien - können sich ergänzen. Ein quantitativer Vergleich im Sinne von "Welcher Ansatz bietet wieviel Qualität oder Sicherheit?" ist aber nicht möglich.

Werkzeuge

Faz

't

5.5 Konfigurationsmanagement Unter das Konfigurationsmanagement fallen alle Objekte eines Entwicklungsverfahrens, an denen Änderungen vorgenommen werden können, die für die Qualität des Produktes und des Entwicklungsverfahrens ausschlaggebend sein können. Hierzu zählen: • Eingesetzte Werkzeuge (Compiler, Linker, Generatoren usw.), • Testumgebungen und -verfahren, • Dokumentationen (auf allen Entwurfsebenen), • Quellcode-Module, • Objectcode-Module, • Handbücher. Das Konfigurationsmanagement muß eine Konfigurationskontrolle (Configuration Control) einrichten, die sicherstellt, daß alle genannten Objekte ordnungsgemäß verwaltet und genutzt werden: • Während der Entwicklung sollen nur Personen Operationen (Ändern, Ergänzen, Löschen usw.) auf Objekten durchführen, die dazu befugt sind. • Aktionen von Personen sollen (in bestimmten Sicherheitsstufen) protokolliert werden. • Objekte müssen mit ihrem Entwicklungsstand ("in der Entwicklung", "im Test", "fehlerhaft", "als korrekt abgenommen",...) und mit ihrer Versionsnummer gekennzeichnet sein. • Aus den verwalteten Objekten müssen bestimmte Produktversionen (ältere oder die aktuelle) auf Anforderung erzeugt werden können. Auch wenn ein manuelles Konfigurationsmanagement möglich ist, so wird doch bei komplexen Entwicklungen mit vielen Objekten und Versionen eine Werkzeugunterstützung durch ein Konfigurationskontrollsystem vorzuziehen sein.

173

Konfigurations-

kontrolle

5. E n t w i c k l u n g

I m K o n t e x t der I T - S i c h e r h e i t ist e s v o r d e m H i n t e r g r u n d v o n M a n i p u l a t i o n e n n o t w e n d i g , e i n e Rollentrennung

im E n t w i c k l u n g s b e r e i c h , e i n e

le b z g l . d e r s e n s i t i v e n O b j e k t e , vertrauenswürdiges e i n sicheres

Auslieferungsverfahren

Zugriffskontrol-

Entwicklungspersonal

und

einzusetzen.

D i e g ä n g i g e n K r i t e r i e n w e r k e stellen d e s h a l b A n f o r d e r u n g e n a n d i e K o n f i g u r a t i o n s k o n t r o l l e (s. T a b e l l e n 5 - 9 bis 5 - 1 1 ) . Konfigurationskontrolle

Q 2

-

3

Versions- und Änderungskontrolle zwingend

4

*

5

Bei mehr als 5 Entwicklern: Konfigurationskontrollsystem erforderlich (Rollen: Spezifizierer, Implementierer und Tester), Protokollierung erforderlich

6

Konfigurationskontrollsystem erforderlich (diskrete und rollenabhängige Zugriffskontrolle zu allen Objekten), Protokollierung aller Modifikationen

7

*

T a b e l l e 5 - 9 : K o n f i g u r a t i o n s k o n t r o l l e in d e n I T - S i c h e r h e i t s k r i t e r i e n UKL

Konfigurationskontrollc

1

good Industry practice

2

ensure that the evaluation results remain valid during operational use

3

changes to the trusted components of the architecture must be strictly controlled

4

changes to the architecture must be strictly controlled

5

changes to the architecture and the implementation must be strictly controlled

6

*

T a b e l l e 5 - 1 0 : Konfigurationskontrolle bei U K L E

Konfigurationskontrolle

1

eindeutige Identifikation des Produktes

2

Konfigurationskontrollsystem erforderlich

3

Abnahmeprozedur

4

werkzeugunterstützte Konfigurationskontrolle, mit Protokollierung

5

Kontrolle aller Objekte, Rollentrennung erzwingen

6

Werkzeuge unterliegen der Konfigurationskontrolle

T a b e l l e 5 - 1 1 : K o n f i g u r a t i o n s k o n t r o l l e in d e n I T S E C

174

5.5 Konfigurationsmanagement

Der Vollständigkeit halber sei eine Passage aus dem Orange Book aufgeführt, die zeigt, welche Anforderungen an die Konfigurationskontrolle bei der Entwicklung gestellt werden. Erstmalig tauchen solche Forderungen bei der Stufe B2 auf: "During development and maintenance of the TCB, a configuration management system shall be in place that maintains control of changes to the descriptive top-level specification, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. The configuration management system shall assure a consistent mapping among all documentation and code associated with the current version of the TCB. Tools shall be provided for generation of a new version of the TCB from source code. Also available shall be tools for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB." In den IT-Sicherheitskriterien wird hinsichtlich der Vertrauenswürdigkeit des Personals fiir die Stufe Q7 gefordert, daß das Entwicklungspersonal überprüft sein muß. Bei den ITSEC werden personelle Sicherheitsmaßnahmen ab der Stufe E2 gefordert.

Personal

An die Produktauslieferung (Product Delivery) werden folgende Anforderun-

Auslieferungs-

gen gestellt:

verfahren

Von den IT-Sicherheitskriterien wird ab der Stufe Q2 ein zugelassenes Verfahren für die Erkennung von Übertragungsfehlern, ab Q5 zusätzlich ein zugelassenes Verfahren für die Software-Verteilung gefordert. Die ITSEC fordern ab der Stufe E2, daß ein von der nationalen Zertifizierungsstelle für diese Stufe zugelassenes Verfahren angewendet wird, das die Authentizität des ausgelieferten Produktes garantiert. Das Orange Book beschreibt Auslieferungsverfahren unter dem Stichwort Trusted Distribution. Sie wird aber erst ab der Stufe AI verlangt: "A trusted ADP system control and distribution facility shall be provided for maintaining the integrity of the mapping between the master data describing the current version of the TCB and the on-site master copy of the code for the current version. Procedures (e.g., site security acceptance testing) shall exist for assuring that the TCB software, firmware, and hardware updates distributed to a customer are exactly as specified by the master copies."

175

5. Entwicklung

5.6 Werkzeuge Im Bereich der System-Entwicklung sind zunächst Basiswerkzeuge wie Compiler, Linker, Debugger gebräuchlich: Anforderungen an die Sprachen und Compiler stellt (ITSK89) ab der Qualitätsstufe Q3, an Werkzeuge ab der Stufe Q4. Die Tabelle 5-12 gibt eine Zusammenfassung. Sprachen

Q

Werkzeuge

Syntax

Semantik

Compiler

Evaluierung

3

e i n d e u t i g definiert

gut d o k u m e n t i e r t

-

-

4

*

*

geprüft

-

validiert

-

5

6

genormt, formal

sehr gut doku-

definiert

mentiert

*

*

*

7

f o r m a l definiert

validiert + z u g e l a s sen f ü r d i e s e S t u f e

qualifizierte QCund MC-Debugger

*

*

Tabelle 5-12: IT-Sicherheitskriterien: Sprachen und Werkzeuge 5 Als "validiert" werden solche Compiler bezeichnet, deren Korrektheit gegenüber einem akzeptierten Standard (z.B. von ANSI) durch eine anerkannte Institution nachgewiesen worden ist. Inhaltlich schwächere Anforderungen haben die ITSEC (vgl. Tabelle 5-13). E

Programmiersprachen + Compiler

3

klar d e f i n i e r t (z.B. I S O - S t a n d a r d ) , i m p l e m e n t i e r u n g s a b h ä n g i g e O p t i o n e n m ü s s e n d o k u m e n t i e r t sein, e i n d e u t i g e Semantik

4

C o m p i l e r - O p t i o n e n m ü s s e n d o k u m e n t i e r t sein

5-6

Q C der L a u f z e i t b i b l i o t h e k erforderlich

Tabelle 5-13: ITSEC: Anforderungen an Sprachen und Werkzeuge 5 Weitere Werkzeuge im Entwicklungsprozeß sind: • Software-Entwicklungswerkzeuge (CASE-Tools) für die Analyse und den Entwurf: Unterstützung bei Dokumentation und Generierung von Quellcode in verschiedenen Zielsprachen; Versionskontrolle mit Generierung der aktuellen Versionen (sowohl Software als auch Dokumentation) • Testwerkzeuge, Testsuites: Generierung von Testfällen auf Basis der Spezifikation, automatische Durchfuhrung und Bewertung von Tests 5

Legende: Q C = Quellcode, M C = Maschinencode

176

5.6 Werkzeuge

• Reverse-Engineering Tools: Für bislang undokumentierte Programme (Altlasten) können Spezifikationen generiert werden, die die weitere Pflege, Anpassung und Korrektur erleichtern. • Spezifikations- und Verifikationswerkzeuge: Meist eingebettet in CASETools, Unterstützung bei der syntaktisch korrekten Eingabe von Spezifikation, Unterstützung von Verifikationsarbeiten

Ein Spezifikations- und Verifikationssystem (SVS) besteht im wesentlichen SVS aus drei Teilwerkzeugen: 1. Der Vorübersetzer (Syntax Checker): Er überprüft die Syntax der Implementation und Spezifikation. Bei Fehlerfreiheit erzeugt er dann aus den Eingabetexten eine interne Darstellung, die dem VCG übergeben wird. 2. Der Verifikationsbedingungserzeuger VCG (Verification Condition Generator) erzeugt mathematisch-logische Formeln, meist der Prädikatenlogik erster Stufe. Er geht dabei üblicherweise von der Nachbedingung aus und verfolgt den Programmablauf rückwärts. Für jede Anweisung auf einem Pfad und der dazu gehörenden Nachbedingung wird die Semantik der Anweisung nachgebildet und die Nachbedingung in eine schwächste Vorbedingung der Anweisung transformiert. Die so abgeleitete Vorbedingung wird als Nachbedingung für die nächste Anweisung aufgefaßt. Wenn man den Pfad in dieser Weise sukzessive abgearbeitet hat, bleibt noch zu zeigen, daß aus der Vorbedingung der Spezifikation die abgeleitete Vorbedingung des Pfades logisch folgt. Dies ist schließlich die noch zu beweisende Verifikationsbedingung. 3. Der (automatische) Beweiser (Theorem Prover): Die vom VCG erzeugten Verifikationsbedingungen müssen formal bewiesen werden. Eine manuelle Beweisführung ist selbst bei kleineren Programmen sehr mühsam und fehleranfällig. Deshalb benötigt man einen weitgehend automatisch arbeitenden Beweiser. Der Grad der Automatisierung variiert zwischen zwei Extremen: Bei einem Beweisprüfer {Prove Checker) liegt die Steuerung vollständig beim Benutzer. Automatisiert ist lediglich die Überprüfung der korrekten Anwendung und die Ausfuhrung einer Ableitungsregel. Bei einem vollautomatischen Beweiser wird die Steuerung nicht durch den Benutzer beeinflußt. Im Bereich der IT-Sicherheit sind Spezifikations- und Verifikationssysteme erstmalig in den USA eingesetzt worden: Hierzu zählen EHDM (Enhanced Hierarchical Development Methodology), FDM (Formal Development Methodology) und GVE (Gypsy Verification Environment). Tools, die für eine Evaluierung nach dem Orange Book zugelassen sind, werden vom NCSC in der Endorsed Tools List (ETL) registriert. Die Anforderungen, die an entsprechende Tools gestellt werden, sind in (NCSC89) angegeben.

177

Beweisprüfer, automatischer Be-

5. Entwicklung

Das genannte Spezifikations- und Verifikationssystem G V E bedient sich für die Spezifikation und die Implementierung der Sprache Gypsy, die sowohl deklarative wie auch imperative Elemente besitzt. Sie ist der Programmiersprache P A S C A L ähnlich. Das folgende Beispiel zeigt die Spezifikation und Implementierung folgender Aufgabe unter Gypsy: Es soll die Summe der ersten n Zahlen berechnet werden. 1. Spezifikation: Die Spezifikation beschreibt die gestellte A u f g a b e als rekursives Verfahren: function sum (n: integer): integer = begin exit (assume result = if n eq 1 then 1 eise n + sum (n-1) fi); end; Diese Zeilen beschreiben das Was - bis auf die Notation praktisch eine Umsetzung der rekursiven Summenformel S = S , + n. ° n n-1 2. Implementierung: Die Implementierung ist bis auf einige spezielle Anweisungen leicht nachvollziehbar: Sie verwendet die übliche Summationsschleife, setzt zu Beginn den Summenwert zu Null und addiert bei j e d e m Schritt die nächste Zahl: function S (n: integer): integer = begin entry n gt 0; exit result = sum (n) ;

var i: integer := 1; result := 0; loop assert result = sum(i-l) & i>l;

result := result + i; if i = n then leave eise i := i + 1 end; end; end; Die durch Fettdruck hervorgehobenen Zeilen sind solche, die gewisse Annahmen über Parameterwerte, Ergebnisse früherer Programmschritte usw. formulieren. Sie sind wichtig für den Verifikationsprozeß: Es handelt sich u m die Vor- und Nachbedingungen (jeweils für den darauf folgenden Programmblock). Übergibt man Spezifikation und Implementation dem GVE-Tool, so können automatisch Verifikationsbedingungen erzeugt werden, deren Korrektheit mit interaktiver Unterstützung durch einen Experten bewiesen werden.

178

5.7 Wartung

Basierend auf der Spezifikationssprache VSE-SL hat in Deutschland das BSI ein Spezifikations- und Verifikationstools VSE (Verification Support Environment) entwickelt. An Werkzeuge zur Softwareentwicklung sind hohe Qualitätsanforderungen zu stellen. Entsprechende Prüfverfahren werden in diesem Kontext nicht Evaluierung, sondern Validierung genannt. Sie muß sich an Kriterien orientieren. Solche Kriterien dienen auch als Maßstab für die Werkzeug-Entwicklung. In Deutschland wurde vom BSI ein Kriterienkatalog (TOOL90) für die Entwicklung, Realisierung und Zulassung von Spezifikations- und Verifikationssystemen erarbeitet. Er ist im Zusammenhang mit der Aufgabe entstanden, ITProdukte nach den hohen Stufen E4 - E6 der ITSEC bzw. Q4 - Q7 der IT-Sicherheitskriterien zu evaluieren.

Qualität

5.7 Wartung Der Betreiber bzw. Anwender von IT-Systemen wird entsprechend seinen Anforderungen Produkte prüfen, erwerben und installieren. Im Rahmen des Abnahmeverfahrens wird überprüft und festgehalten, ob alle Anforderungen erfüllt sind bzw. wie hoch der Erfüllungsgrad ist. Im günstigen Fall liegt das anforderungsgerechte Produkt vor. Zum Zeitpunkt der Auslieferung des Produktes sind aber in aller Regel noch nicht alle Fehler erkannt. Die im Betrieb aufgedeckten Fehler fuhren entweder zu geänderten Einsatzbedingungen beim Betreiber oder zu Änderungen am Produkt beim Hersteller, was in die Phase der Software-Wartung fällt.

179

Software-Wartung

6. Evaluierung Für die Prüfung von IT-Produkten und -Systemen 1 gibt es zwei unterschiedliche Nachweisziele: 1. Bestätigung der Erfüllung bestimmter Produkteigenschaften, die in einem Standard oder einer technischen Vorgabe festgelegt sind (Konformitätsprüfung gegenüber einer Spezifikation); 2. Ausschluß von Sicherheitslücken gegenüber den Bedrohungen wie etwa Verlust der Vertraulichkeit, Verfügbarkeit oder Integrität (Evaluierung nach Sicherheitskriterien). Prüftingen hinsichtlich der Ordnungsmäßigkeit sind im Kern vom ersten Typ, Evaluierungen z.B. nach den ITSEC vom zweiten Typ. Diese Unterscheidung ist allerdings nicht überschneidungsfrei: Zur Aufrechterhaltung der Sicherheit werden Sicherheitsfiinktionen benötigt. Dabei wird natürlich vorausgesetzt, daß diese Sicherheitsfiinktionen so funktionieren wie spezifiziert. Die folgenden Abschnitte befassen sich im Schwerpunkt mit der Evaluierung von Produkten nach Sicherheitskriterien. Eine andere Form der Evaluierung ist die Evaluierung eines Prozesses, z.B. des Entwicklungsprozesses von Produkten bei einem Hersteller. Solche ausschließlich prozeßbezogenen Evaluierungen werden z.B. auf der Grundlage der ISO 9000 Reihe durchgeführt (vgl. Kapitel 5). Um die für ein Produkt spezifizierten Sicherheitsziele erreichen zu können, ist entscheidend, daß 1. die Bedrohungen und die dagegen wirkenden Sicherheitsfiinktionen festgelegt werden, 2. die Korrektheit der Implementierung geprüft und 3. die Wirksamkeit analysiert und bewertet wird. Sicherheitskriterien legen solche Anforderungen fest - meist bezogen auf bestimmte Stufen der Vertrauenswürdigkeit (Sicherheitsstufen, Qualitätsstufen). Insofern können diese Kriterien zunächst als Vorgaben oder Leitlinien für die Entwicklung von Produkten (Zielrichtung Entwickler/Hersteller) dienen. Darüber hinaus wird auch festgelegt, was im Hinblick auf die Anforderungen zu prüfen bzw. zu evaluieren ist, d.h. was der Evaluator zu tun hat. So gesehen sind Sicherheitskriterien gleichzeitig Prüfkriterien (Zielrichtung Evaluator). Weniger detailliert ist festgeschrieben, wie die einzelnen Prüfschritte praktisch durchzuführen sind (Vorgehensweise, Methoden, Werkzeuge). Solche Angaben findet man - allerdings nur bis zu einer bestimmten Tiefe - in Evaluations-

Im folgenden wird für IT-Produkte

und -Systeme

einheitlich das Wort Produkt

verwendet.

181

Entwicklung Evaluierung

6. Evaluierung

Anwendung

handbüchern wie (ITEH90) und (ITSEM93), die die entsprechenden Sicherheitskriterien ergänzen. Kriterienwerke beschäftigen sich oft nicht nur mit technischen Qualitäten (Produkt und Entwicklungsprozeß), sondern betrachten bei der Evaluierung die angenommene oder tatsächliche Anwendung. Hieraus ergeben sich meist wichtige Hinweise für einen sachgerechten Einsatz und damit für den Anwender. Wegen Punkt 3 (Wirksamkeitsanalyse) und der Zielrichtung, Sicherheitslücken zu erkennen, ist klar, daß das Ergebnis entsprechender Penetrationstests davon abhängt, wer mit welcher Erfahrung wie und unter welchen Bedingungen prüft. Trotz gleicher Kriterien kann es bei unterschiedlichen Evaluatoren zu unterschiedlichen Ergebnissen kommen. Die Subjektivität der Auslegung und Anwendung ist das Hauptproblem aller gängigen Sicherheitskriterien. Dem können verschiedene Maßnahmen entgegenwirken: gemeinsame Schulung der Evaluatoren, einheitliche Anwendung der Kriterienwerke, zentrale Überwachung aller Prüfungen durch eine Zertifizierungsstelle, weitgehende Normierung aller Verfahrensschritte und Dokumente. Diese Maßnahmen sind jedoch nicht Gegenstand dieses Buches. Vielmehr sollen die technischen Grundprinzipien von Evaluierungen nach Sicherheitskriterien diskutiert werden.

6.1 Reduktion der Komplexität Abgrenzung

Separation

Kapselung

Schon einfache PC-Sicherheitsprodukte, erst recht aber große Betriebssysteme und Anwendungssoftware entziehen sich zumeist wegen ihrer Komplexität und ihres Umfangs einer vollständigen, detaillierten Prüfung. Eine solche alles abdeckende Prüfung ist für den Kontext der IT-Sicherheit auch gar nicht nötig: Zunächst ist intuitiv klar, daß nur die Sicherheitsfunktionen geprüft werden müssen, die nur einen beschränkten Teil eines Produktes ausmachen. Die Implementierung von Authentisierung und Zugriffskontrolle umfaßt oft nur wenige hundert Statements einer höheren Programmiersprache, so daß theoretisch alles machbar bleibt. Nun ergibt sich aber in der Praxis oft das Problem, daß Sicherheit im nachhinein in existierende Software-Pakete hineinkonstruiert wurde und somit an unzähligen Stellen sicherheitsrelevante Programmteile vorhanden sind, die nicht von den übrigen Funktionen zu trennen sind. Damit sind die Sicherheitsfunktionen als Ganzes kaum identifizierbar. Bei solchen Produkten ist man schnell wieder bei der vollständigen Prüfung. Nehmen wir an, daß durch konstruktive Vorkehrungen (Aufteilung in Module, sauberer Architekturentwurf) alle Sicherheitsfunktionen überschaubar und vom Rest separiert sind. Soll nun ein Betriebssystem vor einer Manipulation seiner ihm anvertrauten Objekte schützen, so müssen die Authentisierung und die Zugriffskontrolle selbst vor Manipulationen geschützt sein. Andernfalls würden

182

6.1 Reduktion der Komplexität

Personen in manipulativer Absicht die Sicherheitsfunktionen ändern, ihr Zusammenwirken beeinträchtigen oder ihre Funktion auf andere Art umgehen können. Dies fuhrt im Ergebnis dazu, daß eine Kapselung oder Abschottung der Sicherheitsfunktionen zu fordern ist. Dies kann in der Praxis durch eine besondere Prozessor-Architektur (Schutz auf Task-Ebene), das Memory Management (Speicherschutz) und geschützte Speicherung auf externen Medien erreicht werden. Damit aber nicht genug: Die Sicherheitsfunktionen selbst können nicht absolut unabhängig vom großen Rest des Systems arbeiten, sondern sind über Schnittstellen auf vielfache Weise mit der Außenwelt verbunden. Hierüber könnten die Sicherheitsfunktionen in bestimmter Absicht zu falschen Aktionen veranlaßt werden. Eine Validierung der Schnittstelle ist deshalb unerläßlich, um die Abwehr inkonsistenter, kontextbezogen unzulässiger Befehle zu garantieren. Aus zeitökonomischen Gründen bei der Programmierung, aber auch aus Speicherplatzgründen kommt man nicht umhin, daß wiederkehrende Verarbeitungen in dafür bestimmten Modulen oder Unterprogrammen ausgeführt werden. Solche Dienstprogramme (Beispiel: Sortieralgorithmen) werden vom gesamten System und somit auch von den Sicherheitsfunktionen genutzt. Werden solche Dienstprogramme manipulativ geändert, kann dieses die Gesamtsicherheit beeinflussen. Für diese Art von Programmen ist also die Korrektheit und Authentizität der entscheidende Punkt - sie erbringen aber nicht direkt Schutzleistungen. Damit haben wir grafisch folgendes Strukturbild für jedes IT-Produkt oder ITSystem:

Abbildung 6-1: Abgrenzungsproblematik

183

Schnittstellen

6. Evaluierung

Orange

Book

ITSEC

Vom nicht vertrauenswürdigen "Rest der Welt" ist der (in Stufen) vertrauenswürdige Teil getrennt. Konkret ist die Frage zu stellen, ob der vertrauenswürdige Teil durch den nicht vertrauenswürdigen Rest getäuscht oder umgangen werden kann. Eine damit eng zusammenhängende Frage ist, ob der "Rest" Funktionen des vertrauenswürdigen Teils vortäuschen kann. Im amerikanischen Orange Book werden die beiden inneren Bereiche (Sicherheitskern und ergänzende Dienste) als TCB - Trusted Computing Base bezeichnet. Die Evaluierung nach dem Orange Book hat deshalb die beiden Ziele, 1. die Abgrenzung (Separation und Kapselung) der TCB nachzuweisen, aber 2. nur für die TCB Korrektheit und Wirksamkeit im Hinblick auf die Sicherheitsziele zu beurteilen. Die ITSEC unterscheiden alle drei Bereiche, fordern 1. für den Sicherheitskern eine detaillierte Evaluierung gemäß der gewünschten E-Stufe, 2. für die ergänzenden Dienste eine Korrektheits- und Authentizitätsprüfung, 3. eine Analyse der Wirksamkeit der Abgrenzung zum Rest der Welt. Die im Sicherheitskern realisierten Funktionen werden in den ITSEC sicherheitsspezifische Funktionen genannt. Die unter "ergänzende Dienste" einzureihenden Funktionen heißen sicherheitsrelevante Funktionen. Der Rest ist nicht sicherheitsrelevant.

Konstruktion

Neuentwicklungen

Altlasten

Grundsätzlich gilt: Je kleiner der Sicherheitskern und der Graubereich (ergänzende Dienste) sind, um so leichter und weniger aufwendig ist eine Prüfung des Produktes, eine um so höhere Sicherheitsstufe ist erreichbar. Die Präzision und Strenge, mit der das Produkt Separation und Kapselung durchhalten kann, ist darüber hinaus ein zentrales Sicherheits- und Qualitätsmerkmal. In neu zu entwickelnden Produkten können solche Aspekte von Anfang an berücksichtigt werden: Beim Design können die Sicherheitsfunktionen zusammengefaßt, in wenigen Modulen konzentriert, mit besonderen Schutzfunktionen der Hardware unterlegt sein. Problematisch ist die Abgrenzung in existierenden Produkten, bei deren Design seinerzeit Sicherheitseigenschaften kaum eine Rolle gespielt haben. In der Praxis umfaßt dort der Sicherheitskern große Teile des realen Produktes oder ist sogar mit dem Gesamtprodukt gleichzusetzen. Damit ist die Prüfbarkeit, Verifizierbarkeit usw. nicht mehr in der Tiefe möglich, die für eine sehr hohe Sicherheitseinstufung erforderlich ist. Die Anforderungen in den Sicherheitskriterien beziehen sich auf die Dokumentation, Implementierung, Täuschbarkeit und Umgehbarkeit der Schnittstellen zwischen den vertrauenswürdigen und den nicht vertrauenswürdigen Teilen. In

184

6.2 Dokumentation

höheren Stufen wird darüber hinaus die Analyse und Protokollierbarkeit verdeckter Kanäle gefordert sowie deren Bandbreite begrenzt. Die Tabelle 6-1 gibt einen Überblick über die Forderungen zur Abgrenzung bei den IT-Sicherheitskriterien (ITSK89). Man beachte, daß dabei jede Qualitätsstufe Q n die Forderungen der tieferen Stufe Q n _i enthält. In der Spalte "Mechanismen" ist eine Bewertungsstufe für die Stärke des Mechanismus der Abgrenzung eingetragen. Die Noten entsprechen der Definition in Abschnitt 4.2.2, d.h. es ist zu fragen, mit welchem Aufwand, mit welchen Hilfsmitteln und mit welchen Kenntnissen die Abgrenzung durchbrochen werden kann. In allen Stufen Q1 - Q7 darf die Beschreibung der Abgrenzung informell sein. Es müssen die Schnittstellen dokumentiert und die Aufgaben einzelner Funktionen und ihre Parameter beschrieben sein. Stufe Mechanismen

Qi

mindestens

Prüfvorgang

verdeckte Kanäle

Test der Schnittstellen

-

stark Q2

*

*

Q3

*

Stichproben im Quellcode

Q4

mindestens sehr stark

volle Quellcode-Überprüfung, Ausschluß anderer Schnittstellen

Q5

*

Q6 Q7

-

-

-

Bandbreite verdeckter Kanäle bestim-

Protokollierung verdeckter

men

Kanäle

*

Überprüfung im Maschinencode

Bandbreite < 1 0 Bit/Sek.

nicht über-

*

Bandbreite