Im ersten Teil unserer Artikelreihe zu Sentinel haben wir gezeigt, warum ein SoC ohne SIEM nicht funktionieren kann. In diesem Beitrag rücken wir nun die Frage in den Mittelpunkt, welche Logs überhaupt ins SIEM gehören – und wie eine effiziente Architektur für das SoC entwickelt werden kann.

Warum Log-Ingest so entscheidend ist

Wer ein eigenes Security Operations Center (SoC) mit SIEM betreibt, steht gleich zu Beginn vor einer entscheidenden Frage: Welche Logs landen im SIEM – und wie?

Die Antwort entscheidet über Effizienz, Übersicht und Kosten. Denn nur mit einer klaren Strategie beim „Log-Ingest“ lassen sich Sicherheitsvorfälle effektiv erkennen, Hunting-Prozesse sinnvoll gestalten und das Budget kontrollieren.

Ein SIEM ist ein zentrales Werkzeug, um Angriffe und Auffälligkeiten sichtbar zu machen. Aber: Nicht jede Logdatei muss im SIEM landen. Ein:e SoC-Analyst:in benötigt keine Datenflut, sondern die relevanten Informationen, um Auffälligkeiten zu identifizieren, Play- und Workbooks zu entwickeln und Bedrohungen einzuordnen.

Die beiden Hauptgründe für ein strukturiertes Log-Management sind:

• Effizienz: Weniger irrelevante Daten bedeuten schnellere Analysen und klarere Hunting-Prozesse.
• Kosten: In Cloud-SIEMs steigen die Kosten direkt mit der Menge der ingesteten Logs.

Microsoft Sentinel im Praxiseinsatz: Konnektoren, Diagnostic Settings und LAW

Wie lässt sich das praktisch umsetzen? Azure Sentinel bietet mehrere Möglichkeiten, Logflüsse effizient anzubinden:

• Konnektoren: Über den Azure Content Hub stehen vorkonfigurierte Lösungen von Microsoft und Drittanbietern bereit. Sie führen in der Regel nur die wichtigsten Logs ins SIEM ein.  
• Diagnostic Settings: Auf Objektebene kann granular eingestellt werden, welche Audit-Logs und Metriken an den Log Analytics Workspace (LAW) weitergeleitet werden. Sentinel selbst arbeitet als Add-on auf einem LAW und ermöglicht so alle sicherheitsrelevanten Operationen.
• Transformationen: Im LAW lassen sich Filter definieren, die unnötige Daten vor dem Ingest aussortieren – und so nicht nur Speicherplatz, sondern auch bares Geld sparen.

Das SIEM als zentrale Sammelstelle für Sicherheitslogs

Das Zielbild eines modernen, SIEM-zentrierten SoC ist klar: Alle sicherheitsrelevanten Ereignisse der gesamten Infrastruktur sollen auf einen Blick erfasst werden. Dafür müssen die Logs unterschiedlichster Systeme von Cloud-Diensten über Endgeräte bis hin zu Security-Tools zentral im SIEM zusammengeführt werden.

Doch zentral heißt nicht automatisch „alles in einer Instanz“. In manchen Fällen ist es sinnvoll, Entwicklungs- und Produktionsumgebung zu trennen und mehrere SIEM-Instanzen parallel zu betreiben:

• In Entwicklungsumgebungen entstehen häufig False Positives.
• Neue Features, Testinstallationen oder Simulationen erzeugen Logeinträge, die bedrohlich wirken können, ohne tatsächlich ein Risiko darzustellen.

Wichtig: Mehrere SIEM-Instanzen bedeuten nicht, dass die Gesamtübersicht verloren geht. Microsoft Sentinel ermöglicht es, Incidents aus verschiedenen Instanzen in einer zentralen Ansicht darzustellen – so bleibt die strategisch wichtige Gesamtperspektive auf alle Sicherheitsvorfälle erhalten.

Architekturfragen vor dem Aufbau eines zentralen SIEM

