SOC und SIEM aufbauen

Weil ein Angriff selten in einem einzigen System sichtbar wird. Eine Anmeldung zur Unzeit auf dem Verzeichnisdienst, ein Verbindungsversuch nach außen auf der Firewall und ein neuer Dienst auf einem Server sind einzeln unauffällig und zusammen ein Vorfall.

Dazu kommt die Nachweispflicht: NIS-2 und das IT-Sicherheitsgesetz verlangen von Betreibern kritischer Infrastrukturen Systeme zur Angriffserkennung.

Eine gemeinsame Sicht auf Ereignisse aus Systemen, die sonst nichts voneinander wissen. Aufbewahrung für die Nachbereitung eines Vorfalls, wenn die Frage kommt, seit wann jemand im Netz war. Und eine messbare Größe für die eigene Erkennung: welcher Angriffsschritt löst eine Regel aus und welcher nicht.

Klassisch im eigenen Rechenzentrum, als Dienst aus der Cloud, oder gemischt, wobei die Sammlung lokal bleibt und die Auswertung außerhalb läuft. Dazu unterscheiden sich die Systeme darin, ob sie nach Ereignismenge oder nach Rechenzeit abrechnen, was den Betrieb stärker beeinflusst als die Technik.

Drei kommen regelmäßig vor. Die Quellen liefern nicht, was die Regeln darauf erwarten. Die Schwellwerte stammen aus einer Vorlage und passen nicht zu Ihrer Umgebung, was Meldungen ohne Substanz erzeugt. Und niemand ist zuständig, die Meldungen zu bearbeiten, wodurch aus einem Alarm ein Eintrag wird, den man wegklickt.

Der teuerste Fehler ist der Anfang bei der Plattform statt bei den Erkennungszielen. Dann wächst die Datenmenge und die Erkennung wächst nicht mit.

Die Abdeckung gegen MITRE ATT&CK als Steuerungsgröße statt der Zahl der angebundenen Quellen. Erkennungsregeln als versionierter Code mit Tests, statt als Klickstrecke in einer Oberfläche. Und die Verschiebung der Aufbewahrung in günstigeren Speicher, weil die Kosten sonst mit der Datenmenge mitwachsen.

Verbreitet sind Splunk, Microsoft Sentinel, Elastic, IBM QRadar und Wazuh, dazu im OT-Umfeld eigene Sensorik. Wir arbeiten mit dem, was bei Ihnen steht: Ein Plattformwechsel ist selten nötig, um die Erkennung zu verbessern.

Ein Security Operations Center ist die Organisation um das SIEM herum: Menschen, Abläufe und Zuständigkeiten. Wer sichtet Meldungen, wer entscheidet über eine Eskalation, wer darf ein System vom Netz nehmen und wann.

Ein SIEM ohne SOC erzeugt Meldungen, die niemand bearbeitet. Deshalb bauen wir beides zusammen auf und übergeben den Betrieb an Ihr Team.

Wir bauen auf und übergeben. Den Betrieb übernimmt Ihr Team, weil die Kenntnis Ihrer Umgebung der Teil ist, der die Erkennung trägt. Für die Anfangszeit und für Eskalationen bleiben wir erreichbar.

An der Abdeckung gegen ATT&CK, am Anteil der bearbeiteten Meldungen und an einer Übung, in der wir Angriffsschritte ausführen und mitschreiben, welche davon in Ihren Werkzeugen ankamen.

Die Spanne ist groß und diese Faktoren bestimmen sie:

• Art des Systems. On-Premise bedeutet eine höhere Anfangsinvestition und niedrigere laufende Kosten. Cloud-basiert ist umgekehrt: wenig Investition, dafür monatliche Kosten und eine stärkere Bindung an den Anbieter.
• Funktionsumfang. Korrelation, Threat Intelligence und Automatisierung kosten mehr als reine Sammlung und Suche.
• Datenvolumen und Nutzerzahl. Beides treibt die Lizenz, im Cloud-Modell besonders deutlich.
• Beratungs- und Betriebsaufwand. Ein SIEM ohne gepflegte Use Cases erzeugt Alarme, denen niemand nachgeht.

Elasticsearch steht seit August 2024 wieder unter einer freien Lizenz, der Basisbetrieb kostet also nichts. Einzelne Sicherheitsfunktionen hängen weiter an einer kostenpflichtigen Stufe und der Aufwand steckt ohnehin in Aufbau und Betrieb. Als unverbindliche Größenordnung aus unseren Projekten:

• Kleine Unternehmen: 10.000 bis 50.000 Euro
• Mittelständische Unternehmen: 50.000 bis 100.000 Euro
• Große Unternehmen: 100.000 bis 250.000 Euro

Eine genaue Zahl ergibt sich erst aus der Bedarfsanalyse: Quellen, Datenvolumen, Aufbewahrungsdauer und die Frage, wer das System betreibt. Mit Elasticsearch, Kibana und Logstash bleibt ein SIEM auch für Unternehmen ohne eigene Sicherheitsabteilung im Rahmen. Ein Einstieg in den Stack steht in unserem Artikel Von Logstash bis Kibana.

Die Arbeit teilt sich in drei Phasen:

• Prävention. Sicherheitskontrollen wie Firewalls, IDS und Endpunktschutz, Patch-Management mit festen Fristen, Härtung nach Vorgabe und Schulung der Mitarbeitenden.
• Detektion. Logdaten aus den relevanten Quellen, Korrelation im SIEM, Use Cases mit definiertem Schwellwert und jemand, der die Alarme bearbeitet.
• Reaktion. Playbooks für die wiederkehrenden Fälle, definierte Eskalation, Forensik und ein Wiederanlauf, der geübt ist.

Die drei hängen zusammen. Detektion ohne Reaktion erzeugt Tickets, Prävention ohne Detektion lässt Sie im Dunkeln, wenn sie einmal versagt.

Die Begriffe werden oft vermischt. Kurz sortiert:

• SIEM (Security Information and Event Management): sammelt und korreliert Ereignisse aus Firewalls, IDS, Endgeräten und Anwendungen und macht daraus Alarme. Ein Werkzeug.
• SOC (Security Operations Center): die Organisation aus Menschen, Prozessen und Werkzeugen, die diese Alarme bearbeitet. Ein SIEM ohne SOC ist ein Archiv.
• SOAR (Security Orchestration, Automation and Response): automatisiert wiederkehrende Reaktionsschritte über Playbooks.
• EDR (Endpoint Detection and Response): Erkennung und Reaktion auf dem Endgerät selbst, mit Prozessbaum und der Möglichkeit, ein System zu isolieren.
• XDR (Extended Detection and Response): dieselbe Idee über Endgerät, Netz, Identität und Cloud hinweg, meist aus einer Hand und damit aus einem Ökosystem.
• MDR (Managed Detection and Response): ein Dienstleister übernimmt Erkennung und Reaktion. Das ist ein Betriebsmodell und keine Technologie.

Welches Modell wirtschaftlich ist, hängt an Ihrer Größe und daran, ob Sie eine Rufbereitschaft rund um die Uhr selbst stellen können. Ein Vergleich steht in unserem Artikel Internes SOC, Managed SOC oder Hybrid.