Inhaltsverzeichnis

Inhaltsverzeichnis   

Seite   

1.  Übersicht.  1

Teil  1: Grundlagen des Auditing.  3

2.  Einführung  4

2.1  Fallschilderung  4

2.2  Protokollierung in der Informationstechnik.  6

2.2.1  Übertragungsprotokolle  6

2.2.2  Übersetzungsprotokolle  6

2.2.3  Datenbank-Logs  7

2.2.4  Auditprotokolle  7

2.3  Protokollierung und Zugriffsschutz  9

2.4  Das Auditing im Zeitablauf.  11

3.  Zweck der Protokollierung.  13

3.1  Schutz durch Abschreckung  13

3.2  Beweissicherung.  14

3.3  Fehlerfindung  15

3.4  Kostenverrechnung.  15

3.5  Auslastungsfeststellung  16

3.6  Erfüllung gesetzlicher Vorgaben  16

3.7  Allgemeines Ziel der Protokollierung.  18

Inhaltsverzeichnis

4.  Allgemeine Probleme der Protokollierung.  20

4.1  Platzbedarf.  20

4.2  Zeitaufwand.  21

4.3  Schwierigkeiten der Auswertung im Verbund  22

4.4  Schutz der Protokolldatei.  23

4.5  Interpretationsbedürftige Protokolldaten  24

4.6  Die Ortsbestimmung der Datenhaltung im Netz.  25

5.  Das Aufzeichnen.  28

5.1  Protokollierungsintensität  28

5.1.1  Systembezogene Kriterien.  31

5.1.2  Anwenderbezogene Kriterien.  32

5.2  Technische und logische Aktionen  33

5.2.1  Protokollierung technischer Aktionen  33

5.2.2  Protokollierung logischer Aktionen  34

5.3  Protokollierung in Trusted-Database-Management-Systemen  35

5.4  Beweiskräftiges Aufzeichnen  38

5.4.1  Sichere Personenidentifikation.  39

5.4.2  Technische Sicherungen  40

5.4.3  Mathematische Sicherungen  40

6.  Die Auswertung des Protokolls.  41

6.1  Das Entdecken von Angriffen  41

Inhaltsverzeichnis

6.2  Online-Auswertungen.  41

6.2.1  Stichproben durch das Personal.  42

6.2.2  Auswertung durch den Rechner  43

6.3  Offline-Auswertungen  48

6.3.1  Manuelle Auswertungen.  48

6.3.2  Auswertungen mit Abfragesprachen  49

6.3.3  Programmierte Recherchen  49

7.  Datenstrukturen und Ablauforganisation.  51

7.1  Intensive Protokollierung.  51

7.1.1  Seitenweises Abspeichern  51

7.1.2  Zeitlich lineare Speicherung.  52

7.1.3  Event-Logs  53

7.2  Häufige Auswertungen  54

7.2.1  Ressourcenorientierte Zeigerstruktur.  54

7.2.2  Anwenderorientierte Zeigerstruktur.  56

7.2.3  Sitzungsorientierte Zeigerstruktur  56

8.  Protokollierung in bestehenden Systemen.  57

8.1  Spezielle Werkzeuge für den Datenschutz  57

8.1.1  CA-Unicenter  57

8.1.2  Resource Access Control Facility (RACF)  58

8.2  Datenbanksysteme.  58

8.2.1  ORACLE  58

Inhaltsverzeichnis

8.2.2  ADABAS.  60

8.3  Betriebssysteme  61

8.3.1  SINIX.  61

8.3.2  BS2000.  62

8.4  Ein Zugangskontrollsystem  64

Teil  2: Der Fachentwurf eines Auditsystems  66

9.  Anforderungen an ein Auditsystem.  67

9.1  Die Hardwareumgebung.  67

9.2  Die Softwareumgebung.  68

9.3  Die Oberfläche.  69

9.4  Aufzuzeichnende Aktionen  70

9.5  Die Auswertungsrechte.  71

9.6  Das Zeitverhalten der Auswertungskomponente  72

9.7  Aktive Reaktionsmöglichkeiten des Systems.  72

10.  Andere Entwicklungen.  73

11.  Das Datenmodell des Auditsystems  76

11.1  Die Struktur der Protokolldatensätze  76

11.2  Die Profildatenstruktur.  84

Inhaltsverzeichnis

12.  Die Schnittstellen.  92

12.1  Die Oberfläche für den Systemadministrator.  92

12.2  Die Schnittstelle für den Anwendungsentwickler  104

13.  Funktionale Eigenschaften des Auditsystems.  109

13.1  Die Steuerung  109

13.2  Die automatisierte Online-Auswertung (OA)  110

13.3  Die Offline-Auswertung  116

13.4  Die Integration der Notebookaktionen  117

14.  Szenarien.  119

14.1  Ein lokaler Anwender  119

14.2  Datenabfrage per DFÜ.  123

14.3  Eine Netzauswertung.  125

15.  Zusammenfassung  130

Literaturliste.   132

Glossar   135

Abbildungsverzeichnis

____________________________________________________________

Abbildungsverzeichnis

Abb. 1 Protokollierung als verfolgende Maßnahme .............................................10

Abb. 2 Auditing über den gesamten Zeitablauf.....................................................11 Abb. 3 Verhältnis von Kosten und Nutzen bei der Protokollierung....................20 Abb. 4 Das Verhältnis zwischen Aufklärungserfolg und Auditingkosten...........31

Abb. 5

Abb. 6

Abb. 7 Auszug aus einer zeitlich linearen Protokollierung...................................52 Abb. 8 Nutzdatensätze, Protokolldatensätze und deren Verbindungen ..............55 Abb. 9 Protokollausschnitt mit zwei Anwendern .................................................56 Abb. 10 Datenausgabe im Zugangskontrollsystem des Produkts ZUPEM ...........65

Abb. 11

Abb. 12 Der Auditmechanismus als eine Anwendung...........................................69 Abb. 13 Zugriffsrechte der Rechner im Verbund....................................................71 Abb. 14 Die Oberfläche im ISOA-Projekt ...............................................................74

Abb. 15

Abb. 16

Abb. 17 Aufbau der Hauptfenster des Auditsystems .............................................93

____________________________________________________________________

Abbildungsverzeichnis

____________________________________________________________

Abb. 18

Abb. 19 Fenster zur Einstellung der Intensitätsstufen ............................................95

Abb. 20

Abb. 21 Recherchemaske für die Suche nach aufgezeichneten Aktionen ............97

Abb. 22

Abb. 23 Die Auswertergebnisse in der Trefferliste .................................................98 Abb. 24 Das Fenster für die Ausgabe der Rechercheergebnisse............................99 Abb. 25 Fenster zur Eingabe neuer Profildatensätze ..............................................100

Abb. 26

Abb. 27

Abb. 28 Die wesentlichsten Aufgaben der Steuerung. ...........................................109 Abb. 29 Grobübersicht über die Funktionalität des Auswertsystems ...................111

Abb. 30

Abb. 31

