SIEM & Security-Monitoring mit Echtzeit-Korrelation

Ausgangslage

Firewall, Mail-Gateway, Microsoft 365, Endpoint-Schutz, Telefonanlage, Kameras, Server, Switches: jedes System schreibt fleißig Logs. Nur gelesen hat sie niemand: verteilt über ein Dutzend Konsolen, jede mit eigenem Login, eigener Sprache und eigenem Alarmverhalten.

Auffälligkeiten fielen auf, wenn etwas kaputt war. Nicht, wenn es anfing kaputtzugehen. Und für ein dediziertes Security-Team ist eine Gruppe mit rund 100 Mitarbeitern schlicht zu klein.

Das Schwierige daran

Logs einzusammeln ist der einfache Teil. Der schwierige ist die Entscheidung, was einen Menschen unterbrechen darf, denn ein System, das zu viel meldet, wird nach zwei Wochen weggeklickt und ist dann schlechter als gar keines: Es täuscht Sicherheit vor, wo längst keine mehr stattfindet.

Eine Auffälligkeit ist noch kein Befund. Ein Beispiel aus dem eigenen Betrieb: Der DNS-Server meldete nächtelang „Festplatte voll“. Gemessen war das richtig, denn die Wartung der Abfrage-Datenbank braucht kurzzeitig den doppelten Platz und gibt ihn danach wieder frei. Als Alarm war es wertlos. Drei solcher Meldungen pro Nacht hätten gereicht, damit auch die vierte ungelesen bleibt.

Die zweite Sorte zeigt auf etwas, das es so nicht mehr gibt. Ein Einbruch des Mailvolumens um 98 Prozent sieht nach Ausfall aus; tatsächlich war es ein stillgelegtes Postfach, dessen Mitschnitt niemand abgedreht hatte.

Die unangenehmste Klasse aber ist die dritte: Ein Monitor kann grün sein, weil er nichts sieht. Nicht, weil nichts ist. Zwischen „keine Meldung“ und „keine Erkennung“ liegt der ganze Unterschied, und von außen sind die beiden nicht zu unterscheiden. Genau deshalb überwacht die Pipeline sich selbst.

Lösung

Aufgebaut wurde ein zentrales SIEM auf eigener Infrastruktur: eine schlanke Log-Pipeline nimmt Syslog-, GELF- und API-Daten aus rund 30 Systemen an: von Microsoft 365 und Endpoint-Security über Proxmox-Cluster, Switches und USVs bis zur Telefonanlage.

Darüber liegt eine selbst entwickelte Monitoring-Schicht: rund 60 Monitore und Echtzeit-Korrelationsregeln prüfen im 30-Sekunden-Takt auf Muster wie Brute-Force-Versuche, unmögliche Anmeldeorte oder auslaufende Zertifikate. Bewertet, dedupliziert und priorisiert wird regelbasiert. Zugestellt wird nur, was eine Handlung verlangt; für die Tiefenanalyse einzelner Vorfälle steht ein lokales Sprachmodell auf Abruf bereit.

Relevante Alarme gehen sofort als Push und Mail an die Verantwortlichen; alles Nachrangige sammelt ein Digest zweimal täglich.

Wie es gebaut ist

Der Aufbau ist ein Trichter mit vier klar getrennten Stufen: Einsammeln, Ablegen, Bewerten, Zustellen. Jede lässt sich einzeln austauschen. Den Logspeicher haben wir im laufenden Betrieb gewechselt, ohne eine einzige Regel anzufassen.

Eingesammelt wird mit einem schlanken Kollektor, der Syslog, GELF und API-Quellen annimmt und normalisiert. Die Bewertung liest dann nicht bei jeder Regel neu im Logspeicher, vielmehr arbeitet auf einem gleitenden Zeitfenster, und das ist der Grund, warum der Takt bei 30 Sekunden stabil bleibt, unabhängig davon, wie viel gerade hereinkommt.

Jeder Monitor ist ein eigener kleiner Dienst mit genau einer Aufgabe, einem Zuständigen und einem Alarmtext. Kein Monolith mit sechzig Schaltern. Ein Monitor, der Unsinn meldet, wird abgeschaltet, ohne die anderen 59 zu berühren.

Zugestellt wird zweigleisig: Was eine Handlung verlangt, geht sofort als Push und Mail an den Zuständigen, alles Übrige sammelt ein Digest zweimal täglich. Diese Trennung ist keine Bequemlichkeit. Sie ist die eigentliche Schutzmaßnahme gegen Alarmmüdigkeit.

Im Betrieb

Der erste Monitor überwacht die Pipeline selbst. Bleibt die Aufnahme stehen, gehen Ereignisse nicht laut verloren, vielmehr leise, und das Lagebild sieht dann ruhig aus, obwohl es blind ist. Ein stehendes Aufnahme-Journal ist deshalb ein Alarm eigener Priorität.

Unterdrückungen gibt es, aber sie sind eng gefasst und begründet: Anmeldungen aus dem eigenen Netz werden anders bewertet als solche von außen. Eine generelle Nachtruhe haben wir bewusst abgelehnt. Angriffe richten sich nicht nach Bürozeiten, und die Stunden, in denen niemand hinsieht, sind genau die interessanten.

Jeder Falsch-Positive wird an der Quelle behoben. Nicht durch Anheben der Schwelle. Schwellen anzuheben ist der Weg, auf dem ein Sicherheitssystem still wird, ohne dass es jemand merkt.

Ergebnis

Rund sieben Millionen Events pro Tag laufen heute durch die Pipeline: gelesen von Maschinen und nicht von Menschen. Zwischen Ereignis und Alarm liegen Sekunden statt Zufall.

Sicherheitsvorfälle, Backup-Ausfälle oder ein volllaufender Storage fallen auf, bevor sie zum Problem werden, ohne zusätzliches Personal und ohne Lizenzkosten für ein Cloud-SIEM.

Was wir daraus gelernt haben

Ein Monitor für die Auslastung der Terminalserver zeigte über Wochen plausible, aber falsche Absolutwerte. Der Grund war eine Verwechslung in der Definition: Die verwendete Kennzahl war der Anteil eines einzelnen Prozesses und nicht die Last des Systems, und im Rohdatensatz heißen die beiden fast gleich. Seither gilt: Erst festschreiben, was eine Zahl bedeutet. Dann anzeigen.

Ein Detektor für blockierte Storage-Replikation war blind für genau die Störung, für die wir ihn gebaut hatten. Er prüfte einen Zähler, der auch im Fehlerfall weiterläuft. Die Lehre daraus steckt heute in der Bauanleitung für jeden neuen Monitor: Bevor er produktiv geht, muss der Fehlerfall einmal künstlich hergestellt und die Meldung tatsächlich gesehen worden sein. Ein Monitor, der nie ausgelöst hat, ist unbewiesen.

Beide Fälle haben dieselbe Form. Nicht das System hat versagt, vielmehr unsere Annahme darüber, was gemessen wird. Deshalb ist die wichtigste Frage bei einem neuen Alarm nicht „ist das schlimm?“, vielmehr: Was genau zählt diese Zahl, und was würde eigentlich passieren, wenn die Störung wirklich einträte?