Abstimmung und Bereitstellung

Ein Sensor sieht nur den Datenverkehr, der ihn erreicht. Wo Sie IDS-/IPS-Sensoren platzieren, bestimmt, was Sie erkennen können. Daher ist die Sensorplatzierung die erste Bereitstellungsentscheidung.

Planen Sie die Platzierung rund um die Engpässe und Vertrauensgrenzen Ihres Netzwerks: am Internet-Perimeter, zwischen Sicherheitszonen, vor besonders schützenswerten Assets und an Egress-Punkten, an denen Exfiltration das Netzwerk verlässt.

Zwei Datenverkehrsachsen müssen überwacht werden:

• North-South — Datenverkehr, der den Perimeter überquert (in das Internet hinein oder aus ihm heraus). Klassische Perimetersensoren decken diesen Bereich ab.
• East-West — Datenverkehr zwischen internen Hosts. Hier findet laterale Bewegung statt, und dieser Datenverkehr wird häufig nicht überwacht.

Angreifer, die ins Netzwerkinnere gelangen, bewegen sich in East-West-Richtung. Eine ausschließlich am Perimeter eingesetzte Lösung erkennt sie nicht. Daher sind interne Taps und Segment-Sensoren für moderne Erkennung unverzichtbar.

Die Wahl der Methode zur Verkehrserfassung beeinflusst die Genauigkeit:

• SPAN-/Mirror-Ports sind kostenlos, beanspruchen jedoch gemeinsam Switch-Ressourcen und verwerfen unter Last Pakete – genau dann, wenn Sie sie am dringendsten benötigen.
• Hardware-TAPs kopieren den Datenverkehr verlustfrei und überstehen den Ausfall eines Geräts, kosten jedoch Geld und Ports.

Bei Verbindungen mit hohem Durchsatz oder kritischen Compliance-Anforderungen sollten Sie TAPs bevorzugen. Aggregation-TAPs und Network Packet Broker können mehrere Tools von einem Erfassungspunkt aus versorgen.

Ein überlasteter Sensor verwirft unbemerkt Pakete und erzeugt dadurch Erkennungslücken, die wie sauberer Datenverkehr aussehen. Dimensionieren Sie Sensoren passend zur Verbindung.

Überwachen Sie die Engine-Statistiken auf capture.kernel_drops und Paketverluste. Steigen die Verluste, benötigen Sie mehr CPU, RAFL-/AF_PACKET-Tuning, Anpassungen am NIC-Offload oder einen schnelleren Sensor. Validieren Sie, dass der Sensor den maximalen und nicht nur den durchschnittlichen Durchsatz bewältigt.

Alle verfügbaren Regeln auszuführen, führt unweigerlich zu Rauschen und Performance-Verlusten. Stellen Sie den Regelsatz gezielt zusammen.

• Aktivieren Sie Regelkategorien, die für Ihre Umgebung und Ihre Assets relevant sind
• Deaktivieren Sie Regeln für Software, die Sie nicht einsetzen
• Verwenden Sie einen Manager wie suricata-update, um Regelquellen abzurufen, zusammenzuführen und zu versionieren
• Verfolgen Sie die Regelquellen (ET Open, ET Pro, benutzerdefiniert) und aktualisieren Sie sie planmäßig

Bearbeiten Sie nicht die Regeln aus den ursprünglichen Quellen, sondern kontrollieren Sie das Rauschen mit einer Threshold-/Suppression-Konfiguration. Unterdrücken Sie eine rauschende sid für eine bekannte gute Quelle; begrenzen Sie bei anderen die Alarmrate mit einem Threshold.

So bleiben Regeln von Drittanbietern aktualisierbar, während die für Ihr Netzwerk spezifischen Fehlalarme weiterhin unterdrückt werden.

Stellen Sie eine neue oder unbekannte Regel niemals direkt auf drop. Führen Sie sie zunächst im Alert-Modus (IDS) aus, beobachten Sie mehrere Tage oder Wochen lang, was sie erkennt, und stellen Sie sicher, dass die Fehlalarmrate akzeptabel ist.

