Blocken oder nicht blocken: Ein IPS, das sich in der Praxis bewährt

Als Security Engineer im NDR-Entwicklungsteam arbeite ich am Aufbau und an der Weiterentwicklung des Service, der Angriffe im Netzwerk erkennt und stoppt, bevor sie Schaden anrichten.
In diesem Artikel nehme ich Sie mit hinter die Kulissen: Wie sind wir beim Aufbau unseres Service vorgegangen - von der Frage, was „gute“ Prävention überhaupt ausmacht, bis zu den Engineering-Herausforderungen, ihn in der Praxis schnell, präzise und zuverlässig zu machen.
Der beste Incident ist der, der nie passiert
Wer Security Operations betreibt, verbringt unzählige Stunden damit, Alerts nachzujagen, Incidents zu untersuchen und nach Angriffen aufzuräumen. Die Grundhaltung meines Teams ist deshalb: Bedrohungen stoppen, bevor sie überhaupt in einem System ankommen. Genau darum umfasst der Network-Detection-and-Response-Service (NDR):
-
Intrusion-Detection-System-Komponenten (IDS), die einen Angriff im Netzwerk erkennen. Dafür kommt das signaturbasierte System SNORT zum Einsatz. Es führt Echtzeit-Traffic-Analysen und Packet Captures in IP-Netzwerken durch. (Eine Signatur ist eine Zeichenkette, zum Beispiel ein Wort, die auf ein Netzwerkpaket passen kann.)
-
Intrusion-Prevention-System-Komponenten (IPS), die verhindern, dass der erkannte Angriff dem Netzwerk und den darin befindlichen Assets schadet. Das IPS ist eine Eigenentwicklung, die auf professionelle Datenquellen von Drittanbietern zurückgreift, um zu beurteilen, ob Traffic bösartig ist. Angetrieben wird es von Zeek, einer Open-Source-Software, die tiefe Einblicke in die Netzwerkaktivität liefert. Sie läuft auf einem Sensor und analysiert den Netzwerkverkehr in Echtzeit. Zeek erfasst hochpräzise Transaktions-Logs, Dateiinhalte und anpassbare Datenausgaben.
IDS und IPS erfüllen bei der Verteidigung von Netzwerkumgebungen jeweils eine eigene, sich ergänzende Rolle. Ein IDS überwacht den Netzwerkverkehr kontinuierlich, um verdächtige Aktivitäten oder bekannte bösartige Muster zu identifizieren, und markiert Alerts zur weiteren Untersuchung - greift aber nicht ein. Ein IPS dagegen nimmt Alerts auf und arbeitet inline im Netzwerkverkehr: Es erkennt Bedrohungen nicht nur, sondern setzt Sicherheitsrichtlinien aktiv durch, indem es bösartige Pakete in Echtzeit blockiert oder verwirft.
Anders gesagt: Das IDS liefert Sichtbarkeit und forensische Einblicke in potenzielle Angriffe, während das IPS eine Durchsetzungsebene hinzufügt, die Attacken im Moment ihres Auftretens unterbinden kann. Zusammen bilden IDS und IPS das analytische und präventive Rückgrat von NDR - und hier gilt es, Erkennungsgenauigkeit und Reaktionsgeschwindigkeit auszubalancieren, um Risiko und operative Auswirkungen zu minimieren.
[caption id=“attachment_19691” align=“alignnone” width=“575”]

