SIEM für MSSP: die Betriebsplattform für Ihr SOC
Alltag im SOC eines MSSP
Ihre Analysten arbeiten nicht in einer Umgebung – sondern in vielen. Jede Kundenumgebung bringt eigene Logquellen mit, eigene Systeme und eigene Erwartungen – und jede erzeugt Alerts, die zunächst alle gleich dringend aussehen. Der größte Teil einer Schicht geht dafür drauf, aus diesem Strom die wenigen Fälle herauszuziehen, die eine Untersuchung wirklich verdienen.
Betriebsrealität im MSSP-SOC: was operative Qualität bedeutet
Vier Dinge entscheiden im Tagesgeschäft, ob eine Plattform trägt.
Wo die Daten liegen und was sie kosten.
Ein MSSP muss Logs auch dann vorhalten, wenn sie nie eine Korrelationsregel auslösen – für Rückfragen, Untersuchungen und Beweiszwecke. Eine Plattform, die jede Zeile durch dieselbe Verarbeitung zwingt, macht aus dieser Vorhaltung ein Kostenproblem.
Wie viel Vorarbeit die Maschine übernimmt.
Triage ist der Ort, an dem Analystenzeit tatsächlich verbraucht wird. Entscheidend ist nicht, ob eine Plattform „KI” enthält, sondern ob ihre Entscheidungen nachvollziehbar sind: Ein Alert, der automatisch geschlossen wurde, muss auch später erklärbar bleiben.
Der Funktionsumfang.
Je mehr Aufgaben – Detection, Response, Verhaltensanalyse, Threat Intelligence – auf getrennte Produkte verteilt sind, desto mehr Integrationsarbeit trägt der Provider selbst.
Reifegrad.
Das Onboarding einer neuen Datenquelle darf kein Projekt über Monate sein, wenn der Kunde in zwei Wochen live gehen muss. Integrationen, Parser und System Actions bestimmen den Zeitpunkt, ab dem ein Kunde Umsatz erzeugt statt nur Aufwand.
Lizenzierung: gebaut für einen Provider mit vielen Umgebungen, nicht mit einer
Eine einzige, serviceweite Lizenz trägt jede Umgebung, die Sie betreiben: keine Abrechnung nach EPS oder Logvolumen, zu keinem Zeitpunkt – lizenziert wird nach der Anzahl der Cyber Assets. Als MSSP kaufen Sie ein definiertes Paket an Assets und verteilen es nach Bedarf auf Ihre Endkundenumgebungen – Kostenplanbarkeit entsteht aus der Asset-Zahl selbst, nicht daraus, wie viele Daten ein einzelner Kunde in einem Monat erzeugt.
Demo anfordern
Betriebliche MSSP-Anforderung: SecureVisio-Funktion
Die Tabelle benennt zu jeder Anforderung den konkreten Mechanismus – nicht die Kategorie.
| Betriebliche MSSP-Anforderung | SecureVisio: Mechanismus |
|---|---|
| Nr. 1 Risikoanalyse | Natives Risikomodul, ausgerichtet an ISO 27005. Das Risk Scoring betrachtet das Asset nicht isoliert: Die CMDB liefert den technischen und organisatorischen Kontext jedes Systems, die BIA seine geschäftliche Relevanz – welche Prozesse davon abhängen und was es für die Organisation bedeutet, wenn es kompromittiert wird. Der Score verbindet Eintrittswahrscheinlichkeit mit dieser geschäftlichen Auswirkung, statt jedes Asset als gleich kritisch zu behandeln. Die Plattform erzeugt keine Richtlinien – Risikomethodik, Risikoregister und Berichtsformat bleiben Entscheidung Ihrer Organisation, und genau dort setzen die Advanced Services an. |
| KI-gestützte Automatisierung in der Triage | Die KI-gestützte Triage bewertet jeden Alert als True oder False Positive, priorisiert ihn über die integrierte Risikoanalyse und reichert ihn mit Kontext an – und übergibt die Entscheidung dann entweder an den Analysten oder schließt den Alert selbst, immer mit sichtbarer, auditierbarer Begründung. Auch Parser und Detection-Regeln kann die KI erzeugen. Die vollständige Architektur dahinter – das Vier-Schichten-Modell, der Agentic SOC und wie autonome Response abgegrenzt und begrenzt wird – finden Sie auf der Use-Case-Seite Agentic SOC. |
| Voller Funktionsumfang in einer Plattform | SIEM, SOAR, UEBA, XDR und CTI bilden eine integrierte Plattform, ausgeliefert als eine Implementierung statt als Engine plus Add-ons. UEBA ist „fester Bestandteil der SecureVisio-Plattform und benötigt keine separate Lizenz”. Ab Tag eins sind über 500 einsatzfertige Detection-Regeln aktiv – gemappt auf das MITRE-ATT&CK-Framework. Zu jedem Alert wird automatisch ein Attack Graph erzeugt, die Backtracking-Analyse identifiziert betroffene Assets, und Threat Hunting läuft direkt aus dem Incident heraus – ohne separates Modul. Grundlage bleibt der Geschäftskontext aus CMDB, BIA und Risikomodul – Details zur Engine zeigt die Seite zur SIEM-Plattform. |
| Reifegrad: Integrationen, Parser, System Actions | Cloud-Umgebungen (GCP, AWS, Azure), EDR/XDR, NDR und Firewalls sind angebunden; die Datenerfassung läuft direkt über API, Syslog oder den XDR-Agenten. Das Onboarding einer neuen Datenquelle dauert Tage, höchstens Wochen; die KI analysiert eingehende Logs und schlägt sofort einsatzfertige Korrelationsregeln vor, was diesen Teilschritt auf Stunden verkürzt. Der Rollout der Plattform selbst ist eine Sache von Wochen, nicht von Monaten. System Actions automatisieren wiederkehrende Arbeit – Daten von Firewalls einsammeln, CTI-Informationen zusammenführen, ein Szenario ausführen. Der Support ist europäisch. |
| Technische Skalierbarkeit | Die Plattform skaliert vollständig horizontal, zusätzliche Collectors kommen ohne Lizenzmehrkosten hinzu und laufen physisch, virtuell on-premises oder in der Cloud. Der Betrieb erfolgt on-premises oder in einer EU-Private-Cloud, Daten werden ausschließlich auf europäischer Infrastruktur gehostet – ein Punkt, der für die digitale Souveränität Ihres Service zählt. |
Evidence
Wenn Sie eine Plattform weiterverkaufen oder Services darauf aufbauen, wird die Stabilität Ihres Herstellers zu einer Position in Ihrem eigenen Risikomodell.
Der Support arbeitet für dringende Fälle im 24-Stunden-Modell: Tickets laufen über Jira, P1-Fälle deckt ein dediziertes Support-Team rund um die Uhr ab – nicht nur zu üblichen Geschäftszeiten. Tickets werden schnell gelöst, und dazu gehört auch Engineering-Arbeit wie das Bauen nicht-standardisierter Parser, nicht nur die Triage vorhandener.
Verbundene Instanzen müssen nicht dieselbe Version fahren, sodass ein MSSP eine Kundenumgebung aktualisieren kann, ohne die übrigen auf denselben Zeitplan zu zwingen. Das steht neben der mandantenfähigen Konsole und HA (High Availability) für dasselbe betriebliche Design – die Plattform ist für einen Provider gebaut, der viele Umgebungen in unterschiedlichem Tempo betreibt, nicht für eine Umgebung, die einmal aufgesetzt wird.
Die Log-Weiterleitung läuft typischerweise über Syslog – ein einfacher, standardisierter Mechanismus – und entscheidend: Der Kunde behält Eigentum an und Zugriff auf seine Detection-Regeln, Parser und alles Weitere, das auf der Plattform aufgebaut wurde. Das ist ein bewusster Gegenentwurf zu der Art, wie MDR-Services häufig funktionieren, bei denen Regeln und Tuning in der Blackbox des Providers bleiben und mit ihm verschwinden, wenn die Beziehung endet. Hier bleibt Ihres, was Sie gebaut haben – in welche Richtung Sie auch migrieren.
Über 250 Kunden in ganz Europa setzen die Plattform ein.
Auf Gartner Peer Insights liegt die Bewertung verifizierter Nutzerrezensionen bei 4,8 von 5. SecureVisio ist als Unternehmen – nicht nur für das Produkt – nach ISO 27001 und ISO 9001 zertifiziert. 2022 wurde das Unternehmen im Deloitte Fast 50 als führendes Unternehmen ausgezeichnet (Deloitte Fast 50, „Leading Company 2022″).
Gartner ★ 4.8/5
Reviews
Bewertungen ansehen
G2 ★ 5/5
Peer Insights
Bewertungen ansehen
ISO 27001
Zertifikat
ISO 9001
Zertifikat
Security Made in Poland
Poland Security Congress
250+
Kunden in Europa
Deloitte Fast 50
Führendes Unternehmen · 2022
Häufig gestellte Fragen
Die Plattform bewertet Alerts als True oder False Positive, priorisiert sie über die integrierte Risikoanalyse und reichert sie mit Kontext an. Sie kann die Entscheidung an den Analysten übergeben oder den Alert selbst schließen. Der Analyst sieht immer die Begründung hinter der KI-Aktion, und die Entscheidung bleibt auditierbar – auch Monate später, vor Ihrem Kunden.
Ja. Ab Version 6.0 steuert eine zentrale, mandantenfähige Konsole die Incident- und Schwachstellenbearbeitung über mehrere SecureVisio-Instanzen hinweg, einschließlich eigenständiger Installationen. Verbundene Instanzen müssen nicht dieselbe Version fahren. Logs und Events lassen sich instanzübergreifend durchsuchen – gleichzeitig über mehrere Instanzen statt nacheinander.
Tage, höchstens Wochen. Unterstützt wird das durch KI-gestütztes Daten-Onboarding: Die KI analysiert eingehende Logs und schlägt sofort einsatzfertige Korrelationsregeln vor, was diesen Teilschritt auf Stunden verkürzt. Parser und Detection-Regeln kann die KI vollständig erzeugen. Der Rollout der Plattform selbst ist eine Sache von Wochen, nicht von Monaten.
Horizontal: Zusätzliche Collectors lassen sich ohne den Kauf weiterer Lizenzen hinzufügen – physisch, virtuell oder in der Cloud. Ab Version 6.0 sind die SIEM-Dienste multithreaded und die PolicyEngine ist aufgeteilt. Weil Log Management vom SIEM getrennt ist, wächst die Vorhaltung unabhängig davon, was korreliert wird; Retention Policies gelten je Gerät.
Lizenziert wird nach Asset-Zahl, erfasst auf Endkundenebene. Als MSSP erwerben Sie vorab ein definiertes Paket an Assets und verteilen es auf die Umgebungen, die Sie betreuen – das Onboarding eines neuen Kunden ist damit eine Frage der Entnahme aus diesem Paket, nicht eines neuen Vertrags oder einer unvorhersehbaren EPS-basierten Rechnung.
Nächster Schritt
Bringen Sie Ihre Zahlen mit: Datenvolumen, Anzahl der Kundenumgebungen, geplante Integrationen.
Wir gehen Architektur- und Mandantenfähigkeitsfragen direkt an Ihrem Setup durch.