Erst wenn sich eine Regel als vertrauenswürdig erwiesen hat, sollten Sie sie in das Inline-Blocking übernehmen. Dieser schrittweise Ansatz verhindert, dass eine einzelne fehlerhafte Regel einen Ausfall verursacht.

Die korrekte Definition von $HOME_NET und anderen Variablen bildet die Grundlage. Viele Regeln reagieren auf die Richtung (extern zu intern bzw. intern zu extern), sodass ein falsches $HOME_NET die Erkennungslogik unbemerkt beeinträchtigt.

Definieren Sie Ihre internen Bereiche, Servergruppen und vertrauenswürdigen Netze präzise. Halten Sie sie bei Änderungen am Netzwerk aktuell und überprüfen Sie sie, wenn sich Erkennungen unerwartet verhalten.

Sensoren sind nur dann nützlich, wenn ihre Ausgabe die Analysten erreicht. Leiten Sie Alerts und Metadaten zur Korrelation, Anreicherung und Aufbewahrung an ein SIEM weiter.

Das EVE JSON von Suricata erzeugt strukturierte Ereignisse (Alerts, Flows, HTTP, DNS, TLS, Datei-Hashes), die sich problemlos in ein SIEM einspeisen lassen. Kombinieren Sie das IDS mit Full-Packet-Capture, damit Analysten während einer Untersuchung den tatsächlichen Datenverkehr hinter einem Alert abrufen können.

Ein Inline-IPS befindet sich im kritischen Pfad, daher bedeutet sein Ausfall einen Netzwerkausfall. Planen Sie auf Ausfallsicherheit.

• NICs mit Hardware-Bypass / Fail-Open halten den Datenverkehr aufrecht, wenn die Engine ausfällt (wenn Verfügbarkeit wichtiger als Sicherheit ist)
• Redundante Sensoren in Active/Standby- oder Cluster-Paaren
• Auch Out-of-Band-IDS-Sensoren benötigen Redundanz, sonst entstehen unbemerkte blinde Flecken

Entscheiden Sie für jede Verbindung abhängig vom Geschäftsrisiko zwischen Fail-Open und Fail-Closed und testen Sie das Failover, bevor Sie sich darauf verlassen.

Ein eingesetzter Sensor kann unbemerkt an Leistungsfähigkeit verlieren: Eine Konfigurationsänderung, eine SPAN-Umleitung oder eine Lastspitze kann ihn blind machen. Überprüfen Sie, ob er weiterhin funktioniert.

• Führen Sie regelmäßig sicheren Testverkehr aus, den bekannte Regeln erkennen sollten
• Lösen Sie einen Alert aus, wenn erwartete Erkennungen ausbleiben
• Überwachen Sie den Zustand des Sensors (Verluste, CPU, Betriebszeit) ebenso sorgfältig wie die Alerts
• Verwenden Sie Angreiferemulation, um die Abdeckung durchgängig zu überprüfen

Eine Erkennung, die Sie nie testen, können Sie nicht vertrauen.

Diagnostizieren Sie eine Lücke in einer realen Bereitstellung.

Eine effektive IDS-/IPS-Bereitstellung erfordert Sichtbarkeit und Disziplin:

• Die Platzierung entscheidet, was Sie sehen können; decken Sie Perimeter und interne Segmente ab
• Überwachen Sie East-West-Verkehr, nicht nur North-South-Verkehr, um laterale Bewegungen zu erkennen
• Bevorzugen Sie für eine verlustfreie Erfassung mit hohem Durchsatz TAPs gegenüber SPAN
• Dimensionieren Sie Sensoren so, dass Paketverluste nahe null bleiben
• Stellen Sie Regelsätze gezielt zusammen mit suricata-update; unterdrücken bzw. begrenzen Sie Rauschen per Konfiguration
• Stimmen Sie Regeln zunächst im Alert-Modus ab und übernehmen Sie sie anschließend in den Modus drop
• Definieren Sie HOME_NET korrekt
• Leiten Sie EVE JSON an ein SIEM weiter und bewahren Sie den Paketmitschnitt für Untersuchungen auf
• Validieren Sie kontinuierlich die Erkennung und den Zustand der Sensoren

Sie haben den Kurs Network Security Monitoring abgeschlossen.