Navigation und Service

BSI - Bundesamt für Sicherheit in der Informationstechnik (Link zur Startseite)

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

Grundlagen: 1. IDS-Grundlagen und aktueller Stand

« zur Übersicht

In diesem Kapitel werden grundlegende Aspekte von Intrusion-Detection-Systemen (kurz IDS) beschrieben:

Neben der allgemeinen Beschreibung wird dabei insbesondere der jeweilige aktuelle Entwicklungsstand marktverfügbarer Produkte dargestellt.

1.1 Definition Intrusion-Detection und Intrusion-Detection-Systeme

Intrusion-Detection

Als Intrusion-Detection wird die aktive Überwachung von Computersystemen und/oder -netzen mit dem Ziel der Erkennung von Angriffen und Missbrauch bezeichnet. Das Ziel von Intrusion-Detection besteht darin, aus allen im Überwachungsbereich stattfindenden Ereignissen diejenigen herauszufiltern, die auf Angriffe, Missbrauchsversuche oder Sicherheitsverletzungen hindeuten, um diese anschließend vertieft zu untersuchen. Ereignisse sollen dabei zeitnah erkannt und gemeldet werden.

Intrusion-Detection ist als Prozess zu verstehen und bedarf einer geeigneten organisatorischen Einbindung sowie der technischen Unterstützung durch geeignete Werkzeuge.

Unterstützende Werkzeuge

Intrusion-Detection bedarf einer technischen Grundlage, um überhaupt Ereignisse aufnehmen und sie dann nach interessierenden Kriterien bewerten zu können. Eine werkzeugbasierte Unterstützung kann zur Generierung von Ereignissen, zur Filterung von Ereignissen, zur Auswertung und Alarmierung sowie zur Archivierung der gefundenen Ergebnisse erfolgen.

Ob und in welcher Form Werkzeuge den Intrusion-Detection-Prozess unterstützen können, hängt im Einzelfall vom organisatorischen und technischen Einsatzumfeld, insbesondere auch vom Überwachungsziel ab. Einfache Werkzeuge, z. B. zur Generierung und zum Vergleich von Checksummen ausgewählter Dateien oder zum Vergleich von Zeichenketten bei der Analyse von Logdateien, können hierzu ebenso nützlich sein wie komplexe Werkzeuge zur Überwachung des Netzverkehrs.

Ein wirksames Intrusion-Detection bedarf daher einer angepassten und zusammenpassenden Auswahl geeigneter Hilfsmittel.

Intrusion-Detection-System

Als Intrusion-Detection-System wird eine Zusammenstellung von Werkzeugen bezeichnet, die den gesamten Intrusion-Detection-Prozess von der Ereigniserkennung über die Auswertung bis hin zur Eskalation und Dokumentation von Ereignissen unterstützen. Der Großteil marktverfügbare Intrusion-Detection-Produkte weist diese integrierte Funktionalität auf. IDS können jedoch auch aus Einzelkomponenten zusammengesetzt werden. Auswahl und Zusammenstellung des IDS richten sich dabei nach den individuellen technischen und organisatorischen Gegebenheiten und Anforderungen.

1.2 Komponenten und Architektur von IDS

Heutige IDS bestehen typischerweise aus folgenden Komponenten:

Die Komponenten werden in den folgenden Abschnitten beschrieben. Zusätzlich sind Kommunikationsverbindungen zwischen den Komponenten vorzusehen, die in Abschnitt 1.2.6 erläutert werden.

1.2.1 Netzbasierte Sensoren

Netzbasierte Sensoren (Netzsensoren) überwachen den Netzverkehr eines Rechners oder eines ganzen Teilnetzes auf verdächtige Ereignisse. Zum Betrieb jedes Netzsensors wird typischerweise ein separater Rechner eingesetzt, so dass andere Applikationen nicht gestört werden können. Teilweise liefern Hersteller Netzsensoren nur noch in Kombination mit der zugehörigen Hardware/Software-Plattform, als sogenanntes Appliance.

Nachstehend sind Vorteile (gekennzeichnet als + ) und Nachteile (gekennzeichnet als - ) von Netzsensoren aufgeführt.

+ Durch Einbringen netzbasierter Sensoren in ein Netz, werden Endsysteme (Hosts, Server) nicht zusätzlich belastet.
+ Netzbasierte Sensoren eignen sich zur Erkennung von netzbasierten Angriffen, die sich gegen mehrere Zielsysteme richten (z. B. SYN flooding, verschiedene Arten von Denial-of-Service Angriffen). Solche Angriffe würden von einem Angriffsziel allein nicht als verteilte Angriffe interpretiert werden können.
+ Netzbasierte Sensoren können so konfiguriert werden, dass sie für Angreifer "unsichtbar" sind und von ihnen nicht direkt angesprochen werden können. Sie sind daher schwerer angreifbar als hostbasierte Sensoren.
+ Netzbasierte Sensoren können über ein zusätzliches Netzwerkinterface miteinander verbunden werden, so dass ein separates IDS-Netz aufgebaut werden kann.
- Viele der heute verfügbaren Sensoren können Netze mit einer hohen Netzlast (ab 100Mbps) bei gleichzeitig hoher Paketdichte nicht mehr vollständig überwachen. Grund hierfür ist die zur Verarbeitung notwendige hohe Rechenleistung und hohe Performance bei Zugriffen auf die Signaturdatenbank der Sensoren, die in dedizierten Netzsensoren meist nur unter sehr hohem technischen Aufwand erbracht werden kann. Grundsätzlich nimmt die Übertragungsgeschwindigkeit der Netze schneller zu als die Geschwindigkeit, mit der netzbasierte Sensoren Daten verarbeiten können. Eine Überwachung sämtlicher Datenpakete ist daher nur in Netzen mit begrenztem Durchsatz oder begrenzter Auslastung möglich.
- In verteilten Netzen (swiched networks) oder in lastverteilten bzw. redundant ausgelegten Netzstrukturen ergeben sich zusätzliche Probleme beim Abgriff des Netzverkehrs (siehe Kapitel 2.6.2).
- Netzsensoren können das Verhalten des eigentlichen Angriffsziels nur begrenzt nachvollziehen und lediglich diejenigen Auswirkungen des Angriffsversuchs wiederspiegeln, die im Netzverkehr sichtbar sind.
- Netzsensoren können keine Ereignisse in verschlüsselten Kommunikationsdaten erkennen (vgl. auch Kapitel 2.4).
- Die Angriffserkennung durch Netzsensoren ist nicht exakt und fehlerbehaftet. Dies liegt darin begründet, dass verdächtiger Netzverkehr nicht nur durch Angriffe, sondern z. B. auch durch Konfigurationsfehler anderer Schutzkomponenten oder durch Fehlern bei der Datenübertragung verursacht werden kann.

Zurück zu Komponenten und Architektur

1.2.2 Hostbasierte Sensoren

Hostbasierte Sensoren (Hostsensoren) sind dadurch gekennzeichnet, dass sie auf dem zu überwachenden System betrieben werden. Sie werden typischerweise eingesetzt, um Angriffe zu erkennen, die auf Anwendungs- oder Betriebssystemebene durchgeführt werden. Beispiele für derartige Angriffe sind Rechteüberschreitungen von Nutzern, Login-Fehlversuche oder Trojaner. Manche Hostsensoren erlauben die Überwachung des hostspezifischen Netzverkehrs.

Nachstehend werden zunächst allgemeine Vor- und Nachteile von Hostsensoren im Vergleich zu Netzsensoren aufgeführt und anschließend die verschiedenen Überwachungstypen von Hostsensoren diskutiert.

Generelle Vor- und Nachteile von Hostsensoren

