Wie leistungsfähig ist SecureVisio? Performance und Skalierung der SIEM/XDR-Plattform

SecureVisio ist eine Plattform der Klasse SIEM/SOAR/XDR, die dafür ausgelegt ist, Daten aus einer Vielzahl von Quellen zu empfangen, zu parsen, zu speichern und zu analysieren. Die modulare Architektur des Systems ermöglicht es, mit einem einzelnen Service-Stack zu starten und anschließend dessen Ressourcen zu erweitern oder weitere Kollektoren hinzuzufügen, wenn Logvolumen, Quellenanzahl und Sicherheitsregeln wachsen.

Wichtigster Grundsatz: Die Performance des SecureVisio LogCollectors sollte nie allein anhand der EPS-Zahl bewertet werden. Die tatsächliche Kapazität einer Umgebung hängt ebenso von der Komplexität der Parser und Regeln, der Geschwindigkeit der Datenträger, der Anzahl der Suchvorgänge, der Retention sowie kurzfristigen Lastspitzen ab.

SIEM-Performance ist mehr als eine EPS-Zahl

Die reale Kapazität einer Umgebung wird gleichzeitig beeinflusst durch:

• Größe und Komplexität der eingehenden Logs,
• die Art und Weise, wie diese geparst werden,
• Anzahl und Komplexität der Sicherheitsregeln,
• die Leistung des Storage-Subsystems,
• die Anzahl gleichzeitig ausgeführter Suchvorgänge,
• Retention-Dauer sowie Anzahl der Quellen und Kollektoren,
• kurzfristige Spitzen im Datenaufkommen.

Deshalb können zwei Umgebungen, die dieselbe EPS-Zahl empfangen, eine unterschiedliche Anzahl an Servern und unterschiedliche Ressourcen benötigen. Einfache Syslog-Meldungen lassen sich deutlich schneller verarbeiten als umfangreiche Ereignisse mit vielen Feldern, die aufwendiges Parsing und die Prüfung gegen zahlreiche Korrelationsregeln erfordern.

Die modulare LogCollector-Architektur

Das zentrale datenverarbeitende Element in SecureVisio ist der LogCollector. Dabei handelt es sich nicht um einen einzelnen Dienst, sondern um eine Reihe von Komponenten, die jeweils für aufeinanderfolgende Verarbeitungsstufen zuständig sind:

• CollectorController – verwaltet die Komponenten des LogCollectors und verteilt die Konfiguration an die übrigen Dienste.
• LogForwarder – empfängt Logs passiv, etwa per SYSLOG, oder aktiv über API-Konnektoren. Anschließend erkennt er die Quelle, parst die empfangenen Daten und übergibt sie an die weitere Verarbeitung.
• FrameStore – speichert die geparsten Logs sowie die für spätere Suchvorgänge benötigten Daten und stellt sie bereit.
• PolicyEngine – ruft die Logs ab und prüft sie gegen die Sicherheitsregeln, die den jeweiligen Richtlinien und Quellen zugeordnet sind. In dieser Komponente findet die Korrelation statt, aus der Sicherheitsereignisse entstehen.
• EventStore – speichert die von der PolicyEngine erzeugten Ereignisse und stellt sie den übrigen Systemkomponenten zur Verfügung.
• LogAnomalyDetector – analysiert Ereignisse auf Anomalien, unter anderem im Zusammenhang mit Benutzern und Assets.

Die Aufteilung des Prozesses in separate Dienste erlaubt es, Ressourcen genau dort zu erweitern, wo die Last entsteht. Liegt das Problem beim Empfang und Parsing der Daten, kann die LogForwarder-Ebene ausgebaut werden. Ist die Regelausführung der Engpass, lässt sich die PolicyEngine auslagern oder mit mehr Ressourcen ausstatten. Betrifft das Problem das Schreiben der Daten, werden FrameStore, EventStore und die Disk-Performance zu den entscheidenden Faktoren.

Wie viele EPS verarbeitet SecureVisio?

Die Performance der Standardarchitektur des LogCollectors wurde – bei typischer Aufteilung der Dienste und empfohlenen Ressourcen – mit rund 20.000 EPS beziffert.

Der vollständige Prozess umfasst dabei:

• Empfang, Parsing und Speicherung der Frames,
• Ausführung der Sicherheitsregeln,
• Erstellung und Speicherung von Ereignissen,
• Aufbau und Aktualisierung der Informationen in der CMDB,
• Anomalie-Analyse,
• Indexerstellung, Suche und Reporting.

