Die versteckten Kosten von SIEM: Warum Ingest-Preise SOC-Budgets sprengen

Viele etablierte SIEM-Plattformen wurden traditionell nach dem Datenvolumen lizenziert, das sie täglich verarbeiten (GB/Tag), oder nach Events pro Sekunde (EPS) – auch wenn in den vergangenen Jahren neuere Lizenzmodelle aufgekommen sind. Dieses Modell koppelt Ihr Sicherheitsbudget an eine Größe, die Sie nicht vollständig kontrollieren können – das Log-Volumen – und führt regelmäßig zu unerwarteten Nachzahlungen, Lizenzverletzungen und Infrastrukturkosten, die nie im Angebot standen. Ein Asset-basiertes Lizenzmodell, wie es SecureVisio verwendet, bepreist die Plattform stattdessen nach der Anzahl der überwachten Geräte. Das Ergebnis sind Gesamtbetriebskosten (Total Cost of Ownership, TCO), die Sie vom ersten Tag an kalkulieren können und die sich nicht verändern, wenn eine Firewall plötzlich im Debug-Modus zu protokollieren beginnt.

Wenn Sie ein SOC betreiben oder ein SecOps-Team leiten, kennen Sie die Lücke zwischen dem Preis im Angebot und dem Preis, den Sie tatsächlich zahlen. Dieser Artikel zeigt, woher diese Lücke stammt, führt durch sechs praxisnahe Szenarien, die die SIEM-TCO klammheimlich in die Höhe treiben, und erklärt, welche architektonischen und lizenzrechtlichen Entscheidungen die Kosten von SecureVisio planbar halten.

Warum SIEM-Preismodelle über Ihr Budget entscheiden

Bevor man Werkzeuge vergleicht, hilft es, zwei sehr unterschiedliche Fragen zu trennen: Was kostet die Lizenz und was kostet der Betrieb der Plattform. Bei Ingest-basierten SIEMs sind beide Antworten variabel – und beide entwickeln sich im Laufe der Zeit in die falsche Richtung.

Die Ingest-Preisfalle

Bei einem volumenbasierten Modell wird jedes Gigabyte abgerechnet, das die Plattform pro Tag indiziert. Das klingt zunächst vernünftig, bis man erkennt, wie wenig des täglichen Log-Volumens man tatsächlich steuert. Eine „geschwätzige” Anwendung, eine geänderte Logging-Konfiguration eines Herstellers, eine falsch konfigurierte Firewall oder ein routinemäßiges Betriebssystem-Update können das Volumen allesamt in die Höhe treiben – ohne dass jemand in Ihrem Unternehmen eine bewusste Entscheidung getroffen hätte. Ihre Rechnung folgt dem Volumen, nicht Ihrer Sicherheitslage.

Es gibt ein zweites, subtileres Problem: Viele Enterprise-SIEM-Plattformen lizenzieren Funktionen wie SOAR, erweiterte Analytik, User Behavior Analytics (UEBA) oder Governance und Compliance getrennt vom Kernprodukt. Das genaue Lizenzmodell variiert je nach Hersteller, doch Organisationen kaufen häufig mehrere Produkte oder Module, um eine vollständige Security-Operations-Plattform aufzubauen. In vielen Deployments werden mehrere separat lizenzierte Produkte zusammengeführt und zu einer einheitlichen Security-Operations-Plattform integriert – was sowohl die Beschaffung als auch die betriebliche Komplexität erhöht.

Worin sich SecureVisio unterscheidet

SecureVisio wird nach den überwachten Informations- und Service-Assets lizenziert – Workstations, Server, mobile Geräte und ähnliche Endpunkte. Sie dimensionieren die Lizenz zum Kaufzeitpunkt nach Ihrer Geräteanzahl, und diese Zahl schwankt nicht mit dem Log-Durchsatz.

Zwei Konsequenzen sind für eine SOC-Leitung entscheidend:

Die Lizenzkosten hängen nicht von EPS ab, und es gibt keine Obergrenze für die Anzahl der Log-Quellen. Sie zählen einzig die überwachten Assets. Binden Sie so viele Log-Quellen an, wie Sie benötigen – der Zähler bewegt sich nicht.

Es handelt sich um eine integrierte Plattform, nicht um ein Bündel. SecureVisio vereint SIEM, SOAR, UEBA und GRC in einem einzigen System. SOAR und SIEM sind lizenzpflichtig; UEBA- und GRC-Funktionen erfordern keinen Kauf zusätzlicher Pakete. Es gibt keine „Engine plus vier Add-ons”-Zusammenbauübung.