+ Da Hostsensoren auf dem zu überwachendem Host betrieben werden, können sie (im Gegensatz zu Netzsensoren) die tatsächliche Reaktion des Systems beobachten und auswerten.
- Hostbasierte Sensoren müssen auf jedem zu überwachendem Host installiert werden.
- Hostbasierte Sensoren sind spezieller als netzbasierte Sensoren, da sie betriebssystem- und ggf. applikationsspezifisch sind. Daher müssen für sämtliche zu überwachende Plattformen entsprechende hostbasierte Sensoren verfügbar sein und angepasst werden. Der Einsatz hostbasierter IDS ist daher im Allgemeinen kostenaufwändiger als der Einsatz reiner netzbasierter IDS.
- Im Gegensatz zu Netzsensoren können Hostsensoren nicht unsichtbar arbeiten. Angreifer können mit dem zu überwachenden System gleichzeitig auch den Hostsensor und damit das IDS angreifen.
- Der Betrieb eines Hostsensors belastet das überwachte System.

Systemüberwachung

In diesem Fall erfolgt eine Überwachung auf Prozessebene durch den IDS-Sensor selbst.

Generelle Vor- und Nachteile von Hostsensoren

+ Zugriffe auf Dateien und Applikationen sowie Systemzugänge können überwacht werden. Häufig fehlgeschlagene Anmeldeversuche, Zugriffsverletzungen und anormale Verhaltensmuster können erkannt werden. Die Überwachung erfolgt einerseits durch Auswertung der Logdaten des Systems (inkl. Kernel-Logs), andererseits durch spezialisierte IDS-Plugins, die Prozesse überwachen, regelmäßige Integritätsscans durchführen, etc.
+ Erkanntes Fehlverhalten kann Nutzerkennungen zugeordnet werden.

Applikationsüberwachung

+ Durch applikationsüberwachende Sensoren ist eine Überwachung spezifischer Applikationen möglich, die weder durch system- noch durch netzüberwachende Sensoren erreicht werden kann. Die Überwachung erfolgt typischerweise durch Auswertung der Logdaten der Applikation.
- IDS-Sensoren müssen jedoch applikationsspezifisch angepasst werden. Häufig werden hierzu applikationseigene Komponenten mitverwendet.

Integritätsüberwachung

Bei der Integritätsüberwachung wird in regelmäßigen Abständen (ggf. auch bei jedem Dateizugriff) überprüft, ob sich Änderungen an Dateien (Daten, Programmen) ergeben haben. Dies erfolgt typischerweise durch einen Vergleich von Checksummen mit einem definierten Sollzustand.

+ Konkret erkannte Veränderungen können die Untersuchung des Vorfalls sowie die Wiederherstellung des Systems erleichtern.
+ Systemüberwachende Sensoren prüfen Dateiinhalte (z. B. Logdaten) und vertrauen auf deren Integrität. Bei der Integritätsüberwachung hängt die Überwachung nicht von Dateiinhalten ab, sondern die Dateien selbst sind das beobachtete System.
- Integritätsverletzungen sind typischerweise die Auswirkung eines erfolgreichen Angriffs. Eine Frühwarnfunktion für Angriffsversuche ist durch integritätsüberwachende Sensoren daher nicht gegeben.
- Eine Erkennung von Integritätsverletzungen erfolgt aus Kapazitätsgründen in der Regel im Batch-Betrieb und nicht in Echtzeit. Die Häufigkeit der Kontrollen ist dabei kritisch, da zu häufig durchgeführte Kontrollen zu einer nicht tragbaren Belastung des System führen können und selten durchgeführte Kontrollen das Restrisiko erhöhen.

Die Integritätsüberwachung eignet sich daher nicht als alleinige Überwachungsmethode.

Überwachung des hostspezifischen Netzverkehrs

Fallweise kann es sinnvoll sein, den zu einem dedizierten System gehörenden Netzverkehr auf diesem System selbst zu beobachten und zu analysieren.

+ Der ins System eingehende Kommunikationsdatenfluss kann auf sämtlichen Protokollebenen überwacht werden.
+ Verschlüsselte Protokolle behindern die Überwachung nicht.
+ Da das System nur entsprechend adressierte Pakete annimmt, ist das Datenaufkommen geringer. Im all gemeinen ist daher eine vollständige Prüfung des für dieses System bestimmten Kommunikationsverkehrs möglich.
- Durch die hostbasierte Überwachung werden jedoch typischerweise keine auf mehrere Ziele verteilten Angriffe erkannt.
Die hostbasierte Erkennung verteilter Angriffe würde neben einer nachträglichen sensorübergreifenden Korrelation eine sensorübergreifende Kommunikation bereits bei der Filterung an jedem Sensor erfordern. Dies würde zu einem sehr hohen Kommunikationsoverhead führen. Marktverfügbare IDS-Produkte bieten hierfür keine ausgereifte Lösung an.

Zurück zu Komponenten und Architektur

1.2.3 Datenbankkomponenten

Intrusion-Detection-Systeme erzeugen bei der Angriffserkennung Ereignisdaten, die zur späteren Weiterverarbeitung gespeichert werden müssen. Abhängig davon, wie diese Ereignisdaten weiterverwendet werden sollen, müssen sie in entsprechender Detailtiefe und über einen möglicherweise langen Zeitraum gespeichert werden.

Bei geringen Datenmengen ist eine Speicherung in Dateiform ausreichend. Abhängig von der konkreten IDS-Konfiguration können jedoch sehr große Datenmengen anfallen, die die Nutzung eines Datenbanksystems notwendig machen, um die anfallende Datenmenge aufzunehmen und zuverlässig zu verwalten sowie andererseits Zugriffszeiten zu minimieren.

Welches Datenbanksystem zum Einsatz gelangen kann, ist dabei abhängig von der Unterstützung der IDS-Hersteller. Die meisten Intrusion-Detection-Systeme beinhalten Schnittstellen zu den "gängigen" SQL-Datenbanken.

Zurück zu Komponenten und Architektur

1.2.4 Managementkomponenten

Über die Managementstation erfolgt die Konfiguration und Kalibrierung des IDS. Dies umfasst in der Regel die folgenden Funktionalitäten:

  • Aufnahme der IDS-Komponenten (Sensoren, Datenbanken, Managementstationen) in das IDS.
  • Einstellen der Kommunikationsparameter der IDS-Komponenten untereinander (IP-Adressen, Namensgebung, Kryptoschlüssel, Lebenszeichen-Intervall).
  • Aufnahme der zu überwachenden Objekte (Netze, IT-Systeme) in das IDS.
  • Erstellung und Anpassung von Überwachungsregeln und Gruppierung dieser zu "IDS-Policies".
  • Gruppierung von IDS-Sensoren.
  • Zuweisung der "IDS-Policies" zu Sensoren oder Sensorengruppen.

Die konkreten Ausführungen der Managementstationen von IDS sind unterschiedlich. Zu unterscheiden sind das Management über

  • ein Kommandozeilen-Interface
  • eine webbasierte Schnittstelle
  • ein IDS-spezifisches GUI.

Bei einigen IDS sind Management- und Auswertungsstation in einer Komponente zusammengefasst.

Zurück zu Komponenten und Architektur

1.2.5 Auswertungsstation

Die Auswertungsstation verfügt typischerweise über Funktionen zur Analyse aufgezeichneter Ereignisse und zum Reporting.

Analog zu Konfigurationsoberflächen des IDS werden auch Auswertungs- und Reporting-Tools angeboten. Auch diese sind zu unterteilen in

  • Kommandozeilen-Interface
  • Webbasierte Schnittstelle
  • IDS-eigene Auswertungsoberfläche