Es wird angenommen, dass nach dem Parsing und der Speicherung der Logs sowie der Ausführung von Regeln, die sicherheitsseitig irrelevanten Traffic aussortieren, etwa 35 % aller Logs die Korrelations-Engine erreichen.

Die endgültige Dimensionierung sollte stets auf Basis von Daten erfolgen, die für die jeweilige Organisation charakteristisch sind.

Referenzarchitektur für ca. 20.000 EPS

Für eine Umgebung mit einer Kapazität von bis zu etwa 20.000 EPS wird empfohlen, die Kollektor-Dienste auf drei Maschinen aufzuteilen:

Server	Dienste	CPU	RAM
SV-COL 01	CollectorController, FrameStore	10 vCPU	16 GB
SV-COL 02	PolicyEngine, EventStore, LogAnomalyDetector	24 vCPU	24 GB
SV-COL 03	LogForwarder	12 vCPU	10 GB

Als Prozessoren für den LogCollector werden in diesem Fall Intel Xeon 24C/32C oder AMD EPYC 24C/32C mit einer Mindesttaktung von 2 GHz pro Kern empfohlen.

Für jede Maschine sollte eine SSD-Systemplatte mit 100 GB vorgesehen werden. Beim FrameStore wird der Speicherplatz für aktive Logs überschlägig mit etwa 80–100 GB pro Tag Retention angesetzt. Für aktive Ereignisse wird ein Wert von rund 10 GB pro Tag angenommen. Der genaue Bedarf hängt von der Loggröße, dem Kompressionsgrad, der Anzahl erzeugter Ereignisse und der Retention-Richtlinie ab.

Es handelt sich um eine Referenzkonfiguration, nicht um eine feste Grenze. Einzelne Dienste können auf gemeinsamen Servern laufen oder auf separate Maschinen verteilt werden, wenn das Lastprofil dies erfordert.

Zu beachten ist, dass die aufgenommene Logmenge bei dieser Architektur je nach Typ der Logquellen und den übertragenen Formaten (SYSLOG, JSON, XML …) variieren kann.

Vertikale Skalierung: mehr Ressourcen für bestehende Dienste

Der einfachste Weg, die Kapazität eines bestehenden Kollektors zu erhöhen, ist die vertikale Skalierung – also mehr vCPUs, mehr RAM und höhere Disk-Performance.

Für einen LogForwarder, der rund 5.000 EPS verarbeitet, umfasst eine Beispielkonfiguration 8 vCPU und 8 GB RAM. Bei einem Anstieg auf etwa 10.000 EPS kann eine Erweiterung auf rund 10 vCPU und 10 GB RAM in Betracht gezogen werden. Dieser Zusammenhang ist jedoch nicht linear, da die Parsing-Zeit vom Logformat und dem eingesetzten Parser abhängt.

Die Prozessorleistung hängt nicht nur von der Anzahl der Kerne ab, sondern auch von deren Geschwindigkeit. Zusätzliche vCPUs erhöhen die Zahl parallel ausgeführter Operationen, während eine höhere Taktung die Verarbeitungszeit eines einzelnen Logs oder die Ausführung einer konkreten Regel verkürzt.

Das ist besonders relevant bei:

• aufwendigen Parsern,
• Regeln mit vielen Bedingungen,
• Operationen, die nacheinander auf einem einzelnen Frame ausgeführt werden,
• virtualisierten Umgebungen mit starker gemeinsamer Nutzung physischer Prozessoren.

Eine hohe Anzahl an vCPUs liefert nicht immer die erwartete Leistung, wenn der Hypervisor überlastet ist, die Prozessoren niedrig getaktet sind oder die virtuelle Maschine lange auf die Zuteilung von CPU-Zeit warten muss.

Horizontale Skalierung: zusätzliche LogForwarder und komplette Kollektor-Stacks

Bei größeren Lasten ist die horizontale Skalierung der empfohlene Ausbauweg – also das Hinzufügen kompletter Stacks von LogCollector-Diensten.

SecureVisio ermöglicht es:

• zusätzliche LogForwarder zu installieren,
• ausgewählte Quellen auf separate LogForwarder zu verlagern,
• vollständige Kollektor-Stacks hinzuzufügen,
• Kollektoren an verschiedenen Standorten zu platzieren,
• für einzelne Kollektoren separate Retention-Richtlinien anzuwenden.

