6 Ein Security Data Lake ist ein zentrales Repository, das große Mengen an Sicherheitstelemetrie wie Logs, Endpoint-Ereignisse, Netzwerkflüsse und Cloud-Audit-Trails in offenen Formaten auf skalierbarem Speicher ablegt, sodass viele Werkzeuge sie abfragen können. Er ist entstanden, weil klassische SIEM-Plattformen an den Kosten scheitern, all das aufzunehmen und aufzubewahren, was Sicherheitsteams heute sammeln. Statt jedes Log durch das SIEM zu schleusen und dort jahrelang vorzuhalten, bewahren Organisationen die vollständige Historie im Lake auf und nutzen das SIEM für die Echtzeiterkennung auf den wichtigsten Daten. Dieser Artikel erklärt, was ein Security Data Lake ist, wie er sich zum SIEM verhält, welche Formate und Architektur er typischerweise nutzt und welche Faktoren über seinen Standort entscheiden: in der Public Cloud, On-Premises oder beides. Die Aufbewahrungsanforderungen für Logs, die diese Entscheidung oft bestimmen, erklärt der Beitrag Wie lange Sicherheitslogs aufbewahrt werden sollten. Warum es Security Data Lakes gibt Sicherheitstelemetrie ist viel schneller gewachsen als Sicherheitsbudgets. Endpoint Detection and Response, Cloud-Audit-Logs, Identitätsanbieter, SaaS-Anwendungen und Netzwerksensoren erzeugen allesamt große Datenmengen. SIEM-Plattformen werden oft nach Ingest-Volumen oder Rechenleistung abgerechnet, und ein Jahr oder mehr an hochvolumigen Daten durchsuchbar zu halten, kann sehr teuer werden. Das Ergebnis ist ein bekannter Kompromiss: Teams verzichten auf Datenquellen, verkürzen die Aufbewahrung oder filtern aggressiv und haben dann bei Ermittlungen nicht die Daten, die sie brauchen. Ein Security Data Lake trennt Speicher und Analyse, sodass Daten kostengünstig aufbewahrt und bei Bedarf abgefragt werden können. Security Data Lake oder SIEM Ein SIEM und ein Security Data Lake erfüllen unterschiedliche Aufgaben: SIEM konzentriert sich auf Echtzeitkorrelation, Erkennungsregeln, Alarmierung, Fallmanagement und die schnelle Suche in aktuellen Daten. Security Data Lake konzentriert sich auf die kosteneffiziente Langzeitspeicherung großer Telemetriemengen, flexible Abfragen, Threat Hunting über lange Zeiträume und die Versorgung von Analytik oder Machine Learning. Viele Organisationen nutzen beides: Hochwertige Daten fließen zur Erkennung ins SIEM, während alle Daten, einschließlich der hochwertigen Quellen, für Aufbewahrung und Hunting im Lake landen. Einige SIEM-Plattformen fragen Lake-Daten inzwischen direkt ab. So ist ein Security Data Lake aufgebaut Speicherschicht Die Basis bildet Objektspeicher, der niedrige Kosten pro Terabyte, Skalierung bis in den Petabyte-Bereich und die S3-API bietet, die Analyse-Engines erwarten. Objektspeicher unterstützt außerdem Unveränderlichkeit, was für Sicherheitsbeweise wichtig ist. Offene Datei- und Tabellenformate Daten werden typischerweise in spaltenorientierten Formaten wie Apache Parquet gespeichert, die gut komprimieren und Abfragen erlauben, nur die benötigten Spalten zu lesen. Offene Tabellenformate ergänzen Dateien im Objektspeicher um Funktionen wie Schemaentwicklung, Partitionierung und Time Travel, sodass sich der Lake eher wie eine Datenbank verhält, während die Daten in offenen Formaten bleiben. Gemeinsames Schema Sicherheitsdaten stammen aus vielen Quellen mit unterschiedlichen Feldnamen. Die Normalisierung auf ein gemeinsames Schema ermöglicht quellenübergreifende Abfragen. Das Open Cybersecurity Schema Framework (OCSF), ein Open-Source-Projekt, das von einer Reihe von Sicherheitsanbietern unterstützt wird, ist eine viel diskutierte Option; manche Organisationen nutzen Schemata ihres SIEM oder eigene Standards. Ingestion-Pipeline Pipelines sammeln Daten aus den Quellen, parsen und normalisieren sie, reichern sie mit Kontext wie Asset- und Identitätsinformationen an und schreiben sie in den gewählten Formaten in den Lake. Pipelines können zudem Teilmengen der Daten an das SIEM weiterleiten. Abfrage- und Analyseschicht SQL-Engines, Notebooks, Threat-Hunting-Werkzeuge und Machine-Learning-Plattformen fragen den Lake ab. Da die Daten in offenen Formaten vorliegen, können mehrere Engines dieselben Daten lesen, ohne sie zu kopieren. Was ein Security Data Lake ermöglicht Längere Aufbewahrung zu geringeren Kosten, was Compliance und die Untersuchung lang andauernder Angriffe unterstützt. Threat Hunting über Monate oder Jahre an Daten. Vorfallsuntersuchungen, die bis zur ursprünglichen Kompromittierung zurückreichen. Detection Engineering: neue Erkennungslogik anhand historischer Daten testen. Analytik und Machine Learning auf großen Datensätzen. Flexibilität bei Werkzeugen, ohne Bindung an einen einzigen Analyseanbieter. Wo sollte ein Security Data Lake liegen? Public Cloud Cloud-Objektspeicher und verwaltete Abfragedienste ermöglichen einen schnellen Start und passen zu Organisationen, deren Telemetrie überwiegend cloudnativ ist. Zu bedenken sind die laufenden Speicherkosten bei wachsenden Daten, Gebühren für Abfragen und Datentransfer, Datenresidenz sowie der Aufwand, große Datenmengen später zu verschieben. On-Premises On-Premises-Objektspeicher hält Sicherheitsdaten in den eigenen Einrichtungen der Organisation, was für regulierte Branchen, Behörden und Organisationen mit strengen Souveränitätsanforderungen wichtig ist. Die Kosten sind planbar, und es fallen keine Gebühren pro Abfrage oder für Egress an, wenn Analysten umfangreiche Hunts durchführen. Erforderlich sind Kapazitätsplanung und Betrieb. Die allgemeinen Designprinzipien behandelt der Beitrag Big-Data-Analytik und Objektspeicher (auf Englisch). Hybrid Viele Organisationen kombinieren beides: Cloud-Telemetrie landet in einem Cloud-Lake, On-Premises-Telemetrie in einem On-Premises-Lake, oder einer dient als Langzeitarchiv für den anderen. Offene Formate machen hybride Designs praktikabel, weil Daten am Ort abgefragt oder ohne Konvertierung verschoben werden können. Faktoren für die Standortwahl Wo der Großteil der Telemetrie entsteht und was es kostet, sie zu verschieben. Datenresidenz und Souveränität mit ihren jeweiligen Anforderungen. Aufbewahrungsdauer und Volumen, die die langfristigen Speicherkosten bestimmen. Abfragemuster: Häufige große Hunts sprechen für Speicher ohne Gebühren pro Abfrage. Vorhandene Kompetenzen und Infrastruktur. Sicherheit des Lake selbst, einschließlich der Frage, wer darauf zugreifen darf und wie er isoliert ist. Den Security Data Lake absichern Ein Lake voller Sicherheitstelemetrie ist ein hochwertiges Ziel. Er enthält Informationen über Infrastruktur, Benutzer und Abwehrmaßnahmen der Organisation. Zu den Schutzmaßnahmen gehören: Strenge Zugriffskontrolle nach dem Least-Privilege-Prinzip und getrennt von der Administration der Produktivsysteme. Unveränderlichkeit für Rohdaten, damit Angreifer keine Spuren löschen können. Verschlüsselung im Ruhezustand und bei der Übertragung, mit sorgfältiger Schlüsselverwaltung. Audit-Protokollierung der Zugriffe auf den Lake selbst. Datenminimierung und Aufbewahrungsgrenzen für personenbezogene Daten. Verhältnis zu SIEM-Speicherstufen Viele SIEM-Plattformen können warme Daten bereits auf Objektspeicher ablegen und nur einen Cache auf ihren Indexern halten. Ein Security Data Lake kann dies ergänzen, indem er Roh- oder normalisierte Daten in offenen Formaten für andere Werkzeuge und eine längere Aufbewahrung vorhält. Manche Organisationen nutzen für beides dieselbe Objektspeicherplattform, mit separaten Buckets und Richtlinien. Kostentreiber, die Sie modellieren sollten Die Wirtschaftlichkeit eines Security Data Lake hängt von wenigen Variablen ab. Die Speicherkapazität wächst mit Ingest und Aufbewahrung, wobei spaltenorientierte Kompression das Volumen gegenüber rohen Logs oft deutlich verringert. Rechenleistung für Abfragen wird schubweise genutzt, bei Hunts und Ermittlungen, nicht kontinuierlich. Die Pipeline-Verarbeitung verursacht Kosten proportional zum Ingest. In der Public Cloud können Anfrage- und Datentransfergebühren bei großen Scans erheblich sein; On-Premises sind die Hauptkosten Hardware, Strom und Betrieb, verteilt über die Lebensdauer der Plattform. Ein hilfreicher Vergleich sind die Kosten pro aufbewahrtem Terabyte und Jahr im Lake gegenüber dem SIEM, für dieselben Daten. Diese Zahl spricht meist dafür, hochvolumige, weniger wertvolle Quellen in den Lake zu verlagern und erkennungskritische Quellen im SIEM zu belassen. Der Einstieg Ein pragmatischer Weg: Hochvolumige Quellen identifizieren, deren Aufbewahrung im SIEM teuer ist. Anforderungen an Aufbewahrung und Schema festlegen. Objektspeicher und ein offenes Tabellenformat bereitstellen. Pipelines für einige Quellen aufbauen und Abfragen validieren. Erkennungskritische Daten ins SIEM leiten und alle Daten in den Lake. Quellen, Analytik und Aufbewahrung schrittweise ausbauen. Checkliste: einen Security Data Lake planen Die Aufgaben festlegen, die der Lake neben dem SIEM übernimmt. Offene Formate und ein gemeinsames Schema wählen. Objektspeicher wählen, der skaliert und Unveränderlichkeit unterstützt. Anhand von Kosten, Datenresidenz und Abfragemustern über Cloud, On-Premises oder Hybrid entscheiden. Ingestion-Pipelines mit Normalisierung und Anreicherung aufbauen. Den Lake mit Zugriffskontrolle, Verschlüsselung und Audit-Protokollierung absichern. Aufbewahrung je Datentyp festlegen und Löschung automatisieren. Hunts und Ermittlungen über lange Zeiträume testen. Fazit Ein Security Data Lake verschafft Sicherheitsteams kostengünstigen, langfristigen Zugriff auf ihre gesamte Telemetrie in offenen Formaten und ergänzt ein SIEM, das sich auf die Echtzeiterkennung konzentriert. Er liegt auf Objektspeicher, in der Cloud, On-Premises oder beides, und der richtige Standort hängt davon ab, wo die Daten entstehen, welche Vorgaben zur Datenresidenz gelten, wie groß das Aufbewahrungsvolumen ist und wie oft Analysten die Historie abfragen. Bauen Sie ihn mit offenen Formaten auf, schützen Sie ihn so sorgfältig wie jedes Produktivsystem und lassen Sie ihn die Aufbewahrungslast tragen, die das SIEM nicht bewältigen kann. Häufig gestellte Fragen Was ist ein Security Data Lake? Ein zentrales Repository für Sicherheitstelemetrie, die in offenen Formaten auf skalierbarem Speicher liegt und von mehreren Werkzeugen für Hunting, Ermittlungen und Analytik abgefragt wird. Ersetzt ein Security Data Lake ein SIEM? In der Regel nicht. Die meisten Organisationen nutzen das SIEM für die Echtzeiterkennung und den Lake für die Langzeitaufbewahrung und breite Analysen. Welche Formate nutzen Security Data Lakes? Meist spaltenorientierte Dateiformate wie Parquet, offene Tabellenformate und ein gemeinsames Schema wie OCSF. Sollte ein Security Data Lake in der Cloud oder On-Premises liegen? Das hängt davon ab, wo die Telemetrie entsteht, welche Vorgaben zur Datenresidenz gelten, wie groß die Datenmengen sind und welche Abfragemuster vorliegen. Viele Organisationen wählen einen hybriden Ansatz. Wie schützt man einen Security Data Lake? Mit strenger Zugriffskontrolle, Unveränderlichkeit für Rohdaten, Verschlüsselung, Audit-Protokollierung und Datenminimierung. Weiterführende Artikel Aufbewahrung von Sicherheitslogs Data Lake oder Data Warehouse