Abb. 32 Alle Server in Oberbayern werden an der Recherche beteiligt ................127

Abb. 33

____________________________________________________________________

Abbildungsverzeichnis

____________________________________________________________

Abb. 34

Abb. 35

Abb. 36 Zugriffsschutz und Auditing ohne Zeitverlust ..........................................131

____________________________________________________________________

Übersicht

____________________________________________________________

1. Übersicht

Diese Studie behandelt im Bereich der Computersicherheit das Aufzeichnen und Auswerten von sicherheitskritischen Aktionen innerhalb eines Rechnersystems. Sie besteht aus zwei Teilen:

• Im ersten Teil wird theoretisch in die allgemeinen Aufzeichnungs- und

Auswertpraktiken mit ihren Problemen und Lösungsansätzen eingeführt.

• Die praktische Umsetzung der Ergebnisse geschieht dann im zweiten Teil mit der

Entwicklung eines Auditsystems im Fachentwurf.

Dabei steht im Vordergrund, daß nicht mehr die weitverbreitet praktizierte 'Protokollierung' - also das simple massenweise Aufzeichnen von Benutzeraktionenverfolgt wird. Vielmehr wird mit dem englischen Begriff des 'Auditing' das Aufzeichnen und das Auswerten gleich gewichtet. Um eine im Vergleich zu früher verstärkte Auswertung zu erreichen, muß dieser Prozeß automatisiert werden. Mit dem Auditing innerhalb eines Rechnerverbundes soll die Sicherung dieses Systems unterstützt werden. Die Funktion schützt wegen ihres retrospektiven Charakters zwar nicht unmittelbar die eingesetzten Rechner und Programme, trägt jedoch entscheidend zur Verbesserung des Zugriffsschutzes und zur Abschreckung potentieller Angreifer bei. wird weniger auf technische Details eingegangen. Vielmehr werden Probleme und

In dieser Studie

Lösungsmöglichkeiten des Auditing aufgezeigt. Im einzelnen untergliedert sich diese Arbeit in die folgenden Kapitel:

Im Abschnitt 2 werden der Nutzen und die Notwendigkeit des Auditing anhand eines praktischen Fallbeispiels aufgezeigt. Die Anforderungen an diese Funktion in verschiedenen Ländern und eine Abgrenzung des Auditing zu anderen Aufzeichnungsarten sowie zum Zugriffsschutz schließen diesen Abschnitt ab. Im darauf folgenden Kapitel werden die wesentlichsten Gründe für die Einführung ^{einer Auditfunktion} aufgezeigt.

Mit allgemeinen Problemen des Auditing beschäftigt sich der Abschnitt 4. Es werden Problembereiche wie Platzbedarf, Zeitaufwand, Schwierigkeiten der Auswertung im Verbund , Schutz der Protokolldatei, Interpretationsbedürftigkeit der Protokolldaten und die Schwierigkeiten der Ortsbestimmung der Datenhaltung untersucht.

Übersicht

____________________________________________________________

Der Abschnitt 5 beleuchtet das Aufzeichnen. Mit der Einführung einer Protokollfunktion muß über die Intensität der Aufzeichnung entschieden werden. Je nach Sicherheitsbedürfnis werden mehr oder weniger Aktionen im Rechnersystem festgehalten. Die Form der Aufzeichnung (technische oder logische Aktionen) und die Anforderungen an ein Trusted-Database-Management-System werden erläutert.

Die Auswertung des Auditdatenbestandes gilt allgemein als der zweite große Teilbereich des Auditing. Ohne Auswertung ist das Aufzeichnen sinnlos. Die verschiedenen Auswertmöglichkeiten werden im 6. Abschnitt aufgezeigt. Im siebten Kapitel dieser Arbeit werden zunächst Datenstrukturen und Abläufe vorgestellt, die eine intensive Protokollierung ermöglichen, wobei die spätere Auswertung der Protokolldaten kaum unterstützt wird. Diese Vorgehensweise ist bei einem hohen Datenaufkommen in der Auditdatei und seltenen Auswertungen gerechtfertigt.

Danach wird der umgekehrte Fall betrachtet: Häufige Auswertungen der Auditdatei erzwingen eine andere Organisation der Daten. In der Praxis muß unter Umständen ein Kompromiß zwischen schneller Abspeicherung und einfachen Auswertmöglichkeiten eingegangen werden.

Bevor ein eigenes Auditsystem entworfen wird, werden im 8. Abschnitt anhand verschiedenartiger auf dem Markt erhältlicher Softwareprodukte die dort realisierten Audit-Funktionen aufgezeigt. Es werden spezielle Auditwerkzeuge, Datenbanksysteme und Betriebssysteme vorgestellt.

Im zweiten Teil dieser Arbeit wird ein Auditsystem im Fachentwurf entwickelt. Mit dem Abschnitt 9 werden die Anforderungen an das System definiert. Auf konkrete und bereits bestehende Umgebungsbedingungen wird genauso eingegangen wie auf das erwartete Verhalten des neuen Systems.

Die Datenstrukturen, die Schnittstellen inklusive Oberfläche und die Funktionen des Auditsystems sind die Themen in den nächsten drei Abschnitten. Diese Bereiche werden fachlich beschrieben. Grundlagen bilden Arbeiten aus [Denn87], [Wink89] und [WeBa90].

Der 13. Abschnitt zeigt drei Geschäftsprozesse, mit deren Hilfe die Funktionalität des Auditsystems auf logischer Ebene beleuchtet wird. Auf technische Details wird dabei weitgehend verzichtet.

Die Arbeit schließt mit einem Resümee, das kurz auf die wichtigsten Erkenntnisse dieser Arbeit eingeht.

Einführung

____________________________________________________________

____________________________________________________________________

Seite 3

Einführung

____________________________________________________________

2. Einführung

Es stellt sich die grundsätzliche Frage, welchen Zweck das Auditing in einem Rechnersystem haben soll. Der folgende Fall aus der Praxis gibt implizit eine Antwort. Zum Schutz der beteiligten Personen und Institutionen wurden Namen und wesentliche zur Identifizierung beitragende Daten verändert.

2.1 Fallschilderung

Am 20.01.95, gegen 11.30 Uhr, bemerkte der 35jährige Richard Kaufmann am Odeonsplatz in München einen weißen VW-Golf mit dem amtlichen Kennzeichen M-KM 8107, der von einer blonden Frau gesteuert wurde. Da Kaufmann die Frau kennenlernen wollte, wandte er sich an den ihm vom Sportverein her bekannten 17jährigen Angestellten Ronald Lex, der seit 5 Monaten in der Zulassungsstelle der Landeshauptstadt München beschäftigt war. Dieser hatte Zugriff auf die städtischen Kraftfahrzeugdateien. Unter anderem war Lex berechtigt, Kfz-Halter-Abfragen durchzuführen.

Auf diesem Weg erhielt Kaufmann am 22.01.95 die Adresse der verheirateten 32jährigen Arzthelferin Olivia Mertens. Kaufmann suchte anfangs telefonisch und brieflich den Kontakt zu dieser Frau. Als sie jedoch keine Anstalten machte, sich mit Kaufmann zu treffen, begann er seine 'Angebetete' zu terrorisieren.