Dieser Unterschied – planbarer Input, integrierter Funktionsumfang – ist das Fundament, auf dem alles Weitere aufbaut.

Sechs praxisnahe Szenarien, die die SIEM-TCO klammheimlich aufblähen

Dies sind keine hypothetischen Fälle. Es sind die Situationen, die die Lücke zwischen dem angebotenen und dem realen Preis erzeugen – und die vor der Vertragsunterzeichnung nur selten zur Sprache kommen.

1. Die Anwendungsfehler-Schleife

Ein Entwicklungsteam bringt eine neue interne Anwendung oder Datenbank mit einem kleinen Syntaxfehler in Produktion. Der fehlerhafte Prozess beginnt, alle paar Millisekunden einen „Connection timeout”-Fehler in die Logs zu schreiben.

Warum es schmerzt: Ein einzelner in einer Schleife laufender Prozess kann in kurzer Zeit zehn oder sogar hunderte Gigabyte unnötiger Logs erzeugen – abhängig von Anwendung und Umgebung.

Die Folge: Ein Ingest-basiertes SIEM nimmt all das an. Am nächsten Morgen stellt das Team fest, dass es sein monatliches Lizenzkontingent in etwa acht Stunden aufgebraucht hat. Die Plattform verhängt eine Lizenzverletzung – und die Wahl besteht darin, entweder eine teurere Stufe zu kaufen oder im denkbar schlechtesten Moment mit eingeschränkter Suchfunktion zu arbeiten. Bei Asset-basierter Lizenzierung ändert dieselbe Fehlerschleife nichts an der Rechnung; die Geräteanzahl hat sich nicht verändert.

2. Betriebssystem-Updates mit hohem Log-Aufkommen

Hersteller ändern regelmäßig, wie ihre Systeme protokollieren. Nach einem größeren Server- oder Verzeichnisdienst-Update können Domänencontroller oder andere Infrastrukturkomponenten deutlich mehr Authentifizierungs- oder Audit-Logs erzeugen – etwa nach umfangreichen Updates oder Konfigurationsänderungen, selbst wenn sich an der Umgebung selbst nichts Wesentliches geändert hat.

Warum es schmerzt: Das Log-Volumen stieg, also stieg unter einem GB/Tag-Modell auch die Rechnung mit.

Die Folge: Der Kunde hat nichts falsch gemacht. Er hat niemanden eingestellt, keine neuen Systeme angebunden, keine Infrastruktur ausgebaut. Er hat lediglich seine Umgebung gepatcht – und die SIEM-Rechnung ist um zweistellige Prozentwerte gestiegen. Asset-basierte Lizenzierung ist dagegen immun: Die überwachten Geräte sind dieselben Geräte.

3. Die Kosten der Datenfilterung vor dem SIEM

Sobald Teams verstehen, wie teuer Ingest-Preise sind, folgt ein naheliegender Gedanke: die Logs an der Quelle filtern und nur die wichtigen weiterleiten.

Warum es schmerzt: Das gut umzusetzen erfordert die Bereitstellung und Wartung zusätzlicher Werkzeuge zur Datenstromverarbeitung – Heavy Forwarder, dedizierte Pipeline-Produkte oder handgeschriebene Log-Shipping-Skripte.

Die Folge: Sie widmen nun Entwicklungsstunden (oder kaufen ein weiteres Produkt), um fortlaufend Regeln zur Log-Verwerfung zu schreiben und zu aktualisieren. Sie zahlen – in Gehalt oder Lizenzen – für das Privileg, herauszufinden, wie Sie Daten nicht an das System senden, das sie eigentlich analysieren sollte. Die Optimierung selbst wird zum Kostenfaktor.

4. Indizierungs-Overhead beim Speicher

Eine verbreitete Annahme vor dem Kauf: „Wir erzeugen 100 GB Logs pro Tag, also brauchen wir 100 GB Speicher.” Das ist ein schwerwiegender Rechenfehler.

Warum es schmerzt: Um Daten schnell durchsuchbar zu machen, indiziert ein Ingest-basiertes SIEM sie umfassend und erzeugt dabei große Metadaten- und Indexdateien. Abhängig von Plattform, Indizierungsmethode und Log-Typ können 100 GB Rohdaten nach Verarbeitung und Indizierung deutlich mehr Speicher erfordern.