Abbildung 1: NDR-Dashboard im Kundenportal.[/caption]
Der NDR-Service überwacht das Netzwerk, um Indicators of Compromise (IoCs) im Traffic zu erkennen. Das können zum Beispiel sein:
-
IP-Adresse
-
URL oder Domainname
-
Datei-Hash, auch kryptografischer Hash genannt: eine Zeichenkette fester Länge aus alphanumerischen Zeichen, die Dateien eindeutig identifiziert.
-
Zertifikats-Fingerprint: eine eindeutige Kennung eines digitalen Zertifikats, die belegt, dass ein gültiger öffentlicher Schlüssel zur Identität des Inhabers gehört.
-
Selbstsignierte Zertifikate: Diese digitalen Zertifikate werden nicht von einer Zertifizierungsstelle (CA) ausgestellt und sind leicht zu erstellen. Sie bieten keinerlei Vertrauenswert. Das ist so, als würde die Person, die das Firmenbudget aufstellt, es auch gleich selbst genehmigen.
Um zu veranschaulichen, wie Traffic überwacht wird, verwende ich manchmal die Analogie des Paketverkehrs bei einer Poststelle.
Angenommen, eine Postmitarbeiterin sieht ein beliebiges Paket und muss anhand bestimmter „Signaturkriterien“ - also schlicht einer Beschreibung von etwas Verdächtigem - beurteilen, ob es eine Waffe enthält. Der Ablauf sieht ungefähr so aus:
-
Zuerst prüfen, ob die Absenderadresse zu einem registrierten Geschäft oder Lieferanten gehört.
-
Dann prüfen, ob das Paket klein und schwer ist.
-
Drittens das Paket röntgen, um zu sehen, ob sich der Umriss einer waffenähnlichen Form abzeichnet.
Treffen alle drei Prüfungen zu, stuft die Postmitarbeiterin das Paket als verdächtig ein. Und es reist nicht weiter.
Übertragen aufs Netzwerk heißt das: Solcher verdächtiger Traffic wird blockiert.
Von False Positives und IoCs
Eine typische Herausforderung in der Netzwerksicherheit ist eine hohe False-Positive-Rate. Sie kann dazu führen, dass legitimer Geschäftsverkehr blockiert wird, obwohl es dafür gar keinen Grund gibt.
Das Ziel meines Teams ist es, die IoCs so präzise wie möglich zu machen. Wir verstehen IoCs als kontextbezogene „Intelligence-Daten“, die einen breiteren Bereich abdecken als Signaturen. Wir wollen Traffic nur dann blockieren, wenn mit hoher Sicherheit feststeht, dass er bösartig ist. Um bei meiner Paket-Analogie zu bleiben: „Nur weil der Umriss wie eine Waffe aussieht, heißt das noch lange nicht, dass es eine ist.“
Bestimmter Traffic kann zum Beispiel legitim sein, wenn ein Kunde eine Firewall-Lösung einsetzt, die unter Umständen ein Traffic-Muster erzeugt, das der NDR-Service als verdächtig eingestuft hat.
Wir wollen False Positives vermeiden, und das ist alles andere als trivial - denn IoCs zeichnen sich vor allem dadurch aus, dass sie sich oft und schnell ändern. Eine bösartige Domain kann morgens registriert, mittags scharfgeschaltet, abends blockiert und am nächsten Tag schon wieder aufgegeben sein. Deshalb sind die NDR-Sensoren so aufgesetzt, dass sie zu jedem Zeitpunkt die aktuellsten verfügbaren IoCs aus professionellen Drittanbieter-Feeds nutzen. Das IPS bezieht diese IoCs und gleicht sie mit dem Netzwerkverkehr ab. Eine weitere Komponente berücksichtigt die NDR-Regeln. Sie sind das Herzstück des IPS und legen fest, welcher Netzwerkverkehr blockiert wird, zum Beispiel: „Wenn der Zertifikats-Fingerprint XYZ auf XZY in einem Netzwerkpaket passt, dann blockiere die Ziel-IP-Adresse.“ Die Verbindung wird unterbrochen und richtet keinen weiteren Schaden an.
[caption id=“attachment_19687” align=“alignnone” width=“575”]