Etwa drei Monate zog sich der Terror gegen Frau Mertens hin. Zuerst handelte es sich 'nur' um Beleidigungen und harmlose Drohungen. Als Kaufmann jedoch telefonisch am 02.04.95 eine Morddrohung gegen Frau Mertens äußerte und diese daraufhin einen Nervenzusammenbruch erlitt, wurde vom Ehemann der Frau die Polizei verständigt. Eine Strafanzeige wegen fortgesetzter Beleidigung und Bedrohung wurde aufgenommen.

Bis zu diesem Zeitpunkt war der Täter Frau Mertens nur mit dem Vornamen bekannt. Sie wußte, daß er ihren Namen und die Adresse aufgrund des Autokennzeichens erhalten hatte. Die Telefonnummer hatte er daraufhin selbständig dem Telefonbuch entnommen.

Da wegen der Bekanntgabe von Halterdaten der Verdacht eines Vergehens nach dem Bayerischen Datenschutzgesetz bestand, ermittelte die Münchner Polizei gleichzeitig wegen dieses Tatbestands. Schon frühzeitig dachte man an Beamte oder Angestellte der Münchner Zulassungsstelle. Um die Personalien des Unbekannten zu erfahren, veranlaßte die Münchner Polizei die Auswertung des Protokollbestandes am Hauptrechner der Zulassungsstelle.

____________________________________________________________________

Seite 4

Einführung

____________________________________________________________

Bei der Eingrenzung der Abfragezeit wurde folgendermaßen vorgegangen: Der erste telefonische Kontakt fand am Abend des 22.01.95 statt. Wegen des umfangreichen Protokollbestandes und der sinkenden Wahrscheinlichkeit eines T reffers bei einer zeitlich rückwärts gerichteten Suche wurde der Auswertungszeitraum auf fünf Tage festgelegt. Ausgewertet wurde deshalb der Protokolldatenbestand zwischen dem 18.01.95, 06.30 Uhr, und dem 22.01.95, 18.00 Uhr.

Der Angestellte Lex wurde ermittelt. Er konnte keine stichhaltige Begründung für die Abfrage des Datensatzes geben. Nachdem er sich später in Widersprüche verwickelt hatte, gab er schließlich zu, den Namen und die Adresse von Frau Mertens an Kaufmann weitergegeben zu haben. So konnte dieser schließlich ermittelt werden. Gegen beide Täter erging Strafanzeige, und es erfolgte einige Monate später eine Verurteilung durch das Amtsgericht München II. Lex wurde außerdem von der Landeshauptstadt München entlassen. Die Straftat hatte er während der Probezeit begangen.

Wie dieses Beispiel aus der Praxis zeigt, ist es mit dem Schutz von Daten gegen unberechtigte Zugriffe nicht getan. Oft erfordert der allgemeine Datenschutz zusätzlich die Protokollierung von Abfragen, Veränderungen, Löschungen oder Speicherungen bestimmter Daten. Es soll so ermöglicht werden, widerrechtliche Datenmanipulationen im nachhinein nachvollziehen zu können. In erster Linie werden dabei Mitarbeiter kontrolliert, die grundsätzlich das Zugriffsrecht auf bestimmte Daten besitzen, dieses Recht jedoch entgegen innerbetrieblicher oder von außen vorgegebener Anweisungen mißbrauchen könnten.

Im weiteren ist daran zu denken, daß die Protokollierung nicht nur für Datenabfragen notwendig ist. Die gesamte Informationstechnik ist davon betroffen. Auch das Anlegen, Löschen und Verändern von Daten kann verheerende Folgen haben, wenn dieses Recht mißbraucht würde. Man denke nur an die Eingabe eines entsprechenden Datensatzes über eine Person bei der SCHUFA, der Aussagen über eine negative Kreditwürdigkeit dieser Person macht.

Neben der Manipulation von Daten kann grundsätzlich jede nur denkbare Aktion protokolliert werden. Das kann z.B. bis zur Aufzeichnung von Roboterbewegungen oder der Nutzung externer Ressourcen gehen.

Nach dem Absturz der 'Birgen-Air' am Anfang dieses Jahres wurde im Atlantik nach dem Voice-Recorder und nach der Black-Box gesucht. Die Auswertung der Geräte klärte die Absturzursache vollständig auf. Dadurch konnte ein wertvoller Beitrag zur künftigen Flugsicherheit geleistet werden.

Im folgenden wird häufig von aufgezeichneten Aktionen gesprochen. In der Praxis werden diese Aktionen meistens Zugriffe auf Daten bedeuten. Andere Eingriffe von Benutzern oder Systemen sind in diesem Begriff jedoch ebenfalls enthalten.

____________________________________________________________________

Seite 5

Einführung

____________________________________________________________

2.2 Protokollierung in der Informationstechnik

Unter Protokollierung wird ganz allgemein das Aufzeichnen von Geschehensabläufen verstanden. Im nachhinein soll es ermöglicht werden, diese Aktionen zu rekonstruieren. Sehr häufig steht das Auditing im Zusammenhang mit der Sicherung von Datenbeständen auf Rechenanlagen. Wegen der universellen Nutzung der Rechner kann die Protokolltechnik innerhalb sehr verschiedener Einsatzgebiete genutzt werden. Die Protokollierung kann darüber hinaus durchaus mit Videoaufzeichnungen in sicherheitskritischen Bereichen, wie Kernkraftwerken, Museen, Waffenlagern, Banken etc., verglichen werden. Dort werden Videokameras automatisch zugeschaltet, wenn ein Bewegungsmelder eine Person in einem bestimmten Bereich feststellt. Diese Kameras dienen dazu, die Ermittlung und Überführung von Tätern im nachhinein zu erleichtern. Da in der Informationstechnik auf den verschiedensten Gebieten protokolliert wird, soll zunächst auf einige dieser Bereiche eingegangen werden.

2.2.1 Übertragungsprotokolle

Die Rechner in einem Netz benutzen in der Regel einen gemeinsamen Standard zur Übertragung von Daten. Diese Regelungen bestimmen die Einzelheiten des Informationsaustausches und insbesondere

• den Aufbau und Abbau von Verbindungen sowie

• die Größe der Nachrichtenpakete.

Der gemeinsame Standard wird auch Kommunikationsprotokoll genannt. In [Voßb95] wird das ISO/OSi-Referenzmodell für offene Kommunikationssysteme als ein abstraktes Modell erwähnt. Es definiert den funktionalen Rahmen für die

Kommunikationsprotokolle in homogenen und heterogenen Rechnernetzen. TCP/IP (Transmission Transport Protocol/Internet Protocol) ist eines der meistbenutzten Protokolle in heterogenen Netzen. Es basiert auf der ISO/OSI-Protokollarchitektur.

____________________________________________________________________

Seite 6

Einführung

____________________________________________________________