Die Folge: Speicher-Arrays füllen sich weit schneller als geplant. Schlimmer noch: Diese Kategorie von Plattform verlangt Speicher mit sehr hoher IOPS-Leistung – schnelle SSD/NVMe –, um überhaupt zu funktionieren. In manchen Umgebungen können die Kosten für Hochleistungsspeicher zu einem erheblichen Bestandteil der gesamten SIEM-Betriebskosten werden und die Softwarelizenzkosten mitunter erreichen oder übersteigen. SecureVisio hingegen nutzt eine optimierte Datenbankstruktur, die für dasselbe Datenvolumen weniger Speicherplatz benötigt, und komprimiert archivierte Logs, sobald ihre konfigurierte Aufbewahrungsfrist abgelaufen ist – archivierte Logs bleiben über eine dedizierte Anwendung weiterhin einsehbar.

5. Defekte Parser nach einer Format-Änderung des Herstellers

Sie haben Logs, die von Cloud-Plattformen und Firewall-Herstellern einlaufen. Einer dieser Hersteller bringt ein größeres Update heraus und ändert seine Log-Struktur – etwa indem er ein Feld von src_ip in source_network_address umbenennt.

Warum es schmerzt: Das SIEM „versteht” diese Logs über Nacht nicht mehr. Erkennungsregeln, die auf den alten Feldnamen verweisen, feuern stillschweigend nicht mehr.

Die Folge: Das System wird für eine ganze Kategorie von Bedrohungen blind. Die Behebung kann eine Aktualisierung von Parsern oder Integrationen erfordern – intern oder mit Unterstützung des Herstellers bzw. Partners, je nach Plattform und Support-Modell. Für SecureVisio-Kunden mit aktivem Support-Vertrag werden Parser-Updates für unterstützte Technologien im Rahmen der Standardwartung vom Hersteller bereitgestellt.

6. Plattformspezifisches Know-how treibt die Kosten

Aufgrund der Komplexität proprietärer Abfragesprachen und verteilter Architektur ist diese Kategorie von SIEM kein „einrichten und vergessen”-System.

Warum es schmerzt: Die Optimierung großflächiger SIEM-Deployments erfordert oft plattformspezifisches Fachwissen, insbesondere in Umgebungen mit hohem Event-Aufkommen und komplexen Suchlasten.

Die Folge: Die Organisation muss zwischen zwei Wegen wählen. Entweder finanziert sie einen dedizierten, spezialisierten SIEM-Architekten – eine erhebliche jährliche Gehaltsposition – oder sie zahlt Monat für Monat ein externes Unternehmen dafür, Dashboards zu beraten und zu reparieren, die nicht mehr funktionieren. So oder so ist der Betriebsaufwand strukturell an die Komplexität der Plattform gekoppelt. SecureVisio bringt integrierte analytische Logik und vorkonfigurierte operative Inhalte mit, die den Umfang an individueller Entwicklung und spezialisiertem Plattform-Know-how reduzieren, der bei Deployment und laufendem Betrieb üblicherweise erforderlich ist.

Auch die Deployment-Komplexität ist ein Kostenfaktor

TCO besteht nicht nur aus Lizenzen und Hardware. Der Aufwand, ein SIEM überhaupt nutzbar zu machen, ist eine reale, wiederkehrende Ausgabe – und genau hier trennen sich integrierte Plattformen deutlich von zusammengesetzten.

Die „Zusammenbau-Steuer” eines modularen SIEM

Um ein modulares, Ingest-basiertes SIEM als funktionierende Erkennungsplattform aufzusetzen, muss ein Team in der Regel:

Die separat lizenzierte Enterprise-Security-Schicht (SIEM) zusätzlich zur Kern-Engine erwerben und bereitstellen. Korrelationsregeln, Parser und Dashboards während der Konfiguration erstellen – eine Arbeit, die praktisch die Beherrschung der proprietären Such-/Verarbeitungssprache der Plattform voraussetzt. SOAR-Module separat erwerben und mit dem SIEM integrieren.

Jeder dieser Schritte verschlingt Spezialistenzeit, und jeder von ihnen wiederholt sich, sobald sich die Umgebung ändert.

Von Grund auf integriert

