Computersicherheit: Protokollierung und Auswertung

Inhaltsverzeichnis

1. Übersicht

Teil 1: Grundlagen des Auditing

2. Einführung
2.1 Fallschilderung
2.2 Protokollierung in der Informationstechnik
2.2.1 Übertragungsprotokolle
2.2.2 Übersetzungsprotokolle
2.2.3 Datenbank-Logs
2.2.4 Auditprotokolle
2.3 Protokollierung und Zugriffsschutz
2.4 Das Auditing im Zeitablauf
3. Zweck der Protokollierung
3.1 Schutz durch Abschreckung
3.2 Beweissicherung
3.3 Fehlerfindung
3.4 Kostenverrechnung
3.5 Auslastungsfeststellung
3.6 Erfüllung gesetzlicher Vorgaben
3.7 Allgemeines Ziel der Protokollierung
4. Allgemeine Probleme der Protokollierung
4.1 Platzbedarf
4.2 Zeitaufwand
4.3 Schwierigkeiten der Auswertung im Verbund
4.4 Schutz der Protokolldatei
4.5 Interpretationsbedürftige Protokolldaten
4.6 Die Ortsbestimmung der Datenhaltung im Netz
5. Das Aufzeichnen
5.1 Protokollierungsintensität
5.1.1 Systembezogene Kriterien
5.1.2 Anwenderbezogene Kriterien
5.2 Technische und logische Aktionen
5.2.1 Protokollierung technischer Aktionen
5.2.2 Protokollierung logischer Aktionen
5.3 Protokollierung in Trusted-Database-Management-Systemen
5.4 Beweiskräftiges Aufzeichnen
5.4.1 Sichere Personenidentifikation
5.4.2 Technische Sicherungen
5.4.3 Mathematische Sicherungen
6. Die Auswertung des Protokolls
6.1 Das Entdecken von Angriffen
6.2 Online-Auswertungen
6.2.1 Stichproben durch das Personal
6.2.2 Auswertung durch den Rechner
6.3 Offline-Auswertungen
6.3.1 Manuelle Auswertungen
6.3.2 Auswertungen mit Abfragesprachen
6.3.3 Programmierte Recherchen
7. Datenstrukturen und Ablauforganisation
7.1 Intensive Protokollierung
7.1.1 Seitenweises Abspeichern
7.1.2 Zeitlich lineare Speicherung
7.1.3 Event-Logs
7.2 Häufige Auswertungen
7.2.1 Ressourcenorientierte Zeigerstruktur
7.2.2 Anwenderorientierte Zeigerstruktur
7.2.3 Sitzungsorientierte Zeigerstruktur
8. Protokollierung in bestehenden Systemen
8.1 Spezielle Werkzeuge für den Datenschutz
8.1.1 CA-Unicenter
8.1.2 Resource Access Control Facility (RACF)
8.2 Datenbanksysteme
8.2.1 ORACLE
8.2.2 ADABAS
8.3 Betriebssysteme
8.3.1 SINIX
8.3.2 BS
8.4 Ein Zugangskontrollsystem

Teil 2: Der Fachentwurf eines Auditsystems

9. Anforderungen an ein Auditsystem
9.1 Die Hardwareumgebung
9.2 Die Softwareumgebung
9.3 Die Oberfläche
9.4 Aufzuzeichnende Aktionen
9.5 Die Auswertungsrechte
9.6 Das Zeitverhalten der Auswertungskomponente
9.7 Aktive Reaktionsmöglichkeiten des Systems
10. Andere Entwicklungen
11. Das Datenmodell des Auditsystems
11.1 Die Struktur der Protokolldatensätze
11.2 Die Profildatenstruktur
12. Die Schnittstellen
12.1 Die Oberfläche für den Systemadministrator
12.2 Die Schnittstelle für den Anwendungsentwickler
13. Funktionale Eigenschaften des Auditsystems
13.1 Die Steuerung
13.2 Die automatisierte Online-Auswertung (OA)
13.3 Die Offline-Auswertung
13.4 Die Integration der Notebookaktionen
14. Szenarien
14.1 Ein lokaler Anwender
14.2 Datenabfrage per DFÜ
14.3 Eine Netzauswertung
15. Zusammenfassung
Literaturliste
Glossar

Abbildungsverzeichnis

Abb. 1 Protokollierung als verfolgende Maßnahme

