1. Einführung
1.1. Motivation
1.2. Ziel
1.3. Definition “Compliance”
1.4. Compliance als Prozess
2. Anforderungsanalyse
2.1. Anforderungen an die Schnittstelle
2.1.1. Schnittstelle zur Compliance-Lösung
2.1.2. Schnittstelle zum Netz
2.2. Beschreibung des Netzes
2.2.1. Technische Sicht
2.2.2. Begriff der Datenverbindung
2.2.3. Anomalien
2.2.4. Sonderfälle
3. Existierende Konzepte
3.1. Network-Monitoring
3.1.1. Definition Network-Monitoring
3.1.2. Definition Network-Management
3.2. Configuration Management
3.2.1. Allgemeines
3.2.2. Produktbeispiele
3.2.3. Vergleich Compliance/Configuration Management
3.3. Vulnerability Scanning
3.3.1. Allgemeines
3.3.2. Produktbeispiele
3.4. Intrusion Detection
3.4.1. NIDS und HIDS
3.4.2. Snort
3.5. Zusammenfassung
4. Arbeitshypothese
4.1. Architektur
4.2. Grundidee
4.3. Aufgabenverteilung
4.4. Verkehrsaufkommen
4.4.1. Bestimmende Faktoren
4.4.2. Herleitung einer Formel zu Berechnung einer oberen Schranke gleichzeitig möglicher Verbindungen
4.4.3. Rechenbeispiel
4.5. Zusammenfassung
5. Modellierung
5.1. Modellierung der Policy
5.1.1. Modellierung von Regeln
5.1.2. Zuordnung von Regeln
5.2. Modellierung der Messdaten
5.3. Anwendung der Regeln
5.3.1. Vorfilterung
5.3.2. Prüfung gegen die Policy
5.4. Platzierung der Policy
5.5. IDS-Anbindung
5.6. Scanner-Anbindung
5.7. Firewall-Anbindung
5.8. Anbindung an den Compliance Manager
5.9. Sicherheitsbetrachtungen
6. Prototyp
6.1. Testnetz
6.2. Policy und Regeln
6.3. Testdaten
7. Bewertung
7.1. Compliance der Compliance
7.2. Sicherheitsaspekte
7.3. Skalierbarkeit
7.4. Vollständigkeit
7.5. Datenschutz
8. Zusammenfassung
9. Ausblick
9.1. Anbindung Risk Management
9.2. Erweiterungen
9.3. Weitere Optimierungen
9.4. Alternative Modellierungsmöglichkeiten
A. Abbildungen
A.1. RM-Metadatenmodell
A.2. RM-Metadatenmodell mit Views
B. Quellcode
B.1. Shellscript zur Berechnung gleichzeitiger Verbindungen
B.2. SQL-Statement für Transaktion der Compliance-Verletzungen zum IT- SCM 65
B.3. SQL-Statement für die Auswertung und Verschiebung der bisher gesammelten Verkehrsdaten
C. Testdaten für den Prototyp
C.1. Adressen
C.2. Regelzuordnung
C.3. Tabelle “traffic” und Views
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.
“IT-Sicherheit ist ein Prozess und kein Produkt”, darin sind sich auch Autoritäten im Bereich der IT-Sicherheit, wie das Bundesamt fu ¨ 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.
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 in dieser Leseprobe nicht enthalten
Abbildung 1.1.: Architekturentwurf der Gesamtschnittstelle
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.
Net work Compliance, die Gegenstand dieser Arbeit ist und das den Systemen zu Grunde liegende Netz betrachtet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1.2.: Säulen IT-Compliance
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.
Im folgenden Kapitel werden die an Schnittstelle und Datenmodell gestellten Anforderungen erarbeitet. Zunächst werden die von Netzund Compliance-Manger-Seite gestellten Schnittstellenanforderungen betrachtet. Anschließend erfolgt eine technische Betrachtung des Netzes und der daraus resultierenden Anforderungen an das Datenmodell.
Die festen Vorgaben hinsichtlich der Gesamt-Schnittstelle sind nur in kleinen Teilen vorgegeben und müssen somit weitestgehend aus der vorhandenen Einsatzumgebung, so wie den Zielsetzungen abgeleitet werden. Hinsichtlich einer angestrebten Investitionssicherheit sollten absehbare Entwicklungen, wie z.B. die Umstellung auf IPv6, berücksichtigt werden.
Die zentrale Compliance-Lösung, der ITSCM, arbeitet mit einer Client-Server Architektur. [IBM04b] Der Server ist hierbei das zentrale System, über das die gesammelten Daten zentral gespeichert und ausgewertet werden. Clients sind all die Systeme, die Daten über den auf ihnen installierten Kollektor an den Server liefern. Kollektoren sind kleine Java-Programme, die Daten auf den Clients erheben. Die Auswertung der Daten hinsichtlich einer definierten Policy erfolgt mittels auf dem Server ausgeführter SQL-Statements über die in der zentralen DB2-Datenbank gespeicheren Daten. Die Kollektoren liefern somit lediglich Daten, führen aber noch keine Bewertung der Daten durch. Die Zeitpunkte, zu denen die Kollektoren Daten an den Server liefern lassen sich über einen Scheduler flexibel konfigurieren. Optional können noch Kollektor-Proxies eingesetzt werden, die als Proxy für beliebige andere Kollektoren fungieren können und so eine so genannte “Hub-Spoke-Architektur” ermöglichen. IBM empfiehlt als Designziel eine Laufzeit von < 10 Sekunden für einen einzelnen Kollektorlauf.
Auf Seiten des zentralen Compliance Managers läuft ein zweiter Scheduler, der zu bestimmten Zeitpunkten die SQL-Auswertung der gesammelten Daten vornimmt und das Ergebnis in Form eines Snapshots speichert.
Die Schnittstelle in Richtung Compliance-Manager muss also Daten liefern, die mittels eines Java-Kollektors ausgelesen werden können. Zudem muss die Art der Daten eine Auswertung mittels SQL erlauben, vorzugsweise mit geringer Komplexität.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1.: Architektur IBM Tivoli Security Compliance Manager
Die zweite, indirekte Vorgabe wird durch die vorhandene Einsatzumgebung impliziert, die im wesentlichen ein typisches Rechenzentrum, basierend auf IP und Ethernet, darstellt. Hierdurch ergibt sich die Anforderung, die eben bei diesen Protokollen relevanten Daten verarbeiten zu können.
Die Schnittstelle muss somit in der Lage sein, von gängigen Werkzeugen gelieferte Daten entgegen zu nehmen, also eine Möglichkeit bieten, derartige Werkzeuge mit der Schnittstelle zu koppeln.
Nach Möglichkeit sollte auch die Architektur mit verteilten Kollektoren unterstützt, zumindest jedoch nicht erschwert werden.
Im Folgenden werden die technischen Gegebenheiten des Netzes betrachtet, für das die Anbindung an den Compliance-Manager erfolgen soll. Die Eigenschaften des Netzes werden kurz eingeführt, im Anschluss erfolgt eine Beschreibung einiger Arten von zu erfassenden Anomalien. Schließlich wird noch auf einige im Rahmen dieser Arbeit nicht weiter betrachtete, jedoch für den praktischen Einsatz interessante Sonderfälle hingewiesen.
Betrachtet man das Netz aus technischer Sicht, so herrschen die gängigen Standards wie Ethernet und IP vor. Wie für ein IP-basiertes Netz üblich, sind im Netz des Kunden verschiedene Teilnetze durch Router und Firewalls voneinander getrennt. Diese Router sorgen als Komponenten der OSI-Schicht 3 zum einen für die Auftrennung der Kollisionsbzw. Broadcastdomänen, bieten aber zum anderen z.T. auch Firewall- Funktionalitäten, die den eigentlichen IP-Verkehr blockieren können.
Folglich ist neben dem IP-Protokoll (derzeit Version 4) und den darauf aufsetzenden Protokollen (TCP und UDP) mit Ethernet auf der Schicht 2 zu rechnen.
Über das gesamte Netz hinweg können nun die IP-Verbindungen von Host zu Host gemessen werden (Point-to-Point, Unicast). Die zweite Möglichkeit für IP-Kommunikation ist ein Bro a dcast, also das Senden von einem Host an alle Hosts (innerhalb eines Subnetzes). Als dritte Möglichkeit existiert noch der Multicast, also das Senden von IP-Paketen von einem Host an eine Gruppe von Hosts.
Auf der Schicht 2 sind die höherschichtigen Datenverbindungen ebenfalls sichtbar - hier in der Form von Ethernet-Frames. Beim Ethernet sind ebenfalls direkte Host-zu-Host Übertragung und Multicast sowie Broadcast möglich. [Hei02a] Bei der direkten Hostzu-Host Kommunikation ist zu beachten, dass auf der Schicht 2 immer nur innerhalb einer Broadcastdomäne kommuniziert wird. Hier sind somit drei Fälle möglich:
- direkte Kommunikation zwischen zwei Hosts, die sich innerhalb der gleichen Broadcastdomäne befinden (Abb. 2.2)
- in der betrachteten Broadcastdomäne terminierende oder beginnende Kommunikation auf höheren Schichten, bei der ein Host auf der Schicht 2 Daten mit einem Router austauscht (Abb. 2.3)
- Transitverkehr, bei dem innerhalb der gleichen Broadcastdomäne Daten zwischen zwei Routern ausgetauscht werden (Abb. 2.4)
Die beiden letzteren Fälle sind hier von besonderer Bedeutung, da hier zwar alle Frames zur gleichen Verbindung auf den Schichten oberhalb der Schicht 3 gehören, aber auf der Schicht 2 getrennte Einzelverbindungen darstellen. Die Zuordnung von MAC-Adressen zu IP-Adressen muss hier also für jede Broadcastdomäne separat erfolgen
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2.: Direkte Kommunikation innerhalb einer Broadcastdomäne
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3.: In einer Broadcastdomäne terminierende Verbindung
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4.: Durchgangskommunikation zweier außerhalb der Broadcastdomäne liegender Hosts
Im weiteren Verlauf dieser Arbeit beschreibt der Begriff Datenverbindung eine allgemeine, abstrakte Kommunikationsbeziehung zwischen zwei Systemen. Wird eine bestimmte Kommunikatonsbeziehung auf einer Schicht L k definiert, so umfasst sie alle als Bestandteil dieser Verbindung auftretenden PDUs der Schichten L n mit 2 ≤ n ≤ k. Zu einer definierten TCP-Verbindung gehören somit alle TCP-Datagramme, die Datagramme transportierenden IP-Pakete sowie die die IP-Pakete transportierenden Ethernet- Frames.
Eine Datenverbindung wird unabhängig von der Zeit definiert. Zwei verschiedene SMTP-Verbindungen von Host A zu Host B, die an 2 verschiedenen Tagen auftreten, gehören somit zur gleichen Datenverbindung.
Ein an einer Datenverbindung beteiligtes System kann ein einzelner Host (Unicast), eine Gruppe von Hosts (Multicast), oder alle Hosts (Broadcast) sein. Die Beschreibung einer Datenverbindung kann mittels Platzhaltern erfolgen, um so eine Flexibilität der Beschreibung zu erreichen. Ein Beispiel wäre die Beschreibung von: Verbindung mit Quell-IP 10.1.1.1, Quell-MAC 42:47:11:08:15:FF, Ziel-Port TCP/25, Ziel-IP *, Ziel MAC
Da die Entdeckung von Anomalien im Netz das eigentliche Ziel des Compliance Managements ist, müssen die möglichen Anomalien zunächst beschrieben werden. Anomalien sind grundsätzlich jede Form von unerwünschten Daten.
Diese können unerwünschte Adressen, unerwünschte Kombinationen von Daten oder Adressen, oder auch nicht protokollkonforme Daten sein.
Im Folgenden werden einige gängige Anomalien, geordnet nach den Schichten des OSI- Referenzmodells, beschrieben. Da oberhalb der Schicht 4 eine nicht überschaubare Protokollvielfalt (vgl. [Hei02b]) existiert, wird der Schwerpunkt der Betrachtung auf die Schichten 2-4 beschränkt sein. Da bereits eine vollständige Anomaliebetrachtung der Schichten 2-4 den Rahmen dieser Arbeit übersteigt, wird auf Protokolle der Anwendungsschicht nur im erforderlichen Maße eingegangen.
Schicht 2
Eine Anomalie auf der Schicht 2 ist, im Bereich Ethernet, zunächst das Auftreten einer unbekannten MAC-Adresse oder einer laut Soll-Konfiguration nicht möglichen Kombination von MAC-Adressen. (z.B. MAC-Adressen aus zwei verschiedenen Broadcastdomänen) Eine unbekannte MAC-Adresse kann ein Indiz für ein unbefugt an das Netz angeschlossenes System sein, oder auf ein falsch konfiguriertes System hinweisen. Virtualisierungslösungen vergeben beispielsweise eigene MAC-Adressen für jede virtuelle Maschine. Im Falle einer falschen Konfiguration könnte die konfigurierte MAC-Adresse solch einer virtuellen Maschine von der Soll-Adresse abweichen und als Anomalie erkannt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.5.: Der Fokus der Arbeit beschränkt sich auf die Sichten 2-4 des OSI- Referenzmodells
Eine nach der im Vorfeld definierten Policy im korrekten Betrieb nicht mögliche Kombination von MAC-Adressen weist entweder auf Fremdsoftware im Netz, oder auf eine falsche Konfiguration des Netzes hin.
Fremdsoftware könnten in diesem Falle Tools für sog. “Frame-Injection” sein, also das Senden von manuell generierten Ethernet-Frames. Hierbei kann auch eine MAC- Adresse adressiert werden, die dem System nicht bekannt ist.
Ist ein Netz falsch konfiguriert, beispielsweise durch nicht korrekt voneinander getrennte VLANs, so ist der Netzwerkverkehr eines Hosts unter Umständen in einer anderen Broadcastdomäne sichtbar. Hierbei kann dann die von diesem Host auf der Schicht 2 ausgehende Kommunikation beobachtet werden, obwohl diese nicht über Router hinweg sichtbar sein dürfte. In durch Switche verbundenen Netzen ist eine derartige Anomalie nicht immer zu entdecken, da Switche bereits eine Wegeführung vornehmen. Durch die auch in geswitchten Netzen sichtbaren Broadcasts der Schicht 2 oder durch Messung am Mirror-Port eines Switches lässt sich jedoch auch eine derartige Anomalie entdecken. Weitere Anomalien können Ethernet-Frames sein, die nicht den Spezifikationen entsprechen, beispielsweise Frames die weniger als 64Byte lang sind.
Schicht 3
Anomalien, im Sinne der Compliance, auf Schicht 3 sind grundsätzlich unbekannte oder unerwünschte Adressen dieser Schicht, also IP-Adressen.
Unerwarteter IP-Verkehr kann auf falsch konfiguriertes Routing, falsch konfigurierte Firewalls sowie auf die von der Schicht 2 “geerbten” Anomalien zurück zu führen sein. Ist eine Route in einem Host, oder einem Router nicht korrekt eingetragen, so wird der IP-Verkehr ggf. in oder durch ein falsches Subnetz geroutet. In diesem Subnetz kann nun der unerwünschte Netzwerkverkehr beobachtet werden(Abb. 2.6). Weitere Arten
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.6.: Beispiel für fehlerhaftes Routing
von Anomalien sind fehlerhafte, oder nicht dem Protokoll entsprechende Pakete. Diese können durch fehlerhafte TCP-Stacks, defekte Hardware oder Angriffe auf das Netz auftreten.
Schicht 4
Beispiele für Anomalien auf der Schicht 4 sind das Auftreten nicht erlaubter Schicht 4-Protokolle oder die Nutzung bzw. Verfügbarkeit nicht gestatteter Dienste. Mögliche “unerwünschte” Protokolle der Schicht 4 sind beispielsweise Routingprotokolle wie RIP und OSPF.1
Schichtübergreifende Anomalien
Ein Beispiel für schichtübergreifende Anomalien sind z.B. Tupel von MAC u. IP- Adressen, die nicht auftreten dürften. So deutet ein IP-Paket, mit einer Quelladresse I P A und einer MAC-Adresse M AC B auf einen möglichen Angreifer hin, wenn der Host, dem IP A zugewiesen wurde, eigentlich die MAC-Adresse MAC A besitzt. Eine derartige Messung ist natürlich nur innerhalb der gleichen Broadcastdomäne möglich, da dieser Fall sonst auf jedes Datenpaket zutreffen würde, das einen Router passiert hat.
Verschlüsselung
Generell verbergen Tunneling-Protokolle, oder Verschlüsselungsverfahren die Inhalte der Kommunikation vor dem (in diesem Falle gewollten) Mitlesen.[VHR03] IPSec, welches auf der Schicht 3 arbeitet, verbirgt den Inhalt des IP-Pakets und lässt somit keine Analyse der Schicht-4-Protokolle mehr zu. [Hei02b] Es kann somit nicht erkannt werden, welcher Dienst auf welchem Host genutzt wird. Bilden die beiden Hosts gar einen VPN-Tunnel, so kann von außen nicht festgestellt werden, ob die beiden Systeme direkt kommunizieren, oder ob sie lediglich eine Verbindung für andere Hosts weiterleiten. Zudem bietet L2TP, das Layer-2-Tunneling-Protocol, noch die Möglichkeit, Ethernet-Verkehr über IPSec zu tunneln, wodurch nur der eigentliche VPN-Tunnel für die Messwerkzeuge sichtbar ist. Mit dem proprietären PPTP, oder dem auf SSL-Basis arbeitenden OpenVPN verhält es sich ähnlich, auch hier wird der Datenverkehr innerhalb des Tunnels vor der Analyse geschützt. Verschlüsselungsverfahren auf der Schicht 3, wie IPSec, verbergen alle Informationen oberhalb der Schicht 3 und sind nur als IP-Verbindung zu erkennen, während Protokolle wie SSL und TLS eine genauere Zuordnung an Hand der Portnummern zulassen.
Im weiteren Verlauf wird auf die Auswertung verschlüsselter Daten nicht näher eingegangen, im praktischen Einsatz müssen die Konsequenzen verschlüsselter Datenübertragung jedoch berücksichtigt werden.
Andere Protokolle
Verschiedene, größtenteils proprietäre, Protokolle wie SMB oder auch das Cisco Discovery Protocol(CDP) werden zum Teil von der eigentlichen Netz-Infrastruktur(Router, Switches) genutzt, um Daten auszutauschen. Auch das Spanning-Tree Protocol ist insbesondere in großen Netzen zu erwarten und fällt aus dem primär betrachteten IP-Protokoll-Stack heraus. Diese Protokolle, die z.T. parallel zum IP-Protokoll angesiedelt sind, müssen entweder ebenfalls im Datenmodell berücksichtigt werden, oder aus der Erfassung ausgeklammert werden.
Auf IP aufsetzende Routingprotokolle wie RIP oder OSPF sind hiervon nur eingeschränkt betroffen, da zumindest bis zur Schicht 3 hin die primär zu betrachtenden Protokolle IP und Ethernet genutzt werden.
Während Software-Lösungen wie BladeLogic [Bla] oder der im Rahmen dieser Arbeit im Vordergrund stehende Tivoli Security Compliance Manager [IBM04b] bereits fertige Lösungen für den Bereich System-Compliance bieten, herrscht noch ein Mangel an fertigen Lösungen für eine gesamte Network-Compliance.
Es existiert jedoch eine Reihe von Konzepten und Tools, die funktional nahe an dem
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1.: Säulen der IT-Compliance
liegen, was das Network-Compliance-Management leisten muss. Im folgenden erfolgt nun eine Betrachtung dieser Einzel-Konzepte.
Im folgenden Kapitel werden bestehende Konzepte betrachtet, die ähnliche Ziele verfolgen, wie das Network-Compliance-Management.
Da in den bisherigen Recherchen noch keine Lösungen im Bereich Network-Compliance zu finden waren, werden die verwandten Konzepte gegen den Bereich der Network- Compliance abgegrenzt und dahingehend betrachtet, was für eine Network-Compliance- Lösung übernommen werden kann.
Definitionen des Network-Monitoring (Netzüberwachung) sind schwierig abzugrenzen, da dieser Bereich in der Praxis zumeist ein Teilbereich des Network-Managements ist. [Heg99]
Als Essenz mehrerer Quellen lässt sich ableiten, dass es Ziel des Network-Monitorings ist, das Netz und seine Komponenten auf deren Zustand und Verhalten hin zu überwachen. Hierfür häufig herangezogene Messwerte sind Latenzzeiten, Paketverluste, Verfügbarkeit der Ressourcen sowie deren Auslastung. [Ste04, bit, Wal95, Won00]
Im Vergleich zum Compliance Management, wo die Korr ekth eit im Vordergrund steht, ist hierbei die Qualit ¨ at eines Dienstes der bestimmende Faktor, welcher sich implizit aus dem Zustand des Netzes ableitet.
Ein Beispiel: In einem Netzwerk befindet sich ein unbefugt aufgestellter Server, der intern einen HTTP-Dienst anbietet. Da der vom Netz nach außen hin angebotene SMTP-Dienst weder in seiner Vertraulichkeit, noch in seiner Verfügbarkeit oder Geschwindigkeit durch den internen HTTP-Server beeinflusst wird, leidet die Dienstgüte nicht. Aus Sicht des Network-Monitorings ist diese Situation unkritisch. Aus Sicht des Compliance-Managements ist das Vorhandensein eines unerwünschten Dienstes ein Verstoß und gegebenenfalls sogar eine Sicherheitslücke.
Unter Network-Management versteht man die Gesamtheit aller Massnahmen und Aktivitäten, die zur Sicherstellung eines zuverlässigen Netzbetriebes ergriffen werden. Diese umfassen sowohl Konfiguration als auch Überwachung des Netzes. Übliche Hilfsmittel in diesem Bereich sind das Simple Network Management Protocol (SNMP) und RMON. [Bre99, Sys01, Kau03]
Für eine Compliance-Lösung scheiden diese Konzepte aus, weil sie keine Informationen über den Sicherheitszustand des Netzes liefern.
Unter Configuration Management versteht man im weiteren Sinne die Konfiguration komplexer Systemverbunde. Nach [Kau03] ist das Configuration Management Teil des Netzwerk-Managements und beschäftigt sich primär mit der “netzwerkund systembezogenen Konfiguration der Endgeräte” und ist “die zentrale Funktion des Netzwerk- Betriebes”.
Im Zuge dieser Arbeit wird das Configuration Management bewusst separat vom Netz-Management betrachtet, um den Unterschied zwischen passiver Überwachung des Netzzustandes (Monitoring), aktiven Konfigurationsvorgängen (Configuration) und einer Überprüfung der Compliance zu verdeutlichen.
Beispiele für Lösungen im Bereich Configuration Management sind BladeLogic [Bla] und cfengine[cfe]. Beide Systeme arbeiten mittels Agenten und abstrahieren die Konfigurationsvorgänge über diese vom konkreten System.
[Hei97] definiert Konfiguration aus drei verschiedenen Sichten. Zum ersten (a) als Vorgabe und abstrakte Beschreibung des Systems. Zum zweiten (b) als den eigentlichen Prozess der Konfiguration, also dem Vornehmen von Einstellungen an den einzelnen (Netz-)Komponenten. Zum dritten (c) als den, nach Ablauf des Konfigurations- Prozesses, angenommenen Zustand. Ordnet man das Compliance Management nun in diesen Kontext ein, so kann man Compliance Management als einen Abgleich zwischen der in (a) erstellten Vorgabe und dem in (c) faktisch angenommenen Zustand definieren.
Compliance Management verifiziert also die korrekte Durchführung der Konfiguration.
Bei Betrachtung des Konzeptes des Configuration Managements wird klar, dass ein Configuration Management zu diskreten Zeitpunkten aktiv wird und somit nicht das kontinuierliche Bild eines Netzwerks liefern kann, welches für die Compliance-Prüfung benötigt wird.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2.: Der Prozess Compliance Management in Verbindung mit dem Prozess des Configuration Managements
Nach [McN04] versteht man unter Vulnerability Scannin g den automatisierten Einsatz von Tools, die das Netz, genau genommen einzelne Hosts, auf bekannte Schwachstellen hin überprüfen.
Die Bandbreite der Möglichkeiten reicht hier vom Einsatz einfacher Pings,über Port- Scanner bis hin zu vollständigen Vulnerability-Scannern wie Nessus.
Tools wie ping oder traceroute, die ICMP bzw. UPD Nachrichten versenden, geben Aufschluss über die Erreichbarkeit eines Hosts, aber beinhalten keine Informationen über auf dem Zielsystem laufende Dienste.
Vollständige Port-Scanner (vgl. NMAP) senden Nachrichten an TCP- und UDP-Ports auf dem Zielsystem um Informationen über die auf dem System laufenden Dienste zu erhalten. Die genaue Art der gesendeten Nachrichten ist sowohl von Konfiguration als auch von der konkreten Implementierung abhängig. Der einfachste Fall ist hierbei ein versuchter Verbindungsaufbau zum gewünschten Port (TCP-SYN) oder das Senden eines Datagramms (UDP). Antwortet das Zielsystem nicht mit einer Fehlermeldung, so wird angenommen, dass auf dem Zielport ein Dienst aktiv ist. Die Information, dass auf Host X ein Dienst auf dem TCP-Port 25 aktiv ist, ist jedoch noch kein Garant dafür, dass dies auch der für gewöhnlich auf diesem Port aktive SMTP-Dienst ist.
Im folgenden werden zwei weit verbreitete Vulnerability Scanner, Nessus und der ISS Internet Scanner, betrachtet, die die engere Auswahl der später einzusetzenden Werkzeuge bilden.
ISS Internet Scanner
Der Internet Security Systems Internet Scanner (ISS Internet Scanner) [Int] ist ein automatisierbares Vulnerability-Assessment-Werkzeug mit integriertem Scheduler. Es führt so z.B. Scans über IP-Netze durch, um so aktive Systeme und offene Ports zu finden. Gefundene Dienste können dann auf bekannte Verwundbarkeiten hin überprüft werden. Die Ergebnisse der Scans werden in Form von Reports zur Verfügung gestellt, die dann als HTML-, Wordoder RTF-Dokument vorliegen.
Aus den Reports lassen sich Angaben und Beschreibungen der gefundenen Dienste und Verwundbarkeiten entnehmen, die im Falle der HTML-Darstellung auch über einen, ggf. noch zu entwickelnden Parser in eine automatisierte Auswertung übernommen werden könnten.
Nessus
Der Nessus Vulnerability Scanner [Ten] bietet vergleichbar mit dem ISS Internet Scanner die Funktionen von automatisierten Port-Scans und Verwundbarkeitsprüfungen. Nessus arbeitet in einer Client-Server Architektur, in der ein zentraler Scan-Server von verschiedenen Clients genutzt werden kann, um von diesem aus Vulnerability- Scans durchzuführen. (vgl. Abb. 3.3)
[...]
1 Auch wenn RIP und OSPF generell der Schicht-3-Funktion zugeordnet werden, so werden die OSPF- bzw. RIP-Pakete dennoch in IP-Pakete verpackt, was sie aus praktischer Sicht der Schicht 4 zuordnet