Ein zusätzlicher LogForwarder kann nah an den Logquellen betrieben werden – auch in einem netzwerkseitig separierten Standort. Er empfängt die Daten dann lokal, parst sie und überträgt sie an den zentralen FrameStore. Das reduziert den Traffic zwischen den Standorten und verteilt die Parsing-Last.

Die Anzahl der einem Stack zugeordneten LogForwarder-Dienste ist architektonisch nicht begrenzt. Bei stärkerem Datenwachstum können stattdessen ganze Kollektoren hinzugefügt werden. Architektur, Anzahl der Kollektor-Dienste, EPS-Volumen und der für Logs vorgesehene Speicherplatz werden in SecureVisio nicht als Lizenzgrenzen berücksichtigt.

Warteschlangen als Schutz vor kurzfristigen Lastspitzen

Die Kollektor-Dienste nutzen Warteschlangen, die die einzelnen Verarbeitungsstufen voneinander entkoppeln. Im typischen Ablauf werden die Daten:

1. empfangen,
2. verarbeitet,
3. an den nächsten Dienst übergeben.

Die Standardgröße der Warteschlangen kann 1.000.000 Elemente betragen und ist konfigurierbar. Treffen kurzzeitig mehr Logs ein, als ein Dienst verarbeiten kann, verbleiben die Daten in der Warteschlange, bis sich die Last wieder abbaut.

Wichtig: Eine Vergrößerung der Warteschlange erhöht nicht die dauerhafte Verarbeitungsleistung eines Dienstes. Sie ermöglicht jedoch, einen kurzfristig erhöhten Logeingang – eine Lastspitze – ohne Datenverlust abzufangen. Übersteigt der Logeingang die Verarbeitungskapazität über einen längeren Zeitraum, läuft letztlich auch die Warteschlange voll.

Die Größe der Warteschlangen kann bei der Implementierung festgelegt werden, nachdem Häufigkeit und Dauer der Lastspitzen geprüft wurden. In diesem Fall muss auch der Arbeitsspeicher entsprechend erweitert werden. Beim Dienst LogForwarder kann das Befüllen eines Puffers mit 1.000.000 Datensätzen zusätzlich etwa 3–5 GB RAMbeanspruchen.

Die Elemente der Warteschlange werden im RAM gehalten. Ihre Vergrößerung sollte daher immer mit einer ausreichenden Speicherreserve einhergehen.

Storage, IOPS und Datenretention

FrameStore und EventStore schreiben ihre Daten in Dateien. Die Größe des verfügbaren Speicherplatzes wirkt sich damit direkt auf die Retention-Dauer aus. SecureVisio unterscheidet zwischen:

• ONLINE-Daten, die direkt in den System-Browsern verfügbar sind,
• ARCHIV-Daten, die über die Archiv-Browser zugänglich sind.

Für aktive Logs und Ereignisse werden SSD-/NVMe-Datenträger mit mindestens rund 5.000 IOPS empfohlen. Archivdaten, die seltener gelesen werden, können auf langsameren Datenträgern oder in einem separaten Speicherbereich abgelegt werden.

In der Praxis beeinflusst die Disk-Performance gleichzeitig:

• das Schreiben neuer Logs und Indizes,
• die Archivierung,
• die Suche,
• das Lesen der Daten durch die PolicyEngine,
• das Schreiben von Ereignissen und Ergebnissen der Anomalie-Analyse.

Wenn sich die Schreib-Warteschlange von FrameStore oder EventStore trotz verfügbarer CPU- und RAM-Ressourcen zu füllen beginnt, kann die Ursache in einer zu geringen Anzahl an Disk-Operationen, hohen Storage-Latenzen oder einem mit anderen Workloads geteilten – und dadurch belasteten – Speichersystem liegen.

Performance der Sicherheitsregeln in der PolicyEngine

Die PolicyEngine führt Sicherheitsregeln für die Logs aus, die von der jeweiligen Richtlinie erfasst sind. Ihre Auslastung hängt nicht nur von der EPS-Zahl ab, sondern auch von:

• der Anzahl aktiver Regeln,
• der Anzahl der Bedingungen pro Regel,
• der Reihenfolge der Bedingungen innerhalb einer Regel,
• den verwendeten Funktionen, z. B. Funktionen auf Basis des CMDB-Kontexts,
• der Häufigkeit, mit der Bedingungen erfüllt werden,
• der Art der analysierten Felder,
• der Logmenge, die einzelne Quellen übermitteln.