Abb. 2 Auditing über den gesamten Zeitablauf

Abb. 3 Verhältnis von Kosten und Nutzen bei der Protokollierung

Abb. 4 Das Verhältnis zwischen Aufklärungserfolg und Auditingkosten

Abb. 5 Rechnersystem mit 3 Festplatten. Wird auf Platte E zugegriffen, so wird diese Aktion protokolliert.

Abb. 6 Verhaltensmuster eines Anwenders, Profileveränderung und Aktion des Systems

Abb. 7 Auszug aus einer zeitlich linearen Protokollierung

Abb. 8 Nutzdatensätze, Protokolldatensätze und deren Verbindungen

Abb. 9 Protokollausschnitt mit zwei Anwendern

Abb. 10 Datenausgabe im Zugangskontrollsystem des Produkts ZUPEM

Abb. 11 Sternförmig vernetzte Hardware mit einem HOST und mehreren Servern mit Terminals sowie zugehörigen Notebooks

Abb. 12 Der Auditmechanismus als eine Anwendung

Abb. 13 Zugriffsrechte der Rechner im Verbund

Abb. 14 Die Oberfläche im ISOA-Projekt

Abb. 15 Das ER-Diagramm für die Auditdatensätze. Die Fremdschlüssel in den Entitytypen wurden aus Übersichtlichkeitsgründen weggelassen.

Abb. 16 Das ER-Diagramm für die Profildatensätze. Die Fremdschlüssel in den Entitytypen wurden aus Übersichtlichkeitsgründen weggelassen.

Abb. 17 Aufbau der Hauptfenster des Auditsystems

Abb. 18 Hauptfenster für die Beobachtung der im System protokollierten Aktionen

Abb. 19 Fenster zur Einstellung der Intensitätsstufen

Abb. 20 Fenster zur Einstellung der Gegenmaßnahmen bei fehlendem Profildatensatz

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

Abb. 22 Maske mit allen angeschlossenen Rechner, die am Auswertverfahren beteiligt werden können. Außerdem ist eine Sammelbenennung durch Auswahl einer Region möglich.

Abb. 23 Die Auswertergebnisse in der Trefferliste

Abb. 24 Das Fenster für die Ausgabe der Rechercheergebnisse

Abb. 25 Fenster zur Eingabe neuer Profildatensätze

Abb. 26 Fenster zur Wahl des Ziels für die Nachrichtenübermittlung des Auditsystems an den Systemadministrator

Abb. 27 Form-Sequence-Diagram (FSD) für die Oberfläche des Auditsystems

Abb. 28 Die wesentlichsten Aufgaben der Steuerung.

Abb. 29 Grobübersicht über die Funktionalität des Auswertsystems

Abb. 30 Die Bewertung der protokollierten Aktion mit Hilfe dreier Informationsquellen

Abb. 31 Die Suche nach Personen, die auf die Datei ‘Patent.doc’ zugegriffen haben

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

Abb. 33 Die Auswertergebnisse der Server auf einen Blick in der Trefferliste

Abb. 34 Ein einzelnes Auswertergebnis mit den dazugehörigen Aktionen davor und danach

Abb. 35 Zugriffsschutz und sehr viel später die Auswertung nach alter Vorstellung

Abb. 36 Zugriffsschutz und Auditing ohne Zeitverlust

Ich versichere hiermit, daß ich diese Diplomarbeit selbständig verfaßt und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Zitate sind kenntlich gemacht.

Oliver Herzog

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 Benutzeraktionen - verfolgt 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.

In dieser Studie wird weniger auf technische Details eingegangen. Vielmehr werden Probleme und 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.

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.

Teil 1:

Grundlagen

des Auditing

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.

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 Treffers 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.

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.

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 und Deaktivieren von Netzwerkkomponenten
- An- und Abmeldevorgänge eines Benutzers im Rahmen der Zugangskontrolle mit Benutzer-ID, Datum, Uhrzeit und der Netzwerkadresse der Arbeitsstation
- 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:

Abbildung in dieser Leseprobe nicht enthalten

Überwachung sicherheitskritischer Ereignisse - - - - +

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.

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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 Protokollierung als verfolgende Maßnahme

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.

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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2 Auditing über den gesamten Zeitablauf

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.

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 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.

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).

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. ä)
- 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^[1] [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):