Die Analysefunktionalität dient primär der Erkennung und Erstanalyse eingehender IDS-Ereignismeldungen, im Einzelnen der

  • Anzeige eingehender Meldungen
  • Sortierung der Ereignisse
  • Klassifikation der Ereignisse
  • Reaktion und Alarmierung
  • Ablage der Ereignisdaten zur späteren Weiterverarbeitung

Reporting-Funktionen können sowohl zur

  • Generierung von Managementreports und -statistiken als auch zur
  • Langfristanalyse der Meldungen eingesetzt werden, um bislang unentdeckte Angriffe und Trends aufzuzeigen.

Wie die Managementstation kann auch die Auswertungsstation unterschiedlich ausgeführt sein (Kommandozeilen-Interface, webbasierte Schnittstelle, IDS-spezifisches GUI).

Zurück zu Komponenten und Architektur

1.2.6 Kommunikation zwischen den Komponenten

Die Kommunikation der IDS-Komponenten untereinander erfolgt teils über proprietäre Protokolle, teils auch über Standardprotokolle (SSH, SCP). Dabei erfolgt eine Kommunikation typischerweise zwischen folgenden Komponenten:

  • Managementstation ? IDS-Sensoren
    (Übertragung von Konfigurationsdaten, Kommandos und IDS-Policy, Abfrage von Statusdaten)
  • IDS-Sensoren ? Managementstation
    (Übertragung von Lebenszeichen – Heartbeats – bei einigen IDS)
  • Managementstation ? Datenbank
    (Übertragung von Konfigurations- und Statusdaten)
  • IDS-Sensoren ? Auswertungsstation
    (Übertragung von Ereignisdaten und ggf. Lebenszeichen)
  • Auswertungsstation ? Datenbank
    (Übertragung von Ereignisdaten)
  • IDS-Sensoren ? Datenbank
    (Übertragung von Ereignisdaten – bei einigen IDS)
  • Managementstation ? Auswertungsstation
    (Signalisierung von Konfigurationsalarmen, etwa Ausbleiben von Lebenszeichen)

Hinzu kommen Kommunikationswege

  • zur Initiierung von Intrusion-Response-Funktionen (z. B. Alarmierung),
  • zum Zugriff auf die Management- und Auswertungsstation sowie
  • ggf. eine Kommunikation zwischen verschiedenen Auswertungsstationen.

Zurück zu Komponenten und Architektur

1.3 Methoden der Angriffserkennung

In den nächsten Abschnitten wird kurz erläutert, auf welche Weise IDS Angriffe erkennen. Folgende Methoden der Angriffserkennung werden beschrieben:

Einsatz der Erkennungsmethoden in marktverfügbaren IDS-Produkten

Derzeit werden von fast allen Anbietern kommerzieller IDS Analysemethoden angewendet, die auf der Erkennung von Angriffsmustern oder auf Protokollanalyse beruhen. Zusätzlich bieten fast alle IDS die Möglichkeit zur manuellen statistischen Anomalieerkennung auf der Basis vom IDS erzeugter Reporte und Angriffsstatistiken. Die automatische statistische Anomalieerkennung ist im Gegensatz dazu kaum in marktverfügbare Produkte integriert und fast ausschließlich im wissenschaftlichen Bereich anzutreffen. Auch die Relevanz von IDS, deren Angriffserkennung auf Basis künstlicher Intelligenz erfolgt, beschränkt sich auf den wissenschaftlichen Bereich.

Die Anomalieerkennung auf Basis von Honeypots ist ein am Markt verfügbares Analyseverfahren. Honeypots werden von einigen Herstellern angeboten und sind auch im Open-Source-Bereich erhältlich. Eine automatische sensorübergreifende Korrelation von Ereignisdaten bieten nur wenige der marktverfügbaren IDS. Möglichkeiten zur manuellen Korrelation sind jedoch in der Regel gegeben.

1.3.1 Erkennung von Angriffsmustern

Als Signaturen werden im IDS-Kontext Muster bzw. Ereignisse bezeichnet, die auf einen bekannten Angriff oder ein missbräuchliches Systemverhalten hinweisen. Signaturen reichen dabei von einfacher Zeichenerkennung in Daten ("pattern matching") bis hin zu komplexen Verhaltensmustern. So erlauben sie auch die Erkennung fehlerhafter Verhaltensweisen des Systems oder einzelner Nutzer (z. B. drei Login-Fehlversuche innerhalb von 5 Minuten).

Bei signaturgestützten IDS erfolgt die Definition des zu erkennenden Angriffs auf der Basis definierter Angriffsmuster. Das IDS alarmiert, sobald ein solches Muster zutrifft. Die meisten verfügbaren IDS gestatten das Anpassen oder Neuerstellen von Signaturen durch eine einfache Skriptsprache.

Vorteil dieser Methode ist die leichte Verständlichkeit des Vorgehens. Nachteilig ist, dass praktisch alle Angriffe (in sämtlichen Modifikationen) aufgezählt werden müssen, damit sie erkannt werden können. Zwar können ähnliche Angriffe durch dieselbe Signatur erkannt werden, wenn die Signatur entsprechend "unscharf" definiert ist. Hierdurch erhöht sich jedoch auch die Fehlalarmrate (false positives) des IDS und mit ihr der personelle Aufwand zur Analyse der IDS-Meldungen.

Zurück zur Angriffserkennung

1.3.2 Anomalieanalyse

Als Anomalieanalyse werden Auswertungsmethoden bezeichnet, bei denen die Abweichung des Systems von seinem Normalverhalten erkannt und gemeldet wird. In den folgenden Abschnitten werden unterschiedliche Verfahren zur Anomalieanalyse kurz erläutert:

  • Protokollanalyse,
  • Anomalieerkennung auf Basis statistischer Daten,
  • Anomalieerkennung auf Basis von Künstlicher Intelligenz,
  • Anomalieerkennung auf Basis von Honeypots.

Protokollanalyse

Bei der Protokollanalyse wird der Netzverkehr auf Anomalien untersucht. Das Normalverhalten ist dabei durch Protokollspezifikationen definiert. Es wird geprüft, ob der Kommunikationsverkehr den zugrunde liegenden Protokollspezifikationen genügt. Da im Bereich von IP-basierten Netzen viele Angriffe darauf beruhen, dass von den spezifizierten Protokollen abgewichen wird, kann hierdurch eine recht zuverlässige Angriffserkennung erfolgen.

Die Methode weist eine hohe Performance auf, da im Gegensatz zur Signaturerkennung keine Vielzahl von Signaturen getestet werden muss. Nachteilig an dieser Methode ist, dass diejenigen Angriffe, die auf Unschärfen oder Fehlern in der Protokollspezifikation beruhen, nicht erkannt werden. IDS, die auf dieser Methode beruhen, beinhalten daher meist zusätzliche signaturbasierte Komponenten, um eine vollständige Angriffserkennung zu gewährleisten.

Anomalieerkennung auf Basis statistischer Daten

Bei der Anomalieerkennung auf Basis statistischer Daten wird davon ausgegangen, dass das Systemverhalten im Angriffsfall signifikant von einem durch statistische Kennwerte festgelegten Normalverhalten abweicht. Um das Normalverhalten eines Systems zu definieren, werden für unterschiedliche Objekte (Nutzer, Dateien, Anwendungen, etc.) und zugehörigen "Verhaltensweisen" (Anzahl von Fehlversuchen bei der Anmeldung, Tageszeiten des Zugriffs, Nutzungshäufigkeit, Zugriffsdauer, etc.) statistische Kennwerte (Mittelwert, Varianz, etc.) ermittelt. Anhand der statistischen Kennwerte ermittelt das IDS, ob das aktuelle Verhalten signifikant vom Normalverhalten abweicht.