2.2.2 Übersetzungsprotokolle

Werden beim Übersetzen eines Quellprogramms durch einen Compiler Aufzeichnungen geführt, so bezeichnet man diese Daten als Übersetzungsprotokoll. Es kann zum Programmtest verwendet werden. In diesem Protokoll werden häufig auch der Quelltext und der erzeugte Code festgehalten.

2.2.3 Datenbank-Logs

Bei Datenbank-Logs handelt es sich um Aufzeichnung von Aktionen in einem Datenbanksystem. Im Falle eines Abbruchs, eines Deadlocks oder bei Integritätsverletzungen soll die Datenintegrität gewährleistet werden (Recovery). Es werden eine oder mehrere Transaktionen mit Hilfe des Log zurückgesetzt [Schl94]. Bei Systemfehlern ermöglicht dieses Log einen Neustart des Systems. Dabei werden alle Aktionen rückgängig gemacht, die vor dem Auftreten des Fehlers noch nicht abgeschlossen waren.

2.2.4 Auditprotokolle

Systemsicherungen können das Eindringen unberechtigter Benutzer in ein System nie zuverlässig verhindern. Auch berechtigte Anwender können die Ressourcen mißbrauchen. Schließlich ist ein schwerwiegender Fehler durch Hardware, Software oder Anwender ebenfalls denkbar. Diese Ereignisse sollen im nachhinein untersucht und Schaden möglichst wieder gutgemacht werden können. Deshalb werden das An- und Abmelden, die Arbeit sowie Systemaktionen am Rechner in einem festzulegenden Umfang revisionsfähig aufgezeichnet (Auditing). Das Einschalten, Verändern und Auswerten der Protokollierung muß ebenfalls festgehalten werden. In [Kers95] wird zwischen dem undifferenzierten Aufzeichnen aller Aktionen, z. B. für die Kostenrechnung, und dem Auditing unterschieden. Letzteres meint die Aufzeichnung und Auswertung von sicherheitsrelevanten Ereignissen. Nach [Voßb95] sind insbesondere folgende Ereignisse zu protokollieren:

• Das Ein- und Ausschalten bzw. Aktivieren u nd Deaktivieren von

Netzwerkkomponenten

• An- und Abmeldevorgänge eines Benutzers im Rahmen der Zugangskontrolle mit

Benutzer-ID, Datum, Uhrzeit und der Netzwerkadresse der Arbeitsstation

____________________________________________________________________

Seite 7

Einführung

____________________________________________________________

• Aufzeichnung der verwendeten Nummer des entfernten Wählnetzanschlusses bei

Rückrufverfahren

• Erfassung von Dateizugriffen, Programmaufrufen und unerlaubten Zugriffsversuchen

• Speicherung von Benutzerprofileinrichtungen, Änderung und Entzug von Rechten

• Beginn und Ende einer DFÜ, Nummer der Wählnetzanschlüsse (bei

Wählverbindungen), die LAN-Adressen (bei LAN-Anschlüssen) und die genutzten Leitungen (bei Standverbindungen).

Zusätzlich muß vor allem auch das Auswerten und die Löschung der Protokolldatei dokumentiert werden.