„Werden personenbezogene Daten automatisiert verarbeitet, sind Maßnahmen zu treffen, die je nach der Art der zu schützenden personenbezogenen Daten geeignet sind,

6. zu gewährleisten, daß überprüft und festgestellt werden kann, an welche Stellen personenbezogene Daten durch Einrichtungen zur Datenübertragung übermittelt werden können (Übermittlungskontrolle),

7. zu gewährleisten, daß nachträglich überprüft und festgestellt werden kann, welche personenbezogenen Daten zu welcher Zeit von wem in Datenverarbeitungssysteme eingegeben worden sind (Eingabekontrolle), ... “

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:

„Protokollbestände, die nach Abfrage nach Absatz 1 eingerichtet worden sind, dürfen zu Zwecken der Kriminalitätsbekämpfung und der Datensicherung ausgewertet werden. Die Auswertung für Zwecke der Kriminalitätsbekämpfung bedarf einer Anordnung der in Art. 33 Abs. 5 genannten Dienststellenleiter. Die Speicherungsdauer einer protokollierten Abfrage darf den Zeitraum eines Jahres nicht übersteigen.“

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.

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 von 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.

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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Verhältnis von Kosten und Nutzen

bei der Protokollierung

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 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 Problem, 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.

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 Verbund. Eine Abhilfe könnte hier erreicht werden, wenn die Protokolldaten durch einen Nebenrechner ausgewertet würden.
- Das Wiederfinden eines bestimmten Protokolldatensatzes gestaltet sich oft wegen der verschiedenen Suchkriterien sehr schwierig. Auf welchem Rechner des Verbundes wurde abgefragt? Eventuell haben die Anwender auf den einzelnen Rechnern verschiedene Abfragemöglichkeiten? Ein Anwender kann auf verschiedenen Wegen an die Ressourcen gelangt sein.

Beispiel:

Ein Anwender möchte Versicherungs- und Bankdaten über eine Person lesen. Das Lesen des Datensatzes wird protokolliert. Bei der Person handelt es sich um Anton Meier, geb. 17.11.58, in Hagen, wohnhaft in 80636 München, Tübinger Str. 10.

Am Rechner könnten dann beispielsweise folgende Anfragen eingegeben worden sein (PVB = Persönliche Versicherungs- und Bankdaten):

PVB Meier, Anton

PVB Meier, 171158

PVB Meier, A.

PVB 80636, Tuebinger Str.,10

PVB Muenchen, Tuebinger Str., 10 <Trefferauswahl>

PVB München, Tübinger Str., 10 <Trefferauswahl>

PVB PID = 0815171158

Die Eingabemöglichkeiten können fast beliebig variiert werden. Wird die Anfrage im Audit-Protokoll gespeichert und soll diese Anfrage wiedergefunden werden, so müßte der Auswertende eine schier unüberschaubare Vielfalt von Suchmöglichkeiten überprüfen. Zusätzlich sollte bekannt sein, an welchem Rechner die Anfrage gestartet wurde, weil sonst der gesamte Verbund ausgewertet werden muß.

4.4 Schutz der Protokolldatei

Bei einem absichtlichen Angriff auf die Ressourcen kann die Protokolldatei ein Angriffsziel des Täters sein. Er könnte die Löschung oder das Verändern der Protokolldatei anstreben, um seine Spuren zu verwischen. Mit den Abschaltmöglichkeiten der Protokollierung entstehen weitere Möglichkeiten der Manipulation. Die Auditdatei kann durch folgende Maßnahmen geschützt werden:

