BSI-Leitfaden zur Einführung von Intrusion-Detection-Systemen

Hilfsmittel für Feinkonzept und Produktauswahl

Folgende Hilfsmittel werden für das Feinkonzept und die Produktauswahl bereitgestellt:

4.1 Abgriff des zu überwachenden Netzverkehrs

Nachstehend werden unterschiedliche Möglichkeiten des Abgriffs des zu überwachenden Netzverkehrs kurz erläutert:

Abgriff von einem Hub
Ein Hub dient zur Anbindung mehrere Komponenten an dasselbe Netzsegment. Sämtliche am Hub angeschlossene Komponenten sehen den gleichen Netzverkehr. Bei der Anbindung eines Netzsensors an den Hub kann von dem Netzsensor der gesamte Netzverkehr des entsprechenden Netzsegments abgehört und überwacht werden.
Abgriff von einem Switch
Im Gegensatz zum Hub kann bei einem Switch der Verkehr zwischen den unterschiedlichen Ports des Switches über Regeln gesteuert werden. Dies ermöglicht die Bildung von VLANs. So kann z. B. eine an Port1 angeschlossene Komponente mit einer an Port2 angeschlossenen Komponenten kommunizieren, während gleichzeitig eine an Port3 angeschlossene Komponente mit einer an Port4 angeschlossenen Komponenten kommuniziert. Dabei ist der Netzverkehr der Verbindungen separiert, d. h. der Verkehr auf der Port 1/3 Verbindung ist auf der Port 3/4 Verbindung nicht sichtbar und umgekehrt.
Die Anbindung eines Netzsensor an einen Switch hat für die Überwachung des Verkehrs den Vorteil, dass über die Programmierung des Switches eingestellt werden kann, welcher Verkehr zur Überwachung zum Sensor geleitet wird. Handelsübliche Switches bieten daneben auch sog. SPAN Ports (SPAN = Switch Port Analyser) an, über die der Netzverkehr des Switches gespiegelt werden kann. Dabei ist darauf zu achten, dass der Port über eine ausreichende Bandbreite verfügt, um auch bei hoher Last den Verkehr der Switch-Ports vollständig spiegeln zu können (vgl. auch Anhang 4.2).
Abgriff über einen TAP
TAPs dienen speziell zum Abgriff von Netzverkehr zu Überwachungszwecken. Sie sind grundsätzlich mit einem Hub (mit 3 Anschlüssen) vergleichbar, weisen jedoch an einem der Anschlüsse eine "Dioden"-Funktion auf: Über den TAP wird der Verkehr auf der Kommunikationsstrecke abgegriffen, es können jedoch keine Datenpakete in die Kommunikation hineingespielt werden. Selbst falls es einem Angreifer gelingt, über den vom Sensor überwachten Datenstrom den Netzsensors zu Fehlfunktionen zu verleiten, ist somit eine aktive Rückkopplung des Sensors auf die überwachte Strecke ausgeschlossen. Diesem Vorteil steht der Nachteil gegenüber, dass aktive Reaktionen des Netzsensors, wie z. B. das Einspielen von Reset-Paketen, auch nicht über den TAP erfolgen können.

4.2 Abgriff des Netzverkehrs bei Lastverteilung

Für die Überwachung von Netzverkehr, der auf mehrere physikalische Verbindungen verteilt ist, bieten sich folgende Lösungsmöglichkeiten an:

Einsatz mehrerer Netzsensoren

Für jede physikalische Verbindung wird ein separater Netzsensor vorgesehen. Dieser Ansatz hat den Vorteil, dass auch die Überwachung lastverteilt erfolgt. Da der Netzverkehr auf mehrere Sensoren verteilt wird, kann eine höhere Verkehrslast überwacht werden als beim Einsatz von nur einem Sensor. Nachteilig ist der hohe technische Aufwand, der sich aus dem Betrieb mehrerer Netzsensoren ergibt. Des Weiteren ist für die Angriffserkennung zu beachten, dass Zusammenhänge zwischen einzelnen Ereignissen, die von verschiedenen Sensoren erkannt wurden, erst nach deren zentraler Zusammenführung korreliert werden können. Um dieselbe Erkennungsqualität wie bei Einsatz eines einzelnen Sensors zu gewährleisten, muss die Analyse später, nach der Zusammenführung der Ereignisse erfolgen. Dies ist als Anforderung für ein auszuwählendes IDS zu berücksichtigen.