Das amerikanische Verteidigungsministerium richtete ein 'DoD Computer Security Center' (heute: 'National Computer Security Center (NCSC)) ein, das die Veröffentlichung der amerikanischen IT-Sicherheitskriterien einleitete [FuHK95]. 1983 und nach einer Überarbeitung 1985 wurden die "Trusted Computer Systems Evaluation Criteria" (TCSEC) herausgegeben. Wegen der Einbandfarbe wurde diese Veröffentlichung unter der Bezeichnung ‘Orange Book’ bekannt. Es handelte sich dabei um eine Vorgabe zur Entwicklung und Bewertung von ‘sicheren’ Rechnersystemen. Es wurden vier Stufen D - A mit sieben Klassen nach steigenden Anforderungen definiert: D, C1, C2, B1, B2, B3, A1 sowie der Klasse "beyond A1". In jeder dieser Klassen wurde eine Menge von Sicherheitsfunktionen beschrieben. Eine Reihe von Richtlinien ergänzte die im ‘ Orange Book’ beschriebenen amerikanischen IT-Sicherheitskriterien. Das sogenannte ‘Tan Book’ behandelte dabei den Bereich des Auditing im besonderen.

In Deutschland wurden durch die Zentralstelle für Sicherheit in der Informationstechnik (ZSI) sog. "Standardwerke zur IT-Sicherheit" herausgegeben. Darin wird die hierarchische Skala aus Amerika übernommen und in die Bereiche Funktionalität und Qualität aufgeteilt. Die IT-Sicherheitskriterien definieren acht Funktionsbereiche in sicheren Systemen. Ein Bereich behandelt die Beweissicherung. Die Anforderungen der Sicherheitsklassen an die Beweissicherung sind der nachfolgenden Übersicht zu entnehmen:

____________________________________________________________________

Seite 8

Einführung

____________________________________________________________

Legende:

- keine Anforderung an diese Klasse

+ neue oder gegenüber der nächstniedrigeren Klasse erweiterte Anforderungen = keine Zusatzanforderungen im Vergleich zur nächstniedrigeren Klasse

F5-Systeme müssen somit Funktionen gemäß der oben genannten Tabelle bereitstellen. Neben den hierarchisch definierten Sicherheitsklassen F1 bis F5 wurden zusätzlich die Klassen F6 bis F10 definiert, die nicht hierarchisch aufgebaut sind. Dabei gilt die Klasse F8 für Systeme, die spezifische Anforderungen an die Sicherung der Integrität der Datenübertragung stellen. Hier wird explizit eine Beweissicherung gefordert. Auch die Klasse F10 (für vernetzte Systeme mit hohen Anforderungen an Geheimhaltung und Integrität) sieht eine Beweissicherung vor. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seinem IT-Grundschutzhandbuch 1996 [BSI96] für den mittleren Schutzbedarf eine Protokollierung am Server. Der mittlere Schutzbedarf wird dabei folgendermaßen definiert:

• Der Schutz von Informationen, die nur für den internen Gebrauch bestimmt sind,

muß gewährleistet sein.

• Kleinere Fehler können toleriert werden. Dagegen müssen die Aufgabenerfüllung

erheblich beeinträchtigende Fehler jedoch erkennbar oder vermeidbar sein.

• Längere Ausfallzeiten, die zu Terminüberschreitungen führen, sind nicht zu

tolerieren.

BSI zufolge muß der Netzadministrator die Protokolldateien des Netzservers in regelmäßigen Abständen überprüfen. Dabei seien insbesondere die folgenden Vorkommnisse von Interesse:

1. falsche Paßworteingabe/Sperrungen bei Erreichen der Fehlversuchsgrenze

2. Versuche von unberechtigten Zugriffen

3. Stromausfall

4. Daten zur Netzauslastung und -überlastung

Wird im folgenden nicht ausdrücklich etwas anderes erwähnt, ist mit Protokollierung diese Aufzeichnungsart gemeint.

____________________________________________________________________

Seite 9

Einführung

____________________________________________________________

2.3 Protokollierung und Zugriffsschutz

Das Aufzeichnen von Benutzeraktionen sollte nicht ohne die Maßnahmen des allgemeinen Zugriffsschutzes im Rechnersystem betrachtet werden. Die Frage "Ist Protokollierung ohne Zugriffsschutz denkbar?" sollte in den meisten Fällen verneint werden. Wird aufgrund eines Log eine mißbräuchliche Benutzung nachgewiesen, so muß dafür gesorgt werden, daß Gegenmaßnahmen den nochmaligen Mißbrauch der Ressourcen durch diesen Täter verhindern. Dies ist jedoch nur mit entsprechenden Schutzmaßnahmen möglich.

Nach [Weck84] werden aufgrund der Meldung auf organisatorischer Ebene Gegenmaßnahmen eingeleitet. Die Berichterstattung sollte nach einem bestimmten Schema an mehreren voneinander unabhängigen Stellen geschehen, damit eine Unterwanderung dieser Schnittstelle erschwert wird. Es könnte sonst sein, daß die Meldung unterdrückt wird, weil derjenige, der sie empfängt, der Verursacher der Sicherheitsverletzung ist oder mit diesem zusammenarbeitet. Das Auditing gewährt im allgemeinen keinen Schutz gegen Angriffe. Die Vorstellung, daß alleine das Wissen um die Protokollierung Angreifer grundsätzlich abschreckt, kann trügen. Nur technische bzw. organisatorische Gegenmaßnahmen können ein Rechnersystem hier erfolgreich schützen.

Abb. 1 zeigt den Protokollierungsbereich als Ergänzung zu Zugriffsschutzmaßnahmen. Weil die Protokollierung grundsätzlich den Zugang zu Ressourcen nicht verwehrt, handelt es sich hier um verfolgende Maßnahmen, da grundsätzlich erst im nachhinein ein Mißbrauch festgestellt werden kann. Die Maßnahmen des Zugriffsschutzes dagegen sollen den Mißbrauch verhüten und sind somit zeitlich vor den Tataktionen anzuordnen. Aus Ergebnissen der Protokollierung resultieren im folgenden wieder neue Zugriffsschutzmaßnahmen. Die Überführung eines Täters mittels Protokollauswertung wird i. d. R. die Entziehung der Rechte des Täters zur Folge haben.

____________________________________________________________________

Seite 10

Einführung

____________________________________________________________

Der Bereich 'Sicherheit in Informationssystemen' wurde ausführlich in vielen Publikationen behandelt. In [Cael94] wird auf verschiedenste Aspekte wie

- Personalauswahl

- Vier-Augen-Prinzip

- Sicherheitstraining

- Balance zwischen Sicherheit und Kosten

- Physikalischer Zugriffsschutz

- Feuer- und Wasserschutz

- Gesetzliche Vorschriften

- Kryptographie

- Zugriffsschutz

- Datenübertragungssicherheit

eingegangen. Bereits mit dieser kleinen Aufzählung wird unmittelbar deutlich, wie breit gefächert dieses Gebiet ist. Die Protokollierung ist somit nur ein relativ kleiner Ausschnitt aus dem Bereich Sicherheit.

Deshalb wird in der Praxis der allgemeine Zugriffsschutz Priorität vor der Protokollierung haben. Denn wer würde sein Haus unverschlossen lassen, jedoch eine Videokamera zur Identifizierung eines evtl. Einbrechers installieren? Vorbeugen ist wichtiger als heilen. In sicherheitskritischen Bereichen wie in Flugzeugen (Black Box) ist die Protokollierung heute unerläßlich. Sie erlaubt die Erhöhung der Sicherheit durch nachträgliche Fehlerfindung und Elimination der so entdeckten sicherheitsgefährdenden Elemente.

____________________________________________________________________

Seite 11

Einführung

____________________________________________________________

2.4 Das Auditing im Zeitablauf

In der ersten Phase des Auditing werden bestimmte Aktionen aufgezeichnet. Sobald ein Rechner im Verbund aktiv ist, sollte die Protokollfunktion eingeschaltet sein. Bereits das Login eines Benutzers soll aus Beweisgründen festgehalten werden. Es muß später nachvollzogen werden können, wann ein Anwender (berechtigt oder unberechtigt) am Rechnersystem agiert hat. Auf keinen Fall beschränkt sich das Auditing auf die Protokollierung der Anmeldung. Die Überwindung des Zugriffsschutzes soll ebenfalls aufgezeichnet werden, weiterhin selbstverständlich auch die Nutzung verschiedener Ressourcen.

In der zweiten Phase stellen sich Fragen, die entweder durch Schäden am System oder durch vorbeugende Maßnahmen entstehen. Der Protokolldatenbestand muß nun ausgewertet werden. Dabei müssen Werkzeuge helfen, die relevanten Daten aus dem Protokoll zu filtern. Die Phasen des Auditing sind in Abb. 2 nochmals skizziert.

____________________________________________________________________

Seite 12

Zweck der Protokollierung

____________________________________________________________

3. Zweck der Protokollierung

Das Auditing soll nachträglich die Möglichkeit bieten, vergangene Aktionen am Rechnersystem nachzuvollziehen. Wird in einem empfindlichen Rechnersystem auf die Protokollierung verzichtet, drohen existentielle Risiken. Das Aufzeichnen der Aktionen ermöglicht unter Umständen Regreßforderungen, die ein solches Fiasko abwenden können. Nach [Cael94] drohen ohne entsprechende Sicherheitsmaßnahmen Gefahren wie Geschäftsverlust, Vermögensverlust, Verlust des Rufes und des öffentlichen Vertrauens.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) definiert in [BSI96] den Zweck der Protokolldaten folgendermaßen:

'Protokolldaten dienen dem Zweck, nachträglich feststellen zu können, ob Sicherheitsverletzungen im IT-System stattgefunden haben oder ob ein solcher Versuch unternommen wurde. Daher können Protokolldaten für die Täterermittlung im Schadensfall genutzt werden. Eine weitere wichtige Funktion der Protokolldaten ist die Abschreckung. Werden Protokolldaten regelmäßig ausgewertet, können vorsätzliche Angriffe auf ein IT-System frühzeitig erkannt werden. Findet die Auswertung der Protokolldaten jedoch nicht oder nur unzureichend statt und wird dies bekannt, verliert sich die Abschreckungswirkung vollständig.'

Es ist dazu jedoch anzumerken, daß mit den Auditdaten sehr wohl mehr als nur die 'Täterermittlung im Schadensfall' und eine Abschreckung erreicht werden kann. Durch eine Echtzeitauswertung der Protokolldaten ist das Unterbinden eines Angriffs und das Abwenden eines Schadensereignisses möglich. Wie dies realisiert werden kann, wird im zweiten Teil dieser Arbeit gezeigt.

3.1 Schutz durch Abschreckung