- Schutz durch Verschlüsselung: kryptographische Verfahren bieten einen sehr wirksamen Schutz gegen Manipulationen, da der Täter seine eigenen Spuren nicht erkennen kann.
- Schutz durch nicht veränderbares Schreiben: Einmal beschreibbare Massenspeicher verhindern das Löschen oder Verändern der Auditdaten. Zu erwähnen sind hier vor allem optische Verfahren wie bspw. einmal beschreibbare CDs.
- Schutz durch Speicherung auf externe Rechner: Werden die Protokolldaten auf einen anderen Rechner übertragen, auf den der Anwender keine direkten Zugriffsmöglichkeiten besitzt, dann wird die Manipulation der Auditdatei wesentlich erschwert. Die Übertragung und Abspeicherung muß dann jedoch gesichert sein. Wird lokal kritisch gearbeitet und werden nur die Auditdaten zum HOST übertragen, muß die Übertragung der Protokolldaten eine Kappung der Leitung überstehen. Die Daten müssen also zu einem späteren Zeitpunkt automatisch zum Hauptrechner übertragen werden. Außerdem ist die Behinderung einer sofortigen Übertragung zu dokumentieren.
- Schutz durch restriktive Rechtevergabe: Der Zugriff auf Ressourcen ist auf die notwendigen Aktivitäten einzuschränken. Insbesondere benötigen Anwender in der Regel keine Zugriffsrechte auf Audit-Funktionen! Die Unterbindung der Protokollierung eigener Aktionen darf nicht möglich sein. Folglich ist die Schaffung eines separaten Systemauditors als Rolle vorteilhaft. Er darf als einziger die Protokollierung ein- bzw. ausschalten und die Aufzeichnungen gegebenenfalls archivieren.

In diesem Zusammenhang ist das Problem der Aufzeichnung von Aktionen des Systemverwalters zu beachten. Dieser besitzt in der Regel Zugriffsrechte auf alle Dateien. Werden seine Aktivitäten aufgezeichnet, dann könnte er diese Daten jederzeit löschen oder verändern. Auch das Ein- bzw. Ausschalten der Protokollfunktion obliegt seiner Entscheidung.

Schlüpft ein Angreifer in die Rolle des Systemverwalters, kann er ebenfalls auf die Auditdatei zugreifen. Der Zugang als solcher sollte deshalb durch organisatorische oder programmtechnische Maßnahmen besonders gesichert sein.

- Schutz vor unerlaubter Auswertung: Die aufgezeichneten Informationen können beispielsweise eine Leistungskontrolle der Mitarbeiter ermöglichen. Dies ist vor allem aus datenschutzrechtlicher Sicht bedenklich. Prinzipiell müssen deshalb auch vorgefertigte Auswertprogramme vor unberechtigtem Zugriff geschützt werden. Besondere Auswertungen hinsichtlich einer Leistungskontrolle bedürfen in der Regel der Genehmigung durch den Betriebsrat.

4.5 Interpretationsbedürftige Protokolldaten

Bezüglich der Beweisbarkeit von Angriffen aufgrund von Protokollen ist auf falsche Protokolldaten bzw. falsche Interpretation dieser Daten einzugehen. Folgender Fall zeigt diese Problematik auf:

Ein Anwender fragt den Datensatz A ab. Das Rechnersystem sei so programmiert, daß es ohne weitere Aufforderung durch den Anwender selbständig im Hintergrund auch den Datensatz B abfragt. Die Zweitabfrage war vom Anwender jedoch nicht gewollt. Wird nur die Abfrage des Datensatzes A aufgezeichnet, so wurde unterstellt, daß der Anwender B nicht gelesen habe. Wurde die Abfrage von B jedoch ebenfalls protokolliert, muß sich der Anwender für eine Abfrage verantworten, die er möglicherweise nicht beabsichtigte.

Hier wird mit der Absicht des Anwenders jongliert, die nur vermutet werden kann. Kennt der Benutzer die Aufzeichnungsweise und wird das automatische Abfragen von B nicht protokolliert, so kann er über die Abfrage von A den eigentlich gewollten Datensatz B lesen, ohne daß dies festgehalten wird. Die Aussage des Protokolls würde aufgrund des Fehlens eines entsprechenden Datensatzes lauten: Der Anwender hat B nicht abgefragt.

Durch eine umfassende Aufzeichnung kann hier die Aussagekraft des Protokolls wesentlich gesteigert werden. Im oben genannten Fall könnte die Problematik durch eine Zwischenfrage des Systems behoben werden:

„Wollen Sie auch Datensatz B lesen? (j/n)“

Die Bestätigung dieser Frage ist aufzuzeichnen. Wird von Seiten des Systems diese Frage nicht gestellt, könnte im Auditbestand explizit die automatisierte Anfrage festgehalten werden.

Bei der Entwicklung der Audit-Funktionen ist es oft nicht leicht, beabsichtigte Aktionen von unbeabsichtigten klar abzugrenzen. Eine sehr sorgfältige Vorgehensweise ist daher angebracht. Zwei im Widerspruch stehende Absichten des Entwicklers stehen sich dabei gegenüber: Einerseits sollte der Auditdatenbestand klein gehalten werden, andererseits kann nur eine umfassende Aufzeichnung eine Fehlinterpretation verhindern.