Marktverfügbare IDS bieten keine Funktionen zur automatischen Anomalieerkennung auf Basis statistischer Daten. Manuell ist eine entsprechende Anomalieerkennung in begrenzter Weise auf Basis von Reports und Angriffsstatistiken möglich. Das Vorgehen verlangt jedoch viel Intuition und ist fehlerbehaftet, da weder das Normalverhalten noch die zu suchenden Angriffe spezifiziert sind. Beispielsweise ist nicht sichergestellt, dass sich in dem durch statistische Daten beschriebenen Normalverhalten keine Angriffe verbergen, die dann als "normal" betrachtet werden. Diese Methode eignet sich daher ausschließlich zur ergänzenden Analyse.

Anomalieerkennung auf Basis von Künstlicher Intelligenz

Analog zur manuellen Anomalieanalyse auf Basis statistischer Daten werden Verfahren der Künstlichen Intelligenz eingesetzt, um die bei manueller Analyse notwendige Intuition maschinell zu kompensieren. Hierdurch kann eine Steigerung der Verarbeitungsgeschwindigkeit erzielt werden, jedoch ist auch hier aufgrund hoher Fehlerraten eine manuelle Nachbearbeitung notwendig und intendiert. Auch diese Methode eignet sich daher nur zur ergänzenden Analyse. Sie wird derzeit nicht von IDS-Herstellern am Markt angeboten. Es gibt jedoch Individuallösungen im wissenschaftlichen Bereich.

Anomalieerkennung auf Basis von Honeypots

Honeypots sind dedizierte IT-Systeme (Server, Netze, Programme, Prozesse), die keine produktive Funktion erfüllen, sondern ausschließlich "Fallen" für Angreifer darstellen, in dem sie produktive oder auch besonders sicherheitskritische Systeme vortäuschen. Ein Honeypot hat ein sehr einfaches Normalverhalten, das darin besteht, dass es keine oder nur eine geringe Anzahl vordefinierter Zugriffe auf das System gibt. Honeypots eignen sich sehr gut für eine Anomalieanalyse, da im Wesentlichen sämtliche Zugriffe und Aktivitäten – ausgenommen der vordefinierten Zugriffe – als anormal einzustufen und damit beobachtenswert sind. Hierdurch lässt sich eine vollständige Aufzeichnung und Nachuntersuchung von Angriffen, aber auch dem Fehlverhalten anderer IT-Systeme realisieren.

Honeypots eignen sich jedoch grundsätzlich nicht dazu, Angriffe auf IT-Systeme außerhalb des Honeypot (z. B. Produktionssysteme) zu erkennen. Auch lässt sich aus der Analyse des Honeypot-Verhaltens nur sehr beschränkt eine Aussage auf das Verhalten von Produktionssystemen treffen. Zudem ist es möglich, dass Angriffe auf Produktionssysteme nicht zuvor oder wiederholt an parallel betriebenen Honeypots ausgeübt werden. Insbesondere bieten Honeypots daher keinen Schutz gegen Insider.

Aus diesen Gründen werden Honeypots in der Praxis nur zusätzlich zu anderen Intrusion-Detection-Maßnahmen eingesetzt. Es ist darüber hinaus bei der Installation, Wartung und Auswertung von einem hohen personellen Aufwand auszugehen. Daher gibt es für Honeypots derzeit nur wenige Anwendungsbereiche:

  • Honeynet-Projekt zur wissenschaftlichen Untersuchung und Auswertung von Angriffen.
  • Hersteller von Viren- und Trojanererkennungssoftware, die hierdurch versuchen, unmittelbar Zugriff auf Angriffsdaten zu erhalten.
  • Bei Internet-Providern werden Pakete, die nicht ordnungsgemäß geroutet werden können, an ein spezielles System weitergeleitet, anstelle sie zu verwerfen. Anhand dieser Pakete können Scan-Versuche oder das in einigen Angriffstools vorkommende zufällige Spoofing von IP-Adressen erkannt werden.

Zurück zur Angriffserkennung

1.3.3 Korrelation von Ereignisdaten

Die Auswertungslogik kann basieren auf Ereignissen und Daten von

  • einem Sensor,
  • mehreren Sensoren gleicher Art oder
  • mehreren Sensoren unterschiedlicher Arten.

Die Berücksichtigung mehrerer, nicht zeitgleicher Ereignisse oder Ereignisse unterschiedlicher Sensoren durch die Auswertungslogik wird als Korrelation bezeichnet. Die Korrelation kann mit der Signaturanalyse und Anomalieanalyse kombiniert sein.

Die Korrelation von sensorübergreifenden oder langfristigen Ereignissen erfolgt in der Regel intuitiv, kann jedoch durch IDS unterstützt werden, z. B. in Form von regelmäßigen Reports.

Nicht alle am Markt erhältlichen IDS-Produkte weisen automatische Korrelationsmöglichkeiten auf. Dagegen wird eine manuelle Korrelation typischerweise durch die Möglichkeit unterstützt, auf Basis der in der Ereignisdatenbank gespeicherten Daten nach verschiedenen Kriterien zu filtern (Report-Funktionen).

Voraussetzung ist hierfür eine möglichst umfangreiche Speicherung der Ereignisdaten und Kontextinformation, da zunächst belanglos erscheinende Daten bei einer Langfrist-Analyse nachträglich an Bedeutung gewinnen können (z. B. Portscans mit einem Port pro Tag oder netzübergreifendes Scanning desselben Ports).

Die Anforderung nach umfangreicher Aufzeichnung verdächtiger Ereignisse konkurriert mit Anforderungen an den Datenschutz. Deshalb ist zu klären, welche Daten für welchen Zeitraum gespeichert werden dürfen. Ereignisdaten können im Allgemeinen auch pseudonymisiert zur Erkennung von Angriffen beitragen. Eine Pseudonymisierung der Ereignisdaten bei der Speicherung wird jedoch von marktverfügbaren IDS-Produkten in der Regel nicht unterstützt.

Die Korrelation wird in der Praxis derzeit hauptsächlich dadurch erschwert, dass einerseits ungeeignete Datenbanksysteme zur Speicherung der Ereignisdaten eingesetzt werden und andererseits aufgrund fehlender Standardisierung eine Korrelation über Sensoren verschiedener Hersteller hinweg nicht von den IDS unterstützt wird. Manuelle Korrelationen sind zwar möglich, jedoch sehr zeitaufwändig und damit kostenintensiv.

Zurück zur Angriffserkennung

1.4 Intrusion-Response-Funktionen

Als Reaktion auf erkannte Ereignisse können verschiedene Aktionen ausgelöst werden, von der Dokumentation des Ereignisses, über die Alarmierung bis zur automatischen Aktivierung von Gegenmaßnahmen. Die von einem IDS automatisch eingeleiteten Maßnahmen werden als Intrusion-Response bezeichnet.(Im Gegensatz zum Incident-Response, das die technisch-organisatorischen zum Umgang mit den erkannten Ereignissen umfasst, wie z. B. Eskalationsprozesse)

Die verschiedenen Intrusion-Response Funktionen werden in den nachfolgenden Abschnitten erläutert.

Welche Funktionen im Einzelnen ausgelöst werden können, ist von Produkt zu Produkt unterschiedlich. Um eine flexible Gestaltung des Intrusion-Response zu ermöglichen, bieten einige IDS die Möglichkeit, als Reaktion auf Angriffe vom Anwender vorgegebene Kommandos bzw. Skripte ausführen zu lassen. Um diese Funktion praktisch sinnvoll einzusetzen, ist es jedoch erforderlich, dass eine Parameterübergabe vom IDS an das Kommando bzw. Script bei dessen Aufruf möglich ist.

Dokumentation

Eine angemessene Dokumentation von Ereignissen ist die Voraussetzung zur Auswertung der Ereignisse. Typischerweise wird das Ereignis zusammen mit relevanten Parametern (Zeitpunkt des Auftretens, betroffenes System, Art des Angriffs, etc.) vom IDS protokolliert.

