Fachhochschule Bonn-Rhein-Sieg
Fachbereich Informatik

Bachelorarbeit
zur Erlangung des Grades
Bachelor of Science in Computer Science

Konzeption eines Datenmodells und einer Schnittstelle für die Integration der Netzwerkinfrastruktur in ein zentrales IT-Compliance-Management

Andreas Neth

Inhaltsverzeichnis

1. Einführung ... 1

1.1. Motivation ... 1
1.2. Ziel ... 2
1.3. Definition “Compliance” ... 2
1.4. Compliance als Prozess ... 3

2. Anforderungsanalyse ... 5

2.1. Anforderungen an die Schnittstelle ... 5
    2.1.1. Schnittstelle zur Compliance-Lösung ... 5
    2.1.2. Schnittstelle zum Netz ... 6
2.2. Beschreibung des Netzes ... 7
    2.2.1. Technische Sicht ... 7
    2.2.2. Begriff der Datenverbindung ... 9
    2.2.3. Anomalien ... 9
    2.2.4. Sonderfälle ... 12

3. Existierende Konzepte ... 14

3.1. Network-Monitoring ... 14
    3.1.1. Definition Network-Monitoring ... 14
    3.1.2. Definition Network-Management ... 15
3.2. Configuration Management ... 15
    3.2.1. Allgemeines ... 15
    3.2.2. Produktbeispiele ... 15
    3.2.3. Vergleich Compliance/Configuration Management ... 15
3.3. Vulnerability Scanning ... 16
    3.3.1. Allgemeines ... 16
    3.3.2. Produktbeispiele ... 17
3.4. Intrusion Detection ... 18
    3.4.1. NIDS und HIDS ... 18
    3.4.2. Snort ... 19
3.5. Zusammenfassung ... 19

4. Arbeitshypothese ... 21

4.1. Architektur ... 21
4.2. Grundidee ... 22
4.3. Aufgabenverteilung ... 23
4.4. Verkehrsaufkommen ... 24
    4.4.1. Bestimmende Faktoren ... 24
    4.4.2. Herleitung einer Formel zu Berechnung einer oberen Schranke gleichzeitig möglicher Verbindungen ... 24
    4.4.3. Rechenbeispiel ... 26
4.5. Zusammenfassung ... 28

5. Modellierung ... 29

5.1. Modellierung der Policy ... 29
    5.1.1. Modellierung von Regeln ... 29
    5.1.2. Zuordnung von Regeln ... 31
5.2. Modellierung der Messdaten ... 34
5.3. Anwendung der Regeln ... 34
    5.3.1. Vorfilterung ... 35
    5.3.2. Prüfung gegen die Policy ... 38
5.4. Platzierung der Policy ... 40
5.5. IDS-Anbindung ... 42
5.6. Scanner-Anbindung ... 43
5.7. Firewall-Anbindung ... 43
5.8. Anbindung an den Compliance Manager ... 44
5.9. Sicherheitsbetrachtungen ... 46

6. Prototyp ... 48

6.1. Testnetz ... 48
6.2. Policy und Regeln ... 49
6.3. Testdaten ... 51

7. Bewertung ... 53

7.1. Compliance der Compliance ... 53
7.2. Sicherheitsaspekte ... 53
7.3. Skalierbarkeit ... 54
7.4. Vollständigkeit ... 54
7.5. Datenschutz ... 54

8. Zusammenfassung ... 56

9. Ausblick ... 57

9.1. Anbindung Risk Management ... 57
9.2. Erweiterungen ... 57
9.3. Weitere Optimierungen ... 57
9.4. Alternative Modellierungsmöglichkeiten ... 58

A. Abbildungen ... 62

A.1. RM-Metadatenmodell ... 63
A.2. RM-Metadatenmodell mit Views ... 64

B. Quellcode ... 65

B.1. Shellscript zur Berechnung gleichzeitiger Verbindungen ... 65
B.2. SQL-Statement für Transaktion der Compliance-Verletzungen zum ITSCM ... 65
B.3. SQL-Statement für die Auswertung und Verschiebung der bisher gesammelten Verkehrsdaten ... 66