SecureVisio wird als ein einziges System ausgeliefert – SIEM, SOAR, UEBA und GRC gemeinsam – mit integrierter analytischer Logik und den operativen Komponenten, die ein SOC benötigt, bereits an Bord: Reports, Playbooks, Sicherheitsregeln, System-Aktionen und Priorisierungsregeln. Diese werden während des Deployments abgestimmt statt während des Deployments erst gebaut.

Der praktische Effekt: Nach dem Deployment versteht das System bereits, was es sieht. Organisationen können mit vorkonfigurierten analytischen Inhalten und operativen Workflows starten und diese anschließend an ihre eigene Umgebung anpassen, statt jede Regel und jeden Prozess von Grund auf neu zu entwickeln. Die Time-to-Value bemisst sich in Feinabstimmung, nicht in Monaten der Regelerstellung.

Schlankerer Infrastruktur-Fußabdruck

Ein modulares, Ingest-basiertes SIEM erfordert bei mittlerer Größe in der Regel eine verteilte Architektur: separate Maschinen für die Such- und Oberflächenschicht und separate Maschinen für die Indizierungsschicht – wobei letztere große IOPS-Mengen und schnellen SSD/NVMe-Speicher verlangt, weil die Plattform alles indiziert.

Die optimierte Datenbankstruktur von SecureVisio erlaubt einen stabilen Betrieb auf schlankerer, konsolidierter Infrastruktur. In vielen Deployments kann eine Standard-Implementierung von SecureVisio auf einer vergleichsweise geringen Anzahl virtueller Maschinen laufen – abhängig von Umfang, Aufbewahrungsanforderungen und Hochverfügbarkeits-Architektur. Weniger Maschinen bedeuten weniger Lizenzierung auf Hypervisor- und Betriebssystemebene, weniger Patch-Aufwand und weniger zu überwachen – eine ruhigere, günstigere Plattform im laufenden Betrieb.

Die beiden Kostenmodelle im direkten Vergleich

Kostendimension	Klassisches Ingest-basiertes SIEM	SecureVisio
Lizenzierungsgrundlage	Datenvolumen (GB/Tag) oder Events pro Sekunde (EPS)	Überwachte Assets (Workstations, Server, mobile Geräte)
Budget-Planbarkeit	Variabel – bewegt sich mit dem Log-Volumen	Fix – zum Kaufzeitpunkt nach Geräteanzahl dimensioniert
Limit für Log-Quellen	Faktisch durch die Volumenstufe begrenzt	Keine Begrenzung der Anzahl an Log-Quellen
Modulstruktur	Kern-Engine + separat lizenzierte SIEM-, SOAR-, UEBA-, Risikomodule	Integriertes SIEM + SOAR + UEBA + GRC; UEBA und GRC ohne Zusatzpakete
Reaktion auf einen Log-Spike	Mögliche Überschreitungsgebühr oder Lizenzverletzung	Keine Auswirkung auf die Kosten
Parser-Updates nach Format-Änderung	Oft ein berechnetes Projekt oder interne Architektenzeit	Vom Hersteller im Rahmen des Supports bereitgestellt, „out of the box”
Speicherprofil	Hoher Indizierungs-Overhead; SSD/NVMe mit hoher IOPS-Leistung nötig	Optimierte Datenbankstruktur; geringerer Speicherbedarf; Komprimierung archivierter Logs
Standard-Infrastruktur	Verteilt: getrennte Such- und Indizierungsschichten	Konsolidiert: Architektur mit weniger Infrastrukturkomponenten
Spezialisten-Abhängigkeit	Proprietäre Abfragesprache; dedizierter Architekt oft erforderlich	Integrierte Analytik-Logik; betreibbar ohne dedizierten Spezialisten

Was das für eine SOC-Leitung bedeutet

Das Argument für SecureVisio lautet nicht „es ist billiger” im engen Sinne einer kleineren Zahl im Angebot. Es lautet, dass die Kosten bekannt und stabil sind.

Mit einem Asset-basierten Modell können Sie die Frage beantworten, die jeder CISO irgendwann stellt – was wird uns diese Plattform nächstes Jahr kosten? – ohne Wenn und Aber. Die Zahl ist an die Anzahl der Geräte gekoppelt, die Sie schützen und die Sie kontrollieren und planen, statt an das Datenvolumen, das Ihre Umgebung zufällig ausstößt und das Sie nicht kontrollieren. Es gibt keine Überschreitungsklausel, die hinter einem lauten Patch-Zyklus lauert. Es gibt keine separate Bestellung beim nächsten Wunsch nach Verhaltensanalytik oder Risiko-Reporting. Es gibt keinen Architekten, dessen Weggang die Plattform gefährdet.