Daneben erlauben einige Produkte für netzbasierte Ereignisse auch eine Aufzeichnung der Rohdaten (IP-Pakete) des Angriffs. Hierdurch können Angriffe nachträglich analysiert und Dritten gegenüber dargestellt werden (Leitungsebene, Strafverfolgungsbehörden).

Alarmierung

Funktionen zur Alarmierung bilden die Grundlage zur Integration des IDS in Eskalationsprozesse. Entsprechend dem Stand der Kommunikationstechnik bieten die meisten IDS Funktionen zur Alarmierung per E-Mail, Signalisierung (z. B. SNMP-Traps) oder Funk (z. B. Pager, SMS).

In der Regel verfügen IDS über mehrere Alarmklassen, in die erkannte Ereignisse automatisch einsortiert werden. Hierdurch wird die Einbettung der IDS-Alarme in organisatorische Eskalationsprozeduren unterstützt.

Automatische Einleitung von Gegenmaßnahmen

Zusätzlich zur Alarmierung können durch das IDS aktive Reaktionen vorgenommen werden, wie z. B. eine automatische Beeinflussung von Netzkomponenten oder Rechensystemen. Dies erlaubt eine unverzügliche, zeitnahe Reaktion auf erkannte Angriffe. Beispiele hierfür sind

  • eine temporäre Regeländerung der Firewall, um bestimmte Zugangsmöglichkeiten für Angreifer zeitweise zu sperren und Zeit für Sicherungsmaßnahmen zu gewinnen,
  • das Beenden von Kommunikationsverbindungen durch aktives Einbringen von Reset-Paketen in das Netz oder
  • die Sperrung von Zugriffsrechten auf einem Rechner, wenn ein Angriffs- oder Missbrauchsversuch erkannt wird.

Die automatische Einleitung von Gegenmaßnahmen auf Grundlage vom IDS erkannte Ereignisse, ist jedoch aus mehreren Gründen mit Vorsicht zu betrachten.

  1. Die Angriffserkennung durch ein IDS ist unscharf. Es treten regelmäßig Fehlalarme auf. Als Reaktion auf Fehlalarme kann das Unterbinden von Kommunikationsbeziehungen oder Zugangs-/Zugriffsmöglichkeiten dazu führen, dass die Verfügbarkeit von Systemen und Applikationen ungewollt beeinträchtigt wird.
  2. Zur Durchführung von Angriffen werden häufig Absenderkennungen gefälscht. Automatische Reaktionen können dann dazu führen, dass Dienste oder Applikationen für legitime Nutzer nicht mehr erreichbar sind.

Deshalb sind bei der Festlegung automatischer aktiver Reaktionen die Nutzenaspekte gegenüber den Auswirkungen der Reaktion des IDS im Falle von Fehlalarmen abzuwägen.

1.5 Sicherheitsaspekte beim Einsatz von IDS

Beim Betrieb eines IDS ist es von elementarer Bedeutung, dass die Funktionalität des IDS selbst nicht in einfacher Weise durch Angriffe außer Kraft gesetzt oder manipuliert werden kann. In den nachfolgenden Abschnitten werden die Anforderungen näher beschrieben, die in diesem Zusammenhang als relevant angesehen werden.

1.5.1 Verfügbarkeit und Stabilität

Nachstehend werden Verfügbarkeits- und Stabilitätsaspekte für netzbasierte Sensoren, hostbasierte Sensoren, Management- und Auswertungsstation sowie die Datenbank kurz diskutiert.

Netzbasierte Sensoren

Die Verfügbarkeit netzbasierter Sensoren kann durch hohe Netz- und Angriffslast, aber auch durch gezielte Angriffe sowie Programm- und Administrationsfehler eingeschränkt werden.

+ Diesem wird in neueren Produkten dadurch begegnet, dass herstellerseitig Netzsensoren als Appliance angeboten werden, um eine ausreichende Hardwareausstattung sowie geeignete Softwarekonfiguration sicherzustellen.
+ Durch eine Selbstüberwachung des Sensors können Störungen erkannt werden.
+ Wenn Sensoren außer Betrieb gesetzt werden, so berührt dies in der Regel nicht die zu überwachenden Systeme.
+ Durch regelmäßige Statusabfragen (Heartbeats) zwischen Managementstation und Sensoren können Störungen und Ausfälle von Sensoren erkannt werden.
+ Eine redundante Auslegung des Netzsensors ist prinzipiell möglich. Sie wird in der Praxis jedoch kaum durchgeführt, da typischerweise keine Hochverfügbarkeitsanforderungen an Netzsensoren gestellt werden.

Hostbasierte Sensoren

Die Verfügbarkeit hostbasierter Sensoren kann sowohl durch direkte, auf den Sensor gezielte Angriffe als auch indirekt, durch erfolgreiche Angriffe auf das zu überwachende System beeinträchtigt werden. Auch Störungen und Fehlverhalten des zu überwachenden IT-Systems wirken unmittelbar auf den hostbasierten IDS-Sensor.

+ Durch eine Selbstüberwachung des Sensors können Störungen erkannt werden.
+ Durch regelmäßige Statusabfragen (Heartbeats) zwischen Managementstation und Sensoren können Störungen der Sensoren erkannt werden.

Umgekehrt können sich auch Störungen des Sensors auf das zu überwachende IT-System auswirken.

- Fehlverhalten oder Abstürze des Sensors können ein Fehlverhalten oder Absturz des zu überwachenden Produktionssystems nach sich ziehen.
- Der Neustart eines Sensors verlangt in der Regel administrativen Zugriff auf das zu überwachende System. Der IDS-Administrator muss demnach Root/Administratorberechtigung zum betreffenden Produktionssystem besitzen.

Im Gegensatz zu netzbasierten Sensoren kann eine redundante Auslegung hostbasierter Sensoren in der Regel nicht erfolgen.

Management- und Auswertungsstationen

Ein Ausfall der Managementstation (Konfiguration oder Auswertung) berührt in der Regel nicht die Funktion der IDS-Sensoren. Dagegen ist eine hohe Verfügbarkeit der Auswertungsumgebung wichtig, denn ein Teil der zu erkennenden Angriffe findet im Sekundenbereich (oder schneller) statt und Folgeschäden können sich schnell ausbreiten. Deshalb ist eine zeitnahe Ereigniserkennung und Reaktion notwendig.

+ IDS unterstützen in der Regel eine redundante Konfiguration der Managementstationen in Form einer Cold-Standby-Konfiguration. Dabei müssen nach Ausfall einer Managementstation die Konfigurationsdaten und verwendete Kryptoschlüssel zum Ersatzsystem übertragen werden.
+ Alternativ dazu können in einigen IDS die Managementstationen kaskadiert werden, so dass bei Ausfall einer Station die Konfiguration und Auswertung eines IDS weiterhin möglich ist.

Datenbank

Einige IDS sind so ausgelegt, dass sie bei Ausfall der Ereignisdatenbank die abzulegenden Ereignisse zwischenspeichern. Dies ist jedoch nicht in allen verfügbaren IDS realisiert.

Weitergehende Mechanismen zur Sicherstellung der Verfügbarkeit werden in der Regel durch das IDS nicht realisiert, sondern müssen durch das Datenbanksystem selbst erbracht werden.

Zurück zu den Sicherheitsaspekten

1.5.2 Integrität

Netzbasierte Sensoren