C. Testdaten für den Prototyp ... 67

C.1. Adressen ... 67
C.2. Regelzuordnung ... 67
C.3. Tabelle “traffic” und Views ... 69

1. Einführung

Im Bereich der öffentlichen Verwaltung, insbesondere in der Bundeswehr, herrschen, auch im Bereich der IT, wesentlich striktere Aufgabentrennungen, als in der Wirtschaft. Auch der Betrieb der IT-Infrastruktur ist aufgabentechnisch vom Bereich der IT-Sicherheit getrennt, womit die IT-Sicherheit zwar die Kompetenz zur Durchführung von Systemaudits besitzt, aber keine Befugnis, erkannte Mängel eigenhändig ab zu stellen.
Bedingt durch den hohen organisatorischen und personellen Aufwand, den ein Systemaudit bedeutet, erwächst die Motivation, zumindest Teile eines solchen Audits zu automatisieren. Ergänzend zum bereits existierenden Anteil für den Bereich Systems Compliance, soll im Rahmen dieser Arbeit nun eine Anbindung für den Bereich Network Compliance an das zentrale Compliance-Management konzipiert werden.

Im Rahmen dieser Arbeit wird nun betrachtet werden, welche Netzwerk-Daten im Kontext eines Compliance-Managements sinnvoll erhoben werden können. Anschließend werden verwandte Konzepte betrachtet, die ähnliche Funktionen oder Teilfunktionen besitzen. In einer ersten Arbeitshypothese wird die Grundidee vorgestellt. Zudem werden einige Designentscheidungen an Hand einer Abschätzung des Datenvolumens veranschaulicht. Im 5. Kapitel wird das eigentliche Datenmodell mit der zu Grunde liegenden Logik vorgestellt, eine prototypische Test-Implementierung erfolgt in Kapitel 6. Im Anschluss folgen noch eine Bewertung und ein Ausblick auf weitere Entwicklungsmöglichkeiten.

1.1. Motivation

“IT-Sicherheit ist ein Prozess und kein Produkt”, darin sind sich auch Autoritäten im Bereich der IT-Sicherheit, wie das Bundesamt für Sicherheit in der Informationstechnik (BSI) und Bruce Schneier, einig. [BSI06, Sch01] Ein immer wiederkehrender Bestandteil dieses Prozesses sind auch Sicherheits-Audits, die trotz sorgfältiger Konfiguration häufig die einzige Möglichkeit darstellen, Schwachstellen und Fehler zu entdecken. Den immensen Aufwand, den manuelle Audits bedeuten, zu reduzieren und wenigstens teilweise zu automatisieren ist das Ziel einer ganzheitlichen Compliance-Lösung für den Bereich IT-Sicherheit. Für viele Teilbereiche existieren bereits fertige Lösungen, die Daten über das Netz sammeln und Schwachstellen entdecken. Bisher fehlt aber eine praktikable Lösung, um diese Daten zu konsolidieren, in durch die eingesetzte Compliance-Lösung verwertbarer Form zu übergeben und von dieser auswerten zu lassen, um so eine ganzheitliche Betrachtung des Netzes zu ermöglichen. Hierdurch entstehen Daten an verschiedenen Stellen, die zwar alle Aussagen über die Compliance des Netzes beinhalten, aber durch die notwendige manuelle Zusammenführung in großen Netzen nur schwierig handhabbar sind. Gerade in großen Netzen mit einer Vielzahl von Systemen, wo die Gefahr übersehener Sicherheitslücken besonders groß ist, ist daher eine Automatisierung der Überprüfung und der Datenauswertung von besonderer Bedeutung.
Die samt Metadatenmodell zu entwickelnde Schnittstelle soll nun eine Möglichkeit zur Verfügung stellen, die heterogenen Daten in einem einheitlichen Datenmodell zu sammeln und so eine konsolidierte Sicht auf den erfassten Datenbestand zu ermöglichen.

1.2. Ziel