4.6 Die Ortsbestimmung der Datenhaltung im Netz

Neben den Fragen der allgemeinen Protokollierung treten in einem Rechnerverbund zentrale Probleme der Datenhaltung auf. Meist steht hier der Aufwand für Datenübertragungen im Vordergrund. Dezentrale Lösungen bieten einerseits die gesamte Leistungsfähigkeit der involvierten Rechner, da jeder für sich seinen eigenen Datenbestand anlegen und auswerten kann; der Komplexitätsgrad nimmt jedoch zu. Das Abspeichern der Auditdaten kann nicht losgelöst vom Auswertungsproblem betrachtet werden. Die Vereinfachung des einen bringt die Erhöhung der Komplexität des anderen mit sich.

Falls die Protokolldateien dezentral geführt werden, erleichtert diese Vorgehensweise zwar das Abspeichern (lokales Arbeiten wird lokal protokolliert), bringt jedoch Probleme bei der Auswertung dieser Dateien mit sich. Dagegen erleichtert eine einzige Datei, z.B. auf dem HOST, zwar die Auswertung, es müssen dafür jedoch erhöhte Datenübertragungs- und Auswertkosten einkalkuliert werden.

Werden per DFÜ von einem externen Rechner Daten vom HOST gelesen, so können grundsätzlich Protokolle auf beiden Rechnern entstehen. Eine redundante Datenhaltung sollte aber, außer in begründeten Fällen, aus Kostengründen vermieden werden.

Eine andere Regelung bietet sich an, wenn am Ort der Datenhaltung oder am Ort der Abfrage (bzw. allgemeiner: am Ort der Ressourcennutzung) protokolliert werden soll.

Protokolle am Ort der Ressourcennutzung:

Pro:

Externe Eindringlinge werden nur so erfaßt. Würde am Ort der Abfrage protokolliert, wären keine Protokolldaten vorhanden. Denn der Angreifer könnte von einem fremden Rechner aus die Ressourcen nutzen.

Bei reisenden Anwendern, die verschiedene Rechner im Verbund nutzen, wird die Verteilung der Protokolle auf diese Rechner vermieden.

Liegen die Ressourcen gesammelt auf einem HOST, so gibt es auch nur eine große Protokolldatei. Bei einer Auswertung ist sichergestellt, daß alle vorhandenen Protokolldaten berücksichtigt werden. Wegen des Zugriffschutzes müssen in der Regel sowieso die Kennungen der Anwender die Anfragen begleiten. Diese werden protokolliert.

Contra:

Werden Ressourcen verschiedener Rechner im Verbund genutzt, verteilen sich die Protokolle der Anwender auf diese Rechner, selbst wenn der Benutzer immer nur von einer Stelle aus die Ressourcen nutzt.

Liegen die Ressourcen auf einem einzigen HOST, so wird auch nur auf diesem protokolliert. Dabei geht allein für das Auditing auf dem HOST ein großer Teil der Rechnerleistung verloren.

Protokollierung am Ort der Aktion (z.B. am Ort der Anfrage):

Pro:

Verbleiben die Anwender stets an einem Rechner und werden Auswertungen anwenderbezogen getätigt, bieten sich dezentrale Auditdateien an. Die üblichen Fragen der Auswertung können dann lokal bearbeitet werden.

Contra:

Wird nicht anwenderbezogen, sondern problembezogen ausgewertet, müssen oft sämtliche Auditdateien im Rechnerverbund ausgewertet werden. Das gleiche gilt bei ‘Travelling-User-Problemen’, wenn der Aktionskreis eines ortsungebundenen Anwenders nicht eingegrenzt werden kann.

5. Das Aufzeichnen

Im folgenden wird auf verschiedene Aspekte des Aufzeichnens eingegangen. Beim Mitschneiden von Aktionen werden nicht nur Zugriffe von Benutzern auf Daten berücksichtigt. Jede sicherheitsrelevante Aktion innerhalb des Rechnerverbundes sollte im Protokoll festgehalten werden. Üblicherweise wird jedoch die Nutzung von ausgewählten Ressourcen aufgezeichnet. Wenn auch in der Praxis primär die Nutzung von Daten im Vordergrund steht, so wird das Auditing in sehr vielfältiger Form in der Informationstechnologie genutzt. Man denke an die Aufzeichnungen in der ‘Black Box’ eines Verkehrsflugzeuges, an Filmmitschnitte in Hochsicherheitsbereichen von Großbanken und Militäranlagen sowie an die Protokollierung von Meßdaten bei Experimenten und in Satelliten.