- Bei hoher Netz- und Angriffslast kann ein Sensor überlastet werden, so dass nicht mehr alle IP-Pakete untersucht werden können und Angriffe möglicherweise übersehen werden.
+ Einer Überlastung kann vorgebeugt werden, indem dem Sensor ausreichend dimensionierte Hardware (ggf. als Appliance) zugrundegelegt wird.
+ Durch eine Selbstüberwachung des Sensors kann eine Überlastung oder sonstige Störung erkannt werden.
+ Durch regelmäßige Statusabfragen (Heartbeats) zwischen Managementstation und Sensoren können Störungen erkannt werden.
+ Durch Einsatz spezieller Netzadapter (TAPs) kann sichergestellt werden, dass sich ein eventuelles Fehlverhalten des netzbasierten Sensors nicht auf Systeme im Produktionsnetz auswirken kann, da jeglicher Datenverkehr vom Sensor in Richtung Produktionsnetz physikalisch blockiert wird.

Hostbasierte Sensoren

Auch hostbasierte Sensoren, die Netzverkehr überwachen, können überlastet werden und Angriffe übersehen. Zusätzlich ist beim Einsatz hostbasierter Sensoren zu bedenken, dass sich ein eventuelles Fehlverhalten des Sensors unmittelbar auf das zu überwachende Produktionssystem auswirken kann, da der Sensor typischerweise administrative Systemrechte wahrnimmt. Gezielte Angriffe auf die Integrität des IDS-Sensors (z. B. Buffer Overflows) können daher auch das Produktionssystem schädigen.

- Ein Fehlverhalten des Sensors kann ein Fehlverhalten oder den Absturz des zu überwachenden Produktionssystems nach sich ziehen.
- Die Konfiguration und der Neustart eines hostbasierten Sensors verlangen in der Regel administrativen Zugriff auf das zu überwachende System. Der IDS-Administrator muss demnach Root/Administratorberechtigung zum betreffenden Produktionssystem besitzen.
- Ein Schutz des Produktionssystems durch Trennung von Sensor und überwachtem System ist – im Gegensatz zu netzbasierten Sensoren – nicht möglich.

Die Integrität hostbasierter Sensoren kann darüber hinaus durch indirekte Angriffe auf das zu überwachende System selbst beeinträchtigt werden, denn auch Störungen und Fehlverhalten des zu überwachenden IT-Systems wirken unmittelbar auf den hostbasierten IDS-Sensor.

+ Der Sensor sollte derartiges Fehlverhalten jedoch erkennen und an das IDS melden.
+ Durch eine Selbstüberwachung des Sensors können Störungen des Sensors erkannt werden.
+ Durch regelmäßige Statusabfragen (Heartbeats) zwischen Managementstation und Sensoren können Störungen erkannt werden.

Datenbank

Die Sicherstellung der Datenbankintegrität muss in der Regel durch diese selbst erbracht werden und erfolgt nicht durch das IDS.

Zurück zu den Sicherheitsaspekten

1.5.3 Vertraulichkeit

Einsatz von Verschlüsselung

Die Kommunikation zwischen den einzelnen IDS-Komponenten erfolgt meist unverschlüsselt, teils nur in eine Richtung verschlüsselt. Bei einigen IDS kann die Verschlüsselung für einige der Kommunikationswege nachgerüstet werden, z. B. durch Einsatz von SSL bei webserver-basierten Managementstationen oder durch Einsatz von SSH/SCP bei der Kommunikation zwischen IDS-Management und Sensoren.

Einsatz separater IDS-Teilnetze

Einige IDS gestatten die Definition eigener physikalischer IDS-Teilnetze für die Kommunikation der IDS-Komponenten untereinander. Hierdurch kann erreicht werden, dass das IDS von Produktionsnetzen aus unsichtbar ist, d. h. ein Angreifer kann nicht durch Installation eines Sniffers die IDS-Kommunikation belauschen. Auch kann ein Angreifer Komponenten des IDS nicht interaktiv erreichen, wenn die Trennung der Netze über TAPs oder Netzwerkinterfaces erfolgt, die in einem sog. Stealth-Mode konfiguriert sind.

Eine hohe Schutzwirkung eines separaten IDS-Netzes ist jedoch nur dann gegeben, falls auch alle weiteren Netzübergänge zu Produktionsnetzen angemessen geschützt sind (vgl. Kapitel 4.3). Dies betrifft insbesondere

  • eine mögliche Netzkopplung über das überwachte System beim Einsatz von Hostsensoren,
  • Alarmierung per E-Mail oder SNMP zu Systemen im Produktionsnetz und
  • Zugriffe auf Webseiten im Internet von der Management- und Auswertungsstation aus (Informationsgewinnung, ggf. Signatur-Updates, etc.)

Zurück zu den Sicherheitsaspekten

1.5.4 Nachvollziehbarkeit des Zugriffs auf IDS-Komponenten

IDS-Systeme sehen typischerweise weder eine Benutzer- und Rechteverwaltung noch eine Rollentrennung vor. In der Regel müssen alle IDS-Benutzer dieselbe administrative Kennung verwenden (Passwort-Sharing). Hierdurch können administrative Zugriffe nachträglich nicht mehr konkreten Personen zugeordnet werden.

Beim Einsatz webbasierter Managementkonsolen kann der Zugriff zu diesen Konsolen durch den Webserver auf Berechtigte eingeschränkt werden. Die Zugriffskontrolle kann durch Einsatz von SSL um eine Authentisierung basierend auf X.509-Zertifikaten ergänzt werden. Eine applikationsseitige Beschränkung von Rechten erfolgt jedoch auch hierdurch nicht.

Zurück zu den Sicherheitsaspekten

1.5.5 Schutzmaßnahmen an Netzübergängen

Wenn IDS-Komponenten über Netzgrenzen hinweg miteinander verbunden werden, so müssen an dieser Stelle die für die Netzgrenze gültigen Schutzmaßnahmen (z. B. Paketfilterung) auch für die IDS-Kommunikation angewendet werden.

Darüber hinaus ist bei webserver-basierten IDS-Konsolen ein regelmäßiges Update des zugrundeliegenden Webservers erforderlich, um Angriffe gegen das IDS auf Ebene des Webservers auszuschließen.

Weitere Sicherheitsaspekte beim Einsatz von IDS an Netzübergängen werden in den Kapiteln 2.5, 2.6 und 4 angesprochen.

Zurück zu den Sicherheitsaspekten

1.5.6 Einsatz von JavaScript bei webserver-basierten Konsolen

In einigen IDS werden ausschließlich Webseiten mit statische Daten eingesetzt. Dies hat den Nachteil, dass neue Ereignisse erst nach clientseitigem Refresh der Webseiten, d. h. nach Betätigen des Refresh-Buttons sichtbar werden. Es gibt grundsätzlich die Möglichkeit, auch für statische Webseiten einen regelmäßigen Refresh zu automatisieren. Diese Funktion wird jedoch in marktverfügbaren IDS-Produkten in der Regel nicht eingesetzt.

Alternativ hierzu verwenden andere IDS JavaScript-basierte Webseiten. Dies führt wiederum zu erhöhten Risiken, da webserver-basierte Konsolen in der Regel auch einen Internetzugriff aufweisen, etwa um Informationen zu Angriffen abzurufen. In diesem Fall sollten Webbrowser eingesetzt werden, die ein selektives An- und Ausschalten von JavaScript für unterschiedliche Webseiten gestatten. Wenn organisationsinterne Regelungen den Einsatz von JavaScript in Webclients verbieten, hat das Auswirkungen auf die Auswahl des IDS.

Zurück zu den Sicherheitsaspekten

1.5.7 Sicheres Signatur-Update

Die Qualität der Angriffserkennung wird wesentlich durch die Signaturen des IDS bestimmt. Die Funktion des IDS kann gestört werden, falls bei der Aktualisierung gefälschte oder manipulierte Signaturen in das IDS geladen werden. Deshalb sollten IDS über Funktionen zur Sicherstellung der Authentizität und Integrität von Signatur-Updates verfügen. Dies ist für einen großen Teil der marktverfügbaren IDS der Fall.