Wer ein zentrales SIEM etablieren möchte, muss sich im Vorfeld einige Grundsatzfragen stellen. Zum Beispiel:

• Multi-Cloud: Welche Cloud-Provider werden genutzt, und wie können deren Logs eingebunden werden?
• Sicherheitstools: Welche weiteren Security-Lösungen (z. B. Microsoft Defender) erzeugen Alerts, die ins SIEM integriert werden müssen?
• Tenant-Struktur: Gibt es mehrere Tenants, die Logs getrennt erfassen oder zusammengeführt werden sollen?

Generell gilt: Zuerst klären, welche Instanzen welche Art von Logs erzeugen. Diese sollten anschließend zentriert zusammengeführt werden – solange nichts dagegen spricht, z. B. alle Produktionslogs.

So schafft man eine Architektur, die Transparenz und Effizienz vereint, ohne die Flexibilität in der Trennung oder Zusammenführung von Logs zu verlieren.

Retention Time: Wie lange bleiben Logs im System?

Ein wesentlicher Stellhebel im Log-Management ist die Retention Time, also die Frage, wie lange Daten im System verfügbar bleiben. Grundsätzlich gilt: Je länger Logs gespeichert werden, desto höher sind die Kosten – unabhängig vom Anbieter. Deshalb sollten Organisationen genau festlegen, welche Daten sie kurzfristig für Analysen benötigen, welche für mittelfristige Auswertungen relevant sind und welche langfristig archiviert werden müssen.

Wer Logs darüber hinaus sichern muss oder will, setzt besser auf persistentere Storage-Lösung wie einem Data Lake, eine SQL-Datenbank oder anderen Archivlösung.   Wenn man eine persistente Lösung wie Data Lake oder SQL einsetzt, entstehen neue Fragen, z. B.: Wie lange sollen die Logs dort gespeichert werden? Wie wird die Verwaltung programmatisch umgesetzt?

Fazit: Effizienz entsteht durch Architektur

Ein modernes SIEM wie Microsoft Sentinel entfaltet seine volle Wirkung nur dann, wenn die Log-Ingest-Strategie stimmt. Unternehmen, die ihr SoC effizient und kostentransparent betreiben wollen, müssen den richtigen Mix finden:

• Infrastruktur erfassen, relevante Logs extrahieren, unnötige Daten herausfiltern
• Sinnvolle Retention-Strategie definieren
• Architekturentscheidungen bewusst treffen

So entsteht das Gerüst für eine Sicherheitsarchitektur, die nicht nur reaktiv schützt, sondern proaktiv Mehrwert schafft. Sobald das Grundgerüst steht, gilt es, den SoC-Analysten effektive Werkzeuge bereitzustellen, mit denen sie schnell aussagekräftige Logs identifizieren können, um eine Hypothese zu einem möglichen Sicherheitsvorfall entweder zu bestätigen oder zu widerlegen. Diese Werkzeuge werden programmatisch in Form von Log-Abfragen oder auch geeigneten Darstellungsformen der Daten umgesetzt.

Ein besonders hilfreiches Werkzeug ist dabei das sogenannte Hunting, auf welches wir im nächsten Artikel eingehen werden. Hunting, also die gezielte Suche nach aussagekräftigen Logeinträgen, helfen dabei, bestehende Sicherheitshypothesen zu bestätigen oder zu widerlegen und eröffnen zudem die Möglichkeit, proaktiv nach bislang unbekannten Sicherheitslücken zu suchen.

Vorschau: Sentinel verstehen – unsere neue Artikel-Reihe

Dieser Beitrag ist der 2. Teil unserer Serie zu Microsoft Sentinel. In den nächsten Ausgaben nehmen wir weitere zentrale Aspekte genauer unter die Lupe:

• Analyse-Regeln & Threat Hunting: Von der Alarmflut zur Erkennungslogik
• MITRE ATT&CK in Aktion: Wie bekannte Taktiken und Techniken mit Sentinel verknüpft sind
• Security-Vorfälle: wie geht ein:e SoC-Miarbeiter:in vor?