Diese Planbarkeit erstreckt sich auch auf die Art, wie Sie Verträge abschließen. Weil die Kosten an einen stabilen, kontrollierbaren Input gekoppelt sind, wird es praktikabel, mehrjährige Verträge mit planbaren Betriebskosten abzuschließen – mit Deployment- und Plattform-Management-Kosten, die für die gesamte Laufzeit von Anfang an bekannt sind. Sich auf ein festes Mehrjahresbudget festzulegen, ist auf einer volumenbasierten Plattform weit schwieriger, bei der die Rechnung sich jedes Quartal ändern kann; ein Asset-basiertes Modell gibt Ihnen und Ihrer Finanzabteilung eine Zahl, mit der sich über Jahre planen lässt, nicht nur über Monate.

Für ein SecOps-Team, das an Erkennungsabdeckung und Reaktionszeit gemessen wird, hat diese Stabilität auch einen operativen Nutzen: Budget, das nicht von überraschenden Überschreitungen und Parser-Neuprojekten aufgezehrt wird, ist Budget, das für die Arbeit zur Verfügung steht, die das Risiko tatsächlich senkt.

Häufig gestellte Fragen

Was ist SIEM-Ingest-Pricing? Ingest-Pricing lizenziert ein SIEM nach dem Datenvolumen, das es pro Tag indiziert – meist gemessen in Gigabyte pro Tag (GB/Tag), manchmal in Events pro Sekunde (EPS). Ihre Kosten steigen und fallen mit dem Log-Volumen, statt sich nach Größe oder Risikoprofil Ihrer Organisation zu richten.

Warum führt Ingest-basiertes SIEM-Pricing zu Budgetüberschreitungen? Weil das Log-Volumen weitgehend außerhalb Ihrer Kontrolle liegt. Anwendungsfehler, Betriebssystem-Updates, geänderte Hersteller-Logging und Fehlkonfigurationen können das Volumen allesamt in die Höhe treiben, ohne dass Sie eine bewusste Entscheidung getroffen hätten – und unter einem Ingest-Modell folgt die Rechnung dem Volumen.

Wie unterscheidet sich die Lizenzierung von SecureVisio? SecureVisio wird nach der Anzahl der überwachten Assets lizenziert – Workstations, Server, mobile Geräte und ähnliche Endpunkte. Die Kosten hängen nicht von EPS ab, und die Anzahl der Log-Quellen ist unbegrenzt. Sie dimensionieren die Lizenz beim Kauf nach Ihrer Geräteanzahl.

Muss ich SOAR und UEBA bei SecureVisio separat kaufen? Nein. SecureVisio ist eine integrierte Plattform aus SIEM, SOAR, UEBA und GRC. SIEM und SOAR sind lizenzpflichtig; UEBA- und GRC-Funktionen erfordern keinen Kauf zusätzlicher Pakete.

Benötigt SecureVisio weniger Infrastruktur als ein klassisches SIEM? Ja. Die optimierte Datenbankstruktur erlaubt den Betrieb auf konsolidierter Infrastruktur – eine Standard-Architektur nutzt rund vier virtuelle Maschinen – statt des verteilten Modells aus Such- und Indizierungsschicht, das Ingest-basierte SIEMs typischerweise erfordern.

Was passiert, wenn ein Log-Hersteller sein Log-Format ändert? Bei vielen Ingest-basierten SIEMs werden defekte Parser zu einem berechneten Projekt oder verbrauchen interne Architektenzeit. Bei SecureVisio werden Parser-Updates dieser Art vom Hersteller im Rahmen des Support-Vertrags bereitgestellt, „out of the box”.

Kann ich einen mehrjährigen SIEM-Vertrag mit festem Budget abschließen? Mit SecureVisio ja. Weil die Kosten an einen stabilen, kontrollierbaren Input gekoppelt sind – Ihre Anzahl überwachter Assets –, ist es praktikabel, mehrjährige Verträge abzuschließen, typischerweise vier bis fünf Jahre, mit Deployment- und Plattform-Management-Kosten, die für die gesamte Laufzeit von Anfang an bekannt sind. Auf einer volumenbasierten Plattform, bei der die Rechnung sich jedes Quartal ändern kann, ist das deutlich schwieriger.