Zurück zu den Sicherheitsaspekten

1.6 Nutzungsfreundlichkeit

Hinsichtlich der Nutzungsfreundlichkeit bestehen große Unterschiede zwischen den am Markt erhältlichen IDS. Die von den Herstellern anvisierte Zielgruppe hat dabei einen wesentlichen Einfluss auf die Gestaltung des IDS.

Die Nutzungsfreundlichkeit eines IDS wird aus technischer Sicht maßgeblich geprägt durch:

1.6.1 Konfiguration, Stabilität und Bedienungsfreundlichkeit

Für die Konfiguration der IDS-Komponenten werden Benutzungsschnittstellen angeboten, die sich in folgende Kategorien einteilen lassen:

  • Kommandozeilen-Interface
    Kommandozeilen basierte IDS richten sich an technisch versierte IDS-Administratoren und Analysten. Das IDS wird durch Editieren von Konfigurationsdateien oder die Angabe von Parametern beim Start des IDS konfiguriert. Neben dem Opensource-IDS "Snort" sind auch einige UNIX-basierte IDS auf diese Weise konfigurierbar. Hierzu ist typischerweise ein Shellzugriff (z. B. per SSH) auf die betreffenden IDS-Komponenten erforderlich. IDS, die kommandozeilenorientiert arbeiten, weisen erfahrungsgemäß eine vergleichsweise hohe Stabilität auf.
  • Webbasierte Schnittstelle
    Die Konfigurationsoptionen werden in einem Webbrowserfenster dargestellt. Der Webbrowser greift dabei auf einen für das IDS konfigurierten Webserver zu, der in der Regel auf der Managementstation installiert ist. Hierzu wird auf Drittprodukte zurückgegriffen(z. B. Apache-Webserver bei UNIX-basierten IDS sowie Microsoft IIS bei Windows-basierten IDS). Schutzmaßnahmen wie Zugriffskontrolle und Verschlüsselung werden typischerweise auf Ebene des Webservers realisiert. Nachteilig ist, dass regelmäßig ein manuelles Refresh der Webseiten am Browser erfolgen muss, da neue Ereignisse erst nach einem Update der Seiten dargestellt werden. Dies wird von einigen Herstellern durch Einsatz von JavaScript oder ActiveX umgangen. Browserseitig muss dann in der Regel jedoch die Verarbeitung entsprechender aktiver Inhalte aktiviert sein. Die Stabilität webserver-basierter Bedienoberflächen ist in hohem Maße von der Stabilität des zugrundeliegenden Webservers abhängig und nach Erfahrungswerten als sehr hoch einzustufen.
  • IDS-proprietäre Bedienoberfläche
    Die Konfigurationsoptionen und die gemeldeten Ereignisse werden in einer proprietären Oberfläche dargestellt, die in der Regel auf der Managementstation installiert ist. Die Bedienoberflächen weisen gegenüber den anderen o. g. Bedienschnittstellen eine wesentlich höhere Komplexität auf. Der Benutzungskomfort ist bei diesen IDS erfahrungsgemäß hoch. Allerdings sind diese IDS anfälliger gegen Programmierfehler und weisen eine geringere Stabilität als IDS mit Webserver-basierten oder Kommandozeilen-basierten Bedienoberflächen auf. Nachteilig ist zudem, dass ein Remote-Zugriff auf die Managementstation den Einsatz von Zusatzprodukten (z. B. pcANYWHERE oder VNC) erfordert.

Zurück zur Nutzungsfreundlichkeit

1.6.2 Übersichtlichkeit und Aussagekraft der IDS-Meldungen

Die Aussagekraft der IDS-Meldungen soll ausreichen, um das gemeldete Ereignis einordnen und bewerten zu können. Hierzu ist ggf. ein Rückgriff auf der Meldung zugrunde liegenden Daten (etwa aufgezeichneten Netzverkehr oder Logdateien) notwendig, die durch das IDS referenziert bzw. bereitgestellt werden sollten.

Umfang und notwendige Detailtiefe der Meldungen hängen dabei wesentlich vom Einsatzszenario des IDS sowie von der Art der zu erkennenden Ereignisse ab. Hierzu folgende Beispiele:

  • Die Analyse eines IP-Paketes, mit dem Shell-Verbindungen über ICMP getunnelt werden (z. B. LOKI-Angriff), verlangt die Aufzeichnung der in Frage kommenden – auch unverdächtigen – ICMP-Pakete im fraglichen Zeitraum.
  • Bei Portscans dagegen werden typischerweise nicht alle in Frage kommenden IP-Pakete, sondern nur kumulierte Daten aufgezeichnet, etwa Quell- und Zieladressen, gescannte Portnummern, Anzahl gescannter Ports.

Bei einigen IDS sind Ereignismeldungen sehr oberflächlich und in ihrer Aussagekraft begrenzt. Die Analyse des zugrunde liegenden Vorfalls und eine Nachverfolgung des Angriffs ist dadurch erschwert oder im Extremfall nicht möglich.

In den gängigen IDS typischerweise zufriedenstellend gelöst ist oder in ausreichendem Maße anpassbar, sind Funktionen zur Vorsortierung der Ereignisse und zur Zuordnung von Intrusion-Response-Funktionen.

Zurück zur Nutzungsfreundlichkeit

1.6.3 Reportgenerierung

Die Generierung von Reports dient typischerweise zweierlei Zielen:

  • Aufdecken neuer, noch nicht erkannter Ereignisse und Trends durch Filterung und grafische Aufbereitung langfristig gespeicherter Daten.
  • Generierung von Statistiken und Grafiken für Management-Reports.

Aus technischer Sicht steht die Erkennung von neuen Ereignissen im Vordergrund, wobei diese in der Regel nur manuell erfolgt – unterstützt durch umfangreiche Such- und Filterfunktionen zu den in der Ereignisdatenbank gespeicherten Datensätzen. Die Erfahrung zeigt jedoch, dass – u. a. auch zur Rechtfertigung der hohen Kosten für Schutzmaßnahmen – die Generierung von Management-Reports und zugehörigen Grafiken ebenso große Bedeutung hat. Einige IDS-Hersteller bieten explizite Schnittstellen zu Management-Reporting-Systemen an.

Zurück zur Nutzungsfreundlichkeit

1.6.4 Einbindung externer Informationsquellen

Zur Analyse von IDS-Meldungen ist es sinnvoll, extern erreichbare Quellen zu konsultieren, um Hintergrundinformationen zu Angriffen zu erhalten oder eigene Beobachtungen dorthin zu melden. Aktuelle IDS unterstützen typischerweise einen Webzugriff via Shortlink zu bekannten Informationsquellen.

Zurück zur Nutzungsfreundlichkeit

1.6.5 Anpassung und Konfiguration von Signaturen

Das IDS sollte die Generierung neuer und die Anpassung bestehender IDS-Signaturen unterstützen, um eine möglichst genaue Kalibrierung des IDS zu erreichen. Sowohl bei der Kalibrierung des IDS als auch der Auswertung gemeldeter Ereignisse ist es notwendig, Details der betreffenden Signatur zu sehen, um festzustellen, warum ein Ereignis gemeldet wurde (Minimierung von Fehlalarmen). Einige am Markt erhältliche IDS unterstützen dies nur sehr eingeschränkt, so dass weder die Signatur angezeigt werden kann noch eine detaillierte technische Beschreibung verfügbar ist. Ein IDS-Administrator hat in diesem Fall bei häufigen Fehlalarmen nur die Möglichkeit, die Signatur abzuschalten, kann diese jedoch nicht an die Bedürfnisse anpassen.

Zurück zur Nutzungsfreundlichkeit