In die Auditdatei sollten jedoch nicht alle sicherheitsrelevanten Daten aufgenommen werden. Protokollierung und Zugriffsschutz sind aufeinander abzustimmen.

Es ist sinnvoll, in die Protokollierungsstrategie in erster Linie solche Aktionen einzubeziehen, die nicht durch einen Zugriffsschutz abgefangen werden können.

Beispiel:

Das Herausnehmen einer Festplatte kann sehr effizient durch ein physikalisches Schloß verhindert werden. Hier hätte eine Protokollierung dieser Aktion vor dem Zugriffsschutz zurückzustehen.

Das Abfragen eines Datenbestandes durch einen berechtigten Mitarbeiter ist dagegen sehr wohl zu protokollieren, da diesem Sachbearbeiter der Zugriff auf die Daten nicht grundsätzlich verwehrt werden kann.

5.1 Protokollierungsintensität

Eine protokollierte Sitzung kann um so besser nachvollzogen werden, desto mehr mitgeschrieben wurde. Prinzipiell kann der Mitschnitt von Benutzeraktionen beliebig von Fall zu Fall in jedem Bereich eines Programms entschieden werden. Abgesehen von der unterlassenen Protokollierung, kann die Intensität (hier willkürlich) in 3 Stufen definiert werden:

Stufe 1:

Nur An- und Abmeldungen der Benutzer werden aufgezeichnet.

Es ist nachvollziehbar, innerhalb welchen Zeitraums welcher Benutzer wo am Rechner gearbeitet hat. Diese Art der Protokollierung kann zwar bei der Eingrenzung und im günstigsten Fall bei der Ermittlung eines Störfaktors helfen. Ein Beweis für ein Fehlverhalten und damit die Überführung den Benutzers wird aber in den seltensten Fällen gelingen.

Oft tritt ein Störfall nur in bestimmten Zeitabschnitten auf. Mit einem solchen Protokoll könnte z. B. festgestellt werden, daß ein bestimmter Anwender außerhalb der üblichen Geschäftszeiten am Rechnersystem gearbeitet hat. Auch das Verkleinern eines Verdächtigenkreises mit dieser Protokollart ist möglich, da nichtangemeldete Personen wahrscheinlich ausscheiden.

Die Auswertung eines Protokolls mit Intensitätsstufe 1 beantwortet Fragen wie:

"Wer war innerhalb eines bestimmten Zeitraums am System angemeldet?"

"Wer war innerhalb eines bestimmten Zeitraums länger/kürzer als x Zeiteinheiten angemeldet?"

"Wer war um ss.mm.ss Uhr (nicht) angemeldet?".

Bis auf Einzelfälle (falls z. B. nur ein Benutzer zum Tatzeitpunkt angemeldet war) ist diese Art der Protokollierung nicht sehr hilfreich. Die Entwicklung einer entsprechenden Software ist bei den gängigen Rechnersystemen nicht notwendig. Entweder bietet bereits das Betriebssystem eine solche Funktion, oder der Markt bietet entsprechende Software.

UNIX unterstützt standardmäßig die oben genannten Fragestellungen, falls man die aktuellen Anmeldungen in eine dauerhafte Datei umleitet.

Stufe 2:

Bestimmte Aktionen werden protokolliert.

Über einen Funktionsaufruf, der global im Rechner zur Verfügung gestellt werden sollte, lassen sich in Anwendungen fast beliebig Protokolldatensätze erzeugen. Es können Fragen zu verschiedenen Benutzeraktionen differenziert behandelt werden.

Beispiel:

Ein Anwender möchte einen bestimmten Datensatz lesen. Je nach Anforderung des individuellen Sicherheitsbedürfnisses im Betrieb kann z.B. mitgeschrieben werden:

- die Anforderung des Datensatzes
- das Fehlen des Datensatzes
- das Fehlen des Zugriffrechts
- die Lieferung des Datensatzes.