Abbildung: Einsatz mehrerer Netzsensoren

Einsatz eines Netzsensors mit mehreren Netzinterfaces

Der von den Verbindungen abgegriffene Netzverkehr wird zu separaten Netzinterfaces desselben Sensors geleitet und durch diesen ausgewertet. Dieses Vorgehen hat den Vorteil, dass ein Sensor den Netzverkehr insgesamt sieht und auswerten kann. Bei der Auswahl des Sensors ist jedoch darauf zu achten, dass dieser die Überwachung des Verkehrs mehrerer Netzinterfaces unterstützt und die Sensor-Performance die Überwachung des gebündelt vorliegenden Verkehrs erlaubt.

Abbildung: Einsatz eines Netzsensors mit mehreren Netzinterfaces

Zusammenführung des Netzverkehrs über einen Switch

Der von den Verbindungen abgegriffene Netzverkehr wird über einen Switch zusammengeführt und zu einem Netzsensors geleitet. Wie zuvor ist der Vorteil gegeben, dass ein Sensor den Netzverkehr insgesamt sieht und auswerten kann. Bei der Auswahl des Sensors ist darauf zu achten, dass die Sensor-Performance die Überwachung des gebündelt vorliegenden Verkehrs erlaubt.

Abbildung: Zusammenführung des Netzverkehrs über einen Switch

Anpassung der Konfiguration von Switches

Falls der zu überwachende Netzverkehr über Switches auf die Zielsysteme verteilt wird, besteht ggf. die Möglichkeit, den gesamten Netzverkehr durch die Anpassung der Konfiguration der Switches zentral auf einen zusätzlichen Port eines Switches zu spiegeln. Dies hat den Vorteil, dass vorhandene Komponenten für die Zusammenführung des Verkehrs genutzt werden können.

Abbildung: Abgriff des Netzverkehrs von einem Switch

4.3 Abgriff des Netzverkehrs in Multicast-Szenarien

Beim Multicast werden mehrere Systeme mit derselben Adresse (IP-/MAC-Adresse) konfiguriert. Eingehender Netzverkehr erreicht sämtliche dieser Systeme parallel und wird von diesen verteilt bearbeitet. Auf der Ebene des Netzverkehrs hat dies zur Folge, dass am Netzinterface eines Systems zwar der eingehende Verkehr vollständig anliegt, der ausgehende Verkehr jedoch nur für den von diesem System bearbeiteten Teil des Verkehrs. Diese Situation ist in der nachstehenden Abbildung skizziert. Die Überwachung des Verkehrs an dieser Stelle durch einen Netzsensor ist problematisch, da der Netzsensor nicht weiß, welcher Teil des eingehenden Verkehrs durch das System weiterbearbeitet wird und welcher nicht. Dies betrifft den oben diskutierten Ansatz 1 (Einsatz mehrerer Sensoren).

Abbildung: Skizze der Multicast-Problematik

Auch die direkte Zusammenführung des Verkehrs (oben beschriebene Ansätze 2 und 3) stellt keine Lösung dar, da im zusammengeführten Verkehr sämtliche eingehenden Pakete doppelt auftreten. Ein Filterung der doppelt auftretenden Pakete aus dem eingehenden Verkehr wäre erforderlich.

Die Problematik und eine Lösungsmöglichkeit soll am Beispiel eines hochverfügbar ausgelegten Internet-Übergang dargestellt werden, bei dem interne Router, Firewalls und externe Router doppelt ausgelegt sind (siehe nachstehende Abbildung). Die Verfügbarkeit ist sichergestellt, solange nicht beide internen Router, beide Firewalls oder beide externen Router gleichzeitig ausfallen.

Abbildung: Beispiel eines hochverfügbaren Internet-Übergangs

Realisiert wird dies typischerweise durch den Einsatz von Switches, die den Netzverkehr zwischen den Komponenten verteilen (siehe nachstehende Abbildung). Z. B. wird der von R3 kommende Verkehr über S3 an F1 und gleichzeitig (über S4) an F2 gesendet.

Abbildung: Realisierung eines hochverfügbaren Internet-Übergangs

Falls die beiden Firewalls im Multicast betrieben werden, tritt die oben dargestellte Situation an jedem der drei Netzinterfaces der Firewalls auf. Ein Abgriff des vollständigen Netzverkehrs auf den Strecken F2-S4-R4 und F1-S3-R3 ist damit nicht direkt möglich. Dies gilt in gleicher Weise für die anderen Schnittstellen der Firewalls.