1.6.6 Backup von Signaturen

Die Konfiguration des IDS (Signaturen, Kalibrierung, etc.) ändert sich häufig und sollte nach jeder Änderung gesichert werden. Für die Datensicherung des aktuellen IDS-Stands ist dabei die Sicherung der Konfigurationseinstellungen (Signaturen, Kalibrierung, etc.) ausreichend. Das IDS sollte hierzu über entsprechende Funktionen verfügen.

Zurück zur Nutzungsfreundlichkeit

1.6.7 Automatisches Signatur-Update

Wie auch bei Virenscannern hängt die Qualität der Ereigniserkennung eines IDS stark von der Aktualität der Signaturen ab. Neu Signaturen sind regelmäßig einzuspielen. Dieser Vorgang kann ggf. automatisiert werden. Manuell festzulegen ist jedoch in jedem Fall, wie das IDS auf die Ereignisse reagieren soll, die durch die neuen Signaturen erkannt werden.

Zurück zur Nutzungsfreundlichkeit

1.7 IDS-Markt, Kosten und Investitionsschutz

Auf dem Markt fand in den letzten zwei Jahren bereits eine Konsolidierung statt. Für einige IDS Produkte wurde die Herstellerunterstützung eingestellt (z. B. Cybercop von NAI), andere wurden nicht weiterentwickelt. Einige kleinere IDS-Anbieter wurden von größeren Firmen übernommen (etwa NetworkICE von ISS, Network Security Wizards von Enterasys, Axent von Symantec).

Im Open-Source-Bereich hat Snort zunehmend an Bedeutung gewonnen. Snort wird inzwischen auch kommerziell unterstützt. Dies betrifft sowohl die Wartung von Snort als auch die kommerzielle Produktversion OpenSnort.

Die Konsolidierung geht jedoch nicht mit einer Preissenkung der Produkte einher. Dies liegt darin begründet, dass eine fortlaufende Weiterentwicklung der Produkte erfolgte. Dies betrifft einerseits die deutliche Verbesserung der Angriffserkennung netzbasierter Sensoren in den letzten Jahren sowie andererseits die Skalierbarkeit der Systeme (Management, Verwaltung mehrerer, ggf. unterschiedlicher Sensoren, etc.).

Bei den Kosten sind Anschaffungs-, Wartungs- und Betriebskosten von IDS gleichermaßen wichtig. Daneben sind die Kosten für einen Hotline-Support durch den Hersteller zu berücksichtigen. Im Rahmen der Vorauswahl können nur die Anschaffungs- und Wartungskosten berücksichtigt werden. Der genaue Betriebsaufwand hängt von der Nutzungsfreundlichkeit des IDS ab (vgl. Kapitel 2.6) und stellt sich daher erst im Test- bzw. Pilotbetrieb heraus.

Beim Einsatz von Open-Source-Produkten entfallen typischerweise die Anschaffungskosten. Im Gegenzug ist jedoch mit höherem Personalaufwand bei Anpassung und/oder Betrieb des IDS zu rechnen.

Für den Investitionsschutz ist zu berücksichtigen, dass ein IDS – wie Virenschutzsysteme – einer regelmäßigen Aktualisierung bedarf. Der praktische Nutzen eines IDS-Produkts verringert sich daher schnell, falls für das IDS keine neuen Signaturen mehr bereitgestellt werden.

1.8 Standardisierung und Interoperabilität

Im Bereich Intrusion-Detection gab es zahlreiche Ansätze zur Standardisierung, die den IDS-Bereich unterschiedlich weit abdeckten. Einige dieser Ansätze sind im Folgenden aufgeführt.

  • Common Intrusion Detection Framework (CIDF) Projekt
    Das CIDF ist ein von der US-amerikanischen DARPA unterstütztes Projekt zur Definition von ID-Komponenten (Ereigniserkennung, Ereignisauswertung, Datenspeicherung und Reaktion) und Protokollen zur Kommunikation dieser Komponenten. Für den einheitlichen Umgang mit Ereignisdaten wurde die "Common Intrusion Specification Language" (CISL) entwickelt.
  • Intrusion Detection Working Group (IDWG) der IETF
    Die IDWG entwickelte das "Intrusion Detection Exchange Format" (IDEF), das ein Format zur Beschreibung von Angriffen definiert. Das IDEF wurde am 15.6.2000 als Internet-Draft veröffentlicht. Eine Umsetzung in einen RFC erfolgte bislang nicht.
  • Common Content Inspection (CCI) API und OPSEC von Check Point
    Das CCI API definiert eine Schnittstelle, über die von einer Firewall oder einem ID-Sensor gesichtete, "verdächtige" Daten, die einer weiteren Untersuchung bedürfen, an eine Auswertungsstation weitergeleitet werden können. OPSEC (www.opsec.com), eine Initiative der Firma Check Point, stellt eine Reihe von APIs und Protokollen bereit, die einen Austausch auch für IDS relevanter Daten zwischen Systemen ermöglichen. Beispiele sind das "Log Export API" (LEA), das "Suspicious Activity Monitoring Protocol" (SAMP) und das "Content Vectoring Protocol" (CVP). Es hat sich eine Allianz von Herstellern gebildet, die in ihren Produkten Protokolle und APIs der OPSEC-Initiative berücksichtigen.
  • Common Vulnerabilities and Exposures (CVE)
    Ziel des CVE (cve.mitre.org) ist die einheitliche Benennung und Nummerierung aller bekannten Angriffe und Schwachpunkte. CVE ist eine Initiative der Mitre Cooperation, einem US-amerikanischem Non-Profit Unternehmen, dass IT-Aufgaben von allgemeinem Interesse nachgeht. Das CVE-Register weist inzwischen über 2000 Einträge auf.
  • ISO Technical Report
    ISO/IEC bereiten einen "Technical Report" zum Thema Intrusion-Detection vor, dessen voraussichtlicher Inhalt in [N3177] wiedergegeben ist. Der Report enthält einen Überblick über das Thema IDS.

Während CIDF ein übergreifendes Framework darstellt, beschränkt sich das IDEF auf die einheitliche Beschreibung und Charakterisierung von Angriffen und CVE lediglich auf deren einheitliche Benennung.

CIDF und IDEF wurden bislang nicht in Produkte umgesetzt, die am Markt angeboten und von Herstellern unterstützt werden. Die CVE-Nummerierung wird inzwischen in den meisten IDS-Produkten berücksichtigt.

Hinsichtlich der Interoperabilität ergibt sich die Situation, dass

  • von unterschiedlichen IDS gemeldete Ereignisse auf Basis ihrer CVE-Nummern verglichen werden können. Grundsätzlich ist hierdurch die Basis zur nachträglichen, IDS-übergreifenden Analyse der Verteilung von Angriffen gegeben.
  • ein Austausch von Komponenten zwischen unterschiedlichen IDS bislang nicht möglich ist. Dies betrifft sowohl Sensoren als auch Signaturbeschreibungen.

Einige Hersteller planen derzeit Definition und Einsatz von "Snort-like Signatures" in ihre IDS zu integrieren. Falls dabei der Syntax der Snort-Signaturen ohne Änderungen und Ergänzungen übernommen wird, könnte hierdurch zumindest für diese Teilmenge von Signaturen eine gewisse Austauschbarkeit erreicht werden. In der Vereinheitlichung von Signaturbeschreibungen besteht grundsätzlich ein hohes Rationalisierungspotenzial, da Signatur-Updates nicht länger herstellerspezifisch ausgearbeitet werden müssten, sondern vereinheitlicht und herstellerübergreifend angeboten werden könnten.

Weitere Informationen

Zurück zu Bundesamt für Sicherheit in der Informationstechnik

Kurz-URL:
https://www.bsi.bund.de/dok/6624202