Abbildung 2: Definition von False und True Positives und Negatives.[/caption]
Ein IPS ist in hohem Maße konfigurierbar. Es ist flexibel und passt sich an Kundenumgebungen an. Sie können entscheiden, den Traffic für eine bestimmte Dauer zu blockieren, oder nur die Quell- oder nur die Ziel-IP sperren. Oder Sie legen fest, dass ein Mission-Control-Ticket mit hoher Dringlichkeit erstellt und eine Benachrichtigung an Ihre wichtigsten IT-Admins geschickt wird. Sie können auch Tickets erstellen lassen, ohne den Traffic zu blockieren. Das richtet sich ganz nach Ihrer Unternehmens-Policy und danach, was für Ihre konkrete Geschäftsumgebung am wirkungsvollsten ist.
Die Technical Account Manager von Open Systems klären gemeinsam mit den Admins der Unternehmen Fragen wie diese:
-
Wenn die Quelle des Netzwerkverkehrs extern ist und das Ziel ebenfalls - was wollen Sie dann tun? Ist es Ihnen wichtig? Es ist ja schließlich extern. Lassen Sie den Traffic also durch? Oder blockieren Sie?
-
Wenn der verdächtige Traffic aus Ihrem Netzwerk hinter dem Security Gateway stammt und ins Internet geht - gehen Sie dann von einer bösartigen Verbindung aus und blockieren sie?
Drei Kernanforderungen an ein IPS
Ich halte es für einzigartig, dass die Entwickler bei Open Systems Systeme nicht nur konzipieren, sondern sie im Rahmen des Mission-Control-Betriebsmodells auch für die Kunden betreiben. So sitzen wir „in der ersten Reihe“, sehen, was im Feld passiert, und können handeln. Wir beobachten, dass moderne Bedrohungen immer raffinierter werden und sich sehr, sehr schnell verändern. Hinzu kommt: Allein die Menge und Vielfalt der Alerts kann es schwer machen, echte Bedrohungen vom Rauschen zu trennen. Genau diese Herausforderung - hochpräzise Erkennung, ohne in False Positives zu ertrinken - hat das Design unseres Systems geleitet.
Wir haben drei Anforderungen an das IPS definiert:
-
Schnell: Bedrohungen bewegen sich im Millisekundenbereich. Das IPS muss bösartigen Traffic deshalb sofort erkennen und blockieren, um die Ausbreitung einer möglichen Kompromittierung zu verhindern. Verbindungen werden heutzutage meist sehr schnell aufgebaut, und Datenübertragungen laufen rasant ab. Je früher bösartiger Traffic erkannt und gestoppt wird, desto weniger Schaden kann er anrichten. Außerdem muss man mögliche Engpässe im Blick behalten, damit das IPS schnell bleibt.
-
Präzise: Die False-Positive-Rate muss sehr niedrig sein. Das IPS muss echte Angriffe zuverlässig von legitimem Geschäftsverkehr unterscheiden, damit der normale Betrieb nicht gestört wird. Ein False Positive kann für Kunden sehr frustrierend sein, wenn legitimer Traffic blockiert wird: Plötzlich funktioniert etwas nicht mehr, und die Fehlersuche ist äußerst schwierig.
-
Zuverlässig: Eine falsch konfigurierte Drop-Regel kann einen ganzen Service lahmlegen. Unser IPS muss auch unter hoher Last oder während eines komplexen Angriffs konstante Performance und Stabilität liefern. Außerdem muss das IPS die Möglichkeit bieten, eine fälschlich blockierte Verbindung so schnell wie möglich wieder freizugeben.
Sicherheit, die sich ergänzt
Mehrere Kunden haben uns gefragt, ob uns eine bestimmte Bedrohung bekannt sei. Sie mussten ihrer SOC-Abteilung berichten, welche Schutzmechanismen dagegen im Einsatz waren. Und tatsächlich: In den IoCs gab es Daten, die eine solche Bedrohung erkannt hätten, wäre der Kunde angegriffen worden. Das ist ein bisschen so, wie wenn eine Hausärztin einen Spezialisten um eine Zweitmeinung bittet.
Manchmal können oder wollen Kunden kein Secure Web Gateway (auch Proxy genannt) einsetzen, etwa wenn Anwendungen es nicht unterstützen. In solchen Situationen können sie unmöglich überwachen oder wissen, mit welchen Websites sich ihr internes Netzwerk verbindet. Der NDR-Service bietet in diesem Fall eine alternative Lösung - und denjenigen, die einen Proxy im Einsatz haben, eine zusätzliche Sicherheitsebene. Der feine Unterschied: Das IPS blockiert eine Verbindung nicht, bevor sie zustande kommt, sondern während sie stattfindet, direkt bei der Erkennung - und kann deshalb auf mehr Elemente matchen als IP, URL oder Domain.
Und dann gibt es Situationen, in denen Edge-Geräte technisch gar nicht in der Lage sind, ein Secure Web Gateway zu nutzen, zum Beispiel Roboter in der Operational Technology. Aber ein Roboter braucht vielleicht gelegentlich ein Treiber-Update und muss dafür eine externe Verbindung aufbauen. Wenn Technical Account Manager eine neue Kundenumgebung zur Prüfung übernehmen, wissen sie noch wenig darüber und müssen einkalkulieren, dass Roboter womöglich (unbemerkt) mit Malware ausgeliefert wurden.
Da das IPS auch den internen Netzwerkverkehr überwachen kann, lässt es sich als Ergänzung zum Secure Web Gateway verstehen - wie eine zusätzliche Sicherheitsschicht, die Hand in Hand mit ihm arbeitet. Langfristig soll der NDR-Service IoCs erkennen, die über den Proxy hinausgehen.
Herausforderungen, die wir gemeistert haben
Wir hatten es mit drei komplexen Konstrukten zu tun:
-
Ein Framework für die Konfiguration von NDR-Regeln zu bauen - so etwas wird sehr schnell sehr schwierig. Inzwischen haben wir dafür eine eingebaute Unterstützung, und wir können in den NDR-Regeln auf Wunsch auch diverse Firewall-Objekte wie Netzwerke oder IP-Gruppen verwenden. Hier haben wir mit dem SD-WAN-Cloud-Team zusammengearbeitet und diskutiert, welche Strategien unseren Kunden am meisten helfen.
-
Die IoCs zu aktualisieren und global zu verteilen, damit die Security Gateways von Open Systems sie nutzen können. Hier überwacht und optimiert mein Team den Prozess kontinuierlich im Hintergrund.
-
Die Software, die wir für das Pattern Matching einsetzen, wirklich zu verstehen - wie sie konfiguriert werden muss, um effektiv zu sein, und wie man sie zuverlässig betreibt. Das ist ein praxisnaher Ansatz kontinuierlicher Weiterentwicklung, kombiniert mit der Bereitschaft, ständig dazuzulernen.
Unsere Erfahrung zeigt: Der NDR-Service bringt mehr Sicherheit, weil er im Verbund mit anderen Services wie Network Analytics, Secure Web Gateway und Firewall laufen kann. Auch beim Incident Handling sowie bei der Analyse und Forensik nach einem Vorfall kann er wertvolle Dienste leisten.
[caption id=“attachment_19689” align=“alignnone” width=“468”]