Da die Switches den Netzverkehr gleichzeitig an beide Firewalls senden, liegt jedoch auf der Übertragungsstrecke zwischen S3 und S4 der vollständige Netzverkehr zwischen internem Netz und Firewall genau einmal an. Er kann hier entweder direkt über einen TAP abgegriffen werden oder auf einen zusätzlichen Port an einem der Switches gespiegelt werden. Gleiches gilt wiederum für die Schnittstellen der Firewall ins Internet und die DMZ.

Bei komplexeren, geswitchten Netztopologien ist häufig eine Konfigurationsänderung eingesetzter Switches erforderlich, um den Netzverkehr vollständig abgreifen zu können und dabei sicherzustellen, dass jedes Paket genau einmal vorkommt (vgl. auch Anhang 4.2, Ansatz 4)

4.4 Beispiel für Festlegungen zur IDS-Eskalation

IDS-Monitoring

Dem IDS-Monitoring obliegt die Beobachtung der IDS-Meldungen und eskaliert gemäß IDS-Eskalationsplan. Da das IDS-Monitoring keine Analyse der IDS-Alarme durchführt, kann auch keine qualitative Bewertung der Alarme vorgenommen werden. Die vom IDS gemeldeten Alarmlevel dienen als Grundlage für die Eskalation.

Bei Ereignissen der Alarmstufe 1 erfolgt eine Benachrichtigung des IDS-Incident-Response per E-Mail, so dass das IDS-Incident-Response spätestens am nächsten Arbeitstag auf den Alarm reagiert.
Bei Ereignissen der Alarmstufe 2 erfolgt eine sofortige Benachrichtigung des IDS-Incident-Response über eine telefonische Rufbereitschaft.

IDS-Incident-Response

Das IDS-Incident-Response bewertet das Ereignis und dessen Auswirkungen qualitativ und entscheidet,

ob das Ereignis nicht weiter zu berücksichtigen ist, da es unwichtig erscheint (z. B. Fehlalarm),
ob das Ereignis mit geringerer Priorität zu behandeln ist, da ggf. wichtigere Ereignisse vorliegen,
ob das verursachte Problem innerhalb der IT-Abteilung gelöst werden kann,
ob eine weitergehende Eskalation erforderlich ist, z. B. an den Abteilungsleiter.

Gemäß IDS-Eskalationsplan ist dabei vorgeschrieben, dass eine Benachrichtigung des Abteilungsleiter zu erfolgen hat, falls ein Problem nicht innerhalb von 4 Std. nach Kenntnisnahme behebbar ist.

Eskalationsebenen

Die oben genannten Eskalationsebenen IDS-Monitoring und IDS-Incident-Response werden je nach Organisation durch weitere Eskalationsebenen ergänzt, die über den Bereich des IDS hinausgehen.

Sobald das Problem auf Ebene der IT-Abteilung eskaliert wurde, muss ein hier definiertes (oder zu definierendes) IT-Krisenmanagement eingreifen. Ab dieser Ebene werden Angriffe, die durch das IDS erkannt werden, wie andere schwere IT-Störungen behandelt. Folgende Tabelle zeigt beispielhaft die Einbindung des IDS in eine Eskalationshierarchie.

Eskalationsstufe	Abteilung	Involvierte Rolle	Ereignisabhängige Aktion	Mitteilung an
Stufe 1	Unternehmensleitung	Vorstand
Stufe 2	Organisationsbereiche	Bereichsleiter	Eskalation zu Stufe 1
Stufe 3	IT-Gesamt	Abteilungsleiter	Einberufung eines IT-Krisenstabs Eskalation zu Stufe 2	IT-Abteilungen
Stufe 4	IT-Abteilungen (IT-Systeme, IT-Netzbetrieb)	IDS-Incident-Response	Rückstufung des Ereignisses (Downgrade) Abteilungsinterne Lösung des Problems Eskalation zu Stufe 3	IDS-Administration ggf. IDS-Manager
Stufe 5	IDS-Betrieb	IDS-Monitoring	Alarmlevel 1: Eskalation per E-Mail zu Stufe 4 Alarmlevel 2: Eskalation per Rufbereitschaft zu Stufe 4
Stufe 5	IDS-Betrieb	IDS-Administration	Nachverfolgung von Ereignissen Ggf. Eskalation zu Stufe 4