Allein das Wissen der Mitarbeiter, daß das Nützen bestimmter kritischer Systemressourcen mitgeschnitten wird, kann sie davon abschrecken, gegen geltende Anweisungen zu handeln. Aber auch Eindringlinge können bedingt abgehalten werden, sich in ein System einzuschleusen, das bestimmte Aktionen wie Anmeldung und Zugriffe mitschreibt. Je nach Konzeption der Audit-Programme könnten Tatsachen festgehalten werden, die der Überführung von Angreifern dienen. Die Mitarbeiter werden gezwungen, bei jeder Nutzung der Ressourcen die Rechtmäßigkeit ihrer Aktion zu überdenken. Sie wissen, daß sie aufgrund des Protokolls zur Rechenschaft gezogen werden können. Nach [Weck84] ist es wichtig, daß nach der ____________________________________________________________________

Seite 13

Zweck der Protokollierung

____________________________________________________________

Identifizierung des Angreifers auf der organisatorischen Ebene mit großer Wahrscheinlichkeit Sanktionen eingeleitet werden. Wird darauf verzichtet, so ist das Auditing als Abschreckung relativ bedeutungslos.

Ob es sich dabei um strafrechtliche oder arbeitsrechtliche Maßnahmen handelt, ist dabei zweitrangig. Diese Wirkung geht jedoch schnell verloren, wenn die Androhung unglaubwürdig wird. Mehrmalige und unbegründete Nachsichtigkeit nach der Ermittlung von Angreifern läßt die Hemmung potentieller Attakierer schmelzen. So hart es auch klingen mag: Es dient der Abschreckung, wenn ein Exempel statuiert und in Einzelfällen hart durchgegriffen wird. Es kann sich dabei um Entlassungen aus dem Arbeitsverhältnis oder auch um Freiheitsstrafen handeln.

In jedem Fall ist es jedoch unklug, die Erkenntnisse aus Protokollauswertungen nur zur Einleitung von Strafaktionen zu benutzen. In erster Linie ist an eine sukzessive Verbesserung der Schutzmechanismen zu denken.

3.2 Beweissicherung

Ein Protokoll soll unter anderem bewußt begangene Sicherheitsverstöße nachweisen können. Es muß dabei deutlich unterschieden werden, ob es nur ein Indiz für bestimmte Aktionen darstellen soll oder ob der Audit-Report sogar einen (gerichtlich verwertbaren) Beweis erbringen muß. Das folgende Beispiel verdeutlicht diesen Unterschied: Beispiel:

Im Protokoll wird beim Auslösen des Befehls „lies Datensatz D“ und vor dem Anzeigen auf dem Bildschirm festgehalten: 24.03.96, 12.37.52, 37, 051612602, D, was sinngemäß bedeutet:

Der Benutzer mit der Nr. 051612602 hat am 24.03.96 um 12.37 Uhr am Terminal 37 den Datensatz D gelesen.

Hier wird lediglich behauptet, daß der Benutzer 051612602 den Nutzdatensatz gelesen habe. Tatsächlich ist dies jedoch keineswegs garantiert. Möglicherweise gab es zur Tatzeit diesen Nutzdatensatz noch nicht. Dann erhielt der Benutzer lediglich eine Negativmeldung. Es handelt sich hier um eine zumindest interpretationsbedürftige Meldung.

____________________________________________________________________

Seite 14

Zweck der Protokollierung

____________________________________________________________

Die Sicherung des Auditdatenbestandes gegen Manipulationen und gegen falsches Aufzeichnen durch das Auditsystem selbst wird im Abschnitt 5.4 behandelt.

3.3 Fehlerfindung

Nicht jeder Schaden am Rechnersystem wird mit Absicht herbeigeführt. Hard- und Softwarefehler können erhebliche Kosten verursachen. Ist es nicht möglich, die Ursachen zu finden, so kann in vielen Fällen ein ernstzunehmender Schaden entstehen. Das Aufzeichnen der Geschehensabläufe kann wesentlich zum Auffinden der fehlerhaften Aktionen beitragen. Fehler können verursacht werden durch

- Hardware,

- Basissoftware und Anwendungen sowie

- Fehlverhalten von Benutzern.

Wird ein Fehler oder ein Angriff erkannt, dann sollte vor allem der letzte Protokolldatenbestand gesichert werden. Diese Informationen können das Eingrenzen der verantwortlichen Akteure ermöglichen.

Wurde durch einen Unberechtigten der Zugriffsschutzes überwunden, so müssen die Sicherungsmaßnahmen auf technischer oder organisatorischer Ebene verbessert werden. Es kann also auch eine Schwäche des Sicherungssystems erkannt werden. Das Auftreten von Anwenderfehlern kann häufig durch die Protokollauswertung erkannt werden. Eine Schulung wäre dann angebracht.

3.4 Kostenverrechnung

Durch eine Protokollführung und deren Auswertung kann eine Kostenverrechnung ermöglicht werden. In Zeiten des Internet-Booms werden häufig Dienste auf diesem Weg in Rechnung gestellt. Dazu notwendige Daten müssen erhoben und aufgezeichnet werden.

Grundsätzlich sind hier zwei Dienste- und Geldstromrichtungen praktisch denkbar:

• Jede Nutzung von Ressourcen wird in Rechnung gestellt (z. B. Lesen von Daten bzw. das ‘Herunterladen’ von Programmen gegen Geld).

____________________________________________________________________

Seite 15

Zweck der Protokollierung

____________________________________________________________

• Jedes Einstellen von Ressourcen kann vergütet werden ( Beispiel: Immobilienvertreter stellen neue zu verkaufende Objekte in eine gemeinsame Datenbank ein und erhalten dafür ein Honorar).

Wird die Protokollierung zur Kostenverrechnung eingesetzt, ist darauf zu achten, daß diese Funktion selbst Kosten verursacht. Im Extremfall kann die Auditfunktion sogar die Rentabilität des Systems zunichte machen. Auf eine vernünftige Kosten-Nutzen-Relation ist deshalb bei der Implementierung einer entsprechenden Software zu achten. Das Auditing zur Ergänzung des Systemschutzes darf aber nur zweitrangig als nützliche Einrichtung zur Kostenverrechnung implementiert werden.

3.5 Auslastungsfeststellung

Mit den Auditdaten kann die Menge der genutzten Ressourcen innerhalb eines bestimmten Zeitraums festgestellt werden. So ist es möglich, strategische Planungen vor allem im Hardwarebereich zu unterstützen. Dabei ist es in der Praxis häufig nicht einmal notwendig, die einzelnen Datensätze der Protokolldatei auszuwerten. Allein die Größe dieser Datei kann schon deutliche Aussagen machen. Wird pro Klasse von Aktionen eine einfache Zählfunktion implementiert, können sogar die Aktionsklassen differenziert ausgewertet werden.

Falls die Protokolldateigröße zu verschiedenen Zeitpunkten festgehalten wird und eine gleichmäßige Eliminierung von veralteten Datensätzen sichergestellt ist, so ist über die sich so ergebende Kurve die Auslastung des Rechnersystems in puncto protokollierte Aktionen feststellbar.