Abbildung 3: Das Mission Control Operations Center von Open Systems kümmert sich um NDR-Tickets.[/caption]
Was am Horizont steht
Ein Bereich, auf den ich mich besonders freue, ist mehr Transparenz bei blockierten Events - durch klareres Logging und eine bessere Oberfläche, damit Prävention nicht nur wirksam, sondern auch nachvollziehbar ist. Und natürlich freue ich mich auf diesen einen Moment beim Testen: sich mit einer bösartigen Domain verbinden, zusehen, wie das IPS sofort reagiert, und wissen, dass der Angriff gestoppt wurde, bevor er überhaupt beginnen konnte. Übrigens: In realen Kundenumgebungen haben wir bislang sehr vielversprechende Ergebnisse erzielt.
Wir erweitern den Service gerade um Malware-Scanning. Die Idee ist, Datei-Scans im internen oder externen Traffic zu ermöglichen. Schickt zum Beispiel jemand eine Datei an einen Roboter, kann diese Datei blockiert werden, wenn sie als bösartig eingestuft wird.
Außerdem wird es für Kunden einfacher, das Filtern an einer zentralen Stelle noch präziser zu konfigurieren. Sie kennen ihre Umgebung am besten und erhalten noch mehr Möglichkeiten, Fälle auszufiltern, von denen sie wissen, dass sie harmlos sind. Solche feingranularen NDR-Regeln sind von mehreren NDR-Komponenten nutzbar, deren Hauptaufgabe das Filtern ist. Die Konfiguration von NDR-Regeln ist bewusst ähnlich aufgebaut wie die von Firewall-Regeln - so ist leichter zu verstehen, wie sie funktionieren, und die Konsistenz spart Zeit. Ich kann definitiv sagen: Wir haben hart daran gearbeitet, die Dinge für unsere Kunden einfach zu machen.
Indem wir IoCs einbinden können, die wirklich bösartigen Traffic erkennen, verhindern wir, dass Malware und andere Cyberangriffe massive geschäftliche Auswirkungen auf unsere Kunden haben.
Denn egal wie stark Ihre Analytik ist: Eine verhinderte Bedrohung ist eine Bedrohung, auf die Sie nie reagieren müssen.
Gleich weiterlesen.

Wenn ein funktionierendes Testsystem zum Engpass wird - und wie wir ihn beseitigt haben
Wie wir ein zuverlässiges Testsystem für mehrere Plattformen weiterentwickelt haben - ohne Neubau von Grund auf und ohne die Entwicklung auszubremsen.

Warum „Human-in-the-Loop“ an seine Grenzen stößt: Mit maschinell erstellten Vorschlägen allein ist es nicht getan
Menschliche Aufsicht allein reicht nicht aus. Erfahren Sie, warum Entscheidungsverantwortung, Kontext und Vertrauen zu den entscheidenden Faktoren für eine erfolgreiche KI-Einführung werden.

Konnektivität im SASE-Zeitalter
Erfahren Sie, wie SASE die Traffic-Flüsse neu ordnet und warum das Design von Last-Mile- und Backbone-Konnektivität über Performance, Sicherheit und operative Resilienz entscheidet.