Eine einzige nicht optimierte Regel kann deutlich mehr Zeit beanspruchen als alle übrigen und dazu führen, dass die Ausführungs-Warteschlange anwächst.

Das System stellt außerdem SPAM-Regeln bereit, die festlegen, wie relevant Logs für die weitere Korrelation sind. Die Logs werden weiterhin geparst und gespeichert. Diese Regeln können geparste Frames zudem zur weiteren Korrelation an einen anderen Kollektor weiterleiten.

Schnelle Suche mit indexierten Feldern und cSQL

Zur Performance einer SIEM-Plattform gehört auch die Zugriffsgeschwindigkeit auf die gesammelten Daten. SecureVisio ermöglicht die indexbasierte Suche für ausgewählte Schema-Felder, darunter:

• SrcIP und DstIP,
• SrcName und DstName,
• SrcUserName und DstUserName,
• SrcProcessName und DstProcessName,
• Message und ReqURL,
• DstFileHash und DstPort,
• ClassCategory und ClassAction.

Abfragen können mit der cSQL-Syntax oder per Volltextsuche ausgeführt werden. Die Nutzung eines Index reduziert die Menge der zu lesenden und zu analysierenden Daten erheblich.

Damit eine cSQL-Abfrage einen Index nutzt, sollte sie unter anderem:

• ausschließlich indexierte Felder verwenden,
• einen Zeitraum abdecken, für den Indizes vorliegen,
• unterstützte Vergleichsoperatoren einsetzen,
• keine nicht unterstützten Funktionen und Konstrukte enthalten.

In der Operator-Konsole von SecureVisio sind indexierte Felder im Log-Browser blau gekennzeichnet.

Multi-Search über verteilte Kollektoren

In verteilten Umgebungen arbeitet der Browser standardmäßig im Multi-Search-Modus. Eine Abfrage wird dann gleichzeitig auf mehreren ausgewählten Kollektoren ausgeführt; die Ergebnisse werden zusammengeführt, sortiert und in einer gemeinsamen Ansicht dargestellt.

Multi-Search unterstützt:

• die cSQL-Syntax,
• erweiterte SELECT-Abfragen,
• Aggregationen,
• Volltextsuche,
• das Zusammenführen von Ergebnissen mehrerer Kollektoren.

Das Hinzufügen weiterer Stacks bedeutet dadurch nicht, jeden einzelnen manuell durchsuchen zu müssen. Die Architektur kann verteilt sein – die Ergebnisse bleiben über eine einzige Oberfläche verfügbar.

Wovon hängt die reale Performance von SecureVisio ab?

Die wichtigsten Faktoren, die die Kapazität des Systems bestimmen, sind:

• Anzahl und Größe der Logs,
• Komplexität der Parser,
• Anzahl der Sicherheitsregeln und deren Ausführungszeit,
• Anzahl der Quellen pro LogForwarder,
• Prozessorgeschwindigkeit und Verfügbarkeit der vCPUs,
• Größe des Arbeitsspeichers,
• Disk-Performance,
• Anzahl gleichzeitiger Abfragen,
• Retention-Dauer,
• kurzfristige EPS-Spitzen,
• Netzwerkkommunikation zwischen den Diensten.

Referenzwerte sollten deshalb als Ausgangspunkt verstanden werden. Das verlässlichste Sizing entsteht auf Basis einer Stichprobe realer Logs, der Liste der einzusetzenden Parser und Regeln sowie der geplanten Retention.

Fazit

SecureVisio lässt sich von einer einzelnen Umgebung mit einigen Tausend EPS bis hin zu einer verteilten Architektur mit mehreren LogCollector-Stacks skalieren.

Eine Organisation kann die Ressourcen eines bestimmten Dienstes erweitern, einen zusätzlichen LogForwarder in Betrieb nehmen oder einen weiteren vollständigen Kollektor-Stack anbinden. Warteschlangen-Mechanismen, Indexierung, Multi-Search sowie die Trennung von Online- und Archivdaten helfen dabei, die Stabilität sowohl bei der laufenden Verarbeitung als auch bei der späteren Datensuche zu erhalten.

Kernaussage: Es gibt keinen einzelnen EPS-Wert, der jede Implementierung beschreibt. Eine korrekte Dimensionierung muss die gesamte Verarbeitungskette berücksichtigen: vom Empfang und Parsing über die Korrelation bis hin zu Speicherung, Retention und Datensuche.