Zu beachten ist, daß die Auditfunktion die Auslastungsfeststellung verfälschen kann. Eine intensive Protokollierung benötigt in der Regel selbst ein hohes Maß an Rechnerkapazität.

3.6 Erfüllung gesetzlicher Vorgaben

Häufig werden durch äußere Zwänge bestimmte Sicherungsmaßnahmen gefordert. Solche Vorgaben können sein:

• Gesetzliche Vorschriften und Verordnungen (z. B. Datenschutzgesetze)

• Anreize für besonders sichere Systeme (Gütezeichen o. ä)

____________________________________________________________________

Seite 16

Zweck der Protokollierung

____________________________________________________________

• Finanzielle Sanktionen positiver oder negativer Art

• Forderungskataloge auf fachlicher Ebene

• Vorgaben aus betriebswirtschaftlicher Sicht (z. B. Datenschutz als wichtiger

Bestandteil der Vertragsbedingungen einer Bank gegenüber den Kunden). Nach ¹ [Pohl95] gibt es mit Ausnahme der Anforderungen aus den Datenschutzgesetzen keine Rechtsvorschriften, die unmittelbar die Sicherheit der Informationstechnik regeln. Zu den Datenschutzgesetzen zählen auch Abschnitte aus anderen Spezialbereichen wie beispielsweise die einzelnen Polizeiaufgabengesetze (PAG) der Bundesländer. Läßt man die Regelungen in Bezug auf personenbezogene Daten außer acht, so gibt es bisher nur die rechtlich unverbindlichen Kriterien der Zentralstelle für Sicherheit in der Informationstechnik (ZSI).

In § 9 Bundesdatenschutzgesetz [BDSG90] werden für bestimmte öffentliche und nichtöffentliche Stellen Sicherheitsmaßnahmen gefordert. Genaueres legt hier für das Land Bayern der Art. 7 Abs. 2 des Bayerischen Datenschutzgesetzes [BayD93] fest: Art. 7 Abs. 2 BayDSG (in Auszügen):

¹ [Pohl95] Beitrag von Prof. Dr. Alexander Roßnagel. Universität-Gesamthochschule, Kassel. Projektgruppe verfassungsverträgliche Technikgestaltung, Darmstadt. Der Beitrag ist die überarbeitete Fassung eines Vortrags, den der Verf. auf der Tagung des Bundesamts für die Sicherheit in der Informationstechnik (BSI) „Interdisziplinärer Diskurs zu querschnittlichen Fragen der IT-Sicherheit“ am 22.09.92 in Boppard gehalten hat.

____________________________________________________________________

Seite 17

Zweck der Protokollierung

____________________________________________________________

Aus diesen beiden Forderungen läßt sich unmittelbar die Verpflichtung zur Protokollierung bestimmter Aktionen ableiten. Diese Forderung gilt für alle bayerischen Behörden, wenn nicht Spezialgesetze andersartig lauten. In der Praxis wird die Vorgabe der Nr. 7 häufig in der Art umgesetzt, daß zum relevanten Datensatz der erfassende Sachbearbeiter und die Zeit der Eingabe festgehalten wird. Dabei handelt es sich jedoch nicht um eine Protokollierung im üblichen Sinne.

Noch konkreter wird für den Bereich der Auswertung eines Protokolls beispielsweise das Polizeiaufgabengesetz des Freistaats Bayern [PAG90]. In Art. 46 Abs. 2 PAG wird festgelegt:

In diesem Artikel werden Regelungen zu folgenden Auditbereichen getroffen:

• Unter welchen Voraussetzungen der Protokolldatenbestand ausgewertet werden darf

• Welche Personen die Auswertung anordnen

• Wie lange der Protokolldatenbestand aufbewahrt wird.

Somit unterliegt die Bayer. Polizei genau definierten Rahmenbedingungen für die Protokollierung beim Abruf von personenbezogenen Daten. Wie für diese Behörde gelten entsprechende Bestimmungen auch für andere Einrichtungen des Staates und der Kommunen.

Die Protokollierung liegt deshalb häufig nicht mehr im Ermessen eines EDV-Leiters oder gar eines Softwareentwicklers. Wegen der deutlich erhöhten Sensibilität der Öffentlichkeit im Bereich Datenschutz und wegen der rechtlichen Bindung ist ein Mindestmaß an Kenntnis der juristischen Regelungen oder die Inanspruchnahme von Rechtsspezialisten auf diesem Gebiet beim Umgang mit personenbezogenen Daten unabdingbar.

Das Auditing gewährleistet somit auch Auswertmöglichkeiten, die durch den Gesetzgeber vorgeschrieben sind.

____________________________________________________________________

Seite 18

Zweck der Protokollierung

____________________________________________________________

3.7 Allgemeines Ziel der Protokollierung

Mit der Protokollierung in einem Rechnersystem kann erreicht werden, daß nachträglich Störfaktoren beseitigt werden. Werden Fehler im Sicherungsmechanismus durch die Audit-Funktionen erkannt, kann neben der ‘Heilung’ des Schadens auch am Ausbau des Zugriffschutzsystems gearbeitet werden. Die Erkenntnisse aus vorangegangenen Schäden ergeben im Idealfall einen besseren Zugriffsschutz. Dabei zielen allgemeine Audit-Funktionen nicht auf eine spezielle Klasse v on Störfaktoren. Fehler bzw. Angriffe können von berechtigten Anwendern, Eindringlingen sowie von Hard- und Software gleichermaßen ausgehen.

Durch das Aufdecken der Störquellen durch die Protokollierung wird so ein wichtiger Beitrag zur Sicherung des Unternehmens geleistet. Denn Betriebe und Behörden sind zunehmend von einer funktionierenden Informationstechnik abhängig.

Wann hat Protokollierung keinen Sinn?

Es stellt sich die Frage, ob Protokollierung unter Umständen keinen Sinn macht. Zunächst müssen Nutzen und Kosten gegenübergestellt werden. Folgende Faktoren können durchaus eine Unterlassung der Protokollierung verursachen:

• Die Ressourcen stehen jedermann zur Verfügung.

• Die Wiederherstellung des Systemzustandes nach einem Angriff oder Fehler ist mit

minimalem Aufwand möglich.

• Die Implementation der Audit-Funktionen ist mit unverhältnismäßig hohen Kosten

verbunden.

• Die Auswertung der Protokolldatei ist nur mit erheblichem Aufwand möglich.

Äußere Vorgaben, wie gesetzliche Bestimmungen, sind jedoch auf jeden Fall zu erfüllen.

____________________________________________________________________

Seite 19

Allgemeine Probleme der Protokollierung ____________________________________________________________

4. Allgemeine Probleme der Protokollierung