Im Rahmen der Aufgabenstellung soll nun ein Datenmodell konzipiert werden, um derartige gesammelte Daten aus einem Netz zu erfassen und in aufbereiteter Form an ein globales IT-Compliance-Management-System zu übergeben.
Zunächst soll betrachtet werden, auf welchen OSI-Schichten überhaupt Daten erfasst und wie diese zusammengeführt werden können. Des weiteren soll geprüft werden, wo und wie diese konsolidierten Daten gegen eine konkrete Policy geprüft werden können und wie diese auszusehen hat.
Im konkreten Fall soll die Schnittstelle zur Erfassung von Daten in einem Rechenzentrum der Bundeswehr genutzt werden. Als Compliance-Lösung wird der IBM Tivoli Security Compliance Manager(ITSCM) zum Einsatz kommen. Das zu Grunde liegende Netz basiert auf IP und Ethernet.
Die Betrachtung wird daher im Rahmen dieser drei Vorgaben keine zusätzlichen Compliance- Lösungen oder LAN-Technologien betrachten.

Abbildung 1.1.: Architekturentwurf der Gesamtschnittstelle [nur in der Download-Version verfügbar]

1.3. Definition “Compliance”

Das vom englischen “to comply” (engl.: “m. etw. übereinstimmen”, “befolgen”) abgeleitete Substantiv “Compliance” beschreibt den Zustand der Übereinstimmung mit einer Regel oder einer Anforderung. [Hor95]
Der Begriff “Compliance Management” bezeichnet demnach den Prozess, des Managements der Übereinstimmung (mit einer Vorgabe).
Der ursprünglich aus dem Bereich der amerikanischen Wirtschaft stammende Begriff “Compliance” wird jedoch in einer spezialisierteren Form gebraucht, und beschreibt in dieser die Einhaltung rechtlicher Vorgaben und Gesetze. [Völ06, Gei00, Ado06]
Im Kontext des IBM Tivoli Security Compliance Managers ist der eigentliche Gegenstand die “Security Compliance”, welche implizit aus den gesetzlichen Anforderungen abgeleitet werden kann. So lassen sich beispielsweise datenschutzrechtliche Anforderungen auf technische Anforderung an die IT-Sicherheit abbilden. Die Grundschutzkataloge des BSI bieten hierbei eine Hilfe, indem zu einem Katalog von Gefährdungen ein Katalog von Maßnahmen geliefert wird. [BSI05]
Diese gesamte, technische IT-Security-Compliance gliedert sich, vergleichbar mit einem Integrierten Management [Ste04], in drei Teilbereiche:

Systems Compliance, die die Compliance eines auf dem Host laufenden Betriebssystems beschreibt.

Application Compliance, welche die Compliance im Bereich der auf den Systemen laufenden Anwendungen beschreibt.

Network Compliance, die Gegenstand dieser Arbeit ist und das den Systemen zu Grunde liegende Netz betrachtet.

Abbildung 1.2.: Säulen IT-Compliance [nur in der Download-Version verfügbar]

1.4. Compliance als Prozess

Als Sicherheitsbestandteil ist auch Network-Compliance kein Produkt sondern ein Prozess. Die anfangs zu definierende Policy muss Schritt für Schritt auf die technischen Gegebenheiten des Netzes abgebildet werden und laufend auf dem aktuellen Stand gehalten werden.
Im Betrieb muss das überwachte System kontinuierlich auf die Einhaltung der Policy überprüft werden. Hier kommt eine geeignete Compliance-Lösung zum Einsatz, die an das konkrete Einsatzszenario angepasst sein muss.
Stellt das Compliance-Management eine Compliance-Verletzung fest, so muss auf diese reagiert werden. Die möglichen Reaktionen sind eine Behandlung der Ursache für die Compliance-Verletzung, oder eine Anpassung der Policy. Die Behandlung der Ursache kann die Rekonfiguration eines Systems, oder das Entfernen eines unerlaubten Systems sein. Eine Anpassung der Policy ist erforderlich, wenn die Policy das Netz unzureichend beschreibt und zulässiges Verhalten so bereits für Compliance-Verletzungen sorgt.

[...]