Für das Aufzeichnen bestimmter Aktionsarten muß sich der Leiter IT bzw. das IT-Sicherheitsmanagement jedesmal neu entscheiden.

Nach [BSI96] sollen z.B. für den mittleren Schutzbedarf in einem UNIX-System mindestens die folgenden Aktionen aufgezeichnet werden:

- Logins (auch Fehlversuche)
- Aufruf von su,
- Fehlerprotokollierungsdatei/Protokollierung wichtiger Vorgänge (errorlog),
- Administratortätigkeiten (insbesondere von root ausgeführte Befehle).

Stufe 3:

Alle Aktionen bzw. jede Eingabe wird protokolliert.

Die Aktionen der Benutzer wurden in früheren Zeiten hauptsächlich wegen der Kostenermittlung festgehalten. Daraus resultierte diese undifferenzierte Aufzeichnungsart. Die Auditdatei wird sehr schnell unübersichtlich und dadurch weniger attraktiv für Stichproben und Auswertungen. Insbesondere existieren in dieser Datei viele Daten, die für den Schutz des Systems irrelevant sind.

Durch die Erhöhung der Aufzeichnungsintensität wird die Wahrscheinlichkeit gesteigert, Angriffe zu erfassen und durch die Auswertung der Protokolle nachzuweisen. Dabei handelt es sich jedoch nicht um einen linearen Prozeß, d.h. die Verdoppelung der Aufzeichnungsdaten verdoppelt nicht die Wahrscheinlichkeit der Erfassung von Angriffen. Die Abb. 4 verdeutlicht dieses Verhältnis.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Das Verhältnis zwischen Aufklärungserfolg

und Auditingkosten

Die schraffierte Fläche zeigt die Aufzeichnungs-/Auswertaufwendungen, die einen Mindestaufklärungserfolg im Unternehmen garantieren sollen. Aus der Skizze ist ersichtlich, daß das Aufzeichnen nicht beliebig intensiviert werden darf, wenn die Kosten und der Nutzen in einem vernünftigen Verhältnis zueinander stehen sollen.

Für die verschiedenen Fälle der Aufzeichnungsintensität dürfte aus diesem Grund die Stufe 2 zu favorisieren sein, da die Auditdatei wesentlich kleiner gehalten wird und die Auswertung dadurch unterstützt werden kann.

5.1.1 Systembezogene Kriterien

Das protokollierende Unternehmen legt fest, innerhalb welcher Anwendung für welche Ressourcen protokolliert wird. Dabei wird unabhängig vom Benutzer die Intensität der Aufzeichnung festgelegt.

Beispiel:

Ein Unternehmen legt datenbezogen 4 Intensitätsstufen fest:

Abbildung in dieser Leseprobe nicht enthalten

Daten des Pools A Aufzeichnung aller Aktionen

Daten des Pools B Aufzeichnung schreibender Aktionen

Daten des Pools C Aufzeichnung lesender und schreibender Aktionen

Daten des Pools D Aufzeichnung der An- und Abmeldung

Falls grundsätzlich nur stichprobenweise der Auditdatenbestand ausgewertet werden soll und konkrete fallbezogene Anfragen unterbleiben, kann eine Zufallsprotokollierung implementiert werden. Beispielsweise wird dann jeder 10. Zugriff protokolliert. Durch diese Maßnahme wird vor allem ein Abschreckungseffekt für potentielle Angreifer erzielt. Der Protokolldatenbestand kann so wesentlich minimiert werden.

5.1.2 Anwenderbezogene Kriterien

Der Umfang der Protokollierung kann grundsätzlich von Eigenschaften des Anwenders abhängig gemacht werden. Die Aktionen des Systemadministrators werden oft aus technischen Gründen nicht aufgezeichnet. Er hat in der Regel unbeschränkte Zugriffsmöglichkeiten auf das gesamte System. Folglich kann auch die Auditdatei nur schwer gegen seinen Zugriff geschützt werden.

Bei Geheimnisträgern mit weitreichenden Zugriffsmöglichkeiten ist zu berücksichtigen, daß bei einer Protokollierung der Aktionen über die Auditdatei ein zusätzlicher Schwachpunkt geboten wird. Ein Angreifer könnte versuchen, über die Aufzeichnungsdatei an die geheimen Daten zu gelangen.

[...]

---

^[1] [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.