Bei der Protokollierung ist generell das Verhältnis zwischen Nutzen und Kosten zu beachten. Im Extremfall wird durch die Protokollierung das Laufzeitverhalten der Software dermaßen ineffizient, daß die Benutzung der Anwendung oder das Einschalten der Protokollierung verhindert wird. Abb. 3 zeigt dazu ein Beispiel. Im Fall A verursacht das Einschalten der Auditfunktion zwar Kosten, jedoch liegt der Nutzen um fast das zehnfache über den Kosten. Demgegenüber heben sich Kosten und Nutzen im Fall B gerade auf. Im Fall C werden sogar durch die Protokollierung mehr Kosten verursacht, als sie Nutzen bringt. In den beiden letztgenannten Fällen wird die Protokollierungsfunktion in der Regel vom Benutzer aus Performance-Gründen nicht eingeschaltet werden.

Weil aus Kostengründen nicht jede Aktion eines Anwenders, einer Funktion oder einer Hardwarekomponente aufgezeichnet werden kann, liegt es in der Natur der Protokollierung, daß sie unvollständig ist. Die Unvollständigkeit schafft wiederum große Probleme bei der Auswertung der Auditdaten.

4.1 Platzbedarf

Häufig wird die Auditdatei eine hohe Speicherkapazität voraussetzen. In großen vernetzten Rechnersystemen ist ein Aufkommen von einem Auditdatensatz/Sekunde und mehr keine Seltenheit. Geht man von einer Zeile mit 80 Zeichen/Auditdatensatz aus

____________________________________________________________________

Seite 20

Allgemeine Probleme der Protokollierung ____________________________________________________________

und werden die Protokolldaten ein Jahr aufbewahrt, so kommt man bei einem 24-Stunden-Betrieb auf etwa 2,5 Gigabyte Protokolldaten. Da diese Daten dem Rechner nicht permanent zur Verfügung stehen müssen, können sie beispielsweise auf Bändern extern abgespeichert werden. Bei den heute zur Verfügung stehenden Speichermedien mit den drastisch gesunkenen Kosten dürfte aus Platzgründen eine einfache Protokollierung nicht mehr verworfen werden. Außerdem können manchmal geschäftsmäßig angefallene und abgespeicherte Daten gleichzeitig als Protokoll dienen. Eine Einschränkung des Auditdatenvolumens ist anzustreben, wenn aufgrund der Fülle eine Auswertung nur noch unter erschwerten Bedingungen möglich ist. Es können Techniken des Intrusion-Detection-Monitoring aus Abschnitt 6 angewendet werden. Der Datenbestand enthält dann hauptsächlich Aktionen, die als ‘verdächtig’ eingestuft wurden.

Ein weiteres Problem ergibt sich, falls der Speicherplatz erschöpft ist. In [Kers95] werden folgende Reaktionsmöglichkeiten aufgezeigt:

• Alle weiteren Aktionen werden unterbunden, und der Systemverwalter hat den

Zustand zu beseitigen (die meist nicht praktikable Lösung).

• Vor dem Speicherüberlauf werden einige Zeit vorher Warnmeldungen ausgegeben

und so der Systemverwalter verständigt.

• Das System läuft weiter und die Protokollierung wird eingestellt. Diese bedenkliche

Vorgehensweise kann sogar ausgenutzt werden, daß ein Angreifer vor seiner tatsächlich geplanten Aktion zunächst den Speicher zum Überlauf bringt. Der eigentliche Angriff wird dann nicht aufgezeichnet. Allgemein entsteht das P roblem, daß mit der Erhöhung der Granularität der Auditdatensätze zwar die Genauigkeit der Protokollierung steigt, die Chancen bzw. der Aufwand des Wiederfindens jedoch sinkt.

4.2 Zeitaufwand

Ein größeres Problem stellt dagegen die benötigte Rechenzeit bei Nutzen der Audit-Funktionen dar. Häufig wird mehr Rechenzeit bei der Auswertung der Daten benötigt als beim einfachen Abspeichern. Sieht man von der Auswertung ab, so kann je nach Audit-Strategie bereits bei der Abspeicherung mehr als die Hälfte der gesamten Rechenzeit verlorengehen. Nur über eine geschickt gewählte Strukturierung der Auditdaten kann die Performance des Systems sichergestellt werden. Die Anforderungen des Unternehmens sind dabei besonders zu beachten. Im Abschnitt 7 (Datenstrukturen und Ablauforganisation) wird näher zum Zeitaufwand bezüglich der jeweiligen Strategie Stellung bezogen.

____________________________________________________________________

Seite 21

Allgemeine Probleme der Protokollierung ____________________________________________________________

Neben der Entscheidung für bestimmte Datenstrukturen müssen auch organisatorische Probleme gelöst werden, die das Aufkommen von Massendaten betreffen. Das folgende Beispiel aus der Praxis verdeutlicht die Probleme, die in solchen Fällen durch Platz- und Zeitaufwand entstehen: Beispiel:

Ein Sachbearbeiter sucht im Rechner eine bestimmte Akte. Da er die Individualnummer nicht kennt, gibt er Suchbegriffe ein. Als Folge erhält er eine 'Trefferliste', die mehrere Akten zur Auswahl anbietet und gleichzeitig eine genauere Beschreibung dieser Akten liefert. Angenommen, er erhält 100 Treffer. Sollen 100 Protokolldatensätze angelegt werden, nur weil der Sachbearbeiter die Grobinformation über die Akten zu Gesicht bekam? Nun können jedoch bereits in Trefferlisten schutzbedürftige Informationen enthalten sein. Im Fall der Trefferlisten muß im Vorfeld der Entwicklung einer Auditanwendung bereits auf organisatorischer Ebene entschieden werden, ob eine solche Aktion protokolliert werden muß. Häufig wird dies am Aufwand scheitern. Ein Lösungsansatz für solche Fälle könnte eine Aufzeichnung nach logischen Gesichtspunkten sein. Protokollbeispiel:

Sachbearbeiter A hat am 15.07.96, 07.34 Uhr, eine Trefferliste über alle Vorgänge mit dem Suchkriterium 'Name = S*' erhalten.

Logische Protokollierung vermindert jedoch erheblich die Beweiskraft, da im nachhinein Fragen zu einzelnen konkreten Datensätzen gestellt werden. In diesem Fall müßte später nachgewiesen werden, daß mit dem oben genannten Suchbegriff auch tatsächlich ein Datensatz 'Name = Steiner' existierte und deshalb auch ausgegeben wurde.

4.3 Schwierigkeiten der Auswertung im Verbund

• Werden die Protokolldateien dezentral gehalten, kann gegebenenfalls die gesamte

Rechenleistung des Verbundes genutzt werden, weil alle Knoten ihren eigenen Protokolldatenbestand auswerten. Es wird dann jedoch eine Software zur automatischen Recherche notwendig. Die Anfrage an die einzelnen Rechner, das dezentrale Auswerten und das Anliefern der Ergebnisse auf einen bestimmten Rechner müssen koordiniert werden.

• Falls eine einzige Protokolldatei des Verbundes auf einem Hauptrechner vorliegt,

wird diese Datei in der Regel durch den Hauptrechner alleine ausgewertet. Eine enorme Bindung dieses Rechners ist die Folge. Die Auswertung dauert länger als im

____________________________________________________________________

Seite 22